Apache Iceberg가 뭐야 — 오픈 테이블 포맷·데이터 레이크하우스·스키마 진화·시간 여행 완전 정리
데이터 엔지니어링 블로그·콘퍼런스·기술 트위터를 둘러보면 어느 순간부터 가장 자주 등장하는 단어 중 하나가 Apache Iceberg다. Snowflake도 BigQuery도 AWS도 Databricks도 모두 "우리 Iceberg 지원합니다"를 새 기능으로 발표하고 있고, 2024년 6월 Databricks의 Tabular 인수(보도 기준 약 20억 달러), 2024년 12월 AWS S3 Tables GA, 2026년 5월 Snowflake의 Iceberg v3 GA까지 줄줄이 이어졌다.
이름은 익숙해졌지만 "그래서 Iceberg가 정확히 뭔지", "Hive·Parquet과 어떻게 다른지", "왜 Snowflake가 자사 포맷이 있는데도 Iceberg를 지원하는지" 한 번에 정리되는 자료는 의외로 드물다. 본 글은 데이터 엔지니어·백엔드 개발자·DBA가 Iceberg를 처음부터 끝까지 한 번에 이해할 수 있도록 정의·핵심 기능·아키텍처·최신 트렌드·시작 예제까지 정리한다.
이 글의 구성
01 Apache Iceberg란 무엇인가
| 항목 | 내용 |
|---|---|
| 정의 | 데이터 레이크용 오픈 테이블 포맷(Open Table Format) |
| 기원 | Netflix 2017년 사내 개발 → 2018년 ASF 기증 → 2020년 Top-Level 졸업 |
| 레이어 | 데이터 파일 위에 얹는 메타데이터 레이어 |
| 데이터 포맷 | Parquet · ORC · Avro (Iceberg가 새 포맷을 만들지 않음) |
| 제공하는 것 | ACID·스키마 진화·시간 여행·Hidden Partitioning |
| 최신 스펙 | v2 안정, v3는 2025~2026 본격 GA (Snowflake v3 GA 2026-05) |
Iceberg의 핵심을 한 문장으로 말하면 "S3·GCS·ADLS 같은 오브젝트 스토리지 위의 파일 묶음을, 데이터베이스 테이블처럼 다루게 해 주는 메타데이터 레이어" 다. Iceberg 자체는 새로운 데이터 파일 포맷이 아니다. 데이터는 여전히 Parquet·ORC·Avro 파일에 들어가고, Iceberg는 그 위에 "어떤 파일이 현재 테이블에 속하는가", "스키마는 무엇인가", "어떤 스냅샷이 존재하는가"를 정밀하게 기록한다.
핵심 관찰 — "테이블 포맷"이라는 신생 카테고리
기존에는 "파일 포맷(Parquet, ORC)"과 "데이터베이스 시스템(Postgres, Snowflake)"의 두 층만 있었다. Iceberg·Delta·Hudi가 등장하면서 그 중간에 "테이블 포맷(Table Format)"이라는 새 층이 생겼다. 데이터는 오브젝트 스토리지에 저장하되, 트랜잭션·스키마·이력 관리는 테이블 포맷이 책임지고, 쿼리는 다양한 엔진이 처리하는 분업 구조다.
02 왜 필요한가 — Hive 테이블의 한계
Iceberg를 이해하려면 그것이 대체하려는 Hive 테이블 포맷의 한계부터 봐야 한다. Hive는 디렉토리 기반 메타스토어로 "이 테이블은 이 디렉토리에 있고, 그 안 모든 파일이 데이터"라는 단순한 약속을 썼다. 이 접근은 HDFS에서는 그럭저럭 동작했지만 S3 시대에 와서 여러 곳이 깨졌다.
한계 1 — 원자적 커밋이 없다
디렉토리에 파일이 하나씩 떨어지므로 읽는 쿼리가 절반쯤 쓰인 결과를 볼 수 있다. 동시 쓰기가 들어오면 충돌 감지도 어렵다.
한계 2 — 파일 단위 통계가 없다
메타스토어가 디렉토리만 알고 개별 파일의 min/max 컬럼 통계는 모른다. 따라서 모든 파일을 일단 열어 확인해야 하고, 큰 테이블에서는 쿼리가 풀스캔에 가까워진다.
한계 3 — 스키마·파티션 변경이 파괴적이다
컬럼 이름 변경, 타입 변경, 파티션 키 변경 등이 사실상 테이블 재작성을 강제한다. 운영 중인 페타바이트 규모 테이블에서 파티션을 바꾼다는 것은 며칠짜리 작업이다.
한계 4 — S3와 궁합이 나쁘다
S3의 LIST API는 비싸고 느리며, 한때 eventual consistency 이슈도 있었다. Hive 모델은 디렉토리 LIST에 의존하므로 큰 테이블 쿼리 계획 단계에서만 수십 초가 깨지는 일이 흔했다.
Iceberg는 이 네 가지 문제를 모두 메타데이터 트리에 정확한 파일 목록과 컬럼 통계를 기록하는 단순한 발상으로 해결한다. 디렉토리를 묻지 않고, 메타데이터를 묻는다.
03 핵심 기능 7가지
기능 1 — ACID 트랜잭션 (스냅샷 기반 격리)
모든 변경이 새 스냅샷으로 기록되고 메타데이터 포인터가 원자적으로 교체된다. 읽는 쿼리는 시작 시점의 스냅샷을 끝까지 유지하므로 Serializable Isolation에 가까운 일관성을 얻는다.
기능 2 — 스키마 진화(Schema Evolution)
컬럼 추가·삭제·이름 변경·타입 승격을 데이터 파일 재작성 없이 메타데이터만으로 처리한다. 각 컬럼은 이름이 아닌 내부 ID로 추적되므로 이름을 바꿔도 기존 파일과의 대응이 깨지지 않는다.
기능 3 — Hidden Partitioning
사용자는 그냥 `WHERE event_ts > '2026-05-01'`이라고 쓰고, Iceberg가 내부적으로 일자 파티션을 추적해 알아서 프루닝한다. Hive처럼 `event_date='2026-05-01'` 같은 별도 컬럼을 만들거나 쿼리에 명시하지 않아도 된다.
기능 4 — 파티션 진화(Partition Evolution)
파티션 스킴 자체를 도중에 바꿀 수 있다. 초기에 month 단위였던 파티션을 운영 중 day 단위로 바꿔도 기존 파일은 그대로 두고 새 데이터부터 새 스킴을 적용한다. Hive에서는 사실상 불가능한 작업으로 Iceberg의 시그니처 기능 중 하나다.
기능 5 — 시간 여행(Time Travel)
스냅샷 ID 또는 타임스탬프를 지정해 과거 시점의 테이블 상태를 그대로 조회할 수 있다. 데이터 사고 분석, A/B 테스트 데이터 검증, 감사 대응에 결정적이다. `SELECT ... FROM t VERSION AS OF 12345` 형태의 SQL이 표준이다.
기능 6 — Row-level Operations (CoW · MoR)
UPDATE·DELETE·MERGE가 가능하다. Copy-On-Write(CoW)는 영향 파일을 통째로 다시 써서 읽기 비용이 낮고, Merge-On-Read(MoR)는 삭제·변경분만 별도 파일로 적재해 쓰기 비용이 낮다. 워크로드에 따라 선택한다.
기능 7 — 다중 엔진 호환(Multi-Engine)
Spark·Flink·Trino·Presto·Snowflake·BigQuery·Athena·DuckDB·StarRocks·ClickHouse 등이 동일 테이블을 읽고 쓸 수 있다. "쓰기는 Spark, 분석은 Trino, BI는 Snowflake"처럼 도구별 강점을 자유롭게 조합할 수 있다는 점이 Iceberg가 표준화되는 가장 큰 동력이다.
04 아키텍처 — Catalog·Metadata·Data 3계층
테이블 이름을 받아 현재 metadata.json의 위치를 알려 준다. 카탈로그가 단일 진실의 원천.
REST · AWS Glue · Apache Polaris · Project Nessie · Hive Metastore
스키마·파티션 스펙·스냅샷 이력을 담는 3단 메타데이터 트리. 쿼리 계획에 필요한 모든 정보가 여기 들어 있다.
실제 컬럼 값이 들어 있는 데이터 파일. Iceberg가 새로 만든 포맷이 아니라 기존 컬럼 포맷을 그대로 사용한다.
Apache Parquet · Apache ORC · Apache Avro
Catalog 계층 — 테이블 이름을 받아 "이 테이블의 현재 metadata.json이 어디 있는가"만 알려 준다. 카탈로그 종류에 따라 다양한 구현이 존재한다. AWS 환경은 Glue Data Catalog가 사실상 표준이고, Snowflake·Dremio는 Apache Polaris를 밀고 있으며, Project Nessie는 Git처럼 브랜치를 지원하는 카탈로그다. REST Catalog 스펙(0.14.0 도입)이 카탈로그 간 상호운용성 표준으로 자리잡고 있다.
Metadata 계층 — metadata.json은 테이블의 모든 스냅샷 이력과 현재 스키마·파티션 스펙을 담는다. 각 스냅샷은 manifest list를 가리키고, manifest list는 manifest file들을 가리키며, manifest file은 실제 데이터 파일 목록과 컬럼별 min/max 통계를 보유한다. 쿼리 계획은 이 트리만 읽어도 끝난다 — 데이터 파일을 열어 보지 않고 어느 파일을 읽어야 하는지 결정할 수 있는 이유다.
Data 계층 — 실제 컬럼 데이터가 들어 있는 Parquet 등 파일. Iceberg가 이 부분에는 손대지 않는다. 기존 Parquet 도구가 그대로 쓰인다.
05 2024~2026 핫토픽과 채택 동향
| 시점 | 사건 | 의미 |
|---|---|---|
| 2024-06 | Databricks의 Tabular 인수 (보도 기준 약 20억 달러) | Iceberg 창시자들이 Databricks 합류, Delta UniForm으로 Iceberg/Delta 통합 추진 |
| 2024-06 | Snowflake가 Polaris Catalog 오픈소스 공개 | Iceberg 카탈로그 시장 표준화 신호탄 |
| 2024-08 | Polaris가 Apache 인큐베이팅 진입 | 2025년 GA |
| 2024-12 | AWS S3 Tables GA (re:Invent) | S3에 매니지드 Iceberg 버킷, 자동 컴팩션·메타데이터 최적화 |
| 2025 | Iceberg v3 스펙 작업 본격화 | Deletion Vector·VARIANT·Geometry·Row Lineage·암호화 |
| 2026-05 | Snowflake가 Iceberg v3 GA 발표 | 주요 벤더 중 v3 본격 채택 시작 |
특히 Tabular 인수가 갖는 의미는 크다. 그동안 Iceberg(Tabular·Netflix·Snowflake)와 Delta Lake(Databricks)는 경쟁 관계였는데, Databricks가 Iceberg 진영 핵심 인물들을 흡수하면서 양 진영이 하나의 공통 메타데이터 레이어로 수렴하는 흐름이 명확해졌다. Delta UniForm은 같은 데이터 파일을 Delta·Iceberg 두 가지 메타데이터로 동시에 노출해 주는 기능이고, Apache Hudi 1.0(2025)부터는 Iceberg 포맷 출력을 공식 지원한다.
"Write Once, Read Anywhere"로 수렴 중
2024~2026 흐름의 본질은 "데이터를 한 번 쓰고 모든 엔진에서 읽는다"는 데이터 엔지니어링의 오랜 꿈이다. 그 공통 포맷의 자리에 Iceberg가 가장 빠르게 자리잡고 있고, Delta·Hudi가 그 위에 호환 레이어로 합류하는 그림이 점차 분명해지고 있다. 특정 벤더 종속을 피하면서도 풀 기능 데이터 레이크하우스를 구축하려는 조직에 Iceberg가 사실상 디폴트 선택지가 된 이유다.
06 Delta Lake·Hudi와의 차이
| 항목 | Iceberg | Delta Lake | Hudi |
|---|---|---|---|
| 주도 | Netflix → ASF | Databricks → LF | Uber → ASF |
| 강점 | 멀티엔진 중립, 파티션 진화, hidden partitioning | Spark·Databricks 친화, 가장 큰 설치 기반 | 실시간 upsert·CDC, MoR 효율 |
| 2025+ 동향 | 사실상 산업 표준 위치 | UniForm으로 Iceberg 호환 | 1.0부터 Iceberg 포맷 출력 |
| 선택 기준 | 엔진 자유도·표준성 | Databricks 의존 환경 | 스트리밍·CDC 비중 높음 |
업계 전반의 방향은 "셋 중 하나를 골라 묶이는" 구도에서 "Iceberg 포맷으로 결국 함께 읽힌다"는 구도로 빠르게 이동 중이다. 신규 채택이라면 Iceberg가 가장 안전한 선택, 기존 Delta 환경이라면 UniForm을 통해 호환을 유지하면서 점진적 전환, Hudi는 실시간 upsert·CDC가 핵심 워크로드일 때 그대로 유지하는 식의 판단이 일반적이다.
07 간단 시작 예제와 채택 판단
Spark + Iceberg 기본 예제
-- 1) Iceberg 테이블 생성 (Spark SQL)
CREATE TABLE demo.nyc.taxis (
vendor_id BIGINT,
trip_id BIGINT,
fare_amount DOUBLE,
pickup_ts TIMESTAMP
) USING iceberg
PARTITIONED BY (days(pickup_ts));
-- 2) 데이터 적재
INSERT INTO demo.nyc.taxis VALUES
(1, 1000, 12.5, TIMESTAMP '2026-05-18 10:00:00');
-- 3) 시간 여행 — 과거 스냅샷 조회
SELECT * FROM demo.nyc.taxis VERSION AS OF 1234567890;
SELECT * FROM demo.nyc.taxis
TIMESTAMP AS OF '2026-05-15 00:00:00';
-- 4) 파티션 진화 — 데이터 재작성 없이
ALTER TABLE demo.nyc.taxis ADD PARTITION FIELD vendor_id;
-- 5) 스냅샷 만료 (오래된 메타데이터 정리)
CALL demo.system.expire_snapshots(
table => 'nyc.taxis',
older_than => TIMESTAMP '2026-05-01 00:00:00'
);
채택 판단 기준
| 잘 맞는 경우 | 잘 맞지 않는 경우 |
|---|---|
| 대용량 분석 워크로드(수 TB 이상) | 트랜잭션 OLTP·운영계 응답 ms 단위 요구 |
| Spark/Trino/Snowflake 등 멀티 엔진 혼용 | 단일 엔진·단일 벤더로 충분한 환경 |
| S3·GCS·ADLS 기반 데이터 레이크 | 소규모(수 GB 이하) 데이터 |
| 스키마·파티션이 자주 바뀌는 도메인 | 강력한 로우 락이 필요한 워크로드 |
| 규제 대응을 위한 시간 여행 필수 | 초고빈도 upsert(이때는 Hudi가 적합할 수 있음) |
요약하면 Iceberg는 분석·아카이브·감사·멀티 엔진에 강점이 있고, 트랜잭션 OLTP는 여전히 Postgres·Oracle의 영역이다. "데이터 웨어하우스 + 데이터 레이크"를 통합하는 레이크하우스 아키텍처에서 메타데이터 표준이 필요할 때 가장 먼저 검토되는 선택지가 됐다는 점이 핵심이다.
08 자주 묻는 질문
Q1. Iceberg가 Parquet를 대체하나요?
아니다. Iceberg는 Parquet 위에 얹는 메타데이터 레이어이고, 실제 데이터는 여전히 Parquet(또는 ORC·Avro)에 들어간다. 둘은 경쟁이 아니라 보완 관계다.
Q2. Snowflake가 자사 포맷이 있는데 왜 Iceberg를 지원하나요?
고객 데이터 락인(lock-in)을 우려한 시장 압력 때문이다. Iceberg 지원은 "S3에 둔 우리 데이터를 다른 엔진과 공유하면서도 Snowflake로 분석할 수 있다"는 약속이고, 이를 위해 Snowflake는 Polaris Catalog를 오픈소스화하고 Iceberg v3까지 발 빠르게 따라가고 있다.
Q3. AWS S3 Tables가 일반 S3와 다른 점은?
S3 Tables는 Iceberg 메타데이터를 매니지드 형태로 관리해 주는 전용 버킷 타입이다. 자동 컴팩션·만료된 스냅샷 정리·메타데이터 최적화가 자동으로 일어나 직접 Iceberg 운영 부담을 크게 줄여 준다. AWS 발표에 따르면 일반 S3 대비 쿼리 최대 3배 빠르다고 한다.
Q4. Catalog는 무엇을 선택해야 하나요?
AWS 중심이면 Glue Data Catalog, 멀티 클라우드·중립성이 중요하면 Apache Polaris, Git-style 데이터 버전 관리가 필요하면 Project Nessie가 일반적이다. REST Catalog 스펙으로 표준화되고 있어 일단 하나를 골라 시작하고 추후 마이그레이션해도 큰 부담은 아니다.
Q5. v2와 v3의 차이는?
v2가 안정 버전이고, v3는 Deletion Vector(Puffin 파일 기반 비트맵 삭제), VARIANT(반구조화 JSON), Geometry·Geography, 나노초 타임스탬프, Row Lineage, 컬럼/행 단위 암호화를 추가한다. 2025~2026에 걸쳐 주요 벤더가 차례로 v3 지원을 발표하는 중이고, 2026-05 Snowflake가 Iceberg v3 GA를 시작했다.
마무리
Apache Iceberg는 단순한 신생 오픈소스 프로젝트가 아니라, 데이터 레이크하우스 시대의 공통 메타데이터 표준으로 자리잡고 있는 기술이다. 그 핵심은 (1) 데이터 파일은 Parquet/ORC 그대로 두고, (2) 그 위에 정밀한 메타데이터 트리를 얹어, (3) ACID·스키마 진화·시간 여행·Hidden Partitioning을 제공하며, (4) 어떤 엔진(Spark·Trino·Snowflake·BigQuery)에서도 동일하게 읽고 쓸 수 있게 만드는 것이다.
신규 데이터 플랫폼을 구축한다면 Iceberg를 디폴트 선택지로 두고 시작하는 것이 안전하고, 기존 Hive·Delta·Hudi 환경이라면 호환 레이어(UniForm·Hudi 1.0)를 통해 점진적으로 Iceberg를 함께 노출하는 전략이 현실적이다. 카탈로그 선택은 AWS 중심이면 Glue, 멀티 클라우드면 Polaris로 시작하면 무난하고, 운영 부담을 줄이고 싶다면 AWS S3 Tables 같은 매니지드 옵션을 적극 검토할 만하다.
Apache Iceberg 도입 체크리스트
본 글은 Apache Iceberg의 정의·아키텍처·핵심 기능·2024~2026 최신 동향을 정리한 자료다. 실제 운영 환경 도입 전 사내 워크로드 특성에 맞게 PoC·벤치마크를 거쳐 검증한다.
#ApacheIceberg #아파치아이스버그 #오픈테이블포맷 #OpenTableFormat #데이터레이크하우스 #Lakehouse #SchemaEvolution #TimeTravel #HiddenPartitioning #ACID #DeltaLake #ApacheHudi #Snowflake #AWSS3Tables #ApachePolaris
'IT' 카테고리의 다른 글
| ORA-06550 PL/SQL compilation error — 컴파일 오류 원인·해결·예방 완전 정리 (0) | 2026.05.19 |
|---|---|
| ORA-01843 not a valid month — 월 값 부적합 에러 원인·해결·예방 (1) | 2026.05.19 |
| ORA-06512 at line N — PL/SQL 스택 트레이스 에러 원인·해결·예방 완전 정리 (0) | 2026.05.18 |
| ORA-00904 invalid identifier — 부적합한 식별자·컬럼명 오타 에러 원인·해결·예방 완전 정리 (0) | 2026.05.18 |
| MVP가 뭐야 — 최소 기능 제품(Minimum Viable Product) 정의·6가지 유형·Dropbox·Airbnb·Zappos 사례·만드는 5단계 완전 정리 (0) | 2026.05.18 |
댓글