Apache Iceberg와 S3 Tables로 설계하는 레이크하우스 아키텍처

독립 컨퍼런스로 드러난 Iceberg 생태계의 변화

2026년 4월 8~9일 샌프란시스코 Marriott Marquis에서 Apache Iceberg 최초의 독립 컨퍼런스인 Iceberg Summit이 열렸다. 오픈소스 프로젝트를 넘어 별도 생태계를 형성했다는 점에서 상징적인 행사였다.

행사는 키노트와 패널 토론, 30분 브레이크아웃 세션, 15분 라이트닝 토크, 60~180분 핸즈온 워크샵으로 구성됐다. 워크샵을 제외한 세션은 모두 녹화·공개됐으며, 커뮤니티 기여자와 벤더, 실제 운영 사용자가 함께 참여했다.

Amazon S3 Tables for Iceberg는 2024년 말 출시 뒤 1년 만에 40만 개 테이블 호스팅을 돌파했다. 이는 클라우드 오브젝트 스토리지 위의 Iceberg 레이크하우스가 엔터프라이즈 워크로드를 대체하는 흐름과 맞닿아 있다.

일반 S3 버킷과 비교하면 S3 Tables는 쿼리 처리량이 3배 향상되고, 초당 트랜잭션 처리 능력은 10배 향상됐다. AWS 인프라가 메타데이터 관리를 맡으면서 소파일, 카탈로그 오버헤드, 동시 쓰기 충돌처럼 오브젝트 스토리지 기반 레이크에서 반복되던 문제를 다루는 방식이다.

메타데이터 계층에서 시작하는 Iceberg의 설계

Iceberg는 논리 테이블과 물리 데이터 파일을 계층적으로 분리한다. 이 메타데이터 구조가 스냅샷 버전 관리와 파티션·스키마 진화를 가능하게 한다.

⤢✕

스냅샷 체인으로 읽기와 쓰기를 분리한다

Iceberg에서 쓰기 작업은 새 스냅샷을 만든다. 스냅샷은 독립된 metadata.json 파일로 기록되고, 단조 증가하는 버전 번호를 따라 체인을 이룬다. 특정 시점이나 스냅샷 ID를 지정해 과거 데이터를 읽을 수 있는 이유도 여기에 있다.

-- 특정 시점 데이터 조회
SELECT * FROM orders FOR SYSTEM_TIME AS OF '2026-01-15 00:00:00';

-- 특정 스냅샷 ID로 조회
SELECT * FROM orders FOR VERSION AS OF 8765432109876543;

쓰기 트랜잭션이 진행 중이어도 읽기 쿼리는 이전 스냅샷을 일관되게 참조한다. 이 읽기·쓰기 격리가 오브젝트 스토리지 위에서 Serializable 수준의 ACID 트랜잭션을 구현하는 기반이다.

파티션 전략은 데이터 재작성 없이 바뀐다

Hive 방식에서는 파티션 컬럼을 바꾸려면 기존 데이터를 다시 써야 했다. Iceberg는 쿼리가 파티션 값을 직접 참조하지 않도록 하고, 파티션 스펙을 메타데이터에 기록한다. 기존 파일은 이전 스펙을 유지하고 새 데이터만 변경된 스펙으로 기록할 수 있다.

-- 기존: 월 단위 파티셔닝
ALTER TABLE events ADD PARTITION FIELD month(event_time);

-- 진화: 일 단위로 변경 (기존 데이터 재작성 불필요)
ALTER TABLE events DROP PARTITION FIELD month(event_time);
ALTER TABLE events ADD PARTITION FIELD day(event_time);

테이블 규모가 커진 뒤 일 단위에서 시간 단위로 세분화해야 하는 경우에도 다운타임 없이 대응할 수 있다.

스키마 변경과 파티션 프루닝을 메타데이터에 맡긴다

Iceberg의 스키마 진화는 제로카피 방식이다. 컬럼 추가·삭제·이름 변경·타입 변경은 메타데이터 계층에서 처리되며, 기존 데이터 파일을 수정하지 않는다. 각 파일은 작성 시점의 스키마를 보존하고, 읽을 때 메타데이터 계층이 버전 사이의 변환을 수행한다.

숨겨진 파티셔닝도 같은 방향의 설계다. event_time에 hour() 파티션 변환을 적용한 테이블이라면, 사용자는 WHERE event_time = '2026-04-08'만 작성해도 해당 날짜 파티션만 스캔한다.

워크로드에 따라 달라지는 테이블 포맷 선택

2026년 오픈 테이블 포맷 시장에서는 Iceberg의 사실상 표준화가 진행되는 한편, Hudi와 Delta Lake도 워크로드별 강점으로 공존한다.

항목	Apache Iceberg	Apache Hudi	Delta Lake
쓰기 성능	보통 (Append 최적화)	우수 (MoR Upsert)	우수 (Append)
타임 트래블	SQL 지원	지원	ACID 기반
CDC 지원	양호	최상 (Key 인덱싱)	양호
메타데이터 크기	최소 (데이터의 1% 미만)	중간	큼
멀티 엔진 지원	최고 (Spark, Flink, Trino, Snowflake, BigQuery, DuckDB)	우수	Spark 중심
동시 쓰기	우수	양호	양호
파티션 진화	완전 지원	지원	제한적
스키마 진화	제로카피	지원	제한적
거버넌스 구조	Apache (벤더 중립)	Apache	Databricks 주도

