나는 메달리온이 싫습니다

요즘 데이터 플랫폼 이야기를 하면 거의 자동으로 따라오는 단어가 있습니다. 바로 Bronze, Silver, Gold로 이어지는 메달리온 아키텍처입니다. 여전히 많이 쓰이고, 특히 Databricks 생태계에서는 사실상 기본값처럼 취급되기도 합니다.

그런데 저는 이 구조를 기본값처럼 받아들이는 분위기를 꽤 불편하게 봅니다. 조금 더 직설적으로 말하면, 저는 메달리온이 싫습니다.

물론 여기서 말하는 싫음은 “절대 쓰면 안 된다”는 뜻은 아닙니다. 반쯤은 농담에 가깝습니다. 특정 상황에서는 분명 유효합니다. 다만 너무 많은 팀이 이 구조를 문제 해결의 결과가 아니라 출발점으로 삼고 있다는 점이 문제라고 생각합니다.

메달리온은 좋은 답이 아니라 좋은 마케팅이었던 경우가 많습니다

메달리온 아키텍처는 설명하기 쉽습니다.

• Bronze는 원본 적재
• Silver는 정제와 표준화
• Gold는 비즈니스용 가공

이렇게만 들으면 굉장히 그럴듯합니다. 각 계층의 역할도 명확해 보이고, 운영도 체계적으로 느껴집니다. 하지만 실제 현장에서는 이 단순한 설명이 오히려 함정이 됩니다.

많은 팀이 이 구조를 도입한 뒤 각 레이어에 데이터를 “왜” 둬야 하는지보다, “일단 세 레이어를 다 채워야 한다”는 식으로 움직입니다. 그러면 구조는 생기지만 설계는 사라집니다. 제가 메달리온을 싫다고 말하는 이유도 사실 메달리온 자체보다 이런 사용 방식에 더 가깝습니다.

데이터 엔지니어링에서 중요한 것은 계층 이름이 아니라, 데이터 계약이 어디서 성립하는지, 품질 검증이 어디서 강제되는지, 소비자 요구사항이 어디서 갈라지는지입니다. 그런데 메달리온은 종종 이 질문들을 가린 채 레이어 이름만 남깁니다.

제가 메달리온을 싫어하는 진짜 이유는 과잉 복제와 책임 분산입니다

메달리온 구조를 만들면 보통 데이터가 최소 세 번 저장됩니다. 원본 한 번, 정제본 한 번, 소비용 집계본 한 번입니다. 이게 늘 문제는 아닙니다. 저장소 비용이 예전보다 싸진 것도 맞습니다.

하지만 실제 비용은 스토리지 비용표에만 있지 않습니다.

• 레이어마다 파이프라인이 하나씩 더 생깁니다.
• 레이어마다 스키마 변경 영향도를 따로 봐야 합니다.
• 레이어마다 모니터링 포인트가 늘어납니다.
• 레이어마다 장애 원인 파악 시간이 길어집니다.

결국 데이터가 세 층으로 나뉜 것이 아니라, 책임이 세 층으로 흩어진 경우가 많습니다.

제가 여러 팀에서 본 문제는 비슷했습니다. Bronze는 아무거나 받는 구역이 되고, Silver는 애매하게 정리된 공용 구역이 되고, Gold는 팀마다 제각각 만들어놓은 소비 테이블 집합이 됩니다. 시간이 지나면 “진실의 원천”이 어디인지 오히려 더 불분명해집니다.

Silver는 특히 자주 실패합니다

현실에서 가장 애매한 레이어는 Silver입니다.

이론상 Silver는 정제되고 검증된 공용 데이터입니다. 그런데 실제로는 가장 많은 논쟁이 몰리는 지점입니다.

• 어디까지 정제를 Silver에서 할지
• 비즈니스 로직을 Silver에 넣을지
• 도메인별로 Silver를 나눌지
• 소비자별 요구사항 충돌을 어떻게 처리할지

이 질문들에 명확한 운영 원칙이 없으면 Silver는 “다들 조금씩 손대는 커다란 중간 테이블”이 됩니다. 그러면 Gold는 Silver를 믿지 못해서 다시 가공하고, 결국 레이어를 나눈 의미가 약해집니다.

데이터 엔지니어 관점에서 보면, 중간 레이어는 많다고 좋은 것이 아닙니다. 재사용성이 높고 계약이 분명한 중간 산출물만 가치가 있습니다. 애매한 공용 레이어는 재사용 자산이 아니라 혼란의 축적물에 가깝습니다.

dbt를 쓰는 팀이라면 메달리온을 억지로 흉내 낼 이유가 없습니다

