✍️ 필사 모드: 레이크하우스 2025 완전 가이드: Iceberg vs Delta vs Hudi, Open Table Format 전쟁, Snowflake·Databricks 합종연횡 (2025)

Season 5 Ep 1 — Season 4가 "AI 제품의 축"이었다면 Season 5는 "AI 아래 흐르는 데이터의 축". 첫 에피소드는 가장 극적으로 변한 영역 — 레이크하우스.

• Prologue — "2024년은 Iceberg의 해였다"
• 1장 · 레이크하우스란 무엇인가
  • 1.1 3세대 데이터 아키텍처
  • 1.2 Lakehouse의 핵심
  • 1.3 왜 레이크하우스인가
• 2장 · Iceberg, Delta, Hudi 아키텍처 비교
  • 2.1 공통 요소
  • 2.2 Apache Iceberg
  • 2.3 Delta Lake
  • 2.4 Apache Hudi
  • 2.5 비교표
  • 2.6 선택 가이드
• 3장 · Parquet·ORC·Puffin — 파일 레벨 진실
  • 3.1 Parquet
  • 3.2 ORC
  • 3.3 Puffin(Iceberg 3.0)
  • 3.4 실무 팁
• 4장 · 카탈로그 전쟁
  • 4.1 왜 카탈로그가 중요한가
  • 4.2 주요 카탈로그
  • 4.3 2024–2025 방향
  • 4.4 카탈로그 고르기
• 5장 · 쿼리 엔진 생태계
  • 5.1 2025 주요 엔진
  • 5.2 엔진별 강점
  • 5.3 "Multi-engine on one lakehouse" 패턴
• 6장 · 성능 튜닝 — 실무 10대 원칙
  • 6.1 파티션 전략
  • 6.2 Z-order / Liquid clustering
  • 6.3 파일 크기
  • 6.4 Compaction
  • 6.5 Vacuum / Snapshot expiration
  • 6.6 Metadata 관리
  • 6.7 통계(Statistics)
  • 6.8 스키마 진화
  • 6.9 Predicate pushdown
  • 6.10 대용량 Upsert
• 7장 · 스트리밍과 CDC
  • 7.1 배치 vs 스트리밍의 경계 약화
  • 7.2 CDC 패턴
  • 7.3 지연 목표
  • 7.4 실무 조언
• 8장 · 거버넌스 · 보안
  • 8.1 테이블 레벨 권한
  • 8.2 컬럼·행 레벨 보안
  • 8.3 데이터 계보(Lineage)
  • 8.4 감사(Audit)
  • 8.5 PII·암호화
• 9장 · 마이그레이션 전략
  • 9.1 Hive → Iceberg
  • 9.2 Delta → Iceberg (UniForm)
  • 9.3 Snowflake 네이티브 → Iceberg External
  • 9.4 Hudi → Iceberg
  • 9.5 마이그레이션 체크리스트
• 10장 · 비용 최적화
  • 10.1 스토리지
  • 10.2 컴퓨트
  • 10.3 네트워크
  • 10.4 쿼리 비용
  • 10.5 실제 절감 사례 범위
• 11장 · AI·ML 통합
  • 11.1 Feature Store로서의 Lakehouse
  • 11.2 벡터·임베딩 저장
  • 11.3 ML 파이프라인
  • 11.4 LLM·RAG
• 12장 · 한국 기업의 레이크하우스
  • 12.1 현황
  • 12.2 의사결정 고려사항
  • 12.3 벤더·파트너
  • 12.4 실무 난관
• 13장 · 안티패턴 10선
  • 13.1 포맷 혼용 남발
  • 13.2 파티션 과잉
  • 13.3 Compaction 미설정
  • 13.4 Snapshot 영원 보관
  • 13.5 카탈로그 없이 Lake 운영
  • 13.6 스키마 강제 변경
  • 13.7 스트리밍 무조건 실시간
  • 13.8 모든 데이터 Gold로
  • 13.9 엔진 한 개에 종속
  • 13.10 거버넌스 후순위
• 14장 · 체크리스트 — 레이크하우스 런칭 전 12가지
• 15장 · 다음 글 예고 — Season 5 Ep 2: "스트리밍 vs 배치의 재정의"

