Lakehouse Architecture & Cloud Data Platforms

1. Overview

레이크하우스 아키텍처 및 클라우드 데이터 플랫폼(Lakehouse Architecture & Cloud Data Platforms, LCP)은 값비싼 컴퓨팅 서버와 스토리지가 한 몸으로 결합되어 있던 과거의 온프레미스(On-premise) 웨어하우스(DW) 시대의 종말과, 연산(Compute)과 저장(Storage)을 물리적으로 완전히 찢어버린 현대 클라우드 데이터 스택의 혁명을 다룹니다.

데이터 레이크(Data Lake)의 무한한 확장성과 저렴한 S3 객체 스토리지 비용, 그리고 데이터 웨어하우스(DW)의 깐깐한 ACID 트랜잭션과 스키마 보장 능력을 융합한 것이 바로 '레이크하우스(Lakehouse)'입니다. 학습자는 Delta Lake, Apache Iceberg 같은 오픈 테이블 포맷이 어떻게 깡통 스토리지 위에서 타임 트래블(Time Travel)과 스냅샷 격리를 구현하는지 그 파케이(Parquet) 파일 레벨의 메타데이터 역학을 해부하고, 필요할 때만 수천 대의 서버를 띄워 쿼리를 돌리고 즉시 반납하는 서버리스 클라우드 플랫폼(Snowflake, BigQuery)의 극단적인 비용-성능 최적화 물리량을 지배합니다.

2. Scope & Boundaries

In-Scope

클라우드 데이터 저장 패러다임: Data Warehouse(정형, 비싼 스토리지) → Data Lake(비정형, 스키마 부재) → Lakehouse(통합, 오픈 테이블 포맷)의 진화.
연산과 저장의 분리 물리 (Compute-Storage Separation): 객체 스토리지(S3, GCS)의 확장성, 로컬 SSD 캐싱 엔진, 가상 웨어하우스(Virtual Warehouse) 오토스케일링.
오픈 테이블 포맷 엔진 (Table Formats): Apache Parquet/ORC(컬럼너 저장소), Delta Lake, Apache Iceberg의 트랜잭션 로그(JSON/Avro) 메타데이터 물리, 타임 트래블(Time Travel), UPSERT 메커니즘.
모던 데이터 스택 (Modern Data Stack): 클라우드 관리형 데이터 플랫폼(Snowflake, BigQuery, Databricks) 아키텍처, 제로 카피 클로닝(Zero-copy Cloning).

Out-of-Scope

데이터 파이프라인의 수송 로직 (Airflow/Kafka): 이 창고(Lakehouse)로 데이터를 실어 나르는 수송망의 설계 → 06-05. Data Ingestion 영역으로 위임.
머신러닝 모델 서빙 인프라: 저장된 데이터를 가져다 AI 모델을 학습시키고 API로 서빙하는 추론 서버 → 11-04. ML Engineering 영역으로 위임.

Boundaries

LCP vs. Storage Systems (06-06): 06-06(SHO)가 '하나의 리눅스 서버 안에서 디스크 섹터와 SSD를 다루는 로우 레벨 파일 시스템'이라면, LCP는 **'전 세계 클라우드 리전에 수백 페타바이트 단위로 뿌려진 객체 스토리지(Object Storage)를 거대한 하나의 데이터베이스처럼 보이게 묶어내는 메타데이터 추상화의 정점'**을 다룹니다.

3. Counterexample

