데이터 마트 (Data Mart)

핵심 인사이트 (3줄 요약)

본질: 데이터 웨어하우스 (DW)의 하위 집합으로, 전사 데이터 중 특정 부서(영업, 재무 등)나 비즈니스 도메인의 요구사항에 맞게 구조화된 소규모 분석용 데이터베이스입니다.

가치: 방대한 전사 데이터에서 필요한 정보만 추출·가공해 제공함으로써 분석 쿼리 응답 시간을 단축하고, 현업(Business User)의 데이터 접근성과 BI (Business Intelligence) 도구 활용의 직관성을 극대화합니다.

융합: 상향식 (Bottom-up)인 킴볼 (Kimball) 아키텍처의 핵심 요소이며, 최근에는 클라우드 네이티브 DW 내에서 물리적 복제를 줄이는 가상 데이터 마트(Virtual Data Mart) 형태로 융합 발전하고 있습니다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

**데이터 마트 (Data Mart)**는 전사적 통합 데이터 저장소인 데이터 웨어하우스(DW)와 달리, 단일 부서나 특정 비즈니스 프로세스의 분석 요구에 초점을 맞춘 목적 지향적 데이터 저장소입니다. 과거 RDBMS 환경에서 방대한 전사 DW에 직접 복잡한 분석 쿼리를 날릴 경우, 극심한 성능 저하와 병목 현상이 발생했습니다. 이를 해결하기 위해 현업이 자주 사용하는 데이터만 미리 집계하고 다차원 모델링(Dimensional Modeling)을 적용하여 분리해 낸 것이 데이터 마트의 시작입니다.

실무적으로 데이터 마트는 "현업 부서가 IT의 도움 없이 데이터를 스스로 이해하고 분석할 수 있는가?"라는 셀프 서비스 (Self-Service) BI의 핵심 전제 조건을 해결합니다. 전사 DW가 수백 개의 정규화된 테이블로 이루어져 있다면, 조인(Join) 로직이 지나치게 복잡해져 쿼리 실패율이 급증합니다. 따라서 특정 주제(예: 월별 영업 실적)에 맞춰 스키마를 비정규화하고 직관적으로 재설계할 필요성이 대두되었습니다.

[전사 데이터 구조의 한계와 데이터 마트의 워크로드 격리]

┌─────────────────── 기존: 전사 DW 직접 쿼리 (병목 발생) ─────────────────┐
│ [Sales App] ─┐                                                        │
│ [HR App]    ─┼─> [ Enterprise Data Warehouse ] <── (Slow Query!) ── [ BI / Analytics ]
│ [ERP App]   ─┘   (수백 개 정규화 테이블, 조인 지옥)                   │
└───────────────────────────────────────────────────────────────────────┘
                                   ↓ (아키텍처 개선)
┌─────────────────── 개선: 데이터 마트를 통한 워크로드 분산 ────────────────┐
│                   ┌─> [ Sales Data Mart ]  <── (Fast!) ── [ Sales BI ]│
│ [ EDW ] ──────────┼─> [ HR Data Mart ]     <── (Fast!) ── [ HR BI ]   │
│ (통합 저장소)     └─> [ Finance Data Mart] <── (Fast!) ── [ Fin BI ]  │
└───────────────────────────────────────────────────────────────────────┘

이 도식은 데이터 마트가 어떻게 전사 시스템의 읽기 부하를 분산시키고 각 부서의 쿼리 성능을 격리 보장하는지를 보여줍니다. 기존에는 모든 무거운 분석 쿼리가 단일 EDW로 집중되어 락 경합과 리소스 고갈이 빈번했습니다. 마트 계층을 도입하면 장애를 부서 단위로 격리할 수 있으며, 각 도메인에 최적화된 맞춤형 스키마를 제공하여 BI 대시보드의 렌더링 속도를 밀리초 단위로 끌어올릴 수 있습니다.

📢 섹션 비유: 대형 창고형 할인매장(데이터 웨어하우스)에서 원하는 물건을 찾으려면 복잡한 지도가 필요하지만, 집 앞 동네 편의점(데이터 마트)은 소비자가 자주 찾는 물건만 눈에 띄게 진열해 두어 누구나 빠르게 쇼핑할 수 있는 원리와 같습니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

데이터 마트 설계의 근간은 Ralph Kimball이 제안한 **다차원 모델링 (Dimensional Modeling)**입니다. 이 기법은 데이터를 '측정 가능한 수치(Fact)'와 '이를 설명하는 텍스트 맥락(Dimension)'으로 엄격히 분리합니다.

