474. 데이터 마트 (Data Mart)와 Kimball 아키텍처

⚠️ 이 문서는 "회사 전체의 데이터를 한 곳에 모으는 거대한 창고(EDW)를 짓기에는 돈도 없고 시간도 없으니, **일단 우리 마케팅팀이 당장 쓸 수 있는 '작은 가건물(데이터 마트)'부터 빨리빨리 만들어서 쓰자!"라는 애자일한 철학의 'Kimball의 상향식(Bottom-Up) 아키텍처'**를 다룹니다.

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

  1. 본질: 데이터 마트는 전사 통합 데이터 웨어하우스(EDW)와 달리, '마케팅팀', '재무팀' 등 특정 부서나 특정 주제에만 딱 맞춰서 잘라 만든 작은 규모의 읽기 전용 데이터베이스다.
  2. Kimball 방식 (상향식): 처음부터 완벽한 중앙 창고를 짓는 Inmon(473번 문서)과 달리, "일단 각 부서별로 데이터 마트를 먼저 빠르게 만들어라. 나중에 이 마트들을 이어 붙이면 그게 전체 데이터 웨어하우스(DW)가 되는 거다!"라는 철학이다.
  3. 다차원 모델링: Kimball 아키텍처의 핵심은 데이터를 조인(JOIN)하기 편하게 '가운데에 사실(Fact) 테이블을 두고, 주변에 차원(Dimension) 테이블을 둥그렇게 배치하는' 스타 스키마(Star Schema) 구조를 쓰는 것이다.

Ⅰ. 개요: 3년짜리 공사 vs 3주짜리 조립식 건물 (Context & Necessity)

"마케팅 효율을 분석해야 하니까 빨리 데이터 창고 좀 지어주세요!"

  • Inmon (하향식): "음... 회사 전체의 데이터 표준을 잡고 중앙 창고(EDW)를 먼저 완벽하게 지어야 하니까 한 3년 기다리세요." $\rightarrow$ 마케팅팀 복장 터짐.
  • Kimball (상향식): "오케이! 재무팀 데이터는 나중에 생각하고, 일단 마케팅에 필요한 데이터만 쏙 뽑아서 **3주 만에 마케팅 전용 데이터 마트(Data Mart)**를 지어줄게. 당장 써!"

랄프 킴볼(Ralph Kimball)의 상향식 접근법은 비즈니스의 민첩성(Agility)을 최우선으로 생각한다. 일단 작은 데이터 마트 여러 개를 부서별로 빠르게 찍어내고, 나중에 그 마트들이 겹치는 부분(예: 두 부서 모두 '고객' 테이블을 씀)을 **공유 차원(Conformed Dimension)**이라는 개념으로 이어 붙여서 하나의 거대한 DW처럼 보이게 만든다.

📢 섹션 요약 비유: Inmon 방식이 **'수십억을 들여서 뼈대부터 완벽하게 짓는 백화점 건물'**이라면, Kimball 방식은 **'일단 야시장에 컨테이너 박스(마트) 하나 세워서 당장 장사를 시작하고, 장사가 잘되면 옆에 컨테이너를 계속 이어 붙여서 백화점처럼 만드는 조립식 건물'**과 같습니다.

Ⅱ. 데이터 마트의 특징과 존재 이유 ★

데이터 마트(Data Mart)는 보통 DW에서 파생되어 나오거나(Inmon), 아예 DW 없이 독립적으로 만들어진다(Kimball).

  1. 특정 부서 / 주제 중심: 마케팅팀 데이터 마트에는 '재고 관리' 데이터가 아예 안 들어있다. 그래서 가볍다.
  2. 비정규화 (Denormalization): 일반 RDBMS처럼 데이터를 잘게 쪼개놓으면(3NF) 나중에 통계 낼 때 JOIN 하느라 밤을 새워야 한다. 그래서 데이터 마트는 일부러 데이터를 뭉뚱그려 놓는(비정규화) 스타 스키마(Star Schema) 구조를 쓴다.
  3. 빠른 구축과 싼 비용: 회사 전체를 아우르지 않기 때문에 구축 기간이 짧고 싸다.

