209. 데이터 마트 (Data Mart) Kimball 다차원 분석 스타 스키마 (Star Schema)

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

본질: 데이터 마트(Data Mart)는 특정 부서나 비즈니스 도메인을 위해 최적화된 분석 전용 소규모 데이터 저장소이며, Kimball 방법론의 스타 스키마(Star Schema)가 핵심 설계 패턴이다.

가치: 팩트 테이블(Fact Table) 중심의 비정규화 스타 스키마는 복잡한 조인 없이 빠른 집계 쿼리를 가능하게 하여, 비즈니스 분석가가 SQL만으로 다차원 분석을 수행할 수 있다.

판단 포인트: 독립형 마트(Independent Mart)는 부서별 신속 구축에 유리하지만 데이터 일관성 문제를 야기하므로, 콘포밍 차원(Conformed Dimension)으로 전사 일관성을 확보하는 설계가 필수다.

Ⅰ. 개요 및 필요성

데이터 마트 정의

데이터 마트는 전사 데이터 웨어하우스(EDW: Enterprise Data Warehouse)의 부분집합으로, 특정 사업부·기능·주제 영역을 위한 분석 저장소다.

판매 마트: 지역별·제품별·채널별 매출 분석
인사 마트: 직원 성과·이직률·채용 비용 분석
공급망 마트: 재고·납품 시간·공급업체 분석

Kimball 방법론의 핵심 원칙

랄프 킴볼(Ralph Kimball)이 주창한 차원 모델링(Dimensional Modeling)의 4원칙:

비즈니스 프로세스 선택: 분석 대상 프로세스 확정 (예: 판매 주문)
세분성(Grain) 정의: 팩트 테이블의 행 하나가 나타내는 단위 확정 (예: 개별 주문 라인)
차원 결정: 분석 축 정의 (날짜, 고객, 제품, 지역 등)
팩트 결정: 측정값 확정 (매출액, 수량, 할인율 등)

📢 섹션 요약 비유: 데이터 마트는 부서 전용 분석 냉장고다. 전사 냉장고(EDW)에서 각 팀이 자주 쓰는 재료만 꺼내 놓은 소형 냉장고다.

Ⅱ. 아키텍처 및 핵심 원리

스타 스키마 (Star Schema) 구조

                    ┌─────────────────┐
                    │  DimDate (날짜)  │
                    │  date_key (PK)  │
                    │  year, month    │
                    │  quarter, day   │
                    └────────┬────────┘
                             │