데이터 레이크를 쓰레기장(Data Swamp)으로 방치 (Storage Fallacy): "일단 S3에 다 때려 넣어두면 나중에 분석가들이 알아서 쓰겠지"라는 안일한 생각. 데이터 레이크에 스키마 강제(Schema Enforcement)와 파티셔닝 전략(년/월/일) 없이 CSV, JSON 파일들을 마구잡이로 적재하면, 나중에 데이터를 읽을 때 1MB를 찾기 위해 1TB를 전부 스캔(Full Scan)해야 하는 네트워크 I/O 병목에 빠져 AWS 청구서 폭탄을 맞고 아무도 쓰지 않는 '데이터 늪(Swamp)'이 됩니다.
레이크하우스 환경에서의 무분별한 덮어쓰기 (Table Format Fallacy): Delta Lake나 Iceberg 환경에서, 단 1건의 레코드를 수정(UPDATE)하기 위해 애플리케이션 코드를 짜듯 접근하는 행위. 객체 스토리지(S3)의 파케이 파일은 '읽기 전용(Immutable)'이므로 1건만 수정하려 해도 1GB짜리 파케이 파일을 통째로 다시 써야 하는 **쓰기 증폭(Write Amplification)**이 터집니다. 이를 막기 위해 데이터가 쌓일 때 병합해 주는 Merge-on-Read 역학이나 주기적인 컴팩션(Compaction) 물리를 통제하지 못하면 클라우드 아키텍트가 아닙니다.

4. Prerequisites

데이터베이스 튜닝과 인덱스 (Basic): 컬럼너(Columnar) 스토리지가 왜 분석 쿼리에 압도적으로 빠른지 파악하려면 Row 기반 인덱스와의 비교 이해가 필수입니다. (06-01. RS)
분산 로직 및 저장 물리 (Recommended): S3와 같은 객체 스토리지가 왜 '강한 일관성(Strong Consistency)' 대신 '최종 일관성(Eventual Consistency)'을 가졌는지에 대한 CAP 이론 기초가 권장됩니다. (06-03. DLP)

5. Learning Map

Sequence	Core Cluster	Objective & Description	Evidence (BoK)
1	Evolution of Storage (DW to Lakehouse)	비싼 DW 사일로와 느린 데이터 레이크의 한계를 넘어, 이 둘을 결합한 클라우드 레이크하우스 패러다임을 확립합니다.	P4
2	Cloud-Native Compute (Separation)	스토리지(S3)는 영구적으로 놔두고, 연산 서버만 쿼리할 때 띄웠다가 즉시 삭제하여 요금을 아끼는 분리 구조를 익힙니다.	P4
3	Metadata Overlays (Delta & Iceberg)	깡통 S3 파일들 위에 JSON 트랜잭션 로그를 덮어씌워 ACID 보장과 과거 데이터 복원(Time Travel)을 물리적으로 증명합니다.	Industry
4	Platform Integration (Snowflake & BQ)	마이크로 파티셔닝과 제로 카피 클로닝 등 현대 클라우드 데이터 플랫폼들의 아키텍처 특장점을 벤치마킹합니다.	Industry

6. Learning Topics

Basic

Core Topic 01: 데이터 스토리지 진화와 객체 스토리지 물리 (Evolution & Object Storage)

Why to Learn: 무한대에 가까운 데이터를 저장하면서도 비용은 기존 스토리지의 1/10 수준으로 방어하는 클라우드의 바닥판(S3)을 지배하기 위함입니다.
What to Learn:
- Concepts: 데이터 웨어하우스(Data Warehouse), 데이터 레이크(Data Lake), 데이터 레이크하우스(Data Lakehouse).
- Skills: 파일 시스템(POSIX)의 폴더 트리 계층 vs 객체 스토리지(S3, GCS)의 플랫(Flat) 네임스페이스와 접두사(Prefix) 파티셔닝 구조의 물리적 차이 파악.
- Tools: AWS S3 CLI, MinIO.
- Trade-offs: 폴더 구조를 바꿔야 할 때 메타데이터만 0.1초 만에 수정하면 끝나는 블록 파일 시스템 vs 이름(Key)을 바꾸려면 수십 GB의 객체를 통째로 새로 복사(Copy)하고 기존 것을 지워야 하는 객체 스토리지의 극단적 변경 패널티.
How to Learn:
- 1단계: 온프레미스 장비에 10TB 하드디스크를 꽂고 서버 대수를 늘려가는 구조(DW)와, 컴퓨팅 서버를 모두 끄더라도 S3에는 데이터가 초저가로 안전하게 살아있는 클라우드 레이크 스토리지 구조의 연간 유지 유지비용 그래프를 비교 도출합니다.
- 2단계: S3에 데이터를 넣을 때 s3://bucket/year=2024/month=10/data.csv 형태로 저장(파티셔닝)해 두면, "10월 데이터만 가져와"라는 쿼리가 99%의 무관한 데이터를 스캔하지 않고(프루닝, Pruning) 물리적으로 즉시 원하는 파일만 낚아채는 원리를 실험합니다.
Implement: 특정 날짜의 대용량 로그 파일을 입력받아, S3 객체 스토리지의 파티션 접두사(Prefix) 규칙에 맞게 디렉토리를 가상으로 쪼개어 업로드하는 스트리밍 파이프라인.

