AI한테도 조인 시키실 건가요? 저는 와이드 테이블로 갑니다 (Star Schema vs. Wide Table)

4 분 소요

데이터 웨어하우스 모델링 이야기를 하면 늘 스타 스키마 vs. 플랫 와이드 테이블 이야기가 나옵니다. 예전에는 이 질문에 꽤 정석적인 답이 있었습니다. 분석용이면 스타 스키마, 운영성이나 단순 조회면 와이드 테이블 정도로 정리하곤 했습니다.

그런데 요즘은 그렇게 단순하게 말하기가 어렵습니다. 특히 BigQuery, ClickHouse 같은 현대적인 분석 엔진을 쓰는 환경에서는, 저는 오히려 와이드 테이블 쪽으로 더 자주 기울게 됩니다. AI를 같이 쓰기 시작하면 그 경향은 더 강해집니다.

이 글은 “스타 스키마는 구식이고 와이드 테이블이 정답입니다” 같은 이야기를 하려는 글은 아닙니다. 다만 AI 시대 기준으로 다시 보면, 와이드 테이블이 생각보다 더 실용적인 선택이라는 이야기를 해보고 싶었습니다.

먼저 구조부터 다릅니다

구성도를 보면 스타 스키마는 팩트 테이블과 여러 차원 테이블의 관계를 중심으로 구성됩니다.

graph LR
    D1["dim_customer"] --> F["fact_order"]
    D2["dim_product"] --> F
    D3["dim_date"] --> F
    D4["dim_channel"] --> F

반면 와이드 테이블은 조회나 분석에 필요한 컬럼을 한 테이블 안에 가능한 많이 펼쳐둡니다.

