왜 파이프라인 설정이 중요한가?
SDP(Spark Declarative Pipelines, 구 Delta Live Tables)는 파이프라인의 실행 모드, 클러스터 구성, 타겟 카탈로그, 채널 등을 설정을 통해 제어합니다. 올바른 설정은 개발 생산성, 프로덕션 안정성, 비용 효율성에 직접적인 영향을 미칩니다.Development vs Production 모드
SDP는 두 가지 실행 모드를 제공하며, 각 모드는 파이프라인의 동작 방식이 크게 다릅니다.| 비교 항목 | Development 모드 | Production 모드 |
|---|---|---|
| 데이터 재처리 | 전체 데이터가 아닌 2개 파일만 샘플 처리합니다 | 전체 데이터 를 처리합니다 |
| 클러스터 재사용 | 실행 사이에 클러스터를 유지합니다 (빠른 반복) | 매 실행마다 클러스터를 새로 생성합니다 |
| 오류 처리 | 오류 발생 시 파이프라인을 즉시 중단합니다 | 재시도 정책에 따라 자동 복구를 시도합니다 |
| 비용 | 클러스터 유지 비용 발생 | 실행 시에만 비용 발생 |
| 적합한 용도 | 개발, 디버깅, 테스트 | 프로덕션 운영 |
| 모드 | 특징 | 설명 |
|---|---|---|
| Development 모드 | 샘플 데이터, 클러스터 유지, 빠른 피드백 | 개발 및 테스트에 적합합니다 |
| Production 모드 | 전체 데이터, 클러스터 자동 관리, 재시도 정책 | 프로덕션 운영에 적합합니다 |
Development 모드에서 검증을 완료한 후 Production 모드로 전환합니다.
🔥 현업 사례: Development 모드와 Production 모드를 혼동해서 데이터를 날린 경험 한 고객사의 데이터 엔지니어가 프로덕션 파이프라인을 수정한 후, Development 모드인 줄 모르고 “Start” 버튼 을 눌렀습니다. Development 모드에서는 기존 테이블을 삭제하고 샘플 데이터만으로 재생성하기 때문에, 프로덕션 Gold 테이블 3개의 데이터가 샘플 2개 파일 분량으로 대체 되었습니다. 마침 BI 대시보드가 이 테이블을 참조하고 있었고, 경영진이 “매출이 갑자기 99% 줄었다”고 보고받는 사태가 벌어졌습니다. 복구 과정: Delta의 Time Travel 기능(RESTORE TABLE ... TO VERSION AS OF)으로 데이터를 복구했지만, 원인 파악과 복구에 약 2시간이 소요되었습니다. 재발 방지책:
- 프로덕션 파이프라인은 반드시
"development": false로 고정(UI에서 변경 불가하도록)- 개발용과 프로덕션용 파이프라인을 물리적으로 분리(같은 파이프라인에서 모드 전환 금지)
- 프로덕션 파이프라인은 Asset Bundles로만 배포(UI 직접 수정 금지)
안전한 개발-프로덕션 분리 패턴
현업에서 권장하는 패턴은 같은 코드, 다른 파이프라인 입니다.databricks bundle deploy -t dev와 databricks bundle deploy -t prod로 완전히 분리된 파이프라인이 생성되어, 모드 혼동 사고를 원천 차단할 수 있습니다.
클러스터 설정
서버리스 컴퓨트
서버리스를 선택하면 클러스터 구성을 직접 관리할 필요가 없습니다. Databricks가 자동으로 인프라를 프로비저닝합니다.| 장점 | 고려사항 |
|---|---|
| 클러스터 시작 대기 시간 최소화 | 커스텀 라이브러리 설치 제한 |
| 인프라 관리 불필요 | 특정 인스턴스 타입 지정 불가 |
| 자동 스케일링 | 일부 워크로드에서 비용이 다를 수 있음 |
Job Cluster (클래식)
세밀한 클러스터 제어가 필요한 경우 직접 클러스터를 구성합니다.| 클러스터 레이블 | 용도 |
|---|---|
default | 파이프라인의 기본 처리에 사용됩니다 |
maintenance | OPTIMIZE, VACUUM 같은 유지보수 작업에 사용됩니다 |
Auto Scaling 설정
Enhanced Autoscaling의 실전 효과
SDP의 Enhanced Autoscaling 은 일반 클러스터의 Autoscaling과 다릅니다. 파이프라인의 데이터 흐름 단계를 이해하고, 각 단계에서 필요한 만큼만 노드를 할당 합니다.| 비교 항목 | 일반 Autoscaling | Enhanced Autoscaling (SDP) |
|---|---|---|
| 스케일 기준 | CPU/메모리 사용률 | 데이터 흐름 단계별 워크로드 |
| 스케일 속도 | 느림 (메트릭 수집 후 판단) | 빠름 (파이프라인 그래프 분석) |
| 과잉 프로비저닝 | 빈번함 | 최소화 |
| 실전 비용 절감 | 10~20% | 30~50% |
💡 현업 팁: Enhanced Autoscaling의 효과가 가장 극적인 경우는 ”** Bronze에서 대량 수집 → Silver에서 소량 변환 → Gold에서 집계**” 패턴입니다. Bronze 단계에서 10개 노드가 필요해도, Gold 단계에서는 2개면 충분합니다. Enhanced Autoscaling은 이 차이를 자동으로 감지하여 노드를 줄입니다.
Channel (채널) 설정
채널은 SDP 런타임의 버전 을 결정합니다. 신기능 테스트와 프로덕션 안정성 사이의 균형을 맞출 수 있습니다.| 채널 | 설명 | 권장 용도 |
|---|---|---|
| Current | 최신 안정 버전의 SDP 런타임입니다 | 프로덕션 환경 |
| Preview | 차기 버전의 기능을 미리 사용할 수 있습니다 | 개발, 신기능 테스트 |
타겟 카탈로그/스키마 설정
Unity Catalog 통합
SDP 파이프라인의 결과 테이블을 Unity Catalog에 저장합니다.| 설정 | 설명 |
|---|---|
catalog | 결과 테이블이 저장될 Unity Catalog 카탈로그입니다 |
target | 결과 테이블이 저장될 스키마(데이터베이스)입니다 |
CREATE STREAMING TABLE orders를 실행하면 production.sales_data.orders로 생성됩니다.
💡 카탈로그/스키마를 파이프라인 레벨에서 설정하면, 개별 테이블 정의에서 3단계 네임스페이스를 매번 작성할 필요가 없습니다.
파이프라인 설정 전체 예제
JSON 설정
YAML 설정 (Asset Bundles)
주요 설정 옵션 총정리
| 설정 | 설명 | 기본값 |
|---|---|---|
name | 파이프라인 이름입니다 | (필수) |
catalog | Unity Catalog 카탈로그입니다 | — |
target | 타겟 스키마(데이터베이스)입니다 | — |
serverless | 서버리스 컴퓨트 사용 여부입니다 | false |
channel | 런타임 채널입니다 (CURRENT/PREVIEW) | CURRENT |
development | 개발 모드 활성화 여부입니다 | true |
continuous | 연속 실행 모드 여부입니다 | false |
photon | Photon 엔진 활성화 여부입니다 | false |
edition | 에디션입니다 (CORE/PRO/ADVANCED) | ADVANCED |
configuration | 파이프라인에서 사용할 키-값 매개변수입니다 | {} |
libraries | 파이프라인에 포함할 노트북/파일 목록입니다 | (필수) |
configuration 매개변수 활용
configuration에 정의한 값은 파이프라인 코드에서 spark.conf.get()으로 접근할 수 있습니다.
Continuous 모드 vs Triggered 모드
| 모드 | 동작 | 적합한 시나리오 |
|---|---|---|
| Triggered(기본값) | 한 번 실행하고 종료합니다. 새 데이터가 있으면 처리하고 멈춥니다 | 배치 ETL, 스케줄 실행 |
| Continuous | 항상 실행 상태를 유지하며, 새 데이터가 도착하면 즉시 처리합니다 | 실시간 스트리밍, 저지연 요구 |
⚠️ Continuous 모드는 항상 클러스터가 실행 중이므로 비용이 지속적으로 발생합니다. 실시간 요구사항이 없다면 Triggered 모드 + 스케줄링을 권장합니다.
실전 비용 비교: Continuous vs Triggered
현업에서 가장 많이 묻는 질문이 “Continuous 모드 비용이 얼마나 되나요?”입니다.| 모드 | 24시간 기준 비용 (4 Worker, i3.xlarge) | 월 비용 예상 | 데이터 지연 |
|---|---|---|---|
| Continuous | 24시간 × 50/일 | ~$1,500/월 | 수초~수분 |
| Triggered (1시간 간격) | 24회 × 10분 = 4시간 × 8/일 | ~$250/월 | 최대 1시간 |
| Triggered (15분 간격) | 96회 × 10분 = 16시간 × 33/일 | ~$1,000/월 | 최대 15분 |
💡 현업 팁: 대부분의 내부 분석/BI 용도에서는 15분~1시간 지연이 허용 됩니다. “실시간이 필요하다”고 요청하는 경우에도, 실제로 확인해 보면 “1시간 이내면 충분”인 경우가 80% 이상입니다. Continuous 모드는 정말 분 단위 지연이 비즈니스에 직접적인 영향을 미치는 경우(사기 탐지, 실시간 추천 등)에만 사용하세요.
서버리스 SDP의 비용 예측 방법
서버리스 SDP는 인프라를 자동 관리하지만, 비용 예측이 어렵다는 현업의 피드백이 있습니다.비용 구성 요소
| 구성 요소 | 과금 기준 | 비중(일반적) |
|---|---|---|
| 처리 DBU | 데이터 처리량(바이트)에 비례 | 70~80% |
| 대기 DBU | Continuous 모드 시 유휴 대기 | 10~20% |
| 유지보수 DBU | OPTIMIZE, VACUUM 자동 실행 | 5~10% |
비용 예측을 위한 실전 공식
🔥 현업에서는: 서버리스 SDP 비용을 정확히 예측하기 어려우므로, 첫 달은 클래식(Job Cluster)과 서버리스를 병렬로 돌려서 비용을 비교 하는 것을 권장합니다. 한 고객사에서는 서버리스 전환 후 비용이 20% 절감된 반면, 다른 고객사에서는 10% 증가한 사례도 있었습니다. 워크로드 특성에 따라 다르므로 반드시 직접 비교 테스트를 하세요.
서버리스 비용 모니터링
정리
| 핵심 설정 | 권장값 |
|---|---|
| 개발 단계 | Development 모드, Preview 채널 |
| 프로덕션 | Production 모드, Current 채널 |
| 비용 최적화 | 서버리스 또는 Spot 인스턴스 |
| 성능 최적화 | Photon 활성화, Auto Scaling |
| 환경 분리 | Asset Bundles 변수로 카탈로그/스키마 분리 |