데이터 엔지니어링 핵심 도구 ‘Apache Airflow’ 개념 정리

한 편으로 이해하는 ‘Airflow’의 모든 것

오늘은 데이터 엔지니어링의 핵심 도구인 ‘Apache Airflow’에 대해 이야기해 보려고 합니다. 에어플로우는 데이터 엔지니어(DE)와 데이터 애널리틱스 엔지니어(DAE)라면 반드시 알아야 하는 툴 중 하나인데요. 데이터 파이프라인을 구축하고 운영하는 데 있어 핵심적인 역할을 하며, 복잡한 데이터 워크플로우를 효율적으로 관리할 수 있게 해주는 필수 도구입니다.

에어플로우(Airflow)란?

에어플로우는 ‘Job Orchestration tool’입니다. 풀어서 설명하면, 복잡한 데이터 처리 작업을 자동화하고 관리하는 도구죠. 마치 오케스트라 지휘자처럼 여러 작업의 실행 순서와 의존성을 조율합니다. 에어플로우에선 데이터 파이프라인을 프로그래밍 방식으로 작성, 스케줄링 및 모니터링할 수 있습니다.

주로 데이터 엔지니어, 애널리틱스 엔지니어가 사용하며, 가장 큰 장점은 파이썬 코드로 파이프라인을 정의할 수 있다는 점입니다. 이는 단순히 설정 파일로 작업을 정의하는 것보다 훨씬 더 유연하고 강력한 기능을 제공하죠. 예를 들어, 조건문과 반복문을 사용해 동적으로 태스크를 생성할 수 있고, 기존 파이썬 라이브러리를 활용할 수도 있습니다.

또한 에어플로우는 확장성도 뛰어납니다. AWS, GCP, Azure 등 클라우드 서비스부터 Hadoop, Spark, Presto 같은 빅데이터 도구까지, 다양한 시스템과의 연동을 위한 수많은 플러그인을 제공합니다. 이러한 풍부한 생태계 덕분에 거의 모든 데이터 처리 작업을 에어플로우로 통합할 수 있습니다. 실제 운영 측면에서도 웹 기반의 직관적인 인터페이스를 통해 복잡한 파이프라인 상태를 한눈에 파악할 수 있고, 문제가 발생했을 때 빠르게 대응할 수 있습니다. 특히 실패한 태스크의 자동 재시도나 알림 설정 같은 기능들은 운영자의 부담을 크게 줄여주죠.

데이터, 그리고 데이터 파이프라인

데이터의 종류

우리가 다루는 데이터는 크게 메타데이터와 이벤트 데이터로 나눌 수 있는데요. 그 역할에 따라 여러 종류로 분류할 수도 있습니다.

저는 데이터 아키텍처를 담당하는 Analytics Engineer이기 때문에, 앞으로의 설명은 주로 메타데이터와 이벤트 데이터를 중심으로 진행하도록 하겠습니다.

데이터 파이프라인

데이터 파이프라인은 데이터가 소스에서 목적지까지 이동하는 전체 과정을 의미합니다. 현대의 데이터 파이프라인은 크게 ETL(Extract, Transform, Load)과 ELT(Extract, Load, Transform) 두 가지 방식으로 구분되죠.

ETL은 전통적인 방식으로, 데이터를 추출하여 변환한 후 적재하는 방식입니다. 반면 ELT는 먼저 데이터를 추출하여 적재한 후, 필요에 따라 변환하는 현대적인 접근 방식입니다. 특히 OLAP(Online Analytical Processing) 환경에서는 ELT가 선호되는데, 이는 대규모 데이터 웨어하우스의 강력한 처리 능력을 활용할 수 있기 때문입니다.

