데이터 웨어하우스 방법론

2. 데이터 웨어하우스 방법론

2.1 Kimball 방법론 (Bottom-Up)

Ralph Kimball이 제안한 방법론으로, 비즈니스 프로세스 단위로 데이터 마트(Data Mart)를 먼저 구축한 후 이를 통합하는 상향식 접근입니다.

핵심 원칙:

• 비즈니스 프로세스 중심의 차원 모델링
• Star Schema를 기본 구조로 사용
• Conformed Dimensions(일치된 차원)을 통한 데이터 마트 간 통합
• "Bus Architecture"로 전사적 일관성 확보

장점:

• 빠른 ROI: 개별 데이터 마트 단위로 빠르게 가치 제공
• 직관적 구조: 비즈니스 사용자가 이해하기 쉬움
• BI 도구와 높은 호환성
• 상대적으로 낮은 구현 복잡도

단점:

• 전사적 일관성 확보에 추가 노력 필요 (Conformed Dimensions 관리)
• 비즈니스 요구사항 변경 시 기존 모델 수정이 어려울 수 있음
• 데이터 중복으로 저장 비용 증가

적합 상황: 빠른 비즈니스 가치 전달이 필요한 경우, 명확한 분석 요구사항이 있는 경우, 중소규모 조직

실무 예시: 이커머스 회사에서 "매출 분석" 데이터 마트를 먼저 구축하고, 이후 "고객 행동 분석", "재고 관리" 데이터 마트를 순차적으로 추가하면서 dim_customer, dim_product, dim_date 등의 일치된 차원으로 통합

2.2 Inmon 방법론 (Top-Down)

Bill Inmon이 제안한 방법론으로, 중앙집중식 엔터프라이즈 데이터 웨어하우스(EDW)를 먼저 구축한 후 필요에 따라 데이터 마트를 파생하는 하향식 접근입니다.

핵심 원칙:

• 엔터프라이즈 수준의 정규화된(3NF) 중앙 데이터 모델
• "단일 진실의 소스(Single Source of Truth)" 구축
• EDW에서 데이터 마트로의 파생
• 주제 지향적(Subject-Oriented), 통합적(Integrated), 시간 변이적(Time-Variant), 비휘발성(Non-Volatile)

장점:

• 전사적 데이터 일관성 보장
• 데이터 중복 최소화
• 유연한 분석 지원 (다양한 데이터 마트 파생 가능)
• 데이터 거버넌스에 유리

단점:

• 초기 구축에 많은 시간과 비용 소요
• 복잡한 모델로 인한 높은 기술 장벽
• ROI 실현까지 오랜 시간 필요
• 단일 모델에 대한 합의 과정이 대기업일수록 길어짐

적합 상황: 대규모 엔터프라이즈 환경, 엄격한 데이터 거버넌스가 필요한 조직, 장기적 데이터 전략이 있는 경우

실무 예시: 대형 금융기관에서 고객, 계좌, 거래, 상품 등 전사 엔티티를 3NF로 통합한 중앙 EDW를 구축하고, 리스크 관리팀, 마케팅팀, 재무팀이 각각 필요한 데이터 마트를 파생하여 사용

2.3 Data Vault 2.0

Dan Linstedt가 고안한 방법론으로, Kimball과 Inmon의 장점을 결합하면서 현대적 데이터 환경의 요구사항(빠른 변화, 대규모 통합, 감사 추적)을 해결하기 위해 설계되었습니다.

핵심 원칙:

• Hub + Link + Satellite 구조
• 모든 데이터의 완전한 이력 보존
• 병렬 로드 최적화
• 비즈니스 키 기반 통합
• 소프트 비즈니스 규칙(Soft Business Rules)과 하드 비즈니스 규칙(Hard Business Rules) 분리

장점:

• 새 데이터 소스 추가가 매우 용이 (기존 구조에 영향 없음)
• 완전한 감사 추적 및 데이터 계보(Lineage) 관리
• 병렬 개발/로드 가능으로 애자일 개발에 적합
• 규제 산업(금융, 헬스케어, 공공)에서 컴플라이언스 요구사항 충족

단점:

• 높은 학습 곡선
• 최종 사용자를 위한 별도의 프레젠테이션 레이어(Data Mart) 필수
• 소규모 프로젝트에서는 과도한 복잡성
• 성능 오버헤드 (조인 수 증가)

적합 상황: 대규모 데이터 통합 프로젝트, 규제 산업, 빈번한 소스 시스템 변경이 있는 환경, 감사 추적이 중요한 경우

