데이터 엔지니어링 완전 가이드 — Lakehouse·Streaming·dbt·Orchestration·Data Mesh (Season 2 Ep 8, 2025)

들어가며 — 데이터 엔지니어의 2025년 기대치

10년 전 데이터 엔지니어는 "ETL 스크립트 작성 + Hadoop 운영"이었다. 2025년의 기대치:

• Lakehouse 설계: Iceberg/Delta/Hudi 중 선택·운영
• Streaming + Batch 통합: Lambda는 가고 Kappa, 이제 진짜 통합
• Modern Data Stack: dbt + Airflow/Dagster + Fivetran/Airbyte + BigQuery/Snowflake
• Data Mesh: 중앙 집중 vs 분산 조직 모델
• Data Contract: Protobuf 같은 스키마 계약
• AI/ML 연계: MLOps와의 접점, Feature Store, Vector DB
• 비용 관리: 클라우드 데이터 비용 통제 (FinOps)

이 글은 2025년 데이터 엔지니어의 사고 프레임을 한 편에 담는다.

1부 — Lakehouse: Data Lake + Data Warehouse의 통합

1.1 역사적 맥락

Lakehouse 정의: 오브젝트 스토리지(S3, GCS, ADLS) + 테이블 포맷(Iceberg 등) + 쿼리 엔진(Spark, Trino, DuckDB) 조합으로 Warehouse급 ACID와 성능 제공.

1.2 세 가지 테이블 포맷 비교 (2024~2025)

2024년 결정적 사건: Databricks가 Tabular(Iceberg 창업사)를 인수 → Iceberg와 Delta 통합 방향.

2025 추천: 새 프로젝트는 Iceberg. Databricks 환경이면 Delta도 OK.

1.3 Iceberg 기본 구조

Metadata (JSON):
  ↓
Manifest List (Avro):
  ├─ Manifest 1 (Avro)
  │   └─ Data Files (Parquet)
  ├─ Manifest 2
  │   └─ Data Files
  └─ ...

• Snapshot: 특정 시점 상태 (시간 여행 가능)
• Partition Evolution: 파티션 스키마 변경 가능
• Hidden Partitioning: 사용자가 WHERE year=2025 써도 내부 파티션 자동 사용

1.4 Lakehouse 쿼리 엔진 2025

2부 — Streaming: Kappa 아키텍처의 승리

2.1 Lambda vs Kappa

Lambda (2010s):

• Batch Layer (정확) + Speed Layer (빠름) + Serving Layer
• 문제: 같은 로직을 두 번 구현 → 유지보수 지옥

Kappa (2014, Jay Kreps):

• Streaming만. 재처리 필요하면 스트림 재시작
• 2025년 표준

2.2 2025 Streaming 엔진

2.3 Streaming 핵심 개념 10

1. Event Time vs Processing Time: 이벤트 발생 시각 vs 시스템 처리 시각
2. Watermark: "이 시간까지의 이벤트는 다 왔다" 신호
3. Windowing: Tumbling, Sliding, Session
4. Stateful Processing: 상태를 유지하며 처리
5. Exactly-Once: 정확히 한 번 처리 보장
6. Backpressure: 하류가 느릴 때 상류 속도 조절
7. Checkpointing: 장애 복구 지점
8. Join: Stream-Stream, Stream-Table
9. CDC (Change Data Capture): DB 변경 → 스트림
10. Deduplication: 중복 제거

2.4 CDC — 현대 데이터 통합의 핵심

PostgreSQL/MySQL → Debezium → Kafka → Flink/Spark → Iceberg

장점: 배치 ETL 제거, 실시간에 가까운 동기화. 도구: Debezium (오픈소스), Fivetran, Airbyte.

2.5 2025 실시간 데이터 플랫폼 예시

[Kafka] → [Flink SQL] → [Iceberg (bronze/silver/gold)] → [Trino/DuckDB]
                   ↓
              [Materialize] (실시간 대시보드)
                   ↓
              [Redis] (저지연 서빙)

3부 — Medallion Architecture: Bronze/Silver/Gold

3.1 3계층 구조

