“스타스키마 안 해도 되나요?”

클라우드 DW 전환 프로젝트를 하면 꼭 나오는 질문입니다.

온프레미스에서 수년간 운영하던 DW를 BigQuery나 Azure Synapse로 옮기는 자리. 누군가가 묻습니다. “거기는 Columnar Storage(컬럼기반 저장소)라 조인 비용이 다르다는데, 그러면 스타스키마 안 해도 되는 거 아닌가요?”

상황에 따라 다릅니다. 그런데 이 “상황에 따라 다르다"가 구체적으로 뭘 따져야 하는 건지를 아는 사람은 많지 않습니다.

온프레미스 시절의 공식

Kimball의 Dimensional(Star-Schema) 모델링이 사실상 표준이던 시절이 있었습니다.

이유는 단순했습니다. 디스크 I/O가 비쌌고, 조인은 더 비쌌습니다. Row 기반 스토리지에서 테이블 10개를 조인하면 쿼리 응답이 분 단위로 넘어갔습니다. 그래서 미리 조인해 놓는 게 합리적이었습니다.

모델링 의사결정이 곧 성능 의사결정이었습니다. 어디까지 비정규화할지, 집계 테이블을 몇 단계로 쌓을지, 파티션 키를 무엇으로 잡을지 결정해야 했습니다. 이 결정들이 쿼리 응답 시간을 초 단위에서 분 단위로 갈랐습니다.

Kimball의 방법론은 이 제약 안에서 비즈니스 가독성과 쿼리 성능을 동시에 잡으려는 시도였습니다. 부서마다 제각각이던 차원 테이블을 전사 공통 기준으로 통일(Conformed Dimension)해서 일관성을 보장하고, Bus Matrix로 전사 통합을 설계했습니다. 방법론 자체의 완성도는 지금 봐도 높습니다.

문제는 이 방법론이 만들어진 전제가 바뀌었다는 것입니다.

클라우드가 바꾼 전제들

클라우드 DW로 오면서 물리적 제약이 근본적으로 달라졌습니다.

Columnar Storage. BigQuery, Redshift, Synapse 모두 컬럼 기반입니다. SELECT에서 필요한 컬럼만 읽습니다. 컬럼이 수백 개인 테이블에서 서너 개만 조회하면 그것만 스캔합니다. Row 기반에서는 전부 읽어야 했습니다.

Compute/Storage 분리. 스토리지가 싸졌습니다. 중복 저장해도 비용 부담이 작습니다. 온프레미스에서 디스크 용량 아끼려고 정규화를 고민하던 것과는 상황이 다릅니다.

MPP 아키텍처. 대규모 병렬 처리가 기본입니다. 조인 비용이 온프레미스 RDBMS 대비 상대적으로 낮아졌습니다. 물론 공짜는 아닙니다. 셔플이 발생하면 여전히 느립니다. 하지만 “조인은 무조건 피하라"는 원칙이 더 이상 절대적이지 않습니다.

ELT 패러다임. 원본을 먼저 적재하고, DW 안에서 변환합니다. 변환 로직을 DW 엔진의 컴퓨팅 파워로 처리합니다. ETL 시절처럼 변환 서버를 별도로 두고 “다 만들어서 넣는” 구조가 아닙니다.

반정형 데이터 지원. JSON, ARRAY, STRUCT를 네이티브로 다룹니다. 전통적인 관계형 모델로 풀기 어려웠던 유연한 스키마를 DW 안에서 직접 처리할 수 있습니다.

이 변화들이 기존 모델링 원칙의 근거를 흔듭니다. 하지만 근거가 약해진 것과 원칙이 틀린 것은 다른 이야기입니다.

세 가지 선택지

클라우드 DW에서 자주 비교되는 세 가지 접근법이 있습니다.

1. Kimball Dimensional 모델링

스타스키마, 팩트와 디멘션, Conformed Dimension. 여전히 가장 널리 쓰입니다.

클라우드에서도 유효한 이유가 있습니다. 비즈니스 사용자가 이해하기 쉽습니다. “매출 팩트를 고객 디멘션으로 잘라본다"는 구조는 BI 도구와도 궁합이 좋습니다. Power BI, Tableau, Looker 전부 이 구조를 전제로 최적화되어 있습니다.

달라진 것도 있습니다. 집계 테이블을 미리 쌓아둘 필요가 줄었습니다. 컬럼나 스토리지에서 원본 팩트를 바로 집계해도 충분히 빠릅니다. SCD Type 2 같은 이력 관리도 스토리지 부담이 작아져서 더 적극적으로 쓸 수 있게 됐습니다.

약점은 유연성입니다. 스키마가 바뀌면 팩트/디멘션 구조를 재설계해야 합니다. 애자일하게 빠르게 바뀌는 요구사항에 대응하기가 구조적으로 어렵습니다.

2. Data Vault 2.0

Hub(비즈니스 키), Satellite(속성), Link(관계). 원본 데이터를 있는 그대로 이력과 함께 저장하는 데 초점을 맞춘 방법론입니다.

강점은 명확합니다. 감사 추적성(auditability). 원본이 언제 어떤 값이었는지를 완전하게 보존합니다. 소스 시스템이 추가되거나 스키마가 변경되어도 기존 구조에 영향을 주지 않습니다. 병렬 적재가 가능해서 ELT 패러다임과도 잘 맞습니다.

