473. 데이터 웨어하우스 (Data Warehouse)와 Inmon 아키텍처

⚠️ 이 문서는 쇼핑몰의 결제 DB, 인사팀의 직원 DB, 마케팅팀의 로그 DB 등 회사 전체에 흩어진 데이터들을 한곳에 긁어모아 사장이 한눈에 회사의 상태를 파악할 수 있도록 만든 '전사 통합 데이터 창고'인 데이터 웨어하우스와, 이를 구축하는 정석인 Inmon의 하향식(Top-Down) 접근법을 다룹니다.

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

  1. 본질: 의사결정 지원을 위해 회사 내의 모든 시스템에서 데이터를 추출(Extract), 변환(Transform), 적재(Load)하여 모아둔 거대한 읽기 전용(Read-only) 데이터베이스다.
  2. 특징 (4대 속성): 데이터는 주제 중심적(Subject-oriented)이고, 통합적(Integrated)이며, 시간에 따라 변하고(Time-variant), 한 번 저장되면 수정되지 않는다(Non-volatile).
  3. Inmon 방식 (하향식): "일단 회사 전체의 완벽한 데이터 창고(EDW)부터 지어라! 그리고 각 부서가 필요하면 그 창고에서 데이터를 빼서 작은 마트(Data Mart)를 차리게 해라!"라는 철학이다.

Ⅰ. 개요: 사장님의 분노 (Context & Necessity)

"이번 달 우리 회사가 마케팅 비용을 쓴 만큼 매출이 얼마나 올랐지?" 사장의 질문에 직원들은 식은땀을 흘린다.

  • 마케팅팀: "저희 DB에는 광고 클릭 수만 있는데요..."
  • 재무팀: "저희 DB에는 최종 결제 금액만 있는데요..."
  • 두 팀의 데이터를 합쳐야 하는데, 마케팅팀은 유저 ID를 user_id라고 쓰고 재무팀은 customer_no라고 써서 합치기(JOIN)가 너무 힘들다.

이 문제를 해결하려면 어떻게 해야 할까? 매일 밤 12시에 마케팅 DB와 재무 DB의 데이터를 싹 다 긁어와서, 이름과 포맷을 예쁘게 통일(정제)한 다음, **아주 거대한 제3의 데이터베이스(창고)**에 차곡차곡 쌓아두면 된다. 이 창고가 바로 **데이터 웨어하우스(DW)**다.

📢 섹션 요약 비유: 각 부서의 DB가 동네 구멍가게라면, 데이터 웨어하우스는 **'코스트코(창고형 대형 마트)'**와 같습니다. 전국 각지에서 올라온 물건(데이터)들을 코스트코 창고 하나에 통일된 박스 규격으로 예쁘게 쌓아두면, 사장님은 창고 한 바퀴만 돌아도 회사 전체의 재고를 1초 만에 파악할 수 있습니다.

Ⅱ. DW의 4가지 핵심 특성 ★

빌 인몬(Bill Inmon)이 정의한 데이터 웨어하우스의 절대 규칙 4가지다. 시험에 100% 출제된다.

1. 주제 중심적 (Subject-oriented)

  • 일반 DB는 '앱이 돌아가기 위한 기능' 중심이다. (예: 결제 테이블, 장바구니 테이블)
  • DW는 '사장이 분석하기 위한 주제' 중심이다. (예: 고객 테이블, 매출 테이블, 상품 테이블)

2. 통합적 (Integrated)

  • 여러 DB에서 날아온 데이터들의 일관성을 맞춘다.
  • A 시스템에선 남자를 'M', B 시스템에선 '1'이라고 쓰더라도, DW에 저장할 때는 무조건 'M'으로 **통합해서 변환(Transform)**하여 저장한다.

3. 비휘발성 (Non-volatile)

  • 일반 DB는 데이터가 수시로 수정(UPDATE), 삭제(DELETE)된다.
  • DW는 오직 **'쓰기(INSERT)'와 '읽기(SELECT)'**만 일어난다. 한 번 들어온 데이터는 역사적 기록이므로 절대 수정되거나 지워지지 않는다.

4. 시계열성 (Time-variant)

  • 데이터마다 "언제 수집된 데이터인가?"라는 스탬프(시간 정보)가 반드시 찍혀있다. 과거부터 현재까지의 변화(Trend)를 분석하기 위함이다.

