Skip to content
←

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

한국어
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

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

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

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

  • 파이프라인이 Git으로 관리된다
  • 변경은 PR + 리뷰 + CI 테스트를 거친다
  • 데이터 모델은 타입·제약·테스트를 갖는다
  • 장애는 OpenLineage·데이터 계약으로 예방된다

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

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

1.1 2가지 축

  • 데이터 변환(Transformation) vs 워크플로우 오케스트레이션
  • SQL 중심 vs 코드(Python) 중심

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 정체성

  • SQL로 데이터 변환을 코드처럼 관리
  • 의존성 그래프·테스트·문서 자동 생성
  • Snowflake/BigQuery/Databricks/Redshift/Postgres/DuckDB 등 어댑터

2.2 핵심 개념

  • Model: SELECT 문으로 정의된 테이블/뷰
  • Source: 외부 시스템 데이터 정의
  • Seed: CSV 데이터 적재
  • Snapshot: SCD Type 2
  • Test: 컬럼·모델 단위 검증(not_null, unique, accepted_values, 관계)
  • Macro: Jinja로 재사용 로직

2.3 의존성 관리

-- models/fact_orders.sql
SELECT *
FROM {{ ref('stg_orders') }}
JOIN {{ ref('dim_customers') }} USING (customer_id)
  • ref()·source()로 의존성 선언
  • DAG 자동 생성 → 올바른 순서 실행
  • dbt build로 전체 파이프라인

2.4 2024–2025 동향

  • dbt Cloud: IDE·스케줄·환경·협업 SaaS
  • dbt Semantic Layer / MetricFlow: 지표 중앙화
  • dbt Mesh: 여러 프로젝트 연합
  • dbt-fusion 엔진 발표(2024): 성능·개발 경험 개선

2.5 한계

  • 증분(incremental) 로직이 복잡해질수록 유지 힘듦
  • 상태 추적이 약함(런 이력·변경 감지)
  • Jinja 매크로가 디버깅 어려움
  • 대규모 프로젝트에서 빌드 시간 문제

2.6 쓰는 곳

  • 거의 모든 모던 데이터 팀의 기본값
  • BI·ML feature 모델링

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

3.1 정체성

  • 2022년 등장, 2024년 주목 받음
  • dbt의 약점(증분·버전·테스트)을 개선
  • Tobiko Data가 상용 지원

3.2 핵심 차별점

  • Virtual environments: 변경을 가상 환경에서 미리 테스트
  • Automatic incremental: 증분 로직 자동화
  • State tracking: 모델 버전 + 변경 영향 분석
  • Backfill: 과거 데이터 재처리 워크플로우 내장
  • dbt 호환: 기존 dbt 프로젝트 import 가능

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 한계

  • 생태계·커뮤니티는 아직 dbt 대비 작음
  • 커넥터·어댑터 수 제한
  • 학습 자료·예시 부족

3.6 쓰는 곳

  • 증분·버전·backfill 중심 팀
  • dbt의 한계로 고통받는 중대형 팀
  • 새로 시작하는 팀의 대안 옵션

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

4.1 정체성

  • 2018 Elementl → Dagster Labs
  • 데이터 에셋(Asset) 중심 모델
  • Airflow의 task 중심에서 한 단계 나아감

4.2 핵심 차이

  • Task DAG (Airflow): "A 실행 후 B 실행"
  • Asset DAG (Dagster): "이 테이블을 만드는 함수" + 의존성 자동
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 강점

  • 파이프라인이 데이터 자산의 집합으로 모델링됨
  • 물질화 상태·freshness·메타 정보가 1등급 개념
  • dbt·Fivetran·Hightouch 등 통합 풍부
  • 로컬 개발 경험 우수

4.4 2024–2025 동향

  • Dagster+: 클라우드 SaaS
  • Dagster Components: 재사용 가능 파이프라인 블록
  • Asset-based scheduling: 신선도 기반 스케줄링
  • AI/ML 파이프라인 통합 강화

4.5 한계

  • 학습 곡선(새 개념)
  • 생태계·플러그인 Airflow 대비 작음
  • 대규모 엔터프라이즈 레퍼런스 축적 중

4.6 쓰는 곳

  • 데이터 제품 중심 팀
  • dbt + Airflow의 "연결부"에서 고통받는 팀
  • 모던 데이터 스택 신규 구축

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

