-
데이터 레이어 아키텍처카테고리 없음 2026. 4. 5. 00:13
3. 데이터 레이어 아키텍처
3.1 Medallion Architecture (Bronze/Silver/Gold)
Databricks가 대중화한 Medallion Architecture는 데이터 품질을 단계적으로 향상시키는 레이어 구조입니다.
📊 공식 다이어그램 참고: Databricks Medallion Architecture | Microsoft Azure Databricks 문서
Bronze (원시 데이터 레이어)
- 소스 시스템에서 추출한 원시 데이터를 그대로 저장합니다
- 변환 없이 수집(Ingestion)만 수행합니다
- 데이터 계보 추적을 위한 메타데이터를 추가합니다 (
data_loaded_at,source_file_name) - 스키마 불일치나 품질 이슈가 있어도 일단 저장합니다
- 목적: 데이터 유실 방지, 재처리 가능성 확보
Silver (정제 데이터 레이어)
- Bronze 데이터에 정제(Cleansing), 표준화(Standardization), 통합(Integration)을 적용합니다
- 데이터 타입 수정, null 처리, 중복 제거를 수행합니다
- 비즈니스 키 기반 데이터 통합을 진행합니다
- 스키마 진화(Schema Evolution)를 관리합니다
- 목적: 신뢰할 수 있는 분석용 데이터셋 구축
Gold (비즈니스 데이터 레이어)
- Silver 데이터에 비즈니스 규칙과 집계를 적용한 최종 소비용 데이터입니다
- 차원 모델(Star Schema), 집계 테이블, KPI 대시보드용 데이터셋을 제공합니다
- 데이터 마트 또는 리포트용 비정규화 테이블을 구성합니다
- 목적: 비즈니스 사용자와 BI 도구에 최적화된 데이터 제공
3.2 전통적 데이터 플랫폼 레이어
전통적 데이터 플랫폼은 레스토랑에 비유하면 이해하기 쉽습니다.
Staging Layer (스테이징 레이어) — "식재료 입고"
Raw 하위 레이어:
- 소스 시스템 데이터를 그대로 저장합니다
- ELT 도구(Fivetran, Airbyte 등)로 로드합니다
- 메타데이터를 추가합니다:
data_loaded_at,file_name,batch_id - 명명 규칙:
<SOURCE_SYSTEM>_<BRAND>(예:salesforce_kr,sap_global)
Standardized 하위 레이어:
- 데이터 타입 수정 및 표준화를 수행합니다
- 메타데이터-퍼스트(Metadata-First) 접근법을 적용합니다
- 변경 이력 관리를 시작합니다
Core Layer (코어 레이어) — "요리 과정"
Prep 하위 레이어:
- 다중 소스를 통합합니다
- 일관된 명명 규칙을 매핑합니다 (예:
cust_id→customer_id) - 비즈니스 키를 식별하고 표준화합니다
- 보편적 정제 규칙을 적용합니다
Conformed 하위 레이어:
- 비즈니스 규칙을 적용하고 복잡한 변환을 수행합니다
- "단일 진실의 소스(Single Source of Truth)" 마스터 데이터셋을 구축합니다
- 참조 데이터(Reference Data)를 통합합니다
Presentation Layer (프레젠테이션 레이어) — "플레이팅"
Data Mart:
- Star Schema 기반의 사실/차원 테이블(Kimball 방법론)을 제공합니다
- 특정 비즈니스 영역에 최적화된 분석 성능을 제공합니다
Report:
- 비정규화된 사전 집계 데이터셋을 제공합니다
- 조인 없이 직접 접근이 가능합니다
- BI 도구(Tableau, Looker, Power BI)와 직접 연결됩니다
3.3 레이어별 원칙과 모범 사례
원칙 Staging Core Presentation 변환 수준 없음 (그대로 저장) 정제, 통합, 비즈니스 규칙 집계, 비정규화 데이터 품질 원시 상태 검증됨 비즈니스 인증됨 접근 권한 데이터 엔지니어만 데이터 엔지니어 + 분석가 비즈니스 사용자 포함 보존 기간 단기 (또는 아카이브) 장기 중기 명명 규칙 예시 stg_salesforce_accountscore_customersmart_sales_daily
3.4 dbt 프로젝트 구조와 레이어 매핑
dbt 프로젝트의 디렉터리 구조는 Medallion Architecture의 각 레이어와 자연스럽게 대응됩니다.
models/ staging/ ← Bronze/Raw (stg_ 접두사) stg_salesforce_accounts.sql stg_shopify_orders.sql intermediate/ ← Silver 중간 단계 (int_ 접두사) int_orders_joined.sql marts/ ← Gold (dim_, fct_, mart_ 접두사) core/ dim_customers.sql fct_orders.sql finance/ mart_revenue_daily.sql레이어별 dbt Materialization 전략
각 레이어의 역할에 따라 dbt의 구체화(Materialization) 전략을 다르게 적용하는 것이 권장됩니다.
- staging:
view를 사용합니다. 항상 최신 소스 데이터를 반영하며, 별도의 저장 비용이 발생하지 않습니다. - intermediate:
view또는ephemeral을 사용합니다. 최종 사용자가 직접 접근하지 않는 중간 변환 단계입니다. - marts:
table또는incremental을 사용합니다. 비즈니스 사용자와 BI 도구가 직접 소비하므로 쿼리 성능을 최우선으로 고려합니다.
3.5 레이어 허용/금지 매트릭스
데이터 품질과 계보(Lineage)를 보장하려면 각 레이어에서 허용되는 작업과 금지되는 작업을 명확히 정의해야 합니다.
레이어 허용되는 작업 금지되는 작업 Raw/Bronze 그대로 저장, 메타데이터 추가 변환, 필터링, 삭제 Staging/Silver 정제, 표준화, 타입 변환 비즈니스 로직, 집계 Core/Gold 비즈니스 규칙 적용, 통합 Raw 데이터 직접 참조 Mart 집계, 비정규화 Core 우회, Raw 직접 참조 이 매트릭스를 준수하면 다음과 같은 이점을 얻을 수 있습니다.
- 재처리 가능성: Raw/Bronze 레이어는 항상 원본 상태를 유지하므로, 변환 로직을 수정한 후 언제든지 하위 레이어를 재처리할 수 있습니다.
- 데이터 계보 추적: 각 레이어의 역할이 명확하므로 데이터가 어디서 어떻게 변환되었는지 추적하기 용이합니다.
- 거버넌스 강화: 비즈니스 로직이 Core/Gold 레이어에만 집중되므로, 규칙 변경 시 영향 범위를 명확히 파악할 수 있습니다.