> ## 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.

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

> 이 문서는 **[데이터 기초](/training/01-data-fundamentals/overview)** 섹션의 일부입니다.

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

데이터를 수집했다면, 어딘가에 저장해야 합니다. 그런데 데이터를 저장하는 방식은 30년 동안 계속 진화해 왔고, 그 과정에서 수많은 기업이 비싼 수업료를 냈습니다. 데이터 웨어하우스의 비용 문제, 데이터 레이크의 거버넌스 문제 — 양쪽의 실패를 모두 경험한 끝에 나온 것이 **레이크하우스(Lakehouse)** 입니다.

이 역사를 모르고 레이크하우스를 배우면, "왜 굳이 이렇게 하는 거지?"라는 의문이 풀리지 않습니다. 각 접근법이 **어떤 문제를 해결하려 했고, 어디서 실패했는지** 이해하면, Databricks의 아키텍처가 자연스럽게 이해됩니다.

***

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

### 개념

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

### 왜 30년간 살아남았는가

1990년대에 Bill Inmon이 데이터 웨어하우스 개념을 정립하고, Ralph Kimball이 차원 모델링 방법론을 체계화한 이후, DW는 기업 분석의 중심이었습니다. **Teradata, Oracle, Netezza, IBM DB2**— 이 이름들은 한 시대를 지배했습니다.

DW가 30년간 살아남은 핵심 이유는 **"비즈니스 사용자가 바로 쓸 수 있다"** 는 것입니다:

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

대기업 임원이 "이번 분기 매출이 얼마야?"라고 물었을 때, 3초 안에 답이 나오는 시스템 — 그것이 데이터 웨어하우스입니다.

### 핵심 특징

| 특징                  | 설명                                   | 실무적 의미                                     |
| ------------------- | ------------------------------------ | ------------------------------------------ |
| **Schema-on-Write** | 데이터를 저장하기 **전에** 스키마를 먼저 정의해야 합니다    | 새로운 데이터 소스 추가 시 스키마 설계 → 리뷰 → 반영에 2\~4주 소요 |
| **정형 데이터 중심**       | 행(Row)과 열(Column)이 명확한 테이블 형태만 저장합니다 | 로그, JSON, 이미지 등은 저장 불가                     |
| **SQL 기반 분석**       | SQL 쿼리를 통해 빠르게 조회 가능합니다              | BI 분석가가 즉시 활용 가능                           |
| **컬럼 기반 저장**        | 분석에 최적화된 구조로 빠른 응답 속도를 제공합니다         | 수억 건의 SUM/AVG가 초 단위로 완료                    |

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

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

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

2010년대에 들어서면서 DW의 한계가 뚜렷해졌습니다:

| 한계              | 구체적 상황                                        | 비용 영향                      |
| --------------- | --------------------------------------------- | -------------------------- |
| **스토리지 비용**     | Teradata 1TB 저장에 연간 수천만 원                     | 데이터가 늘수록 비용이 선형 증가         |
| **비정형 데이터 불가**  | 고객 리뷰(텍스트), 클릭 스트림(JSON), 이미지를 저장 불가          | 별도 시스템 필요 → 사일로 발생         |
| **스키마 변경의 고통**  | 새 컬럼 추가에 DBA 승인 → 스키마 변경 → 테스트 → 배포. 2\~4주 소요 | 빠른 비즈니스 변화에 대응 불가          |
| **컴퓨트-스토리지 결합** | 더 빠른 쿼리를 원하면 더 비싼 하드웨어를 구매해야 함                | 스토리지만 늘리고 싶어도 전체 장비를 업그레이드 |
| **ML/AI 워크로드**  | Python, R, TensorFlow 등을 DW에서 실행하기 어려움        | 데이터를 복사해서 별도 ML 환경으로 이동    |

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

### 대표적인 제품

| 세대                    | 제품                                   | 특징                      |
| --------------------- | ------------------------------------ | ----------------------- |
| **1세대 (1990\~2000s)** | Teradata, Oracle DW, IBM DB2         | 전용 하드웨어, 엄청난 라이선스 비용    |
| **2세대 (2010s)**       | Amazon Redshift, Snowflake, BigQuery | 클라우드 기반, 컴퓨트-스토리지 분리 시작 |
| **3세대 (2020s\~)**     | Databricks SQL, Databricks Lakehouse | 레이크하우스 기반, DW 기능 통합     |

***

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

### 개념

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

### 데이터 레이크의 약속

2010년대 초반, Hadoop 생태계와 함께 데이터 레이크 개념이 떠올랐습니다. 그 약속은 매력적이었습니다:

* **어떤 데이터든 저장 가능**— 정형, 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" — 데이터 레이크의 쓰라린 현실

