데이터 웨어하우스 vs 데이터 레이크

​

왜 이 개념을 알아야 하나요?

​

데이터 웨어하우스 (Data Warehouse) — 30년간 살아남은 이유

​

개념

💡 데이터 웨어하우스(Data Warehouse) 란 비즈니스 의사결정을 위해 다양한 소스의 데이터를 구조화된 형태 로 통합·저장하는 중앙 저장소입니다.

​

왜 30년간 살아남았는가

• SQL만 알면 누구나 분석할 수 있습니다
• 데이터가 깨끗하고 일관됩니다 (Schema-on-Write 덕분)
• 성능이 빠릅니다 (분석에 최적화된 구조)
• 권한 관리가 체계적입니다 (누가 무엇을 볼 수 있는지 명확)

​

핵심 특징

💡 Schema-on-Write란? 데이터를 저장소에 쓰는(Write) 시점에 스키마를 강제하는 방식입니다. 엑셀 시트의 열 제목을 먼저 정하고, 그 규칙에 맞는 데이터만 입력하는 것과 같습니다. 장점은 데이터 품질이 보장된다는 것이고, 단점은 유연성이 떨어진다는 것입니다.

💡 컬럼 기반 저장(Columnar Storage)이란? 일반적인 RDBMS는 행(Row) 단위로 디스크에 데이터를 저장합니다. 하지만 분석용 DW는 열(Column) 단위로 저장합니다. “전체 고객의 매출 합계”를 구할 때, 행 기반이면 모든 컬럼을 읽어야 하지만, 컬럼 기반이면 amount 컬럼만 읽으면 됩니다. 100개 컬럼 중 1개만 읽으니 100배 빠른 것입니다. Databricks의 Delta Lake도 내부적으로 Parquet(컬럼 기반 포맷)을 사용합니다.

​

DW의 한계 — 왜 이것만으로는 안 되는가

⚠️ 실무에서 가장 큰 고통: “DW 저장 비용이 너무 비싸서, 3년 이상 된 데이터를 삭제해야 하는데, 규정상 5년 보관이 필수”라는 딜레마. 많은 기업이 이 비용 문제 하나 때문에 클라우드 전환을 결심했습니다.

​

대표적인 제품

​

데이터 레이크 (Data Lake) — 거대한 약속과 쓰라린 현실

​

개념

💡 데이터 레이크(Data Lake) 란 정형·반정형·비정형 데이터를 원본 형태 그대로 저장할 수 있는 대규모 저장소입니다.

​

데이터 레이크의 약속

• 어떤 데이터든 저장 가능— 정형, JSON, 로그, 이미지, 동영상
• 저렴한 비용— S3에 저장하면 TB당 월 23달러. DW의 1/100
• 유연한 스키마— 먼저 넣고 나중에 구조를 정하면 됨 (Schema-on-Read)
• ML/AI에 적합— Python, Spark로 자유롭게 데이터 처리

💡 Schema-on-Read란? Schema-on-Write와 반대로, 데이터를 읽을 때 비로소 구조를 정하는 방식입니다. 원본 데이터를 그대로 저장해 두고, 분석할 때 “이 파일의 3번째 필드가 이름이고, 5번째 필드가 금액이야”라고 해석합니다. 유연하지만, 읽을 때마다 해석이 필요하고, 데이터 품질을 보장하기 어렵습니다.

💡 오브젝트 스토리지(Object Storage)란? AWS S3, Azure Blob Storage(ADLS), Google Cloud Storage 같은 클라우드 저장소입니다. 파일을 키(Key) 구조로 저장하며, 거의 무제한에 가까운 용량을 저렴하게 사용할 수 있습니다. 전통적인 파일 시스템과 달리 HTTP API로 접근합니다.

​

”Data Swamp” — 데이터 레이크의 쓰라린 현실

1년차: "와, S3에 뭐든 넣을 수 있어! 일단 다 넣자!"
    → 10개 팀이 각자의 데이터를 각자의 버킷에 적재

2년차: "이 파일이 최신인가? 저 팀이 올린 CSV의 스키마가 뭐지?"
    → 문서화 없음. 담당자 퇴사. 메타데이터 없음.

3년차: "이 데이터 써도 되나요? 개인정보가 포함되어 있는 건 아닌가요?"
    → 거버넌스 없음. 접근 제어 없음. 감사 불가.
    → 아무도 믿지 못하는 데이터 → 결국 다시 DW에서 쿼리

4년차: "데이터 레이크에 2PB가 쌓여있는데, 활용률은 10% 미만입니다"
    → 경영진: "이게 무슨 의미가 있나?"

⚠️ 이것은 과장이 아닙니다. Gartner의 2020년 보고서에 따르면, 데이터 레이크 프로젝트의 85%가 실패 했습니다. 실패의 핵심 원인은 기술이 아니라 거버넌스(데이터 관리 체계)의 부재 였습니다.

