메달리온 아키텍처란? 브론즈·실버·골드 레이어 완전 해설

메달리온 아키텍처 vs. 전통적 ETL 파이프라인

전통적인 데이터 웨어하우스의 추출-변환-적재(ETL) 파이프라인에서는 데이터 스키마를 사전에 정의해야 합니다. 데이터 형식이나 스키마가 바뀌면, 수동으로 조정하지 않는 한 시스템은 실패합니다. 

메달리온 기반 추출-적재-변환(ELT) 아키텍처에서는 데이터를 즉시 변환해 최종본만 저장하는 대신, 먼저 원시 형태 그대로 저장합니다. 이 차이는 메달리온 기반 아키텍처를 견고하면서도 유연하게 만듭니다. 원시 데이터를 있는 그대로 보관하고, 이후 활용 방식을 결정할 수 있습니다. 

두 개념을 자세히 비교하려면 ETL vs ELT 가이드를 읽어보시길 권합니다.

메달리온 아키텍처의 또 다른 장점은 플랫폼 중립적이라는 점입니다. 브론즈, 실버, 골드는 특정 벤더 기술에 묶인 것이 아니라 논리적 단계입니다. 데이터 플랫폼과 워크로드 요구사항에 따라 서로 다른 스토리지 시스템, 처리 엔진, 테이블 포맷으로 이 패턴을 구현할 수 있습니다.

메달리온 아키텍처의 브론즈, 실버, 골드 레이어는 어떻게 작동하나요?

세 개의 메달리온 레이어는 논리적으로 이어지며, 각 단계가 이전 단계를 기반으로 구축됩니다.

브론즈 레이어: 복구 지점으로서의 원시 데이터

관계형 데이터베이스, Salesforce 같은 SaaS 애플리케이션, 실시간 이벤트를 운반하는 Kafka 토픽, REST API, CSV 내보내기, IoT 디바이스 스트림 등 원시 데이터가 있는 그대로 도착하는 곳입니다. 적재는 보통 변경 데이터 캡처를 위한 Fivetran이나 오브젝트 스토리지에 도착하는 파일을 위한 Databricks Auto Loader 같은 도구로 처리됩니다.

브론즈 데이터에는 보통 오류, 불일치, 중복이 많이 포함되어 있으므로 비즈니스 목적으로 직접 사용해서는 안 됩니다. 그렇다고 해도, 이 레이어는 복구 지점으로서 매우 가치가 있으며, 여기서 실버나 골드 데이터를 다시 생성할 수 있습니다.

이 레이어의 중요성은 기록 범위에 있습니다. 모든 적재 이벤트나 트랜잭션을 기록하고 로깅합니다. 적재 타임스탬프, 데이터 출처, 다양한 식별자 등 유용한 메타데이터를 자주 포함합니다. 목표는 가능한 한 원시이면서 완전하게 데이터를 저장해, 동일한 소스 데이터로 하류 파이프라인을 재생하며 버그를 디버그할 수 있도록 하는 것입니다.

실버 레이어: 계약 레이어

실버 레이어는 원시 데이터를 정제되고 구조화된 데이터로 변환합니다. 브론즈에서 실버로 이동하며 수행되는 중요한 정제 변환의 예시는 다음과 같습니다.

• 불필요한 열 필터링
• 레코드 중복 제거
• 불일치 수정
• 결측값 처리
• 데이터 표준화
• 여러 데이터셋 조인 및 병합

또한 이 레이어에서는 스키마 강제가 이루어져, 데이터가 사전 정의된 구조를 충족하고 스키마 진화를 지원하도록 합니다. 

데이터 품질 점검도 여기서 수행합니다. 예를 들어, 실패한 비즈니스 트랜잭션이나 이상치를 표시하거나 거부하는 규칙을 추가합니다. 이는 데이터가 단계를 거치며 품질을 개선하는 첫 단계입니다.

