메달리온 아키텍처(Medallion Architecture)

1. 개요

정의: 메달리온 아키텍처(Medallion Architecture)는 데이터 레이크하우스(lakehouse) 내부의 데이터를 품질과 가공 수준에 따라 브론즈(Bronze)·실버(Silver)·골드(Gold)의 계층(layer)으로 점진적으로 정제·구조화하는 데이터 설계 패턴으로, 각 계층을 거칠수록 데이터의 정합성·비즈니스 의미·활용성이 높아지도록 구성하는 다단계(multi-hop) 정제 모델이다.

기업의 데이터 아키텍처는 오랫동안 데이터 웨어하우스(DW)의 엄격한 스키마-온-라이트(schema-on-write) 와 데이터 레이크(data lake)의 유연한 스키마-온-리드(schema-on-read) 라는 두 극단 사이에서 갈등해 왔다. DW는 정형 데이터에 대해 높은 품질과 거버넌스를 제공했지만 반정형·비정형 데이터와 대용량·실시간 처리에 취약했고, 데이터 레이크는 모든 형태의 데이터를 값싸게 저장했지만 품질·일관성 관리가 되지 않아 결국 데이터 늪(data swamp) 으로 전락하는 사례가 빈번했다. 신뢰할 수 없는 데이터가 레이크에 쌓이면 분석가는 매번 원천을 다시 검증해야 하고, 조직 전체가 동일한 수치를 공유하지 못하는 '단일 진실 공급원(Single Source of Truth)'의 부재 문제가 발생한다.

레이크하우스는 이 둘의 장점을 결합하여, 레이크의 저비용 오브젝트 스토리지 위에 ACID 트랜잭션·스키마 적용·버전 관리 같은 DW의 신뢰성 기능을 얹은 구조다. 그러나 레이크하우스라는 저장 기반이 있다고 해서 데이터가 저절로 정돈되지는 않는다. "어디까지가 원천 그대로이고, 어디서부터 검증을 거쳤으며, 무엇이 최종 소비용인가"를 조직이 약속한 표준화된 흐름의 규율이 필요하다. 메달리온 아키텍처는 바로 이 규율을 제공하는 설계 관례(convention)로, Databricks가 레이크하우스의 모범 패턴으로 대중화했다.

이 패턴의 핵심 가치는 점진적 품질 향상(progressive refinement) 에 있다. 올림픽 메달의 등급(동-은-금)에서 이름을 따온 것처럼, 데이터는 원천에서 수집될 때 가장 가공도가 낮은 브론즈로 들어와, 정제·통합을 거쳐 실버로 승격되고, 비즈니스 집계·모델링을 거쳐 최종적으로 금빛의 골드로 완성된다. 이렇게 단계를 명시적으로 분리하면 원천 데이터의 불변 보존(감사·재처리 가능), 중간 산출물의 재사용, 소비 계층의 성능 최적화 를 동시에 달성할 수 있어, 데이터 파이프라인의 신뢰성과 유지보수성이 크게 향상된다.

2. 전체 구조와 설계 원칙

메달리온 아키텍처는 원천 시스템(OLTP DB·로그·IoT·API 등)에서 수집된 데이터가 세 계층을 순차적으로 통과하며 가치가 누적되는 파이프라인형 구조를 가진다. 각 계층은 물리적으로 별도의 테이블(또는 스토리지 경로)로 저장되며, 상위 계층은 바로 아래 계층을 입력으로 삼는다. 전체 구조는 아래와 같다.

graph LR
  subgraph SRC["원천 시스템"]
    S1["OLTP DB"]
    S2["로그/이벤트"]
    S3["IoT/API"]
  end
  subgraph LH["레이크하우스"]
    B["브론즈(Bronze)<br/>원천 그대로 적재"]
    SV["실버(Silver)<br/>정제·검증·통합"]
    G["골드(Gold)<br/>집계·비즈니스 모델"]
  end
  subgraph CON["소비 계층"]
    C1["BI 대시보드"]
    C2["ML 학습/추론"]
    C3["Ad-hoc 분석"]
  end
  S1 --> B
  S2 --> B
  S3 --> B
  B -->|"정제(Cleansing)"| SV
  SV -->|"집계(Aggregation)"| G
  G --> C1
  G --> C2
  SV --> C2
  G --> C3