1. Bronze (Raw): 원본 그대로. 스키마 변화 흡수.
2. Silver (Cleansed): 정제·검증·중복 제거·스키마 통일.
3. Gold (Business): 비즈니스 도메인별 집계, BI/ML 바로 쓸 수 있는 형태.

3.2 각 계층의 책임

3.3 장점

• 재처리 가능 (Bronze 보존)
• 계약 명확 (Silver = 표준 스키마)
• 비즈니스 로직 분리 (Gold)

4부 — dbt: Analytics Engineering의 표준

4.1 dbt란

"SQL로 데이터 모델링을 소프트웨어 엔지니어링처럼" — 버전 관리, 테스트, 문서화, 의존성 그래프.

4.2 핵심 구성 요소

models/
  staging/
    stg_orders.sql        -- Bronze -> Silver 수준
    stg_customers.sql
  marts/
    orders.sql            -- Gold, 비즈니스 로직
    revenue_daily.sql
tests/
  assert_total_revenue.sql
seeds/
  country_codes.csv
macros/
  generate_schema_name.sql

4.3 모델 예제

-- models/marts/orders.sql
{{ config(materialized='table', partition_by={'field': 'order_date', 'data_type': 'date'}) }}

with orders as (
    select * from {{ ref('stg_orders') }}
),
customers as (
    select * from {{ ref('stg_customers') }}
)
select
    o.order_id,
    o.order_date,
    c.country,
    o.amount
from orders o
join customers c using (customer_id)
where o.status = 'completed'

{{ ref('stg_orders') }} — dbt가 의존성 그래프 자동 구축.

4.4 Test와 Documentation

# schema.yml
models:
  - name: orders
    description: "완료된 주문 (Gold 레이어)"
    columns:
      - name: order_id
        tests:
          - unique
          - not_null
      - name: amount
        tests:
          - dbt_utils.expression_is_true:
              expression: ">= 0"

dbt test  # 모든 테스트 실행
dbt docs generate && dbt docs serve  # 문서 사이트

4.5 2025 dbt 생태계

• dbt Core: 오픈소스 CLI
• dbt Cloud: 상용 SaaS (IDE·스케줄링)
• dbt-osmosis: 메타데이터 자동 전파
• Elementary: 데이터 품질·옵저버빌리티
• SQLMesh: dbt 대안, 더 강력한 의존성 관리
• Dagster + dbt 통합: 오케스트레이션 강화

5부 — Orchestration: Airflow vs Dagster vs Prefect vs Temporal

5.1 2025 비교

5.2 Dagster의 철학: "Data-aware Orchestration"

Airflow는 "태스크"를 관리. Dagster는 "Asset"(데이터 결과물)을 관리.

from dagster import asset

@asset
def raw_orders():
    return fetch_from_postgres("orders")

@asset
def cleaned_orders(raw_orders):
    return raw_orders.dropna()

@asset
def revenue_by_day(cleaned_orders):
    return cleaned_orders.groupby("date").sum()

의존성·스키마·타입이 명시적. 실행 그래프 = Asset 그래프.

5.3 Airflow 2.x의 개선

• TaskFlow API (Pythonic)
• Dynamic Task Mapping
• Dataset Triggering (Dagster에 영감)
• Airflow 3.0 (2025 예정): 데이터 중심 개편

6부 — Data Mesh: 조직의 데이터 아키텍처

6.1 배경

중앙집중 데이터 팀의 한계:

• 도메인 지식 부족
• 병목 (한 팀이 전체 요청 처리)
• 우선순위 충돌

6.2 Data Mesh 4원칙 (Zhamak Dehghani, 2019)

1. Domain Ownership: 데이터는 도메인 팀이 소유 (마케팅 팀이 마케팅 데이터)
2. Data as a Product: 데이터셋 = 제품 (품질·문서·SLA)
3. Self-serve Platform: 중앙 팀은 "플랫폼" 제공 (도메인 팀이 자율 사용)
4. Federated Governance: 중앙 규칙 + 도메인 실행

6.3 Data Mesh 실전 고려사항

잘 될 때:

• 조직 규모 500+ 엔지니어
• 도메인 간 명확한 경계
• 플랫폼 엔지니어링 조직 성숙

실패할 때:

• 100명 미만 스타트업 (과공학)
• 도메인 팀 역량 부족
• 중앙 플랫폼 없이 "자유방임"

2025 현실: 이상론에서 실용 조정으로. "Hub-and-Spoke" 혹은 부분 Mesh가 흔함.

7부 — Data Contract: 팀 간 인터페이스

7.1 왜 필요한가

문제: 프론트엔드 팀이 user.full_name을 user.name으로 리네임 → 데이터 파이프라인 100개 깨짐 → 추적 불가.

7.2 Data Contract 정의

스키마 + 의미론 + SLA의 공식 약속. Protobuf나 JSON Schema 같은 형태.

# user_contract.yml
name: user_events
version: 1.2.0
owner: user-platform-team
schema:
  event_id: string (uuid)
  user_id: string
  event_type: enum [signup, login, logout, purchase]
  timestamp: timestamp (UTC)
  properties: map<string, any>
sla:
  freshness: <5 minutes
  availability: 99.9%
  breaking_change_notice: 30 days
consumers:
  - analytics-team
  - ml-team
  - finance-team

7.3 도구 (2024~2025)

• Protobuf + Buf: 엔지니어링 팀 중심
• Great Expectations: 데이터 품질 검증
• dbt Contracts (1.5+): 모델 간 계약
• DataHub: 메타데이터 카탈로그
• Apache Atlas: Hadoop 생태계

7.4 Contract-first 파이프라인

Producer Team                         Consumer Team
  │                                        │
  ├─ Commits schema change to Buf ──→ Review
  │                                        │
  ├─ CI: backward compat check             │
  │                                        │
  ├─ Deploy producer                       │
  │                                        │
  └─ Update event emission ─── Kafka ──→ Update consumer

8부 — Data Quality: 신뢰의 기반

8.1 데이터 품질 6차원

1. 정확성 (Accuracy): 현실 반영
2. 완전성 (Completeness): 결측 없음
3. 일관성 (Consistency): 시스템 간 동일
4. 적시성 (Timeliness): 최신성
5. 유일성 (Uniqueness): 중복 없음
6. 유효성 (Validity): 형식·범위

8.2 Data Observability 5 Pillars (Monte Carlo)

1. Freshness: 언제 마지막 업데이트?
2. Volume: 예상 행 수 범위?
3. Schema: 컬럼·타입 변화?
4. Distribution: 값 분포 변화?
5. Lineage: 어디서 왔고 어디로 가는가?

8.3 2025 도구

• Great Expectations: 오픈소스, 강력
• Soda: SQL 기반, 단순
• Monte Carlo: 상용, ML 기반 이상 감지
• Bigeye: 자동 SLA 학습
• Elementary: dbt 통합

9부 — 모던 데이터 스택 2025

9.1 표준 구성

[Sources]
  ├─ OLTP DBs (Postgres/MySQL)
  ├─ SaaS APIs (Salesforce, Stripe)
  └─ Event Streams (Kafka, Kinesis)
       ↓
[Ingestion]
  ├─ Fivetran / Airbyte (SaaS → Warehouse)
  └─ Debezium (CDC)
       ↓
[Warehouse/Lakehouse]
  ├─ Snowflake / BigQuery / Databricks
  └─ Iceberg on S3 + Trino
       ↓
[Transformation]
  └─ dbt (또는 SQLMesh)
       ↓
[Orchestration]
  └─ Dagster / Airflow
       ↓
[Serving]
  ├─ BI: Looker, Metabase, Hex, Preset
  ├─ ML: Feature Store (Feast)
  └─ Reverse ETL: Census, Hightouch (to SaaS)
       ↓
[Observability]
  ├─ Monte Carlo / Elementary (데이터)
  └─ DataHub (카탈로그)

9.2 2025 새 트렌드

• Semantic Layer: dbt Semantic Layer, Cube, MetricFlow (지표 통일)
• Reverse ETL: Warehouse → CRM·광고 플랫폼
• Zero-copy Cloning: Snowflake·Databricks 데이터 복사 없이 복제
• Open Table Format 수렴: Iceberg 중심 재편
• AI-assisted Data Engineering: 코파일럿이 dbt 모델 초안 작성