Prologue — "2024년은 Iceberg의 해였다"

2020–2023년까지 데이터 업계의 가장 뜨거운 논쟁은 "Open Table Format 3대장" — Apache Iceberg, Delta Lake, Apache Hudi — 중 무엇이 표준이 되는가였다.

2024년 두 사건이 결론을 냈다:

1. Snowflake가 Iceberg 네이티브 지원 + 자체 카탈로그(Polaris) 오픈소스화 (2024 Summit)
2. Databricks가 Tabular(Iceberg 창립자들의 회사)를 $1B+ 인수

Databricks는 Delta 창시자. Tabular는 Iceberg 창시자들(Ryan Blue, Dan Weeks)의 회사. 이 인수는 **"Delta와 Iceberg는 사실상 같은 것이 되어야 한다"**는 선언이었다. 2024–2025년 Databricks는 Delta UniForm을 통해 Delta를 Iceberg로 읽게 만들었다.

2025년 현재, Iceberg가 사실상의 오픈 테이블 포맷 표준이 되었고, Delta·Hudi는 Iceberg와의 상호운용성을 추구한다. 이 글은 그 현실을 전제로, 실무자가 알아야 할 모든 것을 정리한다.

---

1장 · 레이크하우스란 무엇인가

1.1 3세대 데이터 아키텍처

• 1세대(1980s–2000s): Data Warehouse (Teradata, Oracle) — 구조화·고비용
• 2세대(2010s): Data Lake (Hadoop/S3 + Parquet) — 저렴·자유롭지만 ACID·스키마 없음
• 3세대(2020s): Lakehouse — Lake의 저렴함 + Warehouse의 ACID·성능

1.2 Lakehouse의 핵심

• 오브젝트 스토리지(S3/GCS/ADLS) + 오픈 파일 포맷(Parquet/ORC)
• Open Table Format이 위에 메타데이터를 얹어 ACID, 스키마 진화, 타임트래블 제공
• 쿼리 엔진(Spark/Trino/Flink/DuckDB/Snowflake/BigQuery)이 동일 데이터를 공유

1.3 왜 레이크하우스인가

• 데이터 중복 제거(Warehouse + Lake 이중 운영 종료)
• BI · ML · 스트리밍이 같은 테이블 사용
• 벤더 락인 감소(오픈 포맷·오픈 카탈로그)
• 비용 절감(압축·파티션 진화·zstd·ZSTD zlib 대체)

---

2장 · Iceberg, Delta, Hudi 아키텍처 비교

2.1 공통 요소

세 포맷 모두:

• Parquet/ORC 데이터 파일 + JSON/Avro 메타데이터
• Snapshot 기반 ACID
• Schema evolution, Time travel, Partition pruning
• Z-order/Sort-based clustering

2.2 Apache Iceberg

• 2017 Netflix에서 출발, 2018 Apache incubator
• Manifest 파일 2층 구조(metadata.json → manifest list → manifest → data files)
• Hidden partitioning — 쿼리에 파티션 컬럼 명시 불필요
• Partition evolution — 파티션 전략을 사후 변경 가능
• Branch/Tag — Git 같은 분기·태그
• 카탈로그 추상화: REST, Hive, Glue, Nessie, Polaris, Unity 등

2.3 Delta Lake

• 2019 Databricks에서 출발
• Transaction log (_delta_log/) — JSON + Parquet checkpoint
• Databricks 생태계 최적화
• Liquid clustering(2024) — 파티션 없이 자동 클러스터링
• UniForm(2024) — Delta를 Iceberg로 노출 가능(메타데이터 변환)

2.4 Apache Hudi

• 2017 Uber에서 출발
• Copy-on-Write(COW) vs Merge-on-Read(MOR) 선택 가능
• 스트리밍·업서트에 강점(CDC 파이프라인)
• 인덱스(Bloom, Record key) 내장
• 시장 점유율은 Iceberg/Delta에 뒤지지만 CDC 워크로드에서 여전히 경쟁력

2.5 비교표

2.6 선택 가이드