┌───────────────┐            │             ┌────────────────┐
│ DimCustomer   │            │             │  DimProduct    │
│ (고객 차원)    │            │             │  (제품 차원)   │
│ customer_key  ├────────────┤             │  product_key   │
│ customer_name │            │             │  product_name  │
│ city, region  │     ┌──────▼──────┐      │  category      │
│ segment       │     │FactSales    │      │  brand, price  │
└───────────────┘     │ (판매 팩트)  │      └────────────────┘
          ┌───────────┤ date_key(FK)├──────────────┐
          │           │ cust_key(FK)│               │
          │           │ prod_key(FK)│               │
          │           │ store_key(FK│               │
          │           │ sales_amt   │               │
          │           │ quantity    │               │
          │           │ discount    │               │
          │           └─────────────┘               │
          │                   │                     │
          │           ┌───────▼───────┐             │
          │           │  DimStore     │             │
          │           │  (매장 차원)  │             │
          └───────────┤  store_key    ├─────────────┘
                      │  store_name   │
                      │  city, region │
                      └───────────────┘

마트 유형 비교

유형	설명	장점	단점
의존형 마트	EDW에서 서브셋 추출	데이터 일관성 보장	EDW 구축 선행 필요
독립형 마트	소스에서 직접 구축	신속한 구현	부서 간 데이터 불일치
논리적 마트	뷰(View)로 구현	데이터 중복 없음	쿼리 성능 저하 가능

콘포밍 차원 (Conformed Dimension)

여러 마트에서 동일한 차원 테이블을 공유하여 부서 간 일관성 확보:

날짜 차원(Date Dimension): 모든 마트에서 동일한 날짜 기준 사용
고객 차원(Customer Dimension): 판매 마트·CRM 마트·서비스 마트 공유

📢 섹션 요약 비유: 스타 스키마는 별자리 지도와 같다. 중앙의 팩트(별)를 여러 차원(행성)이 둘러싸는 구조로, 각 행성이 분석의 관점이 된다.

Ⅲ. 비교 및 연결

Inmon vs Kimball 방법론

관점	Inmon	Kimball
접근 방향	Top-Down (EDW 우선)	Bottom-Up (마트 우선)
스키마	3NF 정규화	비정규화 스타/스노우플레이크
구현 속도	느림 (수년)	빠름 (수개월)
전사 일관성	높음	콘포밍 차원으로 확보 필요
분석 성능	조인 증가로 느릴 수 있음	빠른 집계 쿼리

스타 스키마 vs 스노우플레이크 스키마

스타 스키마: 차원 테이블 비정규화 → 조인 수 최소화, 쿼리 성능 우수
스노우플레이크 스키마(Snowflake Schema): 차원 테이블 정규화 → 저장 공간 절약, 유지보수 용이

📢 섹션 요약 비유: Inmon은 먼저 도시 전체 설계도 그리기, Kimball은 각 동네부터 빠르게 개발하기다. 어느 쪽이 맞다기보다 상황에 따라 다르다.

Ⅳ. 실무 적용 및 기술사 판단

스타 스키마 설계 실무 단계

비즈니스 요건 수집: 분석 질문 목록 (예: "지역별·제품군별 월매출 비교")
세분성 정의: 팩트의 원자 단위 결정 (개별 거래 라인 vs 일별 집계)
차원 테이블 설계: SCD(Slowly Changing Dimension) 타입 결정
팩트 테이블 설계: 가산적(Additive)·반가산적(Semi-Additive)·비가산적(Non-Additive) 팩트 분류
집계 팩트 테이블: 성능을 위한 사전 집계 테이블 추가

기술사 판단 포인트

마트 증식 위험: 독립형 마트 남용 시 "분석 스파게티" 발생 → 콘포밍 차원으로 통제
클라우드 DW 연계: Snowflake·BigQuery에서 스타 스키마는 성능 최적화의 기본
실시간 마트: CDC(Change Data Capture) + 스트리밍으로 준실시간 마트 구축 가능

📢 섹션 요약 비유: 데이터 마트 설계는 요리 레시피 표준화와 같다. 각 요리사(부서)가 같은 재료(콘포밍 차원)를 쓰되, 자기 전문 요리(마트)를 만들 수 있어야 한다.

Ⅴ. 기대효과 및 결론

도입 기대효과

효과	정량적 목표
쿼리 응답 속도 향상	OLTP 대비 분석 쿼리 10~100배 향상
비즈니스 사용자 셀프 서비스	SQL/BI 도구로 독립적 분석 가능
부서 특화 분석 환경	판매·재무·HR 각 최적화된 데이터 모델
의사결정 속도 개선	임원 리포트 생성 시간 수일 → 실시간

결론

데이터 마트와 Kimball의 스타 스키마는 분석의 민주화를 실현하는 핵심 도구다. 비정규화된 차원 모델은 복잡한 데이터 엔지니어링 없이도 비즈니스 사용자가 다차원 분석을 수행할 수 있게 한다. 그러나 콘포밍 차원과 전사 거버넌스 없이는 마트 증식이 데이터 불일치로 이어지므로, Kimball 방법론의 버스 아키텍처(Bus Architecture) 원칙 준수가 필수다.

📢 섹션 요약 비유: 데이터 마트의 스타 스키마는 각 팀 전용 분석 대시보드다. 공통 데이터(콘포밍 차원)를 공유하면서도 각 팀이 원하는 분석 뷰를 쉽게 만들 수 있다.

📌 관련 개념 맵

관계	개념	설명
설계 방법론	Kimball 차원 모델링	스타 스키마 기반 Bottom-Up 접근
핵심 구조	스타 스키마	팩트+차원 비정규화 구조
확장 스키마	스노우플레이크 스키마	차원 정규화 버전
핵심 테이블	팩트 테이블	측정값·집계 데이터
핵심 테이블	차원 테이블	분석 맥락·속성
일관성 확보	콘포밍 차원	마트 간 공유 차원
이력 관리	SCD (Slowly Changing Dimension)	차원 변경 이력 보존
상위 저장소	데이터 웨어하우스	마트의 원천 데이터

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

데이터 마트는 학급별 사물함이야. 학교 전체 창고(DW)에서 우리 반에 필요한 것만 꺼내 넣어둔 것이지.

📈 관련 키워드 및 발전 흐름도

OLTP (운영 시스템)
    │
    ▼
Data Warehouse (전사 통합 저장소)
    │
    ▼
Data Mart (부서별 서브셋)
    ├─► 종속형: DW에서 추출 (Top-Down, Inmon)
    └─► 독립형: 직접 구축 (Bottom-Up, Kimball)
    │
    ▼
Star Schema · Kimball 차원 모델링

스타 스키마는 별 모양 조직도야. 가운데 별(팩트)이 "우리가 분석할 것"이고, 주변 행성들(차원)이 "어떤 각도에서 볼지"를 나타내.
같은 날짜 기준을 모든 반이 쓰면 "이번 달"이 다 같은 의미가 돼. 그게 콘포밍 차원이야.