10부 — 데이터 엔지니어 로드맵 6개월

Month 1: SQL + 웨어하우스

• PostgreSQL 고급 (window 함수, CTE, recursive)
• dbt 기본 프로젝트

Month 2: 오케스트레이션 + 파이프라인

• Airflow 또는 Dagster
• 스케줄링·의존성·재시도 전략

Month 3: Lakehouse

• Iceberg 또는 Delta 실전
• Trino 또는 DuckDB로 쿼리
• Parquet 튜닝

Month 4: Streaming

• Kafka 기본
• Flink 또는 Spark Streaming
• CDC (Debezium)

Month 5: 품질·관측성

• Great Expectations 또는 Soda
• DataHub 카탈로그
• Data Contract 시도

Month 6: 운영 + ML 연결

• 비용 모니터링 (FinOps)
• Feature Store (Feast)
• Semantic Layer

11부 — 데이터 엔지니어 체크리스트 12

1. Lakehouse 3가지 테이블 포맷 차이를 안다
2. Lambda vs Kappa 아키텍처 차이를 안다
3. Event Time vs Processing Time + Watermark를 설명할 수 있다
4. Medallion (Bronze/Silver/Gold) 각 계층 책임을 안다
5. **dbt의 ref**()로 의존성 그래프가 어떻게 생기는지 안다
6. CDC 파이프라인 구성을 안다
7. Dagster의 Asset vs Airflow의 Task 차이를 안다
8. Data Mesh 4원칙을 말할 수 있다
9. Data Contract가 무엇이고 왜 필요한지 안다
10. 데이터 품질 6차원을 안다
11. Data Observability 5 Pillars를 안다
12. Semantic Layer의 목적을 안다

12부 — 데이터 엔지니어링 안티패턴 10

1. Bronze 없이 Silver로 직접: 재처리 불가. 원본 보존 필수
2. Lambda 아키텍처 고집: 로직 중복. Kappa 전환 고려
3. dbt 없이 SQL 난립: 의존성·테스트·문서화 부재
4. Data Contract 없이 팀 간 데이터 공유: 깨짐·추적 불가
5. 파티션 설계 없이 Parquet: 쿼리 느림. Hidden Partitioning 활용
6. UPSERT를 매 시간 배치: Merge on Read가 안 되면 compaction 필요
7. Airflow DAG에 비즈니스 로직: 오케스트레이션에 상태 저장 ❌. dbt·Flink로 분리
8. 관측성 나중에: 품질 지표 처음부터
9. 파이프라인 실패 시 재시도 전략 없음: 멱등성 설계 필수
10. 비용 모니터링 없음: 클라우드 warehouse 비용 폭주 흔함

마치며 — 데이터 엔지니어링은 "계약의 공학"

소프트웨어 엔지니어링이 "함수와 인터페이스의 공학"이라면, 데이터 엔지니어링은 "스키마와 계약의 공학"이다.

2025년의 본질은 그대로다:

• 신뢰할 수 있는 데이터를 필요한 시점에 필요한 형태로 제공
• 조직의 의사결정·ML·제품이 의존할 수 있는 기반

그러나 도구는 매년 바뀐다. Lakehouse, Streaming, dbt, Dagster, Data Contract — 2020년엔 없던 것들. 2030년엔 또 다른 것들.

핵심은 원리다:

• 데이터의 역사성 (Bronze 보존)
• 스키마 진화 (Contract)
• 처리의 멱등성 (안전한 재시도)
• 관측성 (문제 감지)

이것만 유지되면 도구는 필요에 따라 교체된다.

다음 글 예고 — "Observability 완전 가이드: Metric·Log·Trace·OpenTelemetry·eBPF·SLO"

Season 2 Ep 9는 현대 시스템의 신경계, Observability. 다음 글은:

• Metric·Log·Trace 3축 + Profile 4축 (Pyroscope)
• OpenTelemetry의 진짜 가치
• eBPF와 커널 수준 관측
• SLO·SLI·Error Budget 실전 설계
• Grafana Stack vs Elastic Stack vs Datadog
• 비용 통제 (로그 폭주 막기)

"관측할 수 없으면 운영할 수 없다", 다음 글에서 이어진다.