Iceberg vs Delta, 레이크하우스 포맷 해부

레이크하우스에서 Iceberg와 Delta, 무엇을 기준으로 골라야 하나?

결론부터 쓴다. 두 포맷의 절대 처리 속도 차이보다 적재 엔진 구성, 카탈로그 선택, 커밋·파일 설계가 성능과 신선도를 더 크게 좌우한다. Spark·Databricks 단일 경로로 배치와 스트리밍을 함께 운영한다면 Delta가, Flink·Trino·Snowflake·BigQuery 등 여러 엔진으로 같은 테이블에 접근할 계획이라면 Iceberg가 설계상 자연스럽다. 2026년 기준으로도 두 포맷을 동일 하드웨어·동일 버전·동일 부하에서 비교한 공개 재현 가능 벤치마크는 충분히 쌓이지 않았다.

배치 append는 두 포맷 모두 구조적으로 유리하다 — 기존 Parquet 파일을 다시 쓰지 않고 새 파일과 메타데이터만 커밋한다
Delta는 Spark Structured Streaming과 배치 API를 같은 테이블에 적용하기 쉽고 Databricks 최적화 기능과 결합하면 운영 경로가 단순해진다
Iceberg는 Spark·Flink·Trino·Snowflake 등 여러 엔진에서 동일 테이블을 읽고 쓰는 구성이 핵심 강점이다
스트리밍 신선도는 포맷 자체보다 커밋 빈도, 파일 목표 크기, 컴팩션 주기가 결정한다
"Delta가 N% 빠르다"류 수치는 버전·하드웨어·부하 조건이 명시되지 않으면 기사 결론으로 쓰기 어렵다

이 글은 Iceberg와 Delta의 메타데이터 계층 구조, 배치·스트리밍 적재 경로, 공개된 벤치마크 수치의 재현 가능성, 그리고 설계 선택의 트레이드오프까지를 다룬다. 특정 엔진의 설정 절차나 마이그레이션 가이드는 범위 밖이다.

카탈로그와 메타데이터 계층은 어떻게 다르게 동작하나?

두 포맷 모두 데이터 파일(Parquet) 위에 메타데이터 계층을 얹어 스냅샷·스키마 변경·타임 트래블을 지원하지만, 메타데이터를 가리키는 방식이 다르다. Iceberg는 매니페스트 파일과 매니페스트 리스트를 거쳐 카탈로그가 현재 메타데이터 포인터를 가리키는 구조이고, 카탈로그 구현체로 Hive Metastore, AWS Glue, REST 카탈로그 등을 선택할 수 있다. Delta는 트랜잭션 로그(_delta_log)를 테이블 디렉터리 안에 직접 두고 Spark가 이 로그를 순차적으로 읽어 현재 상태를 재구성하는 방식에 가깝다.

이 차이는 실무에서 "어떤 엔진이 카탈로그를 바꿔 끼울 수 있는가"로 이어진다. Iceberg는 카탈로그 구현체를 교체해도 테이블 포맷 자체는 유지되므로, Hive Metastore에서 REST 카탈로그로 옮기는 식의 변경이 상대적으로 격리돼 있다. Delta는 Databricks Unity Catalog와 결합할 때 거버넌스·접근 제어 기능이 추가되지만, 이는 포맷의 트랜잭션 로그 구조 자체보다 플랫폼 계층의 기능이다. 즉 "카탈로그 유연성"을 선택 기준으로 삼는다면 포맷 스펙과 플랫폼 기능을 분리해서 봐야 한다.

배치 append 경로는 두 포맷에서 왜 비슷하게 유리한가?

배치 append는 Iceberg와 Delta 모두에서 전체 테이블 재작성보다 구조적으로 저렴하다. 새 데이터가 들어올 때 기존 Parquet 파일은 건드리지 않고 새 파일을 쓴 뒤, 그 파일을 가리키는 메타데이터(매니페스트 또는 트랜잭션 로그 엔트리)만 커밋하기 때문이다. 이 구조적 이점은 포맷에 관계없이 동일하게 적용되며, 두 포맷 간 우열을 가르는 지점이 아니다.

