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

클라우드 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에서 온톨로지로 풀려는 문제와 같은 맥락이기도 하다. 기계가 읽을 수 있는 비즈니스 맥락이 없으면, 아무리 좋은 인프라 위에서도 데이터는 의미를 잃는다.