interlinear

실무자와 개발자 사이비즈니스 앱과 에이전트 사이자연어와 기계어 사이

파이프라인을 언제 돌릴까: 스케줄과 이벤트 트리거

시간마다 도는 스케줄 실행과, 파일이 도착하면 바로 도는 이벤트 트리거를 Fabric 파이프라인에서 어떻게 설정하는지, 언제 뭘 골라야 하는지 정리했어요.

원문: Run, schedule, or use events to trigger a pipeline 게시일: 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로 만든 트리거·알림 규칙이 워크스페이스에 저장되는 항목 유형의 이름이에요.