BigQuery와 Iceberg 엔진을 잇는 서버리스 REST 카탈로그

BigQuery의 서버리스 Iceberg REST 카탈로그로 Spark·Flink·Trino와 단일 테이블을 공유하는 레이크하우스 구조를 분석한다.

2026-08-14 · 최초 발행 2026-08-02

하나의 Iceberg 테이블을 여러 엔진이 함께 다루는 방식

Google Cloud는 BigQuery와 Iceberg 호환 엔진 사이의 양방향 읽기·쓰기 상호운용을 프리뷰로 공개했다. 중심에는 Google 관리형 서버리스 Iceberg REST 카탈로그가 있다. BigQuery뿐 아니라 Apache Spark, Flink, Trino, Hive 및 네이티브 Iceberg 라이브러리를 사용하는 엔진이 같은 Iceberg 테이블을 생성·갱신·조회하는 구조다.

이 카탈로그는 과거 BigLake metastore라는 이름으로 제공됐고, 2026년 4월 20일부터 BigLake는 Lakehouse for Apache Iceberg, BigLake metastore는 Lakehouse runtime catalog로 리브랜딩됐다.

기존에는 BigQuery가 관리하는 Iceberg 테이블에 외부 엔진이 직접 쓰기 어려웠다. Spark ETL 결과를 BigQuery로 다시 적재하거나 별도 사본을 유지해야 했던 이유다. 이번 프리뷰는 Iceberg REST 프로토콜을 경계로 삼아 그 단방향 구조를 양방향으로 바꾼다.

REST 카탈로그가 메타데이터 경계를 표준화한다

Iceberg REST Catalog Specification은 테이블 탐색, 메타데이터 조회, 커밋 조정을 HTTP REST 엔드포인트로 정의한다. REST 명세를 구현한 클라이언트라면 엔진 종류에 관계없이 같은 방식으로 카탈로그에 접근할 수 있다. Hive Metastore처럼 특정 엔진에 묶인 메타스토어 대신 개방형 인터페이스를 두는 접근이다.

Iceberg 1.10 릴리스에서는 REST API 성숙화에 Google이 직접 기여했다.

스토리지 계층카탈로그 계층분석 엔진 계층REST API 읽기·쓰기REST API 읽기·쓰기REST API 읽기·쓰기REST API 읽기·쓰기메타데이터 포인터 관리BigQueryApache SparkApache FlinkTrino서버리스 Iceberg REST카탈로그 (Lakehouseruntime catalog)Cloud Storage (Parquet데이터 파일 + Iceberg메타데이터)

실제 데이터는 고객 소유 Cloud Storage 버킷에 Parquet 파일과 Iceberg 메타데이터로 남고, 카탈로그는 현재 상태를 가리키는 메타데이터 포인터를 관리한다. 각 엔진은 Spark Iceberg Runtime이나 Flink Iceberg Connector 같은 자체 Iceberg 커넥터로 접속하므로, BigQuery 전용 변환 계층을 별도로 둘 필요가 없다.

카탈로그가 단일 진실 공급원 역할을 맡으면 엔진별 메타데이터 동기화 작업도 줄어든다. 어느 엔진에서 커밋하더라도 다른 엔진은 카탈로그를 통해 최신 상태를 조회한다.

스냅샷과 스키마 변경은 데이터 파일을 다시 쓰지 않는다

Iceberg의 스냅샷 격리는 낙관적 동시성 제어를 바탕으로 한다. 쓰기 트랜잭션은 새 스냅샷을 만들고, 원자적 커밋으로 메타데이터 포인터를 교체한다. 여러 엔진이 동시에 쓰기를 시도하면 카탈로그가 커밋 충돌을 감지하고 재시도를 유도한다.

읽기 작업은 특정 스냅샷에 고정되므로 일관된 결과를 제공하며, 타임 트래블 조회도 지원한다.

스키마 진화에서는 컬럼 추가·삭제·이름 변경·타입 확장을 데이터 파일 재작성 없이 메타데이터 변경으로 수행한다. 컬럼 ID 기반 매핑을 사용하므로 엔진마다 스키마를 다르게 해석할 가능성을 낮춘다. 한 엔진에서 바꾼 스키마는 카탈로그를 통해 다른 엔진에도 반영된다. 파티션 전략 역시 기존 데이터를 재구성하지 않고 변경할 수 있다.

Google은 메타데이터 관리, compaction, snapshot expiration, 동기화 작업을 관리형 서비스로 수행한다. 작은 파일 병합이나 고아 파일 정리 같은 자체 Iceberg 운영 부담을 줄이는 지점이다.

복제 파이프라인 대신 단일 사본을 둔다

엔진마다 최적화된 포맷을 유지하려고 ETL 파이프라인과 데이터 사본을 늘리면, 사본 간 정합성과 스토리지 비용이 함께 문제 된다. 단일 사본 원칙은 하나의 Iceberg 테이블을 모든 엔진이 직접 읽고 쓰게 하는 방식이다.

단일 사본 방식 (Iceberg REST 카탈로그)Spark / Flink / Trino단일 Iceberg 테이블BigQuery기존 방식 (사본 복제)Spark ETL레이크 사본적재 파이프라인BigQuery 사본

이 구조에서는 데이터 이동·복제 파이프라인을 줄여 아키텍처를 단순화하고, 스토리지 비용과 데이터 신선도 문제를 함께 다룰 수 있다. “어느 사본이 최신인가”라는 운영 문제도 단일 테이블을 기준으로 해소한다.

카탈로그 중심 구조는 거버넌스에도 영향을 준다. 카탈로그 수준에서 권한을 정의하면 여러 쿼리 엔진에 일관되게 적용할 수 있다. credential vending은 스토리지 접근용 단기 자격증명을 동적으로 발급하며, 사용자가 Cloud Storage 버킷에 직접 권한을 갖지 않아도 되게 한다. 최소 권한 원칙을 파일 수준까지 적용할 수 있는 구조다.

