Chaos and Order

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

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분 요약

~2015 Hadoop 시대 — HDFS + MapReduce + Hive
2015~2018 Spark 전성기 — Spark on YARN, 메모리 기반
2018~2020 Modern Data Stack — Fivetran/Stitch로 수집, Snowflake로 적재, dbt로 변환, Looker로 조회
2020~2022 Lakehouse — Delta Lake·Iceberg·Hudi로 테이블 포맷 표준 재형성
2022~2024 "대통합" — Snowflake Polaris, Databricks UniForm, BigQuery Iceberg 지원
2024~2025 AI 통합 — 벡터 인덱스, RAG 파이프라인, 임베딩이 데이터 플랫폼 내장

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

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

2.1 왜 Lakehouse인가

Data Lake의 문제: Schema drift, 데이터 품질, ACID 부재, 조회 성능
Data Warehouse의 문제: 비정형 데이터, 저장 비용, 벤더 락인
Lakehouse의 답: S3에 테이블 포맷(Iceberg/Delta/Hudi)으로 ACID, compute는 Snowflake/Spark/Trino 무엇이든

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

Iceberg (Netflix 출신, Apache) — 2024~2025 사실상 승리. Snowflake Polaris·Databricks UniForm·BigQuery·ClickHouse·DuckDB·Trino 전원 지원
Delta Lake (Databricks) — 2022 OSS 완전 공개, Databricks 중심. UniForm으로 Iceberg 메타데이터 호환 추가
Apache Hudi (Uber 출신) — upsert·incremental 강점, 하지만 커뮤니티 규모에서 Iceberg에 밀림

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

2.3 Iceberg가 이기는 이유

숨겨진 파티션 진화(Hidden Partitioning) — 파티션 스킴 바뀌어도 쿼리 안 깨짐
Time Travel — snapshot 기반 과거 쿼리
Schema Evolution — 컬럼 추가/삭제/타입 변경 안전
Merge-on-Read / Copy-on-Write 선택
REST Catalog — 벤더 중립 메타데이터 API

2.4 Catalog가 새로운 전장

Unity Catalog (Databricks 2024 오픈소스) — 테이블·볼륨·AI 모델 통합
Polaris Catalog (Snowflake 2024 오픈소스) — Iceberg REST
Nessie (Dremio) — git-like branching
AWS Glue Data Catalog — AWS 통합 기본
Gravitino (Datastrato) — 멀티 엔진 메타데이터

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

3.1 ELT의 우위

Extract → Load → Transform
원본을 일단 warehouse에 적재 후 SQL로 변환
Python/Spark 없이 SQL만으로 파이프라인
데이터 엔지니어 수요 병목 완화

3.2 dbt의 지배

ref(), source()로 DAG 자동 구축
dbt test로 not_null/unique/relationship 검증
Jinja 템플릿 + macros로 재사용
Docs, Lineage, Exposures 자동 생성
dbt Cloud로 스케줄/오케스트레이션 내재화
2024 dbt Semantic Layer — 메트릭 정의 표준화

3.3 SQLMesh — dbt의 도전자

Column-level lineage 네이티브
Virtual Data Environment — Dev 환경에서 전체 DAG 미리보기
진정한 idempotent backfills
SCD Type 2 내장

3.4 Trino·Presto·Starburst

페더레이션 쿼리 — S3 + MySQL + Kafka 조인
Lakehouse의 compute 엔진으로도 쓰임
Starburst는 상용 배포판, "Galaxy" SaaS

3.5 PyIceberg · Ibis · Polars

PyIceberg — Python에서 Iceberg를 직접 다룸, JVM 없이
Ibis — DataFrame 추상화, 백엔드(DuckDB/Snowflake/BigQuery) 교체 가능
Polars — Rust 기반 DataFrame, pandas 10~100배, LazyFrame으로 쿼리 최적화

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

4.1 Airflow — 여전히 왕