Why to Learn: 단순한 CSV나 JSON 파일들을 디스크에 저장하는 방식에서 벗어나, 디스크 I/O를 1/100로 줄이고 DB급의 ACID(원자성) 덮어쓰기를 클라우드 저장소 위에서 마법처럼 실현하기 위해서입니다.
What to Learn:
- Concepts: 행 기반(Row-oriented) vs 열 기반(Column-oriented) 저장 포맷(Parquet, ORC).
- Skills: 프로젝션 푸시다운(Projection Pushdown: 필요한 열만 읽기), 프레디케이트 푸시다운(Predicate Pushdown: 스토리지 층에서 필터링), 압축 효율성(Run-length encoding).
- Tools: Apache Parquet Viewer, Delta Lake, Apache Iceberg.
- Trade-offs: 쓰기를 할 때마다 수백 개의 파케이 파일과 트랜잭션 로그를 새로 찍어내야 하는 테이블 포맷의 무거운 쓰기 연산(Write Overhead) vs 100개의 컬럼 중 딱 2개의 컬럼 값만 읽어올 때 디스크를 2%만 읽고 끝내는 경이로운 읽기(Read) 퍼포먼스.
How to Learn:
- 1단계: 1GB짜리 CSV 파일(행 기반)과 동일 데이터를 파케이(열 기반)로 변환해 크기가 100MB 수준으로 압축되는 물리적 이유(같은 데이터 타입이 세로로 모여 있어 압축률이 극대화됨)를 분석합니다.
- 2단계: Iceberg나 Delta Lake의 폴더 내부를 까보고, _delta_log/00001.json 같은 트랜잭션 로그 파일이 "A 파일은 삭제됨, B 파일이 새로 추가됨"이라는 지시어를 통해, 독자가 쿼리를 날릴 때 파일 B만 읽도록 유도하는 스냅샷 격리(Snapshot Isolation) 물리를 도식화합니다.
Implement: 1,000만 건의 CSV 레코드를 읽고, 특정 컬럼별 최솟값(Min), 최댓값(Max)을 푸터(Footer) 통계 메타데이터로 남기면서 열 기반(Columnar) 바이너리 형태로 변환 저장하는 초소형 파케이 인코더.

Practical

Core Topic 03: 연산과 저장의 분리 물리 (Compute-Storage Separation)

