209. 데이터 웨어하우스 (Data Warehouse)

핵심 인사이트

본질: 데이터 웨어하우스(DW)는 Schema-on-Write(쓰기 시점 스키마 정의) 방식으로 이질적인 운영 시스템의 데이터를 통합 정제하여 분석 전용 관계형 저장소에 적재하는 의사결정 지원 시스템이다.

가치: OLAP(Online Analytical Processing, 온라인 분석 처리) 쿼리 최적화를 위해 스타/스노우플레이크 스키마로 설계된 DW는 수십억 건 데이터에서 수초 내 집계를 가능케 하며, Kimball/Inmon 두 방법론은 각각 비즈니스 프로세스 중심·기업 통합 중심으로 상호 보완적이다.

판단 포인트: 정형 데이터·고정 스키마·반복 집계 쿼리 환경이면 DW가 최적이며, 비정형·유연 스키마·탐색적 분석 요구 시 Data Lake 또는 Lakehouse로 전환을 검토해야 한다.

Ⅰ. 개요 및 필요성

1.1 데이터 웨어하우스의 탄생 배경

기업의 ERP(Enterprise Resource Planning), CRM(Customer Relationship Management), SCM(Supply Chain Management) 등 운영 시스템은 OLTP(Online Transaction Processing, 온라인 트랜잭션 처리)에 최적화되어 있어, 수천 개 테이블에 정규화된 데이터를 빠르게 삽입·수정·삭제한다. 그러나 경영진이 원하는 "지난 5년간 분기별 제품 카테고리별 수익성 추이"와 같은 분석 쿼리는 수십 개 테이블을 조인하며 운영 시스템에 과부하를 준다.

이를 해결하기 위해 1980년대 Bill Inmon이 DW 개념을 제안했다. DW는 운영 시스템으로부터 ETL(Extract-Transform-Load, 추출·변환·적재) 프로세스를 통해 데이터를 주기적으로 수집·정제·통합하여 분석 전용 저장소에 유지한다. DW의 4대 특성은 주제 지향성(Subject-Oriented), 통합성(Integrated), 시간 가변성(Time-Variant), **비휘발성(Non-Volatile)**이다.

1.2 Schema-on-Write 패러다임

DW의 핵심 패러다임은 Schema-on-Write(쓰기 시점 스키마 확정)이다. 데이터를 저장하기 전에 스키마를 엄격히 정의하고, 모든 데이터가 해당 스키마에 부합하도록 변환·검증한다. 이 방식은 데이터 품질을 보장하고 쿼리 성능을 극대화하지만, 스키마 변경 비용이 높고 비정형 데이터를 수용하기 어렵다는 트레이드오프가 있다.

📢 섹션 요약 비유: DW는 도서관의 서가 정리 시스템과 같다. 책이 들어오는 즉시 분류 기호를 붙이고(Schema-on-Write), 제자리에 꽂아두어야만(ETL 정제) 독자가 원하는 책을 수초 안에 찾을 수 있다. 반면 바닥에 아무렇게나 쌓으면 나중에 찾는 데 시간이 더 걸린다.

Ⅱ. 아키텍처 및 핵심 원리

2.1 Kimball vs Inmon 방법론

항목	Kimball (Bottom-Up)	Inmon (Top-Down)
접근법	비즈니스 프로세스별 Data Mart 우선 구축	기업 통합 EDW(Enterprise Data Warehouse) 먼저 설계
스키마	스타/스노우플레이크 Dimensional Modeling	3NF 정규화 → Data Mart 파생
구축 속도	빠름 (개별 마트 우선)	느림 (전사 통합 우선)
일관성	마트 간 불일치 위험	높은 일관성
대표 기업	소·중규모 분석 팀	대형 금융·보험사

2.2 스타 스키마 (Star Schema) 구조

