> **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 / 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 단계
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년은 다르다: