Apache Iceberg v4: 현황·제안·중요성

Source: Dev.to

몇 년 전 Apache Iceberg에 대한 질문은 “오픈 테이블 포맷이 독점적인 데이터 웨어하우스를 대체할 수 있을까?”였던 것이다. 그 질문은 이제 답이 나왔다. Iceberg가 승리했다. 이제 새로운 질문이 더 날카롭고 흥미롭다. 다음엔 무엇을 할 것인가?
그것이 Iceberg v4를 이끄는 질문이다.

2026년 샌프란시스코에서 열린 Iceberg Summit에 600명 이상이 이틀 동안 모여 70여 개 세션을 진행했다. 어느 발표도 청중에게 Iceberg를 채택하라고 설득하려 하지 않았다. 모든 세션은 이미 프로덕션에서 Iceberg를 사용하고 있다는 전제 하에 진행되었다. 에너지는 다른 곳으로 향했다. 성공이 만든 한계와 그 한계를 해소하기 위한 스펙 변경에 초점이 맞춰졌다.

이 글에서는 2026년 6월 현재 v4의 상태를 살펴본다. 주요 제안 각각을 기술적인 수준에서 어떻게 작동하는지, 그리고 대규모 Iceberg 운영자에게 왜 중요한지를 다룬다. 또한 v4가 아직 완성되지 않았기 때문에 진행 중인 활발한 토론도 함께 소개한다. 설계 문서만큼이나 개발자 메일링 리스트의 논쟁도 중요한 정보를 제공한다.

솔직한 현황

Iceberg v4는 아직 릴리스되지 않았다. 최종 확정도 되지 않았다. 현재는 설계 문서, GitHub 이슈, Iceberg Enhancement Proposals, 그리고 개발자 메일링 리스트의 긴 스레드 형태로 존재한다. 현재 안정 버전은 2025년 9월에 나온 1.10.0이며, 이 버전은 확실히 v3 시대에 속한다.

실제 운영 가이드는 변함이 없다. v3를 프로덕션 타깃으로 삼고, v4는 눈여겨 볼 미래 지평선으로 간주하라. 확정된 기능이 언제 출시될지 모르는 새로운 기능을 기다리기보다, 이미 안정적이고 검증된 것을 기반으로 구축하라.

그럼에도 v4는 이제 막연한 위시리스트가 아니다. Summit에서 이를 명확히 했다. 제안들은 학문적인 것이 아니라, 실제 대규모 팀이 겪는 운영상의 고통에 대한 직접적인 답이었다. 그리고 이를 만든 사람들은 그 고통을 가장 많이 겪는 사람들이다. Google, Apple, Snowflake, Databricks, Microsoft, Netflix, LinkedIn의 엔지니어들이 같은 설계 논의에 참여하고 동일한 풀 리퀘스트를 검토한다. 그래서 커뮤니티는 투표가 이루어지기 전부터도 방향성을 신뢰한다.

이미 v4의 조각들이 공식 스펙에 스며들고 있다. 스펙 문서가 테이블 위치를 다룰 때 “v4 및 이후 버전”에 대한 동작을 설명한다. 작은 디테일이지만, 스펙 작성자가 v4 의미론을 문서 자체에 반영하기 시작했음을 의미한다.

제안을 이해하려면 현재 Iceberg가 테이블을 어떻게 추적하는지에 대한 간단한 모델이 필요하다. 이미 잘 알고 있다면 이 섹션은 건너뛰어도 된다.

Iceberg는 기존 Hive 방식인 디렉터리 기반 데이터 추적을 대체했다. Hive는 각 파티션을 폴더에 매핑하고, 그 폴더 안의 모든 파일을 테이블의 일부로 간주했다. 이는 디렉터리 목록 조회가 빠른 HDFS에서는 잘 동작했지만, S3와 같은 객체 스토어에서는 수백만 파일을 중첩 파티션에 걸쳐 나열하는 것이 느리고 비용이 많이 들었으며, 요청률 제한으로 인해 실제 장애가 발생했다.

Iceberg는 메타데이터 트리를 통해 개별 파일을 추적함으로써 이를 해결했다. 트리는 몇 개의 계층으로 구성된다.

• 데이터 파일: 실제 행을 저장하며 보통 Parquet 형식이다.
• 매니페스트 파일: 데이터 파일 그룹과 파일별 통계(행 수, 각 컬럼의 최소·최대값 등)를 나열한다.
• 매니페스트 리스트: 하나의 스냅샷을 구성하는 모든 매니페스트를 모아 놓는다.
• 메타데이터 파일(JSON): 현재 스냅샷을 가리키고 스키마, 파티션 스펙, 정렬 순서, 스냅샷 히스토리 등 테이블 수준 정보를 저장한다.

각 커밋은 새로운 불변 스냅샷을 만든다. 리더는 일관된 시점(view)을 얻고, 라이터는 메타데이터 포인터를 원자적으로 교체하면서 데이터를 추가한다. 이 메커니즘이 Iceberg에 타임 트래블, 롤백, 스냅샷 격리 등을 제공하며, 저비용 객체 스토어에서도 작동한다.

