←전체 그래프상위: Data Engineering
요약
Airflow, Dagster, Prefect는 Python 데이터 오케스트레이터의 3대 선택지이다. Airflow는 성숙한 생태계와 스케줄 기반 배치에 강하고, Dagster는 Asset 중심 선언적 모델과 테스트 경험이 뛰어나며, Prefect는 Python-native 접근과 동적 워크플로우에서 빛난다.
핵심 비교
철학의 차이
| Airflow | Dagster | Prefect |
|---|
| 핵심 질문 | "이 작업을 언제 실행?" | "이 자산이 최신인가?" | "이 Python 함수를 어떻게 오케스트레이션?" |
| 단위 | Task/Operator | Asset (SDA) | Flow/Task (함수) |
| 패러다임 | Imperative (명령형) | Declarative (선언형) | Pythonic (Python-native) |
| 비유 | Cron의 진화 | dbt for everything | Python에 날개 |
아키텍처
| Airflow | Dagster | Prefect |
|---|
| 구성 요소 | Webserver + Scheduler + Worker + DB | Webserver + Daemon + Code Location + DB | Server(or Cloud) + Worker + DB |
| 스케줄링 | Cron 기반 | Freshness Policy (선언적) | Cron + 이벤트 드리븐 |
| 실행 모델 | Executor (Local, Celery, K8s) | Run Launcher (로컬, Docker, K8s) | Work Pool (Process, Docker, K8s, Serverless) |
| 코드 격리 | DAG 파일을 스케줄러가 파싱 | Code Location (독립 프로세스) | Worker가 사용자 인프라에서 실행 |
개발자 경험 (DX)
| Airflow | Dagster | Prefect |
|---|
| 로컬 실행 | DB 초기화 + Webserver + Scheduler 필요 | dagster dev 한 줄 | python flow.py (서버 없이 가능) |
| 단위 테스트 | 어렵다 (인프라 의존) | 네이티브 지원 (Mock Resource) | 쉽다 (일반 함수 테스트) |
| CI/CD | DAG 파일 배포 | Branch Deployment (PR별 환경) | Deployment CLI |
| 학습 곡선 | 중간 (개념 多) | 높음 (SDA 패러다임 전환) | 낮음 (Python 그대로) |
| UI | 가장 성숙 | Asset 리니지 뷰 우수 | 깔끔하고 현대적 |
동적 워크플로우
| Airflow | Dagster | Prefect |
|---|
| 동적 태스크 | Dynamic Task Mapping (2.3+) | Dynamic Partitions | 네이티브 Python (for/if) |
| 조건 분기 | BranchOperator | op_config + conditional | if/else (그냥 Python) |
| 유연성 | 제한적 (DAG 구조 고정) | 중간 (Asset 그래프 기반) | 높음 (Python 그대로) |
에러 핸들링
| Airflow | Dagster | Prefect |
|---|
| 재시도 | retries 파라미터 | RetryPolicy | retries 데코레이터 인자 |
| 실패 콜백 | on_failure_callback | @failure_hook | State Handler |
| 부분 재실행 | Clear & Restart | Asset 단위 재실행 | Flow/Task 단위 재실행 |
| 트랜잭션 | 없음 | 없음 | 지원 (3.0, 롤백 가능) |
데이터 인식 (Data-Awareness)
| Airflow | Dagster | Prefect |
|---|
| 데이터 리니지 | 없음 (태스크 의존성만) | 핵심 기능 (Asset Graph) | 없음 |
| 데이터 품질 | 외부 도구 필요 | Asset Check (내장) | 외부 도구 필요 |
| 메타데이터 | XCom (제한적) | Asset Metadata (풍부) | Artifact |
| Freshness | 없음 | Freshness Policy | 없음 |
배포 & 운영
| Airflow | Dagster | Prefect |
|---|
| 매니지드 | Astronomer, MWAA, Cloud Composer | Dagster Cloud | Prefect Cloud |
| 커뮤니티 | 가장 큼 (80,000+ 조직) | 빠르게 성장 중 | 중간 |
| Provider/통합 | 2,000+ Providers (가장 풍부) | 점점 늘어나는 중 | 200+ 통합 |
| 마이그레이션 | - | Airflow → Dagster 도구 있음 | Airflow → Prefect 가이드 있음 |
언제 무엇을 선택?
Airflow를 선택하라
- 이미 Airflow DAG가 많다
- 스케줄 기반 배치 ETL/ELT 중심
- 다양한 외부 시스템 통합이 필요 (Provider 생태계)
- 대규모 조직, 안정적 운영이 우선
- Airflow 3.0 (2025)으로 많은 단점 보완
Dagster를 선택하라
- 데이터 자산의 리니지와 품질이 중요
- 테스트 주도 개발(TDD)을 데이터 파이프라인에 적용하고 싶다
- dbt를 이미 쓰고 있고, 비슷한 선언적 접근을 원한다
- PR별 프리뷰 환경(Branch Deployment)이 필요하다
- 그린필드 프로젝트 (기존 레거시 없음)
Prefect를 선택하라
- Python 코드를 최소한으로 변경하고 싶다
- 동적이고 복잡한 워크플로우가 많다
- 이벤트 드리븐 파이프라인이 필요하다
- 빠르게 시작하고 싶다 (학습 곡선 최소)
- 트랜잭션 시맨틱스가 필요하다
Airflow 3.0 (2025)의 변화
Airflow 3.0은 기존 약점을 상당 부분 보완했다:
- TaskFlow API 강화:
@task 데코레이터로 Prefect와 유사한 경험
- Asset-Aware Scheduling: Dagster의 영향을 받은 데이터 인식 스케줄링
- Multi-Executor: 동일 DAG 내에서 다른 Executor 사용 가능
- Edge Labels: 조건부 분기 개선
- Remote Execution: DAG 파싱과 실행 분리
하지만 여전히 로컬 개발 경험과 테스트 용이성에서는 Dagster/Prefect에 뒤처진다.
관련 개념