2014 Airbnb, 2018 Apache
KubernetesExecutor, CeleryExecutor, LocalExecutor
2.x 이후 TaskFlow API로 함수형 DAG
Airflow 3.0 (2024) — DAG Versioning, Multi-Tenant, Event-Driven, Edge Executor
단점: DAG definition과 execution 분리 불명확, 로컬 개발 불편

4.2 Dagster — 현대화의 대표주자

Software-Defined Asset — DAG가 아니라 "자산"을 정의 → 선언적
Type 시스템, 테스트 용이
dbt 통합이 가장 자연스러움
2024 Dagster+ SaaS, branch deployment(Preview Env처럼)
Observability·Lineage 일급

4.3 Prefect

Dynamic DAG, 결정적 DAG 없이 "run-time" 결정
Python-first, pydantic 기반
Prefect Cloud가 hybrid(실행은 고객 인프라)

4.4 Temporal for Data

앞서 distributed systems 편에서 다룬 Temporal이 데이터 파이프라인에도 쓰임
Durable Execution이 장기 실행 백필/마이그레이션에 이상적
Long-running LLM batch jobs에도 각광

4.5 Mage, Kestra, Windmill, Orchest

신흥 주자. Mage는 notebook UX, Kestra는 YAML DSL, Windmill은 TS/Python hybrid

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

5.1 Flink vs Spark Structured Streaming

Flink — 진정한 event-time 처리, exactly-once, windowing 강력, 상태 관리 네이티브
Spark SS — Mini-batch 기반, 레이턴시 ~ 초 단위, 배치 코드와 통일 쉬움

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

5.2 Apache Flink 핵심 개념

Watermark — out-of-order event 다루기
Stateful Processing — RocksDB 백엔드, incremental checkpoints
Changelog Stream — Flink SQL의 upsert 스트림
Flink CDC — Debezium 없이 DB CDC 직접

5.3 Streaming SQL — Materialize, RisingWave, Arroyo

Materialize — incremental view maintenance, 진짜 streaming SQL
RisingWave — Materialize 대항 OSS, Rust 기반
Arroyo — Rust Flink 라이벌
ksqlDB — Confluent의 Kafka 전용, 낮은 관심
Proton (Timeplus) — OLAP + streaming 결합

5.4 Kafka 대안

Redpanda — C++ 단일 바이너리, ZooKeeper/KRaft 없음
WarpStream — S3에 직접 저장(Broker 없음), 2024 Confluent가 인수
Buf Iggy, Parquet Queue — 새 실험들

5.5 CDC (Change Data Capture)

Debezium이 원조, 아직 주류
Airbyte·Fivetran도 CDC 지원
Estuary Flow가 CDC+streaming SQL 통합 신흥 주자
Materialize + Postgres logical replication 조합으로 "실시간 DB 뷰" 현실화

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

6.1 DuckDB — 2024년 가장 핫한 DB

SQLite-like, in-process OLAP
Parquet/CSV/JSON 직접 쿼리 (no ingestion)
노트북/랩탑에서 억단위 row 분석
MotherDuck이 SaaS + 하이브리드 클라우드
2024 Polars 통합, Ibis 통합, httpfs로 S3 직접
분석 엔지니어의 일상 도구로 자리잡음

6.2 ClickHouse — 초대규모 실시간 OLAP

Yandex 오리진, 2021 회사 분사
Merge Tree 계열 엔진, 초단위 수십억 row 스캔
Cloudflare·Uber·eBay·Shopify 핵심 분석 인프라
2024 ClickHouse Cloud가 Parquet Lake + Iceberg 통합 강화
학습 곡선 가파름, 하지만 성능 대비 비용 최저

6.3 StarRocks·Apache Doris

MPP 아키텍처, MySQL 프로토콜
중국 발원, 세계 확장 중
Snowflake·BigQuery 대안으로 거론

6.4 Apache Pinot·Druid

Real-time OLAP for user-facing analytics
LinkedIn·Uber의 실시간 대시보드
Rockset이 OpenAI 인수 후 사실상 소멸(2024)

6.5 언제 무엇을

