65편 · 약 14분

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

왜 지금 봐야 하나

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개만 생성한다. 모든 변경 정보(새 파일 목록, 삭제 파일 목록, 통계)를 단일 파일로 통합한다.

효과:

커밋당 I/O: O(매니페스트 수) → O(1)
CDC 파이프라인, 스트리밍 수집, AI 에이전트의 잦은 쓰기 패턴에서 오버헤드 감소
오브젝트 스토리지(S3, GCS)의 PUT 요청 수 감소 → 비용 직접 절감

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

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

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

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

효과:

플래닝 I/O: 필요한 컬럼만 읽음. 1,000개 컬럼 테이블에서 2개 컬럼 통계만 필요하면 2/1,000만 읽음
넓은 테이블(wide table)에서 플래닝 메모리 사용 감소

주의점 (중요):

Parquet는 행 그룹(row group) 단위로 읽는다. 메타데이터 노드 하나의 특정 컬럼 통계를 읽어도, 해당 행 그룹 전체가 메모리로 올라온다. 수천 개 컬럼의 넓은 메타데이터 노드에서는 Avro보다 오히려 메모리가 많이 필요할 수 있다.
V3 Avro 매니페스트와의 하위 호환성 마이그레이션 경로를 설계 중이다. V4 엔진이 V3 테이블을 읽을 수 있어야 하고, 점진적 업그레이드가 지원돼야 한다.

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 도입 전 점검

[ ] 현재 커밋 빈도 측정: Iceberg 테이블의 초당/분당 커밋 횟수를 측정한다. 분당 10회 이상이면 단일 파일 커밋이 직접 이익이 된다.
[ ] 플래닝 시간 프로파일링: 느린 쿼리의 병목이 실행이 아닌 플래닝에 있는지 확인한다. Parquet 메타데이터 전환의 우선순위 판단에 쓴다.
[ ] 매니페스트 파일 수 모니터링: 현재 Iceberg 테이블의 매니페스트 파일 수를 추적한다. V4 단일 파일 커밋 전환 시 기준선으로 쓴다.
[ ] Compaction 파라미터 재검토: V4 도입 후 단일 파일 커밋으로 커밋 수와 데이터 파일 수의 관계가 바뀐다. min-snapshots-to-keep, max-snapshot-age-ms 등 기존 파라미터가 여전히 유효한지 검토한다.

V4 타입 활용 준비

[ ] variant 타입 대상 식별: 현재 JSON을 string으로 저장하고 있는 컬럼 목록을 추출한다. V4 variant 전환 후 성능 이익이 예상되는 컬럼을 우선순위화한다.
[ ] timestamp_ns 대상 식별: 마이크로초보다 높은 정밀도가 실제로 필요한 이벤트 소스를 확인한다. 불필요한 타입 전환은 스토리지 증가만 초래한다.
[ ] 암호화 키 관리 준비: V4 내장 암호화를 사용할 테이블을 식별하고 KMS 통합 계획을 세운다. 키 로테이션 정책이 기존 데이터 접근성에 미치는 영향을 사전 검토한다.

포맷 수렴 모니터링

[ ] Delta Lake 5.0 발표 추적: Databricks가 Iceberg v4 메타데이터 채택을 공식 발표하는 시점을 추적한다.
[ ] REST 카탈로그 도입: Polaris 또는 Unity Catalog 같은 Iceberg REST 카탈로그를 도입해두면 포맷 전환 시 엔진 재설정 범위가 줄어든다.

Open Questions

단일 파일 커밋의 최대 파일 크기 제한(매니페스트가 매우 큰 경우)이 명세에서 어떻게 처리될지 미확정이다.
Parquet 메타데이터 전환 시 V3 테이블의 점진적 업그레이드 경로(온라인 마이그레이션 vs 전체 재작성)가 확정되지 않았다.
Delta Lake 5.0의 Iceberg v4 메타데이터 채택 제안이 최종 승인될지, 타임라인이 어떻게 될지 공식 발표가 없다.
Parquet 행 그룹 경계와 메타데이터 노드 크기의 최적 매핑 전략이 논의 중이다.