Ⅲ. Inmon의 전사적 통합 (Top-Down) 아키텍처

데이터 웨어하우스를 짓는 방식에는 Inmon과 Kimball(474번 문서) 두 가지 철학이 팽팽하게 맞선다. **빌 인몬(Bill Inmon)**은 깐깐한 원칙주의자다.

  • 접근법: 하향식 (Top-Down)
  • 철학: "모래성 백날 지어봐야 무너진다. 처음부터 회사 전체를 아우르는 **단 하나의 완벽한 중앙 데이터 웨어하우스(EDW: Enterprise Data Warehouse)**를 튼튼하게 지어라!"
  • 과정:
    1. 전사 데이터 표준화 (이름, 타입 통일)
    2. 거대한 EDW 구축 (제3정규형을 깐깐하게 지켜서 데이터 중복을 없앰)
    3. 각 부서(영업팀, 마케팅팀)는 EDW에서 필요한 데이터만 빼내서 조그만 **데이터 마트(Data Mart)**를 구축해서 쓴다.
  • 장점: 회사 전체의 데이터가 100% 완벽하게 일치한다 (Single Version of Truth).
  • 단점: 첫 삽을 뜨고 EDW를 완공하기까지 수년이 걸리며, 돈이 엄청나게 깨진다.
┌──────────────────────────────────────────────────────────────┐
│           Inmon의 하향식(Top-Down) 데이터 웨어하우스 아키텍처           │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│  [ 운영 DB들 ]                                                │
│  영업 DB ─┐             ┌─▶ 영업팀 Data Mart (조그만 창고)       │
│  재무 DB ─┼─▶ 🏢 전사 DW ─┼─▶ 마케팅팀 Data Mart (조그만 창고)     │
│  인사 DB ─┘  (제3정규형)   └─▶ 임원용 Data Mart (조그만 창고)       │
│                                                              │
│ ★ 특징: 모든 데이터는 반드시 거대한 '전사 DW'를 거쳐야만 각 부서로 나갈 수 있다.│
└──────────────────────────────────────────────────────────────┘

Ⅳ. 결론

"완벽한 통합은 위대하지만, 비즈니스는 기다려주지 않는다." Inmon의 EDW 사상은 대기업, 은행, 통신사처럼 데이터의 정합성이 목숨과도 같은 곳에서 여전히 훌륭한 아키텍처로 칭송받는다. 하지만 스타트업이나 애자일 조직에서는 수년 동안 데이터 표준화 회의만 하다가 회사가 망해버릴 수도 있다. 따라서 실무에서는 이 무겁고 거대한 Inmon 방식 대신, 일단 부서별로 작게 창고를 먼저 만들고 나중에 합치는 Kimball의 상향식(Bottom-Up) 방식과 섞어 쓰거나, 클라우드 시대에 맞춰 데이터 레이크(Data Lake)라는 새로운 형태로 진화하고 있다.

📌 관련 개념 맵

  • 핵심 대척점: Ralph Kimball의 상향식(Bottom-Up) 아키텍처 (474번 문서)
  • 필수 파이프라인: ETL (Extract, Transform, Load - 데이터를 뽑아서 변환하고 싣는 과정)
  • 파생 개념: Data Mart (데이터 마트 - 특정 부서용 미니 DW)
  • 최신 트렌드: Data Lake (정제하지 않은 원본 데이터를 그냥 다 때려 박는 늪지대)

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

  1. 운영 DB가 각자의 방(내 방, 동생 방)이라면, 데이터 웨어하우스는 집안의 물건을 모두 모아두는 거실의 '거대한 공용 장롱'이에요.
  2. 장롱에 물건을 넣을 때는 아무렇게나 던져 넣지 않고, '여름옷', '겨울옷'처럼 아주 예쁜 바구니에 묶어서(주제 중심) 한 번 넣으면 절대 안 버리죠(비휘발성).
  3. Inmon 아키텍처는 "일단 거실에 세상에서 제일 크고 완벽한 장롱부터 짠 다음에, 각자 방에 필요한 작은 수납장(마트)을 가져가서 써라!"라고 명령하는 깐깐한 엄마의 정리법이랍니다.