분석용 데이터 저장소

회사에 데이터베이스가 하나뿐이던 시절이 있었습니다. 사용자가 문서를 열면 그 데이터베이스가 답을 돌려주고, 결제가 일어나면 같은 데이터베이스에 한 줄이 쌓였습니다. 숫자를 보려는 사람도 갈 곳이 거기뿐이었으니 같은 데이터베이스에 집계 질의를 날렸습니다.

그런데 서비스가 하는 일과 분석이 하는 일은 성격이 정반대입니다. 서비스는 한 줄을 빨리 찾아 돌려주면 됩니다. 지금 열린 문서 하나를 0.05초 안에 꺼내 오는 일이 하루에 수십만 번 반복됩니다. 분석은 그 반대로 수백만 줄을 한꺼번에 훑어 합계를 냅니다. 결제 기록 400만 줄을 요금제별로 묶어 월별 매출을 뽑는 질의 하나가 3분씩 돕니다. 그 3분 동안 같은 데이터베이스에 매달린 사용자 화면도 같이 느려집니다.

그래서 이 시절 회사들에는 비슷한 규칙이 하나씩 있었습니다. 무거운 질의는 사람이 없는 새벽에만 돌린다는 규칙입니다. 태오가 오후에 집계를 걸었다가 응답 시간 경보가 울려 급히 질의를 끊는 일이 한 달에 몇 번씩 있었고, 지현은 오늘 회의에 쓸 숫자를 다음 날 아침에 받았습니다. 분석을 하려면 서비스를 위험하게 만들어야 하는 구조였고, 그런 구조에서는 자연히 분석을 덜 하게 됩니다.

문제가 하나 더 있었습니다. 회사가 쓰는 데이터는 애초에 한곳에 모여 있지 않습니다. 결제 기록은 결제 대행사 쪽에, 사용자가 어떤 버튼을 눌렀는지는 이벤트 수집 도구에, 문의 내역은 고객 상담 도구에 들어 있습니다. 여기서 이벤트 수집 도구란 사용자의 행동 하나하나를 누가 언제 무엇을 했는지 한 줄로 남겨 두는 도구를 말합니다. 각각은 제 몫을 잘하지만, 결제한 사람이 그전 한 달 동안 어떤 화면을 지났는지 같은 물음은 세 곳을 합쳐야 답이 나옵니다. 합칠 자리가 없으면 사람이 세 곳에서 표를 내려받아 스프레드시트에서 손으로 붙입니다. 붙이는 사람마다 기준이 달라지고, 다음 달에 같은 물음이 오면 처음부터 다시 붙입니다.

분석용 데이터 저장소는 이 두 가지를 한자리에서 풉니다. 서비스가 쓰는 데이터베이스와 분리된 공간을 따로 두고, 흩어져 있던 원천을 그 안으로 복사해 모읍니다. 그러면 아무리 무거운 질의를 돌려도 사용자 화면은 영향을 받지 않고, 세 곳에 나뉘어 있던 기록이 한 공간 안에서 서로 연결됩니다. 서비스용 데이터베이스가 한 줄을 빨리 찾도록 설계된 것과 달리 이쪽은 수백만 줄을 한꺼번에 훑도록 설계돼 있어서, 같은 집계가 3분이 아니라 몇 초에 끝나기도 합니다.

데이터·분석 분야에서 이 자리는 처리 갈래의 가운데입니다. 원천에서 데이터를 끌어와 형태를 맞추고 옮기는 흐름이 데이터 파이프라인이고, 그렇게 옮겨 온 것을 담아 두는 그릇이 분석용 데이터 저장소이며, 담긴 값을 믿고 쓸 수 있게 지키는 일이 데이터 품질입니다. 셋은 앞뒤로 물려 있어서 그릇만 마련하고 나머지를 비워 두면 비어 있거나 어긋난 값이 잔뜩 쌓인 큰 창고가 남습니다.

분석용 데이터 저장소 아래 묶인 용어는 세 갈래입니다. 데이터를 담는 그릇을 어떤 모양으로 두는지(형태), 그 그릇 안을 어떤 순서의 층으로 나누는지(계층), 마지막 층에 놓을 표를 어떤 구조로 설계하는지(모델링)입니다.

형태는 그릇 자체를 가르는 갈래이고 세 자리가 있습니다. 나뉘는 기준은 들어가기 전에 얼마나 다듬느냐입니다.