이 구조를 떠받치는 설계 원칙은 다음과 같이 요약된다.

• 불변성과 재처리 가능성(immutability & replayability). 브론즈는 원천을 가공 없이 보존하므로, 상위 계층의 변환 로직에 오류가 발견되거나 요구사항이 바뀌어도 브론즈를 다시 읽어 전 계층을 재구성할 수 있다. 즉 브론즈는 데이터 파이프라인의 '백업본이자 리플레이 로그' 역할을 한다.
• 관심사의 분리(separation of concerns). 수집(ingestion)·정제(quality)·활용(serving)이라는 서로 다른 책임을 계층으로 나누어, 각 단계를 독립적으로 개발·테스트·최적화할 수 있다.
• 점진적 품질 상승. 계층이 올라갈수록 품질과 응집도가 높아진다. 아래로 갈수록 범용적·원시적이고 위로 갈수록 특정 비즈니스 목적에 특화된다.
• 단일 진실 공급원. 실버라는 공통 정제 기반을 모든 골드가 공유함으로써, 부서 간 수치 불일치를 방지하고 조직 차원의 일관된 지표를 보장한다.

이러한 원칙 덕분에 메달리온은 '빠르게 저장하되 신중하게 소비하라'는 현대 데이터 엔지니어링의 요구를 자연스럽게 충족한다. 원천은 지체 없이 브론즈에 받아 데이터 유실을 막고, 소비는 검증된 상위 계층에서만 이루어지도록 강제함으로써, 수집의 민첩성과 활용의 신뢰성이라는 상충하는 요구를 계층 분리로 양립시킨다.

주의할 점은 메달리온이 "반드시 세 개의 계층"을 의미하지는 않는다는 것이다. Microsoft와 Databricks의 가이드 모두 이 패턴은 유연(flexible) 하여 조직의 요구에 맞게 계층 수와 명칭을 조정할 수 있다고 명시한다. 실무에서는 브론즈 이전에 원시 파일을 받는 'Raw/Landing' 영역을 두거나, 골드를 용도별(BI용·ML용) 마트로 다시 분할하기도 한다. 핵심은 계층의 개수가 아니라 가공 수준에 따른 명시적 분리와 그에 대한 조직적 합의다.

3. 계층별 역할과 데이터 흐름

실제 데이터가 각 계층에서 어떤 변환을 겪는지를 세부 프로세스로 표현하면 다음과 같다.

flowchart TB
  R["원천 데이터(정형/반정형/비정형)"] --> I["증분 수집(Incremental Ingestion)"]
  I --> B["브론즈: append-only 적재<br/>+ 적재 메타데이터(출처·시각) 부착"]
  B --> V{"데이터 품질 검증"}
  V -->|"통과"| SV["실버: 중복제거·타입정합·조인/통합"]
  V -->|"실패(격리)"| Q["격리 테이블(Quarantine)"]
  SV --> A["비즈니스 집계·차원모델링(스타스키마)"]
  A --> G["골드: 집계 지표·피처·마트"]
  G --> O["소비: BI/ML/리포트"]

가. 브론즈 계층(Bronze — 원천 보존 계층). 브론즈는 원천 시스템에서 수집한 데이터를 가능한 한 원형 그대로(as-is) 적재하는 착지점이다. 이 계층의 설계 철학은 "변환하지 않는다"이다. 스키마 변경이나 클렌징을 최소화하고, 대신 적재 시각·원천 식별자·파일 경로 같은 메타데이터를 추가 컬럼으로 부착하여 데이터의 계보(lineage)를 추적할 수 있게 한다. 적재 방식은 기존 레코드를 덮어쓰지 않는 추가 전용(append-only) 이 기본인데, 이는 원천의 변경 이력까지 보존하여 감사(audit)와 시점 재현(time travel)을 가능하게 하기 위함이다.

