핵심 인사이트 (3줄 요약)
- 본질: Apache Airflow (에어플로우)는 DAG (Directed Acyclic Graph, 방향성 비순환 그래프)로 데이터 파이프라인을 코드로 정의하고 스케줄·의존성 관리·모니터링을 제공하는 오픈소스 워크플로우 오케스트레이터다.
- 가치: 파이프라인을 코드 (Python DAG)로 관리하면 버전 관리 (Git), 테스트, 재사용이 가능해지며, 태스크 간 의존성과 실패 재시도 (Retry)를 선언적으로 정의하여 복잡한 데이터 파이프라인을 신뢰성 있게 운영할 수 있다.
- 판단 포인트: Airflow는 배치 오케스트레이션에 강점이 있지만 실시간 스트리밍 처리에는 적합하지 않으며, 수백 개 이상의 DAG를 운영할 때는 스케줄러 성능과 메타DB 부하를 고려한 아키텍처 설계가 필요하다.
Ⅰ. 개요 및 필요성
데이터 파이프라인은 일반적으로 데이터 수집 → 변환 → 검증 → 적재 → 리포팅의 여러 단계로 구성된다. 각 단계는 이전 단계 완료 후 실행되어야 하는 의존성이 있고, 실패 시 재시도·알림이 필요하다. 이를 cron 스크립트로 관리하면 의존성 처리, 실패 감지, 재실행이 수작업이 된다.
Airflow는 Airbnb가 2014년 개발하고 2016년 Apache 인큐베이터에 기증했다. 파이프라인을 Python DAG로 정의하면 의존성·스케줄·재시도를 선언적으로 관리하고, 웹 UI로 실행 상태를 실시간 모니터링할 수 있다.
- 📢 섹션 요약 비유: Airflow는 공장 조립 라인 관제탑이다. 부품 A가 완성되면 부품 B 조립을 시작하고, 문제가 생기면 자동으로 재작업하며, 전체 라인 상태를 대시보드로 보여준다.
Ⅱ. 아키텍처 및 핵심 원리
┌──────────────────────────────────────────────────────────────────┐
│ Airflow 아키텍처와 DAG 구성 │
├──────────────────────────────────────────────────────────────────┤
│ Airflow 컴포넌트: │
│ 웹 서버 (Web Server) → UI · REST API 제공 │
│ 스케줄러 (Scheduler) → DAG 파싱 · 태스크 스케줄링 │
│ 실행자 (Executor) → 태스크 실행 방식 결정 │
│ SequentialExecutor: 순차 실행 (개발용) │
│ CeleryExecutor: 분산 실행 (Worker 노드 추가 가능) │
│ KubernetesExecutor: K8s Pod로 격리 실행 │
│ 워커 (Worker) → 실제 태스크 실행 프로세스 │
│ 메타 DB (Metadata DB) → DAG·실행 기록·상태 저장 (PostgreSQL 권장) │
│ │
│ DAG 예시 (Python): │
│ extract → transform → validate → load │
│ (t1) → (t2) → (t3) → (t4) │
│ │
│ t1 >> t2 >> t3 >> t4 ← 의존성 선언 (Python 코드) │
└──────────────────────────────────────────────────────────────────┘
| 개념 | 설명 | 역할 |
|---|---|---|
| DAG | 태스크 의존성 그래프 | 파이프라인 전체 정의 |
| Operator | 태스크 실행 단위 (PythonOperator 등) | 각 단계 작업 실행 |
| Task Instance | 특정 날짜의 태스크 실행 인스턴스 | 실행 상태·로그 추적 |
| DAG Run | 특정 날짜의 전체 DAG 실행 인스턴스 | 파이프라인 실행 단위 |
| XCom | 태스크 간 소규모 데이터 전달 메커니즘 | 태스크 결과 공유 |
- 📢 섹션 요약 비유: DAG는 요리 레시피다. 재료 손질(t1) → 볶기(t2) → 간 맞추기(t3) 순서가 정해져 있고, 이전 단계가 완료되어야 다음 단계가 시작된다.
Ⅲ. 비교 및 연결
Airflow vs 대안 오케스트레이터 비교:
| 도구 | 특성 | 강점 | 약점 |
|---|---|---|---|
| Airflow | Python DAG, 풍부한 생태계 | 유연성, 커뮤니티 생태계 | 스케줄러 복잡도, 학습 곡선 |
| Prefect | 파이썬 함수 기반, 현대적 UI | 코드 친화적, 동적 DAG | 상대적으로 작은 생태계 |
| Dagster | 데이터 자산 중심, 타입 시스템 | 데이터 품질 통합, 테스트 용이 | 더 가파른 학습 곡선 |
| dbt (+ 오케스트레이터) | SQL 변환 특화 | 분석 엔지니어 친화적 | 오케스트레이션만으로 불완전 |
- 📢 섹션 요약 비유: Airflow는 범용 공장 자동화 시스템, Dagster는 품질 관리 특화 시스템, dbt는 완제품 포장 전용 기계다. 목적에 맞는 도구 선택이 중요하다.
Ⅳ. 실무 적용 및 기술사 판단
DAG 설계 모범 사례:
- 멱등성 (Idempotency): 같은 DAG Run을 여러 번 실행해도 결과가 동일해야 함 → 덮어쓰기(UPSERT) 기반 설계
- 태스크 원자성: 각 태스크는 독립적으로 성공/실패 판단 가능해야 함
- 적절한 태스크 크기: 너무 세분화 (오버헤드) vs 너무 큰 단위 (재시도 시 전체 재실행)
- 환경 변수 관리: Airflow Variables, Connections로 환경별 설정 분리
성능 튜닝:
-
스케줄러 파싱 부하: DAG 파일 수 최소화,
min_file_process_interval조정 -
동시 실행 제한:
max_active_runs_per_dag,concurrency설정 -
CeleryExecutor 워커 스케일: 작업량에 따른 워커 수 동적 조정
-
📢 섹션 요약 비유: 멱등성은 같은 주문서를 두 번 넣어도 같은 물건이 한 번만 배송되게 하는 것이다. 재처리 시 중복 문제가 없어야 한다.
Ⅴ. 기대효과 및 결론
Airflow 도입으로 데이터 파이프라인이 코드로 관리되어 변경 이력 추적, 코드 리뷰, 자동화 테스트가 가능해진다. 실패 태스크의 자동 재시도와 알림으로 데이터 신뢰성이 높아지고, 시각적 DAG 모니터링으로 운영 효율성이 향상된다.
한계는 실시간 스트리밍 처리에 부적합하다는 점이다. Airflow는 배치 스케줄 기반이므로, 이벤트 드리븐 실시간 처리는 Kafka+Flink 같은 스트리밍 프레임워크가 필요하다. 배치(Airflow)와 스트리밍(Flink)을 병행하는 Lambda Architecture 또는 Kappa Architecture가 실무에서 많이 사용된다.
- 📢 섹션 요약 비유: Airflow는 정기 배송 서비스다. 매일 정해진 시간에 물건을 배달하는 데는 최적이지만, 즉시 배달(실시간 스트리밍)은 다른 서비스(Flink)가 필요하다.
📌 관련 개념 맵
| 개념 | 연결 포인트 |
|---|---|
| DAG (Directed Acyclic Graph) | Airflow 파이프라인 정의 핵심 구조 |
| KubernetesExecutor | 태스크별 K8s Pod 격리 실행 |
| 멱등성 (Idempotency) | 파이프라인 재실행 안전성 핵심 원칙 |
| dbt + Airflow | SQL 변환 + 오케스트레이션 결합 패턴 |
| Lambda / Kappa Architecture | 배치+스트리밍 파이프라인 아키텍처 패턴 |
📈 관련 키워드 및 발전 흐름도
cron 기반 스크립트 (의존성·재시도 관리 어려움)
│
▼
Airflow DAG (Python으로 파이프라인 코드화)
│
▼
CeleryExecutor → KubernetesExecutor (분산·격리 실행)
│
▼
DataOps: dbt + Airflow + 데이터 품질 테스트 통합
│
▼
Prefect · Dagster (현대적 데이터 자산 중심 오케스트레이터)
👶 어린이를 위한 3줄 비유 설명
- Airflow는 레시피 관리 앱이에요. 요리 순서(DAG)를 정해두면 각 단계를 정시에 자동으로 실행해줘요.
- 한 단계가 실패하면 자동으로 다시 시도하고, 계속 실패하면 요리사(운영자)에게 알림을 보내요.
- 모든 요리 기록(실행 로그)이 남아서 "어제 몇 시에 어떤 요리가 실패했는지" 바로 확인할 수 있어요!