Databricks Unity Catalog Managed Iceberg GA: 테이블 포맷 잠금을 해제하고 크로스엔진 쓰기까지 열린 Lakehouse 거버넌스

왜 지금 이 이야기인가

Lakehouse 아키텍처가 성숙해지면서 조직이 현실적인 벽에 부딪혔다. 테이블 포맷 잠금이다.

Databricks 안에서 Delta Lake로 쌓은 테이블은 외부 Spark 클러스터나 Trino로 직접 읽기가 어렵다. 반대로 다른 카탈로그의 Iceberg 테이블을 Unity Catalog에서 거버넌스하려면 복잡한 우회로가 필요하다. 조직은 분석 엔진마다 데이터를 따로 관리하거나, 특정 플랫폼에 종속되거나, 두 가지 모두를 감수해야 했다.

2026년 6월 15일부터 18일까지 열린 Data + AI Summit에서 Databricks는 이 문제를 정면으로 다루는 GA 발표를 했다. 핵심 메시지는 하나였다. "테이블 포맷 잠금을 해제한다."

세 가지가 동시에 GA로 전환됐다.

• Managed Iceberg: Unity Catalog 안에서 Apache Iceberg 테이블을 완전 관리한다.
• Iceberg v3: 삭제 벡터·행 추적·VARIANT 타입을 포함한 최신 스펙을 Databricks 환경에서 쓴다.
• Foreign Iceberg: 다른 카탈로그에 있는 Iceberg 테이블을 Unity Catalog로 거버넌스한다.

배경: 포맷 잠금이 왜 문제였나

데이터 플랫폼이 커질수록 엔진 다양성이 늘어난다. 배치 변환에는 Spark, 대화형 분석에는 Trino나 DuckDB, BI에는 Tableau나 Power BI, 그리고 외부 파트너를 위한 데이터 공유 채널이 필요하다.

이 환경에서 Delta Lake 테이블은 다음과 같은 제약을 만든다.

• Spark 이외의 엔진이 Delta 포맷을 네이티브로 지원하지 않으면 읽기가 불가능하다.
• 외부 엔진이 쓰기를 시도하면 트랜잭션 로그 충돌 위험이 있다.
• 동일 데이터를 여러 포맷으로 복제하면 저장소 비용과 일관성 문제가 함께 생긴다.

Apache Iceberg REST 카탈로그 표준이 이 문제의 해결책으로 떠올랐지만, 표준이 있다고 구현이 자동으로 따라오지 않는다. Unity Catalog가 이 표준을 완전히 구현하고 GA로 올리기까지가 이번 발표의 핵심이다.

1. Managed Iceberg: Unity Catalog 안에서 Iceberg를 완전히 운영한다

GA 이전 상황

Managed Iceberg가 GA 되기 전까지 Unity Catalog에서 Iceberg를 쓰는 방법은 제한적이었다. Delta Lake 테이블에 UniForm을 활성화해 Iceberg 메타데이터를 병행 생성하거나, 외부 Iceberg 카탈로그를 따로 운영하는 방식이 주류였다. 두 방법 모두 완전한 통합이 아니었다.

GA에서 달라진 것

Managed Iceberg GA는 Unity Catalog 안에서 Iceberg 테이블의 전체 라이프사이클을 직접 관리한다는 뜻이다. 구체적으로 다음 작업이 Unity Catalog 내에서 이루어진다.

• 생성: CREATE TABLE ... USING ICEBERG 형식으로 Unity Catalog에 Iceberg 테이블을 만든다.
• 읽기·쓰기: Databricks SQL, Spark에서 네이티브로 읽고 쓴다. 외부 엔진은 Iceberg REST Catalog API를 통해 접근한다.
• 최적화: Predictive Optimization과 Liquid Clustering이 자동 적용된다.
• 거버넌스: Column-level security, row-level filtering, audit log가 Delta 테이블과 동일하게 적용된다.
• 공유: Delta Sharing으로 외부 조직과 Iceberg 테이블을 공유한다.

Predictive Optimization과 Liquid Clustering

이 두 기능은 Managed Iceberg에서 수동 유지 관리 작업을 제거한다.

