Apache Iceberg v3와 통합 카탈로그가 바꾸는 레이크하우스 운영

Iceberg v3가 레이크하우스에 가져온 변화

2026년 6월 데이터+AI 서밋에서 Apache Iceberg v3와 Managed Iceberg가 정식 출시(GA)됐다. 4년간 커뮤니티가 다듬은 v3 스펙은 삭제 벡터, 로우 리니지, VARIANT 타입을 상용 엔진에 안착시켰고, Unity Catalog는 Delta Lake와 Iceberg를 함께 관리하는 거버넌스 계층으로 확장됐다.

Apache Iceberg v3는 Snowflake에서 2026년 5월 7일, Databricks Runtime 18.0+에서는 6월 데이터+AI 서밋을 거쳐 정식 출시됐다. v2가 머지온리드(Merge-on-Read)와 행 수준 삭제를 도입했다면, v3는 레이크하우스를 분석 스토리지에 그치지 않고 트랜잭션, CDC, 반정형 데이터를 다루는 통합 데이터 플랫폼으로 넓힌 변화다.

기능	설명	효과
Deletion Vectors	위치 삭제 파일을 이진 비트맵으로 대체	DML 최대 10배 가속, O(1) 조회
Row Lineage	`_row_id`·`_last_updated_sequence_number` 추적	네이티브 CDC, 증분 처리
VARIANT 타입	반정형(JSON 등) 데이터 네이티브 저장	스키마리스 워크로드 통합
Default Values	컬럼 기본값 정의	무중단 스키마 진화
Geometry/Geography	공간 데이터 타입	지리정보 분석
Nanosecond Timestamp	나노초 정밀 시간	고빈도 시계열
Multi-arg Partition	다중 인자 파티션 변환	유연한 파티셔닝

이 가운데 삭제 벡터와 로우 리니지는 업데이트·삭제, 변경 추적에 들던 비용을 메타데이터 연산 수준으로 옮기는 핵심 기능이다.

삭제와 변경 이력을 메타데이터로 다루는 방식

위치 삭제 파일을 대체하는 삭제 벡터

v2의 위치 삭제(positional delete)는 삭제 대상 행의 위치를 별도 파일에 기록했다. 읽을 때 이 파일을 정렬하고 병합해야 하므로 O(log n) 비용이 들며, 삭제가 쌓이면 작은 파일도 급증했다.

v3의 삭제 벡터는 행 위치를 Roaring Bitmap 기반 이진 비트맵으로 인코딩한다. 데이터 파일 하나와 삭제 벡터 하나가 1:1로 연결되고, 읽기 시점 조회는 O(1)로 내려간다. copy-on-write와 비교하면 DML은 최대 10배 빨라진다.

행 단위 변경을 추적하는 로우 리니지

v3 이상 테이블은 새로 생성하는 모든 행의 로우 리니지 필드를 추적해야 한다. 엔진은 데이터 파일을 기록할 때 테이블 수준의 next-row-id를 관리하고, 각 행에는 다음 필드를 유지한다.

_row_id: 테이블 안의 모든 행을 구분하는 고유 식별자
_last_updated_sequence_number: 해당 행을 마지막으로 갱신한 커밋의 시퀀스 번호

외부 CDC 도구 없이도 어떤 행이 언제 바뀌었는지를 메타데이터만으로 판별할 수 있다. 증분 ETL과 머티리얼라이즈드 뷰 갱신도 네이티브로 가능해진다.

⤢✕

Unity Catalog와 Polaris가 맡는 통합 거버넌스

2026년의 큰 변화는 테이블 포맷만의 이야기가 아니다. Databricks는 데이터+AI 서밋에서 Managed Iceberg를 GA로 발표했고, Unity Catalog 안에서 Iceberg 테이블의 생성, 읽기, 쓰기, 최적화, 거버넌스, 공유를 직접 수행할 수 있게 했다.

