LabHub

블로그

데이터 플랫폼의 현대 — Lakehouse·Iceberg·dbt·Airflow·Dagster·Flink·DuckDB·ClickHouse·Snowflake·Databricks 심층 가이드 (2025)

2026-04-15 · 19 분 읽기 · #data-platform#lakehouse#iceberg#dbt#airflow#dagster#flink#duckdb#clickhouse#snowflake#databricks

2025년 데이터 스택은 어떻게 여기까지 왔는가

Hadoop은 죽었다. 정확히는 HDFS + MapReduce라는 원형이 죽었다. 2010년대 중반 Hadoop 생태계가 데이터의 중심이었지만, 클라우드 오브젝트 스토리지(S3/GCS/ABFS)의 등장과 "compute와 storage를 분리"라는 클라우드 네이티브 원리가 판을 뒤엎었다. 그 자리를 Lakehouse가 차지했고, Snowflake·Databricks·BigQuery라는 삼두 체제가 굳었다. 한편 작은 데이터·빠른 분석에선 DuckDB와 ClickHouse가 파괴적 성장을 이뤘다. 스트리밍은 Kafka + Flink + Materialize 조합이 표준화됐고, 변환은 dbt가 de facto. 거버넌스는 Data Contracts와 Semantic Layer로 재편됐다.

그 위에 LLM의 물결이 얹혔다. Feature Store는 Vector DB와 경쟁·통합하고, Embedding Pipeline은 데이터 엔지니어의 일상 업무가 됐다. "데이터 엔지니어"와 "ML 엔지니어"의 경계가 2024~2025년 빠르게 흐려졌다.

이 글은 그 2025년 데이터 플랫폼의 지형을 그린다.

이 글은 앞선 Platform Engineering 가이드의 쌍둥이 편이다. 애플리케이션을 굴리는 플랫폼이 있다면, 의사결정을 굴리는 건 데이터 플랫폼이다.

1부. Modern Data Stack의 10년 역사 — 1분 요약

각 시대는 다음 시대에 의해 완전히 치환되지 않고 층층이 쌓였다. 그래서 대기업 데이터 플랫폼은 항상 "유산과 신기술의 교집합"이다.

2부. Lakehouse — Data Lake + Warehouse의 통합

2.1 왜 Lakehouse인가

2.2 테이블 포맷 전쟁 — Iceberg·Delta·Hudi

2024년 Snowflake Polaris 오픈소스화가 결정적이었다. Iceberg를 "벤더 공통 기반"으로 인정한 사건. 이제 같은 Iceberg 테이블을 Snowflake·Databricks·ClickHouse·DuckDB가 동시에 읽는다.

2.3 Iceberg가 이기는 이유

2.4 Catalog가 새로운 전장

3부. ETL → ELT → ELT++ — dbt와 그 도전자들

3.1 ELT의 우위

3.2 dbt의 지배

3.3 SQLMesh — dbt의 도전자

3.4 Trino·Presto·Starburst

3.5 PyIceberg · Ibis · Polars

4부. Workflow Orchestration — Airflow·Dagster·Prefect·Temporal

4.1 Airflow — 여전히 왕

4.2 Dagster — 현대화의 대표주자

4.3 Prefect

4.4 Temporal for Data

4.5 Mage, Kestra, Windmill, Orchest

5부. Streaming — Kafka + Flink가 표준이 된 이유

Flink가 진짜 스트리밍에서 이겼다. Shopify·Uber·Netflix·Stripe가 Flink로 대전환.

5.3 Streaming SQL — Materialize, RisingWave, Arroyo

5.4 Kafka 대안

5.5 CDC (Change Data Capture)

6부. OLAP — DuckDB·ClickHouse·StarRocks·Pinot의 시대

6.1 DuckDB — 2024년 가장 핫한 DB

6.2 ClickHouse — 초대규모 실시간 OLAP

6.3 StarRocks·Apache Doris

6.4 Apache Pinot·Druid

6.5 언제 무엇을

7부. Warehouse 삼두 체제 — Snowflake·Databricks·BigQuery

7.1 Snowflake

7.2 Databricks

7.3 BigQuery

7.4 Redshift·Firebolt·Azure Synapse·Fabric

8부. Data Contracts — 생산자·소비자 책임 분담