5.1 정체성

  • 2014 Airbnb → Apache
  • Python DAG로 워크플로우 정의
  • 가장 큰 생태계·커뮤니티

5.2 Airflow 2.x

  • TaskFlow API로 Python 함수 직접 태스크화
  • Dynamic task mapping
  • Datasets(데이터 중심 스케줄링)
  • 수백 개 프로바이더(AWS·GCP·Snowflake·dbt·Databricks 등)

5.3 Airflow 3.0 (2024–2025)

  • 아키텍처 대개편(Task Execution Interface, Task SDK)
  • 언어 무관 태스크 실행(Python 외)
  • DAG Versioning
  • 더 나은 UI·보안·멀티 테넌시

5.4 관리형 옵션

  • Astronomer (Astro)
  • AWS MWAA
  • GCP Cloud Composer
  • Azure Data Factory managed Airflow

5.5 강점

  • 어디서나 돌아감, 수많은 프로바이더
  • 엔터프라이즈 검증 완료
  • 범용 오케스트레이션(데이터 외 작업도)

5.6 한계

  • Task 중심(데이터 자산 추적 약함) — Datasets로 완화 중
  • 스케일 시 복잡(Celery/Kubernetes Executor 튜닝)
  • UI·개발 경험이 Dagster·Prefect 대비 무겁다는 평

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

6.1 정체성

  • 2018 Prefect → Prefect Cloud
  • Airflow 대안으로 출발
  • Python-native, 동적 워크플로우

6.2 Prefect 2.x → 3.0

  • 2024 Prefect 3.0 출시
  • 성능·UI·보안 대대적 개선
  • Flow·Task 추상화
  • 비동기 기본, 동적 그래프 자연스러움

6.3 강점

  • Python 코드가 워크플로우 자체
  • 로컬·클라우드 동일 경험
  • 스케줄·재시도·경보 단순

6.4 한계

  • 생태계가 Airflow 대비 작음
  • 엔터프라이즈 레퍼런스 축적 중
  • dbt·ML 통합은 Dagster가 강점

6.5 쓰는 곳

  • Python 엔지니어 중심 팀
  • 동적 파이프라인(파라미터·런타임 결정)
  • 스타트업·중견

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

7.1 정체성

  • 2020 Uber Cadence에서 포크
  • 장기 실행·상태 머신·신뢰성 중심
  • 일반 워크플로우(결제·주문) + 데이터 워크플로우

7.2 Airflow와의 차이

  • Airflow: 배치 ETL·주기적 실행
  • Temporal: 이벤트 기반·장기 실행·사용자 주도 워크플로우

7.3 쓰는 곳

  • LLM Agent 오케스트레이션(2024–2025 확대)
  • 주문·결제·배송 상태 머신
  • 사용자 여정 워크플로우

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

8.1 무엇인가

  • 데이터 생산자와 소비자 간의 스키마·SLA·소유자 명시 합의
  • 코드 API contract의 데이터 버전
  • 2022–2025 부상한 개념

8.2 구성

  • Schema: 컬럼·타입·제약
  • SLA: freshness, completeness, uniqueness
  • Owner: 데이터 팀·서비스 팀
  • Lifecycle: 변경 정책, 버전, deprecation

8.3 도구

  • Soda: 데이터 품질 + 계약
  • Schemata / Monte Carlo / Metaplane / Datafold: 관측성 + 계약
  • OpenLineage: 계보 표준
  • dbt Contracts: dbt 모델에 계약 선언
  • Great Expectations: 검증 표준

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 운영

  • PR에서 계약 변경 리뷰
  • Breaking change → 버전업 + deprecation 공지
  • 소비자 테이블에서 계약 위반 시 자동 경보

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

9.1 Git·브랜치 전략

  • main: 프로덕션 파이프라인
  • dev: 개발 환경
  • Feature branch → PR → 리뷰 → CI 통과 → 머지

9.2 CI 단계

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

9.3 환경 분리

  • Dev / Staging / Prod의 데이터 세트 분리
  • 접근 권한 엄격 구분
  • Staging에서 Prod 일부 샘플 사용 가능

9.4 배포 전략

  • Blue-Green (테이블 새 버전 + 스위치)
  • Canary (일부 사용자/쿼리만 새 버전)
  • Shadow (새 버전을 계산만, 비교)
  • 롤백 계획

9.5 관측성 통합

  • 배포 후 신선도·실패·지연 모니터링
  • 경보 → Slack·PagerDuty
  • 사고 후 Postmortem

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

