파이프라인이 실패했을 때: Monitoring hub와 재시도·알림 설계

원문: Create alerts for pipeline runs 게시일: 2026-03-31

파이프라인을 스케줄에 걸어두고 “돌아가겠지” 하고 잊어버리면 꼭 새벽에 실패해요. 문제는 실패 자체가 아니라, 실패했다는 걸 언제 알게 되느냐예요. Fabric Data Factory는 실행 이력을 보는 화면(Monitoring hub)과, 활동이 실패했을 때 자동으로 재시도하거나 다른 경로로 흘려보내는 설정, 그리고 사람에게 바로 알리는 활동을 각각 따로 제공해요. 이 셋을 엮으면 최소한의 오류 처리 체계가 됩니다.

Monitoring hub에서 실행 이력 읽기

워크스페이스의 파이프라인에서 More options(…) → View run history를 누르면 최근 실행 목록이 뜨고, 여기서 Go to monitor로 들어가면 더 자세한 필터링이 가능해요. Status·Item Type·Start Time·Submitter 같은 기준으로 실행을 걸러볼 수 있고, 특정 실행을 선택하면 실패한 활동의 Run ID나 오류 내용까지 볼 수 있어요.

실패한 실행은 그 자리에서 Rerun으로 다시 돌릴 수 있는데, 파이프라인 전체를 재실행할지 실패한 활동부터만 재실행할지 고를 수 있어요. 활동이 2,000개를 넘는 대형 파이프라인이라면 Load more로 나머지를 불러오면 됩니다. 시간 흐름을 한눈에 보고 싶으면 Gantt view로 전환해서 실행마다 막대로 표시된 소요 시간과 겹침·지연 패턴을 비교할 수도 있어요.

워크스페이스 설정에서 Monitoring을 켜면 모든 아이템의 로그 수준 이벤트가 KQL 데이터베이스(ItemJobEventLogs 테이블)에 쌓이는 워크스페이스 모니터링도 쓸 수 있어요. 개별 파이프라인 화면을 일일이 열어보는 대신 KQL 쿼리로 성공·실패 추세나 오류를 한 번에 분석하고 싶을 때 유용해요.

활동별 재시도 설정

파이프라인 안의 각 활동은 캔버스에서 선택 후 General 탭에서 Enable retries를 켜면 재시도가 활성화돼요. 재시도 횟수(1~1000회, 기본값 1회)와 시도 사이 대기 시간을 활동마다 따로 지정할 수 있습니다.

대기 방식은 두 가지예요.

Fixed: 매번 같은 초만큼 기다려요(기본 30초). 짧고 예측 가능한 실패에 맞아요.
Increasing Delay: 지수 백오프¹ 방식으로, 시도할수록 대기 구간이 지수적으로 넓어지다가 설정한 최댓값(기본 3600초)에서 멈춰요. 업스트림 서비스가 회복할 시간을 점점 더 주는 식이라 오래가는 장애에 적합해요.

미리보기 상태인 Retry conditions를 쓰면 무조건 재시도하는 대신 특정 조건에서만 재시도하도록 좁힐 수도 있어요. 오류 메시지 내용, 실패 유형(사용자 오류/시스템 오류), 오류 코드(예: 429 요청 제한) 중 하나를 기준으로 조건을 걸 수 있는데, 인증 실패처럼 재시도해도 절대 풀리지 않는 오류에 재시도 횟수를 낭비하지 않으려는 목적이에요. 단, 이 조건부 재시도는 Copy data, Notebook, Dataflow, Stored procedure 같은 일부 활동 유형에서만 지원돼요.

On failure로 분기하기

파이프라인 캔버스에서 활동끼리 연결하는 선(종속성)에는 조건이 붙어요.

On success(녹색): 앞 활동이 성공하면 실행
On failure(빨강): 앞 활동이 실패하면 실행
On completion(파랑): 성공·실패 상관없이 완료되면 실행
On skip(회색): 앞 활동이 건너뛰어지면 실행

재시도를 다 써도 실패하는 활동 뒤에 On failure 조건으로 후속 활동을 연결해 두면, 그 경로로만 흐르는 “실패 시 처리” 흐름을 만들 수 있어요. 이 경로 끝에 알림 활동을 놓는 게 가장 흔한 패턴입니다.

Teams·Outlook 활동으로 알림 보내기

활동 단위 알림은 감시하려는 활동 바로 뒤에 Office 365 Outlook 활동(이메일 발송)이나 Teams 활동(Teams 메시지 발송)을 On failure로 연결하는 방식으로 만들어요. Outlook 활동은 사용자 인증(OAuth), 워크스페이스 ID, 서비스 주체 세 가지 인증 방식을 지원해서, 개인 계정에 묶지 않고 운영 환경에서 자동화하기도 쉬워요. 활동 하나에 감시 대상을 여러 개 연결하면 연결된 모든 활동이 그 조건(예: 실패)을 만족해야 알림이 발동한다는 점도 기억해 둘 만해요. 여러 활동을 각각 따로 감시하고 싶다면 활동마다 별도의 알림 활동을 두는 게 맞습니다.

파이프라인 전체 단위로는 더 간단한 방법도 있어요. 스케줄된 실행이 실패했을 때만 알림을 받고 싶다면, 파이프라인의 Schedule 설정에서 Failure notifications에 사용자나 그룹을 추가하기만 하면 됩니다. 파이프라인 생성·삭제·수정이나 워크스페이스 전체의 실패를 폭넓게 감시하고 싶다면 Data Activator²로 규칙을 만들어 이메일·Teams 알림을 연결하는 방법도 있어요.

정리

오류 처리는 세 겹으로 쌓는 구조예요. 먼저 활동별 재시도로 일시적인 오류를 스스로 넘기게 하고, 그래도 실패하면 On failure 경로로 흘려보내고, 그 끝에 Teams·Outlook 활동을 달아 사람에게 알립니다. 그리고 이 모든 실행 기록은 Monitoring hub에서 필터링하고 재실행할 수 있으니, 알림을 받은 다음 확인하러 갈 곳도 이미 정해져 있는 셈이에요.

어휘 주석

지수 백오프(exponential back-off): 재시도할 때마다 대기 시간을 점점 늘려가는 전략. 장애가 난 서비스에 짧은 간격으로 계속 요청을 몰아치지 않도록 부담을 줄여줘요.
Data Activator: 특정 이벤트나 조건을 감시하다가 조건이 충족되면 이메일·Teams 메시지 같은 액션을 자동으로 실행하는 Fabric의 규칙 기반 알림 기능.