Iceberg는 여러 쿼리 엔진을 병행하는 환경, 파티션 전략이 자주 바뀌는 테이블, 메타데이터 오버헤드를 낮춰야 하는 대규모 테이블에 적합하다. AWS, GCP, Azure가 네이티브 지원을 확대하면서 이 위치를 강화하고 있다.

Hudi는 고빈도 Upsert와 CDC가 중심인 스트리밍 수집 워크로드에서 성숙도가 높다. Merge-on-Read(MoR)는 쓰기 지연을 최소화하면서 읽기 성능을 유지하는 데 쓰인다.

Delta Lake는 Databricks 플랫폼 중심 환경에서 통합성이 높다. Unity Catalog가 2024년 중반 오픈소싱되면서 생태계 확장을 시도하고 있으나, 멀티 엔진 지원에서는 Iceberg에 뒤처져 있다.

오브젝트 스토리지를 중심으로 계층을 분리한다

레이크하우스는 스토리지, 테이블 포맷, 메타데이터, 쿼리 실행을 분리해 구성한다. 이 경계가 엔진 교체와 확장을 가능하게 한다.

⤢✕

카탈로그가 제어 평면을 맡는다

카탈로그는 레이크하우스 데이터 자산의 기록 시스템(System of Record)이다. 2024~2026년 카탈로그 계층의 주요 변화는 Iceberg REST Catalog 스펙의 업계 표준화였다.

AWS Glue Catalog: S3 Tables와 통합, Iceberg 테이블 자동 관리
Databricks Unity Catalog: 2024년 오픈소싱, Iceberg/Delta Lake/Hudi 멀티 포맷 지원
Apache Polaris (incubating): Iceberg REST 카탈로그 레퍼런스 구현, 벤더 중립

표준화된 카탈로그 API는 쿼리 엔진과 카탈로그를 분리한다. Snowflake, Trino, Flink는 데이터 복사 없이 같은 테이블에 접근할 수 있고, 멀티 엔진 레이크하우스를 구성할 수 있다.

스트리밍 수집의 소파일을 관리하는 방법

Kafka나 CDC가 지속적으로 작은 파일을 쓰면 메타데이터 오버헤드가 커지고 쿼리 성능이 악화된다. S3 Tables에서는 AWS가 소파일 압축(Compaction)을 완전 관리형으로 처리한다. 사용자가 임계값을 설정하면 S3 Tables 인프라가 백그라운드에서 파일을 병합하고 최적 크기를 유지한다.

Iceberg를 직접 운영할 때는 데이터 파일과 매니페스트를 별도로 정리할 수 있다.

-- Spark에서 소파일 압축
CALL system.rewrite_data_files(
  table => 'events',
  strategy => 'binpack',
  options => map('target-file-size-bytes', '134217728')  -- 128MB
);

-- 메타데이터 최적화 (매니페스트 파일 병합)
CALL system.rewrite_manifests('events');

같은 스토리지에서 스트리밍과 배치를 함께 처리한다

2026년 레이크하우스 설계에서 스트리밍과 배치 워크로드를 단일 스토리지 계층에서 처리하는 요구가 커졌다. Apache Flink가 Iceberg 테이블에 스트리밍으로 쓰고 Apache Spark가 같은 테이블을 배치로 읽는 패턴이 여기에 해당한다.

Flink가 새 스냅샷을 커밋하는 동안에도 Spark 배치 잡은 이전 스냅샷을 일관되게 읽는다. 두 워크로드의 격리는 Iceberg의 스냅샷 기반 구조가 제공한다.

여러 포맷을 함께 운영하는 선택지

포맷 경쟁과 함께 상호운영성 도구도 부상하고 있다. 단일 포맷 표준화를 강제하기보다 여러 포맷을 병행하는 운영 방식이 선택지로 자리 잡는 흐름이다.

**Apache XTable (구 OneTable)**은 Iceberg, Delta Lake, Hudi 사이의 메타데이터를 실시간으로 동기화한다. 데이터 파일을 복사하지 않고 포맷별 메타데이터만 변환해, 서로 다른 엔진이 동일 데이터를 각 포맷으로 읽을 수 있게 한다.

**DuckLake (2025년 신규)**는 DuckDB/MotherDuck 팀이 제안한 방식이다. 테이블 메타데이터 전체를 관계형 데이터베이스에 저장해 카탈로그 계층에서 일관성과 다중 테이블 트랜잭션을 달성한다. 오브젝트 스토리지의 eventual consistency 문제를 데이터베이스 ACID 트랜잭션으로 다룬다.

Iceberg Summit과 S3 Tables의 성장 지표는 Iceberg가 오픈 테이블 포맷 생태계의 중심축으로 자리 잡고 있음을 보여준다. 레이크하우스 설계에서는 특정 포맷의 채택 자체보다 카탈로그 통합과 쿼리 엔진 분리 원칙이 운영 구조를 결정한다.