검색된 자료 중 "AWS r6g.4xlarge 8개 워커, 코디네이터 1개, 1억 행 append 기준 Delta 91.5초, Iceberg 94.8초"라는 수치가 있었다. 그러나 이 수치는 공식 프로젝트 벤치마크나 학술 논문이 아니며, Spark 버전, Iceberg·Delta 커넥터 버전, 파일 크기, 카탈로그 구현체, 측정 반복 횟수와 분산이 충분히 제시되지 않았다. 3.5%p 차이는 측정 오차 범위 안에 있을 가능성을 배제할 수 없어 "Delta가 append에서 우세하다"는 일반화 근거로 쓰기 어렵다.

스트리밍 신선도는 포맷이 아니라 무엇이 결정하나?

신선도를 결정하는 변수는 포맷 선택이 아니라 커밋 빈도, 파일 목표 크기, 컴팩션 주기, 동시 writer 수다. 작은 이벤트를 짧은 주기로 계속 커밋하면 메타데이터 엔트리와 작은 파일 수가 함께 늘어나고, 이를 정리하는 컴팩션·파일 재작성 작업이 신규 쓰기와 리소스를 두고 경합할 수 있다. 이 패턴은 Iceberg와 Delta 모두에서 관찰되며, 포맷 자체가 이 문제를 자동으로 해결하지 않는다.

Iceberg 스트리밍 쓰기를 다룬 학술 자료는 이벤트를 단건이 아니라 1,000개 단위로 Arrow 테이블에 모아 배치 삽입하는 방식을 보고했고, DuckDB와 PyIceberg 조합 여부에 따라 처리량 차이가 나타났다고 설명했다Apache Iceberg 문서. 다만 이 연구는 Delta를 비교 대상에 포함하지 않아 "Iceberg가 스트리밍에 더 유리하다"는 결론으로 확장할 수 없다. 반대로 "Delta가 스트리밍에 부적합하다"는 주장도 검색 자료에서 뒷받침되지 않는다. Delta는 Spark Structured Streaming과의 결합이 상대적으로 성숙해 있을 뿐, 이벤트 단위 초저지연 쓰기를 포맷이 자동 보장하는 것은 아니다.

실측 수치는 어디까지 믿을 수 있나?

재현 조건이 명시된 수치와 그렇지 않은 수치를 분리해야 한다. AWS 환경에서 r6g.4xlarge 8워커·1억 행 append 기준 Delta 91.5초, Iceberg 94.8초라는 값은 하드웨어 스펙과 데이터 규모는 제시됐지만 엔진 버전, 카탈로그, 측정 반복은 빠져 있어 참고용 주장 수준에 머문다AWS Big Data 블로그.

또 다른 자료는 AWS Glue 5.1, Apache Spark 3.4, Delta Lake 4.0, 1TB 데이터셋 조건에서 Delta 3.0 대비 쿼리 성능 37% 개선을 보고했다. 조건은 상세하지만 Iceberg를 동일 조건에서 비교한 대조군이 없어 "Iceberg 대 Delta" 비교 수치로 쓸 수 없고, Delta 내부 버전 간 개선으로만 해석해야 한다. 두 사례 모두 공통적으로 결여된 것은 원시 실행 로그, 반복 측정값, 분산 지표다. 이 세 가지가 없는 수치는 기사에서 확정값이 아니라 "주장"으로 표기하는 편이 안전하다.

엔진 선택지를 넓히면 무엇을 얻고 무엇을 잃나?

Iceberg 쪽으로 설계를 기울이면 Spark 외에 Flink·Trino·Snowflake·BigQuery 등에서 동일 테이블에 접근할 가능성을 얻는다. 특정 클라우드나 특정 컴퓨트 엔진에 묶이지 않고 분석 워크로드를 분산시킬 수 있는 유연성이 핵심 이득이다. 대신 잃는 것은 단일 플랫폼 최적화의 단순함이다. 여러 엔진이 같은 테이블에 쓰기를 시도하면 동시성 제어, 컴팩션 주체, 카탈로그 일관성을 엔진 간에 조율하는 운영 부담이 커진다.

Delta 쪽으로 기울이면 Spark/Databricks 생태계 안에서 배치·스트리밍·최적화가 한 경로로 묶이는 단순함을 얻는다. 대신 다른 엔진에서 같은 테이블에 접근하려 할 때 커넥터 성숙도나 기능 지원 범위가 Iceberg만큼 넓지 않을 수 있다는 제약을 떠안는다. "Iceberg는 멀티엔진이라 운영비가 낮다"는 식의 단정은 검색 자료로 검증되지 않는다. 엔진이 늘어나면 조율 비용도 함께 늘어나기 때문에, 유연성과 운영 단순성은 상호 배타적인 트레이드오프로 봐야 한다.

