매일 데이터를 수집하고, 변환한 뒤 테이블을 갱신하는 파이프라인을 만든다고 하자. Airflow, Prefect, Dagster는 모두 이 작업을 실행하고 상태를 관리할 수 있다. 차이는 “실패에 강한 도구는 무엇인가”처럼 한 가지 수식어보다, 작업과 결과물을 어떤 모델로 표현하고 운영하는가에서 확인하는 편이 낫다.
이 글은 Airflow 3 계열, Prefect 3 계열, Dagster의 자산 중심 모델을 기준으로 선택 기준을 정리한다. 기능 문서를 바탕으로 한 비교이며, 같은 환경에서 처리량이나 운영 비용을 측정한 결과는 아니다. 세부 API와 배포 구성은 사용할 버전에서 다시 확인해야 한다.
1. 같은 파이프라인을 무엇으로 표현하나
외부 API에서 날짜별 주문 수집
→ 중복·누락 데이터 확인
→ 매출 집계 테이블 갱신Airflow에서는 이 흐름을 DAG와 task의 의존성으로 표현한다. Prefect에서는 Python flow 안에서 task를 호출하는 흐름으로 표현할 수 있다. Dagster에서는 원본 주문 데이터와 집계 테이블을 asset으로 정의하고, 자산 사이의 의존성과 materialization을 관리할 수 있다.
| 항목 | Airflow | Prefect | Dagster |
|---|---|---|---|
| 주로 보는 단위 | DAG 실행과 task | flow 실행과 task | asset, materialization, job/op |
| 의존성 표현 | task 관계, TaskFlow 데이터 전달 | 함수 호출과 작업 결과 전달 | 자산 의존성과 작업 그래프 |
| 확인하기 좋은 관점 | 어떤 작업이 언제 실행·실패했는가? | 어떤 Python 실행 흐름이 어떤 상태인가? | 어떤 데이터가 어떤 입력으로 언제 만들어졌는가? |
| 팀이 검토할 요소 | 기존 DAG·provider와 운영 경험 | 기존 Python 코드의 전환 및 실행 인프라 | 자산 모델·파티션·검사 규칙의 설계 |
세 도구 모두 스케줄링, 상태 관찰, 재실행과 실패 처리 기능을 제공한다. 한 제품만 재시도를 지원하거나 데이터 품질을 관리할 수 있는 것처럼 구분하면 실제 기능을 놓치게 된다.
2. Airflow를 정적 DAG로만 이해하지 않기
Airflow에는 TaskFlow API와 Dynamic Task Mapping이 있다. 실행 중 얻은 목록을 바탕으로 task를 확장할 수 있으므로 “Airflow는 정적 작업만 가능하다”는 비교는 부정확하다. Dynamic Task Mapping은 Airflow 2 계열에도 존재했다.
앞의 예시에서 수집할 날짜 목록을 만든 뒤, 날짜별 수집 작업을 매핑할 수 있다. 중요한 판단은 동적 실행의 가능 여부보다, DAG의 파싱·스케줄링 제약 안에서 원하는 흐름을 얼마나 명확하게 표현할 수 있는가다.
이미 Airflow DAG와 provider를 많이 사용하는 팀은 기존 연동과 운영 절차를 활용할 수 있다. 반면 로컬 실행이 된다는 것과 스케줄러·메타데이터 저장소·executor를 포함한 운영 환경을 준비했다는 것은 구분해야 한다. Airflow 3로 이전할 때는 2 계열의 예제를 그대로 옮기지 말고 공개 API와 배포 구성의 변경을 확인한다.
3. Prefect 3에서는 worker와 실행 방식을 확인하기
Prefect는 Python 함수에 flow·task 단위를 부여해 기존 코드를 단계적으로 작업 흐름으로 관리할 수 있다. 조건문이나 반복문을 사용하는 코드와 함께 읽기 쉽다는 점을 검토할 수 있다.
다만 “Agent가 모든 작업을 가져온다”는 설명을 Prefect 3의 실행 모델로 고정하면 안 된다. Work pool과 worker를 이용해 실행 인프라를 연결할 수 있고, serve와 같은 배포 방식도 있다. 선택한 방식에 따라 실행 프로세스를 어디서 유지하고 누가 시작하는지가 달라진다.
API 수집을 세 번 재시도하도록 설정해도 동일 데이터가 세 번 저장되지 않게 만드는 것은 작업 코드의 책임이다. 자동 재시도 기능은 데이터 쓰기의 멱등성을 대신하지 않는다.
4. Dagster의 자산 모델이 유용한 상황
작업이 성공했는지보다 “이 매출 테이블이 어떤 원본으로 만들어졌고 최신 상태인가”가 중요하면 자산 중심 모델을 검토할 수 있다. Dagster는 자산의 의존 관계, 실행 결과의 메타데이터, 파티션 등을 표현할 수 있다.
Asset check로 누락 비율이나 스키마 조건 등을 검사할 수도 있다. 하지만 검사를 정의했다고 데이터 품질이 자동으로 보장되는 것은 아니다. 무엇을 검사할지, 실패하면 후속 처리를 막을지, 누가 복구할지 정해야 한다.
예를 들어 “주문 ID 중복이 없어야 한다”는 검사와 “원본 도착이 늦어 집계가 오래됐다”는 문제는 다른 조건이다. 품질과 최신성을 각각 표현하고, 자산을 다시 만들 때 외부 시스템에 어떤 영향이 생기는지도 확인한다.
5. 도구를 고르기 전에 작은 운영 시나리오를 실행한다
앞의 주문 집계 파이프라인을 사용해 다음을 비교한다.
- 정상 실행: 개발자가 코드를 작성하고 배포하기까지 필요한 단계는 무엇인가?
- 부분 실패: 수집은 성공하고 집계가 실패했을 때 필요한 범위만 다시 실행할 수 있는가?
- 과거 데이터 재처리: 특정 날짜 구간을 다시 계산할 때 중복과 외부 API 호출량을 통제할 수 있는가?
- 입력 지연: 데이터가 늦게 도착했을 때 오래된 결과를 감지하고 복구할 수 있는가?
- 운영 장애: 실행 프로세스나 제어 서비스가 재시작되면 상태가 어떻게 복원되는가?
실행 시간뿐 아니라 배포 변경 시간, 문제 원인 파악 시간, 재처리 절차를 기록한다. 작은 로컬 예제의 편리함과 여러 사람이 운영하는 환경의 편리함은 다를 수 있다.
6. 팀의 현재 자산에서 출발하기
- 기존 DAG와 외부 연동이 많다면 Airflow에서 필요한 변화가 가능한지 먼저 확인한다.
- Python 중심 코드를 자주 바꾸고 실행 흐름을 유연하게 관리하려면 Prefect의 모델과 배포 방식을 검토한다.
- 테이블·파일·모델의 계보와 최신성을 중심으로 데이터 플랫폼을 관리하려면 Dagster의 자산 모델을 검토한다.
이 기준은 배타적인 정답이 아니다. 새 기능의 이점이 마이그레이션, 운영 인프라, 팀 학습 비용보다 큰지 확인해야 한다. 오픈소스 자체 운영과 관리형 서비스도 구분해서 접근 권한, 백업, 알림, 비용을 비교한다.