데이터 < 1TB, 노트북에서? → DuckDB
실시간 초고처리량 OLAP? → ClickHouse·StarRocks
User-facing low-latency 집계? → Pinot·Druid
Semi-structured, 스키마 유연성? → Snowflake·BigQuery
ML + 데이터 통합? → Databricks

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

7.1 Snowflake

가장 사용자 친화, UI·SQL·관리 쉬움
Snowpark Container Services — 워크로드를 내부 컨테이너로
Cortex LLM — 내장 LLM 함수 (2024)
Iceberg Tables + Polaris — 개방형 지향
비용: 많은 회사가 "Snowflake 비용 폭주" 뉴스 주인공 (연 수백만~수천만)

7.2 Databricks

Spark 창업자 팀
ML/AI 통합 강점(MLflow, Mosaic AI)
Lakehouse + Unity Catalog
2023 MosaicML 인수, 2024 Tabular(Iceberg 창업자) 인수
DBRX·Llama 미세조정을 플랫폼 내에서

7.3 BigQuery

Google Cloud 네이티브, 관리 부담 거의 0
Dremel 기반, 페타바이트 스캔 분 단위
BigLake + Iceberg 지원 확대
BigQuery ML, Vertex AI 통합
가격 모델(온디맨드 vs 에디션)이 2023~2024 여러번 변경

7.4 Redshift·Firebolt·Azure Synapse·Fabric

Redshift는 AWS 네이티브, RA3 + Spectrum
Firebolt는 "ClickHouse 기반 Snowflake 대안"
Microsoft Fabric(2023~)은 모든 데이터 툴 통합 시도

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

8.1 문제

업스트림 서비스가 스키마 바꿈 → 다운스트림 파이프라인 줄줄이 깨짐
Schema registry만으로는 불충분(의미·SLA·품질 기대치)

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%"

datacontract.com OSS 스펙이 표준화 중
Schemata, GX (Great Expectations), Soda 같은 품질 검증 통합

8.3 Shift-Left Data Quality

생산자 CI에서 스키마·품질 검증
GitHub PR에서 breaking change 자동 감지
실패 시 produce 차단

8.4 Data Mesh와의 관계

Data Mesh = 도메인 팀이 데이터 제품 소유
Data Contract = 도메인 팀 간 인터페이스 명세
2020 Zhamak Dehghani의 Data Mesh 책 이후 5년, 실전 도입이 어려워 한정적 성공

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

9.1 문제

Looker·Tableau·Superset·노트북이 각자 "매출"을 다르게 계산
CFO가 "어느 숫자가 맞아?" 질문

9.2 해답

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

Cube — GraphQL/REST/SQL 인터페이스
dbt Semantic Layer — dbt와 네이티브 통합
AtScale — 엔터프라이즈 Cube 경쟁자
MetricFlow — Transform 인수, dbt에 흡수

9.3 Headless BI

BI 툴은 프런트엔드, Semantic Layer는 백엔드
Lightdash, Rill, Omni가 dbt Semantic Layer + 시각화

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

10.1 Feature Store

Training과 Serving에서 같은 피쳐 정의
Online store(ms 조회) + Offline store(모델 학습)
Tecton·Feast·Hopsworks·Databricks Feature Store

10.2 Vector DB의 정체성

Qdrant·Pinecone·Weaviate·Milvus·pgvector·Vespa
2024~2025 기존 DB가 vector 확장 — Postgres(pgvector/pgvectorscale), MongoDB, Elasticsearch, Redis, ClickHouse, DuckDB
"전용 Vector DB vs 기존 DB 확장" 2파전이 계속

10.3 Embedding Pipeline

원본 텍스트 → chunk → embedding 모델 → vector store
업데이트 전략: 전체 재계산 vs incremental
Mother-of-all-RAG: semantic layer + vector + traditional SQL를 동시에

10.4 Unstructured Data 인제스천

Unstructured.io — PDF/HTML/이미지에서 구조 추출
LlamaParse, Reducto — 2024 강력한 PDF 레이아웃 파싱
Firecrawl — 웹 크롤링에서 markdown까지
Marker — PDF → markdown 로컬 모델

