한 줄 정의
Apache Airflow는 Python 코드로 작업 순서표를 쓰고, 예약 실행·재시도·실행 이력을 한곳에서 운영하는 배치 작업 관리 도구야. 2026-04-22에 Airflow 3.2.1, 2026-04-24에 Helm chart 1.21.0이 따로 올라왔다는 점처럼, 본체와 배포 차트를 나눠 봐야 해.
데이터 파이프라인, 정기 리포트, 모델 학습 전처리처럼 여러 단계가 서로 의존하는 작업이면 Airflow가 왜 필요한지 금방 드러나. 반대로 스크립트 하나를 매일 한 번 실행하는 정도라면 과한 선택일 수 있어.
실제로 무엇을 하나
- 개발자는 DAG 파일에 task와 의존성을 적고, Airflow scheduler와 dag processor가 실행 시점과 순서를 계산해. 실행은 local executor, Celery/Kubernetes executor 같은 runtime 구성에 따라 달라져.
- 웹 UI에서는 DAG run, task 상태, 로그, retry, backfill 같은 운영 정보를 봐. 이 화면이 없으면 장애가 난 배치가 언제부터 틀어졌는지 찾는 비용이 커져.
- 외부 시스템 호출은 operator, hook, provider package로 나뉘어. 그래서 API 몇 개를 순서대로 부르는 스크립트가 아니라, 장기적으로 관찰 가능한 운영 그래프로 바뀌어.
왜 중요한가
Airflow를 cron 대체로만 보면 도입 기준이 흐려져. 이 도구의 값은 예약 실행 자체보다 실패한 배치를 다시 보고, 의존성을 재실행하고, 팀이 같은 이력을 보는 데 있어.
반대로 이 운영면이 필요 없으면 Airflow는 무거워져. metadata DB, scheduler, webserver, worker까지 관리해야 하니까 작은 자동화에는 맞지 않을 수 있어.
언제 쓰고 언제 넘기나
- USE: task 간 선후관계, retry, backfill, SLA, 실행 이력 확인이 업무의 일부라면 Airflow가 cron보다 낫다.
- USE: 데이터팀·ML팀·분석팀이 같은 배치 상태를 보며 운영해야 한다면 UI와 DAG history가 의사소통 비용을 줄여.
- SKIP: 이벤트가 들어올 때 즉시 반응해야 하는 서비스 workflow나, 작업 수가 2~3개뿐인 작은 자동화라면 더 가벼운 scheduler가 낫다.
주의해서 볼 점
Airflow는 도입보다 운영이 더 큰 도구야. metadata database, scheduler, webserver, worker, executor, provider version을 같이 관리해야 해서 작은 팀에는 유지비가 크게 느껴질 수 있어.
GitHub release에는 core Airflow release와 Helm chart release가 함께 올라와. 2026-05-03 기준 최신 GitHub release는 helm-chart/1.21.0이고, core Airflow release는 3.2.1이라서 배포 대상에 맞춰 버전을 분리해서 봐야 해.