솔직한 비교
셋 중 어느 것도 만능은 아니야. 트위터 담론 말고 팀의 모양과 제약을 보고 골라. 실제로 쓰는 표를 줄게.
| Airflow | Dagster | Prefect | |
|---|---|---|---|
| Mental model | Task → DAG (3.0 부터 asset 도) | Asset → 그래프가 떠오름 | 함수 → flow |
| 배포 비용 | 높음 (DB + scheduler + DAG processor + API server + worker) | 낮음 (시작 시 single process) | 가장 낮음 (flow 는 그냥 돌리는 Python 파일) |
| Operator ecosystem | 가장 큼 (provider 패키지 80개 이상) | 중간 | 중간 |
| Best for… | 이미 ops 가 있고 통합이 많이 필요한 팀 | 데이터 asset 으로 생각하고 lineage 가 전면이길 원하는 팀 | Orchestration 이 Python 라이브러리처럼 느껴지길 원하는 팀 |
| Async / 동시성 | OK | 좋음 | 최고 (native async) |
| UI 성숙도 | 성숙, 빽빽 | Modern, lineage-first | Modern, flow-first |
| 학습 곡선 | 가파름 | 중간 | 완만 |
실제로 추천하는 default
- 작은/새 팀, 처음부터: Dagster. Asset 모델이 데이터 팀의 사고에 그대로 얹히고,
dagster dev명령 하나면 lineage 를 아는 UI 가 떠. 세우기만 놓고 보면 Prefect 가 진짜 더 가벼워 — flow 는 서버도 없이 그냥 돌리는 Python 파일이니까. 대신 거기서 얻는 건 lineage 뷰가 아니라 flow 뷰야. 그게 거래고, 데이터 팀한테는 프로세스 하나 더 띄우고 lineage 가져오는 쪽이 대개 남는 장사야. - 큰 팀, 기존 인프라, 많은 vendor 통합: Airflow. Ecosystem 이점이 진짜.
- Orchestration 이 platform 아니라 라이브러리처럼 느껴지길 원하는 엔지니어 팀: Prefect. Hybrid 실행 모델이 규제/security 민감 shop 에 진짜 이점.
첫 줄에 붙는 단서 하나
Mental model 줄은 이 표에서 제일 깔끔한 줄이었어. Airflow 는 task, Dagster 는 asset, 팀에 맞는 명사를 고르면 끝. Airflow 3 이 그 선을 흐려 놨어. Dataset 이 Asset 이 됐고, 스케줄링이 event-driven 이 됐고, 이제 DAG 은 시계가 아니라 데이터가 바뀌어서도 깨어나. 구분이 사라진 건 아냐 — Dagster 는 여전히 asset 에서 출발해서 그래프를 끌어내고, Airflow 는 task 그래프가 여전히 주인공인 채로 그 위에 asset 을 얹어. 다만 이제는 종류의 차이가 아니라 강조점의 차이야. 셋을 마지막으로 비교해 본 게 2025년 이전이라면, 다시 읽을 줄이 이 줄이야.
그리고 중요한 비-답: 선택에 고통받지 마. 셋 다 충분히 좋아서 어느 거든 가치 대부분 얻어. 파이프라인을 DAG/asset/flow 로 작성하는 규율 이 일을 더 좋게 만드는 거 — 특정 도구는 작은 결정.