오케스트레이터 선택 기준과 흔한 실수
Airflow vs Dagster vs Prefect 2026: Which Orchestrator to Pick — 블로그 (2026) "When to Choose What" ~ "Common Mistakes" 절 (pp.10-13)
이 모듈을 다 읽으면
- 팀 상황(기존 스킬셋, 규모, 생태계 요구)에 따라 세 오케스트레이터 중 무엇을 고를지 판단 근거를 설명할 수 있다
- 오케스트레이터 선택 시 흔히 저지르는 실수 네 가지를 식별하고 각각을 피하는 방법을 말할 수 있다
오케스트레이터 선택은 기능 비교표로 결정할 문제가 아니라, 팀의 기존 스킬셋·규모·생태계 요구사항이라는 맥락에 달려 있다. 이 모듈은 언제 어떤 도구를 고르는 것이 합리적인지, 그리고 실무에서 반복적으로 관찰되는 잘못된 의사결정 패턴을 정리한다.
선택 기준 요약
Airflow를 고르는 것이 합리적인 경우: 팀이 이미 Airflow 경험이 있다(다른 도구로 옮기는 마이그레이션 비용은 거의 항상 그 대가를 못 뽑는다), 다양한 데이터 소스/목적지에 대한 폭넓은 생태계 지원이 필요하다, AWS MWAA나 GCP Cloud Composer 같은 클라우드 매니지드 서비스를 쓰고 싶다, 채용 시장에서 후보자 대부분이 이미 아는 도구를 원한다, 이미 프로덕션에서 100개 이상의 DAG을 검증된 패턴으로 운영해야 한다.
Dagster를 고르는 것이 합리적인 경우: 기존 오케스트레이터 없이 그린필드로 시작한다, 팀이 dbt를 많이 쓰고 모던 데이터 스택 도구들과 통합한다, 자산 중심의 계보 추적과 내장 데이터 품질 체크를 원한다, 로컬 개발 경험을 최우선으로 친다, 새 도구를 배울 시간적 여유가 있다.
Prefect를 고르는 것이 합리적인 경우: 오케스트레이션 요구사항이 단순하다(플로우 100개 미만, 단순한 의존관계), 보일러플레이트 없이 '그냥 파이썬을 쓰는' 경험을 원한다, 팀이 작고(2-5명) 오케스트레이션 인프라 자체를 관리하고 싶지 않다, 오케스트레이션은 매니지드로 두고 실행은 자체 환경에 두는 하이브리드 모델을 원한다.
핵심 포인트
- Airflow: 팀의 기존 Airflow 경험, 넓은 생태계 요구, 클라우드 매니지드 서비스(MWAA/Composer) 활용, 채용 용이성, 100개 이상 DAG의 검증된 스케일링 패턴이 필요할 때 적합하다
- Dagster: 그린필드 프로젝트, dbt 중심 모던 데이터 스택, 자산 중심 계보·데이터 품질 체크, 로컬 개발 경험 우선일 때 적합하다
- Prefect: 100개 미만의 단순한 플로우, 최소 보일러플레이트, 소규모 팀, 오케스트레이션 인프라를 직접 관리하고 싶지 않을 때 적합하다
흔히 저지르는 네 가지 실수
첫째, '더 새롭다는 이유만으로 Dagster를 고르는 것'. 새 도구로의 마이그레이션에 몇 달을 쓰고도 기존과 비슷한 안정성 수준에 도달하는 데 그치는 경우가 많다 — Airflow가 이미 잘 동작하고 있다면 그대로 쓰는 편이 낫다.
둘째, '옛 버전(1.x)에서의 나쁜 경험을 근거로 오케스트레이터 자체를 평가하는 것'. Airflow 1.x의 단일 스케줄러·취약한 XCom·열악한 로컬 개발 경험은 2.0에서 크게 개선되었고, 3.x에서 아키텍처가 한 번 더 재구성되었다. 옛 버전의 인상으로 현재 버전을 평가하면 잘못된 결론에 이른다.
셋째, '생태계 검증 없이 팀 규모에 안 맞는 Prefect를 고르는 것'. 처음 몇 주는 `@flow`/`@task`가 마법처럼 느껴지지만, 레거시 Oracle DB나 특정 SaaS API 커넥터가 없다는 걸 3개월 차에 알게 되는 식이다. 실제 연동 요구사항을 미리 조사해야 한다.
넷째, '장난감 예제로 평가하는 것'. 태스크 3개짜리 데모에서는 어떤 도구든 좋아 보인다. 조건부 분기, 동적 태스크 생성, 크로스 파이프라인 의존성, 복잡한 재시도 로직, SLA/기한 모니터링이 얽히는 실제 사용 사례로 프로토타입을 만들어야 진짜 차이가 드러난다.
핵심 포인트
- '더 새로우니까'라는 이유로 오케스트레이터를 바꾸는 것은 흔한 실수이며, 마이그레이션 비용 대비 안정성 이득이 크지 않은 경우가 많다
- Airflow 1.x 시절의 경험(단일 스케줄러, 취약한 XCom)으로 현재의 Airflow(2.x/3.x)를 평가하면 잘못된 결론에 이른다
- Prefect처럼 생태계가 작은 도구를 팀 규모/연동 요구사항 검증 없이 선택하면 몇 달 뒤 커넥터 공백에 부딪힌다
- 장난감 예제가 아니라 조건부 분기·동적 태스크·복잡한 재시도가 섞인 실제 사용 사례로 오케스트레이터를 검증해야 한다