관련 포스트데이터 웨어하우스 데이터 마트 비즈니스 인텔리전스 ETL데이터 모델링

스타 스키마(Star Schema)

•

2026년 10월 25일 발행•2026년 10월 25일 수정

요약

하나의 팩트 테이블을 중심으로 여러 차원 테이블을 외래키로 연결한 분석용 데이터 모델

초급

관계형 데이터베이스와 SQL 조인에 대한 기본 이해가 필요하며, 입도와 천천히 변하는 차원 같은 차원 모델링 개념을 알아야 한다.

태그

데이터 웨어하우스 데이터 마트 비즈니스 인텔리전스 ETL데이터 모델링

#개념

스타 스키마(Star Schema)는 분석 대상이 되는 사건을 기록한 하나의 팩트 테이블(Fact Table)을 가운데 두고, 그 사건을 설명하는 여러 차원 테이블(Dimension Table)을 외래키로 연결한 데이터 모델이다. 테이블 관계를 그리면 중심에서 차원이 방사형으로 뻗어 나가 별 모양이 되어 이런 이름이 붙었다.

스타 스키마는 Ralph Kimball이 체계화한 차원 모델링(Dimensional Modeling)의 기본 형태로, 데이터 웨어하우스(Data Warehouse)와 데이터 마트(Data Mart)에서 가장 널리 쓰이는 설계 방식이다. 운영 시스템의 정규화 모델이 쓰기와 무결성에 최적화되어 있다면, 스타 스키마는 사람이 이해하기 쉽고 집계 쿼리가 빠르게 동작하도록 읽기에 최적화된 구조다. 온라인 분석 처리(Online Analytical Processing, OLAP)와 BI 도구도 이 구조를 전제로 동작하는 경우가 많다.

스타 스키마를 이루는 요소는 많지 않지만, 각 요소의 역할을 정확히 구분하는 것이 설계 품질을 좌우한다. 특히 어떤 값을 팩트에 두고 어떤 값을 차원에 둘지는 이후 쿼리의 단순함과 집계 정확도에 직접 영향을 준다. 잘못 배치된 속성은 나중에 대규모 재적재를 부르므로 초기에 신중히 정한다. 주요 구성 요소는 다음과 같다.

스타 스키마의 구성 요소

팩트 테이블: 주문, 결제, 클릭처럼 업무 과정에서 발생한 측정 가능한 사건을 한 행씩 기록한다. 행 수가 매우 많고, 차원을 가리키는 외래키와 측정값 컬럼으로 이루어진다.
차원 테이블: 날짜, 고객, 상품, 매장처럼 사건의 맥락을 설명하는 테이블이다. 행 수는 상대적으로 적지만 필터와 그룹화에 쓰이는 서술 속성 컬럼이 많다.
측정값(Measure): 수량, 금액, 할인액처럼 팩트 테이블에 저장되어 합계나 평균으로 집계되는 숫자 값이다.
외래키(Foreign Key): 팩트 테이블의 각 행이 어떤 차원 행에 속하는지 가리키는 컬럼이다. 팩트와 차원은 다대일 관계로 연결된다.
대리키(Surrogate Key): 원천 시스템의 업무 키와 별개로 웨어하우스가 부여하는 의미 없는 정수 식별자다. 원천 키 변경을 흡수하고 이력 관리를 가능하게 한다.

측정값은 집계 가능성에 따라 성격이 다르다. 판매 금액처럼 모든 차원으로 더할 수 있는 값은 가산(Additive) 측정값이고, 계좌 잔액이나 재고 수량처럼 시간 축으로는 더할 수 없는 값은 반가산(Semi-additive) 측정값이다. 할인율이나 전환율 같은 비율은 비가산(Non-additive) 측정값이므로, 분자와 분모를 따로 저장하고 집계한 뒤 나누는 방식으로 다룬다.

설계에서 가장 먼저 확정해야 할 것은 입도(Grain), 즉 팩트 테이블 한 행이 무엇을 의미하는지다. 주문 한 건인지, 주문 안의 상품 한 줄인지, 하루 단위 상품 매출인지에 따라 연결할 수 있는 차원과 측정값이 달라진다. Kimball은 가능한 한 더 쪼갤 수 없는 원자 수준의 입도를 권장하며, 한 팩트 테이블에 서로 다른 입도의 행을 섞으면 이중 집계 오류가 생긴다고 경고한다.

