데이터 마트

데이터를 한곳에 모으고 나면 곧바로 다음 문제가 따라옵니다. 모아 둔 곳이 너무 크다는 것입니다. 데이터 웨어하우스에는 결제·가입·접속·문의 기록이 수백 개 표로 나뉘어 들어 있는데, 세일즈가 보고 싶은 것은 그중 계정별 결제 현황 하나뿐입니다. 그 하나를 보려고 어느 표의 어느 칸을 어떻게 이어 붙여야 하는지부터 알아내야 했습니다.

그래서 질문 하나가 답이 되기까지 며칠이 걸렸습니다. 수아가 "이번 달에 요금제를 올린 계정이 몇 개예요" 하고 물으면 데이터 담당이 표 여섯 개를 이어 붙이는 SQL 질의문을 씁니다. SQL 은 저장된 표에서 원하는 줄과 칸을 꺼내 오라고 적는 언어입니다. 2주 뒤에 같은 질문이 오면 다른 사람이 자기 방식으로 다시 씁니다. 한 사람은 무료 체험 계정을 빼고 세고 다른 사람은 넣고 세서, 같은 달 숫자가 41 과 57 로 두 개 나옵니다.

데이터 마트는 이 반복을 한 번으로 줄이려고 만든 자리입니다. 자주 나오는 질문의 답을 미리 표로 만들어 한곳에 두고, 그다음부터는 그 표만 봅니다. 물을 때마다 새로 계산하던 것을 이미 계산해 둔 것을 꺼내 쓰는 쪽으로 바꾼 겁니다.

데이터 마트는 같은 계산을 매번 다시 하는 상황을 없앱니다. 한 부서가 반복해서 묻는 질문을 추려 그 답이 되는 표를 미리 만들어 두고, 갱신은 하루 한 번처럼 정해진 주기로 자동으로 돌립니다.

없어지는 수고는 셋입니다.

1. 찾는 시간. 세일즈 마트에 표가 세 개뿐이면 수아는 수백 개 중에 무엇을 봐야 하는지 고민하지 않습니다. 계정 하나가 한 줄이고 요금제·누적 결제액·마지막 접속일이 그 줄에 다 들어 있는 표를 그대로 엽니다.
2. 숫자의 어긋남. 무료 체험 계정을 뺄지 말지 같은 판단을 표를 만들 때 한 번만 정해 박아 둡니다. 지표 정의를 문서가 아니라 표 안에 넣어 두는 셈이라 누가 꺼내 보든 같은 값이 나옵니다.
3. 기다리는 시간과 비용. 웨어하우스 전체를 훑는 질의는 수억 줄을 읽습니다. 미리 줄여 둔 표는 수만 줄이라 몇 초 만에 끝나고, 읽은 양만큼 요금을 매기는 저장소에서는 그만큼 값도 내려갑니다.

만드는 방법은 대개 데이터 파이프라인에 한 단계를 더하는 것입니다. 데이터 파이프라인은 원천에서 데이터를 가져와 다듬어 저장소에 넣는 자동화된 흐름입니다. 그 흐름 끝에 웨어하우스의 표 여섯 개를 이어 붙여 세일즈용 표 하나로 만드는 단계를 붙이고 매일 새벽에 돌립니다.

마트를 따로 만들지 않고도 같은 목적에 닿는 길이 셋 있습니다. 어느 쪽이 맞는지는 그 표를 볼 사람이 몇 명인지와 얼마나 자주 갱신돼야 하는지로 갈립니다.

1. 뷰만 만들어 둡니다. 뷰는 질의문에 이름을 붙여 저장해 둔 것으로, 열어 볼 때마다 그 질의가 원본 위에서 새로 돕니다. 저장 공간을 따로 쓰지 않고 항상 최신이라는 점이 좋지만, 무거운 계산이면 열 때마다 그 시간을 그대로 기다립니다.
2. 마트 레이어에 표를 하나 더 놓습니다. 저장소 안을 원본·정제·완성 세 층으로 이미 나눠 뒀다면 새 그릇을 만들 것 없이 마지막 층에 표 하나를 추가하는 것으로 끝납니다. 층 구조가 잡힌 팀에서는 이쪽이 먼저입니다.
3. 대시보드 도구 안에서 해결합니다. 요즘 도구는 데이터를 스스로 다듬어 품는 기능을 갖고 있어서 BI 담당자가 도구 안에서 표를 조합해 두면 보는 사람에게는 마트와 구분되지 않습니다. 다만 그 정의가 도구 안에만 있어서 도구를 바꾸면 함께 사라집니다.

볼 사람이 한 명이고 분기에 한 번 필요한 숫자라면 마트를 만드는 값이 쓰는 값보다 큽니다. 그때는 질의문을 한 번 돌려 결과를 내보내는 것이 답입니다. 마트는 같은 질문이 매주 돌아올 때부터 이득으로 넘어갑니다.

"세일즈 마트에 요금제 변경 이력 칸 하나만 추가해 주실 수 있나요?"

저장소를 새로 만들자는 게 아니라 이미 있는 표에 칸을 하나 늘려 달라는 요청입니다.

"그 숫자 마트에서 뽑은 거예요, 원본에서 직접 뽑은 거예요?"

두 경로의 값이 다를 수 있으니 어느 쪽을 봤는지 확인하는 말입니다.

"마트 새로 파기 전에 기존 걸로 되는지부터 봅시다."

저장소가 늘면 관리할 정의도 같이 는다는 뜻으로, 추가를 한 번 막아 세우는 말입니다.

페이지덱에서는 세일즈 마트가 가장 먼저 생겼습니다. 수아가 매주 같은 질문을 가져왔기 때문입니다. 어느 계정이 이번 달에 요금제를 올렸는지, 어느 계정이 3주째 안 들어왔는지, 계약 갱신이 다음 달인 계정이 몇 개인지가 매번 반복됐습니다. 태오가 세 질문의 답을 한 표에 합쳐 두고 새벽 4시에 갱신되도록 걸어 뒀습니다.

그다음부터 회의 모양이 바뀌었습니다. 예전에는 수아가 화요일에 요청해 목요일에 숫자를 받고 금요일 회의에 들고 갔습니다. 지금은 회의 도중에 표를 열어 봅니다. 대신 규칙이 하나 생겼습니다. 숫자가 이상하면 표를 고치지 말고 표를 만드는 단계를 고치기로 한 겁니다. 표에서 값을 직접 바꿔 두면 다음 새벽에 원래대로 돌아오기 때문입니다.

부서마다 마트를 하나씩 만들어 두면 좋다고 생각하기 쉽습니다. 각자 보고 싶은 게 다르니 각자의 그릇을 갖는 편이 자연스러워 보이고, 만드는 일 자체는 어렵지 않습니다. 그런데 마트가 늘면 같은 이름의 지표가 마트마다 조금씩 다른 규칙으로 계산되기 시작합니다. 세일즈 마트의 활성 계정은 이번 달에 결제한 계정이고 마케팅 마트의 활성 계정은 이번 달에 한 번이라도 들어온 계정인 식입니다.

그대로 두면 회의에 활성 계정 숫자가 두 개 들어오고, 어느 쪽이 맞는지 가리는 데 회의 시간의 절반이 갑니다. 마트를 나눠서 생긴 문제라 마트를 더 만들어서는 풀리지 않습니다. 계산 규칙은 웨어하우스 쪽 한 곳에 두고 마트는 그 결과를 잘라 가져가는 구조로 잡아야 합니다. 단일 진실 원천이 가리키는 게 이 자리입니다. 같은 값에 대해 기준이 되는 곳을 하나만 둔다는 원칙입니다.