- Authors
- Name
- Youngju Kim
- @fjvbn20031
Season 5 Ep 4 — Ep 3이 "누가 빨리 쿼리하나"였다면 Ep 4는 "누가 파이프라인을 다스리나". 2025년 데이터 오케스트레이션은 엔지니어링 원칙(CI/CD·테스트·계약)이 데이터에 이식되는 중.
- Prologue — "데이터 파이프라인도 소프트웨어다"
- 1장 · 오케스트레이션 도구 분류
- 2장 · dbt — Analytics Engineer 표준
- 3장 · SQLMesh — "dbt의 대안인가 보완인가"
- 4장 · Dagster — "Asset-centric 혁명"
- 5장 · Airflow — "여전히 가장 널리 쓰이는"
- 6장 · Prefect — "Pythonic 오케스트레이션"
- 7장 · Temporal — "워크플로우 엔진의 다른 계보"
- 8장 · 데이터 계약(Data Contracts)
- 9장 · 데이터 파이프라인 CI/CD
- 10장 · 관측성(Observability)과 경보
- 11장 · 실제 스택 조합 5종
- 12장 · 한국 기업 실무 팁
- 13장 · 안티패턴 10선
- 14장 · 체크리스트 — 데이터 파이프라인 성숙도 12가지
- 15장 · 다음 글 예고 — Season 5 Ep 5: "Semantic Layer·Metrics Store·Reverse ETL"
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 / Cloud | SQL 변환 | Analytics Engineer 표준 |
| SQLMesh | SQL 변환 | 버전·증분·상태 |
| 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 단계
- Lint(sqlfluff, dbt lint)
- 컴파일(dbt compile, SQLMesh plan)
- 유닛 테스트(모델 단위 샘플)
- 계약 검증
- Staging 환경에 부분 실행
- 통계 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 도구 도입 순서
- dbt + 스케줄(간단히)
- 테스트·문서 확대
- 오케스트레이션(Airflow/Dagster)
- 관측성(Monte Carlo/Metaplane)
- 계약(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 · 테스트 · 계약 · 관측성 · 롤백" 다섯 단어로 요약된다. 다음 편은 이 모든 것 위에 "비즈니스 언어로 말하는 층".