Orchestrator 가 (결국) 필요한 이유

Cron + bash 시절은 괜찮아 — 안 괜찮아지는 날까지

모든 데이터 팀이 같은 모습으로 시작해: Python 스크립트, cron 엔트리, 실패하면 Slack 알림. 파이프라인이 한두 개일 땐 그걸로 굴러가. 열 개가 되는 순간 무너져 — 필요한 게 cron 엔 하나도 없거든: dependency 순서, retry, backfill, observability, 구조화된 실패 처리, 스케줄 가시성, run 이력. 전부 직접 만들거나, 이미 다 갖춘 orchestrator 를 들이거나.

Modern orchestrator 라면 다 주는 것

DAG / 의존성 그래프 — "task B 는 task A 가 성공한 다음에 돌아."
스케줄링 — cron 스타일 또는 interval 기반, timezone 인지.
Retry — 자동, 설정 가능, idempotent 전제.
Backfill — "지난주 다시 돌려, 순서대로."
Run 이력 — 모든 실행이 status, duration, log 와 함께 남아.
UI — 지금 뭐가 도는지 보고, 실패를 파고들고, 수동 rerun 을 걸고.
알림 — 실패나 SLA miss 에 Slack/PagerDuty 연동.

2026 의 세 후보

Apache Airflow — 배포 수 1위, ecosystem 최대, 셋 중 최고참. 성숙하고, 고집이 있고, 진짜 배포가 필요해 (DB, scheduler, DAG processor, API server, 그리고 보통 worker 까지). 여러 시스템과 이야기해야 해서 operator 가 많이 필요한 팀에 제일 맞아.

Dagster — Asset-first 모델. 데이터 asset 을 선언하면 Dagster 가 의존성 그래프를 알아서 떠올려. "customers ETL task" 보다 "customers 테이블" 로 생각하는 팀에 제일 맞아.

Prefect — 셋 중 가장 Python 다워. Flow 가 그냥 decorate 된 함수야. 설치가 제일 가볍고 (Cloud 옵션 또는 self-host). Orchestration 이 platform 이 아니라 라이브러리처럼 느껴지길 원할 때 제일 맞아.

Code

"Cron + bash" 가 어떻게 생겼는지 — 그리고 왜 scale 안 되는지·bash

# crontab -e
# 0 3 * * * /usr/bin/env python /opt/pipelines/orders.py >>/var/log/orders.log 2>&1
# 0 4 * * * /usr/bin/env python /opt/pipelines/customers.py >>/var/log/customers.log 2>&1
# 0 5 * * * /usr/bin/env python /opt/pipelines/revenue_dashboard.py >>/var/log/revenue.log 2>&1

# 10+ 파이프라인 가지면 문제:
#  - revenue_dashboard 가 orders+customers 성공 여부 무관하게 새벽 5시 돌음
#  - transient API 실패 retry 없음
#  - backfill 메커니즘 없음 — 화요일 run 실패면 fix 가 수동
#  - "지금 뭐 돌아?" 볼 중심 장소 없음
#  - 알림은 shell loop 으로 로그 파일 parse 하는 거

Exercise

본인 환경의 스케줄 작업들을 다 적어 봐 (crontab, launchd, GitHub Actions cron, 뭐든). 하나마다 세 줄: (1) 뭐에 의존하나, (2) 뭐가 이것에 의존하나, (3) 실패하면 무슨 일이 나나. 대부분의 팀이 이미 깨지기 쉬운 DAG 를 cron 엔트리 여러 개에 흩어 놓고 살아 — 그 발견이 orchestrator 를 들일 진짜 근거야.