---
title: 파이프라인을 언제 돌릴까: 스케줄과 이벤트 트리거
description: 시간마다 도는 스케줄 실행과, 파일이 도착하면 바로 도는 이벤트 트리거를 Fabric 파이프라인에서 어떻게 설정하는지, 언제 뭘 골라야 하는지 정리했어요.
date: 2026-09-27
tags: [Data Pipeline, 스케줄, 이벤트 트리거, Activator, Fabric]
cards:
- /cards/fabric-pipeline-schedule-and-event-triggers/card-01.png
- /cards/fabric-pipeline-schedule-and-event-triggers/card-02.png
- /cards/fabric-pipeline-schedule-and-event-triggers/card-03.png
- /cards/fabric-pipeline-schedule-and-event-triggers/card-04.png
- /cards/fabric-pipeline-schedule-and-event-triggers/card-05.png
- /cards/fabric-pipeline-schedule-and-event-triggers/card-06.png
- /cards/fabric-pipeline-schedule-and-event-triggers/card-07.png
author: Lissa
source: https://interlinear.work/notes/fabric-pipeline-schedule-and-event-triggers/
---
> **원문:** [Run, schedule, or use events to trigger a pipeline](https://learn.microsoft.com/en-us/fabric/data-factory/pipeline-runs)
> **게시일:** 2026-03-10 · **Microsoft Fabric 설명서**
파이프라인을 만들고 나면 다음 질문은 "이걸 언제 돌릴까"예요. 매일 새벽에 한 번 돌리면 되는 것도 있고, 파일이 도착하는 순간 바로 반응해야 하는 것도 있죠. Fabric 파이프라인은 이 둘을 다 지원하는데, 원리와 쓰는 시점이 꽤 달라요.
## 세 가지 실행 방식
Fabric 파이프라인을 시작하는 방법은 크게 셋이에요.
- **온디맨드(On-demand)**: 캔버스에서 **Run**을 눌러 즉시 한 번 돌리는 방식. 개발·테스트할 때 씁니다.
- **스케줄(Scheduled)**: 시간과 빈도를 정해서 자동으로 반복 실행.
- **이벤트 기반(Event-based)**: 스토리지에 파일이 새로 생기거나 지워지는 것 같은 특정 사건이 일어나면 실행.
이번 글은 뒤 두 가지, 스케줄과 이벤트 트리거에 집중해요.
## 스케줄: 시간을 기준으로 도는 방식
파이프라인 홈 탭의 **Schedule**에서 **Add Schedule**을 누르면 설정 화면이 열려요. 여기서 정하는 값은 이렇습니다.
- 시작일·종료일, 빈도, 시간대
- **Fixed schedule**: 매일 몇 시, 몇 시간마다처럼 고정된 반복 주기
- **Interval-based schedule (미리보기)**1: 겹치지 않는 고정 구간 단위로 실행 — 이 경우 파이프라인 식 빌더에 `Window start time`, `Window end time`이라는 트리거 파라미터가 자동으로 추가돼요.
스케줄을 걸 때 한 가지 특이한 제약이 있어요. **시작일과 종료일을 반드시 둘 다 지정**해야 하고, 끝없이 도는 스케줄이라는 옵션은 없어요. 계속 돌리고 싶으면 종료일을 아주 먼 미래(예: 2099년)로 잡아두면 돼요. 파이프라인 하나에 스케줄을 최대 20개까지 추가할 수 있어서, "평일에는 이 시간, 주말엔 저 시간" 같은 조합도 가능하고요. 파이프라인에 파라미터가 정의돼 있다면 스케줄마다 값(직접 입력 또는 변수 라이브러리 참조)을 다르게 넣을 수도 있어요.
실행이 실패했을 때는 **Failure notifications**에 사용자나 그룹을 등록해두면 이메일로 알림을 받을 수 있어요. 온디맨드 실행에는 이 알림이 가지 않는다는 점은 기억해둘 만해요.
## 이벤트 트리거: 사건이 생기면 도는 방식
스케줄은 "몇 시에 파일이 도착해 있겠지"라는 가정 위에서 동작해요. 그런데 실제로는 파일이 정시에 딱 맞춰 오지 않는 경우가 많죠. 이럴 때 쓰는 게 **이벤트 트리거**예요. OneLake나 Azure Blob Storage에 파일이 생성·삭제되는 등의 이벤트가 발생하면 그 즉시 파이프라인을 실행해줘요.
Fabric의 이벤트 트리거는 내부적으로 **eventstream**과 **Data Activator2 알림(alert)** 기능을 함께 써요. 설정은 파이프라인 캔버스에서 시작할 수 있어요.
1. 파이프라인 홈 리본의 **Trigger** 버튼을 누르면 **Set alert** 패널이 열려요.
2. 감지할 이벤트 소스 유형을 고릅니다 — OneLake 파일 이벤트, Azure Blob 이벤트 등.
3. 실제 스토리지 계정과 구독을 연결하면, 이 과정에서 워크스페이스에 **eventstream** 객체가 자동으로 하나 생겨요.
4. 감지할 이벤트 종류(파일 생성, 삭제 등 다양한 옵션이 있어요)를 선택하고, 폴더명·파일명·확장자 같은 조건으로 필터를 걸어요.
5. 트리거가 저장될 워크스페이스와 실행할 파이프라인, 트리거 이름을 지정하고 **Create**를 누르면 완료돼요.
이렇게 만든 트리거는 워크스페이스 목록에 **Reflex3**라는 별도 항목으로 나타나고, 파이프라인 메뉴의 **Triggers > View triggers**에서 다시 확인·관리할 수 있어요.
## 이벤트에서 넘어온 파일명·경로 쓰기
이벤트 트리거로 실행되면 어떤 파일 때문에 실행됐는지도 알아야 다음 활동에서 그 파일을 처리할 수 있겠죠. Fabric은 이벤트의 `Subject` 필드에서 폴더명·파일명을 자동으로 파싱해서 파이프라인 표현식에서 바로 쓸 수 있게 해줘요.
```
@pipeline()?.TriggerEvent?.FileName
```
`pipeline()` 뒤에 붙는 `?`는 널(NULL) 값을 다루기 위한 문법이에요. 수동으로 **Run**을 눌러 테스트할 때는 파일명·폴더명 파라미터가 채워지지 않아 NULL이 나오기 때문에, 이 물음표가 없으면 테스트 실행에서 오류가 날 수 있어요. 실제로 이벤트가 파이프라인을 실행시키면 그때는 값이 정상적으로 채워져요.
## 스케줄 vs 이벤트, 언제 뭘 쓸까
- 데이터가 **정해진 시간에 안정적으로 도착**한다면 스케줄이 단순하고 관리하기 쉬워요. 실패 알림도 스케줄 실행에만 붙일 수 있고요.
- 데이터가 **언제 올지 예측하기 어렵거나, 도착 즉시 처리해야** 한다면 이벤트 트리거가 낫습니다. 파일이 없는데도 빈 실행을 도는 낭비를 줄이고, 반대로 늦게 온 파일을 다음 스케줄까지 놓치는 지연도 없앨 수 있어요.
두 방식은 서로 배타적이지 않아서, 같은 파이프라인에 스케줄과 이벤트 트리거를 동시에 걸어두는 것도 가능해요.
## 정리
스케줄은 "몇 시에 돈다"를 사람이 정하는 방식이고, 이벤트 트리거는 "무슨 일이 생기면 돈다"를 시스템이 감지하는 방식이에요. Fabric에서 이벤트 트리거는 eventstream과 Data Activator 알림 위에서 동작하며 Reflex 항목으로 관리되고, 실행된 뒤엔 `@pipeline()?.TriggerEvent?.FileName` 같은 표현식으로 어떤 파일 때문에 실행됐는지 파이프라인 안에서 바로 알 수 있어요.
---
## 어휘 주석
1. **인터벌 기반 스케줄(Interval-based schedule):** 겹치지 않는 고정 구간(윈도) 단위로 실행 시각을 나누는 스케줄 방식. 이 글 작성 시점 기준 미리보기(preview) 기능이에요.
2. **Data Activator:** Fabric에서 데이터 조건을 감시하다가 조건이 맞으면 알림을 보내거나 다른 작업을 실행시키는 서비스. 이벤트 트리거의 알림(alert) 로직을 이 서비스가 담당해요.
3. **Reflex:** Data Activator로 만든 트리거·알림 규칙이 워크스페이스에 저장되는 항목 유형의 이름이에요.