⚙️ Airflow/dbt를 활용한 ETL 파이프라인 기초(데이터를 흐르게 만드는 구조의 시작)

🎯 들어가며

데이터를 단순히 “수집해서 저장”하는 것만으로는 충분하지 않습니다.
시간이 지나면서 데이터는

• 불필요한 중복이 생기고,
• 컬럼 구조가 바뀌고,
• 새로운 데이터가 섞이고,
• 정제되지 않은 상태로 쌓이게 됩니다.

결국 데이터가 많아질수록, “신뢰할 수 있는 분석용 데이터”를 유지하기가 어려워집니다.

그래서 필요한 게 바로 ETL 파이프라인(Extract, Transform, Load) 입니다.
이번 글에서는 그 개념과 함께, 실무에서 많이 쓰이는 두 도구 Airflow와 dbt를 중심으로
ETL 구조를 어떻게 설계할 수 있는지에 대한 내용을 정리했습니다.

---

🧩 1. ETL이란 무엇인가

ETL은 데이터를 “흐르게 만드는 기본 구조”입니다.
단어 그대로,

Extract (추출) — 데이터를 여러 곳에서 모으고
Transform (변환) — 분석 가능한 형태로 가공하고
Load (적재) — 정제된 데이터를 최종 저장소로 옮기는 과정

입니다.

단계	설명	예시
Extract	데이터 원천에서 가져오기	API, CSV, 구글 시트, 로그, DB 등
Transform	데이터 정제 및 구조화	중복 제거, 형식 변환, 컬럼 가공
Load	분석용 저장소에 저장	BigQuery, Snowflake, Redshift 등

 

핵심은 ETL은 ‘데이터가 흘러가는 루틴’을 만든다는 점입니다.
수작업이 아니라, 시스템이 주기적으로 데이터를 준비하도록 만드는 구조라고 생각하면 됩니다.

---

🧱 2. 왜 Airflow와 dbt인가?

ETL을 구성하는 방법은 다양하지만,
Airflow와 dbt는 서로 역할이 명확하게 다르면서도 잘 맞는 조합입니다.

 

도구	역할	핵심 포인트
Airflow	전체 워크플로(파이프라인)의 “스케줄러”	여러 작업(Task)을 순서대로 자동 실행
dbt (data build tool)	데이터 변환(Transform) 담당	SQL 기반으로 데이터 모델링 및 버전 관리

 

• Airflow는 “언제, 어떤 순서로 작업할지”를 관리하고
• dbt는 “데이터를 어떻게 변환할지”를 정의합니다.

---

🔄 3. Airflow로 데이터 흐름 설계하기

Airflow는 ‘데이터 작업(Task)의 흐름’을 DAG(Directed Acyclic Graph) 로 표현합니다.

개념 요약

• Task: 데이터 작업 단위 (예: “데이터 불러오기”, “정제하기”)
• DAG: Task들의 연결 구조 (A → B → C 순서로 실행)
• Operator: 각 Task가 실제로 수행할 동작 (PythonOperator, BashOperator 등)

예시 코드 (간단한 DAG)

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

def extract_data():
    print("데이터 추출 완료")

def transform_data():
    print("데이터 정제 완료")

def load_data():
    print("데이터 적재 완료")

with DAG(
    dag_id='simple_etl_pipeline',
    start_date=datetime(2025, 1, 1),
    schedule_interval='@daily',
    catchup=False
) as dag:
    extract = PythonOperator(task_id='extract', python_callable=extract_data)
    transform = PythonOperator(task_id='transform', python_callable=transform_data)
    load = PythonOperator(task_id='load', python_callable=load_data)

    extract >> transform >> load

💡 이 DAG는 매일 자동으로 extract → transform → load 순서로 실행됩니다.
즉, 데이터 수집·정제·적재의 자동화 루틴이 구성됩니다.

---

 4. dbt로 데이터 변환(Transform) 관리하기

Airflow가 전체 ‘흐름’을 관리한다면, dbt는 그 중간 단계인 Transform (변환) 을 깔끔하게 정리해줍니다.

핵심 개념

• Model: SQL 파일 단위의 변환 로직
• Source: 원본 테이블 정보
• Ref(): 모델 간 의존 관계를 정의
• Jinja 템플릿: SQL 안에서 변수나 조건문을 활용

예시 SQL (dbt 모델)

-- models/cleaned_orders.sql
SELECT
  order_id,
  user_id,
  CAST(order_date AS DATE) AS order_date,
  total_amount,
  CASE
    WHEN total_amount > 100000 THEN 'High Value'
    ELSE 'Normal'
  END AS order_type
FROM {{ source('raw', 'orders') }}
WHERE order_status = 'completed'

 

이 모델은 ‘원본 데이터(raw.orders)’를 불러와 형식을 통일하고, 새로운 컬럼(order_type)을 추가하는 변환을 수행합니다.

💡 dbt의 장점

• 모든 변환이 SQL 파일로 명시되어 버전 관리 가능
• 데이터 계보(Lineage) 자동 생성 (어떤 테이블이 어떤 모델에서 파생됐는지 시각화)
• 테스트·문서화 기능 포함

즉, dbt는 “데이터 변환을 코드로 관리하는 문화”를 만들어줍니다.

---

🔗 5. Airflow + dbt 결합 구조

현실적인 데이터 파이프라인은 밑과 같이 동작합니다.

[데이터 소스] → [Airflow - Extract 단계] 
                ↓
              [dbt - Transform 단계]
                ↓
        [Airflow - Load 단계 (BigQuery)]

Airflow가 dbt 실행 명령을 관리하면서,
전체 파이프라인을 하나의 자동화된 DAG로 통합할 수 있습니다.

• Airflow가 스케줄링과 실행을 담당
• dbt가 SQL 변환과 모델 관리 담당

---

6. 데이터 파이프라인을 설계할 때 기억할 점

1. 모든 데이터는 목적이 있을 것.
   → “이 데이터를 왜 가공하는가?”를 명확히 정의해야 불필요한 모델이 생기지 않음.
2. 단계별로 로그를 남길 것.
   → ETL은 실패 지점을 찾아야 개선이 가능함.
3. 데이터 계보(Lineage)를 시각화할 것.
   → dbt의 Lineage 그래프는 구조적 사고를 훈련시키는 도구이기도 함.
4. 점진적 개선이 핵심.
   → 처음엔 간단한 DAG 하나로 시작해, 점차 자동화 범위를 확장하는 게 현실적.

---

☕ 마무리하며

Airflow와 dbt를 알아보면서 가장 크게 느낀 건,

“데이터 엔지니어링은 코딩보다 구조 설계의 문제” 라는 점이었습니다.

단순히 파이썬으로 데이터를 옮기는 게 아니라, 데이터가 언제, 어떻게, 왜 변환되는지를 명확히 관리할 수 있는 구조를 만드는 게 핵심인 영역인 것 같습니다.

이번 글은 그 구조를 이해하기 위한 기초 다지기 단계로, 앞으로 “데이터 품질 관리”, “자동화 모니터링”, “ML 파이프라인 확장”으로 이어질 수 있는 기반이 됩니다.

결국 ETL은 “데이터가 살아 움직이게 하는 생명줄”이라고 할 수 있을 것 같습니다.