• 일반 BI/ML + 벤더 중립: Iceberg
• Databricks 전용 + 최대 성능: Delta
• CDC 스트리밍 중심: Hudi 또는 Iceberg + Flink
• 혼재된 팀: Iceberg(Delta UniForm으로 Databricks도 수용)

---

3장 · Parquet·ORC·Puffin — 파일 레벨 진실

3.1 Parquet

• 컬럼형, Dremel 논문 기반
• 압축(Snappy/Zstd/Gzip/LZ4), 인코딩(Dictionary/RLE/Delta)
• Row group + Page 구조
• Predicate pushdown, Column pruning

3.2 ORC

• Hive 생태계에서 출발
• Stripe 단위, 인덱스 내장
• Parquet 대비 BI 워크로드 일부 우위, 생태계 규모는 Parquet 우세

3.3 Puffin(Iceberg 3.0)

• Iceberg 전용 사이드카 포맷
• 통계·인덱스·ML 벡터 저장
• Blob 기반 — 유연한 확장

3.4 실무 팁

• 2025년 거의 모든 신규 프로젝트는 Parquet + Zstd
• Zstd level은 3–6이 CPU 대비 최적
• Row group size 128–256MB, Page size 1MB 기준
• Dictionary encoding이 컬럼 크기의 60–90%를 좌우

---

4장 · 카탈로그 전쟁

4.1 왜 카탈로그가 중요한가

• 테이블 위치·스키마·스냅샷을 중앙 관리
• 권한·감사·멀티엔진 접근
• Iceberg는 카탈로그 API가 표준화돼 있어 카탈로그 교체 가능

4.2 주요 카탈로그

• AWS Glue Data Catalog: AWS 생태계, Iceberg/Delta/Hudi 모두 지원
• Snowflake Polaris (2024 오픈소스): REST 표준, 외부 엔진 접근
• Databricks Unity Catalog: Databricks 생태계, 2024 오픈소스화(Unity Catalog OSS)
• Project Nessie: Git 같은 브랜치·태그, Iceberg 특화
• Apache Gravitino: 메타데이터 연합(federation), 2024 부상
• Tabular(현 Databricks): Iceberg REST 카탈로그 기준 구현

4.3 2024–2025 방향

• Iceberg REST Catalog가 표준 인터페이스로 자리잡음
• Polaris와 Unity Catalog OSS가 서로 호환성 강조하며 경쟁
• 엔터프라이즈는 카탈로그 연합(여러 카탈로그 통합)으로 이동

4.4 카탈로그 고르기

• AWS 중심: Glue 또는 Polaris(S3 통합)
• Databricks 중심: Unity Catalog
• 벤더 중립 + 고급 기능: Polaris 또는 Nessie
• 다중 엔진·다중 벤더: REST 표준이면 어떤 카탈로그도 OK

---

5장 · 쿼리 엔진 생태계

5.1 2025 주요 엔진

• Snowflake: Iceberg External Table + Native 지원, 세계 최대 DWH 중 하나
• Databricks SQL: Delta + Iceberg UniForm
• BigQuery: Iceberg External, BigLake
• Trino/Presto: 오픈, Iceberg 최고 성능 중 하나
• Apache Spark: 범용 배치·ML
• DuckDB: 단일 노드, Iceberg 읽기 2024 확장
• ClickHouse: OLAP 초고속, Iceberg 읽기 지원 확대
• Apache Flink: 스트리밍·CDC
• StarRocks / Doris: MPP OLAP, Iceberg 활발

5.2 엔진별 강점

5.3 "Multi-engine on one lakehouse" 패턴

• ETL: Spark
• BI: Trino 또는 Snowflake
• 실험·분석: DuckDB
• 스트리밍: Flink
• ML: Databricks 또는 Spark + Ray

하나의 Iceberg 테이블을 여러 엔진이 공유하는 것이 2025년의 지배적 패턴.

---

6장 · 성능 튜닝 — 실무 10대 원칙

6.1 파티션 전략

• 기본: 날짜(월/일)로 파티션
• 고카디널리티 컬럼은 파티션 금지(작은 파일 폭증)
• Hidden partitioning(Iceberg): 함수 기반(year, month, bucket)

6.2 Z-order / Liquid clustering