Ⅲ. Kimball의 필살기: 스타 스키마 (Star Schema)

Kimball 아키텍처에서 데이터 마트를 짤 때 쓰는 가장 유명한 테이블 구조다. 테이블 모양이 밤하늘의 별(Star)처럼 생겼다고 해서 붙은 이름이다.

  • 가운데 별의 몸통 (Fact Table, 사실 테이블)
    • 가장 무겁고 거대한 데이터. (예: 1억 건의 주문 내역, 클릭 로그)
    • 숫자로 된 결괏값(매출액, 클릭 수)과, 별의 꼭짓점들과 연결될 외래 키(FK)만 잔뜩 들어있다.
  • 주변의 별 꼭짓점 (Dimension Table, 차원 테이블)
    • 분석의 기준이 되는 텍스트 데이터. (예: 고객 테이블, 시간 테이블, 상품 테이블)
    • 비정규화가 되어 있어서, 조인을 한 번만 하면 모든 정보가 다 끌려 나온다.
┌──────────────────────────────────────────────────────────────┐
│           Kimball의 상향식 아키텍처와 스타 스키마 시각화                │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│ [ 🏗️ Kimball의 상향식 아키텍처 ]                                │
│ 운영 DB ─▶ [마케팅 마트] ─┐                                      │
│ 운영 DB ─▶ [영업 마트]   ├─▶ (이것들이 모여서 논리적인 전사 DW가 됨)   │
│ 운영 DB ─▶ [인사 마트]   ─┘                                      │
│                                                              │
│ [ 🌟 마트 내부의 스타 스키마 구조 ]                               │
│    [ 고객 차원 ]           [ 상품 차원 ]                       │
│           ↘                 ↙                              │
│              [ 주문 FACT ]      ◀── (매출액 10,000원)         │
│           ↗                 ↖                              │
│    [ 시간 차원 ]           [ 매장 차원 ]                       │
│                                                              │
│ ★ 특징: 무거운 FACT 테이블을 가운데 두고, 딱 한 번의 JOIN으로 차원 정보 획득!│
└──────────────────────────────────────────────────────────────┘

Ⅳ. 결론

"완벽함의 함정에 빠지지 마라. 시작이 반이다." IT 역사에서 Inmon(하향식)과 Kimball(상향식)의 논쟁은 짜장면과 짬뽕만큼 유명하다. 결과적으로 승자는 시대의 흐름을 탄 Kimball 쪽에 가깝다. 비즈니스 환경이 하루가 다르게 변하는 현대 사회에서, 3년짜리 전사 데이터 표준화 프로젝트(Inmon)는 시작하기도 전에 실패할 확률이 너무 높기 때문이다. 현대의 데이터 엔지니어들은 클라우드에 값싼 데이터 마트(Kimball)를 빠르게 찍어내서 마케터들에게 즉각적인 인사이트를 제공하는 민첩함(Agility)을 최우선으로 삼고 있다.

📌 관련 개념 맵

  • 대척점 아키텍처: Inmon의 하향식 접근법 (473번 문서)
  • 스키마 구조: Star Schema (스타 스키마 - 비정규화), Snowflake Schema (스노우플레이크 스키마 - 정규화)
  • 주요 구성요소: Fact Table (사실 테이블), Dimension Table (차원 테이블)
  • 관련 분야: OLAP (Online Analytical Processing)

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

  1. Inmon 아키텍처는 레고 블록 수만 개를 색깔별, 크기별로 완벽하게 정리한 '거대한 레고 창고'를 짓는 거예요. (시간이 오래 걸림)
  2. Kimball 아키텍처는 당장 내가 만들고 싶은 '자동차 레고 세트(데이터 마트)'만 따로 작은 상자에 담아서 바로 조립을 시작하는 거예요. (엄청 빠름)
  3. 나중에 이런 작은 세트 상자들을 여러 개 모아두면, 그게 결국 거대한 레고 창고(DW) 역할을 대신하게 되는 거랍니다!