이 단계에서는 데이터가 수정되므로, 데이터 라인리지 도구인 dbt 등을 사용해 브론즈에서 실버로 데이터가 어떻게 변환되는지 추적하는 것이 중요합니다. 품질 검사는 일반적으로 dbt 테스트, Great Expectations, Soda로 구현하고, 거버넌스는 데이터 카탈로그(예: Databricks Unity Catalog 또는 Collibra)를 통해 적용합니다.

지저분한 데이터를 올바른 실버 데이터셋으로 바꾸는 방법을 배우고 싶다면 Cleaning Data in Python 코스부터 시작해 보세요.

골드 레이어: 비즈니스 준비 완료 출력

아키텍처의 마지막 레이어는 가능한 최고 품질로 데이터를 저장합니다. 이 고도로 정제된 데이터는 Power BI, Tableau, Looker에서의 비즈니스 보고에 사용되거나, 하류 분석 애플리케이션에서 소비되거나, Feast나 Databricks Feature Store 같은 피처 스토어를 통해 머신러닝 모델에 제공됩니다.

이미 데이터가 정제되어 있으므로, 이 단계는 데이터를 가치 있는 비즈니스 자산으로 바꾸는 데 초점을 맞춥니다. 구체적 사용 사례(재무 보고, 마케팅 대시보드, 알림 시스템, ML 모델 학습 등)에 따라, 실버 이후의 변환은 골드가 당면한 작업에 필요한 정보만 정확히 담도록 보장합니다.

이 단계에서는 KPI를 만들고, 맞춤 비즈니스 공식을 적용하거나, 집계하여 정기 보고용 주간/월간/분기 데이터로 만듭니다. 브론즈와 실버의 작업이 흔히 공통적인 반면, 골드 레이어의 작업은 이 데이터를 어떻게 활용할지에 따라 더 유연하고 맞춤화됩니다.

브론즈 데이터에서 실버와 골드를 어떻게 재구축하나요?

브론즈에 원시 데이터를 보존하는 것이 실제로 가치 있으려면, 무언가 상류나 하류에서 바뀌었을 때 이를 활용할 수 있어야 합니다. 변경 비용은 체인의 어느 지점에서 발생했는지에 따라 달라집니다. 

• 소스 스키마가 바뀌면 브론즈를 실버와 골드까지 모두 재생해야 합니다. 
• 비즈니스 정의 변경(예: 새로운 매출 규칙, 다른 집계 윈도우)은 이미 검증된 실버에서 골드만 재구축하면 됩니다.

어느 경우든 소스 시스템으로 돌아가지는 않습니다. 이는 과거 정정을 가능하게 하는 핵심으로, 소스가 원래 적재했던 형태로 더 이상 데이터를 보유하지 않을 수 있기 때문입니다. 

또한 지표 정의를 바꾸더라도 적재를 다시 실행할 필요가 없다는 의미이기도 하며, 이는 골드 소비자가 많은 팀이 레이어를 분리하는 실질적 이유입니다.

메달리온 아키텍처는 데이터 레이크하우스에서 어디에 맞나요?

데이터 레이크하우스는 데이터 레이크의 저렴한 오브젝트 스토리지에 웨어하우스의 트랜잭션 보장을 더해줍니다. 단, 내부의 테이블을 어떻게 배치할지는 규정하지 않습니다. 이 공백을 메달리온이 채웁니다. 레이크하우스가 저장 기반이라면, 브론즈·실버·골드는 이를 서로 다른 품질 보장을 갖는 카탈로그, 스키마, 테이블로 나누는 방식입니다.

실무에서는 이 구분이 보통 물리적입니다. Databricks에서는 Unity Catalog의 하나의 카탈로그 안에 세 개의 스키마를 둘 수 있고, Microsoft Fabric에서는 브론즈와 실버 테이블이 골드 웨어하우스를 공급하는 레이크하우스를 둘 수 있습니다. 패턴은 같고 배관만 다릅니다.

오픈 테이블 포맷은 동시 읽기/쓰기를 견디게 하는 핵심입니다. Delta Lake, Apache Iceberg, Apache Hudi는 각각 다음의 일부 혹은 전부를 제공합니다.