​

데이터 레이크가 실패하는 구체적인 이유

​

대표적인 기술

• 1세대: Hadoop HDFS + MapReduce (2006~2015)
• 2세대: AWS S3 / Azure ADLS + Apache Spark (2015~현재)
• 3세대: S3/ADLS + Delta Lake + Unity Catalog = Lakehouse(2020~현재)

​

한눈에 비교

​

”우리 회사는 아직 DW를 쓰고 있는데, 전환해야 하나요?”

​

전환이 필요한 신호

1. DW 라이선스/하드웨어 비용이 연간 수억 원을 초과 하고 계속 증가하고 있다
2. 비정형 데이터(로그, JSON, 이미지)가 급증하는데 DW에 넣을 수 없다
3. ML/AI 프로젝트 를 시작하려는데, DW에서 데이터를 빼서 별도 환경으로 복사해야 한다
4. 스키마 변경 에 2주 이상 걸려서 비즈니스 변화에 대응이 느리다
5. DW의 3년 이상 데이터를 삭제 해야 하는 비용 압박을 받고 있다
6. 실시간 데이터 처리 가 필요한데 DW로는 한계가 있다

​

전환이 아직 불필요한 경우

• 데이터 규모가 수 TB 이하이고, 정형 데이터만 분석한다
• 현재 DW 비용이 적정 수준이고, ML/AI 요구사항이 없다
• 조직 내 Spark/Python 역량이 전무하고, SQL만 사용한다
• 규정/보안 요건으로 클라우드 전환 자체가 제한된다

💡 핵심 조언: “무조건 레이크하우스로 가야 한다”는 것이 아닙니다. DW가 현재 니즈를 충족하고, 비용이 관리 가능하며, 향후 3년간 ML/AI 니즈가 없다면 — 지금 당장 전환할 이유가 없습니다. 하지만 대부분의 기업은 위 체크리스트의 3개 이상에 해당합니다. 그리고 전환은 빨리 시작할수록 비용이 적게 듭니다. 데이터가 10TB일 때 전환하는 것과 100TB일 때 전환하는 것은 복잡도가 10배가 아니라 100배 차이입니다.

​

전환 시 가장 흔한 실수

1. “DW를 끄고 레이크하우스를 켜자” (빅뱅 전환)— 절대 하지 마세요. 6개월~1년 이중 운영을 각오해야 합니다
2. ”** 데이터 레이크를 먼저 만들고, 나중에 거버넌스를 추가하자**” — Data Swamp의 지름길입니다. Unity Catalog부터 설정하세요
3. ”** 기존 ETL 로직을 그대로 Spark로 포팅하자**” — ETL 패턴을 ELT로 전환해야 합니다. 1:1 변환은 의미가 없습니다

​

그래서, 레이크하우스란?

데이터 레이크 (저렴, 유연, 하지만 거버넌스 없음)
    +
데이터 웨어하우스 (빠른 SQL, 거버넌스, 하지만 비싸고 제한적)
    =
레이크하우스 (저렴 + 유연 + 빠른 SQL + 거버넌스 + ML/AI)

​

현업 사례: Data Lake를 도입했는데 3년 만에 Data Swamp가 된 팀

​

사례: 대형 유통사의 Data Lake 프로젝트

[1년차 — 희망의 시작]
- S3 버킷 3개 생성 (raw, processed, analytics)
- EMR Spark로 ETL 파이프라인 구축
- "모든 데이터를 한 곳에 모으자!"
- 10개 팀이 각자 데이터를 적재 시작

[2년차 — 혼돈의 시작]
- S3에 500TB 적재, 그런데...
  - raw/ 아래 같은 데이터가 JSON, CSV, Parquet 3가지 형식으로 존재
  - 팀 A가 올린 customer.csv와 팀 B가 올린 customers.json이 스키마가 다름
  - 담당자 퇴사 후 "이 데이터가 뭔지" 아는 사람이 없음
  - 개인정보(주민번호)가 포함된 파일이 raw/에 방치 — 감사 시 발견

[3년차 — Data Swamp 확정]
- 1.2PB 적재, 활용률 8%
- "이 데이터를 분석에 쓸 수 있나요?" → "모르겠습니다"
- 결국 분석팀은 기존 Oracle DW에서 계속 쿼리
- 경영진: "데이터 레이크에 쓴 비용이 연간 3억인데, ROI가 뭐죠?"

​

Data Swamp의 핵심 원인 5가지

⚠️ 현업에서는 이렇게 합니다: Data Lake를 시작하기 전에 반드시 거버넌스 프레임워크를 먼저 수립 합니다. Databricks로 전환한다면 Unity Catalog를 첫 번째로 설정하세요. “데이터를 넣고 나중에 정리하자”는 접근은 100% 실패합니다. 이것을 안 하면 3년 후 1PB의 쓰레기 더미를 갖게 됩니다.

