LLM WikiAccess-protected knowledge portal
← 스터디 홈
3편 · 약 22분

Data Lake, Lakehouse, Medallion Architecture

이 세션의 목표

이번 세션은 사용자가 직접 언급한 핵심 용어인 Medallion Architecture, Data Lake, Data Warehouse, Data Mart 중 Lake 계열을 먼저 정리한다.

핵심은 간단하다.

  • Data Lake: 원본에 가까운 다양한 데이터를 크게 담는 곳
  • Lakehouse: Lake 위에 Warehouse식 신뢰성·관리 기능을 얹은 구조
  • Medallion Architecture: Bronze → Silver → Gold로 데이터 품질을 단계적으로 높이는 설계 패턴

Data Lake: 일단 잃지 않고 담는다

Data Lake는 구조화된 테이블뿐 아니라 JSON, 로그, CSV, 이미지, parquet, dump 파일 같은 다양한 데이터를 원본에 가깝게 저장하는 공간이다. 보통 S3, GCS, Azure Data Lake Storage, HDFS, MinIO 같은 object storage 또는 distributed file system 위에 만든다.

Data Lake의 장점은 유연성이다. 처음부터 모든 스키마와 지표를 정하지 않아도 데이터를 보관할 수 있다. 나중에 새로운 분석 요구가 생겼을 때 원본에서 다시 처리할 수 있다.

하지만 무작정 쌓기만 하면 Data Swamp가 된다. 어느 파일이 최신인지, 어느 데이터가 검증됐는지, 누가 써도 되는지 모르는 늪이다.

Lakehouse: Lake에 관리 기능을 붙인다

Lakehouse는 Data Lake의 저렴하고 유연한 저장소를 유지하면서, Warehouse가 제공하던 관리 기능을 추가하려는 구조다.

대표 기능은 다음과 같다.

기능왜 필요한가
ACID transaction여러 job이 동시에 쓰더라도 테이블 상태를 일관되게 유지
Schema enforcement/evolution스키마가 갑자기 깨지는 것을 감지하거나 안전하게 변경
Time travel/versioning과거 버전 조회, rollback, 재현성 확보
Catalog integration테이블 위치, 권한, owner, lineage 관리
SQL query supportBI/분석 사용자가 쉽게 접근

Delta Lake, Apache Iceberg, Apache Hudi 같은 table format이 이 영역에서 자주 언급된다.

Medallion Architecture: 원재료에서 완제품까지

Medallion Architecture는 데이터를 Bronze, Silver, Gold 세 단계로 나눠 품질을 점진적으로 높이는 패턴이다. Databricks Lakehouse 문맥에서 널리 알려졌지만, 이름보다 중요한 것은 “원본 보존 → 정제 → 소비용 데이터”라는 원칙이다.

🥉 Bronze Raw / Landing
원본, 수집 메타데이터, 재처리 기준
→
🥈 Silver Clean / Conformed
정제, 중복 제거, 타입 정리, 조인
→
🥇 Gold Business-ready
지표, 집계, mart, dashboard
Bronze → Silver → Gold

Bronze Layer

Bronze는 “받은 그대로 보관한다”에 가깝다. 완전히 아무 검증도 하지 말라는 뜻은 아니다. 최소한 수집 시각, source, 파일명, batch id, schema version 같은 메타데이터는 붙여야 한다.

Bronze에서 중요한 것은 다음이다.

  • 원본을 최대한 잃지 않는다.
  • 재처리할 수 있게 immutable하게 보관한다.
  • downstream 변환 실패가 원본 손실로 이어지지 않게 한다.
  • source schema drift를 감지할 수 있게 한다.

DBA 관점에서는 backup, binlog archive, snapshot export와 비슷한 사고방식이다. “나중에 다시 만들 수 있는 기준점”을 남긴다.

Silver Layer

Silver는 분석 가능한 공통 데이터로 정리하는 단계다.

예를 들어 여러 source에서 온 사용자 정보를 하나의 key 기준으로 맞추고, 타입을 정리하고, 중복을 제거하고, 삭제/수정 이벤트를 반영한다. 이 단계에서 data quality rule이 본격적으로 들어간다.

Silver에서 자주 하는 작업은 다음이다.

  • deduplication
  • type casting
  • invalid row quarantine
  • primary key/unique key 검증
  • CDC merge/upsert
  • reference data join
  • 개인정보 masking/tokenization

Gold Layer

Gold는 소비자에게 가까운 데이터다. BI dashboard, Data Mart, report, ML feature, 고객사 배포용 dataset이 여기에 올 수 있다.

Gold에서는 “정확한 원본”보다 “합의된 비즈니스 의미”가 중요해진다. 예를 들어 active_user, monthly_revenue, fixed_vulnerability_count 같은 지표 정의가 명확해야 한다.

DBA·플랫폼 엔지니어가 볼 운영 포인트

Layer운영 질문
Bronze원본 보관 기간은? 개인정보 삭제 요청이 오면 raw도 지워야 하는가? schema drift를 어떻게 감지하는가?
Silvermerge key는 안정적인가? 중복/역전 이벤트를 어떻게 처리하는가? 실패 row는 버리는가 격리하는가?
Gold지표 정의 owner는 누구인가? dashboard와 mart가 같은 정의를 쓰는가? refresh 실패 시 사용자에게 어떻게 보이는가?

Medallion을 무조건 도입하면 안 되는 경우

작은 팀에서 데이터 source가 1~2개이고, 요구사항이 단순하며, 분석 사용자가 적다면 Bronze/Silver/Gold를 물리적으로 모두 나누는 것이 과할 수 있다. 이때는 폴더 이름이나 schema 이름만 raw, staging, mart로 나누어도 충분할 수 있다.

중요한 것은 계층 이름이 아니라 다음 원칙이다.

  1. 원본을 잃지 않는다.
  2. 정제 기준을 명시한다.
  3. 소비자용 데이터와 중간 데이터를 섞지 않는다.
  4. 장애 시 어느 단계부터 재처리할지 정한다.

세션 과제

현재 다루는 데이터셋 하나를 Bronze/Silver/Gold로 나눠보자.

Layer어떤 데이터가 들어가야 하는가보관 기간실패 시 재처리 기준
Bronze
Silver
Gold

References

  • https://www.databricks.com/glossary/medallion-architecture
  • https://learn.microsoft.com/en-us/fabric/onelake/onelake-medallion-lakehouse-architecture
  • https://www.databricks.com/glossary/data-lakehouse
  • https://delta.io/
  • https://iceberg.apache.org/
  • https://hudi.apache.org/