브론즈를 원형 보존하는 이유는 재처리 유연성 때문이다. 예컨대 실버 변환 로직에 버그가 있어 지난 6개월치 지표가 잘못 계산되었다면, 원천 시스템에 다시 접근하지 않고도 브론즈만 리플레이하여 복구할 수 있다. 만약 수집 단계에서 이미 정제를 해버렸다면 원본 정보가 소실되어 이런 복구가 불가능하다. 전자상거래 기업을 예로 들면, 주문 API의 JSON 응답을 파싱·가공하지 않고 통째로 브론즈에 저장해 두면, 나중에 "결제 수단별 환불율" 같은 새 요구가 생겨도 과거 데이터에서 즉시 추출할 수 있다.

나. 실버 계층(Silver — 정제·통합 계층). 실버는 브론즈의 원시 데이터를 검증·정제·통합하여 '신뢰할 수 있는 기업 뷰(enterprise view)'를 구축하는 계층이다. 여기서 수행되는 핵심 변환은 (1) 결측·이상치 처리와 중복 제거, (2) 데이터 타입·단위·코드값 표준화, (3) 여러 원천을 공통 키로 조인하여 엔터티(고객·상품·주문)를 통합하는 작업이다. 품질 검증을 통과하지 못한 레코드는 버리지 않고 격리 테이블(quarantine) 로 분리하여 원인을 분석하는 것이 모범 관례다. 이렇게 하면 불량 데이터가 상위로 전파되는 것을 막으면서도 손실 없이 추적할 수 있다.

실버가 중요한 이유는 이 계층이 대부분의 데이터 소비자가 공유하는 공통 기반이 되기 때문이다. 골드가 특정 부서의 특정 지표에 특화된다면, 실버는 "정제되었지만 아직 특정 용도에 치우치지 않은" 범용 자산이다. 머신러닝 엔지니어는 자유로운 피처 탐색을 위해 종종 골드가 아닌 실버를 직접 사용하는데, 이는 골드의 집계가 원본의 세밀한 정보를 소실시키기 때문이다. 금융권의 경우, 여러 코어뱅킹 시스템의 계좌·거래 데이터를 실버에서 하나의 표준 거래 모델로 통합하면, 이후 리스크·마케팅·규제보고 등 다양한 골드 산출물이 이 단일 기반 위에서 일관되게 만들어진다.

다. 골드 계층(Gold — 비즈니스 소비 계층). 골드는 실버의 정제 데이터를 특정 비즈니스 목적에 맞게 집계·모델링한 '소비 준비 완료(business-ready)' 데이터를 담는 최상위 계층이다. 전형적으로는 BI 도구가 빠르게 조회할 수 있도록 사전 집계된 지표(일별 매출·KPI), 분석 친화적인 차원 모델(스타 스키마의 팩트·디멘션 테이블), 혹은 ML 모델이 바로 학습에 쓸 수 있는 피처 테이블 형태로 구성된다. 골드의 설계 목표는 읽기 성능과 사용 편의성이므로, 조인을 미리 수행해 비정규화(denormalization)하고 자주 쓰는 집계를 물리화(materialize)하는 전략을 쓴다.

골드를 용도별로 여러 개 두는 것이 일반적이라는 점도 중요하다. 재무팀의 '월별 손익 마트', 마케팅팀의 '캠페인 성과 마트', 데이터과학팀의 '이탈 예측 피처셋'은 모두 동일한 실버에서 파생된 서로 다른 골드다. 이렇게 하면 부서별 요구를 독립적으로 수용하면서도, 근본 데이터는 실버라는 단일 기반을 공유하므로 수치 불일치가 방지된다. 아래 표는 세 계층의 특성을 비교한 것이다.

구분	브론즈(Bronze)	실버(Silver)	골드(Gold)
데이터 상태	원천 그대로(raw)	정제·통합(cleansed)	집계·모델링(curated)
주요 변환	적재·메타데이터 부착	중복제거·표준화·조인	집계·차원모델·비정규화
스키마	원천 스키마/느슨	정형·강제	비즈니스 지향
주 소비자	데이터 엔지니어	ML 엔지니어·분석가	BI·경영진·현업
적재 방식	append-only	upsert/merge	overwrite/집계
품질 수준	낮음(보존 우선)	중간(신뢰 기반)	높음(완성형)