구성 요소	역할	내부 동작 메커니즘	실무 비유
Fact Table (팩트 테이블)	비즈니스 이벤트의 정량적 수치 보관	트랜잭션 발생 시 대리 키(Surrogate Key)와 측정값(매출, 수량) 위주로 Append 기록	영수증의 결제 금액과 수량
Dimension Table (차원 테이블)	팩트의 맥락(Who, What, Where) 제공	카테고리, 속성 등을 텍스트 형태로 비정규화하여 저장. 필터링 조건으로 사용됨	영수증의 품목 상세 설명
Surrogate Key (대리 키)	테이블 간 조인 속도 향상 및 이력 격리	원본 시스템의 비즈니스 키 대신 독립적인 정수(Integer) 시퀀스를 발급하여 매핑	주민번호 대신 쓰는 사내 사원번호
ETL Pipeline	소스에서 마트로 데이터 정제 및 적재	증분 추출, 차원 속성 업데이트(SCD 처리), 팩트 테이블 로드 스케줄링 수행	창고에서 편의점으로의 새벽 배송 트럭
OLAP Engine	다차원 데이터 고속 탐색 및 집계 지원	데이터 마트 구조 위에서 드릴다운(Drill-down), 롤업(Roll-up) 등 사전 큐브(Cube) 연산	3D 루빅스 큐브의 단면 돌려보기

마트 설계의 표준은 팩트 테이블을 중앙에 두고 차원 테이블이 방사형으로 연결되는 **스타 스키마 (Star Schema)**입니다.

[스타 스키마 (Star Schema) 아키텍처 흐름]

       [ Dim_Time ] (시간 차원)     [ Dim_Product ] (상품 차원)
       - Time_Key (PK)              - Product_Key (PK)
       - Year, Month, Date          - Category, Brand, Name
            |                             |
            +-------------+---------------+
                          | (1:N 조인)
                  [ Fact_Sales ] (중앙 팩트 테이블)
                  - Time_Key (FK)
                  - Product_Key (FK)
                  - Store_Key (FK)
                  - Sales_Amount (Measure / 수치)
                  - Discount_Amount (Measure / 수치)
                          |
            +-------------+
            |
       [ Dim_Store ] (매장 차원)
       - Store_Key (PK)
       - Region, City, Manager

이 구조도의 핵심은 조인(Join)의 깊이가 항상 '1단계'로 고정된다는 점입니다. 정규화된 DB에서는 카테고리 이름을 찾기 위해 여러 테이블을 거쳐야 하지만, 스타 스키마에서는 Dim_Product 하나에 모든 텍스트 정보가 중복을 감수하고 들어가 있습니다. 분석 쿼리는 항상 차원 필터링(Where) -> 팩트 조인(Join) -> 집계(Sum)의 단순한 실행 계획(Execution Plan)을 가지게 되며, 이는 RDBMS 옵티마이저가 가장 빠르고 효율적으로 처리할 수 있는 패턴입니다. 데이터 중복으로 인한 스토리지 비용 상승보다, 조인 제거로 얻는 CPU 연산 속도 향상이 압도적으로 크기 때문에 채택됩니다.

📢 섹션 비유: 팩트 테이블이 '매출액'이라는 요리의 '메인 식재료'라면, 차원 테이블은 '언제, 어디서, 누가'라는 요리의 맛을 다채롭게 만드는 '다양한 양념 세트'입니다. 이 구조를 미리 세팅해 두면 주문(쿼리) 즉시 완제품을 낼 수 있습니다.

Ⅲ. 융합 비교 및 다각도 분석 (Comparison & Synergy)

데이터 플랫폼을 설계할 때 가장 많이 대립하는 철학이 Bill Inmon의 하향식(Top-down) 접근과 Ralph Kimball의 상향식(Bottom-up) 데이터 마트 접근입니다.

1. 데이터 마트 vs 데이터 웨어하우스 (Kimball vs Inmon)

비교 항목	데이터 웨어하우스 (Inmon 모델)	데이터 마트 (Kimball 모델)	아키텍처 판단 포인트
목적과 사상	전사 데이터의 단일 진실 공급원 (SSOT) 구축	특정 부서의 신속한 의사결정 및 BI 분석	데이터의 보편성 vs 특수성
설계 구조	3차 정규화 (3NF) 중심의 릴레이션 모델	다차원 모델 (Star Schema 중심의 비정규화)	중복 제거(쓰기 최적화) vs 조인 축소(읽기 최적화)
구축 방식	하향식 (전사 모델링 완료 후 배포, 수년 소요)	상향식 (부서별 마트를 먼저 짓고 점진적 통합)	초기 도입 속도와 투자 대비 효용 (ROI)
데이터 범위	엔터프라이즈 전체의 상세 트랜잭션	단일 비즈니스 주제 (예: 마케팅 캠페인 성과)	분석 스코프의 폭