데이터 레이크의 약속은 아름다웠지만, 현실은 달랐습니다. **제대로 관리하지 않은 데이터 레이크는 "데이터 늪(Data Swamp)"이 됩니다.** 이것은 비유가 아니라, 실제로 수많은 기업이 겪은 일입니다.

**실제로 벌어지는 일:**

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

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

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

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

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

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

| 문제         | DW에서는                       | 데이터 레이크에서는                          |
| ---------- | --------------------------- | ----------------------------------- |
| **데이터 품질** | 스키마가 강제하므로 잘못된 데이터가 들어오지 않음 | 아무 데이터나 들어옴. CSV 구분자가 다른 파일이 섞여도 모름 |
| **트랜잭션**   | ACID 보장. 실패 시 자동 롤백         | 파일 쓰기 중 실패하면 깨진 파일이 남음              |
| **스키마 변경** | DDL로 관리, 이력 추적 가능           | 소스 시스템이 컬럼을 추가하면, 아무 예고 없이 파일 형식 변경 |
| **접근 제어**  | 테이블/컬럼 단위 권한 관리             | S3 버킷 단위 관리. 파일 안의 특정 컬럼만 제한하기 어려움  |
| **데이터 발견** | 카탈로그로 테이블 검색 가능             | "이 파일이 뭔지" 알려면 파일을 직접 열어봐야 함        |

### 대표적인 기술

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

***

## 한눈에 비교

| 비교 항목        | 데이터 웨어하우스                     | 데이터 레이크                  |
| ------------ | ----------------------------- | ------------------------ |
| **데이터 유형**   | 정형 데이터만                       | 정형 + 반정형 + 비정형           |
| **스키마**      | Schema-on-Write (쓸 때 정의)      | Schema-on-Read (읽을 때 정의) |
| **데이터 품질**   | 높음 (스키마가 강제)                  | 관리에 따라 천차만별              |
| **쿼리 성능**    | 매우 빠름 (최적화됨)                  | 상대적으로 느림 (최적화 미비)        |
| **주요 사용자**   | BI 분석가, 비즈니스 사용자              | 데이터 과학자, 데이터 엔지니어        |
| **저장 비용**    | 높음 (TB당 연 수백\~수천만 원)          | 매우 낮음 (TB당 월 23달러)       |
| **거버넌스**     | 체계적                           | 추가 도구 없이는 부실             |
| **ML/AI 지원** | 제한적                           | 우수                       |
| **확장성**      | 비용에 비례                        | 거의 무한                    |
| **대표 제품**    | Redshift, Snowflake, BigQuery | S3 + Spark, ADLS, HDFS   |

***

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

이 질문을 정말 많이 받습니다. 솔직한 답변을 드리겠습니다.

### 전환이 필요한 신호

다음 중 **3개 이상 해당** 하면 레이크하우스 전환을 심각하게 고려해야 합니다:

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 변환은 의미가 없습니다

***

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

양쪽의 한계를 모두 겪은 끝에 나온 것이 **레이크하우스(Lakehouse)** 아키텍처입니다.

| 레이크하우스의 해결        | 데이터 레이크의 문제 →               | 데이터 웨어하우스의 문제 →                   |
| ----------------- | --------------------------- | --------------------------------- |
| **Delta Lake**    | 트랜잭션 없음 → ACID 트랜잭션 지원      | 비정형 데이터 불가 → 모든 형식 저장 가능          |
| **Unity Catalog** | 거버넌스 부재 → 테이블/컬럼 수준 권한, 리니지 | 비용 폭발 → 저렴한 오브젝트 스토리지 사용          |
| **Photon Engine** | SQL 성능 열악 → DW급 쿼리 성능       | ML/AI 불가 → Spark, Python, R 모두 지원 |
| **Serverless**    | —                           | 컴퓨트-스토리지 결합 → 완전 분리, 필요 시만 비용     |

쉽게 말해, **데이터 레이크의 저렴함과 유연성**+ **데이터 웨어하우스의 성능과 거버넌스**= **레이크하우스** 입니다.

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

Databricks의 레이크하우스 아키텍처는 **Delta Lake** 라는 오픈소스 기술을 기반으로 이 통합을 실현합니다. 다음 섹션인 [03. 레이크하우스 아키텍처](../03-lakehouse-architecture/README)에서 이 내용을 자세히 다루겠습니다.

***

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

현업에서는 이런 일이 정말 자주 벌어집니다. 실제 패턴을 구체적으로 공유합니다.

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

어느 대형 유통사가 2019년에 "빅데이터 플랫폼"이라는 이름으로 AWS S3 기반 데이터 레이크를 구축했습니다. 초기 계획은 야심찼습니다.

