LLM WikiAccess-protected knowledge portal

WIKI

Apache Iceberg V4: 대규모 운영이 드러낸 V3의 한계와 다음 포맷 설계 방향

왜 지금 봐야 하나 Apache Iceberg V3가 Iceberg 1.11 2026년 5월 로 안정화된 직후, V4 명세 작업이 본격화됐다. Iceberg Summit 2026 6월, Snowflake Summit 병행 개최 에서 V4 로드맵이 공개됐고, 2026년 7월 현재 개발 메일링 리스트에서 핵심 설계 결정이 논의 중이다. V4는 "더 많은 기능"이 목표가 아니다. 대규모 프로덕션 운영이 드러낸 V3의 세 가지 구조적

경로human/study/content/database-frontier/65-apache-iceberg-v4-spec-lakehouse-next-generation.md
카테고리Study
태그#generation #iceberg #lakehouse #mysql #next #spec #study

왜 지금 봐야 하나

Apache Iceberg V3가 Iceberg 1.11(2026년 5월)로 안정화된 직후, V4 명세 작업이 본격화됐다. Iceberg Summit 2026(6월, Snowflake Summit 병행 개최)에서 V4 로드맵이 공개됐고, 2026년 7월 현재 개발 메일링 리스트에서 핵심 설계 결정이 논의 중이다.

V4는 "더 많은 기능"이 목표가 아니다. 대규모 프로덕션 운영이 드러낸 V3의 세 가지 구조적 한계—메타데이터 I/O 오버헤드, 실시간 쓰기 병목, 새로운 데이터 유형 요구—를 설계로 해결하려는 시도다.

이 챕터는 V4에서 확정됐거나 논의 중인 변화를 운영자 관점에서 정리한다. V4는 아직 릴리스되지 않았으며, 일부 기능은 최종 명세에서 변경될 수 있다.

V3에서 V4로: 무엇이 문제였나

한계 1: 메타데이터 읽기 비용이 커밋 수에 비례한다

Iceberg는 테이블 상태를 여러 파일로 나눠 관리한다. 스냅샷 → 매니페스트 리스트 → 매니페스트 파일 → 데이터 파일의 계층 구조다. 쿼리 플래너가 파티션 필터를 적용하려면 매니페스트 파일을 여러 개 열어 읽어야 한다.

커밋이 잦아질수록 매니페스트 수도 늘고, 플래닝 비용이 증가한다. 스트리밍 파이프라인이나 AI 에이전트처럼 분당 수십 회 쓰는 워크로드에서 이 오버헤드가 임계점을 넘는다.

한계 2: 메타데이터 파일이 Avro(행 기반)다

매니페스트 파일은 Avro로 인코딩된다. 쿼리 플래너가 컬럼 min/max 값만 필요해도 전체 행을 역직렬화해야 한다. 컬럼이 수천 개인 넓은 테이블에서 플래닝 메모리가 불필요하게 증가한다.

한계 3: 새 워크로드 유형이 포맷에 없다

벡터 검색(AI 임베딩), 반정형 데이터(JSON-like), 지리공간 데이터가 Lakehouse 워크로드로 들어오고 있다. V3는 이를 위한 네이티브 타입을 제공하지 않아 우회 방식(바이너리 직렬화 등)을 쓸 수밖에 없다.

V4 변화 상세

V2 (2021~)
행 수준 삭제 (position/equality delete)
스냅샷 기반 time travel
파티션 진화
V3 (2025~, Iceberg 1.7+)
삭제 벡터 (delete vector)
Variant 타입 (초기)
REST 카탈로그 서버사이드 플래닝
Row tracking
V4 (논의 중)
단일 파일 커밋 (Single-file commit)
Parquet 메타데이터 (Avro 대체)
geometry / geography 타입
timestamp_ns 타입
컬럼 기본값 (write/initial-default)
내장 암호화 (at-rest)
Apache Iceberg 버전별 진화 방향

1. 단일 파일 커밋 (Single-File Commit)

현재 구조: 커밋 한 번에 최소 2~3개 파일이 생성된다(매니페스트 파일 + 매니페스트 리스트 + 스냅샷 메타데이터). 매니페스트 수는 커밋이 쌓일수록 누적된다.

V4 제안: 커밋 한 번에 파일 1개만 생성한다. 모든 변경 정보(새 파일 목록, 삭제 파일 목록, 통계)를 단일 파일로 통합한다.

