Apache Airflow란? 에어플로우로 데이터 파이프라인을 자동화하는 이유

매일 아침 데이터를 내려받고, Python이나 R로 정리하고, 보고서를 갱신한 뒤 담당자에게 완료 메시지를 보내고 있나요? 작업이 하나일 때는 직접 실행하거나 예약 실행으로 충분합니다. 하지만 단계가 늘어나면 “몇 시에 실행할까?”보다 “앞 작업이 실패하면 어떻게 할까?”, “어제 데이터만 다시 처리할 수 있을까?”가 더 중요한 문제가 됩니다.

Apache Airflow는 여러 작업의 순서, 실행 조건, 일정, 재시도와 실행 기록을 코드로 정의하고 관리하는 워크플로 오케스트레이션 플랫폼입니다. 이 글에서는 Airflow가 실제 업무에서 어떤 문제를 해결하는지, DAG·Task·Operator·Scheduler가 각각 무엇인지, Cron만으로 충분한 경우와 Airflow가 필요한 경우를 처음 접하는 분도 이해할 수 있게 설명합니다.

Airflow를 한 문장으로 설명하면

Airflow는 데이터를 분석하거나 보관하는 프로그램이 아닙니다. Python 함수, 셸 명령, SQL, 외부 서비스 호출처럼 이미 존재하는 작업들이 언제, 어떤 순서로, 어떤 조건에서 실행될지 관리합니다.

예를 들어 일일 매출 보고서를 만드는 과정은 다음과 같습니다.

원천 데이터 도착 확인
        ↓
매출 데이터 수집
        ↓
데이터 정제
        ↓
일일 지표 계산
        ↓
대시보드 갱신
        ↓
완료 메시지 전송

이 흐름에는 단순한 실행 시간 외에도 여러 규칙이 있습니다.

• 원천 데이터가 도착해야 수집을 시작합니다.
• 수집이 성공해야 정제를 실행합니다.
• 정제가 실패하면 잘못된 지표를 만들면 안 됩니다.
• 일시적인 네트워크 오류라면 일정 시간 뒤 재시도합니다.
• 최종 실패하면 담당자에게 알려야 합니다.
• 특정 날짜의 데이터만 다시 처리할 수 있어야 합니다.

Airflow는 이런 규칙을 Python 코드로 표현하고, 각 실행의 상태와 로그를 웹 화면에서 확인할 수 있게 해줍니다.

반복 스크립트가 복잡해질 때 생기는 문제

처음에는 파일 세 개를 차례대로 실행하는 셸 스크립트를 만들 수 있습니다. 그러나 시간이 지나면 다음과 같은 일이 벌어집니다.

• 첫 번째 작업이 실패했는데 뒤 작업이 계속 실행됩니다.
• 어느 단계에서 실패했는지 로그를 찾아다녀야 합니다.
• 실패한 한 단계만 다시 실행하기 어렵습니다.
• 작업 순서와 담당 스크립트가 여러 서버에 흩어집니다.
• 담당자가 바뀌면 전체 흐름을 파악하기 어렵습니다.

Airflow의 가장 큰 가치는 “자동으로 실행한다”가 아니라 작업의 관계와 상태를 명시적으로 관리한다는 데 있습니다.

DAG, Task, Operator, Scheduler 쉽게 이해하기

DAG: 전체 작업의 설계도

DAG는 Directed Acyclic Graph의 약자입니다. 쉽게 말해 어떤 작업을 어떤 순서로 실행할지 나타내는 설계도입니다. 일일 매출 보고서 전체가 하나의 DAG가 될 수 있습니다.

DAG에는 실행 일정, Task 목록, Task 사이의 의존 관계, 재시도와 같은 운영 정보가 들어갑니다. 한 방향으로 진행하며 순환하지 않아야 합니다. A가 B를 기다리고 B가 다시 A를 기다리는 구조는 시작할 수 없기 때문입니다.

Task: 실제로 실행되는 한 단계

Task는 DAG 안의 개별 작업입니다. API에서 데이터 받기, CSV 정리하기, SQL 실행하기, 보고서 생성하기, Slack 메시지 보내기 등이 각각 Task가 될 수 있습니다.

Task를 적절한 크기로 나누면 실패 위치를 찾기 쉽고, 성공한 작업을 다시 돌리지 않고 실패한 부분만 재실행하기도 편합니다.

Operator: Task를 만드는 작업 템플릿

Operator는 어떤 종류의 작업을 실행할지 정의하는 템플릿입니다.