• ACID 트랜잭션
• 스키마 진화
• 버전이 있는 테이블 상태
• 동시성 제어
• 파티션 진화
• 타임 트래블

방금 다룬 재생 동작에서 버전 관리는 특히 중요합니다. 원시 Parquet 파일은 소스 데이터를 잘 보존하지만, 롤백할 트랜잭션 히스토리를 제공하지 않기 때문에, 잘못된 실버 실행이 좋은 실행을 덮어쓰면 비교할 대상이 없습니다. Delta Lake는 트랜잭션 로그로 변경 사항을 추적하고, Apache Iceberg는 스냅샷으로 테이블 상태를 나타냅니다.

이 모든 것이 필수는 아닙니다. 메달리온은 논리적 패턴이며, 많은 팀이 Postgres 스키마나 평이한 S3 프리픽스 위에 dbt를 얹어 운영합니다. 다만 저렴한 롤백을 잃게 됩니다.

메달리온 아키텍처 vs 데이터 메쉬

두 개념은 자주 비교되는데, 대개 서로 경쟁한다고 가정하기 때문입니다. 그러나 두 개념은 서로 다른 질문에 답합니다. 데이터 메쉬는 누가 데이터를 소유하는지 결정하고, 메달리온 아키텍처는 그 소유자가 데이터를 어떻게 정제하는지를 결정합니다.

데이터 메쉬는 판매, 재무, 공급망 같은 도메인 팀에 데이터 책임을 부여합니다. 이들은 데이터를 제품으로 게시하고, 품질, 검색 용이성, 라인리지, 거버넌스를 소유합니다. 이를 지탱하는 두 축은 모든 도메인에 동일한 도구를 제공하는 셀프서비스 인프라와, 도메인의 소유권을 빼앗지 않으면서 조직 차원의 표준을 설정하는 연합 거버넌스입니다.

메달리온 아키텍처는 각 도메인 팀이 자기 구획 안에서 운영하는 방식입니다. 예컨대 공급망 팀이 선적 데이터를 소유한다면, 원시 선적 이벤트는 브론즈에, 검증된 레코드는 실버에 보관하고, 다른 도메인이 소비할 수 있도록 분석 준비가 된 선적 데이터셋을 골드로 게시합니다. 메쉬는 골드 경계에서의 계약을 정의하고, 그 상류는 해당 팀의 고유 영역입니다.

둘을 결합하기 전에 한 가지 주의할 점: 도메인별 브론즈 레이어는 각 도메인이 적재와 저장 비용을 자체 부담한다는 뜻이며, 고객이나 제품 같은 공통 차원이 세 곳에서 각각 재구축되는 경향이 있습니다. 메쉬 옹호자들은 그것이 소유권의 대가라고 말하겠지만, 여전히 실질적 비용이므로 도입 전에 비용을 산정할 가치가 있습니다.

메달리온 아키텍처의 이점과 한계는?

메달리온은 재사용성과 복구 가능성을 제공하는 대신, 저장소, 지연 시간, 파이프라인 수에 비용을 청구합니다. 이 교환이 유리한지는 거의 전적으로 소비자 수에 달려 있습니다.

지연 시간은 가장 과소평가되기 쉽습니다. 각 레이어는 보통 자체 스케줄 작업이므로, 시간당 실행되는 3계층 배치 파이프라인에서는 골드가 소스 시스템보다 두 시간 뒤처질 수 있습니다. 주간 매출 보고에는 문제가 없지만 운영 알림에는 적합하지 않습니다. 그래서 팀은 종종 알림이 골드를 기다리지 않고 실버를 직접 읽도록 합니다.

저장소는 사람들이 먼저 지적하는 비용이지만, 대개 더 작은 문제입니다. 브론즈는 저렴한 오브젝트 스토리지에 있고, 중복은 현실적이지만 한정적입니다. 실제로 아픈 곳은 파이프라인 수입니다. 20개의 소스 테이블에 3개 레이어라면, 새벽 3시에 잠재적으로 실패할 수 있는 항목이 60개입니다.

