차원 모델링

제품이 쓰는 데이터베이스는 분석하라고 만든 것이 아닙니다. 같은 값을 두 군데 적지 않는 것을 목표로 설계하기 때문에, 계정 정보는 계정 표에, 결제 정보는 결제 표에, 요금제 정보는 요금제 표에, 할인 정보는 할인 표에 흩어져 있습니다. 앱이 한 줄씩 읽고 쓰기에는 이 모양이 제일 낫습니다.

문제는 그 데이터베이스를 그대로 분석에 쓸 때 생깁니다. 페이지덱에서 지현이 "이번 달 매출을 요금제별로" 라고 물으면, 태오는 표 일곱 개를 순서대로 이어 붙이는 질의문을 씁니다. 어떤 표를 어떤 칸으로 잇는지 알아야 하고, 환불된 결제를 빼는 조건과 시험 계정을 걸러 내는 조건도 기억해야 합니다. 이틀이 걸립니다.

그리고 다음 주에는 "같은 걸 유입 경로별로" 라는 요청이 옵니다. 각도만 바뀌었는데 질의문을 처음부터 다시 씁니다. 더 나쁜 것은 사람마다 다르게 쓴다는 점입니다. 태오는 환불을 빼고 세고 다른 사람은 빼지 않고 세면, 같은 달 매출이 회의에 두 개 들어옵니다.

차원 모델링은 이 지점을 뒤집습니다. 저장 공간을 아끼는 대신 읽는 사람이 헤매지 않는 쪽으로 표를 다시 짭니다. 사건이 쌓이는 표 하나를 가운데 두고, 그 사건을 나눠 볼 기준 표들을 둘레에 붙여 두는 모양입니다. 가운데 표를 팩트 테이블, 둘레의 표를 디멘전 테이블이라고 부릅니다. 이렇게 짜 두면 각도를 바꾸는 일이 질의문을 다시 쓰는 일이 아니라 칸을 하나 바꿔 고르는 일이 됩니다.

네 단계를 순서대로 밟습니다. 무엇을 다룰지 고르고, 한 줄의 단위를 정하고, 나눠 볼 기준을 고르고, 마지막으로 셀 값을 정합니다.

1. 다룰 사건 고르기 — 결제·문서 생성·팀원 초대처럼 반복해서 일어나는 일 하나를 고릅니다. 회사 전체를 한 번에 모델링하지 않습니다. 가장 자주 묻는 질문이 걸려 있는 사건부터 시작하고, 페이지덱이라면 결제입니다.
2. 한 줄의 단위 정하기 — 팩트 테이블 한 줄이 무엇에 대응하는지 한 문장으로 적습니다. "결제 한 건" 인지 "계정의 한 달 결제 합계" 인지를 여기서 못 박습니다. 잘게 잡을수록 나중에 묶어 볼 여지가 남습니다. 월 합계로 잡아 두면 주 단위 질문에 영영 답할 수 없습니다.
3. 나눠 볼 기준 고르기 — 그 한 줄을 어떤 각도로 자를지 정하고, 각도마다 기준 표를 하나씩 둡니다. 결제라면 날짜·계정·요금제·지역이 각각 표 하나가 됩니다. "언제·누가·무엇을·어디서" 를 채우면 대개 빠진 것이 보입니다.
4. 셀 값 고르기 — 팩트 테이블에 넣을 숫자를 정합니다. 더할 수 있는 값만 넣습니다. 결제 금액과 결제 건수는 들어가고 전환율 같은 비율은 넣지 않습니다. 비율을 넣으면 여러 줄을 묶을 때 비율의 평균이 계산되는데, 그 값은 전체 비율과 다릅니다. 분자와 분모를 각각 칸으로 두고 보는 쪽에서 나누게 합니다.

네 단계를 마치면 가운데 팩트 테이블 하나에 기준 표 서넛이 붙은 모양이 나옵니다. 별을 닮아서 별 모양 구조라고 부릅니다. 이 표들은 보통 분석하는 사람이 바로 꺼내 쓰는 마트 레이어에 놓습니다.

