데이터 분석에서 DW(Data Warehouse)와 DM(Data Mart)는 단순히 있어도 되고 없어도 되는 옵션이 아니라, “제대로 된 분석”을 가능하게 만드는 기본 인프라에 가깝습니다.
특히 BI 도구(Power BI, Tableau 등)와 결합했을 때 DW·DM 유무에 따라 분석 속도, 데이터 신뢰도, 유지보수 비용이 극단적으로 갈립니다.
Data Warehouse가 필요한 이유
Data Warehouse는 여러 운영 시스템(ERP, CRM, 업무 DB 등)의 데이터를 한 곳에 모아 구조화해 두는 전사 분석용 저장소입니다.
운영 DB는 실시간 트랜잭션 처리에 최적화되어 있지만, DW는 복잡한 집계와 대량 조회에 맞춰 설계된 “분석 전용 데이터베이스”라고 보면 됩니다.
DW가 중요한 핵심 이유는 다음과 같습니다.
- 전사 단일 진실 공급원(Single Source of Truth)
여러 시스템에서 온 데이터를 공통 정의로 통합해, 조직 전체가 같은 지표 정의와 숫자를 보고 의사결정 할 수 있게 해줍니다.
이 덕분에 “어느 팀 숫자가 맞냐” 같은 소모적인 논쟁이 줄어듭니다. - 장기적인 히스토리 분석
운영 시스템은 오래된 데이터를 지우거나 아카이브하는 반면, DW는 수년 치 데이터를 저장해 장기 추세 분석과 시계열 비교에 특화됩니다.
이를 통해 경기 사이클, 시즌ality, 정책 변경 전후 효과 등 전략적인 분석이 가능해집니다. - 분석 성능과 안정성
분석 쿼리를 운영 DB에서 직접 날리면 트랜잭션 지연, 락, 성능 저하 등 문제가 생기지만, DW는 분석 워크로드를 분리해 이런 리스크를 줄여줍니다.
인덱스, 파티셔닝, 분산 처리 같은 기술을 활용해 대규모 데이터를 빠르게 조회할 수 있게 설계됩니다. - 확장성과 클라우드 친화성
최근에는 대부분의 DW가 클라우드 기반 DWH/DBaaS 형태로 제공되어, 데이터 증가에 따라 탄력적으로 확장하면서도 인프라 관리 부담을 줄여줍니다.
Data Mart가 필요한 이유
Data Mart는 DW 전체 데이터 중 특정 도메인(판매, 마케팅, 재무, 물류 등)에 초점을 맞춘 “부분 집합” 저장소입니다.
전사 관점의 DW가 너무 크고 복잡하기 때문에, 실제 분석·보고는 보통 도메인별 DM 위에서 수행하는 구조가 일반적입니다.
Data Mart의 필요성은 다음과 같이 정리할 수 있습니다.
- 도메인별로 집중된 데이터 제공
DM은 특정 부서나 기능에 필요한 테이블과 지표만 노출해, 사용자가 불필요한 스키마를 탐색하지 않아도 됩니다.
예를 들어 “Sales Mart”에는 매출, 주문, 고객 관련 테이블과 KPI 위주로만 구성합니다. - Self-Service BI와 의사결정 속도 향상
도메인 최적화 스키마(보통 Star Schema, Snowflake Schema)를 사용해 BI 도구가 빠르게 집계·시각화할 수 있게 도와줍니다.
이를 통해 현업이 데이터 팀 도움 없이도 대시보드와 Ad-hoc 분석을 수행하는 Self-Service BI 환경을 만들 수 있습니다. - 성능 및 비용 최적화
전사 DW 전체를 대상으로 복잡한 쿼리를 날리는 것보다, 범위가 좁고 사전 집계된 DM에 쿼리하는 쪽이 훨씬 빠르고 비용도 적게 듭니다.
클라우드 DWH 과금 구조(쿼리당/컴퓨트 사용량 기반)를 생각하면 DM을 잘 쪼개는 것이 곧 비용 최적화 전략이기도 합니다. - 보안과 권한 관리
부서별로 필요한 데이터만 DM에 올려두고, 해당 마트를 기준으로 권한을 부여하면 민감 데이터 접근 범위를 자연스럽게 제어할 수 있습니다.
DW와 DM의 차이 한눈에
아래 표는 Data Warehouse와 Data Mart의 역할과 특성을 간단히 비교한 것입니다.
| 구분 | Data Warehouse | Data Mart |
| 범위 | 전사 전체, 여러 부서와 기능을 포괄 | 특정 부서·도메인(판매, 마케팅, 재무 등)에 집중 |
| 데이터 소스 | 다양한 내부·외부 시스템에서 통합 수집 | DW 또는 일부 운영 시스템에서 필요한 부분만 가져옴 |
| 크기 | 수백 GB~수 TB 이상 대규모 | 상대적으로 소규모, 특정 주제 데이터만 포함 |
| 복잡도 | 설계·구축이 복잡, 기간 길고 비용 큼 | 상대적으로 단순, 빠르게 구축 가능 |
| 의사결정 | 전사 전략·장기 분석 중심 | 전술적·운영적, 부서 KPI 중심 |
왜 데이터 분석에서 둘 다 필요한가
현대 데이터 아키텍처에서는 “DW만” 혹은 “DM만”으로 끝내기보다는, DW를 기반으로 여러 DM을 올리는 레이어드 구조가 일반적입니다.
이 구조가 필요한 이유를 분석 관점에서 정리해보면 다음과 같습니다.
- 지표의 일관성과 전사 관점 유지
지표 정의·마스터 데이터 관리(MDM) 등 공통 규칙은 DW 레벨에서 통합 관리해야 부서 간 지표 불일치가 줄어듭니다.
DM은 이 통합 규칙 위에서 도메인 특화 지표를 더해 쓰는 구조이기 때문에, 전사 관점과 부서 관점을 동시에 유지할 수 있습니다. - 실제 작업 속도와 사용자 경험
실무 분석가는 “정확하지만 느리고 복잡한” 시스템보다, “충분히 정확하면서 빠르고 직관적인” 스키마를 선호합니다.
DM은 전사 규칙을 깨지 않는 선에서 모델을 단순화해, BI 도구에서 테이블 3~4개만 조인해도 대부분의 분석이 끝나도록 설계할 수 있습니다. - 성능·비용·운영 측면의 균형
전사 DW를 너무 세세한 쿼리까지 모두 감당하는 플랫폼으로 사용하면, 컴퓨트 비용과 성능 이슈가 빠르게 터집니다.
반복적으로 쓰이는 패턴은 DM에서 사전 집계/인덱싱해 두고, DW는 원시 데이터와 장기 보존, 신규 분석용으로 쓰는 식으로 역할을 나누면 효율적입니다. - 거버넌스와 책임 분담
DW는 전사 Data Governance, 품질 기준, 보안 정책을 담당하는 중앙 허브 역할을 하고,
DM은 도메인 팀이 스스로 스키마와 리프레시 주기를 조절하면서 책임 있게 데이터 제품을 운영하는 단위가 될 수 있습니다.
예시로 보는 Power BI와 DW·DM
실제 Power BI 같은 BI 도구 사용 시 시나리오를 그려보면 DW·DM의 필요성이 더 직관적으로 보입니다.
- 나쁜 패턴
- 개별 운영 DB(예: ERP, CRM)에 DirectQuery 또는 Import를 직접 걸어 각각 다른 모델을 구성
- 보고서마다 지표 정의와 조인 로직이 다르게 구현되어, 숫자가 맞지 않고 성능도 느려짐
- 쿼리 부하가 운영 시스템에 직접 영향을 줌
- 좋은 패턴
- ETL/ELT 파이프라인으로 여러 소스를 DW에 통합하고 공통 지표 정의를 정리
- Sales, Marketing, Finance 등 도메인별 Star Schema 형태의 DM 뷰/테이블을 설계
- Power BI는 각 DM에만 연결해 모델링을 최소화하고, 공통 Dimension은 재사용
- 같은 고객, 같은 매출 지표를 어떤 리포트를 열어도 동일하게 보게 됨
이렇게 구성하면 데이터 엔지니어/BI 엔지니어는 DW·DM 계층에서 복잡한 모델링과 품질 관리를 맡고, 현업은 BI 도구에서 시각화와 인사이트 도출에 집중할 수 있습니다.
DW·DM 없이 진행할 때 생기는 문제들
DW와 DM이 없이 “운영 DB + 엑셀 + 개별 Power BI 모델”로만 분석을 진행하면 다음과 같은 문제가 거의 필연적으로 발생합니다.
- 보고서마다 숫자가 다른 문제
팀마다 다른 SQL, 다른 필터 조건, 다른 집계 기준을 사용해 같은 지표도 서로 다른 값이 나오게 됩니다.
결국 “데이터 불신”이 쌓이고, 데이터 기반 의사결정 문화가 자리 잡기 어렵습니다. - 성능과 안정성 이슈
월말/분기 말에 무거운 리포트가 동시에 돌아가면서 운영 시스템이 느려지거나, 쿼리 타임아웃이 빈번히 발생합니다.
DW에 분석 워크로드를 분리하는 것만으로도 이런 문제 상당수를 해소할 수 있습니다. - 관리 불가능한 모델 스프롤(Model Sprawl)
각자가 만든 Power BI 파일, 엑셀 피벗, 로컬 SQL 스크립트가 난립하면서, 어떤 모델이 기준인지, 어디를 수정해야 하는지 파악하기 어려워집니다.
DW·DM 기반의 중앙 모델로 수렴시키면 변경 관리와 영향 분석이 훨씬 쉬워집니다.
현실적인 구축 방향
모든 조직이 완벽한 Enterprise DW를 한 번에 구축할 필요는 없지만, “DW + 도메인별 DM + BI”라는 기본 패턴을 염두에 두고 점진적으로 확장하는 것이 좋습니다.
- 1단계: 핵심 소스 시스템 2~3개를 선정해 클라우드 DW로 통합
전사 완성보다, 공통 Dimension(고객, 상품, 조직 등)과 핵심 Fact(매출, 주문 등)을 먼저 정리하는 것이 중요합니다. - 2단계: 가장 비즈니스 임팩트가 큰 도메인(예: Sales Mart)을 Star Schema로 설계
반복적으로 보는 KPI(매출, 주문 수, 신규 고객 수 등)를 DM에서 쉽게 조회할 수 있게 만들고, 기존 리포트를 이쪽으로 옮깁니다. - 3단계: 도메인 확장 + 거버넌스 강화
마케팅, 재무, 운영 등으로 순차 확장하면서, 데이터 품질 규칙, 메타데이터 관리, 권한 모델을 DW 레벨에서 강화합니다.
이렇게 하면 초기에는 “작지만 제대로 된 DW·DM”부터 시작해, 점차 전사 아키텍처로 성장시킬 수 있습니다.
- Data Warehouse는 전사 데이터를 한 곳에 모아 “신뢰할 수 있는 전사 관점”을 제공하는 백본입니다.
- Data Mart는 그 위에서 도메인별로 빠르고 쓰기 쉬운 “분석용 창구”를 제공하는 전면 창구입니다.
데이터 분석·BI 환경에서 DW와 DM은 선택이라기보다, “스케일 있는 분석”을 가능하게 하는 기본 전제에 가깝다고 보는 것이 현실적입니다.
놓치면 아쉬운 추천 글, 함께 읽어보세요!
- 추천 글을 불러오는 중입니다...