실무 예시: 글로벌 보험사에서 20개 이상의 소스 시스템(보험 계약, 클레임, 고객 관리, 파트너 등)을 통합할 때, Data Vault로 Raw Vault를 구축하고 비즈니스 규칙은 Business Vault에서 적용, 최종 분석은 Information Mart(Star Schema)에서 제공

2.4 방법론 비교

비교 항목	Kimball	Inmon	Data Vault	OBT
접근 방식	Bottom-Up	Top-Down	하이브리드	비정규화
복잡도	중-하	높음	높음	낮음
쿼리 성능	우수	좋음	좋음	우수
유연성	높음	중간	매우 높음	중간
정규화 수준	비정규화	정규화(3NF)	하이브리드	완전 비정규화
초기 구축 속도	빠름	느림	중간	매우 빠름
이력 관리	SCD로 관리	시간 변이적 설계	기본 내장	스냅샷 방식
데이터 중복	있음	최소	있음 (Satellite)	매우 높음
적합 조직	중소규모	대규모 엔터프라이즈	대규모/규제 산업	소규모/특정 용도

2.5 상호보완적 구조

실무에서 이 방법론들은 배타적이 아니라 상호보완적으로 사용됩니다:

• Inmon + Kimball: 중앙 EDW는 Inmon 방식(3NF)으로, 데이터 마트는 Kimball 방식(Star Schema)으로 구축하는 것이 가장 전통적인 조합입니다
• Data Vault + Kimball: Raw Vault에서 데이터를 통합/이력 관리하고, 소비 레이어에서 Kimball의 Star Schema로 제공하는 현대적 조합입니다
• Lakehouse + Data Vault: 데이터 레이크에 Data Vault 구조를 적용하여 유연성과 거버넌스를 동시에 확보합니다

🔑

핵심 메시지: 방법론 선택은 이분법적 결정이 아닙니다. 조직의 규모, 데이터 성숙도, 비즈니스 요구사항에 따라 여러 방법론을 레이어별로 조합하는 것이 현대적 모범 사례입니다.

---

2.6 ETL vs ELT

데이터 웨어하우스에 데이터를 적재하는 두 가지 대표적인 파이프라인 패턴입니다. 전통적인 ETL과 현대적인 ELT는 변환(Transform)이 일어나는 위치에 근본적인 차이가 있습니다.

ETL (Extract → Transform → Load)

전통적인 데이터 파이프라인 방식으로, 외부 서버에서 데이터를 변환한 후 DWH에 적재합니다.

처리 흐름:

1. Extract: 소스 시스템(RDBMS, API, 파일 등)에서 데이터 추출
2. Transform: 별도의 ETL 서버에서 정제, 변환, 집계 수행
3. Load: 변환된 결과만 DWH에 적재

대표 도구: Informatica, IBM DataStage, SSIS, Talend

적합 환경:

• 온프레미스 DWH 환경
• PII(개인식별정보) 마스킹이 적재 전에 반드시 필요한 경우
• 데이터 볼륨이 작고 변환 로직이 단순한 경우
• 레거시 시스템과의 통합이 필요한 경우

ELT (Extract → Load → Transform)

현대적인 데이터 파이프라인 방식으로, DWH에 원시 데이터를 그대로 적재한 후 DWH 내부에서 변환합니다.

처리 흐름:

1. Extract: 소스 시스템에서 데이터 추출
2. Load: 원시 데이터를 DWH에 그대로 적재
3. Transform: DWH의 컴퓨팅 파워를 활용하여 내부에서 변환

대표 도구: Fivetran / Airbyte (EL 담당) + dbt (T 담당)

적합 환경:

• 클라우드 DWH 환경 (BigQuery, Snowflake, Redshift, Databricks)
• 원시 데이터 보존 및 재처리가 필요한 경우
• 분석가가 SQL로 직접 변환 로직을 관리하고자 하는 경우

ETL vs ELT 비교표

항목	ETL	ELT
변환 위치	외부 서버	DWH 내부
원시 데이터 보존	❌	✅
확장성	서버 사양 의존	클라우드 스케일
개발 속도	느림	빠름 (SQL/dbt)
비용 구조	고정 서버 비용	컴퓨팅 사용량 기반
재처리 가능성	제한적	✅
주요 환경	온프레미스	클라우드 DWH

언제 ETL을 선택하는가?

• PII 데이터를 DWH 적재 전 마스킹해야 할 때: 규제(GDPR, CCPA 등) 요구사항으로 원시 개인정보가 DWH에 저장되면 안 되는 경우
• 온프레미스 레거시 시스템: 클라우드 마이그레이션 전 기존 인프라를 활용해야 하는 경우
• 데이터 볼륨이 작고 변환 로직이 단순할 때: 별도의 클라우드 DWH 컴퓨팅 비용 없이 ETL 서버에서 처리가 충분한 경우