OLAP 시스템은 복잡한 분석 쿼리를 효율적으로 처리할 수 있도록 설계되었습니다. Snowflake, Redshift, BigQuery 같은 현대적인 데이터 웨어하우스들은 컬럼 기반 저장소와 대규모 병렬 처리를 통해 빠른 분석을 가능하게 합니다. 현대의 데이터 파이프라인은 실시간 처리와 배치 처리를 모두 지원해야 하는데요. 실시간 처리는 Kafka, Spark Streaming 등을 통해 이루어지며, 배치 처리는 Airflow와 같은 도구를 통해 정기적으로 수행되죠.

실시간 처리 vs 배치 처리

다음으로 데이터 처리 방식은 크게 실시간과 배치로 나눌 수 있습니다.

실시간 처리는 즉각적인 대응이 필요한 상황에서 필수적입니다. 예를 들어, 금융 거래에서 부정 거래를 탐지하는 경우, 거래가 발생하는 순간 패턴을 분석하여 이상 징후를 감지해야 하죠. 또한 사용자의 현재 행동에 기반한 실시간 추천 시스템이나 서비스 장애를 감지하는 모니터링 시스템에서도 실시간 처리가 중요한 역할을 합니다.

Airflow의 역할

배치 처리 환경에서 Airflow는 데이터 파이프라인의 중추적인 역할을 담당합니다. 현재 데이터 엔지니어링 분야에서 가장 널리 사용되는 워크플로우 관리 도구로 자리 잡았는데, 이처럼 표준이 된 이유는 다음과 같습니다.

실제 기업들은 Airflow를 다음과 같은 배치 작업에 활용하고 있습니다.

• 데이터 웨어하우스 테이블 새로고침(Daily/Weekly)
• 비즈니스 인텔리전스 리포트 자동 생성
• 데이터 품질 검사 자동화
• ML 모델 정기적인 재학습
• 로그 데이터 아카이빙

특히 분석 환경에서는 데이터의 신선도(Freshness)와 품질(Quality)이 매우 중요한데, Airflow는 이러한 요구사항을 효과적으로 충족시켜 줍니다. 예를 들어, 매일 아침 9시에 전날의 데이터를 집계하고, 품질 체크를 수행한 후 이상이 없다면, BI 대시보드를 갱신하는 일련의 과정을 자동화할 수 있습니다.

DAG(Directed Acyclic Graph) 이해하기

Airflow를 완벽히 이해하기 위해서는 몇 가지 핵심 구성요소를 알아야 하는데요. 먼저 DAG부터 시작해 보겠습니다. DAG는 쉽게 말해 ‘할 일 목록’과 ‘실행 순서’를 정리해 둔 설계도입니다. “먼저 이 작업을 하고 → 그다음 저 작업을 하고 → 마지막으로 이걸 하자”라는 순서를 정의해 놓은 것이죠.

예를 들어, 매일 아침 데이터를 처리하는 과정을 DAG로 표현하면 이렇습니다.

간단한 DAG 예시도 살펴볼게요.

위 예시를 살펴보면, 데이터 파이프라인의 기본적인 구조를 이해할 수 있습니다. DAG의 이름을 정하고, 실행 시작일과 주기를 설정하며, 필요한 작업들을 Task로 정의하고 있죠. 이 예시에서는 데이터를 추출하고 변환하는 두 가지 Task를 만들었는데, 이는 PythonOperator를 사용해 구현했습니다. Task들 간의 실행 순서는 >>연산자로 정의하고 있습니다. 이러한 Task와 Operator는 뒤에서 더 자세히 다뤄보겠습니다.

Task란?

Task는 DAG 내에서 실행되는 개별 작업의 단위입니다. 하나의 DAG는 여러 개의 Task로 구성되며, 각 Task는 특정한 작업을 수행합니다.

이 다이어그램은 하나의 DAG 안에서 여러 Task가 어떻게 협력하는지 보여줍니다. 각각의 네모 박스가 하나의 Task이며, 화살표는 Task 간의 의존성을 나타냅니다. Task들의 의존성은 데이터 파이프라인에서 매우 강력한 기능을 제공하죠.

