이 문서는 레이크하우스란? 의 하위 문서입니다.
심화: 레이크하우스의 한계와 실전 트레이드오프
레이크하우스가 만능은 아닙니다. Principal SA로서 고객에게 정직하게 전달해야 할 한계와 트레이드오프를 살펴보겠습니다.레이크하우스의 한계
| 한계 영역 | 상세 | 해결 방향 |
|---|---|---|
| OLTP 워크로드 | 레이크하우스는 분석(OLAP)에 최적화되어 있습니다. 웹 앱의 건 단위 INSERT/UPDATE(sub-ms 지연시간)에는 부적합합니다 | Lakebase 로 해결: PostgreSQL OLTP를 레이크하우스와 통합합니다 |
| 실시간 저지연(<100ms) | Structured Streaming도 마이크로배치 기반이므로 수백 ms~수 초의 지연이 발생합니다. Delta Lake의 commit 오버헤드도 있습니다 | Kafka/Flink 조합으로 실시간 레이어를 별도 구성하거나, Lakebase + Change Data Capture를 활용합니다 |
| 동시성 제한 | Delta Lake의 Optimistic Concurrency Control은 동일 파일에 대한 동시 쓰기 충돌 시 재시도가 필요합니다 | 파티셔닝으로 쓰기 충돌을 분산하고, delta.isolationLevel을 WriteSerializable로 설정합니다 |
| 소규모 데이터 | 수 MB~GB 수준의 데이터는 오히려 PostgreSQL이나 MySQL이 더 효율적입니다. 레이크하우스의 오버헤드(메타스토어, 파일 관리)가 과합니다 | 데이터 규모가 수십 GB 이상일 때 레이크하우스의 이점이 본격적으로 나타납니다 |
| 그래프 쿼리 | 관계형/컬럼형 스토리지 기반이므로, 그래프 탐색(친구의 친구, 최단 경로 등)에는 비용이 높은입니다 | Neo4j 등 전용 그래프 DB와 연동합니다 |
멀티 클라우드 레이크하우스 전략
엔터프라이즈 고객의 80% 이상이 2개 이상의 클라우드를 사용합니다. 멀티 클라우드 환경에서의 레이크하우스 전략은 다음과 같습니다.| 과제 | 상세 | Databricks 해법 |
|---|---|---|
| 데이터 레지던시 | GDPR(EU), 개인정보보호법(한국) 등으로 데이터가 특정 리전을 벗어날 수 없습니다 | 리전별 Workspace를 분리하고, Unity Catalog Metastore를 리전별로 운영합니다 |
| 크로스 클라우드 거버넌스 | AWS와 Azure의 Workspace에서 동일한 거버넌스 정책을 적용해야 합니다 | Unity Catalog의 Account-level 관리로 복수 클라우드의 Workspace를 단일 계정에서 통합 관리합니다 |
| 데이터 공유 | AWS의 데이터를 Azure에서 분석해야 하는 경우 | Delta Sharing 으로 크로스 클라우드 공유합니다. 데이터 복사 없이 읽기 권한만 부여합니다 |
| 재해 복구 | 한 클라우드 리전 전체 장애 시 복구 | Deep Clone으로 다른 리전/클라우드에 복제본을 유지합니다. RPO/RTO는 클론 주기에 의존합니다 |
💡 실무 조언: 멀티 클라우드는 비용과 복잡성이 크게 증가합니다. “정말 필요한가?”를 먼저 검증하세요. 규제 요건이 아니라면 단일 클라우드 + 멀티 리전이 대부분의 경우 더 효율적입니다.
거버넌스 부채 (Governance Debt) 관리
기존 데이터 웨어하우스(Teradata, Oracle, Netezza 등)에서 레이크하우스로 마이그레이션할 때, 거버넌스 정책 마이그레이션이 가장 큰 과제입니다.| 거버넌스 항목 | 기존 DW | 레이크하우스 (Unity Catalog) | 마이그레이션 전략 |
|---|---|---|---|
| 접근 제어 | GRANT/REVOKE (DB 레벨) | Unity Catalog GRANT (3-level namespace) | 기존 권한 매핑 스크립트 작성, INFORMATION_SCHEMA에서 기존 권한 추출 |
| 데이터 마스킹 | DB 내장 함수, View | Row Filter + Column Mask | 마스킹 정책을 SQL 함수로 재작성 |
| 감사 로그 | DB 자체 감사 | system.access.audit 테이블 | 기존 감사 보고서 쿼리를 시스템 테이블 기반으로 변환 |
| 데이터 분류 | 수동 태깅 또는 없음 | UC Tags + AI Classification | 마이그레이션 시점에 민감도 분류 일괄 적용 |
| 리니지 | 없음 또는 외부 도구 | UC 자동 리니지 | 마이그레이션 후 자동 수집 시작 |
⚠️ 실무 경험: 거버넌스 마이그레이션을 데이터 마이그레이션 이후로 미루면 “거버넌스 부채”가 눈덩이처럼 불어납니다. Day 1부터 Unity Catalog를 활성화 하고, 데이터 마이그레이션과 거버넌스 마이그레이션을 동시에 진행하는 것이 핵심입니다.
비용 모델 분석
레이크하우스의 비용 구조를 정확히 이해하면, 기존 DW 대비 40~70%의 비용 절감이 가능합니다.스토리지 계층별 비용 (AWS 기준, 2025)
| 스토리지 계층 | 월 비용/TB | 접근 빈도 | 레이크하우스 활용 |
|---|---|---|---|
| S3 Standard | ~$23/TB | 자주 접근 (Gold) | Hot 데이터, 최근 파티션 |
| S3 Intelligent-Tiering | $23~2.3/TB | 자동 분류 | 대부분의 Silver/Gold 테이블에 권장 |
| S3 Glacier Instant Retrieval | ~$4/TB | 분기 1회 | Bronze 히스토리, 규제 보존 데이터 |
| S3 Glacier Deep Archive | ~$1/TB | 연 1회 | 7년 이상 보존 의무 데이터 |
컴퓨트-스토리지 분리의 비용 이점
| 항목 | 기존 DW (컴퓨트+스토리지 결합) | 레이크하우스 (컴퓨트+스토리지 분리) |
|---|---|---|
| 프로비저닝 | 피크 시간 기준 → 70% 유휴 | 필요할 때만 시작, 사용한 만큼 과금 (DBU) |
| 스토리지 확장 | 컴퓨트도 함께 확장 (불필요한 비용) | S3/ADLS에 독립 저장 ($23/TB/월) |
| 스케일링 | - | 오토스케일링: 피크 시 확장, 비피크 시 축소 |
| 비용 | 연간 라이선스: 수억~수십억 원 | Serverless: 프로비저닝 없이 즉시 실행, 유휴 비용 0 |
Serverless의 경제성
| 워크로드 패턴 | Classic 클러스터 | Serverless | 절감률 |
|---|---|---|---|
| 배치 ETL (1일 2시간) | 24시간 프로비저닝 or 시작 대기 시간 | 실행 시간만 과금 | 50~70% |
| 애드훅 쿼리 (간헐적) | 최소 1노드 상시 대기 | 쿼리 실행 시간만 과금 | 60~80% |
| 피크 타임 대응 | 수동 스케일업 (10분+ 소요) | 즉시 확장 (초 단위) | 가용성 향상 |
💡 비용 최적화 공식: 총 비용 = (스토리지 비용) + (컴퓨트 DBU x 단가) + (네트워크 egress). 대부분의 경우 컴퓨트가 70~80%를 차지합니다. Serverless 전환, 클러스터 자동 종료 정책(idle 10분), Photon 활성화 가 가장 효과적인 비용 절감 수단입니다.
경쟁사 비교 심화
| 비교 항목 | Databricks Lakehouse | Snowflake | Microsoft Fabric | Google BigLake |
|---|---|---|---|---|
| 테이블 포맷 | Delta Lake (UniForm으로 Iceberg 호환) | Iceberg Tables (자체 포맷 + Iceberg) | Delta Lake (OneLake) | BigLake (다중 포맷) |
| 오픈소스 기반 | ✅ Apache Spark, Delta Lake, MLflow | ❌ 독점 엔진 | 부분적 (Delta Lake은 오픈) | 부분적 |
| 플랫폼 의존 | 낮음 (오픈 포맷, 포터블) | 높음 (데이터 export 필요) | 중간 (Azure 종속) | 중간 (GCP 종속) |
| ML/AI 통합 | ✅ 네이티브 (MLflow, Feature Store, Model Serving) | 제한적 (Snowpark ML) | 중간 (Azure ML 연동) | 중간 (Vertex AI 연동) |
| 실시간 스트리밍 | ✅ Structured Streaming | ❌ Snowpipe (마이크로배치만) | 중간 (Eventstream) | 중간 (Dataflow) |
| 멀티 클라우드 | ✅ AWS/Azure/GCP 모두 지원 | ✅ AWS/Azure/GCP | ❌ Azure 전용 | ❌ GCP 전용 |
| 거버넌스 | Unity Catalog (통합) | Horizon (자체) | Purview 연동 | Dataplex |
| 가격 모델 | DBU (사용량 기반) | Credit (사용량 기반) | CU (용량 기반) | Slot (용량 기반) |
| OLTP 통합 | ✅ Lakebase (PostgreSQL) | ✅ Unistore (제한적 OLTP) | ❌ 별도 Azure DB | ❌ 별도 Cloud SQL |
💡 Databricks의 핵심 차별점: (1) 오픈소스 기반 으로 플랫폼 의존이 가장 낮습니다. (2) ML/AI 워크로드가 네이티브 로 통합되어 있습니다. (3) 멀티 클라우드 지원 이 가장 성숙합니다. Snowflake는 SQL/BI에 강하고, Fabric은 Microsoft 생태계 내에서 강점을 가집니다.
현장에서 배운 것들: 레이크하우스 전환의 현실
20년간 데이터 플랫폼을 구축하면서, 데이터 레이크의 “유연성”이라는 말이 얼마나 위험한 함정인지 수없이 목격했습니다. 여기서는 교과서에 나오지 않는 현실적인 이야기를 공유하겠습니다.데이터 레이크를 운영해본 사람이라면 공감할 이야기
2016년경, 한 제조업 고객이 “빅데이터 전략”이라는 이름으로 AWS S3에 데이터 레이크를 구축했습니다. 처음 6개월은 순조로웠습니다. ERP, MES, 품질 시스템의 데이터를 모두 S3에 적재했고, “이제 데이터 민주화가 시작됐다”고 자축했습니다. 1년 뒤, 그 데이터 레이크는 Data Swamp(데이터 늪) 이 되어 있었습니다.| 증상 | 실제 상황 |
|---|---|
| 데이터를 찾을 수 없음 | S3 버킷에 50TB 데이터가 있지만, 어떤 폴더에 무슨 데이터가 있는지 아는 사람이 퇴사함 |
| 스키마를 모름 | JSON 파일의 필드명이 소스 시스템 업그레이드 후 바뀌었는데, 아무도 눈치채지 못함 |
| 품질 보장 없음 | 같은 고객 ID가 세 가지 다른 포맷으로 존재 (C001, CUST-001, 1) |
| 접근 제어 불가 | 인사 데이터(급여 정보)가 전사 읽기 권한으로 열려 있었음 |
| 쿼리 성능 처참 | 분석가가 Athena로 쿼리하면 15분 이상 걸려서 결국 Excel로 돌아감 |
⚠️ Data Swamp의 핵심 원인: “일단 넣고 나중에 정리하자”라는 마인드셋입니다. 데이터 레이크에 거버넌스 없이 데이터를 쏟아붓는 순간, 그 데이터는 자산이 아니라 부채가 됩니다. 현업에서 이런 프로젝트를 10건 이상 봤습니다.
레이크하우스가 실제로 해결한 문제들
위 고객이 2020년에 Databricks 레이크하우스로 전환했을 때, 단순히 기술을 바꾼 것이 아니라 데이터 운영 문화 자체가 바뀌었습니다.| Data Swamp 시절 | 레이크하우스 전환 후 | 핵심 변화 |
|---|---|---|
| S3에 파일을 던져놓고 “알아서 쓰세요” | Unity Catalog에 등록된 테이블만 공식 데이터로 인정 | 데이터 카탈로그가 Single Source of Truth |
| 스키마가 없거나 문서만 존재 | Delta Lake의 스키마 강제 + 스키마 진화 | ”데이터 계약(Data Contract)” 문화 정착 |
| 누가 어떤 데이터를 읽었는지 모름 | 시스템 테이블(audit log)로 전수 추적 | 감사 가능한 데이터 접근 |
| 분석가가 쿼리하면 15분 | Photon + Liquid Clustering으로 2~5초 | 분석가가 드디어 SQL을 다시 쓰기 시작 |
| ML 팀이 별도 데이터 복사본으로 학습 | 같은 Delta 테이블에서 SQL과 ML 동시 수행 | ”하나의 데이터” 원칙 실현 |
기존 DW팀이 레이크하우스 전환 시 겪는 5가지 문화적 충격
Teradata, Oracle Exadata, Netezza 같은 전통적 DW에서 레이크하우스로 전환하는 팀들을 20개 이상 지원하면서 발견한 공통 패턴입니다. 기술보다 문화적 충격 이 더 큰 장벽이었습니다.충격 1: “테이블이 파일이라고요?”
충격 2: “인덱스가 없다니?”
전통 DW에서는 B-Tree 인덱스, Bitmap 인덱스, Materialized View로 성능을 튜닝합니다. 레이크하우스에는 전통적 인덱스가 없습니다. 대신 Data Skipping(min/max 통계), Liquid Clustering, Z-Order 가 그 역할을 합니다. 처음에는 “인덱스 없이 어떻게 성능이 나오지?”라고 의심하지만, 실제로 10TB 테이블에서 Liquid Clustering만으로 서브초 쿼리가 가능하다는 걸 보면 놀랍니다.충격 3: “스토리지와 컴퓨트가 분리되어 있으면 느리지 않나요?”
Teradata의 MPP(Massively Parallel Processing) 아키텍처에서는 데이터가 컴퓨트 노드의 로컬 디스크에 있어서 네트워크 오버헤드가 없었습니다. S3에서 데이터를 읽는 레이크하우스가 더 느릴 것 같지만, 실제로는:- Photon 엔진의 벡터화 처리 + 캐싱으로 상쇄
- 컬럼 프루닝 + 파일 스킵으로 실제 읽는 데이터가 1~5%에 불과
- 스토리지 비용이 1/10~1/50이므로 같은 예산으로 10배 더 많은 컴퓨트 사용 가능
💡 현업 경험: Teradata에서 3분 걸리던 쿼리가 Databricks SQL + Photon에서 8초로 줄어든 사례를 여러 번 봤습니다. 물론 반대 경우도 있습니다 — 잘 튜닝된 DW의 단순 조인은 DW가 더 빠를 수 있습니다. 핵심은 전체 TCO(총 소유 비용)와 유연성 입니다.
충격 4: “ETL을 SQL로만 할 수 있었는데, 이제 Python도 써야 하나요?”
좋은 소식이 있습니다. Databricks SQL만으로도 90% 이상의 ETL이 가능합니다. SDP(선언적 파이프라인)는 순수 SQL로 작성할 수 있습니다. Python은 ML이나 복잡한 비정형 처리에서만 필요합니다.충격 5: “운영 DBA의 역할이 사라지나요?”
사라지는 것이 아니라 진화 합니다. VACUUM 스케줄링, 클러스터 사이징, 비용 최적화, Unity Catalog 거버넌스 설계 등 레이크하우스에도 전문 운영자가 필요합니다. 기존 DBA의 스킬(쿼리 튜닝, 데이터 모델링, 백업/복구 전략)은 레이크하우스에서도 그대로 가치 있습니다.레이크하우스 전환 ROI: 실제 숫자
“레이크하우스로 전환하면 얼마나 절감되나요?”는 경영진이 가장 먼저 묻는 질문입니다. 제가 참여한 5개 프로젝트의 익명화된 평균 데이터입니다.| 비용 항목 | 전통 DW (연간) | 레이크하우스 (연간) | 절감 |
|---|---|---|---|
| 소프트웨어 라이선스 | 2M | $0 (오픈소스 기반) | 100% |
| 스토리지 | $200K (DW 독점 스토리지) | $30K (S3/ADLS) | 85% |
| 컴퓨트 | $500K (상시 프로비저닝) | $300K (온디맨드 + Serverless) | 40% |
| ETL 도구 라이선스 | $150K | $0 (SDP/Spark 내장) | 100% |
| 관리 인력 | DBA 3명 ($450K) | Platform Engineer 2명 ($350K) | 22% |
| 합계 | 3.3M | $680K | 67~79% 절감 |
⚠️ 주의: 이 수치는 “잘 전환한 경우”입니다. 전환 자체에 6~12개월의 시간과 인력 투자가 필요하며, 마이그레이션 기간에는 두 시스템을 병행 운영해야 하므로 비용이 일시적으로 증가합니다. ROI는 보통 전환 완료 후 12~18개월 뒤에 나타납니다.
실전 레이크하우스 도입 체크리스트
15개 이상의 레이크하우스 구축 프로젝트 경험에서 추린, “Day 1부터 반드시 해야 하는 것”과 “절대 하지 말아야 하는 것”입니다.| 구분 | 항목 | 이유 |
|---|---|---|
| 반드시 | Unity Catalog를 Day 1에 활성화 | 나중에 켜면 기존 테이블 마이그레이션이 고통 |
| 반드시 | Medallion 아키텍처(Bronze/Silver/Gold) 표준 수립 | 팀마다 다른 레이어 구조를 쓰면 6개월 뒤 카오스 |
| 반드시 | 클러스터 자동 종료 정책 설정 (10~30분) | 이것 안 하면 첫 달 청구서에서 심장이 멈춤 |
| 반드시 | 데이터 품질 기대치(Expectations) 정의 | 쓰레기 데이터가 Gold까지 흘러가면 신뢰 상실 |
| 절대 금지 | 모든 테이블을 External Table로 생성 | UC의 거버넌스 이점을 포기하는 것과 같음 |
| 절대 금지 | 파티셔닝 키를 “일단 날짜로” | 쿼리 패턴 분석 없이 파티셔닝하면 성능이 더 나빠질 수 있음 |
| 절대 금지 | 개인 노트북에서 프로덕션 테이블 직접 수정 | Job으로만 프로덕션 데이터를 변경하는 원칙 수립 |
정리
| 핵심 개념 | 설명 |
|---|---|
| 레이크하우스 | 데이터 레이크의 유연성 + 웨어하우스의 안정성을 결합한 아키텍처입니다 |
| Delta Lake | 레이크하우스를 가능하게 하는 핵심 기술. 오픈 파일 포맷 위에 트랜잭션을 추가합니다 |
| Photon | Databricks의 고성능 쿼리 엔진으로, 웨어하우스 수준의 SQL 성능을 제공합니다 |
| 오픈 포맷 | Parquet 등 독점 포맷이 아닌 오픈 포맷을 사용하여 플랫폼 의존을 방지합니다 |
| 단일 플랫폼 | 하나의 데이터로 BI, ML, 스트리밍 등 모든 워크로드를 지원합니다 |