• 다차원 쿼리 패턴일 때 유용
• Z-order: Iceberg/Delta 모두
• Liquid(Delta 2024): 자동, 파티션 불필요

6.3 파일 크기

• 타겟 128MB–1GB
• 작은 파일 폭증은 성능 1순위 문제
• Compaction 주기적 실행

6.4 Compaction

• Bin-packing(기본)
• Sort-based(쿼리 빈도 높은 컬럼 기준)
• Z-order(다차원)

6.5 Vacuum / Snapshot expiration

• 오래된 스냅샷·데이터 파일 제거
• 비용·성능 동시 개선
• 기본 보존 7–30일, 규제에 따라 조정

6.6 Metadata 관리

• Manifest list 너무 커지면 쿼리 플래닝 느려짐
• 주기적 rewrite_manifests (Iceberg)
• Checkpoint 생성(Delta)

6.7 통계(Statistics)

• NDV(Number of Distinct Values), Min/Max, Null count
• Puffin(Iceberg)에 저장
• Cost-based optimizer 성능 핵심

6.8 스키마 진화

• Add/Drop/Rename 안전하게
• 컬럼 ID 기반(Iceberg/Delta)으로 이름 변경도 무중단
• 타입 변경은 호환 방향만(Int → Long 등)

6.9 Predicate pushdown

• WHERE 조건을 엔진 → 포맷까지 전달
• 파티션 pruning + Row group 스킵
• 쿼리 패턴에 맞춰 파티션·Sort 키 설정

6.10 대용량 Upsert

• MERGE INTO 활용
• Copy-on-Write vs Merge-on-Read 선택
• Hudi는 Record key 기반 인덱스로 빠른 upsert

---

7장 · 스트리밍과 CDC

7.1 배치 vs 스트리밍의 경계 약화

• 2025년 Lakehouse는 배치·스트리밍 같은 테이블에 쓸 수 있음
• Iceberg + Flink: 실시간 append + 쿼리 가능
• Delta + Structured Streaming: Databricks 표준

7.2 CDC 패턴

• MySQL/Postgres → Debezium → Kafka → Flink → Iceberg
• 또는 Fivetran·Airbyte → Iceberg 직접
• Upsert 처리: Iceberg v2 row-level delete + MERGE

7.3 지연 목표

• Near-realtime: 1–5분
• Micro-batch: 10–60초
• 진짜 실시간: 스트리밍 OLTP(Kafka) + 분석은 별도 rollup

7.4 실무 조언

• "스트리밍 = 모든 걸 실시간"은 비용 폭탄
• SLA 기반으로 테이블별 지연 목표 설정
• 대부분의 BI는 15분–1시간 지연이면 충분

---

8장 · 거버넌스 · 보안

8.1 테이블 레벨 권한

• Iceberg REST + 카탈로그 기반 RBAC
• Snowflake/Databricks는 카탈로그에서 통합 관리
• Ranger/Open Policy Agent(OPA) 통합 가능

8.2 컬럼·행 레벨 보안

• Masking, Row-level filter
• Unity Catalog / Snowflake Dynamic Data Masking 지원
• Iceberg 자체보다는 엔진·카탈로그 계층에서 주로 처리

8.3 데이터 계보(Lineage)

• OpenLineage 표준
• Marquez, DataHub, Atlan, Collibra
• "어느 소스가 이 지표를 만드는가"를 자동 추적

8.4 감사(Audit)

• 모든 DDL/DML 로그
• 누가 언제 어떤 스냅샷을 읽었는가
• 금융·의료 규제 대응

8.5 PII·암호화

• Column-level 암호화(Parquet Modular Encryption)
• S3/GCS 서버측 암호화는 기본
• Tokenization으로 PII 대체(분석 가능성 유지)

---

9장 · 마이그레이션 전략

9.1 Hive → Iceberg

• In-place migration: 메타데이터만 변환 (데이터 복사 없이)
• Iceberg migrate 프로시저(Spark) 또는 Tabular/Polaris 도구
• 주의: 기존 파티션 구조 그대로 유지하거나 재구성

9.2 Delta → Iceberg (UniForm)