1. 데이터 웨어하우스 — 미리 정한 구조에 맞춰 다듬은 데이터를 모아 둡니다. 어떤 칸에 어떤 값이 들어갈지를 넣기 전에 정해 두기 때문에 들어간 뒤에는 바로 꺼내 쓸 수 있습니다. 결제 기록이라면 결제일·계정·요금제·금액 네 칸으로 통일해 두는 식입니다. 대신 원천에 없던 칸이 생기거나 형식이 바뀌면 받아들이기 전에 손을 봐야 합니다.
2. 데이터 레이크 — 가공하지 않은 원본을 형식 그대로 쌓아 둡니다. 서버가 남긴 기록 파일, 고객이 올린 이미지, 칸 구성이 제각각인 외부 응답까지 일단 받아 둡니다. 넣을 때 맞출 규격이 없으니 무엇이든 들어오지만, 꺼내 쓸 때마다 이게 무슨 값인지 해석하는 수고가 붙습니다.
3. 데이터 마트 — 특정 부서나 주제에 맞춰 필요한 것만 잘라 놓은 작은 저장소입니다. 세일즈가 보는 계정별 결제 현황만 따로 떼어 두면 수아는 전체를 뒤지지 않고 그 표 하나만 봅니다.

셋은 하나를 고르는 문제가 아니라 겹쳐 쓰는 문제입니다. 흔한 조합은 원본을 레이크에 전부 쌓아 두고, 그중 분석에 쓸 것만 다듬어 웨어하우스에 올리고, 자주 보는 조각을 마트로 잘라 두는 것입니다.

계층은 저장소 안쪽을 가르는 갈래이고 세 자리가 있습니다. 나뉘는 기준은 원본에서 얼마나 멀어졌느냐입니다.

1. 로우 레이어 — 원천에서 받은 모양 그대로를 담는 첫 층입니다. 오타가 섞인 값도 비어 있는 칸도 손대지 않고 그대로 둡니다. 여기를 건드리지 않는 이유는 나중에 정제 규칙이 틀렸다는 것을 알았을 때 돌아올 자리가 필요하기 때문입니다.
2. 스테이징 레이어 — 정제 중간 단계를 담는 층입니다. 날짜 형식을 하나로 맞추고, 같은 계정이 두 줄로 들어온 것을 하나로 합치고, 금액 칸이 비어 있는 줄을 걸러 내는 일이 여기서 일어납니다.
3. 마트 레이어 — 분석하는 사람이 바로 꺼내 쓰도록 다듬어 놓은 마지막 층입니다. 계정 하나가 한 줄이고 가입일·요금제·누적 결제액·마지막 접속일이 한 줄에 다 들어 있는 표가 여기 놓입니다.

층을 나누는 이유는 같은 계산을 한 번만 하려는 데 있습니다. 매출을 계산하는 규칙을 마트 레이어의 표 하나에 박아 두면 대시보드와 주간 보고와 투자자 자료가 모두 같은 표를 봅니다. 층 없이 각자 원본에서 계산하면 같은 달 매출이 회의에 세 개 들어옵니다.

모델링은 마지막 층에 놓일 표의 생김새를 정하는 갈래이고 세 자리가 있습니다.

1. 차원 모델링 — 표를 측정값 쪽과 기준 쪽으로 나눠 설계하는 방법입니다. 나누는 목적은 저장 공간을 아끼는 데 있지 않고 처음 보는 사람도 원하는 각도로 잘라 볼 수 있게 만드는 데 있습니다.
2. 팩트 테이블 — 측정값이 쌓이는 중심 표입니다. 한 줄이 사건 하나에 대응합니다. 결제 한 건, 문서 생성 한 번이 각각 한 줄이고 금액이나 개수처럼 더할 수 있는 값이 칸에 들어갑니다.
3. 디멘전 테이블 — 그 측정값을 나눠 볼 기준을 담은 표입니다. 계정 표에는 요금제와 유입 경로와 산업군이, 날짜 표에는 요일과 분기가 들어 있습니다. 매출을 요금제별로 보고 싶다는 요구는 팩트 테이블에 계정 표를 붙여 요금제 칸으로 묶는 것으로 해결됩니다.

세 갈래는 순서대로 정합니다. 형태를 먼저 고르고, 그 안을 층으로 나누고, 마지막 층의 표를 모델링합니다. 순서를 건너뛰고 그릇만 만들어 두면 안에 원본이 그대로 쌓이고, 쓸 사람은 결국 매번 처음부터 정제해 쓰게 됩니다.