graph TD
    W["wide_order_table
order_id
order_date
customer_id
customer_name
product_id
product_name
channel
amount
region"]

둘의 차이는 단순히 정규화 여부만이 아닙니다. 데이터를 읽는 방식, 쿼리를 짜는 방식, 운영하는 방식이 전부 달라집니다.

왜 스타 스키마가 오랫동안 표준이었는가

스타 스키마는 좋은 모델입니다. 이 말은 지금도 유효합니다.

장점은 명확합니다.

비즈니스 개체가 잘 드러납니다
재사용 가능한 차원 테이블을 만들 수 있습니다
지표 정의를 정돈하기 좋습니다
데이터 중복을 줄이기 쉽습니다
BI 모델링과 권한 관리가 구조적으로 깔끔합니다

특히 전통적인 DW에서는 이 구조가 매우 강력했습니다. 저장 비용도 더 민감했고, 정규화와 계층 구조를 잘 잡아두는 것이 곧 모델링 품질이던 시절이 있었습니다.

저도 여전히 고객, 상품, 조직, 날짜 같은 핵심 차원을 제대로 관리해야 하는 조직에서는 스타 스키마가 주는 질서가 크다고 봅니다.

그런데 현대 DW에서는 계산이 달라집니다

문제는 지금 우리가 쓰는 엔진이 예전과 다르다는 점입니다.

BigQuery 같은 컬럼형 엔진에서는 조인이 아주 비싼 선택이 될 수 있습니다. 물론 무조건 느리다는 뜻은 아닙니다. 다만 대규모 팩트와 대규모 차원을 계속 조인하는 패턴은 비용과 복잡도를 같이 올리는 경우가 많습니다.

데이터 엔지니어 입장에서 운영해보면 이런 순간이 자주 나옵니다.

비슷한 조인을 모든 리포트가 반복합니다
분석가마다 조인 조건을 조금씩 다르게 씁니다
차원 테이블 변경이 하위 쿼리에 연쇄적으로 영향을 줍니다
셀프서비스 분석이라고 해놓고 실제로는 조인 규칙을 아는 사람만 제대로 씁니다

이쯤 되면 모델이 예쁜 것과 잘 쓰이는 것은 다르다는 생각을 하게 됩니다.

그래서 와이드 테이블이 자주 이깁니다

와이드 테이블은 단순합니다. 필요한 컬럼을 한 장에 펼쳐두고, 사용자는 그걸 바로 읽으면 됩니다.

데이터 엔지니어 관점에서 와이드 테이블의 장점은 꽤 현실적입니다.

1. 쿼리가 단순해집니다

조인이 줄어들면 쿼리도 단순해집니다. 단순한 쿼리는 보통 다음 장점으로 이어집니다.

작성 속도가 빨라집니다
실수할 가능성이 줄어듭니다
리뷰와 운영이 쉬워집니다
지표 정의를 재현하기 쉬워집니다

특히 조직 안에 SQL 숙련도가 다양한 사용자가 섞여 있으면, 와이드 테이블은 생각보다 큰 생산성 차이를 만듭니다.

2. 성능보다 더 중요한 것은 예측 가능성입니다

현업에서는 “가끔 빠른 모델”보다 “대체로 예상 가능한 모델”이 더 낫습니다.

스타 스키마는 잘 설계하면 매우 좋지만, 사용자가 조인을 잘못하는 순간 결과도 틀리고 비용도 커집니다. 반면 와이드 테이블은 애초에 잘못 조인할 여지를 줄여버립니다.

저는 이것이 단순한 편의성 문제가 아니라 운영 안정성 문제에 더 가깝다고 봅니다.

3. AI가 맥락을 이해하기에도 유리합니다

AI 시대에는 이 장점이 더 커집니다.

LLM에게 SQL을 생성하게 하거나, 테이블 설명을 읽고 지표를 찾게 하거나, 자연어로 데이터 탐색을 시키는 경우를 생각해보면 결국 모델은 한 번에 읽히는 맥락 에 강합니다.

스타 스키마에서는 AI가 이런 것들을 동시에 이해해야 합니다.

어떤 테이블이 팩트인지
어떤 차원이 어떤 키로 연결되는지
어떤 조인이 1:N인지
어떤 컬럼이 실제 분석 기준인지
어느 차원이 최신 기준인지

반면 와이드 테이블은 이런 인지 부하를 줄여줍니다.

필요한 컬럼이 한 테이블 안에 있습니다
컬럼명만 읽어도 의미가 드러납니다
잘못된 조인 경로를 추론할 여지가 적습니다
프롬프트 안에 테이블 설명을 넣기도 쉽습니다

즉, 와이드 테이블은 단순히 사람이 쓰기 쉬운 모델이 아니라, AI가 문맥을 잃지 않도록 돕는 모델이기도 합니다.

AI 시대의 실제 기준은 “정규화”보다 “맥락 전달력” 같습니다

요즘은 데이터를 사람이 직접 보는 것만 고려하면 부족합니다. BI 툴, 메트릭 레이어, SQL 생성기, 에이전트형 분석 도구까지 모두 같은 테이블을 읽습니다.

이때 중요한 질문은 이것 같습니다.

“이 모델이 정규화 관점에서 얼마나 예쁜가?” 보다는
“이 모델이 사람과 AI 모두에게 얼마나 덜 헷갈리게 읽히는가?”

이 기준으로 다시 보면 와이드 테이블은 꽤 강합니다.

테이블 구조를 보면 전달해야 할 맥락이 한 덩어리로 모여 있습니다.

graph LR
    A["사용자 질문"] --> B["AI / BI Tool"]
    B --> C["wide table"]
    C --> D["직접 집계 / 필터 / 탐색"]

반대로 스타 스키마에서는 관계 이해 단계가 하나 더 들어갑니다.

graph LR
    A["사용자 질문"] --> B["AI / BI Tool"]
    B --> C["fact table 선택"]
    C --> D["dimension join 판단"]
    D --> E["집계 / 필터 / 탐색"]

이 추가 단계는 숙련자에게는 별것 아닐 수 있습니다. 하지만 셀프서비스 분석이나 AI 보조 분석에서는 꽤 큰 차이를 만듭니다.

그렇다고 스타 스키마가 필요 없다는 뜻은 아닙니다

여기서 자주 오해가 생깁니다. 와이드 테이블이 좋다는 말은 스타 스키마를 버리자는 뜻이 아닙니다.

오히려 저는 둘의 역할을 분리해서 보는 편이 더 현실적이라고 생각합니다.

코어 모델과 기준 차원 관리에는 스타 스키마가 여전히 유효합니다
최종 소비 계층에서는 와이드 테이블이 더 실용적일 수 있습니다
AI나 셀프서비스 분석용 서빙 계층은 와이드 테이블이 특히 강합니다

즉 내부 표준 모델은 정돈해두고, 마지막 서빙은 와이드하게 가져가는 식입니다. 실제 운영에서는 이 절충안이 꽤 자주 먹힙니다.

어떤 상황에서 무엇을 고를까

제가 실무에서 대략 이렇게 판단합니다.

스타 스키마가 더 어울리는 경우:

조직 차원 정의가 매우 중요합니다
여러 팩트가 공통 차원을 재사용합니다
BI 모델링 체계가 이미 잘 잡혀 있습니다
데이터 거버넌스와 표준화가 우선입니다

와이드 테이블이 더 어울리는 경우:

BigQuery 같은 컬럼형 엔진 중심입니다
소비자가 직접 SQL을 많이 작성합니다
AI가 SQL 생성이나 탐색에 자주 개입합니다
조인 실수를 줄이는 것이 중요합니다
빠른 전달과 셀프서비스가 우선입니다

제 결론

요즘 제 기준은 꽤 단순합니다.

기준 정보와 의미 체계는 정돈하되, 소비는 가능한 넓고 단순하게 제공하자 입니다.

스타 스키마는 여전히 좋은 모델입니다. 다만 모든 소비 계층의 기본값이어야 하느냐고 묻는다면, 지금은 그렇지 않다고 봅니다. 특히 AI가 데이터 모델을 함께 읽는 시대에는, 와이드 테이블이 주는 문맥 전달력과 사용성 이점이 생각보다 큽니다.

결국 중요한 것은 모델링 이론의 승패가 아닙니다. 사람이든 AI든, 데이터를 더 덜 헷갈리게 읽고 더 덜 틀리게 쓰게 만드는 구조가 지금 조직에 맞는 구조라고 생각합니다.

댓글 목록

관리자 보기

관리자 키

YourFiesta Blog