• Databricks UniForm 활성화 → Delta가 Iceberg 메타도 생성
• 양방향 읽기 가능, 외부 엔진 접근 용이
• Delta 고유 기능(Liquid clustering 등)은 Iceberg 측에서 미보임

9.3 Snowflake 네이티브 → Iceberg External

• Iceberg External Table로 Snowflake 내부 데이터 덤프
• 쿼리 엔진 다양화 가능, 일부 기능(Time Travel 등)은 내부 테이블 대비 제한
• 비용·성능 비교 후 결정

9.4 Hudi → Iceberg

• 스트리밍 워크로드 특성상 직전 마이그레이션은 드묾
• 새 테이블은 Iceberg로, 기존은 Hudi 유지하는 하이브리드 흔함

9.5 마이그레이션 체크리스트

• 백업·롤백 계획
• 파티션 전략 재검토
• 쿼리 엔진·BI 툴 호환성 확인
• 비용 시뮬레이션
• 단계별 이관(샤드·기간별)

---

10장 · 비용 최적화

10.1 스토리지

• Parquet Zstd 압축(일반 대비 30–50% 절감)
• 오래된 데이터는 Glacier/Archive로 이동
• Snapshot expiration 주기화

10.2 컴퓨트

• Spot/Preemptible 인스턴스(배치)
• Autoscale with warm pool(지연 줄이기)
• 작은 쿼리는 DuckDB로 오프로드

10.3 네트워크

• 같은 리전 내 처리
• S3 Transfer Acceleration 필요 시만
• Cross-region 복제는 꼭 필요한 경우만

10.4 쿼리 비용

• BI 대시보드는 프리컴퓨트(Materialized view)
• 반복 ad-hoc은 결과 캐시
• 사용자별·팀별 쿼터 설정

10.5 실제 절감 사례 범위

• 레이크하우스 전환으로 스토리지 30–50%, 쿼리 비용 20–40% 절감 보고 사례 흔함
• 규모가 클수록 효과 큼

---

11장 · AI·ML 통합

11.1 Feature Store로서의 Lakehouse

• Feast, Tecton이 Iceberg·Delta 지원 확대
• 배치 피처 + 온라인 스토어(Redis/DynamoDB) 조합
• Online-offline skew 관리가 핵심

11.2 벡터·임베딩 저장

• Iceberg v3 / Puffin에 벡터 저장 실험
• 전용 벡터 DB(Pinecone, Weaviate, Milvus) 대비 정확도 낮지만 비용·통합 우위
• 2025년 하이브리드가 흔함

11.3 ML 파이프라인

• 원본 → Silver → Gold(Medallion 패턴)
• Gold 테이블을 ML 학습·추론에 사용
• 학습·평가 데이터 버전: Iceberg tag/branch 활용

11.4 LLM·RAG

• 회사 문서 → Chunk → 임베딩 → Iceberg 테이블(메타+벡터)
• Iceberg 시간여행으로 RAG 결과 재현 가능
• 인증·권한을 카탈로그에서 중앙 관리

---

12장 · 한국 기업의 레이크하우스

12.1 현황

• 금융·통신·대기업: Warehouse(Teradata/Oracle) + Lake(Hadoop/HDFS) 이중 운영
• 2022–2024 Databricks·Snowflake 도입 가속
• 2024–2025 Iceberg 기반 자체 구축도 증가

12.2 의사결정 고려사항

• 규제·망분리: 금융·공공은 온프레/사내 VPC 필수
• 인건비: 관리형 서비스 vs 자체 운영
• 기존 DW와 공존: 즉시 대체보다 데이터 영역별 단계 도입
• 한국어 생태계: 카탈로그·BI 한국어 메타 지원

12.3 벤더·파트너

• 국내 클라우드(NHN Cloud, KT Cloud, Naver Cloud) + 오브젝트 스토리지
• 국내 SI·컨설팅: LG CNS, 삼성 SDS, SK C&C, 베스핀글로벌 등 레이크하우스 프랙티스
• 스타트업: Superb AI(MLOps), Upstage(LLM·Document AI) 등 파트너십

12.4 실무 난관

