Airflow

Airbnb의 사내 도구에서 ASF 톱레벨 프로젝트로

Apache Airflow는 2014년 10월 Airbnb에서 Maxime Beauchemin이 만들었다. 당시 Airbnb는 늘어나는 데이터 작업을 스크립트와 cron만으로 관리하기 어려운 상황이었고, 작업 간 의존성을 표현하고 실패를 자동으로 처리하며 전체 파이프라인을 한눈에 볼 수 있는 도구가 필요했다. 이 필요가 '태스크 간의 방향성 있는 의존성 그래프(DAG)'라는 핵심 개념으로 이어졌다.

2015년 Airbnb는 이 도구를 오픈소스로 공개했고, 2016년 Apache Software Foundation(ASF)의 인큐베이터 프로그램에 합류했다. 이후 커뮤니티 기여가 늘어나며 2019년 ASF의 톱레벨 프로젝트(Top-Level Project)로 승격되었다. 이 과정 자체가 Airflow의 특징 하나를 설명한다 — 특정 벤더가 아니라 커뮤니티가 주도하는 오픈소스 표준으로 자리잡았기 때문에, 클라우드/온프레미스를 가리지 않고 다양한 시스템과 연동하는 프로바이더(Provider) 생태계가 폭넓게 성장할 수 있었다.

1.x의 한계와 2.x의 해결, 그리고 3.x로의 전환

Airflow 1.x는 스케줄러가 단일 인스턴스로만 동작했고(Scheduler가 단일 장애점), XCom이 취약했으며, 로컬 개발 경험도 열악했다. Airflow 2.0(2020년)은 이 문제들을 정면으로 겨냥해, 여러 스케줄러를 동시에 띄우는 고가용성(HA) 스케줄러, TaskFlow API(`@task` 데코레이터로 XCom을 자동 처리), DAG Serialization(웹서버가 DAG 파일을 직접 파싱하지 않고 스케줄러가 저장한 JSON을 읽게 함) 등을 도입했다.

Airflow 3.0(2025-2026)은 여기서 한 걸음 더 나아가 아키텍처 자체를 재구성했다. 가장 큰 변화는 태스크 실행을 스케줄러의 DB 직접 접근에서 분리한 Task SDK/Execution API 기반 구조로, 이를 통해 태스크 코드가 더 이상 메타데이터 DB에 직접 접근하지 않고 API를 통해서만 통신한다(제어 평면과 워커 평면의 신뢰 경계 분리). 또한 Dataset이라는 이름이 Asset으로 바뀌며 자산 기반 스케줄링이 정식 개념으로 자리잡았고, Python 외 언어(Go/Java/TypeScript) SDK가 추가되었으며, SLA·SubDAG·SequentialExecutor 같은 레거시 기능은 완전히 제거되었다(구체적인 대체재는 이 카테고리의 다른 모듈에서 자세히 다룬다).

— 정정: 블로그("What Is Airflow")의 예제 코드는 `schedule_interval='@daily'`를 사용하는데, 이는 Airflow 2.2부터 `schedule`로 대체 권장되었고 Airflow 3.x에서는 DAG 생성자 파라미터로 완전히 제거되었다. Airflow 3.x 기준 예제는 `schedule='@daily'`로 작성해야 한다.