병렬 처리

서로 독립적인 Task들은 동시에 실행될 수 있습니다.

또한 Task들 간의 의존성은 다음과 같은 방식으로 정의할 수 있습니다.

조건부 실행

이전 Task의 결과에 따라 다른 경로로 진행할 수 있습니다.

재시도 및 복구

Task 실패 시 자동으로 재시도하거나 대체 작업을 실행할 수 있습니다. 이러한 의존성 관리 덕분에 복잡한 데이터 파이프라인도 안정적으로 운영할 수 있습니다. 예를 들어, 매일 아침 실행되는 데이터 품질 검사 Task가 실패했다고 가정해 보겠습니다. 

Airflow는 설정된 재시도 정책에 따라 자동으로 Task를 다시 실행하며, 계속 실패할 경우 담당자에게 알림을 보내 즉각적인 대응이 가능하게 합니다. 문제 해결 후에는 실패한 지점부터 파이프라인을 재개할 수 있어, 전체 프로세스의 안정성을 보장합니다.

또한 여러 데이터 소스로부터 정보를 수집하는 경우, 각각의 수집 Task를 병렬로 실행하여 전체 처리 시간을 단축할 수 있습니다. 만약 특정 소스에서 문제가 발생하더라도 다른 Task들은 정상적으로 진행되므로, 전체 파이프라인의 효율성을 유지할 수 있죠. 이처럼 Airflow는 파이썬 코드로 이러한 복잡한 워크플로우를 명확하게 정의하고 안정적으로 실행하며, 문제 발생 시 즉각적인 대응이 가능합니다.

Task의 종류

Task의 종류는 다음과 같습니다. 실무적으로는 Operator 사용이 거의 대부분이라 이 부분만 설명하겠습니다.

Operator란?

Operator는 Task의 실제 작업을 정의하는 클래스입니다. “실제로 무엇을 할지”를 결정하는 실행 단위라고 생각하면 됩니다. 여기서 클래스란 사전에 어떻게 실행할지 정해놓은 양식입니다.

• BashOperator: 명령어 실행 클래스
• PythonOperator: 파이썬 코드 실행 클래스
• PostgresOperator: DB 작업 클래스

이러한 Operator를 조립하여 원하는 데이터 파이프라인을 만들 수 있습니다.

BashOperator

BashOperator는 Shell 명령어를 실행하는 Operator입니다. 시스템 명령어 실행, 스크립트 실행, 파일 조작 등 Shell에서 할 수 있는 모든 작업을 수행할 수 있습니다. 실무에서는 Python 스크립트를 별도의 모듈로 작성하고, 이를 BashOperator를 통해 실행하는 패턴을 많이 사용합니다.

이 방식을 선호하는 데는 두 가지 이유가 있습니다.

1. 코드 관리의 용이성

• 복잡한 로직을 별도의 Python 파일로 분리하여 관리할 수 있습니다.
• 버전 관리 시스템(Git 등)을 통한 코드 리뷰가 수월해집니다.
• 다른 DAG에서도 같은 스크립트를 재사용할 수 있습니다.

2. 디버깅의 편의성

• Python 스크립트를 독립적으로 테스트할 수 있습니다.
• IDE의 디버깅 도구를 활용할 수 있습니다.
• 로컬 환경에서 쉽게 테스트가 가능합니다.

가상환경 관리

가상환경 관리는 데이터 파이프라인 운영에서 매우 중요한 부분입니다. Airflow에서는 두 가지 방식으로 가상환경을 관리할 수 있습니다.

1. DAG 레벨에서의 관리

• DAG 전체에서 사용할 가상환경을 지정합니다.
• 모든 Task가 동일한 환경에서 실행됩니다.
• 설정이 간단하고 일관성을 유지하기 쉽습니다.

2. Operator 레벨에서의 관리