모든 엔진의 테이블 접근이 단일 카탈로그를 거치므로 감사 로그를 한곳에 모을 수 있다. Dataplex와 연계하면 데이터 계보와 품질 관리까지 통합한다.

개방형 포맷이 바꾸는 선택권

데이터는 고객 소유 버킷에 표준 Parquet와 Iceberg 메타데이터로 저장된다. 특정 벤더 포맷에 데이터를 묶어 두지 않는 포맷 개방성이 여기서 나온다. 표준 Iceberg REST API를 채택하면 카탈로그를 교체하거나 병행할 때의 마이그레이션 비용도 줄일 수 있다.

워크로드에 따라 BI에는 BigQuery, 스트리밍에는 Flink, 대화형 조회에는 Trino를 조합하는 선택도 가능하다. 하이퍼스케일러가 폐쇄 포맷 대신 개방형 표준을 1급 시민으로 채택하는 흐름으로 볼 수 있다.

Lakehouse for Apache Iceberg는 기존 BigLake managed Iceberg tables와도 연결된다. 이 테이블은 BigQuery가 메타데이터를 관리하고 데이터 파일은 GCS에 기록한다. 관리형 Spark의 Lightning Engine은 TPC-H 유사 벤치마크 기준으로 오픈소스 Spark보다 쿼리 성능을 4배 이상 가속한다. Google은 공개 데이터셋도 Iceberg 포맷으로 제공하기 시작했다.

BigQuery, Snowflake, Databricks의 접근 차이

구분 BigQuery (Google) Snowflake Databricks
기본 포맷 전략 Iceberg 네이티브 (REST 카탈로그 표준) Iceberg 지원 (자사 관리 카탈로그 중심) Delta Lake 기본 + UniForm으로 Iceberg 노출
카탈로그 서버리스 Iceberg REST 카탈로그 (Spanner 기반) Snowflake 관리 카탈로그, Polaris(오픈소스) Unity Catalog
외부 엔진 쓰기 양방향 읽기·쓰기 (프리뷰) 카탈로그 조정 필요, 제약 존재 UniForm은 Delta 쓰기 후 Iceberg 읽기 노출
데이터 위치 고객 소유 GCS 버킷 고객 클라우드 스토리지 고객 클라우드 스토리지
거버넌스 카탈로그 중앙 접근 제어 + credential vending Horizon 거버넌스 Unity Catalog 거버넌스

Snowflake는 2025년 4월부터 Iceberg 테이블 완전 네이티브 지원과 제로 카피 공유를 제공한다. 다만 Iceberg 지원은 기반 설계가 아닌 후방 통합(retrofit) 성격이라는 평가가 있다.

Databricks는 UniForm으로 Delta 테이블과 Iceberg 메타데이터를 함께 유지하며, Iceberg v3 퍼블릭 프리뷰를 진행하고 있다. 쓰기는 여전히 Delta 중심이다.

BigQuery의 차이는 REST 카탈로그 표준 프로토콜을 관리형 서비스로 제공한다는 데 있다. 반면 Snowflake Polaris 같은 외부 연합 카탈로그를 직접 연동하는 기능은 아직 지원하지 않아 성숙도 측면의 과제가 남아 있다.

Iceberg 네이티브Iceberg 채택 (관리 카탈로그)Delta 기반 + Iceberg 노출멀티 엔진 레이크하우스 요구기본 테이블 포맷 전략?BigQuery: 서버리스 REST카탈로그Snowflake: Horizon +PolarisDatabricks: UniForm +Unity Catalog표준 프로토콜 상호운용크로스 플랫폼 Iceberg 생태계수렴

레이크하우스 설계에서 확인할 지점

이 구조는 데이터 레이크하우스, Iceberg·Delta Lake·Hudi 같은 개방형 테이블 포맷, 메타데이터 관리 체계, 데이터 거버넌스를 함께 다룬다. 데이터 웨어하우스에서 데이터 레이크를 거쳐 레이크하우스로 발전하는 과정에서 테이블 포맷이 맡는 역할을 설명할 때도 연결된다.

ACID 트랜잭션, 스냅샷 격리, 스키마 진화는 레이크하우스의 핵심 기술 요소다. REST 카탈로그는 이기종 엔진 사이에서 상호운용성을 확보하는 메커니즘이 된다. 단일 카탈로그 기반 접근 제어 일원화는 DAMA-DMBOK의 메타데이터 관리·데이터 보안 영역과도 직접 연결되며, 단일 사본 원칙은 MDM의 골든 레코드 개념과 유사한 논리로 비교할 수 있다.

2026년에 이어지는 확장 방향

Google Next '26에서는 AWS, Azure, Databricks, Snowflake의 Iceberg 카탈로그를 가로지르는 크로스 클라우드 레이크하우스 쿼리 지원이 발표됐다. Iceberg 테이블을 AI/ML 파이프라인의 피처 저장소와 학습 데이터 소스로 직접 쓰는 방향도 강화되고 있다.

삭제 벡터(Deletion Vectors), 행 계보(Row Lineage) 같은 Iceberg v3 기능은 플랫폼 전반으로 확산되는 흐름이다. 프리뷰 기능이 정식 출시로 전환되면서 Polaris 같은 외부 연합 카탈로그 연동도 확대될 전망이다. 3대 플랫폼이 Iceberg를 중심으로 수렴하면서 경쟁의 중심은 포맷보다 카탈로그와 거버넌스로 이동하고 있다.

Sources

Apache IcebergBigQuery레이크하우스REST 카탈로그데이터 거버넌스