• BashOperator: 셸 명령 실행
• PythonOperator: Python 함수 실행
• 각종 데이터베이스·클라우드 서비스용 Operator: 외부 시스템 작업 실행

Operator를 DAG 안에서 사용하면 실제 Task가 만들어집니다. Python 함수를 자연스럽게 Task로 표현하는 TaskFlow API도 많이 사용합니다.

Scheduler: 실행할 시점을 판단하는 관리자

Scheduler는 DAG의 일정과 Task 의존 관계를 확인합니다. 실행 시간이 되었고 앞선 Task가 성공했다면 다음 Task를 실행 대상으로 보냅니다.

Airflow 3.x의 기본 구조에는 Scheduler 외에도 DAG 파일을 읽는 DAG Processor, 웹 UI와 REST API를 제공하는 API Server, 실행 상태를 저장하는 메타데이터 데이터베이스가 포함됩니다.

Airflow와 Cron은 무엇이 다른가?

비교CronApache Airflow

핵심 역할	시간에 맞춰 명령 실행	여러 작업의 흐름과 상태 관리
작업 관계	스크립트 안에서 직접 처리	DAG에서 의존 관계를 명시
실행 화면	기본 제공하지 않음	웹 UI에서 DAG와 Task 확인
실패 재시도	별도 구현	Task별 정책 설정
로그	직접 수집·보관	Task 실행별로 확인
과거 데이터 재처리	직접 구현	데이터 구간과 backfill 지원

매일 새벽 백업 명령 하나를 실행하는 정도라면 Cron이 더 간단합니다. 반대로 여러 작업에 선후 관계가 있고, 실패 지점을 추적하거나 특정 날짜를 다시 처리해야 한다면 Airflow의 장점이 커집니다.

Airflow가 적합한 상황

• 데이터 수집, 정제, 적재, 보고서 갱신이 단계적으로 연결됩니다.
• 앞 작업의 성공 여부에 따라 다음 작업을 실행해야 합니다.
• 매일 또는 매주 같은 파이프라인을 반복합니다.
• 실패한 단계와 로그를 한곳에서 확인해야 합니다.
• 작업별 재시도와 실패 알림이 필요합니다.
• 특정 날짜나 데이터 구간을 다시 처리해야 합니다.
• Python, 셸, SQL, 외부 서비스를 하나의 흐름으로 연결해야 합니다.

Airflow가 적합하지 않을 수 있는 상황

• 실시간 요청에 매우 빠르게 응답해야 하는 일반 웹 서비스
• 한 번 실행하고 끝나는 간단한 스크립트
• 작업 하나를 정해진 시간에 실행하는 단순 예약
• 서버와 컨테이너 운영 부담이 더 큰 소규모 자동화

Airflow는 주로 일정이나 이벤트에 따라 실행되는 배치형 워크플로에 강합니다. 큰 데이터를 Airflow 자체에 저장하는 도구도 아닙니다. 실제 데이터는 데이터베이스나 객체 스토리지에 두고, Task 사이에는 위치나 작은 메타데이터를 전달하는 방식이 적절합니다.

처음 배울 때의 순서

1. WSL2와 Docker로 로컬 실습 환경 구성
2. DAG와 Task의 관계 이해
3. 첫 DAG 작성과 수동 실행
4. BashOperator와 PythonOperator 사용
5. XCom으로 작은 데이터 전달
6. Sensor와 Trigger Rule로 실행 조건 제어
7. Connection과 Hook으로 외부 서비스 연결
8. 로그, 알림, 모니터링으로 운영 준비

정리

이 글에서는 Airflow의 역할, DAG·Task·Operator·Scheduler의 관계, Cron과의 차이, 적합한 사용 상황을 판단하는 기준을 완결했습니다. Airflow가 무엇인지 이해하는 것이 목적이라면 여기까지로 충분합니다. 다음 단계는 직접 실습 환경을 구성하고 작은 DAG 하나를 실행해 보는 것입니다.

환경 구성부터 DAG 작성, Operator, XCom, Sensor, 외부 서비스 연결, Slack 알림과 모니터링까지 하나의 흐름으로 실습하고 싶다면 Apache Airflow 마스터 클래스의 전체 구성을 확인해 보세요. 총 86개 수업과 58종 이상의 실습 DAG로 각 기능을 연결해 학습할 수 있습니다.

전체 Airflow 커리큘럼 확인하기

참고 문서

• Apache Airflow Architecture Overview
• Apache Airflow DAGs