그에 비해 낮은 데이터 품질도 자체 비용이 있습니다. IBM은 2026년에 COO의 43%가 데이터 품질을 가장 중요한 데이터 우선순위로 꼽았다고 보고했습니다(자사 Institute for Business Value의 2025년 조사 기반). 그 연구에서 4분의 1이 넘는 조직이 데이터 품질 저하로 인한 연간 손실이 500만 달러를 초과한다고 답했습니다.

따라서 질문은 메달리온 아키텍처 구현이 단일 파이프라인보다 비용이 많이 드느냐가 아닙니다. 그렇다는 점은 분명합니다. 진짜 질문은, 대안으로 인한 조정 회의와 신뢰받지 못하는 대시보드에 이미 비용을 지불하고 있지는 않은가입니다.

메달리온 아키텍처를 언제 사용해야 하나요?

메달리온은 동일하게 정제된 데이터가 둘 이상의 소비자에게 제공될 때 진가를 발휘합니다. 데이터 볼륨, 팀 규모, 소스 수보다 이 변수가 가장 좋은 예측 지표입니다.

다음과 같은 경우 메달리온 아키텍처를 사용하세요:

• 여러 팀이나 워크로드가 동일한 데이터를 읽는 경우. 실버에서 한 번 정제·표준화한 뒤, BI/리포팅/모델 학습용으로 필요한 만큼 골드 데이터셋을 쌓으세요.
• 서로 다른 비즈니스 질문이 동일 데이터의 다른 모양을 요구하는 경우. 재무는 월별 인식 매출을, 영업은 담당자별 일일 예약을 원합니다. 둘 다 적재 로직을 중복하지 않고 하나의 실버 테이블에서 파생됩니다.
• 소스 간에 상충이 있는 경우. 실버에서 Salesforce의 계정 ID와 청구 시스템의 고객 ID를 조정해, 하류에서 누가 권위 있는지 추측할 필요가 없게 합니다.
• 숫자에 대해 책임을 져야 하는 경우. 원시·검증·큐레이션 데이터를 분리하면, 논쟁 중인 수치를 각 변환 단계를 거슬러 추적할 수 있고, 처음부터 재계산할 필요가 없습니다.
• 변환 로직이 자주 바뀌는 경우. 앞서 설명했듯, 보존된 브론즈 데이터가 소스로 돌아가지 않고도 재구축할 수 있게 해줍니다.

다음과 같은 경우는 건너뛰세요:

• 데이터 팀이 작고 파이프라인 복잡도가 낮습니다.
• 데이터가 하나의 소스에서 오고 정제·변환이 최소화됩니다.
• 하류 애플리케이션이나 팀이 하나뿐입니다.
• 리포팅 요구가 단순하여 여러 처리 레이어를 유지할 명분이 없습니다.

두 레이어로 충분할 때

3계층 다이어그램은 기본값일 뿐 필수 요건이 아닙니다. 단일 비즈니스 사용 사례라면, 브론즈와 단일 결합 레이어가 종종 최선입니다. 재생을 위해 원시 데이터를 보존하고, 정제와 비즈니스 로직을 한 단계에서 처리하세요.

소비자에 맞는 형태를 선택하세요. 합치지 말아야 할 것은 브론즈입니다. 브론즈는 다시 만들 수 없는 레이어이기 때문입니다.

애매하다면 두 레이어로 시작해, 두 번째 소비자가 나타날 때 세 번째를 추가하는 접근이 좋습니다. 수개월간 원시 데이터를 덮어써 온 뒤에 브론즈를 사후 추가하는 것보다, 나중에 골드를 추가하는 편이 훨씬 저렴합니다.

메달리온 구현에서 흔한 실수

대부분의 메달리온 문제는 아키텍처 자체의 문제가 아닙니다. 마감 압박 속에서 한 작은 타협이, 애초 레이어를 만든 이유를 조용히 무력화하는 데서 비롯됩니다.