┌─────────────────────────────────────────────────────┐
│              Star Schema Architecture               │
│                                                     │
│   ┌──────────┐        ┌────────────────┐           │
│   │ DIM_DATE │        │   FACT_SALES   │           │
│   │──────────│        │────────────────│           │
│   │ date_id  │◄───────│ date_id   (FK) │           │
│   │ year     │        │ product_id(FK) │           │
│   │ quarter  │        │ customer_id(FK)│           │
│   │ month    │        │ store_id  (FK) │           │
│   └──────────┘        │ sales_amt      │           │
│                       │ qty_sold       │           │
│   ┌──────────┐        │ discount       │           │
│   │DIM_PROD  │        └────────────────┘           │
│   │──────────│◄───────────────┘  │                 │
│   │product_id│                   │                 │
│   │category  │        ┌──────────┘                 │
│   │brand     │        ▼                             │
│   └──────────┘   ┌──────────┐  ┌──────────┐       │
│                  │DIM_CUST  │  │DIM_STORE │       │
│                  │──────────│  │──────────│       │
│                  │cust_id   │  │store_id  │       │
│                  │segment   │  │region    │       │
│                  └──────────┘  └──────────┘       │
└─────────────────────────────────────────────────────┘

2.3 OLAP 큐브와 집계 연산

OLAP(Online Analytical Processing) 큐브는 다차원 데이터 모델로, Drill-Down(상세 분석), Roll-Up(상위 집계), Slice(단면 분석), Dice(다면 분석), Pivot(차원 전환) 연산을 지원한다. MOLAP(Multidimensional OLAP)은 큐브를 사전 계산해 성능이 높고, ROLAP(Relational OLAP)은 관계형 DB를 그대로 활용해 유연성이 높다.

📢 섹션 요약 비유: 팩트 테이블은 슈퍼마켓 영수증 묶음이고, 차원 테이블은 상품·고객·날짜 정보가 담긴 색인 카드다. 스타 스키마는 영수증 묶음 주위에 색인 카드를 별 모양으로 배치해 "어느 날, 어느 고객이, 어느 상품을 얼마에 샀는지"를 초고속으로 집계한다.

Ⅲ. 비교 및 연결

3.1 DW vs 운영 DB vs Data Lake

항목	OLTP DB	Data Warehouse	Data Lake
목적	트랜잭션 처리	분석·리포팅	원시 데이터 보관
스키마	정규화 (3NF)	비정규화 (스타)	Schema-on-Read
데이터 유형	정형	정형	정형·반정형·비정형
쿼리 패턴	단건 CRUD	집계·분석 쿼리	탐색적 분석·ML
응답 시간	ms 단위	초~분 단위	분 단위
저장 비용	높음	중간	낮음

3.2 DW 성숙도 모델 (Maturity Model)

단계	설명	특징
Level 1: 보고 DW	단순 집계 리포트	정기 배치, 고정 리포트
Level 2: 분석 DW	셀프서비스 BI	Ad-hoc 쿼리, OLAP
Level 3: 예측 DW	ML 모델 통합	Feature Store 연계
Level 4: 실시간 DW	스트리밍 ETL	Lambda/Kappa 아키텍처

📢 섹션 요약 비유: DW는 복잡한 도시 교통망을 한눈에 보여주는 종합 관제 센터다. OLTP가 개별 신호등이라면, DW는 전체 도시의 교통 흐름을 분석해 "출퇴근 혼잡 패턴"을 알려주는 컨트롤 타워다.

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

4.1 클라우드 DW 솔루션 비교

제품	특징	최적 환경
Snowflake	컴퓨트·스토리지 완전 분리, 멀티클라우드	가변 워크로드, 비용 최적화
BigQuery	서버리스, 콜럼나(Columnar) 스토리지	GCP 네이티브, 데이터 과학
Redshift	MPP(Massively Parallel Processing), Spectrum	AWS 생태계, 온프레미스 연계
Azure Synapse	통합 분석 플랫폼	마이크로소프트 365 연계

4.2 기술사 출제 포인트

Kimball vs Inmon 비교: 접근 방향, 스키마 설계, 장단점을 반드시 표로 비교 설명
스타 vs 스노우플레이크 스키마: 스노우플레이크는 차원 테이블을 추가 정규화하여 중복을 줄이지만 조인이 복잡해진다는 트레이드오프
SCD(Slowly Changing Dimension, 완만히 변하는 차원): Type 1(덮어쓰기), Type 2(이력 유지), Type 3(이전 값 컬럼 추가) 처리 방식
데이터 마트(Data Mart): DW의 부분집합으로 특정 부서·업무에 특화된 소규모 DW

