원문: Delta Live Tables: Declarative ETL
주의 참고: 원문 URL(https://www.databricks.com/blog/delta-live-tables-declarative-etl)은 현재 404 오류를 반환합니다. 이 번역은 Databricks 공식 블로그 GA 발표(2022년 4월) 및 공식 DLT 문서를 기반으로 작성되었습니다. 관련 원문은 Announcing General Availability of Databricks Delta Live Tables에서 확인할 수 있습니다.
참고 핵심 요약
- 선언적 ETL: Delta Live Tables(DLT)는 데이터 엔지니어가 “무엇을 원하는지”만 선언하면, 실행 방법·인프라·의존성 관리를 플랫폼이 자동으로 처리합니다.
- 배치 + 스트리밍 통합: 동일한 코드로 배치 파일과 실시간 스트리밍 소스를 처리하며, DLT가 실행 시맨틱스를 자동으로 결정합니다.
- 내장 데이터 품질: CONSTRAINT(제약 조건) 기반의 기대값(Expectations)으로 데이터 품질을 파이프라인 레벨에서 선언적으로 보장합니다.
- 완전 관리형 운영: 클러스터 프로비저닝, 자동 스케일링, 재시도, 체크포인트, 리니지(Lineage) 추적이 모두 자동화됩니다.
전통적 ETL의 한계: 왜 새로운 접근이 필요한가
데이터 엔지니어링 팀은 수십 년간 동일한 문제와 씨름해 왔습니다. 데이터를 추출하고, 변환하고, 적재하는 것 자체는 단순해 보이지만, 실제 운영 환경에서는 수많은 질문에 답해야 합니다. 데이터를 어떻게 추출할 것인가? 변환 단계를 어떻게 오케스트레이션할 것인가? 인프라를 어떻게 관리하고 스케일링할 것인가? 파이프라인 간 의존성을 어떻게 추적할 것인가? 실패 시 어떻게 재시도할 것인가? 데이터 품질을 어떻게 보장할 것인가? 이 모든 질문은 비즈니스 가치와는 무관한 도구적 복잡성 입니다. 데이터 엔지니어가 실제 데이터 변환 로직이 아니라 인프라 관리와 오케스트레이션에 대부분의 시간을 소비하는 것이 전통적 ETL의 근본적인 문제입니다. 전통적인 ETL 파이프라인의 전형적인 과제를 구체적으로 살펴보면 다음과 같습니다. 명령형 코드(Imperative Code) 방식에서는 각 처리 단계를 순서대로 기술하고 모든 실행 세부 사항을 명시해야 합니다. 수동 의존성 관리 에서는 테이블 간 의존 관계를 개발자가 직접 정의하고 유지해야 하며, 의존성 변경 시 파이프라인 전체를 수동으로 업데이트해야 합니다. 인프라 부담 측면에서는 클러스터 크기 결정, 자동 스케일링 설정, 장애 복구 로직 구현이 모두 개발자의 몫입니다. 데이터 품질 관리 는 별도의 검증 코드를 작성해야 하며, 품질 이슈가 하류(Downstream)로 전파되는 것을 막기 위한 추가 로직이 필요합니다.“우리는 더 이상 Databricks에게 ETL을 ‘어떻게’ 할지 알려주지 않습니다. 우리가 ‘무엇을 원하는지’만 말하면, Databricks가 나머지를 알아서 처리합니다.”
Delta Live Tables란 무엇인가
Delta Live Tables(DLT)는 Databricks가 개발한 선언적 ETL 프레임워크 입니다. DLT는 단순히 새로운 도구가 아니라, ETL 개발 패러다임을 근본적으로 바꾸는 접근 방식입니다. 데이터 엔지니어는 SQL 또는 Python을 사용해 데이터 변환의 결과 만 정의하면 되고, 실행 순서·클러스터 관리·의존성 해소·오케스트레이션은 DLT가 자동으로 처리합니다. DLT의 핵심 철학은 선언형 프로그래밍(Declarative Programming) 에 있습니다. 개발자는 원하는 상태(What)를 기술하고, 플랫폼이 그 상태에 도달하는 방법(How)을 결정합니다. 이는 Terraform이 인프라를 선언적으로 관리하는 것과 동일한 원리입니다. DLT로 데이터 엔지니어가 정의하는 것은 다음과 같습니다.- 소스(Source): 데이터를 어디서 읽을 것인가
- 변환(Transformations): 데이터를 어떻게 바꿀 것인가
- 기대값(Expectations): 데이터 품질 조건은 무엇인가
- 의존성(Dependencies): 테이블 간 관계는 어떻게 되는가
- 오케스트레이션: 실행 순서와 태스크 스케줄링
- 인프라 관리: 클러스터 프로비저닝과 자동 스케일링
- 의존성 해소: DAG 자동 생성 및 관리
- 리니지 추적: 엔드투엔드 데이터 계보 자동 캡처
- 모니터링: 파이프라인 상태와 데이터 품질 메트릭 추적
- 재시도와 복구: 장애 시 자동 재시도 및 체크포인트 기반 복구
- 배치 + 스트리밍 통합: 동일 코드로 두 처리 방식 지원
DLT의 실행 모델: 내부에서 무슨 일이 일어나는가
DLT가 선언적 코드를 받아 실제로 실행하기까지의 과정을 단계별로 이해하면 프레임워크를 더욱 효과적으로 활용할 수 있습니다.1단계: 선언적 코드 작성
가장 기본적인 DLT 예시를 보겠습니다.2단계: DAG 자동 컴파일
DLT는 코드 내 테이블 참조를 분석하여 Directed Acyclic Graph(방향성 비순환 그래프)를 자동으로 생성합니다. 복잡한 파이프라인도 마찬가지입니다.| 레이어 | 테이블 | 소스 |
|---|---|---|
| Landing | 원시 파일 | 외부 소스 |
| Bronze | orders_bronze | Landing 파일 |
| Silver | orders_silver_cleaned | orders_bronze |
| Gold | daily_sales_gold | orders_silver |
3단계: 실행 시맨틱스 결정
DLT는 소스 유형에 따라 실행 방식을 자동으로 결정합니다.- 정적 파일 소스 → 배치(Batch) 처리
- 스트리밍 소스(Kafka, Kinesis 등) → 스트리밍 처리
- 혼합 소스 → 하이브리드 파이프라인
4단계: 컴퓨팅 프로비저닝
DLT는 파이프라인 유형과 데이터 볼륨에 맞게 클러스터를 자동으로 선택하고 프로비저닝합니다. 서버리스 DLT(Serverless DLT) 를 사용하면 클러스터 관리가 완전히 추상화되어, 개발자는 컴퓨팅 인프라에 대해 전혀 신경 쓸 필요가 없습니다.5단계: 오케스트레이션, 재시도, 장애 처리
DLT는 DAG 기반으로 태스크 실행 순서를 자동으로 결정하고, 실패한 스테이지를 재시도하며, 마지막 일관된 체크포인트에서 재시작합니다. 이는 정확히 한 번 처리(Exactly-once Processing)를 보장합니다. 별도의 Airflow, ADF 같은 오케스트레이션 도구 없이 DLT가 이 역할을 대체합니다.6단계: 자동 리니지 추적
DLT는 입력, 출력, 변환 로직을 모두 파악하고 있기 때문에 엔드투엔드 데이터 계보를 자동으로 구축합니다. 컬럼 수준의 리니지까지 별도 도구 없이 제공됩니다. Unity Catalog와 통합 시 이 리니지 정보는 Data Explorer에서 시각적으로 확인할 수 있습니다.7단계: 지속적 최적화
DLT는 실행 과정에서 세 가지 방식으로 성능을 자동 최적화합니다. 증분 처리 는 변경된 데이터만 재처리합니다. 의존성 가지치기(Dependency Pruning) 는 업스트림이 변경되지 않으면 다운스트림 테이블 재계산을 건너뜁니다. 적응형 실행(Adaptive Execution) 은 데이터 볼륨과 메트릭에 따라 실행 계획을 동적으로 조정합니다.데이터 품질: 기대값(Expectations)으로 선언적 품질 보장
DLT의 가장 강력한 기능 중 하나는 선언적 데이터 품질 관리 입니다. 별도의 검증 코드를 작성하는 대신, 데이터 품질 조건을 테이블 정의에 직접 선언합니다.| ON VIOLATION 옵션 | 동작 | 사용 시나리오 |
|---|---|---|
DROP ROW | 위반 행을 제거하고 처리 계속 | 필수 식별자 누락, 음수 금액 등 치명적 오류 |
FAIL UPDATE | 파이프라인 실행 중단 | 데이터 무결성이 절대적으로 중요한 경우 |
WARN (기본값) | 경고 로그 기록, 처리 계속 | 소프트한 품질 이슈, 모니터링 목적 |
DROP ROW는 불량 데이터를 즉시 제거하여 다운스트림에 오염이 전파되는 것을 막습니다. FAIL UPDATE는 파이프라인 전체를 중단시켜 즉각적인 대응을 강제합니다. WARN은 기록을 남기되 처리를 계속하여 데이터 탐색 단계에서 유용합니다.
DLT는 이 기대값들을 자동으로 추적하고, UI에서 품질 메트릭 대시보드를 통해 시간에 따른 품질 트렌드를 시각화합니다. 이를 통해 데이터 품질 저하를 사전에 감지하고 근본 원인을 빠르게 파악할 수 있습니다.
Medallion 아키텍처와 DLT의 자연스러운 통합
Delta Live Tables는 Medallion 아키텍처(메달리온 아키텍처) — Bronze, Silver, Gold 레이어 구조 — 와 완벽하게 설계적으로 정렬되어 있습니다. DLT의 선언적 의존성 모델은 레이어 간 데이터 흐름을 자연스럽게 표현합니다.Bronze 레이어: 원시 데이터 수집
Bronze 레이어는 소스 데이터를 최소한의 변환만으로 Delta 포맷으로 저장합니다. 이 레이어는 진실의 원천(Source of Truth) 역할을 하며, 불변성(Immutability)과 재처리 가능성(Replayability)이 핵심입니다.cloud_files)는 새로운 파일이 도착하면 자동으로 감지하여 증분 수집합니다. 파일 메타데이터(_metadata.file_name)를 함께 저장하면 데이터 계보 추적이 용이해집니다.
Silver 레이어: 정제와 풍부화
Silver 레이어는 Bronze 데이터를 정제하고, 비즈니스 규칙을 적용하며, 데이터 품질을 보장합니다. SCD Type 2(Slowly Changing Dimension Type 2)와 같은 복잡한 병합 로직도 선언적으로 처리할 수 있습니다.APPLY CHANGES INTO 또는 AUTO CDC 구문으로 선언적으로 처리합니다.
valid_from, valid_to), 현재 버전 플래그(is_current), 버전 번호 관리 등이 모두 자동화됩니다. 전통적인 방식으로 구현하면 수십 줄의 복잡한 MERGE SQL이 필요한 작업입니다.
Gold 레이어: 비즈니스 집계
Gold 레이어는 분석가, 비즈니스 사용자, ML 팀을 위한 도메인별 집계 데이터를 제공합니다. DLT의MATERIALIZED VIEW는 의존성이 변경될 때 자동으로 갱신됩니다.
Python API로 작성하는 DLT 파이프라인
SQL만큼 Python API도 강력합니다. 복잡한 비즈니스 로직, 커스텀 UDF, 재사용 가능한 유틸리티 함수가 필요한 경우 Python DLT API를 활용합니다.@dp.table, @dp.expect_or_drop, @dp.materialized_view)은 코드를 직관적이고 테스트하기 쉽게 만들어 줍니다.
AUTO CDC: 변경 데이터 캡처의 선언적 처리
AUTO CDC(자동 변경 데이터 캡처) 는 DLT의 최신 CDC 처리 방식으로, 전통적인APPLY CHANGES INTO보다 더욱 간결하고 강력합니다.
| 전략 | 사용 시점 | DLT 동작 |
|---|---|---|
| 단조 증분(Monotonic Append) | 순서가 보장된 CDC 피드 | 신규 레코드만 처리, 이력 수정 불필요 |
| 병합 업데이트(Merge Updates) | 키 수준 변경이 있는 경우 | 영향받은 키만 만료/재삽입, 전체 재계산 불필요 |
| 파티션 재계산(Partition Recompute) | 늦게 도착한 데이터로 과거 이력 수정 필요 | 영향받은 파티션/시간 범위만 재계산 |
| 전체 재계산(Full Recompute) | 대규모 백필, 변환 로직 전면 변경 | 테이블 전체 재구성, 코드 변경 불필요 |
KEYS는 비즈니스 엔티티의 식별자를 정의하고, SEQUENCE BY는 변경의 올바른 순서를 결정합니다. 이 두 요소가 없으면 SCD Type 2의 신뢰성을 보장할 수 없습니다.
Unity Catalog와 서버리스 DLT: 현대적 DLT 파이프라인
DLT는 현재 두 가지 방식으로 운영됩니다. 다음 표는 레거시 방식과 현대적 방식의 주요 차이를 보여줍니다. 새로운 프로젝트에서는 Unity Catalog + 서버리스 조합이 권장됩니다.| 항목 | 레거시 방식 | 현대적 방식 |
|---|---|---|
| 메타스토어 | Hive Metastore | Unity Catalog |
| 컴퓨팅 | Classic Job Cluster | Serverless DLT |
| 스토리지 참조 | Mount Points | Volumes (3-레벨 네임스페이스) |
| CDC 구문 | APPLY CHANGES INTO | AUTO CDC (또는 혼용) |
| 네임스페이스 | 2-레벨 (database.table) | 3-레벨 (catalog.schema.table) |
| LIVE 키워드 | 필요 | 불필요 |
| 거버넌스 | 제한적 | Unity Catalog 완전 통합 |
실제 도입 사례: 기업들이 DLT를 선택하는 이유
Delta Live Tables는 출시 이후 전 세계 1,000개 이상의 기업에서 채택되었습니다. ADP, Shell, H&R Block, Jumbo, Bread Finance, JLL을 포함한 다양한 산업의 선도 기업들이 DLT를 활용하여 다음 세대의 셀프서비스 분석과 데이터 애플리케이션을 구축하고 있습니다. Deloitte 는 DLT를 활용하여 복잡한 데이터 파이프라인을 선언적으로 구축하는 내부 모범 사례를 개발했습니다. 팀의 생산성이 크게 향상되었고, 파이프라인 장애로 인한 운영 부담이 현저히 감소했습니다. DLT 도입 기업들이 공통적으로 보고하는 비즈니스 효과는 세 가지입니다. 운영 부담 감소 는 별도 오케스트레이션 도구, 수동 클러스터 관리, 커스텀 재시도 로직, 모니터링 프레임워크가 불필요해집니다. 데이터 신뢰성 향상 은 내장 기대값과 자동 품질 추적으로 데이터 품질 이슈를 조기에 발견하고 하류 오염을 방지합니다. 개발 속도 가속 은 인프라와 오케스트레이션이 아닌 비즈니스 로직과 데이터 모델링에 집중할 수 있어 파이프라인 개발 사이클이 단축됩니다.선언적 ETL이 팀 생산성에 미치는 영향
선언적 ETL은 단순히 기술적 개선이 아니라 팀의 일하는 방식을 근본적으로 바꿉니다. 전통적인 명령형 ETL에서는 데이터 엔지니어가 비즈니스 로직을 구현하기 전에 먼저 인프라 설계, 오케스트레이션 구조, 재시도 전략을 결정해야 했습니다. 이는 높은 인지 부하(Cognitive Load)를 유발하고 실수를 낳습니다. DLT의 선언적 접근은 이 인지 부하를 플랫폼에 위임합니다. 또한, 선언적 코드는 의도가 명확하기 때문에 코드 리뷰와 유지보수가 쉽습니다. 새로운 팀원이 파이프라인 코드를 보더라도 “이 코드가 무엇을 하는가”를 즉시 이해할 수 있습니다. 실패 시 복구도 간단해집니다. DLT가 체크포인트와 상태를 관리하기 때문에, 파이프라인이 실패하면 마지막 일관된 상태에서 자동 재시작됩니다. 데이터 중복이나 상태 손상 없이 안전하게 재처리됩니다.DLT와 Lakeflow: 미래 방향
2025년 Databricks Data + AI Summit에서 Delta Live Tables는 Lakeflow Declarative Pipelines 라는 이름으로 더 넓은 Lakeflow 플랫폼에 통합되었습니다. Lakeflow는 세 가지 핵심 컴포넌트로 구성됩니다.- Lakeflow Connect: SQL Server, Salesforce, Workday, Google Analytics, ServiceNow, SharePoint 등 엔터프라이즈 소스를 위한 네이티브 고스케일 커넥터
- Lakeflow Declarative Pipelines (기존 DLT): 선언적 변환 레이어
- Lakeflow Jobs: 워크플로우 오케스트레이션
참고 마이그레이션 가이드: 기존 DLT 파이프라인을 Lakeflow Declarative Pipelines로 전환하는 방법은 What happened to Delta Live Tables (DLT)? 문서를 참고하세요.
결론: 현대 데이터 엔지니어링의 새로운 기준
Delta Live Tables는 ETL 개발의 패러다임 전환을 대표합니다. 파이프라인 코드를 도구 관리가 아닌 데이터 모델링 에 집중할 수 있게 해주는 이 프레임워크는, 현대 데이터 엔지니어링에서 점점 더 중요한 역할을 차지하고 있습니다. 선언적 접근, 내장 데이터 품질, 통합 배치+스트리밍 처리, 자동 리니지 추적 — 이 네 가지 특성이 DLT를 단순한 편의 도구가 아닌, 엔터프라이즈급 데이터 파이프라인의 근본적인 재설계로 만들어 줍니다.“현대 데이터 엔지니어링은 Spark 코드를 작성하는 것에 관한 것이 아닙니다. 실제 세계의 데이터 동작에 자동으로 적응하는 탄력적이고 상태 인식 가능한 데이터 시스템을 설계하는 것입니다.”