​

현업 가이드: DW에서 Lakehouse로의 데이터 마이그레이션 실전 전략

​

마이그레이션의 현실적 타임라인

[Phase 0: 준비] — 1~2개월
- 현재 DW의 테이블 목록, 사용 빈도, 의존성 분석
- 팀별 핵심 쿼리/리포트 식별 (보통 전체의 20%가 80% 트래픽 차지)
- Unity Catalog 설계 (카탈로그/스키마 구조)
- PoC 대상 선정 (영향도 낮은 리포트 3~5개)

[Phase 1: PoC] — 2~3개월
- 선정된 리포트를 Databricks SQL로 재구현
- 데이터 정합성 검증 (DW와 Lakehouse 결과 비교)
- 성능 벤치마크 (응답 시간, 처리량)
- 비용 비교 (DW 유지 비용 vs Lakehouse 비용)

[Phase 2: 점진적 전환] — 6~12개월
- 배치 파이프라인부터 전환 (일별 리포트 → Lakeflow Jobs)
- DW와 이중 운영 (parallel run) — 최소 4주간 결과 비교
- BI 도구 연결 변경 (JDBC 엔드포인트를 DW → DBSQL로)
- DW 테이블 단위로 폐기 (사용하는 쿼리가 0개 된 테이블부터)

[Phase 3: 완전 전환] — 3~6개월
- 나머지 파이프라인 전환
- DW 라이선스 축소/해지
- 모니터링/알림 체계 안정화
- 운영 매뉴얼/교육 완료

​

마이그레이션에서 가장 많이 실패하는 3가지

​

전환 비용의 현실적 규모

💡 비용 절감 팁: 전환 비용의 50% 이상은 “이중 운영”과 “정합성 검증”에서 발생합니다. 이 기간을 줄이려면 (1) 영향도가 낮은 테이블부터 시작하고, (2) 자동화된 정합성 비교 도구를 초기에 구축하고, (3) DW 테이블 사용 빈도를 분석하여 안 쓰는 테이블은 전환 대상에서 제외하세요. 대부분의 기업에서 전체 테이블의 20~30%는 아무도 사용하지 않는 “좀비 테이블”입니다.

​

DW를 유지하면서 Lakehouse를 병행하는 전략

[하이브리드 아키텍처]
기존 DW (Oracle/Teradata)
- 기존 리포트/대시보드 계속 서비스 (변경 없음)
- 핵심 비즈니스 KPI 쿼리 유지

Databricks Lakehouse (신규)
- 신규 데이터 소스 (로그, IoT, 비정형) 적재
- ML/AI 워크로드 전담
- 신규 분석 요구사항 처리
- 점진적으로 DW 테이블을 Lakehouse로 이관

[전환 완료 기준]
- DW의 일일 쿼리 수가 0에 도달한 테이블부터 DW에서 삭제
- 최종적으로 DW 라이선스를 축소 또는 해지

⚠️ 현업에서는 이렇게 합니다: “DW를 없앨 거야”라고 선언하면 기존 DW 팀의 저항이 시작됩니다. “Lakehouse는 DW를 대체하는 것이 아니라 보완하는 것”이라고 포지셔닝하고, 신규 요구사항을 Lakehouse에서 처리하면서 자연스럽게 DW 사용량을 줄이는 것이 현실적입니다. 1~2년 후 DW 쿼리가 거의 없어지면, 그때 DW 해지를 논의합니다.

​

데이터 이관 시 꼭 확인할 체크리스트

☐ DW 테이블의 row count가 Delta 테이블과 일치하는가?
☐ 핵심 집계 값(SUM, AVG, COUNT DISTINCT)이 DW와 일치하는가?
☐ NULL 처리 로직이 동일한가? (Oracle의 NVL과 Spark의 COALESCE 차이 등)
☐ 날짜/시간 타입의 시간대(timezone) 처리가 동일한가?
☐ 문자열 정렬(collation) 결과가 동일한가? (한국어 정렬 차이 주의)
☐ 소수점 연산 결과가 일치하는가? (DECIMAL vs FLOAT 차이)

💡 현업 팁: 마이그레이션 비용의 70%는 “데이터 정합성 검증”에 들어갑니다. 이 단계를 줄이려고 하면 나중에 10배의 비용으로 돌아옵니다. Oracle과 Spark는 NULL 처리, 문자열 비교, 소수점 연산에서 미묘한 차이가 있으므로, 반드시 샘플이 아닌 전수 검증 을 하세요.

​

정리

​

참고 링크

• Databricks: What is a Data Lakehouse?
• Azure Databricks: What is a data lakehouse?
• Databricks Blog: What is a Lakehouse?
• CIDR 2021: Lakehouse Paper
• Databricks: Delta Lake
• Databricks: Unity Catalog