10.5 Data Warehouse 안에서 LLM

BigQuery: ML.GENERATE_TEXT, ML.GENERATE_EMBEDDING
Snowflake Cortex: COMPLETE, EMBED_TEXT_768
Databricks: Mosaic AI Model Serving
ClickHouse: embedText() 함수 (2024)
데이터를 밖으로 내보내지 않고 SQL로 LLM 추론

11부. Reverse ETL과 Data Activation

11.1 개념

Warehouse → 운영 시스템(Salesforce, HubSpot, Zendesk, Intercom)으로 역방향
영업·마케팅·CS가 데이터를 일상 업무에서 씀

11.2 도구

Hightouch, Census, Grouparoo(2022 EOL)
dbt Cloud도 이 영역 진입

11.3 Composable CDP

전통 CDP(Segment)가 독자 DB를 가지는 대신, warehouse 위에 얹는 Composable CDP 유행
Segment Profiles, RudderStack, Hightouch이 지향

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

12.1 Data Catalog

DataHub (LinkedIn OSS) — 현재 CNCF 준수 방향
OpenMetadata — 경쟁 OSS
Atlan, Collibra, Alation — 상용
Unity Catalog (Databricks 2024 OSS) — Catalog 전쟁 진입

12.2 Column-level Lineage

dbt docs + SQLMesh가 자동 생성
OpenLineage 스펙으로 Airflow/Dagster/Flink 간 연결
Marquez가 레퍼런스 구현

12.3 PII·Privacy

Immuta, Privacera — 정책 기반 컬럼 마스킹
Databricks Unity Catalog의 Row-level Security
Snowflake Dynamic Data Masking
Differential Privacy — Tumult Labs, Google DP Library

12.4 GDPR·CCPA·EU AI Act

Right to Deletion: Iceberg MERGE, Delta DELETE로 오브젝트 스토리지에서 직접 삭제
Data Residency: 리전 분리 catalog
EU AI Act(2025~): 학습 데이터 출처 기록 필수 → Lineage가 법적 의무로

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

13.1 시드 ~ 시리즈 A

수집: Fivetran/Airbyte Cloud
웨어하우스: Snowflake·BigQuery(관리 부담 최소)
변환: dbt Core + GitHub Actions
BI: Metabase (OSS) 또는 Looker Studio
팀: 데이터 엔지니어 1명 + 분석 엔지니어 1명

13.2 시리즈 B~C

Airflow or Dagster 도입
Kafka + CDC (Debezium) 도입
Feature Store 검토
Data Catalog (OpenMetadata/DataHub)
팀: 데이터 플랫폼 3~~5명 + 분석 6~~10명

13.3 엔터프라이즈

Lakehouse (Iceberg + Databricks/Snowflake 병행)
Flink 실시간
Self-service BI + Semantic Layer
Data Contract + Shift-left quality
Privacy/Governance 전담

13.4 AI 기능 추가 로드맵

Phase 1: Vector DB + RAG (외부 LLM)
Phase 2: 임베딩 파이프라인 상시화
Phase 3: 내부 warehouse LLM 함수 (Cortex/BQML)
Phase 4: Agent + Feature Store 통합

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

✅ 체크리스트 12

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

⚠️ 안티패턴 10

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

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

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

Pull Request 리뷰의 사회학 — 블로커가 되지 않는 법
Code Owner, Reviewer Assignment 자동화
Merge Queue — GitHub, Mergify, Aviator, Graphite
Stacked PRs — Graphite·Sapling·Jujutsu
Monorepo vs Polyrepo 2025 최신 논의
Nx·Turborepo·Moon·Bazel·Buck2 비교
AI 코드 리뷰 — Cursor/Copilot/CodeRabbit/Greptile/Ellipsis
Linear History vs Merge Commit
Trunk-based Development
Pre-commit/Pre-push 훅 — Husky, lefthook, pre-commit.com
정적 분석 — Semgrep, SonarQube, CodeQL

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