마트 레이어

층을 나누기 전에는 모두가 원본을 직접 뒤졌습니다. 이번 달 유료 계정 매출이 궁금하면 결제 기록 표와 계정 표를 각자 붙여서 계산했습니다. 문제는 계산 규칙이 사람 머릿속에 있었다는 점입니다. 환불된 건을 뺄지, 체험 기간에 걸린 결제를 셀지, 취소된 계정의 지난달 결제를 남길지는 각자 판단했습니다.

그래서 월요일 회의에 같은 달 매출이 세 개 들어왔습니다. 지현은 4,820만 원, 규원은 5,100만 원, 재무는 4,650만 원을 들고 왔습니다. 셋 다 틀리지 않았고 셋 다 다른 규칙으로 센 것뿐이었습니다. 어느 값이 맞는지 가리는 데 회의의 절반이 갔고, 다음 달에 같은 일이 또 벌어졌습니다.

마트 레이어는 이 계산을 한 곳에 못 박으려고 둡니다. 매출을 세는 규칙을 표 하나에 박아 두면 대시보드와 주간 보고와 투자자 자료가 같은 표를 봅니다. 각자 계산하지 않으니 값이 갈릴 일이 없습니다. 이것이 저장소 안쪽을 층으로 나누는 가장 큰 이유입니다.

원본에서 가장 멀리 떨어진 층이고, 그만큼 질문에 가깝게 생겼습니다. 로우 레이어의 표는 원천 시스템이 만든 모양 그대로라 사람이 읽기 어렵고, 스테이징 레이어의 표는 형식만 맞춰 놓은 중간 상태입니다. 마트 레이어의 표는 그 위에서 질문 단위로 다시 묶입니다.

이 층의 표는 대체로 이런 모습입니다.

1. 한 줄이 분석 대상 하나에 대응합니다. 계정 표라면 계정 하나가 한 줄이고, 가입일·요금제·누적 결제액·마지막 접속일이 그 한 줄에 다 들어 있습니다.
2. 여러 원천이 이미 합쳐져 있습니다. 쓰는 사람이 결제 표와 접속 기록 표를 따로 붙일 필요가 없습니다.
3. 계산이 끝나 있습니다. 누적 결제액이나 이용 개월 수처럼 규칙이 필요한 값이 이미 칸에 들어 있습니다.
4. 이름이 업무 언어로 붙어 있습니다. usr_stat_cd 가 아니라 계정_상태 입니다.

그래서 데이터 분석가가 아니어도 이 층은 다룰 수 있습니다. 마케터가 요금제별 유지율을 보고 싶을 때 표 다섯 개를 붙이는 대신 마트 레이어의 계정 표 하나에 조건을 걸면 됩니다.

대신 이 층은 원본이 아닙니다. 단일 진실 원천이라는 말이 붙지만, 그건 지표의 기준이라는 뜻이지 여기 값이 원본이라는 뜻이 아닙니다. 정제 규칙이 잘못됐다는 걸 알았을 때 돌아갈 자리는 로우 레이어입니다. 마트 레이어의 표는 언제든 지우고 다시 만들 수 있어야 합니다.

여기서 만든 표를 실제 업무에 쓰려면 세 가지가 먼저 갖춰져야 합니다.

첫째, 지표 정의가 문서로 정해져 있어야 합니다. 지표 정의는 무엇을 어떻게 세는지 못 박은 규칙입니다. "유료 계정" 이 결제가 한 번이라도 있는 계정인지 이번 달에 결제가 있는 계정인지가 문장으로 적혀 있지 않으면, 표를 만드는 사람이 그 자리에서 정하게 되고 처음의 세 숫자가 그대로 돌아옵니다.

둘째, 표가 갱신된 시각과 실패 여부가 보여야 합니다. 마트 레이어는 대개 하루에 한 번 다시 계산되는데, 새벽 작업이 실패했는데도 어제 값이 그대로 화면에 떠 있으면 아무도 틀린 걸 모릅니다. 갱신 시각을 화면에 같이 띄우고 실패하면 알림이 오게 해 두는 것이 이 층을 쓰기 시작하는 최소 조건입니다.

셋째, 쓰는 사람이 어떤 표가 있는지 찾을 수 있어야 합니다. 표가 마흔 개인데 목록이 없으면 새로 온 사람은 결국 자기 표를 하나 더 만듭니다. 비슷한 표가 늘어나면 층을 나눈 효과가 사라집니다.

세 조건이 갖춰지면 이 층 위에 차원 모델링으로 구조를 다시 잡는 단계로 넘어갑니다. 측정값을 담는 팩트 테이블과 그것을 나눠 볼 기준을 담은 디멘전 테이블로 표를 갈라 두는 방식입니다. 질문마다 표를 하나씩 만들던 방식은 질문이 스무 개를 넘으면 유지가 안 되고, 그때 이 구조로 옮겨 갑니다.

"그 숫자 어디서 뽑으셨어요? 마트에 있는 계정 테이블 쓰셨나요?"

기준이 되는 표를 썼는지 확인해 값이 갈린 이유를 찾는 질문입니다.

"그건 마트 레이어에 없어요. 스테이징에서 직접 꺼내셔야 해요."

아직 정리된 표가 없으니 중간 단계에서 직접 계산해야 한다는 뜻입니다.

"이 계산은 대시보드 말고 마트 테이블에 넣어 주세요."

같은 규칙을 여러 화면에서 따로 짜지 말고 한 곳에 박아 두자는 요청입니다.

페이지덱에서는 태오가 새벽에 도는 갱신 작업을 관리하고, 지현이 그 결과로 만들어진 계정 표를 봅니다. 요금제를 하나 늘린 달에 지현이 새 요금제가 표에 안 잡힌다고 알려 오면, 태오가 스테이징의 변환 규칙을 고치고 마트 레이어의 표를 다시 만듭니다. 고치는 자리는 언제나 표가 아니라 그 표를 만드는 규칙입니다. 표를 손으로 고치면 다음 갱신에 그대로 지워집니다.

마트 레이어를 따로 두면 저장 공간과 작업이 두 배로 든다고 보는 경우가 있습니다. 같은 데이터가 층마다 복제되니 낭비처럼 보이는 게 사실입니다. 하지만 실제로 줄어드는 건 사람 시간 쪽입니다. 다섯 명이 매번 같은 조인을 다시 짜고 결과가 갈려 맞춰 보는 시간이, 표 하나를 하루 한 번 다시 만드는 비용보다 큽니다.

또 하나는 마트 레이어에 표가 많을수록 좋다고 여기는 것입니다. 요청이 올 때마다 표를 하나씩 만들면 처음 몇 달은 편합니다. 문제는 비슷한 표가 늘어나면서 생깁니다. 계정_요약·계정_요약_v2·계정_요약_마케팅 이 나란히 있고 셋의 유료 계정 기준이 조금씩 다르면, 결국 처음 층을 나누기 전과 같은 상태로 돌아갑니다. 표를 더할 때 기존 표를 넓힐 수 있는지 먼저 보는 습관이 이 층을 오래 쓰게 합니다.