Orchestrator 가 (결국) 필요한 이유

Cron + bash phase 는 OK — 안 OK 일 때까지

모든 데이터 팀이 같은 식으로 시작해: Python 스크립트, cron 엔트리, 실패 시 Slack 알림. 그 stack 이 한두 파이프라인엔 작동. 열 개 되는 순간 깨져 — cron 이 필요한 거 하나도 없으니까: dependency 순서, retry, backfill, observability, 구조화된 실패 처리, 스케줄 가시성, run 이력. 다 본인이 빌드하거나 이미 가진 orchestrator 채택.

모든 modern orchestrator 가 주는 것

DAG / 의존성 그래프 — "task B 가 task A 성공 후 돌아."
스케줄링 — cron 스타일 또는 interval 기반, timezone-aware.
Retry — 자동, 설정 가능, idempotent.
Backfill — "지난주 다시 돌려, 순서대로."
Run 이력 — 모든 실행을 status, duration, log 와 함께 기록.
UI — 뭐 돌고 있는지 보고, 실패 drill, 수동 rerun 시작.
알림 — 실패, SLA miss 등에 Slack/PagerDuty 통합.

2026 의 세 후보

Apache Airflow — 가장 많이 배포, 가장 큰 ecosystem, 셋 중 가장 오래됨. Mature, opinionated, 진짜 배포 필요 (DB, scheduler, webserver, worker). 많은 시스템 말하는 operator 많을 때 best.

Dagster — Asset-first 모델. 데이터 asset 선언하고 Dagster 가 의존성 그래프 알아냄. 팀이 "customers ETL task" 보다 "customers 테이블" 으로 생각할 때 best.

Prefect — 가장 Pythonic. Flow 가 decorate 된 함수. 가장 가벼운 배포 (Cloud 옵션 또는 self-host). Orchestration 이 platform 아니라 라이브러리처럼 느껴지길 원할 때 best.

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

본인 환경의 스케줄 작업 inventory (crontab, launchd, GitHub Actions cron, 뭐든). 각각에 대해 적어: (1) 뭐에 의존, (2) 뭐가 의존, (3) fail 하면 뭐 일어남. 대부분 팀이 이미 여러 cron 엔트리에 깨지기 쉬운 DAG 가졌단 거 발견 — 그게 orchestrator 채택의 진짜 case.