• Task마다 다른 가상환경을 사용할 수 있습니다.
• Task별로 필요한 라이브러리가 다를 때 유용합니다.
• 더 세밀한 제어가 가능합니다.

다음으로 BashOperator 예시 코드에 대해 설명하겠습니다.

이 코드는 두 가지 방식의 BashOperator 사용을 보여줍니다. 첫 번째는 기본 실행 방식입니다. task_id로 ‘run_basic_script’라는 고유 식별자를 지정하고, bash_command를 통해 시스템의 기본 Python으로 스크립트를 실행합니다. 이 방식은 구현이 간단하지만, 시스템 Python에 의존하므로 라이브러리 간 충돌이 발생할 수 있다는 단점이 있죠.

두 번째는 가상환경을 사용하는 방식입니다. task_id는 ‘run_with_venv’로 지정하고, 세 가지 명령어를 연속적으로 실행합니다. 먼저 source 명령어로 특정 가상환경을 활성화하고, Python 스크립트를 실행한 후, deactivate 명령어로 가상환경을 비활성화하게 됩니다.

여러 줄의 명령어는 ‘\\\\’ 문법으로 연결되며, 이 방식은 격리된 환경에서 실행되므로 의존성 충돌을 방지할 수 있다는 장점이 있습니다. 실무에서는 두 번째 방식을 더 많이 사용하는데, 가상환경을 통해 각 파이프라인에 필요한 정확한 라이브러리 버전을 관리할 수 있기 때문입니다.

PythonOperator

PythonOperator는 Python 함수를 실행하는 가장 유연한 Operator입니다. 데이터 처리, API 호출, 복잡한 비즈니스 로직 등 Python으로 할 수 있는 모든 작업을 수행할 수 있습니다.

일반적으로는 Python 스크립트를 별도의 모듈로 만들어 두고, import해서 사용합니다.

위 예시처럼 이렇게 코드를 구성하면 유지보수가 쉽고, 재사용성도 높아집니다.

PostgresOperator

다음은 PostgreSQL 데이터베이스 작업을 위한 Operator입니다. 이러한 데이터베이스를 작업할 때는 크게 두 가지 접근 방식이 있습니다.

1. PythonOperator 내에서 직접 데이터베이스 연결 코드를 작성하는 방법
2. Airflow에서 제공하는 데이터베이스 전용 Operator를 사용하는 방법

PostgresOperator를 사용하면 연결 관리나, 에러 처리와 같은 기본적인 기능을 Airflow가 알아서 처리해 주기 때문에 코드가 더 간결해지고 관리하기 쉬워집니다. 특히 데이터베이스 연결 정보를 Airflow의 Connection 시스템을 통해 중앙에서 관리할 수 있다는 것이 큰 장점입니다.

이 외에도 Airflow는 다양한 Operator를 제공합니다. 이렇게 특화된 Operator는 각각의 서비스나 플랫폼과의 연동을 쉽게 만들어 줍니다. 그러나 꼭 전용 Operator를 사용할 필요는 없습니다. Python 스크립트로 직접 해당 기능을 구현하고, 이를 PythonOperator나 BashOperator로 실행하는 것도 좋은 방법이 될 수 있습니다.

개인적으로는 최근 ‘Cursor’와 같은 AI 기반 IDE의 발전 덕분에, PythonOperator, BashOperator, 그리고 DB 관련 Operator 정도만 사용하고, 나머지 기능들은 직접 구현하는 것을 선호합니다. 물론 접근 방식은 회사마다 다를 수 있습니다. 유지보수와 관리 측면에서 기본 Operator 사용을 선호하는 조직도 있습니다. 그러나 주석을 잘 달고 문서화를 철저히 한다면, 직접 구현하는 방식도 충분히 좋은 선택이 될 수 있다고 생각합니다.

Airflow 전체 구성요소