효과:

주의점: Compaction 전략이 바뀐다. 현재는 매니페스트 개수로 compaction 시점을 판단하는데, 단일 파일 커밋으로 커밋 수와 파일 수의 관계가 달라진다. 기존 compaction 파라미터를 그대로 쓰면 최적이 아닐 수 있다.

2. Parquet 메타데이터 (Avro 대체)

현재: 매니페스트 파일이 Avro(행 기반 포맷)로 저장된다. 플래너가 특정 컬럼의 min/max 통계만 필요해도 전체 행을 읽어야 한다.

V4 제안: 매니페스트를 Parquet 포맷으로 저장한다. 컬럼형 접근이 가능해져 플래너가 필요한 통계만 선택적으로 읽는다.

효과:

주의점 (중요):

3. 새로운 데이터 타입

variant: JSON-like 반정형 데이터를 네이티브 타입으로 저장한다. V3에서 초기 도입됐으나 V4에서 완성도를 높인다. shredding(자주 조회하는 경로를 별도 컬럼으로 분리)과 결합해 성능을 최적화한다.

geometry / geography: 지리공간 데이터 타입. GIS 워크로드를 Lakehouse 내에서 네이티브로 처리한다. PostGIS, Snowflake의 GEOGRAPHY 타입과 유사한 개념.

timestamp_ns / timestamptz_ns: 나노초 정밀도 타임스탬프. 기존 Iceberg timestamp는 마이크로초까지만 지원했다. IoT 센서, 금융 거래, AI 추론 로그처럼 나노초 해상도가 필요한 워크로드를 위한 추가다.

4. 컬럼 기본값 (write-default / initial-default)

스키마 진화에서 새 컬럼 추가 후 기존 데이터 처리를 명확하게 한다.

설정의미적용 시점
write-default새로 쓰는 행에서 해당 컬럼 미설정 시 사용할 값쓰기 시점
initial-default컬럼 추가 이전에 작성된 기존 행을 읽을 때 사용할 값읽기 시점

V3까지는 새 컬럼의 기본값을 명세 수준에서 표현하기 어려워 애플리케이션 레이어에서 처리했다. V4에서 포맷 수준으로 내려온다.

5. 내장 암호화 (At-Rest Encryption)

테이블 수준 또는 파티션 수준으로 데이터 파일을 암호화한다. KMS 키 참조를 메타데이터에 포함시켜 엔진이 자동으로 복호화 키를 찾는다. 현재 Parquet의 열 암호화(column encryption)와 연동하는 방향으로 논의 중이다.

Delta Lake 5.0과의 수렴 논의

2026년 7월 현재, Databricks가 Delta Lake 5.0에서 Iceberg v4 메타데이터 트리를 네이티브로 채택하는 제안을 논의 중이다. 기술적 근거는 두 포맷이 이미 핵심 아이디어 측면에서 수렴했다는 것이다.

Apache Iceberg V4
이미 수렴한 영역
컬럼형 메타데이터
매니페스트 트리 구조
삭제 벡터
Variant 타입
스냅샷 / 체크포인트
Delta Lake 5.0 (논의 중)
제안: Delta Lake 5.0이 Iceberg v4 메타데이터 트리를 네이티브 채택 → 멀티엔진 환경에서 변환 레이어 없는 읽기/쓰기
두 포맷의 기술적 수렴 영역

이 제안이 실현되면 Spark, Trino, Flink, DuckDB 등 다양한 엔진이 별도 변환 없이 동일한 테이블을 읽고 쓸 수 있다. 현재 Databricks의 UniForm(Delta+Iceberg 병렬 메타데이터)이 이 역할을 하지만, 포맷 수준에서의 통합은 더 근본적인 변화다.

운영자 관점의 함의: 현재 Delta Lake나 Iceberg 중 하나를 선택해야 한다면, V4/5.0 수렴이 확정될 때까지 기존 선택을 유지하는 것이 합리적이다. 단, Polaris·Unity Catalog 같은 REST 카탈로그 레이어를 도입해두면 포맷 전환 시 마이그레이션 범위를 줄일 수 있다.

운영자 체크리스트

V4 도입 전 점검

V4 타입 활용 준비

포맷 수렴 모니터링

Open Questions

References