Kimball 그룹은 차원 모델을 설계하는 절차를 네 단계로 정리했다. 이 순서는 업무 요구와 원천 데이터의 현실을 함께 고려하도록 돕고, 특히 입도를 차원과 팩트보다 먼저 정하게 하여 설계 도중 의미가 흔들리는 것을 막는다. 원천 데이터를 먼저 보고 테이블을 만드는 방식과 달리, 측정하려는 업무에서 출발한다는 점이 특징이다. 각 단계는 다음과 같다.

Kimball 차원 설계 4단계

비즈니스 프로세스 선택: 주문, 배송, 재고 스냅숏처럼 측정할 업무 활동 하나를 고른다. 부서가 아니라 프로세스 단위로 모델을 만든다.
입도 선언: 팩트 테이블 한 행이 정확히 무엇을 나타내는지 문장으로 정의한다. 이후 모든 결정은 이 선언과 일치해야 한다.
차원 식별: 선언한 입도에서 사건을 설명하는 누가, 무엇을, 언제, 어디서 같은 맥락을 차원으로 정한다.
팩트 식별: 해당 프로세스에서 발생하고 입도와 일치하는 숫자 측정값을 정한다. 입도와 맞지 않는 값은 별도 팩트 테이블로 분리한다.

차원 테이블은 의도적으로 넓고 평평하게 만든다. 상품 차원에는 대분류, 중분류, 소분류, 브랜드를 한 행에 모두 담아 계층을 펼쳐 두고, 날짜 차원에는 요일, 주차, 월, 분기, 공휴일 여부를 미리 계산해 둔다. 여러 팩트 테이블이 같은 의미와 키를 공유하는 적합 차원(Conformed Dimension)을 쓰면 주문과 배송처럼 다른 프로세스의 지표를 같은 기준으로 나란히 비교할 수 있다.

스타 스키마는 다른 모델링 방식과 비교할 때 특징이 더 분명해진다. 차원을 얼마나 정규화하는지, 팩트 테이블을 몇 개 두는지, 조인을 미리 해 두는지에 따라 저장 효율과 조회 편의성의 균형이 달라진다. 하나의 조직 안에서도 용도에 따라 여러 방식이 함께 쓰이는 경우가 많다. 대표적인 방식은 다음과 같다.

분석용 스키마 비교

스타 스키마: 차원을 비정규화한 단일 테이블로 두어 팩트에서 한 번의 조인으로 모든 속성에 접근한다. 이해하기 쉽고 쿼리가 단순하다.
스노우플레이크 스키마(Snowflake Schema): 차원의 계층을 여러 테이블로 정규화해 눈송이처럼 가지를 친 구조다. 저장 공간과 중복은 줄지만 조인이 늘어나 쿼리가 복잡해진다.
갤럭시 스키마(Galaxy Schema): 여러 팩트 테이블이 적합 차원을 공유하는 구조로, 팩트 컨스텔레이션(Fact Constellation)이라고도 한다. 기업 단위 웨어하우스는 대부분 이 형태가 된다.
OBT(One Big Table): 팩트와 필요한 차원 속성을 미리 조인해 하나의 넓은 테이블로 만든 방식이다. 조인 없이 바로 조회할 수 있지만 중복과 갱신 부담이 크다.

스타 스키마의 핵심은 정규화(Normalization)와 비정규화(Denormalization)의 절충이다. 차원을 비정규화하면 같은 카테고리명이 여러 상품 행에 반복 저장되지만, 차원 테이블은 팩트에 비해 매우 작으므로 저장 비용 증가는 미미하다. 대신 분석가가 이해해야 할 테이블 수가 줄고 조인 경로가 하나로 고정되어 쿼리 오류가 줄어든다. 팩트 테이블은 외래키와 숫자만 남겨 정규화된 형태를 유지한다.

차원 속성은 시간이 지나며 바뀐다. 고객의 등급이나 주소, 상품의 카테고리가 바뀌었을 때 과거 사건을 어떤 값으로 볼지 정하는 기법이 천천히 변하는 차원(Slowly Changing Dimension, SCD)이다. Kimball 그룹은 Type 0부터 Type 7까지 정리했으며, 가장 많이 쓰이는 세 가지는 다음과 같다.

