---
title: 파이프라인이 실패했을 때: Monitoring hub와 재시도·알림 설계
description: Monitoring hub에서 실행 이력을 읽는 법, 활동별 재시도 설정, On failure 분기와 Teams·Outlook 활동으로 알림 보내는 기본 오류 처리 구성을 정리했어요.
date: 2026-09-28
  tags: [Data Pipeline, Monitoring hub, 오류 처리, 재시도, Fabric]
cards:
  - /cards/fabric-pipeline-monitoring-and-error-handling/card-01.png
  - /cards/fabric-pipeline-monitoring-and-error-handling/card-02.png
  - /cards/fabric-pipeline-monitoring-and-error-handling/card-03.png
  - /cards/fabric-pipeline-monitoring-and-error-handling/card-04.png
  - /cards/fabric-pipeline-monitoring-and-error-handling/card-05.png
  - /cards/fabric-pipeline-monitoring-and-error-handling/card-06.png
  - /cards/fabric-pipeline-monitoring-and-error-handling/card-07.png
author: Lissa
source: https://interlinear.work/notes/fabric-pipeline-monitoring-and-error-handling/
---

> **원문:** [Create alerts for pipeline runs](https://learn.microsoft.com/en-us/fabric/data-factory/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**: 지수 백오프<sup>1</sup> 방식으로, 시도할수록 대기 구간이 지수적으로 넓어지다가 설정한 최댓값(기본 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<sup>2</sup>로 규칙을 만들어 이메일·Teams 알림을 연결하는 방법도 있어요.

## 정리

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

---

## 어휘 주석

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