이 문서는 레이크하우스란? 의 하위 문서입니다.
심화: 레이크하우스의 한계와 실전 트레이드오프
레이크하우스가 만능은 아닙니다. Principal SA로서 고객에게 정직하게 전달해야 할 한계와 트레이드오프를 살펴보겠습니다.레이크하우스의 한계
멀티 클라우드 레이크하우스 전략
엔터프라이즈 고객의 80% 이상이 2개 이상의 클라우드를 사용합니다. 멀티 클라우드 환경에서의 레이크하우스 전략은 다음과 같습니다.💡 실무 조언: 멀티 클라우드는 비용과 복잡성이 크게 증가합니다. “정말 필요한가?”를 먼저 검증하세요. 규제 요건이 아니라면 단일 클라우드 + 멀티 리전이 대부분의 경우 더 효율적입니다.
거버넌스 부채 (Governance Debt) 관리
기존 데이터 웨어하우스(Teradata, Oracle, Netezza 등)에서 레이크하우스로 마이그레이션할 때, 거버넌스 정책 마이그레이션이 가장 큰 과제입니다.⚠️ 실무 경험: 거버넌스 마이그레이션을 데이터 마이그레이션 이후로 미루면 “거버넌스 부채”가 눈덩이처럼 불어납니다. Day 1부터 Unity Catalog를 활성화 하고, 데이터 마이그레이션과 거버넌스 마이그레이션을 동시에 진행하는 것이 핵심입니다.
비용 모델 분석
레이크하우스의 비용 구조를 정확히 이해하면, 기존 DW 대비 40~70%의 비용 절감이 가능합니다.스토리지 계층별 비용 (AWS 기준, 2025)
컴퓨트-스토리지 분리의 비용 이점
Serverless의 경제성
💡 비용 최적화 공식: 총 비용 = (스토리지 비용) + (컴퓨트 DBU x 단가) + (네트워크 egress). 대부분의 경우 컴퓨트가 70~80%를 차지합니다. Serverless 전환, 클러스터 자동 종료 정책(idle 10분), Photon 활성화 가 가장 효과적인 비용 절감 수단입니다.
경쟁사 비교 심화
💡 Databricks의 핵심 차별점: (1) 오픈소스 기반 으로 플랫폼 의존이 가장 낮습니다. (2) ML/AI 워크로드가 네이티브 로 통합되어 있습니다. (3) 멀티 클라우드 지원 이 가장 성숙합니다. Snowflake는 SQL/BI에 강하고, Fabric은 Microsoft 생태계 내에서 강점을 가집니다.
현장에서 배운 것들: 레이크하우스 전환의 현실
20년간 데이터 플랫폼을 구축하면서, 데이터 레이크의 “유연성”이라는 말이 얼마나 위험한 함정인지 수없이 목격했습니다. 여기서는 교과서에 나오지 않는 현실적인 이야기를 공유하겠습니다.데이터 레이크를 운영해본 사람이라면 공감할 이야기
2016년경, 한 제조업 고객이 “빅데이터 전략”이라는 이름으로 AWS S3에 데이터 레이크를 구축했습니다. 처음 6개월은 순조로웠습니다. ERP, MES, 품질 시스템의 데이터를 모두 S3에 적재했고, “이제 데이터 민주화가 시작됐다”고 자축했습니다. 1년 뒤, 그 데이터 레이크는 Data Swamp(데이터 늪) 이 되어 있었습니다.⚠️ Data Swamp의 핵심 원인: “일단 넣고 나중에 정리하자”라는 마인드셋입니다. 데이터 레이크에 거버넌스 없이 데이터를 쏟아붓는 순간, 그 데이터는 자산이 아니라 부채가 됩니다. 현업에서 이런 프로젝트를 10건 이상 봤습니다.
레이크하우스가 실제로 해결한 문제들
위 고객이 2020년에 Databricks 레이크하우스로 전환했을 때, 단순히 기술을 바꾼 것이 아니라 데이터 운영 문화 자체가 바뀌었습니다.
전환 결과: 연간 스토리지 비용 40% 절감, ETL 파이프라인 수 60% 감소, 분석 리포트 생성 시간 1일 → 2시간.
기존 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개 프로젝트의 익명화된 평균 데이터입니다.⚠️ 주의: 이 수치는 “잘 전환한 경우”입니다. 전환 자체에 6~12개월의 시간과 인력 투자가 필요하며, 마이그레이션 기간에는 두 시스템을 병행 운영해야 하므로 비용이 일시적으로 증가합니다. ROI는 보통 전환 완료 후 12~18개월 뒤에 나타납니다.
실전 레이크하우스 도입 체크리스트
15개 이상의 레이크하우스 구축 프로젝트 경험에서 추린, “Day 1부터 반드시 해야 하는 것”과 “절대 하지 말아야 하는 것”입니다.정리
다음 문서에서는 레이크하우스의 핵심 기술인 Delta Lake 를 자세히 살펴보겠습니다.