• 대용량 레거시 DW 이관 비용
• 한국어 컬럼명·데이터 규칙(한자·영문 혼재)
• 감사·접근 통제의 까다로움(금융감독원·개인정보위)
• 내부 인력 확보(데이터 엔지니어 부족)

---

13장 · 안티패턴 10선

13.1 포맷 혼용 남발

Iceberg, Delta, Hudi를 모두 도입 → 운영 비용·학습 곡선 폭증.

13.2 파티션 과잉

고카디널리티(사용자ID 등)로 파티션 → 작은 파일 수백만.

13.3 Compaction 미설정

파일 쌓이다가 쿼리 10배 느려짐.

13.4 Snapshot 영원 보관

스토리지 비용 폭증, 메타데이터 비대.

13.5 카탈로그 없이 Lake 운영

"파일 있으면 테이블" → 일관성 없음, 감사 불가.

13.6 스키마 강제 변경

Drop + Add → 컬럼 ID 깨짐, 타임트래블 깨짐.

13.7 스트리밍 무조건 실시간

필요하지 않은데 kinesis/kafka → 비용 낭비.

13.8 모든 데이터 Gold로

Bronze/Silver/Gold 계층 없음 → 비용·품질 동시 저하.

13.9 엔진 한 개에 종속

Snowflake/Databricks 한 벤더 락인 → 협상력 상실.

13.10 거버넌스 후순위

PII·감사·계보 무시 → 감사 실패·사고.

---

14장 · 체크리스트 — 레이크하우스 런칭 전 12가지

• 테이블 포맷 선택 근거 문서화(Iceberg 기본, 이유 있는 경우만 Delta/Hudi)
• 카탈로그 선택(Glue/Polaris/Unity/Nessie) + 권한 전략
• 파일 포맷·압축·크기 정책(Parquet + Zstd, 128MB–1GB)
• 파티션 전략 + Z-order/Liquid 여부
• Compaction·Vacuum 자동화
• Snapshot retention 정책
• Medallion 계층(Bronze/Silver/Gold) 정의
• 쿼리 엔진 라인업(BI·ML·스트리밍·ad-hoc)
• 스트리밍 SLA별 아키텍처
• 거버넌스(RBAC, 마스킹, 계보, 감사)
• 비용 대시보드(스토리지·컴퓨트·쿼리)
• 마이그레이션 경로와 롤백 플랜

---

15장 · 다음 글 예고 — Season 5 Ep 2: "스트리밍 vs 배치의 재정의"

레이크하우스가 정리됐으니, 다음은 데이터가 얼마나 빠르게 흐를 수 있는가의 재정의.

• Lambda vs Kappa 아키텍처의 2025년 버전
• Flink, Spark Structured Streaming, Kafka Streams, Materialize, RisingWave
• Change Data Capture(CDC) 심화: Debezium, Fivetran, Airbyte
• Iceberg v3의 row-level delete와 실시간 upsert
• Streaming SQL (ksqlDB, Flink SQL, RisingWave)
• 실시간 Feature Store
• 관측성·디버깅(Flink CEP, Kafka lag)
• 비용·지연 트레이드오프
• 한국 기업 실시간 아키텍처(금융 거래·커머스·게임)
• "진짜 실시간"이 필요한 케이스와 아닌 케이스 구분

"모든 데이터를 실시간으로"는 2020년의 약속, 2025년은 실용주의의 시대.

다음 글에서 만나자.

---

요약: 2024년 Snowflake의 Iceberg 네이티브 지원과 Databricks의 Tabular 인수로 Open Table Format 전쟁은 Iceberg의 사실상 승리로 종결. 2025년 실무자는 Iceberg를 기본으로 하되, Databricks 전용 최대 성능이 필요하면 Delta, CDC 스트리밍 중심이면 Hudi를 고려한다. 카탈로그(Glue/Polaris/Unity/Nessie)는 REST 표준 덕에 교체 가능하고, 쿼리 엔진은 하나의 테이블을 여러 엔진이 공유하는 "Multi-engine on one lakehouse" 패턴이 지배적. "레이크하우스 = 오픈 포맷 + 오픈 카탈로그 + 다양한 엔진" — 이 세 축이 2025년 데이터 플랫폼의 기반이 됐다.