2. 독립형 (Independent) vs 종속형 (Dependent) 데이터 마트

데이터 마트를 구축할 때 데이터를 소스(운영 DB)에서 직접 가져올지, 아니면 EDW를 거쳐서 가져올지가 시스템 안정성을 결정합니다.

[독립형 마트의 사일로 위협 vs 종속형 마트의 정합성]

[A. 독립형 (Independent) - 안티패턴]
운영 DB ─(ETL)─> [ Data Mart 영업 ] ──> 영업 BI (매출: 100억)
운영 DB ─(ETL)─> [ Data Mart 재무 ] ──> 재무 BI (매출: 95억) 
===> 부서별 로직 차이로 "데이터 사일로(Silo)" 및 신뢰도 하락 발생

[B. 종속형 (Dependent) - 권장 아키텍처]
운영 DB ─(ETL)─> [ EDW (통합/정제) ] ─(추출)─> [ Data Mart 영업 ]
                                     ─(추출)─> [ Data Mart 재무 ]
===> 중앙 통제를 통해 "단일 진실 공급원(SSOT)" 기반 파생 보장

이 비교도는 단기적인 구축 속도와 장기적인 데이터 거버넌스 사이의 트레이드오프를 보여줍니다. 독립형 방식(A)은 EDW가 없어도 되므로 구축이 매우 빠르지만, 부서마다 '매출'을 정의하는 기준(예: 부가세 포함 여부)이 달라져 전사 회의에서 지표가 어긋나는 치명적 결함을 낳습니다. 반면 종속형 방식(B)은 EDW라는 거대한 필터를 거치므로 일관성이 완벽히 보장됩니다. 실무에서는 B 방식을 기본으로 하되, 클라우드 환경에서는 물리적 이동 없이 'View'만 생성하는 가상 마트(Virtual Mart)로 비용을 상쇄합니다.

📢 섹션 비유: 독립형 마트가 각 지점이 알아서 레시피를 만들어 파는 '개인 식당'이라면, 종속형 마트는 중앙 본사(EDW)에서 통일된 재료를 받아 요리하는 '프랜차이즈 체인점'과 같습니다. 프랜차이즈만이 전국 어디서나 일관된 맛(데이터 정합성)을 보장합니다.

Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)

실무에서 데이터 마트를 운영할 때 가장 큰 기술적 난제는 과거의 이력 데이터를 어떻게 보존할 것인가를 다루는 SCD (Slowly Changing Dimension, 느리게 변하는 차원) 처리입니다.

실무 시나리오: 고객 등급 변경에 따른 과거 실적 왜곡 방어

상황: 고객 A가 1월에는 '실버' 등급으로 100만 원을 구매했고, 2월에 'VIP'로 승급. 영업팀은 1월의 실적도 VIP의 실적으로 소급 적용되는 데이터 왜곡(Overwrite) 현상을 리포팅함.
원인: 차원 테이블(Dim_Customer) 업데이트 시 기존 데이터를 덮어쓰는 무조건적인 SCD Type 1 방식을 적용했기 때문.
해결 (운영 의사결정 플로우):

[SCD(Slowly Changing Dimension) 전략 의사결정 트리]

[차원 데이터 변경 이벤트 발생 (예: 주소, 등급 변경)]
         ↓
[Q1. 과거 데이터(Fact) 분석 시, 과거 시점의 상태가 필요한가?]
 ├── (No) ──> [SCD Type 1 적용]: 기존 레코드 단순 UPDATE (덮어쓰기) => 이력 유실
 └── (Yes) ─> [Q2. 이력 추적 테이블 관리에 리소스를 투자할 수 있는가?]
               ├── (No) ──> [SCD Type 3 적용]: 현재값/과거값 컬럼 분리 추가
               └── (Yes) ─> [SCD Type 2 적용]: 신규 레코드 INSERT 및 유효기간(Start/End Date) 플래그 관리

이 흐름도는 데이터 정합성을 지키기 위한 핵심 의사결정 과정을 나타냅니다. 실무적으로 마케팅이나 재무 분석에서는 특정 시점(Point-in-Time)의 고객 상태를 아는 것이 필수적이므로, 레코드 자체를 새로 생성하고 이력 기간(Valid_From, Valid_To)을 명시하는 SCD Type 2 적용이 표준입니다. 이는 데이터 마트의 복잡도를 높이지만, 비즈니스 인텔리전스의 신뢰도를 결정짓는 가장 중요한 방어선이 됩니다. 또한 서로 다른 마트 간 교차 분석을 위해서는 'Conformed Dimension(전사 공통 차원)'을 반드시 사전에 정의해야 합니다.