언제 Delta, 언제 Iceberg를 먼저 검토해야 하나?

Databricks·Spark가 사실상 표준이고 배치와 Structured Streaming을 한 플랫폼에서 운영한다면 Delta를 우선 검토한다. 적재·변환·모니터링·최적화 경로를 한 생태계 안에서 묶기 쉽다는 점이 선택 근거다. 반대로 Spark 외에 Flink·Trino·Snowflake·BigQuery 등 여러 엔진을 실제로 사용할 계획이거나 특정 클라우드 종속을 피하려 한다면 Iceberg를 우선 검토한다. 이때 이득은 특정 쿼리의 절대 처리시간이 아니라 엔진 교체와 교차 접근의 유연성이다.

신선도 목표가 초 단위이고 업데이트·삭제 비율이 높다면 포맷 선택만으로는 해결되지 않는다. 마이크로배치 간격, 커밋 빈도, 파일 목표 크기, 컴팩션 주기, 동시 writer 수, 실패 재시도 정책을 함께 설계해야 신선도와 재처리 비용의 균형이 맞는다. 재처리 비용을 줄이려면 원천 이벤트 보존과 idempotent 변환을 우선해야 하며, 스냅샷·타임 트래블 기능만으로 전체 재처리 비용이 자동으로 줄어드는 것은 아니다.

핵심 정리

배치 append는 두 포맷 모두 파일 재작성 없이 메타데이터만 커밋해 구조적으로 유리하지만, 공개된 91.5초 대 94.8초 수치는 재현 조건이 불충분해 확정값으로 쓸 수 없다
Delta는 Spark/Databricks 단일 경로에서 배치·스트리밍 운영을 단순화하는 쪽에, Iceberg는 Flink·Trino·Snowflake 등 다중 엔진 접근 유연성 쪽에 강점이 있다
스트리밍 신선도는 포맷이 아니라 커밋 빈도·파일 크기·컴팩션 주기·동시 writer 수가 결정한다
CDC·upsert 비율이 높으면 두 포맷 모두 파일 재작성과 동시성 제어 비용이 커지므로 별도 검증이 필요하다
포맷 선택의 승패는 적재 엔진, 카탈로그, 파일 설계, 웨어하우스 연계 방식에서 갈린다

자주 묻는 질문

Iceberg와 Delta 중 하나를 나중에 바꿀 수 있나?

포맷 간 변환은 데이터 파일(Parquet) 자체는 재사용하고 메타데이터 계층만 새로 생성하는 방식으로 가능한 경우가 많지만, 테이블 크기와 파티션 구조에 따라 메타데이터 재생성 작업이 상당한 시간이 걸릴 수 있다. 운영 중단 없이 전환하려면 병행 기간을 두고 양쪽 메타데이터를 동시에 유지하는 전략이 필요하다.

두 포맷을 한 파이프라인에서 함께 쓰는 구성이 가능한가?

기술적으로는 레이어별로 다른 포맷을 쓰는 구성이 가능하다. 예를 들어 수집 레이어는 한 포맷, 서빙 레이어는 다른 포맷으로 분리할 수 있지만, 이 경우 레이어 간 변환 작업이 추가 재처리 비용으로 쌓인다는 점을 고려해야 한다.

작은 테이블에서도 포맷 선택이 중요한가?

데이터 규모가 작고 단일 엔진·단일 배치 경로만 쓴다면 포맷 간 차이가 체감되는 영역이 메타데이터 오버헤드나 엔진 호환성 정도로 제한된다. 포맷 선택의 영향은 테이블 수, 동시 writer 수, 엔진 종류가 늘어날수록 커진다.

컴팩션 주기는 어떻게 정해야 하나?

컴팩션 주기는 포맷 스펙이 아니라 쓰기 빈도와 쿼리 패턴에 맞춰 설계해야 한다. 쓰기가 잦고 파일이 작게 쪼개지는 워크로드일수록 컴팩션 주기를 짧게 가져가되, 컴팩션 작업 자체가 신규 쓰기와 리소스를 경합하지 않도록 별도 스케줄이나 리소스 풀을 분리하는 설계가 필요하다.

더 알아보기

데이터 파이프라인 아키텍처: 배치·스트리밍·신선도의 설계 축 — 이 주제의 종합 가이드