8.1 문제

8.2 Data Contract 구성

dataContractSpecification: 0.9.3
id: user-events
info:
  title: User Events
  owner: identity-team
  version: 2.1.0
servers:
  production:
    type: kafka
    topic: user.events.v2
schema:
  type: avro
  definition: ...
quality:
  - type: sql
    description: "no null user_id"
    query: "select count(*) from user_events where user_id is null"
    mustBe: 0
sla:
  freshness: "5 minutes"
  availability: "99.9%"

8.3 Shift-Left Data Quality

8.4 Data Mesh와의 관계

9부. Semantic Layer — "Single Source of Truth for Metrics"

9.1 문제

9.2 해답

메트릭 정의를 중앙에서. BI툴·SQL·API가 모두 거기서 계산.

9.3 Headless BI

10부. AI 시대의 데이터 — Feature Store·Vector DB·Embedding Pipeline

10.1 Feature Store

10.2 Vector DB의 정체성

10.3 Embedding Pipeline

10.4 Unstructured Data 인제스천

10.5 Data Warehouse 안에서 LLM

11부. Reverse ETL과 Data Activation

11.1 개념

11.2 도구

11.3 Composable CDP

12부. 거버넌스 — Lineage, Catalog, Privacy

12.1 Data Catalog

12.2 Column-level Lineage

12.3 PII·Privacy

12.4 GDPR·CCPA·EU AI Act

13부. 실전 — 데이터 플랫폼 구축 로드맵

13.1 시드 ~ 시리즈 A

13.2 시리즈 B~C

13.3 엔터프라이즈

13.4 AI 기능 추가 로드맵

14부. 체크리스트 12 · 안티패턴 10

✅ 체크리스트 12

  1. Lakehouse 테이블 포맷(Iceberg 권장)이 표준화됐는가?
  2. dbt/SQLMesh로 변환이 버전 관리되는가?
  3. 변환 DAG에 data tests가 붙어 있는가?
  4. Airflow/Dagster로 schedule + retry + backfill이 자동인가?
  5. CDC로 운영 DB가 실시간 동기되는가?
  6. Data Contract가 도메인 간 인터페이스에 있는가?
  7. Semantic Layer가 핵심 지표 정의를 중앙화했는가?
  8. Catalog + Lineage가 가시화됐는가?
  9. PII 마스킹·접근 제어가 엔진 수준에 있는가?
  10. 핫 테이블에 파티셔닝·Z-order가 적용됐는가?
  11. 비용 대시보드가 팀별 쿼리/스토리지 비용을 보여주는가?
  12. AI 통합(Vector, LLM 함수)이 플랫폼의 일등 시민인가?

⚠️ 안티패턴 10

  1. Snowflake/Databricks 비용 모니터링 없이 사용
  2. SELECT *를 BI에서 무제한 허용 → 비용 폭발
  3. 파이프라인이 schedule-only — 실패 복구 수동
  4. 파티셔닝 없는 다중 TB 테이블 스캔
  5. PII가 마스킹 없이 warehouse에 평문
  6. dbt 테스트 0개
  7. 운영 DB 직접 쿼리 허용 (OLTP 부하)
  8. Kafka 토픽 스키마 없이 JSON 자유 필드 — 컨트롤 불가
  9. Data Contract 없이 "producer가 바뀌면 consumer가 터짐" 반복
  10. AI 피쳐를 training/serving에서 따로 구현 → skew

다음 글 예고 — "DevEx의 프런트라인: 코드 리뷰·GitHub·Mergeflow·Monorepo·Merge Queue·AI 리뷰" — 엔지니어 일상 업무의 품질을 결정하는 코드 리뷰/머지 파이프라인

데이터까지 왔다면 이제 다시 엔지니어의 일상으로 돌아가 본다. 코드 리뷰라는, 우리 모두가 매일 하면서 가장 언급 적게 하는 활동.

일상의 습관이 팀의 속도를 만든다. 다음 글에서 그 일상을 해부한다.

원문 보기: https://www.youngju.dev/blog/culture/2026-04-15-data-platform-lakehouse-iceberg-dbt-airflow-dagster-flink-duckdb-clickhouse-snowflake-databricks-deep-dive-guide-2025

댓글

아직 댓글이 없습니다.

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