4.3 SCD Type 2 이력 관리 예시

고객 차원 테이블 (SCD Type 2 적용)
┌─────┬──────────┬────────┬────────────┬────────────┬────────┐
│ SK  │ cust_id  │ region │ start_date │  end_date  │current │
├─────┼──────────┼────────┼────────────┼────────────┼────────┤
│  1  │  C001    │ 서울   │ 2020-01-01 │ 2023-06-30 │   N    │
│  2  │  C001    │ 부산   │ 2023-07-01 │ 9999-12-31 │   Y    │
└─────┴──────────┴────────┴────────────┴────────────┴────────┘

📢 섹션 요약 비유: SCD Type 2는 고객의 이사 이력을 남겨두는 주민등록 등본과 같다. 과거 주소가 지워지지 않고 유효 기간과 함께 보존되어, "2022년 기준 서울 거주 고객 매출"도 정확히 집계할 수 있다.

Ⅴ. 기대효과 및 결론

5.1 DW 도입 기대효과

효과	내용
의사결정 속도 향상	분석 쿼리 응답시간 운영 DB 대비 10~100배 단축
데이터 일관성 확보	단일 진실 원천(Single Source of Truth) 구현
운영 DB 부하 분리	분석 쿼리를 DW로 격리해 운영 시스템 안정성 보장
비즈니스 민첩성	셀프서비스 BI를 통해 현업이 직접 분석 수행

5.2 한계 및 발전 방향

DW는 스키마 변경 비용이 높고, 비정형 데이터(로그·이미지·텍스트)를 수용하기 어렵다. 이를 극복하기 위해 Data Lake와 결합한 Lambda Architecture 또는 완전 통합된 Lakehouse Architecture로 진화하고 있다. 또한 실시간 스트리밍 데이터를 수용하기 위해 Near-Real-Time ETL과 스트리밍 DW 개념이 도입되고 있다.

DW는 데이터 기반 의사결정의 핵심 인프라로, 클라우드 시대에도 BigQuery, Snowflake, Redshift 등으로 진화하며 기업 분석의 중심축을 유지하고 있다.

📢 섹션 요약 비유: DW는 기업의 "기억 궁전(Memory Palace)"이다. 모든 과거 데이터가 체계적으로 정리되어 있어, "3년 전 이맘때 베스트셀러 제품은?"이라는 질문에 즉각 답할 수 있다. 단, 새로운 방을 추가하려면 건축 설계를 다시 해야 한다는 제약이 있다.

📌 관련 개념 맵

개념	설명	연관 키워드
OLAP (Online Analytical Processing)	다차원 데이터 분석 엔진	큐브, Drill-Down, Roll-Up
ETL (Extract-Transform-Load)	DW 적재 프로세스	데이터 파이프라인, 배치 처리
스타 스키마 (Star Schema)	팩트+차원 테이블 비정규화 설계	Kimball, Data Mart
SCD (Slowly Changing Dimension)	차원 테이블 이력 관리 방식	Type 1/2/3, 이력 보존
Kimball 방법론	Bottom-Up Data Mart 우선 설계	Dimensional Modeling
Inmon 방법론	Top-Down EDW 우선 설계	3NF, 기업 통합
Data Mart	부서별 특화 소규모 DW	셀프서비스 BI
MPP (Massively Parallel Processing)	대규모 병렬 쿼리 처리	Redshift, Snowflake

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

데이터 웨어하우스는 학교 도서관처럼, 책(데이터)을 가져올 때 반드시 분류 번호를 붙여서(Schema-on-Write) 정해진 자리에 꽂아두는 곳이야.
스타 스키마는 마치 햇빛이 가운데 해(팩트 테이블)에서 여러 방향으로 퍼지는 것처럼, 영수증 묶음(판매 사실) 주위에 고객·상품·날짜 카드를 별 모양으로 배치한 거야.
Kimball은 반 교실(부서)마다 먼저 꾸미고 나중에 합치는 방식이고, Inmon은 학교 전체 설계도를 먼저 그린 뒤 각 교실을 꾸미는 방식이야.