데이터 레이크하우스에서 Delta Lake·Iceberg·Databricks를 선택하는 기준

데이터 레이크하우스의 테이블 포맷, 카탈로그, 컴퓨트 계층을 기준으로 Delta Lake·Apache Iceberg·Databricks의 운영 전략과 선택 기준을 정리한다.

2026-08-14 · 최초 발행 2025-10-14

오브젝트 스토리지 위에 웨어하우스의 제어면을 올리는 방식

데이터 레이크하우스는 데이터 레이크의 확장성과 비용 효율성에 데이터 웨어하우스의 스키마 관리, ACID 트랜잭션, 거버넌스를 결합한 분석 플랫폼 아키텍처다. 핵심은 개방형 테이블 포맷과 범용 컴퓨트 계층을 연결해 분석과 AI 워크로드를 한곳에서 다루는 데 있다.

테이블 포맷은 오브젝트 스토리지에서 ACID, 스냅샷, 스키마 진화를 보장하는 메타데이터 레이어다. Delta Lake와 Apache Iceberg가 대표적이다. Databricks는 Delta Lake를 중심으로 Unity Catalog, 워크플로우, Photon 같은 운영 편의 기능을 제공하는 매니지드 레이크하우스 플랫폼이다. 특정 기능의 최신 지원 범위는 최신 정보 확인이 필요하다.

테이블 포맷부터 카탈로그까지 이어지는 구성

Delta Lake는 트랜잭션 로그(_delta_log)를 바탕으로 낙관적 락, MERGE·DELETE·UPDATE, 타임 트래블, Change Data Feed를 제공한다. Optimize와 Z-Order 같은 파일·레이아웃 최적화 기능도 있으며, 지원 범위는 환경마다 다를 수 있다.

Apache Iceberg는 스냅샷과 매니페스트 기반 메타데이터를 사용한다. 히든 파티셔닝, 포지션·이퀄리티 딜리트, 브랜치와 태그를 지원하며, 스냅샷 만료와 파일 리라이트로 성능·비용을 조정할 수 있다.

이 테이블들을 Hive Metastore, Glue, Unity Catalog 같은 카탈로그와 연결하면 오브젝트 스토리지 경로를 테이블로 추상화하고 권한, 라인리지, 데이터 마스킹 정책을 적용할 수 있다. 멀티엔진 환경에서는 스키마와 권한을 일관되게 관리하고 감사 로깅과 감사지표를 일원화해야 한다.

컴퓨트 계층에는 Spark, Trino/Presto, Flink, Snowflake(External Tables), Databricks SQL 등이 참여할 수 있다. 공용 테이블에 여러 엔진이 접근하며, Structured Streaming 또는 Flink를 통해 배치와 스트리밍을 함께 처리한다. 벡터화와 컬럼식 실행은 비용·성능 최적화의 기반이 된다.

운영 계층에서는 Bronze에서 Silver, Gold로 이어지는 레이어를 두고 CDC·업서트 중심의 증분 처리를 구성한다. 체크포인트와 오프셋 관리는 재시도와 정합성에 관여한다. 소파일 문제를 줄이기 위한 컴팩션(Delta Optimize/Iceberg Rewrite Data Files), 스냅샷 정리(VACUUM/Expire Snapshots)도 정례화 대상이다.

보안은 스토리지 IAM, 카탈로그 RBAC, 열·행 수준 보안, PII 마스킹·토큰화, 감사 추적으로 구성한다. KMS 기반 키 관리, 데이터 보존·파기 정책, 교차 리전 DR, 데이터 무결성 검증 절차도 함께 설계한다.

적재부터 제공까지의 일관성 경로

입력 단계에서는 CDC·이벤트 스트림과 배치 파일 드랍을 받는다. 처리 과정은 스키마 검증, 업서트 또는 MERGE, 컴팩션, 스냅샷 고정으로 이어지고, 조회는 타임 트래블과 스냅샷 일관성을 기준으로 제공한다. 오류가 발생하면 체크포인트에서 재처리하고, 커밋 실패 시 롤백과 스냅샷 재시작을 적용한다.

출력트랜잭션/일관성처리입력CDC/Batch/Stream성공실패소스 시스템DB/로그/이벤트수집Kafka/Flink/SparkBronze원시 저장Open Table FormatSilver정제/스키마 정합Gold서빙 모델/집계커밋 시도메타데이터 스냅샷 갱신Delta Log or IcebergSnapshot롤백/재시도체크포인트 복원BI/SQLTrino/DBSQLML/Feature Store데이터 제품/API

포맷과 플랫폼이 나뉘는 지점

