레이크하우스와 메달리온 아키텍처 — Bronze/Silver/Gold 경계 설계
Data Lake vs Data Warehouse vs Lakehouse: A DE's Guide (2026) — DataVidhya (blog) Why Lakehouse Has Become the Default Conversation / Lake vs DW vs Lakehouse Comparison 1-6 (pp.9-14); 100+ Interview Q4 Medallion Architecture (p.3); 40 System Design Q8 Medallion boundary, Q16 e-commerce warehouse design (pp.5-6, 9-10)
이 모듈을 다 읽으면
- 레이크하우스가 레이크와 웨어하우스 중 하나를 대체하는 것이 아니라 둘의 아이디어를 결합한 것임을 설명할 수 있다
- 메달리온 아키텍처의 Bronze/Silver/Gold 계층을 소비자 기준으로 구분하고, Gold 계층이 너무 넓어지는 실수를 진단할 수 있다
- SCD Type 1/2 선택 같은 실전 웨어하우스 설계 결정을 구체적 사례에 적용할 수 있다
레이크하우스는 데이터 레이크의 저비용·유연성과 웨어하우스의 신뢰성·성능을 한 기반 위에 결합해, 데이터를 여러 시스템으로 복사하지 않고도 탐색과 신뢰할 수 있는 리포팅을 동시에 지원한다. 이를 실제로 조직화하는 표준 패턴이 메달리온 아키텍처(Bronze-Silver-Gold)이며, 각 계층의 경계는 '누가 이 계층을 읽는가'로 결정된다.
왜 레이크하우스가 기본 대화가 되었는가
과거에는 데이터 아키텍처 논의가 '깨끗한 리포팅을 위한 웨어하우스를 만들 것인가, 유연한 탐색을 위한 레이크를 만들 것인가'라는 단순한 양자택일에서 출발했다. 하지만 현대 데이터 팀은 대시보드를 만드는 분석가, 원본 데이터를 다루는 데이터 사이언티스트, 지속적으로 확장해야 하는 파이프라인을 운영하는 데이터 엔지니어를 하나의 플랫폼으로 동시에 지원해야 한다. 각 그룹마다 별도 시스템을 만드는 접근은 처음엔 실용적으로 보이지만 복잡도가 금방 쌓인다.
레이크하우스는 웨어하우스를 대체하거나 레이크를 포기하는 것이 아니다. 데이터를 여기저기로 복사하거나 몇 달마다 파이프라인을 재구축하지 않고도 서로 다른 사용자와 워크로드를 지원하기 위해 등장했다. 목적/유스케이스 측면에서는 레이크처럼 원본·다양한 데이터를 빠르게 들이면서도 웨어하우스처럼 리포팅·분석을 위한 구조화되고 신뢰할 수 있는 데이터를 지원한다. 스키마 처리 측면에서는 유연성이 필요할 때는 레이크처럼 원본 상태로 데이터를 받아들이고, 사용 패턴이 명확해지면 웨어하우스처럼 점진적으로 구조를 더한다. 성능 측면에서는 같은 데이터 위에서 직접 분석을 실행해 중복 시스템의 필요성을 줄이고, 비용 측면에서는 레이크만큼 스토리지를 저렴하게 유지하면서 웨어하우스 수준의 성능/신뢰성을 지원한다. 변화 대응 측면에서는 스키마 진화와 버전 관리를 내장해 구조를 함부로 바꾸지 않으면서도 새 필드/포맷의 유입을 허용하고, 신뢰/소유권 측면에서는 웨어하우스처럼 일관된 지표를 재사용 가능하게 정의하면서도 레이크처럼 여러 팀이 같은 데이터를 다룰 수 있게 한다.
핵심 포인트
- 레이크하우스는 웨어하우스나 레이크를 대체하는 것이 아니라, 서로 다른 사용자(분석가/데이터 사이언티스트/엔지니어)를 데이터 복제 없이 하나의 기반으로 지원하기 위해 등장했다.
- 목적, 스키마 처리, 성능, 비용, 변화 대응, 신뢰/소유권 6가지 측면 모두에서 레이크하우스는 레이크와 웨어하우스 각각의 강점을 절충해 결합한다.
메달리온 아키텍처 — Bronze, Silver, Gold
메달리온 아키텍처는 레이크하우스 내부 데이터를 세 가지 품질 등급으로 조직화하는 패턴이다(원래 Databricks가 대중화한 용어이지만, 지금은 Delta Lake·Iceberg 등 특정 벤더에 묶이지 않는 일반적인 레이크하우스 설계 패턴으로 널리 쓰인다 — 정정). Bronze는 수집된 원본 데이터를 변형 없이 그대로 보관하는 append-only 계층이다. Silver는 정제·중복 제거·정합화(conformed)를 거친 데이터로, null이 처리되고 스키마가 강제되며 PII가 마스킹된다. Gold는 특정 소비자를 위해 최적화된 비즈니스 수준 집계와 차원 모델을 담는다.
각 계층의 경계는 '누가 그 계층을 읽는가'로 결정된다. Bronze는 디버깅과 재처리(replay)를 위한 것이고, Silver는 탐색적 작업을 하는 데이터 엔지니어와 사이언티스트를 위한 것이며, Gold는 대시보드와 경영진 리포팅을 위한 것이다. 흔한 실수는 Gold를 지나치게 넓게 만드는 것이다 — 하나의 대시보드를 위해 Gold 테이블 5개를 조인하고 있다면, Gold 계층이 너무 세분화(granular)되어 있다는 신호다. Gold 테이블 하나는 한두 가지 구체적 유스케이스만 서비스해야 한다.
핵심 포인트
- Bronze=원본 그대로(append-only, 재처리용), Silver=정제·중복제거·정합화(엔지니어/사이언티스트 탐색용), Gold=비즈니스 집계(대시보드/리포팅용) — 경계는 '누가 읽는가'로 결정한다.
- 흔한 실수는 Gold를 너무 넓게 만드는 것 — 하나의 대시보드를 위해 여러 Gold 테이블을 조인해야 한다면 Gold가 지나치게 세분화된 것이다.
실전 사례 — 2백만 건/일 이커머스 웨어하우스 설계
일 200만 건의 주문(초당 약 23건)을 처리하는 중견 이커머스 기업을 예로 들면, 수집량 자체는 크지 않지만 쿼리 복잡도가 설계의 핵심이다. Bronze 계층에는 Kafka Connect나 Fivetran을 통해 주문·클릭·재고 변경 같은 원본 이벤트 스트림이 S3에 Parquet 형태로 그대로 적재된다. Silver 계층에서는 dbt 모델이 주문 데이터를 고객·상품·재고와 정제·중복제거·조인해 정합화된 팩트/차원 테이블을 만든다. Gold 계층에는 상위 5개 대시보드 쿼리(카테고리별 일일 매출, 고객 생애가치, 재고 회전율 등)를 위한 사전 집계 테이블만 둔다. Snowflake나 Databricks 위에서 ETL용(야간에 크게 도는)과 BI용(하루 종일 도는, 더 작은) 웨어하우스를 분리해 운영하고, 팩트 테이블은 order_date로 파티셔닝한다.
이런 설계에서 자주 검증받는 결정이 SCD(Slowly Changing Dimension) 선택이다 — 고객이 주소를 변경했을 때 덮어쓸 것인가(Type 1), 이력을 남길 것인가(Type 2)? 이커머스에서는 고객·상품 차원에 Type 2를 쓰는 것이 표준이다. 주문이 발생한 시점에 고객이 어느 지역에 있었는지를 알아야 하기 때문이다 — Type 1로 덮어쓰면 과거 주문의 배송지·세율 등을 재구성할 수 없게 된다.
핵심 포인트
- Bronze(Kafka Connect/Fivetran으로 원본 이벤트를 S3 Parquet에 적재) → Silver(dbt로 정제/조인해 팩트·차원 테이블 생성) → Gold(상위 대시보드 쿼리 전용 사전 집계)로 이어지는 파이프라인이 실전 이커머스 웨어하우스의 표준 구조다.
- 이커머스에서 고객/상품 차원은 SCD Type 2가 표준이다 — 주문 시점의 지역/속성을 재구성해야 하므로 Type 1(덮어쓰기)은 과거 주문 정보를 왜곡시킨다.