Iceberg 생태계 — REST 카탈로그와 멀티 엔진 지원
Delta Lake vs Iceberg 2026: Which Table Format Wins? — 미상 (실전 프로덕션 경험 기반 블로그, 2026) Head-to-Head Comparison 표의 Engine Support/Catalog/Community 행 (p.7), The Ecosystem Reality (pp.9-10)
이 모듈을 다 읽으면
- Iceberg가 엔진에 종속되지 않도록 설계된 배경과 이를 뒷받침하는 카탈로그 옵션들을 설명할 수 있다
- REST 카탈로그 스펙이 사실상 표준이 된 배경과 이것이 벤더 종속을 낮추는 원리를 설명할 수 있다
- Databricks의 Tabular 인수와 Unity Catalog의 Iceberg REST 지원이 '두 진영' 구도를 어떻게 흐리는지 판단할 수 있다
Iceberg는 넷플릭스에서 시작해 아파치 재단에 기증된 이후 Spark, Trino, Flink, Dremio, Athena, BigQuery, Snowflake 등 폭넓은 엔진 지원을 확보했다. 카탈로그는 Hive Metastore, AWS Glue, Nessie, REST 카탈로그 스펙, Apache Polaris 등 다양한 선택지가 있으며 REST 카탈로그 스펙이 사실상 업계 표준으로 자리잡고 있다. 다만 원문이 'Databricks 진영 vs Iceberg 진영'으로 단순화한 구도는, Databricks의 Tabular 인수와 Unity Catalog의 오픈소스화 및 Iceberg REST 호환성 확보로 인해 실제로는 훨씬 더 흐릿해졌다.
엔진 독립적으로 설계된 이유
Apache Iceberg는 넷플릭스가 페타바이트 규모 데이터 레이크를 운영하며 겪은 문제를 해결하기 위해 처음부터 설계되었고, 이후 아파치 소프트웨어 재단에 기증되었다. 이런 출발점 덕분에 Iceberg는 처음부터 특정 벤더나 특정 엔진에 종속되지 않는 것을 설계 목표로 삼았다.
그 결과 Spark, Trino, Flink, Dremio, Athena, BigQuery, Snowflake 등 서로 다른 벤더의 엔진들이 Iceberg 테이블을 읽고 쓸 수 있는 성숙한 커넥터를 제공한다. 여러 엔진을 함께 쓰는 아키텍처(예: 적재는 Flink, 대화형 분석은 Trino, 배치는 Spark)이거나 스토리지 레이어를 특정 벤더에 묶고 싶지 않은 조직이라면 이 점이 실질적인 장점이 된다.
핵심 포인트
- Iceberg는 넷플릭스가 페타바이트 규모 데이터 레이크 문제 해결을 위해 설계했고 이후 아파치 재단에 기증했다
- Spark, Trino, Flink, Dremio, Athena, BigQuery, Snowflake 등 폭넓은 엔진이 성숙한 Iceberg 지원을 제공한다
- 여러 엔진을 함께 쓰거나 벤더 종속을 피하려는 아키텍처에서 Iceberg의 엔진 독립성이 실질적 이점이 된다
카탈로그의 역할과 옵션들
카탈로그는 '테이블 이름 → 현재 메타데이터 파일 위치' 매핑을 관리하고, 낙관적 동시성 제어에서 설명한 원자적 포인터 교체를 실제로 수행하는 주체다. Iceberg는 이 카탈로그 구현을 여러 가지 중에서 선택할 수 있게 열어두었다.
Hive Metastore는 가장 오래된 선택지로 기존 Hadoop 생태계와 호환성이 좋다. AWS Glue Catalog는 AWS 네이티브 서비스와 잘 통합된다. Nessie는 Git과 유사한 브랜치/커밋 개념을 카탈로그에 도입해 여러 테이블에 걸친 원자적 커밋과 브랜치 기반 실험을 가능하게 한다. REST 카탈로그는 특정 구현이 아니라 HTTP 기반의 카탈로그 API '스펙'으로, 이 스펙을 구현하기만 하면 어떤 카탈로그 백엔드든 같은 방식으로 접근할 수 있게 해준다. Apache Polaris는 Snowflake가 2024년 오픈소스로 공개한 뒤 아파치 소프트웨어 재단에 기증한 REST 카탈로그 구현체다.
핵심 포인트
- 카탈로그는 '테이블 이름 → 현재 메타데이터 위치' 매핑과 원자적 포인터 교체를 담당하는 핵심 컴포넌트다
- Hive Metastore, AWS Glue, Nessie(Git과 유사한 브랜치/커밋 개념), REST 카탈로그, Apache Polaris(Snowflake가 오픈소스화 후 아파치에 기증)가 대표적인 선택지다
- REST 카탈로그는 특정 구현체가 아니라 HTTP 기반 API 스펙이며, 이를 구현한 카탈로그끼리는 상호 호환된다
생태계 재편 — 정정/업데이트
정정/업데이트 — 원문은 'Databricks 진영(Unity Catalog)'과 'Iceberg 진영(REST 카탈로그, Nessie, Polaris)'을 서로 분리된 두 진영으로 대비시킨다. 이 구도는 2024년 이후 상당히 흐려졌다.
첫째, Databricks는 2024년 Tabular를 인수했다. Tabular는 Iceberg의 원 창시자(Ryan Blue를 비롯한 Iceberg PMC 멤버들)가 넷플릭스와 애플을 거쳐 만든 회사로, 이 인수를 통해 Databricks는 Iceberg 프로젝트에 대한 핵심 전문성을 사내에 확보했다.
둘째, Databricks는 2024년 Unity Catalog를 오픈소스로 공개했고, 이후 Iceberg REST 카탈로그(IRC) API 호환성을 추가했다. 즉 Unity Catalog 자체가 Iceberg REST 카탈로그로서 동작할 수 있게 되어, Databricks 바깥의 엔진(Trino, Spark 등)이 Unity Catalog에 등록된 테이블을 표준 Iceberg REST 프로토콜로 읽고 쓸 수 있는 경로가 열렸다. 이는 Delta Lake UniForm(Delta 메타데이터 옆에 Iceberg 호환 메타데이터를 함께 쓰는 기능)과 맞물려, '이 테이블을 만든 조직이 Databricks냐 아니냐'와 '이 테이블을 Iceberg 프로토콜로 읽을 수 있느냐'가 점점 별개의 질문이 되어가고 있음을 보여준다.
따라서 원문의 '두 진영' 프레이밍은 방향성(생태계가 갈려 있었던 역사적 배경)은 맞지만, 현재 시점에서는 경계가 명확한 진영 대립이라기보다 여러 겹의 상호운용성 레이어가 겹쳐진 상태로 이해하는 것이 더 정확하다.
핵심 포인트
- Databricks는 2024년 Iceberg 원 창시자들의 회사 Tabular를 인수해 Iceberg 핵심 전문성을 확보했다
- Databricks가 오픈소스화한 Unity Catalog는 Iceberg REST 카탈로그(IRC) API를 지원해, Databricks 밖의 엔진도 표준 프로토콜로 접근할 수 있다
- 'Databricks 진영 vs Iceberg 진영'이라는 이분법은 낡은 프레이밍이며, 실제로는 여러 상호운용성 레이어가 겹쳐진 상태로 봐야 한다
그래도 오늘은 하나를 선택해야 한다
UniForm, Iceberg REST 호환 Unity Catalog, Apache XTable(구 OneTable, 포맷 간 메타데이터를 번역해주는 프로젝트) 같은 수렴 흐름이 있다고 해서 '포맷 선택이 더 이상 중요하지 않다'는 뜻은 아니다. 이런 변환/호환 레이어는 그 자체로 추가적인 운영 복잡성(동기화 지연, 변환 실패 시 디버깅 난이도)을 만든다. 오늘 파이프라인을 설계하는 입장에서는 여전히 하나의 주력 포맷을 정하고 그에 맞춰 도구 체계를 구축해야 한다는 원문의 결론은 타당하다.
핵심 포인트
- 포맷 간 호환/변환 레이어(UniForm, XTable 등)의 존재가 포맷 선택의 중요성을 없애지는 않는다
- 호환 레이어 자체가 동기화 지연, 변환 실패 등 새로운 운영 복잡성을 만들 수 있다