2026년 Delta Lake vs Apache Iceberg: 레이크하우스 아키텍처와 면접 대비 가이드

Delta Lake와 Apache Iceberg는 2026년 현재 모던 데이터 레이크하우스를 구동하는 두 가지 주요 오픈 테이블 포맷입니다. 두 포맷 모두 클라우드 오브젝트 스토리지에 ACID 트랜잭션, 스키마 진화, 타임 트래블 기능을 제공하는 동일한 근본적인 문제를 해결하지만, 프로덕션 워크로드에서 중요한 차이를 만드는 서로 다른 아키텍처적 접근 방식을 취합니다.

Delta Lake vs Iceberg: 핵심 아키텍처 차이점

두 포맷 모두 데이터를 Parquet 파일로 오브젝트 스토리지에 저장하지만, 메타데이터 레이어는 크게 다릅니다.

Delta Lake는 모든 변경 사항을 기록하는 JSON 파일이 포함된 트랜잭션 로그(_delta_log/)를 사용합니다. 각 커밋은 새로운 JSON 파일을 생성하고, 주기적인 체크포인트가 이를 Parquet로 통합하여 읽기 속도를 높입니다. Delta Lake 프로토콜 명세는 전방 호환성을 위한 버전 관리된 리더/라이터 기능을 정의합니다.

Apache Iceberg는 매니페스트 리스트를 가리키는 메타데이터 JSON 파일의 계층 구조를 유지합니다. 매니페스트 리스트는 파일 수준 통계를 포함하는 매니페스트를 가리킵니다. 이 설계는 계획 단계에서 술어 푸시다운을 가능하게 하여 쿼리 엔진이 데이터를 읽기 전에 전체 파일을 건너뛸 수 있습니다.

| 기능 | Delta Lake | Apache Iceberg | |------|------------|----------------| | 트랜잭션 로그 | JSON + Parquet 체크포인트 | 메타데이터 JSON + 매니페스트 파일 | | 파티션 진화 | 재작성 필요 | 재작성 없이 인플레이스 변경 가능 | | 엔진 지원 | Spark, Trino, Flink | Spark, Trino, Flink, Dremio, Athena | | 타임 트래블 | 버전 기반 | 브랜치/태그가 있는 스냅샷 기반 | | 스키마 진화 | 컬럼 추가/이름 변경 | 컬럼 추가/이름 변경/순서 변경/타입 확장 |

히든 파티션: Iceberg의 핵심 장점

전통적인 Hive 스타일 파티셔닝은 쿼리에서 파티션 컬럼을 노출시키며(WHERE year=2026 AND month=7), 물리적 레이아웃과 SQL 구문을 결합시킵니다. Iceberg의 히든 파티션은 이러한 관심사를 분리합니다.

# iceberg_partition_example.py
from pyiceberg.catalog import load_catalog
from pyiceberg.schema import Schema
from pyiceberg.types import StringType, TimestampType, LongType, NestedField
from pyiceberg.partitioning import PartitionSpec, PartitionField
from pyiceberg.transforms import MonthTransform

# 스키마 정의
schema = Schema(
    NestedField(1, "event_id", LongType(), required=True),
    NestedField(2, "event_time", TimestampType(), required=True),
    NestedField(3, "user_id", StringType(), required=True),
    NestedField(4, "event_type", StringType(), required=False),
)

# event_time에서 월을 추출하는 히든 파티션
partition_spec = PartitionSpec(
    PartitionField(
        source_id=2,  # event_time 필드
        field_id=1000,
        transform=MonthTransform(),
        name="event_month"
    )
)

catalog = load_catalog("glue", **{"type": "glue"})
catalog.create_table(
    identifier="analytics.events",
    schema=schema,
    partition_spec=partition_spec
)

쿼리는 event_time으로 직접 필터링할 수 있으며, 엔진은 WHERE 절에서 파티션 컬럼을 노출시키지 않고 자동으로 파티션 프루닝을 적용합니다. 파티션 진화를 통해 기존 데이터를 재작성하지 않고도 월별에서 일별 파티셔닝으로 전환할 수 있습니다.

Delta Lake ACID 트랜잭션과 낙관적 동시성 제어

Delta Lake는 낙관적 동시성 제어를 사용하여 직렬화 가능 격리를 구현합니다. 라이터는 충돌을 감지하기 위해 커밋 전에 트랜잭션 로그를 확인합니다.

# delta_concurrent_writes.py
from delta import DeltaTable
from pyspark.sql import SparkSession