4. 구현 기술과 운영 패턴

메달리온 아키텍처는 개념적 패턴이므로 특정 제품에 종속되지 않지만, 실무 구현에는 오픈 테이블 포맷(open table format) 이 핵심 역할을 한다. Delta Lake·Apache Iceberg·Apache Hudi 같은 포맷은 오브젝트 스토리지 위에서 ACID 트랜잭션·스키마 진화(schema evolution)·시점 조회(time travel)·업서트(MERGE)를 제공하여, 각 계층 테이블을 신뢰성 있게 갱신할 수 있게 한다. 예컨대 실버 계층에서 변경 데이터만 반영하는 MERGE INTO(upsert) 연산은 Delta Lake의 ACID 보장 없이는 안전하게 수행하기 어렵다. 전형적인 구현 스택은 다음 요소로 구성된다.

• 저장·포맷 계층: 오브젝트 스토리지(S3·ADLS·GCS) + 오픈 테이블 포맷(Delta·Iceberg·Hudi).
• 처리 엔진: Spark·Flink·Trino 등 분산 처리 엔진과 SQL 변환 도구(dbt).
• 수집·증분: CDC 커넥터, 스트리밍 적재(Auto Loader·Kafka), 선언형 파이프라인(Delta Live Tables).
• 품질·검증: Great Expectations·DLT expectations 등으로 계층 전이 게이트 구현.
• 거버넌스·카탈로그: Unity Catalog·OneLake·오픈 카탈로그로 계보·권한·감사를 중앙 관리.

데이터 흐름의 효율을 위해서는 증분 처리(incremental processing) 가 필수다. 매번 전체 데이터를 재처리하면 비용과 지연이 폭증하므로, 변경분만 하위 계층으로 흘려보내는 CDC(Change Data Capture) 와 스트리밍 적재(예: Spark Structured Streaming의 Auto Loader)를 결합한다. 이때 각 계층을 스트리밍으로 연결하면 배치와 실시간을 단일 코드로 처리하는 람다를 넘어선 통합 파이프라인을 구성할 수 있다. 품질 규율을 코드로 강제하기 위해 Delta Live Tables·dbt의 테스트, Great Expectations 같은 데이터 품질 프레임워크의 기대값(expectation) 을 계층 전이 시점에 적용하여, 불량 데이터가 승격되지 못하도록 게이트를 둔다.

운영 관점에서는 각 계층의 물리적 최적화도 중요하다. 브론즈는 작은 파일이 다수 생성되는 경향이 있어 조회 성능이 저하되므로, 주기적으로 작은 파일을 병합하는 컴팩션(compaction) 과 질의 패턴에 맞춘 파티셔닝·클러스터링(예: Z-Order·Liquid Clustering) 을 적용한다. 또한 브론즈는 저장 비용 최적화를 위해 보존 주기를 정하고 오래된 버전을 정리(vacuum)하는 반면, 골드는 자주 조회되므로 캐시·물리화 뷰로 응답 속도를 높인다. 이처럼 계층마다 상반된 최적화 목표(브론즈=보존·비용, 골드=성능) 를 갖는다는 점이 메달리온 운영의 핵심 설계 포인트다.

비교: 전통적 ETL/DW와의 차이. 전통적 DW는 수집 전에 스키마를 확정하고 ETL로 정제한 뒤에야 적재하는 schema-on-write였다. 이 방식은 원본을 버리므로 요구 변경 시 재처리가 어렵고, 비정형 데이터를 담지 못한다. 반면 메달리온은 ELT(먼저 적재 후 변환) 철학을 따라 원본(브론즈)을 먼저 보존하고 변환을 계층적으로 지연·분산시킨다. 그 결과 유연성(재처리·신규 요구 수용) 과 확장성(저비용 스토리지) 에서 우위를 가진다. 다만 계층이 많아 스토리지 중복과 지연이 발생하는 트레이드오프가 있다.

