221. 데이터 웨어하우스 (Data Warehouse / DW)

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

본질: 데이터 웨어하우스(DW)는 경영 의사결정을 위한 정제·통합 정형 데이터의 중앙 저장소로, BI 리포트와 OLAP 분석에 최적화된 고비용 고성능 플랫폼이다.

가치: ETL을 통해 여러 운영 시스템의 데이터를 단일 진실의 공급원(Single Source of Truth)으로 통합하여, 일관된 기업 지표를 전사에 제공한다.

판단 포인트: 클라우드 DW(Snowflake·BigQuery·Redshift)는 스토리지와 컴퓨팅을 분리하여 독립적 스케일링이 가능하며, 온프레미스 DW 대비 운영 비용과 확장성에서 혁신적 우위를 제공한다.

Ⅰ. 개요 및 필요성

1980년대 Bill Inmon이 제창하고 1990년대 Ralph Kimball이 차원 모델링 방법론으로 체계화한 데이터 웨어하우스(Data Warehouse, DW)는, 기업의 다양한 운영 시스템(ERP, CRM, SCM 등)에 흩어진 데이터를 통합·정제·구조화하여 경영 분석에 제공하는 플랫폼이다.

운영 DB(OLTP)는 초당 수천 건의 트랜잭션 처리에 최적화되어 있어, 대규모 집계·분석 쿼리를 실행하면 서비스 성능에 영향을 준다. DW는 이를 물리적으로 분리하여 분석 전용 환경을 제공한다.

[기업 데이터 흐름]
┌─────────────┐  ┌─────────────┐  ┌─────────────┐
│  ERP 시스템  │  │  CRM 시스템  │  │  SCM 시스템  │
│  (운영 DB)  │  │  (운영 DB)  │  │  (운영 DB)  │
└──────┬──────┘  └──────┬──────┘  └──────┬──────┘
       │                │                │
       └────────────────┼────────────────┘
                        ↓  ETL (야간 배치)
               ┌────────────────┐
               │  Data Warehouse │
               │  (통합·정제 데이터)│
               └───────┬────────┘
                       │
            ┌──────────┼──────────┐
            ↓          ↓          ↓
         BI 도구    OLAP 분석   데이터 마트
        (Tableau) (집계쿼리)  (부서별 뷰)

📢 섹션 요약 비유: DW는 기업의 "중앙 도서관"이다. 각 부서(운영 DB)가 직접 만든 장부(데이터)를 밤마다 복사·정리해 중앙 도서관에 보관하고, 경영진이 언제든 전사적 통계를 조회할 수 있도록 한다.

Ⅱ. 아키텍처 및 핵심 원리

클라우드 DW 아키텍처 (스토리지-컴퓨팅 분리)

┌──────────────────────────────────────────────────────┐
│              클라우드 DW 아키텍처                       │
│                                                      │
│  소스 시스템 → ETL/ELT → ┌──────────────────────┐   │
│                          │  공유 스토리지 계층     │   │
│                          │  (S3/GCS/Azure Blob)  │   │
│                          │  컬럼 압축 Parquet     │   │
│                          └──────────┬───────────┘   │
│                                     │               │
│          ┌──────────────────────────┴─────┐         │
│          │     컴퓨팅 클러스터 (독립 스케일)│         │
│          │  ┌────────┐  ┌────────┐         │         │
│          │  │ 가상웨어│  │ 가상웨어│  ...    │         │
│          │  │ 하우스 1│  │ 하우스 2│         │         │
│          │  │(BI팀)  │  │(데이터팀)│         │         │
│          │  └────────┘  └────────┘         │         │
│          └────────────────────────────────┘         │
└──────────────────────────────────────────────────────┘

핵심 기술 요소

구성 요소	역할
스타 스키마 (Star Schema)	팩트 테이블 + 차원 테이블 구조, 쿼리 단순화
스노우플레이크 스키마	차원 테이블 정규화, 저장 효율 ↑ / 조인 복잡도 ↑
컬럼 지향 저장	SELECT 시 필요 열만 읽어 I/O 절감
MPP (Massively Parallel Processing)	수백 노드 병렬 쿼리 처리
구체화 뷰 (Materialized View)	반복 집계 쿼리 사전 계산 저장
파티셔닝/클러스터링	날짜·카테고리 기준 데이터 분할로 쿼리 범위 축소

📢 섹션 요약 비유: 클라우드 DW의 스토리지-컴퓨팅 분리는 창고(데이터)와 지게차(컴퓨팅)를 분리한 것이다. 바쁜 날(분석 집중)엔 지게차만 늘리고, 한산한 날엔 줄이면 되므로 창고 크기와 무관하게 운영 비용을 최적화할 수 있다.

Ⅲ. 비교 및 연결

클라우드 DW 3대 서비스 비교

비교 항목	Snowflake	Google BigQuery	Amazon Redshift
아키텍처	스토리지-컴퓨팅 완전 분리	서버리스 MPP	클러스터 기반 MPP
가격 모델	컴퓨팅 크레딧 + 스토리지 분리 과금	쿼리 스캔 바이트 과금	노드 시간 과금
확장성	Virtual Warehouse 즉시 확장	자동 확장 (서버리스)	클러스터 리사이즈 필요
멀티 클라우드	AWS/GCP/Azure 모두 지원	GCP 전용	AWS 전용
ML 통합	Snowpark (Python/Java 내부 실행)	BigQuery ML	Redshift ML (SageMaker 연동)
고유 강점	데이터 공유(Data Sharing)	비정형 데이터 분석	AWS 에코시스템 통합
적합 사례	멀티클라우드 기업, 외부 데이터 공유	GCP 기반 스타트업, 분석 우선	AWS 전용 기업, 기존 Redshift 전환

