Apache Airflow (아파치 에어플로)
Python 코드로 작업 순서와 의존성을 적고 예약 실행·재시도·실행 이력까지 묶어 운영하는 배치 오케스트레이션 도구
Apache Airflow (아파치 에어플로)은(는) 자동화 서버, 클라우드에서 자동화 흐름을 설계하고 운영하는 데 도움이 되는 자동화 프레임워크입니다. 문서가 어느 정도 갖춰져 있고 유지 신호도 보여서 스타 45254개와 외부 언급 6개를 함께 보면 먼저 살펴볼 만합니다.
환경
좋은 용도
설치
`pip install`과 constraints 파일을 함께 쓰거나 공식 Docker 이미지로 설치합니다. 프로덕션에서는 Helm chart로 Kubernetes에 배포하는 경로도 많이 씁니다.
사용 예시
DAG 파일에 task와 의존성을 Python으로 적으면 scheduler와 dag processor가 실행 시점과 순서를 계산해요. 웹 UI에서 DAG run, task 상태, 로그, retry, backfill 같은 운영 정보를 한곳에서 봅니다.
연동 방식
외부 시스템 호출은 operator, hook, provider package로 나뉘어요. 그래서 [API](/ko/wiki/api/) 몇 개를 순서대로 부르는 스크립트가 아니라, local·Celery·Kubernetes executor 같은 [runtime](/ko/wiki/runtime/) 구성 위에서 장기적으로 관찰 가능한 운영 그래프로 바뀝니다.
연결
관련 뉴스
별칭
리뷰
Apache Airflow는 Python 코드로 작업 순서표를 쓰고, 예약 실행·재시도·실행 이력을 한곳에서 운영하는 배치 작업 관리 도구예요. 데이터 파이프라인, 정기 리포트, 모델 학습 전처리처럼 여러 단계가 서로 의존하는 작업이면 왜 필요한지 금방 드러납니다.
핵심 판단 기준은 Airflow를 cron 대체로 볼지, 의존성과 재시도까지 관리하는 배치 운영 도구로 볼지예요. 이 도구의 값은 예약 실행 자체보다 실패한 배치를 다시 보고, 의존성을 재실행하고, 팀이 같은 이력을 보는 데 있어요.
반대로 이 운영면이 필요 없으면 Airflow는 무거워집니다. metadata DB, scheduler, webserver, worker까지 관리해야 하니, 스크립트 하나를 매일 한 번 실행하는 정도라면 더 가벼운 scheduler가 낫습니다.
사용 예시
개발자는 DAG 파일에 task와 의존성을 적고, Airflow scheduler와 dag processor가 실행 시점과 순서를 계산해요. 실행은 local executor, Celery/Kubernetes executor 같은 runtime 구성에 따라 달라집니다.
웹 UI에서는 DAG run, task 상태, 로그, retry, backfill 같은 운영 정보를 봅니다. 이 화면이 없으면 장애가 난 배치가 언제부터 틀어졌는지 찾는 비용이 커져요. 외부 시스템 호출은 operator, hook, provider package로 나뉘어, API 몇 개를 순서대로 부르는 스크립트가 관찰 가능한 운영 그래프로 바뀝니다.
확인할 점
Airflow는 도입보다 운영이 더 큰 도구예요. metadata database, scheduler, webserver, worker, executor, provider version을 같이 관리해야 해서 작은 팀에는 유지비가 크게 느껴질 수 있습니다. 실시간 이벤트 처리나 작업 수가 2~3개뿐인 자동화라면 DAG 모델과 맞지 않을 수 있어요.
GitHub release에는 core Airflow release와 Helm chart release가 함께 올라와요. 2026-05-03 기준 최신 GitHub release는 helm-chart/1.21.0이고 core Airflow release는 3.2.1이라, 배포 대상에 맞춰 버전을 분리해서 봐야 합니다.