비교: 데이터 메시(Data Mesh)와의 관계. 메달리온이 하나의 레이크하우스 '내부'의 수직적 정제 흐름을 규정하는 기술적 패턴이라면, 데이터 메시는 도메인별 팀이 데이터를 '제품(data product)'으로 소유·공급하는 조직적·거버넌스 패러다임이다. 둘은 경쟁 관계가 아니라 보완적이다. 실무에서는 각 도메인 팀이 자기 데이터 제품을 내부적으로 메달리온 구조(브론즈→실버→골드)로 구현하는 방식으로 결합되곤 한다.

비교: 람다(Lambda) 아키텍처와의 차이. 과거 실시간 분석은 배치 레이어와 스피드 레이어를 별도로 운영하고 서빙 단계에서 병합하는 람다 아키텍처로 구현되었는데, 이는 동일 로직을 배치·스트리밍 두 코드베이스로 중복 유지해야 하는 부담이 컸다. 메달리온은 오픈 테이블 포맷의 ACID와 스트리밍 테이블을 활용해 하나의 계층 파이프라인에 배치와 증분 스트리밍을 통합함으로써, 코드 이중화를 제거하고 동일한 정제 규칙을 양쪽에 일관되게 적용한다. 이는 '카파(Kappa) 지향'의 단일 파이프라인 철학에 가깝다.

구체 사례(정량적). 글로벌 소매 기업의 수요예측 파이프라인을 예로 들면, 수백 개 매장의 POS 거래 로그(일 수억 건)와 날씨·프로모션 데이터가 브론즈에 그대로 적재된다. 실버에서는 결제 취소·환불을 상계하고 상품코드를 표준 분류체계로 매핑하며 매장 마스터와 조인하여 '정규화된 일별 판매 사실'을 구축한다. 골드에서는 이를 SKU×매장×주 단위로 집계한 피처 테이블을 만들어 수요예측 모델에 공급한다. 이 구조를 도입한 조직들은 전처리 코드 중복 제거와 증분 처리로 일일 파이프라인 처리 시간과 재처리 비용을 수십 % 단축하고, 실버라는 단일 기반 덕분에 재무·물류 부서가 동일한 판매 수치를 공유하게 되었다고 보고한다(구체 수치는 조직·환경에 따라 달라지므로 일반화된 경향으로 이해해야 한다).

5. 심화: 최신 동향과 안티패턴

최근 메달리온 아키텍처는 거버넌스·자동화·실시간의 세 축으로 진화하고 있다. 첫째, Databricks의 Unity Catalog나 Microsoft Fabric의 OneLake처럼 통합 카탈로그·거버넌스 계층이 결합되어, 계층 간 데이터 계보(lineage)·접근 통제·감사가 중앙에서 관리된다. 과거에는 브론즈/실버/골드가 단순한 폴더 관례였다면, 이제는 카탈로그가 각 계층 테이블의 소유자·품질·활용을 메타데이터로 추적한다. 둘째, Delta Live Tables(DLT)처럼 선언형 파이프라인으로 계층 간 변환을 코드가 아닌 선언으로 정의하고, 품질 기대값·의존성·증분 처리를 프레임워크가 자동 관리하는 방향이다. 셋째, 스트리밍 테이블을 계층마다 연결해 수집부터 골드까지 준실시간(near real-time) 으로 흐르게 하는 '스트리밍 메달리온'이 보편화되고 있다.

반대로 실무에서 자주 발생하는 안티패턴도 명확히 인식해야 한다. 아래는 현장에서 반복적으로 관찰되는 대표적 실패 유형이다.

• 과도한 브론즈 가공. 수집 단계에서 클렌징·변환을 수행해 원본을 소실시키면, 로직 변경 시 재처리가 불가능해져 메달리온의 핵심 이점인 리플레이 능력을 잃는다.
• 실버 생략(브론즈→골드 직행). 정제·통합 계층을 건너뛰면 품질 게이트가 사라지고, 각 골드가 제각기 원시 데이터를 해석해 수치 불일치가 재발한다.
• 이름뿐인 계층화. 계층별 책임·품질 기준(SLA)·소유자를 문서화·강제하지 않으면, 폴더만 셋으로 나뉜 또 다른 데이터 늪이 된다.
• 규모 무시한 교조적 3계층. 소규모·단순 데이터에까지 세 계층을 기계적으로 적용하면 불필요한 복제·지연·비용만 늘어난다. 데이터 규모와 조직 성숙도에 맞춘 계층 수 조정이 권장된다.
• 품질 실패 데이터의 무단 폐기. 검증 실패 레코드를 격리 없이 버리면 원인 추적과 보정이 불가능해지므로, 반드시 격리 테이블로 분리·보존해야 한다.