현실적인 걸림돌이 있습니다. 직접 쿼리하기가 까다롭습니다. Hub-Satellite 조인을 여러 번 거쳐야 하나의 비즈니스 엔터티가 나옵니다. 그래서 결국 프레젠테이션 레이어(보통 스타스키마)를 따로 만들어야 합니다. 모델링 레이어가 하나 더 생기는 셈입니다. 팀이 Data Vault 경험이 없으면 학습 곡선도 가파릅니다.

금융, 의료 같은 규제 산업에서 감사 추적이 필수일 때, 또는 소스 시스템이 수시로 추가되는 환경에서 강합니다.

3. One Big Table (OBT)

팩트와 디멘션을 전부 하나의 와이드 테이블에 합칩니다. 극단적인 비정규화입니다.

클라우드에서 이게 통하는 이유가 있습니다. 컬럼나 스토리지에서는 200개 컬럼이 있어도 쿼리에 쓰는 5개만 읽으니까 성능 저하가 크지 않습니다. 조인이 없으니 쿼리가 단순합니다. 개발 속도도 빠릅니다. dbt 같은 도구에서 한 번의 SELECT로 만들면 끝입니다.

대가가 있습니다. 데이터 정합성을 보장할 구조적 장치가 없습니다. 고객 주소가 바뀌면 모든 OBT를 다시 빌드해야 합니다. 같은 디멘션 속성이 여러 OBT에 중복되면 어디가 맞는 건지 알 수 없습니다. 데이터가 적고 도메인이 단순할 때는 빠르지만, 규모가 커지면 관리가 급격히 어려워집니다.

프로토타이핑이나 단일 도메인의 분석용 마트로는 좋습니다. 전사 DW의 기반 구조로 쓰기에는 위험합니다.

실무에서의 판단 기준

“뭐가 최고냐"는 의미 없는 질문입니다. 아래 기준으로 따져야 합니다.

팀 역량. Data Vault를 제대로 하려면 방법론을 아는 사람이 팀에 있어야 합니다. 없으면 Kimball이 현실적입니다. OBT는 진입 장벽이 낮지만 규모가 커지면 경험 있는 모델러가 더 절실해집니다.

데이터 복잡도. 소스 시스템이 3개인지 30개인지, 도메인이 하나인지 여러 개인지 봐야 합니다. 복잡도가 높을수록 Kimball의 Conformed Dimension이나 Data Vault의 Hub 구조가 필요합니다.

변경 빈도. 요구사항이 자주 바뀌는 환경이면 Data Vault가 유리합니다. 안정적인 환경이면 Kimball로 충분합니다.

규제 요건. 감사 추적이 법적으로 필요하면 Data Vault를 고려해야 합니다. 아니라면 오버엔지니어링이 될 수 있습니다.

쿼리 패턴. BI 대시보드 중심이면 Kimball 구조가 BI 도구와 궁합이 좋습니다. Ad-hoc 분석이 많으면 OBT의 단순함이 장점이 됩니다.

실무에서 자주 보는 패턴은 레이어드 접근입니다.

Raw (원본 적재) → Staging (정제) → Integration (통합 모델) → Mart (분석용)

Integration 레이어를 Data Vault로 설계하고, Mart를 스타스키마로 제공하는 조합이 대표적입니다. Data Vault는 허브-링크-위성 구조로 이력 추적과 유연한 확장에 특화되어 있고, 스타스키마는 중심 팩트 테이블 주위에 차원 테이블을 별 모양으로 배치한 분석 최적화 구조입니다. 또는 Integration을 중복 없이 정규화한 관계형 모델(3NF)로 잡고 Mart를 Kimball 방식으로 가는 전통적인 구조도 있습니다. 어느 쪽이든 핵심은 레이어를 나누는 것입니다.

한 레이어에서 원본 보존과 분석 최적화를 동시에 해결하려는 순간 복잡도가 폭발합니다.

모델링은 여전히 중요하다

클라우드로 오면서 바뀐 건 “왜 이렇게 모델링하는가"의 판단 기준이지, “모델링이 필요한가"의 여부는 아닙니다.

스토리지가 싸졌으니 비정규화를 더 적극적으로 해도 됩니다. 조인 비용이 줄었으니 집계 테이블을 덜 만들어도 됩니다. 하지만 비즈니스 용어의 일관성, 데이터 계보(lineage), 도메인 간 통합 - 이런 문제는 인프라가 바뀐다고 사라지지 않습니다.

오히려 클라우드에서 모델링 없이 시작한 팀이 나중에 더 고생합니다. OBT로 빠르게 만들어서 처음엔 잘 돌아갑니다. 1년 지나면 같은 지표의 정의가 테이블마다 다르고, 어디가 원본인지 아무도 모릅니다. 기술 부채는 조용히 쌓입니다.

도구와 인프라가 좋아진 만큼 모델링의 무게중심이 “성능 최적화"에서 “의미 체계의 일관성"으로 옮겨가고 있습니다. DataNexus에서 온톨로지로 풀려는 문제와 같은 맥락이기도 합니다. 기계가 읽을 수 있는 비즈니스 맥락이 없으면, 아무리 좋은 인프라 위에서도 데이터는 의미를 잃습니다.