> ## Documentation Index > Fetch the complete documentation index at: https://docs.sifi.life/llms.txt > Use this file to discover all available pages before exploring further. # 레이크하우스 한계와 전환 현실 > 레이크하우스의 한계, 트레이드오프, 실전 전환 전략과 현장에서 배운 교훈 > 이 문서는 **[레이크하우스란?](/training/03-lakehouse-architecture/what-is-lakehouse)** 의 하위 문서입니다. ## 심화: 레이크하우스의 한계와 실전 트레이드오프 레이크하우스가 만능은 아닙니다. 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 동시 수행 | **"하나의 데이터" 원칙 실현** | 전환 결과: **연간 스토리지 비용 40% 절감, ETL 파이프라인 수 60% 감소, 분석 리포트 생성 시간 1일 → 2시간.** ### 기존 DW팀이 레이크하우스 전환 시 겪는 5가지 문화적 충격 Teradata, Oracle Exadata, Netezza 같은 전통적 DW에서 레이크하우스로 전환하는 팀들을 20개 이상 지원하면서 발견한 공통 패턴입니다. 기술보다 **문화적 충격** 이 더 큰 장벽이었습니다. #### 충격 1: "테이블이 파일이라고요?" ``` 전통 DW 사고방식: 테이블 = DB가 관리하는 추상적 개체 레이크하우스 현실: 테이블 = S3/ADLS의 Parquet 파일 + Delta Log ``` DW 출신 DBA들은 "테이블 데이터가 그냥 파일로 존재한다"는 개념에 불안해합니다. "누가 실수로 파일을 지우면 어떡하죠?" 이 불안감은 정당합니다. 그래서 **Unity Catalog의 Managed Table** 을 기본으로 사용하고, 스토리지 접근을 UC를 통해서만 허용하는 것이 핵심입니다. #### 충격 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 (연간) | 레이크하우스 (연간) | 절감 | | --------------- | ------------------- | ----------------------------- | -------------- | | **소프트웨어 라이선스** | $800K~$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% | | **합계** | $2.1M~$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, 스트리밍 등 모든 워크로드를 지원합니다 | 다음 문서에서는 레이크하우스의 핵심 기술인 **Delta Lake** 를 자세히 살펴보겠습니다. *** ## 참고 링크 * [Databricks: What is a Data Lakehouse?](https://docs.databricks.com/aws/en/lakehouse/) * [Azure Databricks: What is a data lakehouse?](https://learn.microsoft.com/en-us/azure/databricks/lakehouse/) * [Databricks Blog: What is a Lakehouse?](https://www.databricks.com/blog/2020/01/30/what-is-a-data-lakehouse.html) * [Delta Lake Official Site](https://delta.io/)