브론즈에서의 데이터 변환

재생 논리는 브론즈가 소스가 실제로 보낸 것에 가까운 상태를 보유한다는 전제에 서 있습니다. 착지 전에 비즈니스 로직을 적용하면 원래 상태를 잃게 되며, 이는 재처리 불가와 감사 추적 상실을 의미합니다.

이는 보통 타당한 이유에서 벌어집니다. 공간 절약을 위해 아무도 쓰지 않는 열을 삭제하거나, 다음 작업을 깨뜨리는 지저분한 타임스탬프 필드를 적재 시 강제 변환합니다. 여섯 달 뒤, “아무도 안 쓰던” 열이 중요해지고, 원래 값은 사라졌습니다. 실무적으로 관리 가능한 한 브론즈는 소스에 최대한 가깝게 유지하고, 수정은 실버에서 하세요.

실버와 골드 경계의 흐림

실버는 정제와 표준화를 담당합니다. 골드는 비즈니스 질문에 답합니다. 지표 로직이 실버로 새어 들어가면, 모든 골드 데이터셋이 원치 않는 정의를 상속받게 되고, 메달리온이 해결하려던 문제로 되돌아갑니다.

판단 기준은 단순합니다. 비즈니스 사용자가 그 숫자를 두고 논쟁한다면, 그 로직은 골드에 있어야 합니다. 중복 제거는 실버의 관심사입니다. “활성 고객”의 정의는 아닙니다.

세 레이어를 의무로 여김

메달리온 아키텍처는 논리적 설계 패턴이지, 모든 파이프라인이 정확히 세 개의 물리적 레이어를 가져야 한다는 요구사항이 아닙니다. 브론즈·실버·골드는 데이터 정제의 논리적 단계를 나타내며, 각 레이어는 워크로드에 따라 다르게 구현될 수 있습니다. 

예를 들어, 별도의 물리적 복사본을 요구하지 않고도, 레이어는 머티리얼라이즈드 테이블, 뷰, 기타 적절한 추상화를 사용할 수 있습니다. 요점은 원시 상태에서 비즈니스가 신뢰하고 사용할 수 있는 상태로 이동할 때 의미 있는 경계를 만드는 것이지, 고전적인 3계층 다이어그램을 그대로 재현하는 것이 아닙니다. 

골드를 덤핑 구역으로 방치

가장 자주 보지만 가장 덜 논의되는 문제입니다. 골드 데이터셋은 만들기 쉽고, 아무도 삭제하지 않습니다. 1년 뒤에는 테이블이 마흔 개쯤 되고, 그중 열한 개는 월간 매출의 변주이며, CFO가 실제로 보는 것이 무엇인지 아무도 기억하지 못합니다.

실버는 역할이 분명해 자연스러운 규율이 생깁니다. 골드는 그렇지 않으므로, 데이터셋별 소유자와 삭제 의지가 필요합니다. 이것이 없으면 동일 지표의 경쟁 버전이 여럿 생기고, 이는 레이어가 예방하려던 문제 중 하나입니다.

마무리 생각

메달리온이 실제로 제공하는 것은, 누군가 숫자의 출처를 물을 때 가리킬 수 있는 위치와, 답이 틀렸다는 것이 드러났을 때 돌아갈 수 있는 원본 데이터 사본입니다. 여러 팀이 동일한 데이터를 읽는다면 추가 저장 공간과 추가 작업은 그만한 가치가 있습니다. 단 하나의 팀만 읽는다면, 두 레이어가 더 나은 해법일 수 있고 유지보수도 줄여줍니다.

이 패턴의 더 넓은 맥락을 알고 싶다면, Understanding Modern Data Architecture 코스가 현대 데이터 스택의 플랫폼과 기술을 다룹니다. Data Engineer 커리어 트랙은 생산 파이프라인을 구축하고 유지하는 과정까지 더 깊이 들어갑니다.