spark = SparkSession.builder \
    .config("spark.sql.extensions", "io.delta.sql.DeltaSparkSessionExtension") \
    .config("spark.sql.catalog.spark_catalog", 
            "org.apache.spark.sql.delta.catalog.DeltaCatalog") \
    .getOrCreate()

# 자동 충돌 해결을 통한 동시 MERGE 작업
delta_table = DeltaTable.forPath(spark, "s3://bucket/events")

# 수신 배치와 기존 데이터 병합
delta_table.alias("target").merge(
    source=incoming_df.alias("source"),
    condition="target.event_id = source.event_id"
).whenMatchedUpdateAll() \
 .whenNotMatchedInsertAll() \
 .execute()

# 충돌 감지는 커밋 중에 자동으로 수행됨
# 실패한 트랜잭션은 업데이트된 스냅샷으로 재시도

Delta Lake의 충돌 해결 규칙은 동일한 파티션에 대한 충돌하는 업데이트를 직렬화하면서 동시 추가 작업이 성공할 수 있도록 합니다.

타임 트래블 및 데이터 버전 관리 비교

두 포맷 모두 타임 트래블을 지원하지만 시맨틱이 다릅니다.

-- Delta Lake: 버전 번호로 쿼리
SELECT * FROM events VERSION AS OF 42;

-- Delta Lake: 타임스탬프로 쿼리
SELECT * FROM events TIMESTAMP AS OF '2026-07-15 10:00:00';

-- Iceberg: 스냅샷 ID로 쿼리
SELECT * FROM analytics.events FOR SYSTEM_VERSION AS OF 8823749234;

-- Iceberg: 타임스탬프로 쿼리
SELECT * FROM analytics.events FOR SYSTEM_TIME AS OF TIMESTAMP '2026-07-15 10:00:00';

Iceberg 1.5+에서는 브랜칭과 태깅이 추가되어 격리된 실험을 위한 명명된 브랜치를 생성한 다음 병합하거나 폐기할 수 있습니다. Delta Lake는 얕은 클론을 통해 유사한 워크플로우를 달성합니다.

-- Iceberg: 테스트용 브랜치 생성
ALTER TABLE analytics.events CREATE BRANCH experiment;

-- 메인에 영향을 주지 않고 브랜치에 쓰기
INSERT INTO analytics.events.branch_experiment 
SELECT * FROM staging.events WHERE event_type = 'test';

-- 브랜치를 메인에 병합
CALL system.fast_forward('analytics.events', 'main', 'experiment');

쿼리 엔진 호환성 매트릭스

엔진 호환성은 많은 조직에서 포맷 선택을 결정하는 요소입니다.

| 엔진 | Delta Lake 지원 | Iceberg 지원 | |------|-----------------|---------------| | Apache Spark | 네이티브 (Databricks, OSS) | 네이티브 | | Trino/Presto | 커넥터 | 네이티브 | | Apache Flink | 커넥터 | 네이티브 (1.16+) | | Dremio | 읽기 전용 | 네이티브 | | AWS Athena | 제한적 | 네이티브 | | Snowflake | 외부 테이블 | 네이티브 (Iceberg 테이블) | | BigQuery | 외부 테이블 | BigLake Iceberg |

Spark 전용 환경에서는 Delta Lake의 더 긴밀한 통합이 더 나은 성능을 제공합니다. 멀티 엔진 아키텍처에서는 Iceberg의 더 넓은 호환성이 유리합니다. Iceberg REST 카탈로그는 카탈로그 작업을 위한 벤더 중립적인 API를 제공합니다.

성능 최적화 기법

두 포맷 모두 최적의 쿼리 성능을 위해 유지보수 작업이 필요합니다.

# delta_optimize.py
from delta import DeltaTable

delta_table = DeltaTable.forPath(spark, "s3://bucket/events")

# 작은 파일 컴팩션 (빈 패킹)
delta_table.optimize().executeCompaction()

# 다중 컬럼 술어를 위한 Z-오더
delta_table.optimize().executeZOrderBy("user_id", "event_time")

# 이전 버전 제거 (배큠)
delta_table.vacuum(retentionHours=168)  # 7일 보관

-- Iceberg: 컴팩션을 위한 데이터 파일 재작성
CALL catalog.system.rewrite_data_files(
  table => 'analytics.events',
  strategy => 'binpack',
  options => map('target-file-size-bytes', '134217728')
);

-- Iceberg: 오래된 스냅샷 만료 처리
CALL catalog.system.expire_snapshots(
  table => 'analytics.events',
  older_than => TIMESTAMP '2026-07-01 00:00:00',
  retain_last => 10
);