6. 고려사항 및 시사점

메달리온 아키텍처는 단순한 폴더 구획이 아니라, 데이터 품질과 거버넌스를 흐름의 규율로 제도화하는 전략이다. 기술사 관점에서 도입을 검토할 때는 다음을 종합적으로 판단해야 한다.

• 적용 전략(계층 설계의 유연성). 세 계층을 교조적으로 강제하기보다, 데이터 특성과 활용 목적에 맞게 계층 수·명칭을 조정해야 한다. 원시 파일 착지용 Landing을 추가하거나, 골드를 BI용·ML용으로 분할하는 등 조직의 요구를 반영한 맞춤형 설계가 핵심이다. 소규모·단순 데이터에는 2계층으로 축소하는 판단도 필요하다.

• 트레이드오프(품질 vs 비용·지연). 계층을 많이 둘수록 재처리 유연성과 품질 통제력은 높아지지만, 동일 데이터가 계층마다 복제되어 스토리지 비용과 종단 지연(latency) 이 증가한다. 증분 처리·스트리밍으로 지연을 줄이고, 브론즈의 보존 주기(retention)·압축(compaction)·파일 최적화로 비용을 관리하는 운영 설계가 병행되어야 한다.

• 전망(거버넌스와의 통합). 향후 메달리온은 단독 패턴이 아니라 데이터 카탈로그·계보·접근통제·데이터 품질 자동화와 결합된 거버넌스 체계의 일부로 자리 잡을 것이다. 통합 카탈로그가 각 계층의 신뢰 수준을 메타데이터로 보증하면, 소비자는 "이 테이블이 어느 계층의 어떤 검증을 거쳤는가"를 신뢰 근거로 삼을 수 있다.

• 연계 기술(테이블 포맷·CDC·품질 프레임워크). 메달리온의 실효성은 ACID를 보장하는 오픈 테이블 포맷(Delta·Iceberg·Hudi), 증분을 가능하게 하는 CDC·스트리밍, 그리고 계층 전이 게이트로서의 데이터 품질 프레임워크가 함께 갖춰질 때 발휘된다. 이들 없이 계층만 나누면 패턴의 핵심 이점이 사라진다.

• 운영·관측(Observability). 계층 간 전이의 성공·실패, 품질 지표(결측률·중복률), 종단 지연, 데이터 신선도(freshness)를 상시 모니터링하고 SLA 위반 시 경보하는 체계가 필요하다. 격리 테이블의 적재량 추세는 원천 품질 저하를 조기에 감지하는 신호로 활용할 수 있다.

• 조직·거버넌스 관점. 계층의 책임 주체와 품질 기준(SLA)을 명문화하고, 데이터 메시의 도메인 소유권 개념과 결합하여 각 계층 데이터 제품의 소유자·품질·활용 규칙을 정의해야 한다. 기술 패턴만으로는 데이터 늪을 막을 수 없으며, 조직적 합의와 운영 규율이 성패를 좌우한다.

참고자료

• OneLake medallion lakehouse architecture (Microsoft Learn): https://learn.microsoft.com/fabric/onelake/onelake-medallion-lakehouse-architecture
• Describe medallion architecture (Microsoft Learn): https://learn.microsoft.com/training/modules/describe-medallion-architecture/2-describe-medallion-architecture
• Demystifying the Medallion: Practical Insights into the Layers (O'Reilly): https://www.oreilly.com/library/view/building-medallion-architectures/9781098178826/ch02.html

---

한 줄 요약: 메달리온 아키텍처는 레이크하우스의 데이터를 브론즈(원천 보존)·실버(정제·통합)·골드(집계·소비)의 계층으로 점진적으로 정제하여, 원본의 재처리 유연성과 소비 데이터의 신뢰성을 동시에 확보하는 다단계 데이터 설계 패턴이다.