LabHub

블로그

데이터 오케스트레이션 2025 완전 가이드: dbt·SQLMesh·Dagster·Airflow·Prefect, 데이터 계약, CI/CD (2025)

2026-04-15 · 18 분 읽기 · #data-orchestration#dbt#sqlmesh#dagster#airflow#prefect#data-contracts#data-observability#deep-dive#series

한국어English日本語中文

Season 5 Ep 4 — Ep 3이 "누가 빨리 쿼리하나"였다면 Ep 4는 "누가 파이프라인을 다스리나". 2025년 데이터 오케스트레이션은 엔지니어링 원칙(CI/CD·테스트·계약)이 데이터에 이식되는 중.

Prologue — "데이터 파이프라인도 소프트웨어다"

2010년대 데이터 엔지니어링은 "SQL 스크립트 + cron"이었다. 2025년은 다르다:

이 변화는 Analytics Engineer라는 새 직무를 만들었고, dbt가 그 중심에 섰다. 그러나 2025년은 dbt만이 아니다 — SQLMesh·Dagster가 실질적 대안으로, Airflow·Prefect는 여전히 범용 오케스트레이션의 왕좌를 지킨다.

1장 · 오케스트레이션 도구 분류

1.1 2가지 축

1.2 주요 도구

도구주 역할철학
dbt Core / CloudSQL 변환Analytics Engineer 표준
SQLMeshSQL 변환버전·증분·상태
Dagster오케스트레이션Asset-centric
Airflow 2/3오케스트레이션Task DAG, 범용
Prefect 3오케스트레이션Pythonic, 동적
Temporal워크플로우신뢰성·상태 머신
Mage, Kestra오케스트레이션새 세대

2장 · dbt — Analytics Engineer 표준

2.1 정체성

2.2 핵심 개념

2.3 의존성 관리

-- models/fact_orders.sql
SELECT *
FROM {{ ref('stg_orders') }}
JOIN {{ ref('dim_customers') }} USING (customer_id)

2.4 2024–2025 동향

2.5 한계

2.6 쓰는 곳

3장 · SQLMesh — "dbt의 대안인가 보완인가"

3.1 정체성

3.2 핵심 차별점

3.3 철학

"dbt의 생산성 + 데이터 웨어하우스의 엄격함 + 데브옵스의 안전망"

3.4 예시 — 증분 모델

MODEL (
  name core.fact_orders,
  kind INCREMENTAL_BY_TIME_RANGE (
    time_column order_date,
  ),
);

SELECT *
FROM raw.orders
WHERE order_date BETWEEN @start_date AND @end_date;

→ SQLMesh가 증분 처리·백필·캐시를 자동 관리.

3.5 한계

3.6 쓰는 곳

4장 · Dagster — "Asset-centric 혁명"

4.1 정체성

4.2 핵심 차이

from dagster import asset

@asset
def orders(raw_data):
    return transform(raw_data)

@asset
def customer_lifetime_value(orders, customers):
    return compute_clv(orders, customers)

4.3 강점

4.4 2024–2025 동향

4.5 한계

4.6 쓰는 곳

5장 · Airflow — "여전히 가장 널리 쓰이는"

5.1 정체성

5.2 Airflow 2.x

5.3 Airflow 3.0 (2024–2025)

5.4 관리형 옵션

5.5 강점

5.6 한계

6장 · Prefect — "Pythonic 오케스트레이션"

6.1 정체성

6.2 Prefect 2.x → 3.0

6.3 강점

6.4 한계

6.5 쓰는 곳

7장 · Temporal — "워크플로우 엔진의 다른 계보"

7.1 정체성

7.2 Airflow와의 차이

7.3 쓰는 곳

8장 · 데이터 계약(Data Contracts)

8.1 무엇인가

8.2 구성

8.3 도구

8.4 예시 (dbt Contract)

models:
  - name: dim_customers
    config:
      contract:
        enforced: true
    columns:
      - name: customer_id
        data_type: bigint
        constraints: [{type: primary_key}, {type: not_null}]
      - name: email
        data_type: varchar
        constraints: [{type: not_null}]

8.5 운영

9장 · 데이터 파이프라인 CI/CD

9.1 Git·브랜치 전략

9.2 CI 단계

  1. Lint(sqlfluff, dbt lint)
  2. 컴파일(dbt compile, SQLMesh plan)
  3. 유닛 테스트(모델 단위 샘플)
  4. 계약 검증
  5. Staging 환경에 부분 실행
  6. 통계 diff(Datafold 등)

9.3 환경 분리

9.4 배포 전략

9.5 관측성 통합

10장 · 관측성(Observability)과 경보

10.1 5대 기둥(Monte Carlo)

10.2 도구 지형

10.3 경보 설계

10.4 SLO

11장 · 실제 스택 조합 5종

11.1 Startup (소규모)

11.2 Scale-up

11.3 Data-heavy SaaS

11.4 Enterprise

11.5 한국 금융·공공

12장 · 한국 기업 실무 팁

12.1 채용·조직

12.2 도구 도입 순서

  1. dbt + 스케줄(간단히)
  2. 테스트·문서 확대
  3. 오케스트레이션(Airflow/Dagster)
  4. 관측성(Monte Carlo/Metaplane)
  5. 계약(dbt Contracts/Soda)

12.3 언어·로케일

12.4 보안·감사

13장 · 안티패턴 10선

13.1 "cron + SQL" 그대로

Git·테스트·문서 부재 → 사고 빈발.

13.2 테스트 없는 dbt

모델 수백 개 → 회귀 폭증.

13.3 증분 로직 손으로

dbt에서 손 증분 → 유지 악몽. SQLMesh 검토.

13.4 Airflow DAG 모놀리식

1개 DAG에 100개 태스크 → 장애 전파.

13.5 Dagster·Prefect·Airflow 동시 운영

한 회사에 3개는 오버엔지니어링.

13.6 계약 없이 소비자 다수

한 변경이 다섯 팀을 깨뜨림.

13.7 관측성 후순위

사고를 사용자가 먼저 발견.

13.8 CI 없이 Prod 직접 배포

PR 리뷰 생략 → 말 못하는 실수.

13.9 환경 분리 없음

Dev에서 Prod 데이터 수정 사고.

13.10 문서 자동 생성만 믿기

자동 문서는 구조만 보여줌. 비즈니스 설명은 사람이.

14장 · 체크리스트 — 데이터 파이프라인 성숙도 12가지

15장 · 다음 글 예고 — Season 5 Ep 5: "Semantic Layer·Metrics Store·Reverse ETL"

파이프라인이 데이터를 만든다면, Semantic Layer는 말한다. Ep 5는 데이터를 비즈니스 언어로 연결하는 축.

"데이터의 의미를 한 번만 정의한다"는 약속의 2025년 버전.

다음 글에서 만나자.

요약: 2025년 데이터 오케스트레이션은 "파이프라인도 소프트웨어" 원칙이 완성되는 단계. dbt가 변환의 표준이 됐고, SQLMesh가 증분·버전으로 보완하며, Dagster가 asset-centric 오케스트레이션으로 등장했다. Airflow는 3.0 대개편으로 재도약, Prefect 3.0은 Pythonic 대안. 데이터 계약과 관측성이 엔지니어링 품질을 밀어 올리고, CI/CD + SLO + 온콜이 데이터 팀의 일상이 됐다. 스택은 규모·맥락에 따라 달라지되, 핵심 원칙은 "Git · 테스트 · 계약 · 관측성 · 롤백" 다섯 단어로 요약된다. 다음 편은 이 모든 것 위에 "비즈니스 언어로 말하는 층".

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다