앞서 설명한 DAG와 Task 외에도 Airflow는 다양한 구성 요소로 이루어져 있습니다. 마치 정교한 시계처럼 여러 부품이 조화롭게 작동하는 시스템이죠. 전체 구성요소를 좀 더 쉽게 알아보기 위해 공항과 활주로에 비유해 봤습니다.

그리고 위 구성 요소들의 워크플로우를 시각화하면 다음과 같습니다. Airflow는 인천공항과 같은 곳으로, 각 구성 요소가 맡은 역할이 있고, 이들이 서로 협력하면서 안정적인 워크플로우 실행을 가능하게 만들어 줍니다.

Web Server(웹 서버): 공항 전체

웹 서버는 인천공항과 같은 공항 전체라고 생각하면 됩니다. 하나의 거대한 시스템으로서, 모든 운영을 총괄하고 감독하는 역할을 하죠. 공항이 터미널, 활주로, 관제탑을 통합 관리하듯이, 웹 서버도 여러 스케줄러, Executor, Worker를 하나의 시스템으로 통합해서 관리합니다. 모든 운영 현황은 대시보드(공항의 중앙 관제 시스템)를 통해 한눈에 파악할 수 있죠.

Scheduler(스케줄러): 터미널

스케줄러는 공항의 터미널과 같습니다. 인천공항의 T1, T2처럼 여러 개의 터미널이 동시에 운영될 수 있죠. 각 터미널은 독립적으로 운영되면서도 전체 공항 시스템과 긴밀하게 연계됩니다. 각 터미널이 자신의 게이트와 비행기들을 관리하듯이, 각 스케줄러도 자신에게 할당된 DAG를 독립적으로 관리합니다. 한 터미널에 문제가 생겨도 다른 터미널은 정상 운영될 수 있는 것처럼, 여러 스케줄러를 운영하면 시스템의 안정성과 확장성을 높일 수 있습니다.

Worker(작업자): 비행기

Worker는 실제로 하늘을 나는 비행기입니다. 활주로를 통해 이륙한 비행기들이 각자의 목적지를 향해 날아가듯이, Worker는 각자 할당받은 Task를 수행합니다. 각 비행기가 독립적으로 운항하면서도 관제 시스템과 지속적으로 통신하듯이, Worker도 독립적으로 작업을 수행하면서 중앙 시스템과 상태를 공유하죠.

Executor(실행기): 활주로

Executor는 터미널에 속한 활주로입니다. 각 터미널마다 여러 개의 활주로를 가질 수 있고, 이 활주로를 통해 실제 비행기(Worker)들이 이륙(Task)하게 됩니다. 공항마다 활주로 운영 방식이 다르듯이, Airflow도 상황에 맞는 다양한 Executor를 선택할 수 있습니다. 가장 기본이 되는 SequentialExecutor는 작은 지방 공항처럼 활주로가 하나밖에 없습니다. 비행기가 아무리 많아도 한 번에 한 대씩만 이륙할 수 있죠. 개발 환경이나 테스트용으로는 충분하지만, 실제 운영 환경에서는 비효율적일 수도 있습니다.

반면, CeleryExecutor는 인천공항처럼 대형 국제공항입니다. 여러 터미널에 많은 활주로가 있어서 수많은 비행기를 동시에 처리할 수 있습니다. 다른 지역의 공항과도 긴밀하게 협력하면서 운영됩니다.

KubernetesExecutor는 미래의 스마트 공항이라고 할 수 있는데요. 필요할 때마다 활주로를 자동으로 만들고, 사용이 끝나면 다른 용도로 전환할 수 있습니다. 각 비행기는 완벽하게 독립된 공간에서 운영되며, 자원도 효율적으로 관리되죠.