도입 및 운영 체크리스트

모델링 품질: 팩트 테이블에 문자열 정보가 섞여 있어 스토리지를 낭비하고 있지 않은가?
파이프라인 지연: 마트를 생성하기 위한 ETL 작업이 야간 배치를 초과하여 아침 업무 시간에 영향을 주지 않는가?

📢 섹션 비유: 이력 관리가 없는 데이터 마트(Type 1)는 과거의 일기장을 오늘의 감정으로 전부 고쳐 쓰는 것과 같아 역사적 진실을 알 수 없게 됩니다. 올바른 마트(Type 2)는 과거의 기록을 보존한 채 새로운 페이지를 추가해 나가는 충실한 연대기입니다.

Ⅴ. 기대효과 및 결론 (Future & Standard)

데이터 마트 아키텍처는 데이터의 비즈니스적 가치를 폭발시키는 라스트 마일(Last Mile) 딜리버리 시스템입니다.

도입 효과 영역	도입 전 (As-Is)	도입 후 (To-Be)
조직/문화	분석을 위해 IT 부서에 SQL 추출 요청(티켓팅) 후 수일 대기	현업 사용자가 BI 툴로 직접 드래그 앤 드롭 분석 (Self-Service)
시스템 성능	복잡한 정규화 테이블 조인으로 수십 분 소요되던 쿼리	비정규화된 스타 스키마 구조로 수 초 이내 응답 보장

미래 전망 및 결론 과거에는 스토리지와 컴퓨팅 성능의 물리적 한계 때문에 데이터를 직접 복사하여 마트를 구성하는 방식이 필수적이었습니다. 그러나 Snowflake나 BigQuery 같은 현대적 클라우드 데이터 웨어하우스의 등장으로 스토리지와 연산의 완전한 분리가 이루어졌습니다. 이에 따라 데이터 엔지니어링의 패러다임은 물리적인 데이터 이동을 지양하고, 원본 데이터 위에 논리적인 뷰(View) 형태로 모델링만 입히는 **가상화된 데이터 마트(Virtual Data Mart)**와 dbt(Data Build Tool) 기반의 모듈화 코드로 진화하고 있습니다. 결론적으로 물리적 형태는 클라우드 안으로 흡수되더라도, 비즈니스 요건을 반영하여 직관적으로 데이터를 펼쳐내는 다차원 모델링(Kimball)의 철학 자체는 AI/BI 시대에도 변함없는 데이터 아키텍처의 황금률로 남을 것입니다.

📢 섹션 비유: 무거운 종이책(물리적 마트)이 가벼운 전자책(가상 마트)으로 매체는 바뀌었더라도, 독자가 이해하기 쉽게 목차를 짜고 편집하는 작가의 저술 방식(다차원 모델링)은 영원히 필수적인 것과 같습니다.

📌 관련 개념 맵 (Knowledge Graph)

Data Warehouse (DW) | 데이터 마트에 검증되고 통합된 데이터를 공급하는 전사적 진실의 원천(SSOT).
Star Schema | 데이터 마트 구축의 뼈대가 되는 다차원 물리 모델로, 조인 성능을 극대화한 구조.
OLAP (Online Analytical Processing) | 데이터 마트에 적재된 데이터를 다차원으로 슬라이스 앤 다이스(Slice & Dice)하여 분석하는 처리 엔진.
SCD (Slowly Changing Dimension) | 차원 속성(예: 고객의 주소 변경)의 변화 이력을 관리하는 데이터 마트 핵심 갱신 기법.
dbt (Data Build Tool) | 최신 데이터 환경에서 ELT 방식으로 논리적 데이터 마트를 코드(SQL)로 정의하고 구축하는 데이터옵스 툴.

👶 어린이를 위한 3줄 비유 설명

도서관 전체(데이터 웨어하우스)에는 수백만 권의 책이 섞여 있어서 원하는 내용을 찾기 너무 힘들어요.
그래서 과학 숙제를 할 때는 과학 책만 모아둔 작은 '과학 전용 책장(데이터 마트)'을 만들면 훨씬 편해요.
이렇게 부서마다 자기들이 필요한 정보만 예쁘게 모아둔 작고 빠른 맞춤형 데이터베이스를 데이터 마트라고 부른답니다!