이 트리 구조의 장점은 쿼리 시에 나타난다. 엔진은 메타데이터를 읽고 파일별 통계를 확인해, 최소·최대값이 쿼리 필터와 일치하지 않는 파일은 스킵한다. 디렉터리를 나열하거나 데이터 파일을 열 필요가 없다. 스캔 플래닝은 스토리지 레이아웃을 전체 스캔하는 것이 아니라 메타데이터 조회가 된다. 테이블이 수십 페타바이트 규모여도 엔진은 메타데이터만 읽어 빠르게 플래닝할 수 있다. 이 특성이 Iceberg의 핵심 아키텍처 장점이며, 모든 v4 제안은 이를 보호하도록 설계되었다.

스펙은 명확한 단계별로 성장해왔다.

• V1: 불변 데이터 파일, 스냅샷, 숨겨진 파티셔닝, 안전한 스키마 진화를 기반으로 토대를 마련했다.
• V2: 삭제 파일을 도입해 전체 데이터 파일을 재작성하지 않고도 행을 삭제 표시할 수 있게 했다. 이를 통해 행 수준 업데이트와 merge‑on‑read가 실용화됐으며, CDC와 GDPR 삭제에도 활용되었다.
• V3(2025년 1.8~1.10 릴리즈): 바이너리 삭제 벡터, 반정형 데이터용 variant 타입, 네이티브 지오메트리·지리 타입, 나노초 타임스탬프, 행 계보, 기본 컬럼 값, 다중 인자 파티션 변환, 테이블 암호화 키 등을 추가했다.

각 버전은 실제 문제를 해결했으며, 동시에 새로운 문제를 드러냈다. 이제 v4가 등장한다.

v4 뒤의 패턴은 일관된다. Iceberg는 대용량, 느리게 변하는 분석 테이블을 위해 설계되었다. 하지만 현재 사용되는 워크로드는 전혀 느리지 않다. 스트리밍 파이프라인은 몇 초마다 커밋하고, 머신러닝 피처 테이블은 수천 개 컬럼을 보유한다. 재해 복구 계획은 테이블이 버킷·리전 간에 이동할 수 있어야 한다고 요구한다. 배치 분석에 최적화된 메타데이터 설계가 이러한 새로운 패턴에서는 병목이 된다. v4는 그 병목을 여러 각도에서 동시에 공략한다.

가장 큰 제안이자 가장 야심찬 제안

오늘날 커밋 비용을 살펴보라. 아주 작은 쓰기라도 새로운 metadata.json, 새로운 매니페스트 리스트, 그리고 하나 이상의 새로운 매니페스트 파일을 만든다. 변경 사항이 하나의 데이터 파일만을 건드리더라도 메타데이터 작업은 여러 파일을 다룬다. 이는 쓰기 증폭이며, 커밋 지연시간으로 나타난다.

시간당 한 번 실행되는 배치 작업에서는 비용이 눈에 띄지 않지만, 몇 초마다 커밋하는 스트리밍 작업에서는 치명적이다. 메타데이터 쓰기가 지배적이고, 작은 파일이 쌓여 객체 스토어가 공유 프리픽스에 대한 요청을 제한하기 시작한다. 삭제 작업은 상황을 더욱 악화시킨다. Copy‑on‑write 방식에서는 삭제가 전체 매니페스트 재작성으로 이어질 수 있다. 커밋 간 매니페스트 캐싱도 파일이 계속 교체되면서 어려워진다.

v4의 해답은 Root Manifest를 중심으로 재구성된 메타데이터 트리다. Root Manifest는 기존 매니페스트 리스트를 대체하고, 각 스냅샷의 단일 진입점 역할을 한다. 계층 구조는 깔끔한 두 단계 형태로 축소된다.

Root Manifest → Data Manifests / Delete Manifests / Files

핵심 동작은 커밋 시 변경된 부분만 수정한다는 점이다. 메타데이터 성장량이 테이블 크기가 아니라 작업 규모에 비례한다. 하나의 파일을 쓰면 하나의 파일만 변경된다. 즉각적인 이점이 나타난다. 커밋이 빨라지고, 재작성 빈도가 줄어들며, 쿼리 플래닝도 개선된다. Root Manifest는 하위 매니페스트에서 파일 수준 메트릭을 집계할 수 있어 엔진이 플래닝 단계에서 더 일찍 프루닝할 수 있다.

“adaptive”(적응형)이라는 단어가 설계의 핵심이다. 이 제안은 모든 쓰기가 단일 파일 커밋이어야 한다고 강제하지 않는다. 작은 쓰기는 루트에 바로 인라인되어 저지연을 얻는다. 루트가 채워지면 백그라운드 유지보수가 엔트리를 리프 매니페스트로 재배치한다. 라이터는 재배치 비용을 자신에게 맞는 시점에 지불하도록 선택할 수 있다. 구조가 워크로드에 맞춰 스스로 적응한다. 스트리밍 테이블은 핫 쓰기를 루트 근처에 유지해 속도를 높이고, 배치 테이블