Airflow로 데이터 파이프라인 만들기

Airflow로 데이터 파이프라인 만들기. 매일 새벽 돌아가는 배치들이 늘어나면, 순서와 실패 관리가 지옥이 된다. Airflow는 이 워크플로를 코드(DAG)로 정의하고 스케줄링·재시도·모니터링까지 해준다. DAG의 개념부터 실제 작성까지 코드로 정리한다.

---

들어가며

데이터 작업이 하나둘 늘어나면 곧 문제가 생긴다. "매일 새벽 2시에 데이터를 추출하고, 끝나면 변환하고, 그게 끝나면 적재하고, 실패하면 알림을 보낸다." 이걸 cron과 셸 스크립트로 엮다 보면, 어느 순간 무엇이 언제 돌고, 어디서 실패했는지 아무도 모르는 상태가 된다.

ETL/ELT, 배치 처리 글에서 다룬 데이터 작업들을 체계적으로 관리하는 도구가 바로 Apache Airflow다. 워크플로를 코드로 정의하고, 스케줄링·의존성·재시도·모니터링을 한곳에서 처리한다.

Airflow의 핵심은 "워크플로를 코드로 관리한다"는 것이다. 파이프라인이 코드가 되면, 버전 관리도 리뷰도 테스트도 가능해진다.

이 글에서는 Airflow의 핵심 개념(DAG, Task, Operator)을 잡고, 실제 파이프라인을 코드로 만들어본다.

---

Airflow란

Airflow는 워크플로를 작성·스케줄링·모니터링하는 플랫폼이다. 2014년 에어비앤비에서 시작해 지금은 데이터 엔지니어링의 사실상 표준이 됐다.

핵심은 "파이프라인을 파이썬 코드로 정의한다" 는 점이다. GUI로 드래그하는 게 아니라, 코드로 작성하기 때문에 다음이 가능하다.

• 버전 관리: Git으로 파이프라인 변경 이력을 추적
• 코드 리뷰: 파이프라인 변경도 PR로 검토
• 동적 생성: 반복문으로 비슷한 작업을 자동 생성
• 테스트: 파이프라인 로직을 테스트 코드로 검증

cron이 "시간이 되면 명령어를 실행"하는 단순 스케줄러라면, Airflow는 작업 간의 의존성, 실패 시 재시도, 진행 상황 시각화까지 관리하는 오케스트레이터다.

---

핵심 개념 — DAG, Task, Operator

Airflow를 이해하려면 세 개념만 잡으면 된다.

DAG (Directed Acyclic Graph) — 방향성 비순환 그래프. 쉽게 말해 작업들의 실행 순서를 정의한 흐름도다. "A 끝나면 B, B 끝나면 C" 같은 의존 관계를 나타낸다. 순환(cycle)이 없어서, 작업이 자기 자신으로 돌아오지 않는다.

Task — DAG를 구성하는 개별 작업 하나. "데이터 추출", "변환", "적재" 각각이 Task다.

Operator — Task가 실제로 무슨 일을 하는지 정의하는 템플릿. 종류가 다양하다.

Operator	하는 일
PythonOperator	파이썬 함수 실행
BashOperator	셸 명령 실행
SQLExecuteQueryOperator	SQL 쿼리 실행
EmailOperator	이메일 발송

 

Airflow

정리하면, DAG라는 흐름도 안에 여러 Task가 있고, 각 Task는 Operator로 실제 동작을 수행한다.

---

첫 DAG 만들기

추출 → 변환 → 적재로 이어지는 간단한 ETL 파이프라인을 DAG로 만들어보자.

from airflow import DAG
from airflow.operators.python import PythonOperator
from datetime import datetime, timedelta

# 1. 기본 설정 (실패 시 재시도 등)
default_args = {
    "owner": "jinoism",
    "retries": 2,                          # 실패하면 2번 재시도
    "retry_delay": timedelta(minutes=5),   # 5분 간격으로
}

# 2. 각 Task가 실행할 함수
def extract():
    print("소스에서 데이터 추출")
    return "raw_data"

def transform():
    print("데이터 변환·가공")
    return "clean_data"

def load():
    print("웨어하우스에 적재")

# 3. DAG 정의
with DAG(
    dag_id="daily_etl",
    default_args=default_args,
    description="매일 도는 ETL 파이프라인",
    schedule="0 2 * * *",                  # 매일 새벽 2시 (cron 표현식)
    start_date=datetime(2026, 1, 1),
    catchup=False,                         # 과거 미실행분 건너뛰기
    tags=["etl", "daily"],
) as dag:

    # 4. Task 정의 (각각 Operator로)
    extract_task = PythonOperator(
        task_id="extract",
        python_callable=extract,
    )
    transform_task = PythonOperator(
        task_id="transform",
        python_callable=transform,
    )
    load_task = PythonOperator(
        task_id="load",
        python_callable=load,
    )

    # 5. 실행 순서(의존성) 정의 — 이게 DAG의 핵심
    extract_task >> transform_task >> load_task