Managed Iceberg(GA): UC가 관리하는 모든 테이블은 자동으로 최적화되고, 개방형 API를 통해 거버넌스되며, 어떤 엔진에서도 접근할 수 있다.
Predictive Optimization: AI가 유지보수가 필요한 테이블을 판단하고 워크로드 패턴에 맞춰 데이터 레이아웃을 적응시킨다.
Liquid Clustering: 최적 클러스터링 키를 자동으로 선정해 모든 엔진의 성능을 높이고, 수작업 파티셔닝과 OPTIMIZE 부담을 없앤다.
Foreign Iceberg + Credential Vending(GA): Databricks 외부에서 관리되는 Iceberg 테이블도 UC 개방형 API로 안전하게 거버넌스한다.
External Sharing to Iceberg clients(GA): Delta Sharing 프로토콜로 Iceberg REST 호환 클라이언트와 라이브 데이터를 공유한다.

Snowflake는 Horizon Catalog를 Apache Polaris 위에서 운영하며, Snowflake 관리 Iceberg 테이블에 외부 엔진이 양방향 읽기·쓰기로 접근하도록 했다. Apache Polaris는 2026년 2월 최상위 프로젝트로 졸업했고 Iceberg뿐 아니라 Delta Lake까지 지원을 넓혔다. Unity Catalog, AWS Glue, Hive Metastore의 테이블을 단일 창(single pane of glass)으로 묶는 방향이다.

⤢✕

포맷보다 카탈로그 경계를 먼저 설계할 때

레이크하우스 표준화를 추진한다면, 신규 워크로드는 Iceberg v3를 기본값으로 두고 기존 Delta 자산에는 UniForm으로 Iceberg 메타데이터를 병행 생성하는 방식을 고려할 수 있다. 데이터 중복 없이 양쪽 클라이언트가 읽을 수 있기 때문이다.

분산된 Glue, Hive, Unity, Polaris 카탈로그는 개방형 REST 카탈로그 스펙으로 수렴시키고, ABAC와 컬럼·행 마스킹 같은 거버넌스 정책은 카탈로그 계층에서 단일하게 정의한다. Spark, Flink, Trino, Snowflake, BigQuery가 같은 테이블을 동시에 읽고 쓰는 환경이라면 REST 카탈로그와 Credential Vending으로 접근 경로를 표준화한다.

스토리지와 파티셔닝도 이 흐름에 맞춰 운영할 수 있다. 삭제 벡터로 작은 파일의 급증을 억제하고, Predictive Optimization과 Liquid Clustering으로 OPTIMIZE와 compaction을 자동화하면 수동 파티션 튜닝 비용이 사라진다.

핵심은 특정 포맷에 고정되지 않는 것이다. Delta UniForm(GA), Hudi 네이티브 Iceberg 지원, Apache XTable은 모두 포맷 간 변환을 제공한다. 따라서 포맷 선택보다 카탈로그 거버넌스를 어디에 둘지가 더 본질적인 의사결정이 된다.

Delta Lake와 Hudi 사이에서 보는 Iceberg v3

항목	Apache Iceberg v3	Delta Lake	Apache Hudi
파티션 진화	✅ 메타데이터 연산	제한적	제한적
스키마 진화	✅ 불변 ID 기반 최강	컬럼 매핑(부분)	지원
멀티 엔진 지원	✅ 가장 넓음	Databricks 중심 강세	중간
고빈도 업서트	삭제 벡터로 개선	양호	✅ 가장 성숙
카탈로그 표준	✅ REST(Polaris)	UniForm으로 상호운용	XTable 의존
거버넌스	✅ 벤더 중립	Unity Catalog	외부 카탈로그

2026년 현재 Iceberg는 Spark, Flink, Trino, Snowflake, BigQuery, DuckDB에 걸친 멀티 엔진 지원과 벤더 중립 거버넌스, 파티션 진화를 강점으로 사실상 산업 표준으로 자리잡았다. 모든 차원에서 기술적으로 우월해서가 아니라, 엔진 지원 폭과 벤더 중립 거버넌스가 가장 강하기 때문이다.

Delta Lake는 Databricks 생태계에서 여전히 강력하며 UniForm으로 Iceberg와 상호운용한다. Hudi는 고빈도 스트리밍 업서트에서 가장 성숙한 도구를 갖췄다. Iceberg v4는 적응형 메타데이터 트리로 재설계되고, Delta 5.0은 같은 메타데이터 구조를 채택해 상호운용과 성능의 트레이드오프를 제거하는 수렴(convergence)을 예고하고 있다.