요즘 많은 팀은 warehouse 중심으로 움직이고, 변환은 dbt가 맡습니다. 이 환경에서는 staging / intermediate / marts 구조가 훨씬 자연스러운 경우가 많습니다.

이 구조의 장점은 이름보다 의도가 더 직접적이라는 점입니다.

• staging은 소스 정합성 확보
• intermediate는 재사용 가능한 변환 로직
• marts는 소비 목적별 산출물

즉, 저장 계층 중심 사고보다 모델링 중심 사고에 가깝습니다. 데이터 엔지니어 입장에서 이 차이는 큽니다. 메달리온은 저장 위치를 기준으로 사고하게 만들고, dbt 스타일 구조는 변환 책임을 기준으로 사고하게 만듭니다.

저는 후자가 더 운영 친화적이라고 봅니다.

메달리온이 맞는 조직도 분명 있습니다

그렇다고 메달리온을 무조건 버리자는 이야기는 아닙니다. 이 부분은 분명히 짚고 넘어가야 합니다.

예를 들어 아래 같은 조직에서는 메달리온이 꽤 잘 맞습니다.

• Databricks를 중심으로 플랫폼을 운영하는 경우
• 원본 재처리가 자주 필요한 경우
• 규제나 감사 요구사항이 강한 경우
• 데이터 소스와 소비자가 모두 많은 경우
• 여러 팀이 같은 정제 레이어를 공유해야 하는 경우

이런 환경에서는 Bronze의 원본 보존 가치가 분명하고, Silver의 공용 정제층도 실제 재사용성을 가질 수 있습니다. Gold 역시 부서별 소비 모델로 자연스럽게 분화됩니다.

문제는 이런 조건이 없는 팀까지 메달리온을 따라 한다는 점입니다.

작은 팀에게 메달리온은 종종 너무 비쌉니다

팀 규모가 작고, 데이터 소스도 몇 개 안 되고, 대부분의 변환이 SQL 기반 분석 모델이라면 메달리온은 높은 확률로 과합니다.

이 경우에는 보통 아래 질문부터 해야 합니다.

• 원본을 정말 장기간 별도 보존해야 하는가
• 재처리가 실제로 얼마나 자주 발생하는가
• 공용 정제층이 여러 소비자에게 실제로 재사용되는가
• 운영 인력이 이 복잡도를 감당할 수 있는가

이 질문에 선명한 “예”가 없다면, 메달리온은 아키텍처라기보다 미래 불안을 위한 보험 상품에 가깝습니다. 그리고 대부분의 작은 팀은 그 보험료를 운영 복잡도로 지불합니다.

데이터 엔지니어링은 구조보다 계약이 먼저입니다

제가 메달리온을 싫어하는 가장 큰 이유는, 많은 팀이 레이어를 먼저 만들고 계약을 나중에 생각하기 때문입니다.

하지만 좋은 데이터 플랫폼은 반대로 만들어야 합니다.

먼저 정해야 하는 것은 이런 것들입니다.

• 어떤 데이터가 신뢰 가능한가
• 누가 어떤 스키마를 소유하는가
• 품질 검증 실패 시 어디서 막을 것인가
• 재처리는 어떤 단위로 가능한가
• 소비자는 어떤 SLA를 기대하는가

이 계약이 먼저 서면 구조는 자연스럽게 따라옵니다. 어떤 팀은 메달리온이 맞을 것이고, 어떤 팀은 2계층이면 충분할 것이고, 어떤 팀은 dbt 기반 모델 계층이 더 적합할 것입니다.

즉, 아키텍처는 교리처럼 가져오면 안 되고 운영 모델의 결과물이어야 합니다.

결론적으로 저는 메달리온보다 운영 가능한 단순함을 더 믿습니다

메달리온은 2026년에도 여전히 유효합니다. 하지만 유효하다는 것과 기본 선택지여야 한다는 것은 전혀 다른 이야기입니다.

저는 데이터 엔지니어로서, 팀이 실제로 운영할 수 있는 가장 단순한 구조에서 시작하는 편을 선호합니다. 재처리가 필요하면 그때 원본 보존을 강화하면 됩니다. 공용 정제층이 정말 필요해지면 그때 Silver에 해당하는 레이어를 만들면 됩니다.

처음부터 Bronze, Silver, Gold를 다 깔아두는 것이 성숙함의 증거는 아닙니다. 오히려 아직 필요하지 않은 복잡도를 미래의 자신에게 떠넘기는 선택일 수 있습니다.

그래서 저는 여전히 메달리온이 싫다고 말하고 싶습니다. ( 는 반쯤 농담이고, 아무 생각 없이 메달리온부터 꺼내 드는 습관이 싫습니다. )