같은 질문이 각도만 바꿔 되풀이되고, 그 답을 볼 사람이 데이터를 다루는 직군이 아닐 때 잘 맞습니다. 페이지덱이 매주 신규 결제 건수를 요금제별로, 유입 경로별로, 지역별로 돌아가며 확인한다면 딱 이 경우입니다. 한 번 짜 두면 데이터 분석가를 거치지 않고도 지현이 대시보드에서 필터를 바꿔 스스로 답을 냅니다. 집계 규칙이 표 하나에 박혀 있으니 BI 담당자가 만든 리포트와 지현이 본 화면의 숫자도 어긋나지 않습니다.

한계는 셋입니다.

1. 무엇을 볼지 아직 모르는 단계에는 이릅니다. 3단계에서 기준을 미리 골라야 하는데, 제품을 막 낸 팀은 그 목록을 못 만듭니다. 이때는 원본을 직접 뒤지는 편이 빠릅니다.
2. 한 줄의 단위를 잘못 잡으면 되돌리는 값이 큽니다. 2단계를 바꾸는 것은 표를 새로 만들고 과거 데이터를 다시 채우는 일이라, 그 사이 대시보드가 멈춥니다.
3. 얽힌 관계를 따라가는 질문에는 맞지 않습니다. "이 사용자가 초대한 사람이 또 초대한 사람" 처럼 연결을 타고 가는 질문은 이 구조로 잘 풀리지 않습니다.

"이 팩트 테이블 한 줄이 뭐예요? 결제 한 건이에요, 계정-월이에요?"

단위부터 확인하는 말입니다. 이걸 모르면 합계를 잘못 읽습니다.

"비율은 팩트에 넣지 말고 분자랑 분모를 따로 넣어 주세요."

묶어서 볼 때 평균이 틀어지니 계산은 보는 쪽에서 하자는 뜻입니다.

"그 각도로 보려면 디멘전을 하나 더 붙여야 해서 이번 주는 어렵습니다."

기준 표가 없는 각도라 설계를 손봐야 한다는 말입니다.

페이지덱에서는 결제 모델을 가장 먼저 짰습니다. 한 줄을 결제 한 건으로 잡고, 날짜·계정·요금제 세 기준을 붙였습니다. 반년 뒤 현우가 유입 경로별 매출을 물었을 때는 표를 다시 만들 필요가 없었습니다. 계정 기준 표에 유입 경로 칸을 더하는 것으로 끝났습니다.

반대로 문서 생성 모델은 한 번 갈아엎었습니다. 처음에 한 줄을 "계정의 하루 생성 건수" 로 잡았는데, 시간대별 사용 패턴을 보자는 요청이 들어오자 답할 방법이 없었습니다. 단위를 생성 한 건으로 바꾸고 과거 넉 달치를 다시 채우는 데 2주가 걸렸습니다.

같은 값이 여러 줄에 되풀이되면 잘못 설계한 표라고 읽는 경우가 많습니다. 데이터베이스를 배울 때 중복을 없애는 쪽이 정답이라고 익히니 그렇게 보입니다. 하지만 두 설계는 목적이 다릅니다. 제품 데이터베이스는 같은 값을 한 군데만 두어 수정 실수를 막으려 하고, 분석용 표는 읽는 사람이 표를 이어 붙이지 않고도 질문을 던지게 하려 합니다. 중복을 지우려고 기준 표를 잘게 쪼개면 저장 공간은 줄지만, 이어 붙이는 법을 모르는 사람은 질문 자체를 포기합니다.

한 번 설계하면 끝이라고 보는 것도 흔한 오해입니다. 설계라는 말이 건물 도면처럼 들리기 때문입니다. 실제로는 기준 칸이 계속 늘고, 원천이 바뀌면 채우는 규칙도 바뀝니다. 유지할 사람을 정해 두지 않으면 반년 뒤에는 아무도 값을 믿지 않는 표가 남고, 사람들은 다시 각자 원본을 뒤집니다.