주요 SCD 유형

Type 1: 기존 값을 새 값으로 덮어쓴다. 이력은 남지 않고 과거 사건도 현재 값으로 집계되며, 오타 수정처럼 이력이 의미 없는 속성에 쓴다.
Type 2: 변경 시 새 대리키로 새 행을 추가하고 유효 시작일, 유효 종료일, 현재 여부 플래그를 관리한다. 과거 사건은 당시 값으로 정확히 집계된다.
Type 3: 이전 값 컬럼을 하나 더 두어 직전 값과 현재 값을 함께 보관한다. 조직 개편 직후 신구 기준을 비교할 때처럼 제한된 이력만 필요할 때 쓴다.

Type 2에서 대리키가 중요한 이유가 여기에 있다. 같은 고객이 실버에서 골드로 바뀌면 고객 차원에는 업무 키가 같은 두 행이 생기고, 팩트는 주문 시점에 유효했던 행의 대리키를 저장한다. 이렇게 하면 별도의 시점 조건 없이 단순 조인만으로 당시 등급 기준의 매출을 구할 수 있고, 현재 등급 기준이 필요하면 현재 여부 플래그로 필터한다.

스타 스키마는 조인 성능 면에서도 유리하다. 쿼리는 작은 차원에 필터를 걸고 큰 팩트와 조인하는 형태로 일정하므로, 전통적인 데이터베이스는 비트맵 인덱스와 스타 조인 최적화로 이를 처리한다. 열 지향 저장(Columnar Storage) 엔진에서는 필요한 컬럼만 읽고 압축 효율이 높으며, 작은 차원은 브로드캐스트 조인으로 분산 처리된다. Spark의 동적 파티션 프루닝처럼 차원 필터 결과로 팩트 파티션을 건너뛰는 최적화도 이 구조를 전제로 한다.

클라우드 웨어하우스가 보편화되면서 OBT 방식도 자주 쓰인다. 열 지향 엔진에서는 넓은 테이블이라도 필요한 컬럼만 읽으므로 비용 부담이 줄었고, 조인이 없어 대시보드 응답이 빠르다. 그러나 차원 속성이 바뀌면 거대한 테이블 전체를 다시 만들어야 하고, 같은 속성이 여러 OBT에 흩어져 정의가 어긋나기 쉽다. 그래서 실무에서는 스타 스키마를 정본으로 두고, 그 위에 용도별 OBT를 파생시키는 구성이 일반적이다.

dbt(data build tool)는 SQL 변환을 코드로 관리하며 스타 스키마를 구현하는 대표 도구다. 원천을 정리하는 스테이징 모델 위에 fct_, dim_ 접두사를 붙인 마트 모델을 두는 명명 관례가 널리 쓰인다. 차원 대리키는 업무 키를 해시해 생성하는 경우가 많고, Type 2 이력은 dbt 스냅숏 기능으로 유효 기간 컬럼을 자동 관리한다. 대리키의 유일성과 팩트-차원 참조 무결성은 dbt 테스트로 매 실행마다 검증한다.

전자상거래 주문 분석을 예로 들면, 비즈니스 프로세스는 주문이고 입도는 주문 안의 상품 한 줄로 선언한다. 팩트 테이블에는 날짜, 고객, 상품, 판매자, 프로모션 차원의 대리키와 수량, 판매 금액, 할인 금액, 배송비 같은 측정값을 둔다. 주문 번호처럼 별도 차원 없이 팩트에 남기는 키는 퇴화 차원(Degenerate Dimension)이라 부른다. 이 구조에서 월별 카테고리별 매출은 날짜와 상품 차원을 조인해 그룹화하는 단순한 쿼리로 얻는다.

스타 스키마는 수십 년 된 설계 방식이지만 데이터 레이크하우스와 클라우드 웨어하우스 환경에서도 여전히 분석 모델링의 기본으로 쓰인다. 입도를 명확히 선언하고, 차원을 이해하기 쉽게 펼치고, 이력 관리 방식을 의식적으로 선택하는 원칙은 저장 기술이 바뀌어도 데이터의 의미를 일관되게 유지하는 데 그대로 유효하다.