DP-900에서 "분석용 데이터는 어떤 모양으로 저장하나요?"라는 질문에 답하는 핵심 개념이 스타 스키마입니다. 팩트 테이블과 차원 테이블, 스타와 스노우플레이크의 차이, 그리고 그 위에 만드는 분석 데이터 모델(시맨틱 모델)은 공식 출제 범위 도메인 4의 "분석 데이터 저장소 옵션"과 "Power BI 데이터 모델의 기능" 두 항목에 함께 걸쳐 있습니다. 한 번 정리해 두면 두 영역의 문제를 동시에 풀 수 있습니다.
이 글은 DP-900 학습자료 시리즈의 보충편입니다. 앞에서 본 OLTP와 OLAP, 데이터 레이크와 데이터 웨어하우스 개념을 이어받아, 분석 데이터가 실제로 어떤 테이블 구조로 정리되고 Power BI에서 어떻게 모델이 되는지 순서대로 살펴봅니다.
---
분석용 데이터는 왜 모양을 바꿔야 할까?
쇼핑몰 주문 시스템을 떠올려 보세요. 주문이 들어올 때마다 주문, 주문 상세, 고객, 주소, 상품, 결제 테이블에 나누어 기록합니다. 정규화 덕분에 중복이 없고 쓰기가 빠르지만, "지난 분기 지역별·카테고리별 매출"을 구하려면 테이블 대여섯 개를 JOIN해야 합니다.
영수증 더미와 잘 정리된 가계부의 차이와 같습니다. 영수증은 한 장씩 빠르게 쌓기에는 좋지만, 한 달 식비를 알려면 전부 다시 뒤져야 합니다. 가계부는 날짜·항목·금액을 미리 정해진 칸에 정리해 두었기 때문에 합계를 바로 낼 수 있습니다.
그래서 분석용 저장소에서는 트랜잭션 데이터를 그대로 복사하지 않고, 집계하기 쉬운 모양으로 다시 정리합니다.
| 구분 | 트랜잭션용 스키마 (OLTP) | 분석용 스키마 (OLAP) | |------|------|------| | 목적 | 주문·결제를 빠르고 정확하게 기록 | 대량의 데이터를 집계·비교 | | 설계 원칙 | 정규화로 중복 최소화 | 팩트와 차원으로 나눠 집계하기 쉽게 | | 대표 쿼리 | 주문 1건 조회·수정 | 월별·지역별 합계, 추세 | | 테이블 구조 | 작은 테이블 여러 개 | 중심 팩트 테이블 + 차원 테이블 | | 대표 예 | 쇼핑몰 주문 데이터베이스 | 데이터 웨어하우스, Power BI 모델 |
시험 팁: "트랜잭션 데이터를 분석 쿼리에 최적화된 스키마로 바꿔 저장한다" → 데이터 웨어하우스. 이때 쓰는 대표적인 테이블 설계가 스타 스키마입니다.
---
팩트 테이블과 차원 테이블
스타 스키마는 두 종류의 테이블로 구성됩니다. 숫자를 담는 팩트 테이블과, 그 숫자를 묶고 거르는 기준을 담는 차원 테이블입니다.
팩트 테이블: 일어난 일과 숫자
팩트 테이블의 한 행은 기록된 사건 하나입니다. 판매 한 건, 배송 한 건, 센서 측정 한 번이 각각 한 행이 됩니다. 각 행에는 분석하고 싶은 숫자 값(수량, 매출액, 비용)과, 그 사건이 어떤 차원에 속하는지 가리키는 키(날짜 키, 제품 키, 고객 키)가 들어갑니다.
차원 테이블: 숫자를 묶는 기준
차원 테이블은 "무엇별로" 집계할지를 정하는 엔터티입니다. 제품 차원에는 제품명·카테고리·브랜드가, 고객 차원에는 이름·도시·등급이 들어갑니다. 각 행은 고유한 키 값을 가지고, 팩트 테이블은 이 키로 차원의 행을 참조합니다.
대부분의 분석 모델에는 날짜(시간) 차원이 들어갑니다. 날짜·월·분기·연도 열을 미리 갖춘 날짜 차원이 있으면 "월별 매출"이나 "작년 같은 분기 대비" 같은 질문을 쉽게 풀 수 있습니다.
| 구분 | 팩트 테이블 | 차원 테이블 | |------|------|------| | 담는 것 | 측정값(숫자) + 차원 키 | 설명 속성(이름·분류·위치) | | 행 하나의 의미 | 사건 1건 (판매 1건) | 엔터티 1개 (제품 1개) | | 행 수 | 매우 많고 계속 늘어남 | 상대적으로 적음 | | 열 예시 | 수량, 매출액, 날짜 키, 제품 키 | 제품명, 카테고리, 브랜드 | | 쿼리에서의 역할 | 합계·평균을 계산할 대상 | 그룹화·필터의 기준 |
분석 모델에서는 이 둘을 각각 측정값(measure)과 차원(dimension)이라고 부릅니다. "고객별 총매출"이나 "제품별 월간 판매 수량"은 모두 측정값을 하나 이상의 차원으로 집계한 결과입니다.
시험 팁: "수량·매출처럼 집계할 숫자 값" → 팩트 테이블. "제품명·카테고리·도시처럼 그룹화하거나 필터링할 속성" → 차원 테이블.
---
스타 스키마 vs 스노우플레이크 스키마
팩트 테이블 하나를 가운데 두고 차원 테이블들이 둘러싼 모양이 별처럼 보여서 스타 스키마라고 부릅니다. 차원 테이블과 팩트 테이블은 일대다(1:N) 관계입니다. 제품 하나는 판매 기록 여러 건에 등장하지만, 판매 한 건은 제품 하나만 가리킵니다.
스노우플레이크 스키마는 스타 스키마의 차원 테이블을 한 번 더 나눈 형태입니다. 예를 들어 제품 차원 안에 카테고리 이름을 반복해서 저장하는 대신, 카테고리 테이블을 따로 만들어 제품 테이블과 연결합니다. 가지가 바깥으로 뻗어 나간 모양이 눈송이 같다고 해서 붙은 이름입니다.
!스타 스키마 vs 스노우플레이크 스키마
| 구분 | 스타 스키마 | 스노우플레이크 스키마 | |------|------|------| | 차원 구조 | 차원 하나가 테이블 하나 | 차원이 여러 테이블로 정규화 | | 계층 표현 | 같은 테이블의 열 (제품 → 카테고리) | 별도 테이블 (제품 테이블 → 카테고리 테이블) | | JOIN 수 | 적음 | 많음 | | 쿼리와 모델 | 단순하고 빠름 | 복잡해짐 | | 중복 | 차원 안에 일부 중복 허용 | 중복이 더 적음 |
Power BI 공식 가이드는 모델을 스타 스키마로 설계하라고 권장합니다. 관계가 단순해야 필터가 예측한 대로 흐르고 DAX 수식도 쉬워지기 때문입니다. 원본이 스노우플레이크 형태라면 차원 테이블들을 하나로 합쳐 스타 형태로 바꾸는 경우가 많습니다.
시험 팁: "차원 테이블이 또 다른 테이블(예: 제품 → 카테고리)과 연결되어 계층을 표현한다" → 스노우플레이크 스키마. "팩트 테이블 하나에 차원 테이블들이 직접 연결된다" → 스타 스키마.
---
큐브에서 시맨틱 모델로
분석가가 웨어하우스 테이블을 직접 쿼리할 수도 있지만, 보고서와 대시보드를 쉽게 만들려고 그 위에 분석 데이터 모델을 하나 더 둡니다. 어떤 테이블이 어떻게 연결되고, 무엇을 측정값으로 보고, 어떤 계층으로 드릴다운할지를 미리 정의해 둔 설계도입니다.
예전 방식: OLAP 큐브
과거에는 SQL Server Analysis Services(SSAS) Multidimensional 같은 기술로 큐브를 만들었습니다. 제품별·지역별 매출처럼 차원 조합마다 숫자를 미리 집계해 저장해 두는 방식이라 조회는 빠르지만, 새로운 집계가 필요하면 큐브를 다시 처리해야 했습니다.
지금 방식: 시맨틱 모델
현재 Power BI와 Microsoft Fabric이 쓰는 방식은 시맨틱 모델(테이블 형식 모델)입니다. 테이블, 관계, 계층, 그리고 DAX로 작성한 측정값을 정의해 두고, 집계는 미리 저장하지 않고 쿼리할 때 계산합니다. Import 모드에서는 데이터를 VertiPaq 엔진의 메모리 내 열 기반 저장소에 담아 빠르게 계산합니다. Fabric에서는 Direct Lake 모드로 OneLake의 Delta 테이블을 별도 복사본 없이 바로 모델 메모리에 올릴 수 있습니다.
| 구분 | OLAP 큐브 (다차원) | 시맨틱 모델 (테이블 형식) | |------|------|------| | 대표 기술 | SSAS Multidimensional | Power BI, Microsoft Fabric | | 집계 시점 | 미리 계산해 저장 | 쿼리할 때 계산 | | 계산 정의 | MDX 등 | DAX 측정값 | | 현재 위치 | 과거 방식 | 현재 권장 방식 |
특성 계층: 드릴업과 드릴다운
계층은 차원 안의 수준을 위아래로 오가게 해 줍니다. 연도별 매출을 보다가 한 해를 클릭해 월별로 내려가는 것이 드릴다운, 다시 연도로 올라가는 것이 드릴업입니다.
날짜 차원: 일 → 월 → 연도 제품 차원: 제품 → 카테고리 고객 차원: 고객 → 도시
Power BI Desktop의 모델 보기에서 팩트와 차원 테이블 사이의 관계를 만들고, 계층을 정의하고, 데이터 형식과 표시 형식을 지정합니다. 측정값과 계산 열의 차이, 데이터 연결 모드는 Power BI 핵심 정리 글에서 이어서 볼 수 있습니다.
시험 팁: "숫자를 차원별로 미리 집계해 저장하는 다차원 구조" → 큐브. "연도에서 월로 내려가며 값을 본다" → 계층을 이용한 드릴다운. "Fabric의 Delta 테이블을 복사 없이 모델에 올린다" → Direct Lake.
---
데이터 웨어하우스, 데이터 레이크, 레이크하우스
스타 스키마가 테이블을 어떤 모양으로 짤지에 대한 이야기라면, 분석 데이터 저장소는 그 데이터를 어디에 어떤 형태로 둘지에 대한 이야기입니다. DP-900은 세 가지를 구분하도록 요구합니다.
| 구분 | 데이터 웨어하우스 | 데이터 레이크 | 데이터 레이크하우스 | |------|------|------|------| | 저장 형태 | 관계형 테이블 | 분산 파일 시스템의 파일 | 레이크의 파일 + Delta 테이블 | | 스키마 적용 | 쓸 때 (스타 스키마 등) | 읽을 때 | Delta Lake 테이블이 스키마 강제 | | 담는 데이터 | 정형 | 정형·반정형·비정형 | 정형·반정형 중심 | | 주 쿼리 방식 | SQL | Apache Spark 등 | SQL과 Spark 모두 | | Azure 예 | Fabric Warehouse | Azure Data Lake Storage Gen2, OneLake | Fabric Lakehouse, Azure Databricks |
레이크하우스를 가능하게 하는 것이 Delta Lake입니다. Parquet 파일 위에 트랜잭션 로그를 더해 테이블 스키마 강제, 트랜잭션 일관성, 배치·스트리밍 적재, SQL 쿼리를 지원하는 오픈소스 형식으로, Microsoft Fabric과 Azure Databricks 모두 기본 테이블 형식으로 씁니다.
Fabric Lakehouse vs Fabric Warehouse
Microsoft Fabric에서는 두 저장소 모두 데이터를 OneLake에 둡니다. 차이는 데이터를 다루는 방식입니다.
Fabric Lakehouse: Delta Lake 형식으로 저장하고 노트북과 Spark로 다룹니다. 만들면 SQL 분석 엔드포인트가 자동으로 생겨 SQL로도 조회할 수 있습니다. 반정형·혼합 데이터나 머신러닝 작업에 맞습니다. Fabric Warehouse: T-SQL로 다루는 완전 관리형 관계형 데이터 웨어하우스입니다. 데이터가 정형이고 팀이 SQL에 익숙하며, 강한 스키마 강제와 많은 동시 사용자가 필요할 때 맞습니다.
Azure Databricks는 Apache Spark 기반 분석 플랫폼으로 Delta Lake를 기본 형식으로 쓰고, BI 도구를 위해 Databricks SQL 웨어하우스를 제공합니다. 코드 중심의 Spark 작업이나 여러 클라우드에서 같은 플랫폼을 써야 할 때 자주 선택됩니다.
시험 팁: "정형 데이터, SQL을 쓰는 팀, 동시 사용자가 많은 보고" → Fabric Warehouse. "반정형 파일과 노트북, 머신러닝" → Fabric Lakehouse. "레이크의 파일에 스키마와 ACID 트랜잭션을 더하는 오픈소스 형식" → Delta Lake.
---
시나리오로 연습하기
시험 문제는 대부분 상황을 주고 개념이나 서비스를 고르게 합니다. 아래 상황을 보고 먼저 답을 떠올린 뒤 오른쪽 열을 확인해 보세요.