데이터 레이크(Data Lake)가 처음 등장했을 때, 우리는 모든 데이터를 한곳에 모으기만 하면 자연스럽게 가치가 만들어질 것이라고 기대했습니다. 하지만 현실은 조금 달랐습니다. 검증되지 않은 데이터가 무작정 쌓이면서 레이크는 금세 ‘데이터 늪(Data Swamp)’으로 변했고, 분석가는 “도대체 어떤 테이블을 믿어야 하지?”라는 질문부터 시작해야 했습니다.
이런 문제의식에서 등장한 개념이 메달리온 아키텍처(Medallion Architecture)입니다. 데이터의 품질과 목적에 따라 브론즈(Bronze) – 실버(Silver) – 골드(Gold) 3단계 레이어로 나누어 관리하는 방식입니다. 특정벤더에 맞는 프레임워크라기보다는, 데이터를 어떻게 흘리고, 어디에서 품질을 끌어올릴지에 대한 구조적 사고법에 가깝습니다.
이번 글에서는 메달리온 아키텍처의 각 레이어가 어떤 역할을 하는지, 그리고 파이프라인이 여러 번 재실행되어도 일관된 결과를 유지할 수 있도록 설계할 때 어떤 관점을 가져야 하는지까지 함께 정리해 보려고 합니다.
메달리온 아키텍처의 3단계 구조
메달리온 아키텍처는 데이터가 파이프라인을 통과할수록 품질과 용도가 점점 명확해지는 흐름을 전제로 합니다. 그 단계를 메달 색으로 표현한 것이 브론즈–실버–골드 레이어입니다.
1. 브론즈 레이어 (Bronze) — Raw / Source-aligned
역할
브론즈 레이어는 소스 시스템(DB, API, 로그, 이벤트 스트림 등)에서 가져온 데이터를 가능한 한 원본에 가깝게(As-is) 저장하는 구간입니다. 일단 들어온 것은 최대한 버리지 않고 받아둔다에 초점이 있습니다.
특징
•
스키마를 과하게 손보지 않고, 소스의 구조를 그대로 유지하려고 합니다.
•
보통 Append-only 형태로 파티션을 나누어 적재합니다. (예: ingested_at 일자 기준)
•
모든 히스토리를 보존하는 것을 원칙으로 하여, 나중에 다시 처리(Reprocess)할 때 기준점으로 사용합니다.
스키마 진화(Schema Evolution) 대응
브론즈 레이어의 중요한 역할 중 하나는 스키마 변화에 대한 완충층이 되어 주는 것입니다.
•
소스에 컬럼이 하나 추가되거나 이름이 바뀌었을 때
•
API 응답 JSON 구조가 살짝 달라졌을 때
이 변화에 바로 실패를 던지는 것이 아니라, 일단은 받아 둘 수 있는 유연함이 필요합니다.
예를 들어 전체 JSON을 문자열/JSON 컬럼으로 저장해 두고 실버에서 실제로 사용하는 필드를 점진적으로 파싱하는 방식을 사용하면, 소스가 조금씩 변해도 브론즈에서 받고 나서 생각할 수 있는 여유를 확보할 수 있습니다.
재실행 관점
브론즈는 몇 번을 다시 돌려도, 적어도 원본 히스토리가 망가지지 않는 구조여야 합니다.
•
같은 파일/배치를 다시 가져올 수 있다는 가정 하에
◦
파일명, 배치 ID, 이벤트 ID 등을 기준으로 중복 여부를 구분하거나
◦
아예 파티션 단위(DATE(ingested_at) 등)로 “해당 파티션은 항상 통째로 덮어쓴다”는 규칙을 둘 수 있습니다.
이렇게 설계해 두면, 상위 레이어에서 문제가 발생했을 때 소스 시스템을 다시 뒤흔들지 않고 브론즈부터 안정적으로 재실행이 가능합니다.
2. 실버 레이어 (Silver) — Cleansed & Conformed
역할
실버 레이어는 브론즈에서 가져온 데이터를 정제하고 정합성을 맞춘 뒤, 분석과 모델링에 바로 사용할 수 있는 신뢰 가능한 중간 레이어를 만드는 구간입니다. 이 테이블부터는 기본적인 품질은 보장되었다고 믿고 써도 된다는 기준선을 세우는 곳입니다.
특징
•
데이터 타입 변환, 중복 제거, 결측치 처리, 코드/포맷 표준화 등을 수행합니다.
•
도메인 공통 키(예: user_id, place_id)를 맞추고, Join이 용이한 구조로 재설계합니다.
•
도메인 주도 설계(DDD)에서 말하는 Ubiquitous Language(공통 언어)에 맞추어 컬럼명과 테이블 구조를 정리합니다.
•
너무 구체적인 비즈니스 로직을 모두 실버에 쌓기보다는, 어떤 팀이 가져다 써도 납득 가능한 수준의 정제/정합 레벨 정도에 초점을 둡니다.
데이터 품질 검사(Data Quality Gate)
실버에서 중요한 관점 하나는 브론즈에서 실버로 넘어갈 때 품질 게이트를 통과한다는 느낌입니다.
•
NOT NULL 제약이 필요한 필드(예: user_id, event_at)에 대해 결측 여부를 검사
•
UNIQUE/PRIMARY KEY 역할을 하는 조합에 대해 중복 여부 확인
•
값의 범위, 카테고리(validation list) 등 검증
•
스키마 수준(타입, 필수 컬럼) 검증
이런 검사를 통과하지 못한 레코드는 별도의 에러 테이블로 보낸다든지 is_valid=false 플래그를 달아 격리시킨다든지 하는 방식으로 관리할 수 있습니다.
중요한 점은, 실버 레이어에 도달한 데이터에 대해서는 최소한의 품질 기준을 조직적으로 합의해 두는 것입니다.
재실행 관점
실버 레이어는 가능하면 멱등(idempotent)하게 설계하는 것이 좋습니다.
•
같은 날짜/파티션을 다시 실행해도 결과가 중복으로 쌓이지 않아야 합니다.
•
이를 위해 보통 아래와 같은 전략을 사용합니다.
◦
identity_key + event_at 등 자연 키를 기준으로 MERGE / UPSERT
◦
특정 파티션(dt, event_date) 단위로 INSERT OVERWRITE 수행
이렇게 설계하는 이유는 멱등을 보장하기 위해 동일한 기간에 대해 같은 입력을 넣었을 때, 항상 같은 실버 결과가 나오도록 하는 것 입니다. 이 조건이 만족되면, 브론즈에서 버그를 수정하거나 새로운 컬럼을 추가했을 때 특정 구간만 선택적으로 다시 계산하는 운영이 매우 수월해집니다.
3. 골드 레이어 (Gold) — Curated & Business-level
역할
골드 레이어는 실제 비즈니스 의사결정과 지표, 리포팅, 모델링에 바로 쓰이는 최종 소비 레이어입니다.
•
경영진/프로덕트/마케팅이 보는 대시보드
•
추천/랭킹을 위한 피처 테이블
•
실험 분석용 지표 테이블
등이 여기에 포함됩니다.
특징
•
비즈니스 로직과 복잡한 집계(Aggregation)가 많이 녹아 있습니다.
•
스타 스키마(Star Schema) 형태의 Fact/Dimension 테이블로 구성되거나,
◦
실무에서는 OBT(One Big Table, 역정규화된 하나의 큰 테이블) 형태로 노출하는 경우도 많습니다.
◦
예: “일단 이 테이블 하나만 보면, 유저 단위/일 단위로 필요한 지표는 다 있다” 수준
•
BI 도구, 리포트, 실시간 서빙 등에 맞춰 쿼리 성능과 사용성이 최적화되어 있는 경우가 많습니다.
즉, 골드는 데이터 팀 내부의 작업용이 아니라 조직 전체에서 직접 소비되는 인터페이스에 가깝습니다.
재실행 관점
골드 레이어는 가능하면 재계산이 쉬운 함수처럼 다루는 것이 이상적입니다.
•
입력: 실버 레이어의 안정적인 테이블들
•
출력: 특정 기간/도메인에 대한 지표·마트 테이블
이 관계를 명확히 정의해두면:
•
“10월 1일~31일 MAU 정의가 바뀌었다”
•
“결제 취소 처리 로직이 잘못되어, 특정 기간만 다시 반영해야 한다”
와 같은 상황에서, 해당 구간 골드만 선택적으로 재실행하는 것이 자연스러운 작업이 됩니다.
보통은 다음과 같은 전략을 씁니다.
•
날짜 파티션 단위로 전체를 다시 계산해서 덮어쓴다
•
기준 버전(지표 정의 버전 등)을 컬럼으로 두고, 새 버전으로 다시 쌓는다
중요한 것은, 골드를 손대기 무서운 덩어리”로 만들지 않고 언제든 다시 계산할 수 있는 결과물로 두는 것입니다.
메달리온을 적용하는 이유
굳이 데이터를 세 단계나 나누어서 저장하고 가공하는 이유는 크게 네 가지 정도로 정리할 수 있습니다.
1. 데이터 품질 기준을 단계별로 분리
•
브론즈: “일단 뭐가 들어왔는지 전부 보존한다”
•
실버: “이 레벨부터는 기본적인 정합성과 품질을 보장한다”
•
골드: “이 레벨의 지표/마트는 비즈니스 의사결정에 그대로 사용해도 된다”
이렇게 품질의 기준선을 단계별로 명확히 나누어 두면,
“이 분석에 어떤 테이블을 써야 하느냐”에 대한 논쟁과 혼란이 줄어듭니다.
2. 재처리·재실행을 전제로 한 설계
현실에서는 다음과 같은 일이 계속 발생합니다.
•
소스 스키마가 바뀐다
•
비즈니스 로직(지표 정의)이 변경된다
•
ETL 코드에 버그가 있었다는 것이 뒤늦게 발견된다
이때 메달리온 구조는 언제든 다시 말아 올릴 수 있다는 전제를 두고 설계할 수 있게 해 줍니다.
•
브론즈에서 원본을 다시 읽고
•
실버에서 멱등 로직으로 정합성을 맞추고
•
골드에서 필요한 구간만 재계산
이 흐름이 자연스럽게 자리 잡습니다.
3. 역할과 책임 분리
레이어를 나누면, 자연스럽게 역할이 분리됩니다.
•
브론즈/실버 구간
◦
데이터 엔지니어링/플랫폼 팀이 책임
◦
수집/정제/정합성/품질 게이트/멱등성에 집중
•
골드 구간
◦
애널리틱스 엔지니어, 데이터 분석가, 데이터 사이언티스트가 책임
◦
도메인 지표 정의, 집계 로직, 리포팅 구조에 집중
이렇게 되면 지표가 이상한데, 이게 ETL 버그인지 지표 정의 문제인지를 추적하는 과정도 훨씬 수월해집니다.
4. 스키마 변화와 삭제·누락에 대한 방어선
•
브론즈는 스키마 진화와 원본 보존 관점의 방어선입니다.
•
실버는 데이터 품질(Data Quality Gate) 관점의 방어선입니다.
•
골드는 비즈니스 해석과 지표 안정성 관점의 방어선입니다.
각 레이어가 이런 역할을 분담하면, 휘발성 이벤트, 스키마 변경, 삭제/누락 데이터에 대한 대응 전략을 레이어별로 다르게 설계할 수 있습니다.
마무리
메달리온 아키텍처는 Databricks에서만 쓰는 개념이 아니라, 어떤 스택을 쓰고 있더라도 데이터 흐름을 설계할 때 가져갈 수 있는 사고의 틀에 가깝습니다. Databricks를 쓰든 BigQuery + dbt 조합을 쓰든 S3 + Airflow 기반의 레이크를 운영하든 브론즈–실버–골드라는 관점으로 파이프라인을 나눠 보는 것만으로도, 어디에서 품질을 끌어올리고, 어디까지는 원본을 그대로 두며, 어디에서 비즈니스 지표로 굳히는지가 훨씬 명확해집니다.
결국 이 아키텍처의 핵심은 데이터가 어디서 와서 어떻게 정제되는지를 투명하게 보여주는 약속을 만드는 데 있습니다. 브론즈는 원본 데이터의 유실을 막는 안전망이 되고, 실버는 신뢰할 수 있는 품질의 기준선이 되며, 골드는 비즈니스에 직결되는 가치를 제공합니다.
파이프라인이 여러 번 재실행되더라도, 각 레이어의 의미와 결과가 깨지지 않도록 설계하는 것이 메달리온 아키텍처를 실질적으로 잘 운영하는 핵심이라고 생각합니다.