Snowflake, Databricks, Google, AWS 발표를 정리하다 보니 Iceberg가 빠지는 행사가 없었습니다. 정작 Iceberg가 정확히 무엇인지는 한 번도 따로 적어 본 적이 없어서, 공식 소개 문서를 읽고 정리했습니다.
한 줄 정의
Iceberg는 데이터 파일 묶음을 테이블처럼 다루게 해 주는 개방형 테이블 형식입니다. 문서의 표현으로는 Spark, Trino, PrestoDB, Flink, Hive, Impala 같은 컴퓨트 엔진에 테이블을 더해 줍니다.
중요한 건 "엔진에 더해 준다"는 부분입니다. 데이터는 오브젝트 스토리지에 한 번 두고, 여러 엔진이 같은 테이블로 읽고 씁니다.
문서가 꼽는 네 가지
문서는 "놀랄 일이 없게"라는 목표 아래 네 가지를 듭니다.
| 기능 | 문서의 설명 |
|---|---|
| 스키마 진화 | 열을 추가·삭제·수정·이름 변경해도 지운 데이터가 되살아나지 않는다 |
| 숨은 파티셔닝 | 사용자가 파티션 구조를 직접 다루지 않아, 조용히 틀린 결과나 아주 느린 쿼리를 내는 실수를 막는다 |
| 시간 여행 | 같은 스냅샷으로 쿼리를 재현하거나 변경을 살펴볼 수 있다 |
| 버전 롤백 | 테이블을 좋은 상태로 되돌려 문제를 빨리 바로잡는다 |
숨은 파티셔닝이 실무에서 특히 와닿습니다. 하이브 방식 테이블에서는 날짜 파티션 열을 쿼리에 직접 써 주지 않으면 전체를 읽는 일이 흔했습니다. Iceberg는 이걸 형식 쪽에서 처리합니다.
왜 여러 엔진이 동시에 써도 되나
문서는 직렬화 격리를 내세웁니다. 테이블 변경은 원자적이고, 읽는 쪽은 일부만 반영되거나 커밋되지 않은 변경을 보지 않습니다.
여러 엔진이 동시에 쓰면 낙관적 동시성으로 처리합니다. 충돌하면 다시 시도하는 방식입니다. 그리고 결과적 일관성만 보장하는 클라우드 오브젝트 스토리지에서도 정확하게 동작하도록 설계됐다고 합니다.
규모도 큽니다. 문서는 수십 PB에 이르는 테이블도 분산 SQL 엔진 없이 읽을 수 있고, 파티션과 열 단위 통계로 읽을 파일을 걸러 낸다고 설명합니다.
왜 행사마다 나오나
Iceberg는 공개된 명세를 가진 커뮤니티 표준이고, 아파치 재단에서 개발됩니다. 특정 회사의 형식이 아니라는 점이 핵심입니다.
그래서 각 회사는 "데이터를 우리 쪽으로 옮기라"는 대신 "Iceberg로 두면 우리 엔진으로도 읽고 쓰게 해 주겠다"고 말할 수 있게 됐습니다. Snowflake의 Iceberg 상호운용 발표와 Databricks의 LTAP가 모두 이 위에 서 있습니다.
남는 숙제
형식이 같다고 권한까지 같아지지는 않습니다. 한 엔진에 건 마스킹 정책을 다른 엔진이 같은 파일을 읽을 때도 지키게 하는 일은 카탈로그의 몫입니다. Iceberg를 도입할 때 가장 먼저 물어야 할 질문은 "어떤 카탈로그가 권한을 관리하는가"일 것 같습니다.
