Airflow의 탄생

2014년, Airbnb.

데이터 팀이 수백 개의 ETL 파이프라인을 크론탭으로 관리하고 있었다. 매일 새벽마다 누군가 실패한 작업을 찾아 재실행했다.

"이거 미친 짓이야"

그래서 만든 게 Airflow다.

타임라인

• 2014: Airbnb에서 개발 시작
• 2016: Apache 인큐베이터
• 2019: Apache 정식 프로젝트
• 현재: 데이터 엔지니어링의 사실상 표준

---

크론 vs Airflow

크론탭으로 ETL:

Airflow로 ETL:

차이가 보이는가?

크론은 "시간"으로 실행한다. Airflow는 "의존성"으로 실행한다.

---

핵심 개념: DAG

DAG = Directed Acyclic Graph

• Directed: 방향이 있음 (A → B)
• Acyclic: 순환이 없음 (A → B → A 불가)
• Graph: 노드와 엣지의 구조

DAG는 "무엇을 어떤 순서로 실행할지"를 정의한다.

---

Airflow 아키텍처

각 컴포넌트의 역할

컴포넌트	역할
Web Server	DAG 상태 확인, 수동 실행, 로그 조회
Scheduler	DAG 파일 파싱, 실행 시점 결정, Task 큐 관리
Worker	실제 Task 실행
Metadata DB	DAG 실행 이력, Task 상태 저장

---

Executor 종류

Worker를 어떻게 운영할지 결정하는 게 Executor다.

Executor	특징	사용 환경
SequentialExecutor	순차 실행, 디버깅용	개발
LocalExecutor	로컬 병렬 실행	소규모
CeleryExecutor	Redis/RabbitMQ 기반 분산	중/대규모
KubernetesExecutor	K8s Pod으로 실행	클라우드

실무에서는?

• 소규모: LocalExecutor
• 대규모: CeleryExecutor 또는 KubernetesExecutor