Predictive Optimization은 테이블의 쿼리 패턴을 분석해 어떤 최적화가 필요한지, 언제 실행할지를 자동으로 결정한다. OPTIMIZE, VACUUM, ANALYZE STATISTICS 같은 명령을 일일이 스케줄링하지 않아도 된다. 워크로드 패턴이 바뀌면 최적화 전략도 함께 바뀐다.

Liquid Clustering은 데이터를 물리적으로 배치하는 방법을 자동으로 선택한다. CLUSTER BY AUTO 옵션을 사용하면 Databricks가 쿼리 로그를 분석해 클러스터링 키를 자동으로 선택한다. Hive 스타일의 정적 파티셔닝과 달리, 초기 설계 결정이 잘못됐을 때 재파티셔닝 없이 클러스터링 기준을 바꿀 수 있다.

Databricks 발표 기준으로 이 두 기능의 조합은 최대 20배 쿼리 속도 향상과 50% 스토리지 비용 절감을 가져온다고 한다. 실제 환경에서의 결과는 데이터 특성과 쿼리 패턴에 따라 다르다.

2. Iceberg v3: 삭제 벡터, 행 추적, VARIANT 타입

Apache Iceberg v3 스펙이 Databricks 환경에서 GA됐다. 세 가지 주요 기능이 Managed Iceberg, Foreign Iceberg, UniForm 테이블 모두에서 사용 가능하다.

삭제 벡터 (Deletion Vectors)

Iceberg v1/v2에서 행 삭제는 기존 파일에 마커를 남기거나 파일을 다시 쓰는 방식이었다. v3의 삭제 벡터는 삭제된 행의 위치를 별도 파일(DV 파일)에 비트맵 형태로 기록한다.

이 방식의 장점은 쓰기 성능이다. 하나의 행을 삭제하기 위해 수백 MB 파일을 다시 쓸 필요 없이 작은 DV 파일만 추가된다. DELETE FROM, MERGE INTO(upsert) 작업이 크게 빨라진다.

읽기 시에는 DV 파일을 참조해 삭제된 행을 건너뛴다. 쿼리 엔진이 DV 형식을 이해해야 하므로, 삭제 벡터를 사용하는 테이블을 읽으려면 엔진이 Iceberg v3를 지원해야 한다.

행 추적 (Row Tracking)

행마다 고유한 식별자를 부여한다. 파티셔닝이나 컬럼파닝 없이도 특정 행의 변경 이력을 추적할 수 있다. CDC(변경 데이터 캡처) 파이프라인에서 소스 행과 타깃 행을 정확히 매핑할 때 유용하다.

행 추적은 증분 처리의 정확성을 높인다. 특히 대용량 테이블에서 변경된 행만 다운스트림에 전달하는 파이프라인 설계가 단순해진다.

VARIANT 타입

반정형(semi-structured) 데이터를 위한 네이티브 타입이다. JSON, XML 같은 구조가 일정하지 않은 데이터를 하나의 열에 저장하되, 내부 필드별로 효율적으로 쿼리할 수 있다.

기존에는 JSON을 STRING 열에 저장하고 쿼리 시 파싱하거나, 가능한 모든 필드를 미리 정의한 스키마로 펼치는 방법을 썼다. VARIANT는 이 두 방법의 중간이다. 스키마를 미리 정의하지 않아도 되고, 필드 접근은 일반 컬럼처럼 빠르다.

3. Foreign Iceberg: 다른 카탈로그의 테이블도 Unity Catalog로 거버넌스한다

문제

조직이 여러 데이터 카탈로그를 운영하는 경우는 흔하다. AWS Glue Catalog, Apache Polaris, Nessie, Snowflake의 Horizon 등 각기 다른 카탈로그에 테이블이 분산돼 있을 수 있다. 이 테이블들에 Unity Catalog의 거버넌스(접근 제어, 감사 로그, 데이터 공유)를 적용하려면 데이터를 Unity Catalog로 이동해야 했다.

Foreign Iceberg GA의 역할

Foreign Iceberg는 외부 카탈로그의 Iceberg 테이블을 Unity Catalog에 등록해 거버넌스를 적용한다. 데이터 이동 없이 메타데이터 레벨에서 통합한다.