Why to Learn: 과거 하둡(Hadoop) 시절처럼 서버 한 대에 데이터와 CPU를 몰아넣던 HDFS의 지옥에서 벗어나, 데이터는 한곳(S3)에 모아두고 필요할 때만 마법처럼 컴퓨팅 서버를 100대씩 띄워 연산을 끝내고 요금을 끄는 클라우드 엘라스틱(Elastic) 파워를 통제하기 위함입니다.
What to Learn:
- Concepts: 연산-저장 분리(Compute-Storage Separation), 가상 웨어하우스(Virtual Warehouse), 오토스케일링(Autoscaling).
- Skills: 네트워크 셔플링(Network Shuffling) 병목 완화 로직, 컴퓨팅 노드(EC2) 내부의 에페메럴(Ephemeral, 휘발성) 로컬 NVMe 캐싱 물리 적용.
- Tools: Snowflake 리소스 모니터, AWS EMR 서버리스.
- Trade-offs: 연산을 띄울 때 S3에서 데이터를 네트워크를 통해 당겨와야 하므로 발생하는 필연적인 네트워크 I/O 대기시간(Cold Start Latency) vs 평소에는 스토리지 저장 비용(월 몇만 원 수준)만 내다가 월말 결산 쿼리 10분을 위해 슈퍼컴퓨터를 렌탈해 쓰고 버리는 기적의 과금 효율성.
How to Learn:
- 1단계: 아침 9시 전사 직원 500명이 동시에 대시보드 조회를 누를 때, 스토리지(데이터)는 하나지만 10대의 가상 컴퓨팅 클러스터가 0.1초 만에 병렬로 복제 생성되어 쿼리를 분산 처리하고 9시 10분에 자동 소멸하는 탄력성 곡선을 그립니다.
- 2단계: 네트워크에서 매번 수십 GB의 데이터를 당겨오는 한계를 극복하기 위해, 가상 웨어하우스 서버의 로컬 SSD에 자주 읽는 파일 블록을 마이크로초 단위로 임시 저장하는 마이크로 파티션 캐싱(Micro-partition Caching) 물리를 분석합니다.
Implement: 마스터 노드가 쿼리를 받으면, 현재 S3 객체 목록을 파티션 키 기준으로 쪼갠 뒤 여러 개의 워커(Worker) 스레드에 네트워크 다운로드 임무를 분배하여 집계 연산을 병렬로 처리하는 Map-Reduce 개념 증명 뼈대.

Advanced

Core Topic 04: 모던 데이터 스택 아키텍처와 통합 플랫폼 (Modern Data Platforms)

Why to Learn: 단순히 스크립트 뭉치가 아니라 Snowflake, BigQuery, Databricks 같은 수백조 단위 가치의 관리형 플랫폼들이 어떤 극한의 아키텍처 비기를 숨기고 엔터프라이즈의 표준으로 자리 잡았는지 그 엔진 내부를 해부하기 위해서입니다.
What to Learn:
- Concepts: 모던 데이터 스택(Modern Data Stack), 마이크로 파티셔닝(Micro-Partitioning), 제로 카피 클로닝(Zero-copy Cloning), 데이터 셰어링(Data Sharing).
- Skills: 인덱스 없이도(Index-less) 메타데이터 통계(Min/Max)만으로 페타바이트급 테이블을 1초 만에 훑어내는 푸시다운 마법, 연산 성능 프로파일링.
- Tools: Snowflake, Google BigQuery.
- Trade-offs: 인프라 관리자 없이 쿼리만 던지면 알아서 확장/축소되는 완전 관리형(SaaS) 플랫폼의 압도적 비즈니스 민첩성 vs 내부 튜닝 손잡이(인덱스 지정, 디스크 매핑)가 모두 막혀 있어, 한 번 쿼리를 잘못 짜면 엄청난 컴퓨팅 크레딧(요금)이 그대로 타버리는 벤더 종속(Lock-in) 리스크.
How to Learn:
- 1단계: 개발계 DB를 복사하기 위해 10TB 데이터를 이틀 동안 덤프(Dump) 뜨던 과거와 달리, 제로 카피 클로닝 명령어 1줄로 '원본 S3 파일들의 메타데이터 포인터만 복제'하여 단 1초 만에, 디스크 용량 소모 0바이트로 똑같은 10TB 가상 테이블을 띄워내는 B-Tree 메타 포인터 역학을 연구합니다.
- 2단계: 파트너사에게 데이터를 넘겨주기 위해 FTP로 파일을 매일 쏘는 대신, 클라우드 플랫폼의 데이터 셰어링(Data Sharing) 기능을 통해 파트너사가 내 S3 스토리지를 '직접 읽게(읽기 권한만 줌)' 만들어 데이터 이동을 원천 제거하는 네트워크 토폴로지를 설계합니다.
Implement: 특정 컬럼의 (최솟값, 최댓값, Null 갯수) 정보를 메타데이터 JSON에 기록해두고, 사용자가 WHERE age = 30 이라는 쿼리를 날렸을 때 실제 데이터 파일을 열어보기도 전에 메타데이터만 확인하여 "이 파일에는 30이 없음(Min 40, Max 50)"을 판단해 스캔을 물리적으로 차단(Pruning)하는 모의 필터 엔진.