10.1 5대 기둥(Monte Carlo)

  • Freshness: 데이터가 최신인가
  • Volume: 행 수가 정상인가
  • Schema: 컬럼·타입 바뀌었는가
  • Quality: 값의 분포·결측
  • Lineage: 상·하류 의존성

10.2 도구 지형

  • Monte Carlo, Metaplane, Bigeye, Anomalo: SaaS 관측성
  • Datafold: 배포 전 데이터 diff
  • Great Expectations: 오픈소스 검증
  • Soda: 오픈 + 상용
  • OpenLineage + Marquez: 계보 표준

10.3 경보 설계

  • Severity 등급: P1(파이프라인 전면 정지) / P2(지연) / P3(품질)
  • 스로틀링: 동일 경보 반복 방지
  • 온콜 로테이션: 데이터 팀 최소 2인

10.4 SLO

  • 파이프라인별 신선도·성공률 SLO
  • 월간 에러 버짓 관리
  • 위반 시 배포 동결·리뷰

11장 · 실제 스택 조합 5종

11.1 Startup (소규모)

  • 저장: BigQuery / Snowflake
  • 변환: dbt
  • 오케스트레이션: dbt Cloud 스케줄 or GitHub Actions
  • 관측성: dbt tests + Elementary

11.2 Scale-up

  • 저장: Snowflake / Databricks + Iceberg
  • 변환: dbt + SQLMesh 일부
  • 오케스트레이션: Dagster or Airflow
  • 관측성: Monte Carlo / Metaplane

11.3 Data-heavy SaaS

  • 저장: Iceberg + ClickHouse
  • 스트리밍: Flink/RisingWave
  • 변환: dbt + Spark
  • 오케스트레이션: Dagster
  • 관측성: Datadog + OpenLineage

11.4 Enterprise

  • 저장: Snowflake/Databricks + Iceberg
  • 변환: dbt + 커스텀
  • 오케스트레이션: Airflow (Astronomer) + Dagster 일부
  • 계약: OpenLineage + Monte Carlo
  • 거버넌스: Unity/Polaris + Collibra

11.5 한국 금융·공공

  • 저장: 온프레 Iceberg + StarRocks / Snowflake Private
  • 변환: dbt (개발) + Spark (프로덕션)
  • 오케스트레이션: Airflow on Kubernetes
  • 보안·감사: 자체 구축 + Ranger/OPA

12장 · 한국 기업 실무 팁

12.1 채용·조직

  • Analytics Engineer 직무 채택 증가(카카오·토스·당근·쿠팡 등)
  • 데이터 엔지니어 + 분석 엔지니어 + 데이터 사이언티스트 3층
  • 팀 규모 5인 이상일 때 도구 스택 표준화 필요

12.2 도구 도입 순서

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

12.3 언어·로케일

  • 한국어 컬럼명은 지양(호환성 이슈)
  • 타임존은 UTC 저장, 분석 시 KST 변환
  • 공휴일·주말 로직 별도 관리

12.4 보안·감사

  • PII 탐지·마스킹 파이프라인
  • 접근 로그 장기 보관
  • 배포 이력 감사 추적 가능

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가지

  • 모든 변환 코드가 Git에 있다
  • PR + 리뷰 + CI가 표준
  • dbt tests (또는 동급) 커버리지 70%+
  • 신선도·볼륨·스키마 경보 설정
  • 데이터 계약·소유자 문서화
  • 환경 분리(Dev/Staging/Prod)
  • 계보(Lineage) 자동 추적
  • SLO/SLA 정의와 모니터링
  • 온콜 로테이션
  • 롤백·백필 플레이북
  • 비용 대시보드(쿼리·스토리지)
  • 온보딩 문서·교육 자료

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

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

  • Semantic Layer의 역사와 재발견
  • dbt Semantic Layer / MetricFlow
  • Cube / AtScale / Looker의 의미론
  • Metrics Store 패턴
  • Headless BI(Transform, Lightdash)
  • Reverse ETL (Hightouch, Census, Grouparoo): 분석 데이터를 운영 도구로
  • Data activation 전략
  • 소프트웨어 엔지니어링과의 경계 소멸
  • 한국 기업의 Semantic Layer 성숙도
  • AI와 Semantic Layer의 만남

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

다음 글에서 만나자.

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

현재 단락 (1/272)

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

작성 글자: 0자원문 글자: 7,846자작성 단락: 0/272