Credential Vending이 핵심 메커니즘이다. Unity Catalog가 외부 엔진에게 임시 자격증명(단기 토큰)을 발급한다. 외부 엔진은 이 자격증명으로 스토리지에 직접 접근한다. Unity Catalog는 이 과정에서 누가, 언제, 어떤 테이블에 접근했는지를 기록한다.

외부 카탈로그에서 Foreign Iceberg를 통해 Unity Catalog에 등록한 테이블은 다음 기능을 얻는다.

• Unity Catalog의 RBAC / 컬럼 레벨 보안 적용
• Audit log 통합
• Delta Sharing으로 외부 공유

단, Foreign Iceberg는 Unity Catalog가 테이블 파일을 소유하지 않는다. Predictive Optimization, Liquid Clustering 같은 관리형 최적화는 적용되지 않는다.

4. UniForm: Delta Lake와 Iceberg를 동시에

UniForm(Universal Format)은 Delta Lake 테이블에 Iceberg 메타데이터를 병행 생성하는 기능이다. 데이터 파일은 Delta 포맷으로 유지되지만, 외부 엔진은 Iceberg REST Catalog API를 통해 같은 데이터를 읽을 수 있다.

Delta 테이블
├── data/                 # Parquet 파일 (Delta + Iceberg 공유)
├── _delta_log/           # Delta 트랜잭션 로그
└── metadata/             # Iceberg 메타데이터 (UniForm이 자동 생성)
    ├── v1.metadata.json
    └── snap-*.avro

UniForm의 장점은 마이그레이션 없이 점진적 전환을 지원한다는 점이다. 기존 Delta 워크로드를 바꾸지 않고 외부 엔진에 Iceberg 인터페이스를 열 수 있다.

제약은 명확하다. 외부 엔진의 UniForm 접근은 읽기 전용이다. 쓰기는 Delta 경로(Spark, Databricks SQL)를 통해서만 가능하다. 완전한 크로스엔진 쓰기가 필요하다면 Managed Iceberg를 써야 한다.

5. 크로스엔진 읽기·쓰기 매트릭스

Managed Iceberg + Trino의 조합이 완전한 크로스엔진 쓰기를 지원하는 첫 번째 케이스다. Trino가 Unity Catalog의 Iceberg REST Catalog API를 통해 테이블에 쓸 수 있다.

6. 운영자가 확인해야 할 것

Managed Iceberg 도입 시

• 기존 Delta 테이블 마이그레이션: Delta → Managed Iceberg 전환은 데이터 재작성이 필요하다. 대용량 테이블의 경우 downtime 없이 마이그레이션하는 전략을 세워야 한다.
• 엔진 호환성: Iceberg v3 기능(Deletion Vectors, Row Tracking, VARIANT)을 사용하는 테이블은 Iceberg v3를 지원하는 엔진에서만 읽을 수 있다. 팀 내 모든 엔진이 업데이트됐는지 확인이 필요하다.
• Predictive Optimization 비용: 자동 최적화는 편리하지만 추가 컴퓨팅 비용이 발생한다. 최적화 빈도와 규모를 모니터링해야 한다.

Foreign Iceberg 도입 시

• Credential Vending 만료 정책: 임시 자격증명의 유효 기간과 갱신 주기를 파악해야 한다. 자격증명이 만료되면 외부 엔진의 작업이 중단된다.
• 감사 로그 범위: Foreign Iceberg를 통한 접근이 Unity Catalog 감사 로그에 기록되지만, 외부 카탈로그 자체의 로그와 이중 기록이 발생할 수 있다. 어느 쪽을 단일 출처로 쓸지 정의해야 한다.
• 최적화 책임: Foreign Iceberg 테이블의 OPTIMIZE, VACUUM은 외부 카탈로그 측에서 관리해야 한다. Unity Catalog는 거버넌스만 담당한다.

UniForm 도입 시

• 메타데이터 동기화 지연: Delta 쓰기 후 Iceberg 메타데이터가 업데이트될 때까지 외부 엔진에서 최신 데이터를 볼 수 없는 지연이 있을 수 있다. 실시간 읽기가 중요한 워크로드에서 이 지연을 확인해야 한다.
• 외부 쓰기 방지: UniForm 테이블을 외부 엔진이 쓰지 못하도록 접근 제어를 설정해야 한다. Delta 트랜잭션 로그와 충돌이 발생하면 데이터 손상 위험이 있다.