"그 숫자 서비스 디비에서 직접 뽑으신 거예요? 웨어하우스에 어제 것까지 올라와 있어요."

같은 값을 분석용 저장소에서 꺼낼 수 있으니 서비스 쪽을 건드리지 말라는 말입니다.

"원본은 로우에 그대로 두고 중복 제거는 스테이징에서 하죠."

정제 규칙을 나중에 고칠 수 있도록 원본 층은 손대지 말자는 제안입니다.

"이 표는 팩트라서 한 줄이 결제 한 건이에요. 그냥 세면 계정이 중복으로 잡힙니다."

표의 한 줄이 무엇을 뜻하는지 확인하지 않고 집계하면 숫자가 부풀어 오른다는 지적입니다.

페이지덱이 이 자리를 처음 만든 것은 시리즈 A 직후였습니다. 시작은 규원이 던진 질문 하나였습니다. 무료로 쓰다가 유료로 넘어온 팀이 넘어오기 전 한 달 동안 무엇을 했는지 알고 싶다는 요구였습니다. 답하려면 결제 대행사의 기록과 이벤트 수집 도구의 기록을 계정 단위로 붙여야 했는데, 두 곳은 같은 계정을 서로 다른 번호로 부르고 있었습니다. 지현이 양쪽에서 표를 내려받아 손으로 맞추는 데 이틀이 걸렸고, 석 달 뒤 비슷한 질문이 다시 왔을 때 그 이틀이 그대로 다시 들었습니다.

두 번째 요청을 받은 날 태오가 저장소를 만들자고 제안했습니다. 두 원천을 매일 새벽에 복사해 첫 층에 쌓고, 계정 번호를 하나로 맞추는 작업을 중간 층에서 처리하고, 계정 한 줄에 결제와 행동이 모두 붙은 표를 마지막 층에 놓는 구조였습니다. 만드는 데 3주가 걸렸습니다. 그 뒤로 같은 유형의 질문은 이틀짜리 작업이 아니라 20분짜리 질의 하나가 됐고, 지현이 다른 각도로 질문을 새로 던져도 이미 붙어 있는 표 위에서 답이 나왔습니다.

저장소를 마련하는 일과 데이터가 쓸 만해지는 일을 같은 일로 여기는 경우가 가장 많습니다. 도구를 붙이면 그날부터 복사가 돌기 시작하고 표 개수가 눈에 띄게 늘어나니 정리가 되고 있는 것처럼 보이기 때문입니다. 그러나 저장소는 그릇일 뿐이라 안에 무엇이 어떤 상태로 들어오는지는 따로 만들어야 합니다. 옮기는 흐름, 정제 규칙, 값이 어긋났을 때 알려 주는 점검이 붙지 않으면 그릇은 원본을 그대로 받아 둡니다. 그대로 두면 표가 300개인데 어느 표가 맞는 표인지 아무도 모르는 창고가 됩니다. 그 상태가 되면 사람들은 결국 각자 원천에서 다시 뽑아 쓰기 시작하고, 저장소는 쓰는 사람 없이 비용만 나가는 자리로 남습니다.

레이크가 웨어하우스의 상위 호환이라고 읽는 오해도 자주 봅니다. 한쪽은 무엇이든 넣을 수 있고 다른 쪽은 규격을 맞춰야 하니 제약이 적은 쪽이 더 나아 보이는 것이 자연스럽습니다. 하지만 둘의 차이는 좋고 나쁨이 아니라 다듬는 비용을 언제 내느냐입니다. 웨어하우스는 넣을 때 한 번 내고 꺼내는 사람은 그냥 씁니다. 레이크는 넣을 때 안 내는 대신 꺼내는 사람이 매번 냅니다. 분석가 다섯 명이 같은 원본을 각자 해석하면 비용은 다섯 번 나가고, 해석이 조금씩 달라져 같은 질문에 다른 답이 나옵니다. 그래서 레이크만 두고 위층을 만들지 않으면 넣기는 쉬웠는데 아무도 꺼내 쓰지 않는 상태가 됩니다. 실제로 많은 회사가 둘을 겹쳐 씁니다. 원본은 레이크에 두어 나중에 필요해질 값까지 잃지 않고, 분석에 자주 쓰는 것만 다듬어 웨어하우스에 올려 둡니다.