마지막 줄 extract_task >> transform_task >> load_task가 Airflow의 정수다. >> 연산자로 "추출 → 변환 → 적재" 순서를 선언한다. transform은 extract가 성공해야 시작되고, load는 transform이 끝나야 시작된다.

---

의존성 — 복잡한 흐름 만들기

실제 파이프라인은 일직선이 아니다. 여러 작업이 갈라지고 합쳐진다. Airflow는 이런 흐름도 직관적으로 표현한다.

# 여러 소스에서 동시에 추출 → 모두 끝나면 병합
extract_db >> merge
extract_api >> merge
merge >> transform >> load

# 또는 리스트로 한 번에
[extract_db, extract_api] >> merge >> transform >> load

extract_db와 extract_api는 동시에(병렬로) 실행되고, 둘 다 끝나야 merge가 시작된다. 이렇게 "여러 작업을 병렬로 돌리고, 다 모이면 다음으로" 같은 흐름을 코드 몇 줄로 표현한다.

# 적재 후 갈라지기: 성공하면 알림 + 통계 동시 실행
load >> [send_notification, update_stats]

---

실패 처리와 재시도

Airflow가 cron보다 강력한 결정적 이유다. 작업이 실패했을 때의 처리를 세밀하게 제어한다.

default_args = {
    "retries": 3,                          # 3번까지 재시도
    "retry_delay": timedelta(minutes=5),   # 5분 간격
    "retry_exponential_backoff": True,     # 재시도 간격을 점점 늘림
    "email_on_failure": True,              # 실패 시 이메일
    "execution_timeout": timedelta(hours=1),  # 1시간 넘으면 실패 처리
}

특정 Task만 다르게 설정할 수도 있다.

critical_task = PythonOperator(
    task_id="critical_load",
    python_callable=load,
    retries=5,                             # 이 작업만 5번 재시도
    retry_delay=timedelta(minutes=10),
)

일시적인 네트워크 오류로 실패했다면 몇 분 뒤 재시도로 자동 복구되고, 그래도 안 되면 알림이 온다. 새벽에 조용히 실패해서 아침에 발견하는 cron의 악몽이 사라진다.

---

웹 UI — 한눈에 보는 파이프라인

Airflow의 또 다른 강점은 웹 UI다. 모든 DAG의 실행 상태를 시각적으로 보여준다.

• Graph View: DAG의 흐름도와 각 Task의 상태(성공=초록, 실패=빨강, 실행중=노랑)
• Grid View: 날짜별 실행 이력을 격자로 — 언제 무엇이 실패했는지 한눈에
• Logs: 각 Task의 실행 로그를 클릭 한 번으로 확인
• 수동 실행·재실행: 실패한 Task만 골라 다시 돌리기

cron은 "돌았는지 안 돌았는지"조차 로그를 뒤져야 알지만, Airflow는 대시보드에서 전체 파이프라인의 건강 상태를 바로 본다. 이 가시성이 운영을 완전히 바꾼다.

---

cron과 무엇이 다른가

	cron	Airflow
정의 방식	셸 스크립트	파이썬 코드 (DAG)
의존성	수동 관리 (지옥)	>>로 명시
실패 처리	직접 구현	재시도·알림 내장
모니터링	로그 뒤지기	웹 UI 대시보드
재실행	수동	실패분만 선택 재실행
버전 관리	어려움	Git으로 관리

cron이 나쁜 건 아니다. 단순한 단일 작업이면 cron으로 충분하다. 하지만 작업이 여러 개로 얽히고, 순서와 실패 관리가 중요해지는 순간 Airflow의 가치가 폭발한다.

---

마치며

Airflow는 "데이터 파이프라인을 코드로 관리한다"는 발상의 도구다. 흩어진 배치 작업들을 DAG라는 흐름도로 묶고, 의존성·스케줄·재시도·모니터링을 한곳에서 처리한다. cron과 셸 스크립트로 버티던 워크플로가 커졌다면, Airflow 도입을 고민할 때다.

핵심만 다시 짚으면, DAG(흐름도) 안에 Task(작업)들이 있고, 각 Task는 Operator로 동작하며, >>로 순서를 잇는다. 이 단순한 모델 위에 재시도·알림·시각화가 얹혀 있다. 처음엔 개념이 낯설지만, 한 번 DAG를 짜보면 "왜 진작 안 썼지" 싶어질 것이다.

데이터가 흐르는 파이프라인을 만드는 일은 결국 "무엇을, 언제, 어떤 순서로, 실패하면 어떻게"를 정의하는 일이다. Airflow는 그 정의를 코드로 명확하게 만들어준다.

---

참고 출처

• Apache Airflow 공식 문서 — https://airflow.apache.org/docs/
• Airflow: Core Concepts (DAGs) — https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/dags.html
• Astronomer: Airflow Guides — https://www.astronomer.io/docs/learn/