지표 Delta Lake Apache Iceberg Databricks(플랫폼)
성능 로그 기반 커밋, Optimize/Z-Order로 범위·조인 성능 향상. CDF로 증분 처리 최적화 매니페스트·히든 파티셔닝으로 프룬·스캔 효율 우수. 포지션 딜리트로 머지 비용 절감 Photon 등 벡터화 엔진, 자동 옵스(Optimize/Autotune)로 일관된 성능
확장성 수십 PB 사례, OSS/클라우드 네이티브 확장 메타데이터 스케일 안정성 우수, 파일 수 대규모 환경에 강점 관리형 클러스터/서버리스, 워크로드 자동 스케일
일관성 낙관적 동시성, 스냅샷 일관성, 타임 트래블 지원 스냅샷/브랜치/태그, 멀티테이블 오케스트레이션 유연 카탈로그·권한·라인리지 통합으로 일관성 운영
안정성 트랜잭션 로그 손상 대비 복구 절차 필요 매니페스트 정합성 유지 및 GC 정책 중요 SLA 기반 관리, 백업/감사/보안 연계
운영 편의 OSS 중심, 엔진 호환성은 구현별 상이 광범위 엔진 지원, 표준화된 API 올인원 UI/워크플로우/모니터링, 벤더 종속성 트레이드오프

실제 성능과 기능 범위는 버전, 클라우드, 엔진 조합에 따라 다르므로 최신 정보 확인이 필요하다.

같은 테이블을 여러 워크로드에 쓰는 패턴

CDC 기반 업서트 파이프라인에서는 Debezium/Kafka에서 Bronze로 적재한 뒤 MERGE INTO로 Silver를 정합화한다. CDF 또는 스냅샷 시간을 기준으로 증분 집계를 수행해 Gold 서비스를 구성할 수 있다.

배치·스트리밍 통합 ETL에서는 디바이스 텔레메트리 스트림과 참조 배치를 조인한다. 체크포인트와 워터마크는 지연 데이터 처리와 정확성 보장에 사용된다.

피처 스토어와 MLOps에서는 Gold 테이블을 오프라인·온라인 피처 동기화의 기준으로 삼고, 스냅샷 고정과 라인리지로 재현성을 확보한다.

멀티엔진 BI와 애드혹 분석에서는 Trino/DBSQL이 동일 테이블에 접근한다. 히든 파티셔닝과 Z-Order는 스캔 범위를 줄이는 데 활용된다.

운영 정책에서 결정되는 트레이드오프

고카디널리티 컬럼은 Iceberg의 히든 파티셔닝이나 Delta·플랫폼의 클러스터링으로 대체할 수 있다. 소파일을 막으려면 파일 크기 목표를 256MB~1GB로 두고 정기 컴팩션 일정을 수립한다.

스키마 진화에서는 Nullable→Non-Nullable 변경 제한 같은 호환성 규칙을 지켜야 한다. CDC 설계에서는 MERGE 모드(COPY-ON-WRITE)와 DELETE 파일(MERGE-ON-READ)의 트레이드오프를 고려한다.

카탈로그는 단일화해 권한과 라인리지를 일원화하고, 외부 엔진 호환이 필요하다면 Glue/Hive 병행을 검토한다. 열·행 수준 정책과 PII 마스킹은 카탈로그 계층에서 중앙 관리한다.

일관성 관점에서는 커밋 충돌에 대비한 낙관적 동시성 재시도와 보수적인 스냅샷 만료 정책이 필요하다. 백필과 재처리 설계에는 타임 트래블을 이용한 재현성을 포함한다.

Databricks의 운영 편의와 성능 이점을 택할지, 멀티클라우드와 엔진 휴대성을 우선할지도 결정해야 한다. 순수 OSS(Delta/Iceberg)를 선택한다면 모니터링과 옵스 자동화에 드는 추가 공수를 감안한다.

비용·성능·거버넌스에 미치는 변화

데이터 웨어하우스 전환과 비교하면 스토리지 비용은 30~60% 절감되고, 컴퓨트 최적화에 따라 TCO는 20~40% 절감될 수 있다. 파티션 프루닝과 레이아웃 최적화는 대규모 스캔 지연을 20~50% 단축하며, 증분 처리는 리프레시 시간을 50% 이상 단축한다. 이 수치는 환경별로 다르다.

ACID와 스냅샷 일관성은 오류 롤백 시간을 줄이고, 중앙 권한과 감사 체계는 규제 대응 효율을 높인다. BI와 ML이 같은 테이블을 재사용할 수 있어 데이터 제품화 속도도 높아진다.

레이크하우스의 선택은 포맷 하나를 고르는 문제에 그치지 않는다. 조직의 기술 스택, 운영 역량, 벤더 전략에 맞춰 포맷과 플랫폼을 정하고, 컴팩션·스냅샷·권한 관리를 표준 운영 절차로 굳혀야 한다.

데이터 레이크하우스Delta LakeApache IcebergDatabricks데이터 거버넌스