언제 ELT를 선택하는가?

• 클라우드 DWH 환경 (BigQuery, Snowflake, Redshift, Databricks): DWH의 강력한 컴퓨팅 파워를 변환에 직접 활용할 수 있는 경우
• 원시 데이터 보존 및 재처리가 필요할 때: 비즈니스 규칙 변경 시 원시 데이터부터 다시 변환할 수 있어야 하는 경우
• 분석가가 SQL로 직접 변환 로직 관리를 원할 때: dbt 등의 도구를 통해 분석가가 데이터 변환의 주체가 되는 조직 문화

💡

실무 팁: 현대 데이터 스택에서는 ELT가 표준으로 자리잡고 있지만, ETL이 완전히 사라진 것은 아닙니다. 보안 요구사항이 엄격한 환경에서는 ETL 방식의 사전 마스킹이 여전히 필수적입니다. 많은 조직이 두 패턴을 혼합하여 사용합니다.

---

2.7 Kimball Bus Matrix

정의

Kimball Bus Matrix는 비즈니스 프로세스(Fact Table)와 차원(Dimension Table)의 관계를 격자(Matrix)로 표현한 DWH 설계 도구입니다. Ralph Kimball이 제안한 "Bus Architecture"의 핵심 산출물로, 전사적 데이터 웨어하우스의 청사진 역할을 합니다.

Bus Matrix 예시 (이커머스)

아래는 이커머스 플랫폼의 주요 비즈니스 프로세스와 차원 간의 관계를 Bus Matrix로 표현한 예시입니다.

	dim_date	dim_customer	dim_product	dim_store	dim_supplier
fact_sales	✅	✅	✅	✅	❌
fact_inventory	✅	❌	✅	✅	✅
fact_returns	✅	✅	✅	✅	❌
fact_web_events	✅	✅	✅	❌	❌

활용법

• ✅: 해당 Fact Table이 이 Dimension을 외래키로 참조한다는 의미입니다
• 여러 Fact에서 공유되는 Dimension = Conformed Dimension (일치된 차원)입니다. 위 예시에서 dim_date, dim_product는 모든 Fact Table에서 공유되므로 대표적인 Conformed Dimension입니다
• 개발 우선순위 결정 및 신규 Data Mart 설계에 활용합니다. 공유 차원이 많은 Fact부터 개발하면 재사용성이 극대화됩니다

Bus Matrix 작성 절차

1. 비즈니스 프로세스 목록 정의: 각 행(Row)이 하나의 Fact Table에 대응합니다. 조직의 핵심 비즈니스 프로세스(매출, 재고, 반품, 웹 이벤트 등)를 식별합니다
2. 각 프로세스의 핵심 차원 식별: 각 Fact Table이 참조하는 Dimension을 파악하여 열(Column)에 배치합니다
3. 공유 가능한 Dimension을 Conformed Dimension으로 지정: 여러 Fact에서 동일한 정의로 사용되는 차원을 식별하고, 일관된 구조와 키로 통일합니다
4. 행렬 작성 → 공백이 많은 Dimension은 재설계 검토: 특정 차원이 거의 사용되지 않는다면, 해당 차원의 필요성을 재검토하거나 다른 차원과 통합을 고려합니다

Drill Across의 힘

Conformed Dimension 덕분에 독립적으로 개발된 Data Mart들을 동일 차원 기준으로 통합 분석할 수 있습니다. 이를 Drill Across라고 부릅니다.

아래 예시는 Sales와 Returns를 같은 고객/날짜 기준으로 통합하여 순매출(Net Revenue)을 분석하는 쿼리입니다:

-- Sales와 Returns를 같은 고객·날짜 기준으로 통합 분석
SELECT dc.customer_id, dd.month,
       SUM(fs.revenue) AS sales,
       SUM(fr.return_amount) AS returns,
       SUM(fs.revenue) - SUM(fr.return_amount) AS net_revenue
FROM dim_customer dc
JOIN dim_date dd ON TRUE
LEFT JOIN fact_sales fs ON fs.customer_key = dc.customer_key AND fs.date_key = dd.date_key
LEFT JOIN fact_returns fr ON fr.customer_key = dc.customer_key AND fr.date_key = dd.date_key
WHERE dd.year = 2024
GROUP BY dc.customer_id, dd.month;

💡

핵심 포인트: Bus Matrix는 단순한 문서가 아니라, 데이터 웨어하우스의 전사적 설계 청사진입니다. Conformed Dimension을 통해 독립적으로 개발된 Data Mart 간의 Drill Across가 가능해지며, 이것이 Kimball 방법론의 핵심 가치입니다.