7. Delta Lake vs Managed Iceberg: 어떤 것을 써야 하나

Managed Iceberg GA 이후로도 Delta Lake가 기본 포맷이 사라지지 않는다. 두 포맷 중 무엇을 선택할지는 환경에 따라 다르다.

Delta Lake를 계속 쓰는 경우

• 기존 Databricks 워크로드가 Delta에 의존하고 있고, 외부 엔진 쓰기 요구사항이 없다.
• Delta-specific 기능(Change Data Feed, Deletion Vectors via Delta)이 필요하다.
• 마이그레이션 비용보다 현상 유지 편익이 크다.

Managed Iceberg로 전환하는 경우

• Trino, EMR, DuckDB 등 Iceberg를 기본 포맷으로 쓰는 엔진에서 쓰기가 필요하다.
• 조직이 멀티클라우드 환경이고 특정 벤더에 대한 의존성을 줄이고 싶다.
• Iceberg REST Catalog 표준을 기반으로 새 데이터 플랫폼을 설계하는 단계다.

UniForm으로 병행하는 경우

• 내부 Delta 워크로드는 유지하면서, 외부 파트너나 다른 팀에 Iceberg 인터페이스를 제공해야 한다.
• Iceberg 읽기가 필요하지만 Delta → Iceberg 완전 마이그레이션은 당장 할 수 없다.

마무리

Unity Catalog Managed Iceberg GA는 데이터 플랫폼 생태계에서 오랫동안 해결되지 않았던 문제에 대한 구체적인 답이다. 테이블 포맷 잠금을 해제하고, 외부 엔진의 읽기뿐 아니라 일부 쓰기까지 허용하면서, 거버넌스 경계는 Unity Catalog 안에서 단일하게 관리한다.

Iceberg v3(삭제 벡터·행 추적·VARIANT), Predictive Optimization, Liquid Clustering의 조합은 Managed Iceberg 테이블이 단순한 오픈 포맷이 아니라 완전히 관리되는 데이터 자산이 됐음을 의미한다.

이 구조가 완전히 자리 잡으면, 분석 팀이 쓰는 엔진이 Spark든 Trino든 DuckDB든 상관없이 같은 테이블 위에서 작업하는 환경이 가능해진다. 다만 실제 다중 엔진 쓰기 환경에서의 동시성 충돌, 메타데이터 동기화 지연, 자격증명 관리 복잡성은 운영 경험이 쌓여야 명확해질 영역이다.

References

• Databricks Blog, "Advancing Apache Iceberg on Databricks: Iceberg v3 GA, Open Sharing, and Unified Governance": https://www.databricks.com/blog/unity-catalog-and-next-era-apache-icebergtm
• Databricks Blog, "What's new with Unity Catalog at Data + AI Summit 2026": https://www.databricks.com/blog/whats-new-unity-catalog-data-ai-summit-2026
• Databricks Blog, "Expanded interoperability with Unity Catalog Open APIs": https://www.databricks.com/blog/expanded-interoperability-unity-catalog-open-apis
• Databricks Blog, "The next era of the open lakehouse: Apache Iceberg™ v3 in Public Preview on Databricks": https://www.databricks.com/blog/next-era-open-lakehouse-apache-icebergtm-v3-public-preview-databricks
• Databricks Press Release, "Databricks Eliminates Table Format Lock-in and Adds Capabilities": https://www.databricks.com/company/newsroom/press-releases/databricks-eliminates-table-format-lock-and-adds-capabilities
• StartupHub.ai, "Databricks Touts Unity Catalog for Iceberg" (2026): https://www.startuphub.ai/ai-news/technology/2026/databricks-touts-unity-catalog-for-iceberg
• Databricks Docs, "Predictive optimization for Unity Catalog managed tables": https://docs.databricks.com/aws/en/optimizations/predictive-optimization
• Databricks Docs, "Use liquid clustering for tables": https://docs.databricks.com/aws/en/tables/clustering
• amdatalakehouse.substack.com, "Lakehouse Table Formats in 2026: Iceberg, Delta Lake, Hudi, Paimon, and DuckLake": https://amdatalakehouse.substack.com/p/lakehouse-table-formats-in-2026-iceberg