Z-오더링은 관련 데이터를 클러스터링하여 술어 푸시다운의 효과를 향상시킵니다. 스트리밍 소스에서 많은 작은 파일을 수집할 때 두 포맷 모두 파일 컴팩션의 이점을 누릴 수 있습니다.

데이터 레이크하우스 면접에서 자주 묻는 질문

데이터 엔지니어링 면접에서 자주 출제되는 질문들을 준비합니다.

Q: Iceberg를 Delta Lake보다 선택하는 경우는 언제입니까?

Iceberg가 적합한 경우: (1) 여러 쿼리 엔진(Spark, Trino, Flink)이 동일한 테이블에 접근하는 경우, (2) 데이터 재작성 없이 파티션 스키마를 발전시켜야 하는 경우, (3) 조직이 벤더 중립적인 오픈 표준을 선호하는 경우. Delta Lake는 Databricks 중심 아키텍처 또는 Unity Catalog 거버넌스가 조직 니즈에 맞는 순수 Spark 환경에서 탁월합니다.

Q: Iceberg는 어떻게 데이터 재작성 없이 파티션 진화를 달성합니까?

Iceberg는 파티션 명세를 메타데이터로 저장합니다. 명세가 변경되면 새 데이터는 새 파티셔닝을 사용하고 기존 데이터는 원래 레이아웃을 유지합니다. 쿼리 플래너는 모든 파티션 명세를 읽고 각 파일 그룹에 대해 올바른 프루닝 로직을 적용합니다.

Q: Delta Lake의 체크포인트 메커니즘을 설명해 주세요.

Delta Lake는 기본적으로 10개의 커밋마다 체크포인트 파일을 생성합니다. 체크포인트는 트랜잭션 로그를 단일 Parquet 파일로 통합하여 더 빠른 읽기를 제공합니다. _last_checkpoint 파일은 최신 체크포인트를 가리키며, 리더는 체크포인트와 이후의 JSON 커밋을 읽어 상태를 재구성합니다.

Q: Copy-on-Write와 Merge-on-Read의 차이점은 무엇입니까?

Copy-on-Write(COW)는 업데이트 시 전체 파일을 재작성합니다. 쓰기 비용은 높지만 읽기가 빠릅니다. Merge-on-Read(MOR)는 델타를 별도로 작성하고 쿼리 시점에 병합합니다. 쓰기 지연 시간은 낮지만 읽기 오버헤드가 있습니다. Iceberg는 두 가지를 모두 지원하며, Delta Lake는 최근 버전에서 소프트 삭제를 위한 삭제 벡터와 함께 주로 COW를 사용합니다.

면접 전 이해를 확고히 하기 위해 SharpSkill의 데이터 엔지니어링 면접 문제에서 이러한 패턴을 연습하는 것을 권장합니다.

마이그레이션 경로: 포맷 간 변환

조직에서는 때때로 포맷 간 마이그레이션이 필요합니다. 두 포맷 모두 변환 유틸리티를 지원합니다.

# Spark를 사용하여 Delta에서 Iceberg로 변환
spark.sql("""
    CALL catalog.system.snapshot(
        source_table => 'delta.`s3://bucket/delta_events`',
        table => 'analytics.events_iceberg'
    )
""")

# Iceberg에서 Delta로 변환
from delta.tables import DeltaTable

iceberg_df = spark.read.format("iceberg").load("catalog.analytics.events")
iceberg_df.write.format("delta").save("s3://bucket/delta_events")

전체 마이그레이션에는 스키마 타입, 파티셔닝 시맨틱, 다운스트림 컨슈머 호환성에 대한 신중한 검증이 필요합니다.

결론

• Spark 네이티브 워크로드, Databricks 환경, Unity Catalog 거버넌스가 조직 니즈에 맞는 경우 Delta Lake를 선택합니다
• 멀티 엔진 아키텍처, 파티션 진화 요구 사항, 클라우드 불가지론적 배포의 경우 Iceberg를 선택합니다
• 두 포맷 모두 ACID 트랜잭션, 타임 트래블, 스키마 진화를 제공합니다. 올바른 선택은 기존 인프라와 쿼리 엔진 다양성에 따라 달라집니다
• 면접 준비는 트랜잭션 로그 내부, 파티션 프루닝 최적화, COW vs MOR 트레이드오프를 다루어야 합니다
• 파일 컴팩션과 스냅샷 만료 처리는 포맷 선택과 관계없이 중요한 유지보수 작업으로 남습니다