결국 어떤 Executor를 선택할지는 여러분의 공항 규모와 운영 방식에 달려있습니다. 하루에 몇 개의 비행기(Task)를 운영해야 하나요? 얼마나 많은 승객(데이터)을 처리해야 하나요? 미래에는 얼마나 확장할 계획인가요? 지금보다 규모가 더 커질 것으로 예상한다면, 처음부터 CeleryExecutor나 KubernetesExecutor를 고려하는 것이 현명할 수 있습니다. 물론 더 복잡한 관제 시스템이 필요하지만, 장기적으로는 더 안정적인 운영이 가능할 겁니다.

XCom(크로스 커뮤니케이션): 항공 통신 시스템

XCom은 공항의 항공 통신 시스템과 같습니다. 비행기들(Workers)이 서로 중요한 정보를 주고받을 때 사용하는 무전기나 데이터링크 시스템이라고 생각하면 됩니다. 예를 들어, A 비행기가 특정 구역의 기상 정보를 발견했다면, 이를 뒤따라오는 B 비행기에 전달할 수 있죠. 단, 무전기로 큰 화물을 전송할 수 없듯이, XCom도 대용량 데이터 전송보다는 간단한 상태 정보나 제어 신호를 주고받는 데 적합합니다.

Metadata Database(메타데이터 데이터베이스): 항공 운항 기록 시스템

메타데이터 데이터베이스는 공항의 운항 기록 시스템입니다. 모든 비행기의 이착륙 시간, 운항 경로, 특이 사항 등을 꼼꼼히 기록하는 블랙박스와 같은 역할을 합니다. 마치 항공사가 과거 운항 기록을 분석하여 더 효율적인 스케줄을 짜고 안전성을 높이듯이, 이 기록들은 파이프라인 최적화와 문제 해결에 귀중한 자료가 됩니다.

예를 들어, 특정 노선(Task)에서 지연이 자주 발생한다면, 그 원인을 파악하고 개선할 수 있죠. 중요한 점은 운영 환경에서는 반드시 PostgreSQL이나, MySQL과 같은 프로덕션급 데이터베이스를 사용해야 한다는 것입니다. 

기본으로 설정되는 SQLite는 개발 환경에서만 사용해야 합니다. SQLite는 동시 접근을 제대로 처리하지 못하기 때문에, 여러 스케줄러나 워커가 동시에 접근하면 데이터베이스 잠금 문제가 발생할 수 있습니다. 특히 CeleryExecutor, KubernetesExecutor를 사용할 때는 PostgreSQL 또는 MySQL 사용이 필수적입니다. 이러한 분산 환경에서는 안정적인 동시성 제어와 트랜잭션 관리가 매우 중요하기 때문이죠.

마치며

지금까지 Apache Airflow의 기본 개념부터, DAG, Task라는 핵심 구성요소, 그리고 다양한 Operator의 활용법까지 알아보았습니다. Airflow는 단순한 스케줄러 이상의 강력한 워크플로우 관리 도구로, 현대 데이터 엔지니어링의 핵심 축을 담당하고 있습니다. 특히 DAG를 통해 복잡한 데이터 파이프라인을 명확하고, 유지 보수하기 쉬운 형태로 정의할 수 있다는 점이 가장 큰 장점이라고 할 수 있죠.

실제 운영 환경에서는 단순히 기능을 아는 것을 넘어, 시스템 아키텍처에 대한 이해가 매우 중요합니다. Web Server, Scheduler, Worker, Executor 등 각 구성 요소들이 어떻게 협력하여 작동하는지 이해함으로써, 더 안정적이고 효율적인 파이프라인을 구축할 수 있습니다.

2025년 3.0 버전 출시를 계획 중인 Airflow는 계속해서 발전하고 있는 도구입니다. 꾸준히 새로운 기능을 선보이고 있고, 커뮤니티도 활발하게 운영되죠. 앞으로 데이터 파이프라인의 복잡성은 더 증가할 것으로 보여, Airflow 같은 워크플로우 관리 도구의 중요성도 커질 것입니다. 이번 글을 통해 Airflow를 이해할 수 있는 기회가 될 수 있길 바랍니다.

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.