7. Terminology

Term (EN / ko, abbr)	1문장 정의	단계(기본/권장/실무/심화)	역할/맥락	관련 개념	유사/대비/함께 사용	오해 포인트	Evidence(Primary/Secondary/Industry)	Flags(core/misused/legacy)
Lakehouse	데이터 레이크의 저렴한 저장성 위에 데이터 웨어하우스의 정합성 기능을 물리적으로 구현한 아키텍처입니다.	추천	통합 패러다임	Delta Lake	Data Warehouse	단순히 '둘 다 씀'으로 오해	P4:DS-BoK Platforms	core
Object Storage	비정형 데이터를 키-값 형태로 관리하며 무한 확장성을 제공하는 클라우드 기본 저장 서비스입니다.	기본	인프라	S3 / GCS	File System	계층적 폴더로 오해	P4:DS-BoK Infrastructure	core
Time Travel	데이터의 변경 이력을 보존하여 특정 시점의 데이터 상태로 즉시 조회하거나 복구할 수 있는 기능입니다.	실무	편의성/복구	Snapshot	Git for Data	'백업 복원'과 동일시함	Industry Delta	core
Parquet	데이터 분석에 최적화된 컬럼 기반의 바이너리 저장 포맷으로 높은 압축률과 선택적 읽기를 지원합니다.	추천	성능 최적화	Columnar	CSV	사람이 읽는 포맷으로 오해	Industry Parquet	core

8. References

Primary References

[P4] DS-BoK - Data Platforms & Infrastructure — Modern architectural trends.
[P5] SFIA - Data Management — Enterprise level data platform skills.

Secondary References

[Building the Data Lakehouse] Bill Inmon — The father of DW on modern tech.
[The Modern Data Stack] online courseware/books — Integrating managed services.

Industry References

[Databricks: Lakehouse Architecture Definition] — Industry pioneer whitepaper.
[Snowflake: Architecture & Design Overview] — Unique cloud DW implementation.

9. Final Checklist

Primary Checklist

데이터 웨어하우스를 운영할 때 발생하는 '데이터 사일로' 현상을 레이크하우스가 어떠한 물리적 통합 방식으로 해결하는지 설명 가능한가? (P4)
컬럼 기반 저장 포맷(Parquet 등)이 특정 열만 조회하는 집계 쿼리에서 왜 I/O를 획기적으로 줄이는지 수리적으로 인지하는가? (P4)

Secondary Checklist

컴퓨팅과 저장소가 물리적으로 분리된 환경에서, 네트워크 지연(Network Latency)이 쿼리 성능에 미치는 영향을 제안 및 분석 가능한가?
테이블 포맷 간의(Delta vs Iceberg) 메타데이터 관리 방식 차이가 다중 동시성 쓰기 환경에서 어떤 영향을 주는지 이해하고 있는가?

Industry Checklist

Snowflake나 BigQuery와 같은 서버리스 DW를 도입할 때의 비용 모델이 고정 할당 방식 대비 가지는 물리 자원 경제성을 평가 가능한가? (SFIA)
데이터 레이크를 구축한 후 데이터 카탈로그가 부재할 때 발생하는 '데이터 늪(Data Swamp)' 상태를 식별하고 해결책을 제시 가능한가?