DW vs DL(데이터 레이크) vs DLH(레이크하우스)

특성	DW	Data Lake	Lakehouse
데이터 유형	정형	모든 유형	모든 유형
스키마	Schema-on-Write	Schema-on-Read	둘 다 지원
품질	높음	낮음~중간	높음
비용	고비용	저비용	중간
ACID 트랜잭션	지원	미지원	지원 (Delta/Iceberg)

📢 섹션 요약 비유: DW·DL·DLH는 식당에서 음식 관리하는 세 가지 방식이다. DW는 미리 다 조리해 냉장고에 넣는 것(빠르지만 유연성 없음), DL은 재료를 날것으로 쌓는 것(유연하지만 위생 우려), DLH는 반조리 상태로 정리한 것(두 장점 모두)이다.

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

DW 설계: Star Schema vs Snowflake Schema

[Star Schema - 팩트 중심 비정규화]
           ┌──────────────┐
           │  날짜 차원    │
           └──────┬───────┘
                  │
┌──────────┐  ┌───┴──────────────┐  ┌──────────┐
│ 상품 차원 │──│  매출 팩트 테이블  │──│ 고객 차원 │
└──────────┘  │ (주문ID, 날짜ID,  │  └──────────┘
              │  상품ID, 고객ID,  │
              │  금액, 수량)      │
              └──────────────────┘

실무 적용 지침

상황	권장 선택
복잡한 집계 분석, 고정 리포트	DW (BigQuery, Snowflake)
ML 학습, 탐색적 분석, 비정형	Data Lake (S3 + Glue)
ACID + 유연성 + 저비용 모두 필요	Lakehouse (Delta Lake)
AWS 생태계 all-in	Redshift + S3 + Glue
GCP 기반	BigQuery + Cloud Storage
멀티클라우드·외부 데이터 공유	Snowflake

기술사 핵심 판단: DW 선택 시 스토리지-컴퓨팅 분리 여부와 MPP 아키텍처를 설명하고, 조직의 클라우드 전략(단일 CSP vs 멀티)에 따라 서비스를 차별화하여 제안한다.

📢 섹션 요약 비유: DW 선택은 식당 종류 선택과 같다. 패스트푸드(Redshift, 이미 AWS 사용 중)는 빠르지만 제약이 있고, 뷔페(BigQuery, GCP)는 먹는 만큼 내며, 프랜차이즈 체인(Snowflake)은 어디서나 같은 맛(멀티클라우드)을 제공한다.

Ⅴ. 기대효과 및 결론

기대효과

효과	정량 기준
쿼리 성능	OLTP 대비 분석 쿼리 10~1000배 빠른 응답
운영 DB 보호	분석 쿼리로 인한 운영 서비스 간섭 제거
데이터 일관성	전사 KPI 정의 통일, 부서간 숫자 불일치 제거
의사결정 속도	임원 대시보드 T+1일 → T+수분 단위 갱신

한계 및 주의점

한계	내용
비용	클라우드 DW는 쿼리·스토리지 과금으로 월 수백만 원 발생 가능
Schema Agility 부족	스키마 변경 시 ETL 파이프라인 전체 수정 필요
비정형 데이터 처리 한계	JSON 중첩 구조, 이미지 등 처리 불리
지연 시간	ETL 배치 주기(야간)로 실시간성 제한 (ELT 또는 스트리밍 연동 필요)

📢 섹션 요약 비유: DW는 잘 정리된 도서관과 같다. 원하는 책(데이터)을 빠르게 찾을 수 있지만, 새 책(스키마 변경)을 들이려면 사서(ETL 엔지니어)가 전체 목록(파이프라인)을 다시 정리해야 하는 번거로움이 있다.

📌 관련 개념 맵

개념	연결 포인트
Schema-on-Write	DW의 ETL 기반 데이터 품질 보장 전략
데이터 마트	DW의 서브셋, 부서별 특화 저장소
OLAP	DW의 주요 쿼리 패턴 (다차원 집계)
Star Schema	DW 물리 설계의 핵심 패턴
ETL	DW 적재를 위한 전통적 데이터 통합 방식
ELT	클라우드 DW 시대의 새로운 적재 패턴
MPP	DW 쿼리 병렬화 아키텍처 원리

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

데이터 웨어하우스는 회사의 모든 서류를 깨끗이 정리해 보관하는 중앙 서류함이다. 영업팀, 재무팀 서류를 모두 통일된 형식으로 정리해두면, 사장님이 언제든 빠르게 찾아볼 수 있다.

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

OLTP (트랜잭션 처리, 행 기반)
    │
    ▼
Data Warehouse: OLAP · Star/Snowflake 스키마
    ├─► BigQuery · Snowflake · Redshift
    └─► Schema-on-Write · 컬럼 지향 저장
    │
    ▼
Lakehouse: DW + Lake 통합 (Delta Lake · Iceberg)

마치 도서관 사서처럼, 밤마다(ETL 야간 배치) 각 교실(운영 DB)에서 중요한 내용을 가져와 도서관(DW)에 깔끔하게 분류해 넣는다.
BigQuery·Snowflake·Redshift는 같은 서류함이지만, 각각 Google·중립·Amazon 건물에 있는 셈이다. 어느 건물에 이미 살고 있느냐에 따라 선택이 달라진다.