```
[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가지

현업에서 20년간 수많은 Data Lake 프로젝트를 지켜본 결과, **실패 원인은 기술이 아니라 거버넌스** 입니다.

| # | 원인               | 구체적 증상                        | 예방법                       |
| - | ---------------- | ----------------------------- | ------------------------- |
| 1 | **메타데이터 관리 부재**  | "이 파일이 뭔지 모르겠다"               | Unity Catalog 도입 후 데이터 적재 |
| 2 | **접근 제어 없음**     | 인턴이 프로덕션 데이터에 접근 가능           | 테이블/컬럼 단위 권한 설정           |
| 3 | **데이터 품질 규칙 없음** | null 80%인 테이블이 방치             | 스키마 검증 + 품질 체크 파이프라인      |
| 4 | **네이밍 표준 없음**    | `cust_data_v2_final_REAL.csv` | 네이밍 컨벤션 문서화 + 자동 검증       |
| 5 | **오너십 불명확**      | "이 데이터 누가 관리하죠?" → 침묵         | 데이터 오너 제도 + 정기 리뷰         |

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

***

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

DW에서 레이크하우스로 전환하는 것은 기술적 도전이면서 동시에 **조직적 도전** 입니다. 수년간의 마이그레이션 프로젝트 경험에서 얻은 실전 전략을 공유합니다.

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

```
[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가지

| # | 실패 패턴                                              | 빈도    | 올바른 접근                              |
| - | -------------------------------------------------- | ----- | ----------------------------------- |
| 1 | **"빅뱅 전환" 시도**— 전체를 한 번에 옮기려다 실패                   | 매우 흔함 | 테이블/파이프라인 단위 점진적 전환                 |
| 2 | **데이터 정합성 검증 생략**— "같은 SQL이니까 결과도 같겠지"             | 흔함    | DW와 Lakehouse 결과를 4주간 row-level 비교  |
| 3 | **기존 ETL을 1:1로 포팅**— Informatica 매핑을 Spark로 그대로 옮김 | 매우 흔함 | ELT 패턴으로 재설계. 원본을 Bronze에 넣고 SQL 변환 |

### 전환 비용의 현실적 규모

현업에서 DW→Lakehouse 전환 프로젝트의 비용을 투명하게 공유합니다.

| 항목                  | 소규모 (테이블 50개) | 중규모 (테이블 200개) | 대규모 (테이블 500개+)  |
| ------------------- | ------------- | -------------- | ---------------- |
| **분석/설계**           | 1~~2개월, 1~~2명 | 2~~3개월, 3~~4명  | 3~~6개월, 5~~8명    |
| **파이프라인 전환**        | 3\~6개월        | 6\~12개월        | 12\~24개월         |
| **이중 운영 기간**        | 1\~2개월        | 2\~4개월         | 4\~6개월           |
| **총 소요 기간**         | 6\~10개월       | 10\~18개월       | 18\~36개월         |
| **Databricks 러닝커브** | 팀 교육 1개월      | 팀 교육 2개월       | 전문가 채용 + 교육 3개월+ |

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

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

모든 기업이 DW를 완전히 버릴 수 있는 것은 아닙니다. 현실적으로 가장 많이 채택하는 하이브리드 전략입니다.

```
[하이브리드 아키텍처]
기존 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 처리, 문자열 비교, 소수점 연산에서 미묘한 차이가 있으므로, 반드시 샘플이 아닌 **전수 검증** 을 하세요.

***

## 정리

| 핵심 포인트              | 설명                              | 한마디                            |
| ------------------- | ------------------------------- | ------------------------------ |
| **데이터 웨어하우스**       | 구조화된 데이터를 빠르게 분석하기 위한 저장소       | 30년간 표준이었지만 비용과 유연성의 한계        |
| **데이터 레이크**         | 모든 종류의 데이터를 원본 그대로 저장하는 대용량 저장소 | 약속은 좋았으나 85%가 Data Swamp로 전락   |
| **Schema-on-Write** | 저장 시 스키마를 정의 (DW)               | 품질 보장, 유연성 낮음                  |
| **Schema-on-Read**  | 읽을 때 스키마를 적용 (Lake)             | 유연성 높음, 품질 보장 어려움              |
| **Data Swamp**      | 관리되지 않는 데이터 레이크                 | 거버넌스 없이 시작하면 반드시 도달            |
| **레이크하우스**          | 양쪽 장점을 결합한 차세대 아키텍처             | Delta Lake + Unity Catalog가 핵심 |

***

## 참고 링크

* [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)
* [CIDR 2021: Lakehouse Paper](http://cidrdb.org/cidr2021/papers/cidr2021_paper17.pdf)
* [Databricks: Delta Lake](https://docs.databricks.com/aws/en/delta/)
* [Databricks: Unity Catalog](https://docs.databricks.com/aws/en/data-governance/unity-catalog/)