데이터 웨어하우스

회사가 쓰는 데이터는 처음부터 한자리에 있지 않습니다. 가입과 문서 기록은 제품이 돌아가는 저장소에, 결제 내역은 결제 대행사 쪽에, 광고비는 광고 플랫폼에 따로 쌓입니다. 각 시스템은 자기 일에 필요한 모양으로만 데이터를 들고 있어서, 옆 시스템과 계정을 맞출 기준이 없습니다.

그래서 질문 하나에 며칠이 걸립니다. 규원이 "지난달에 유료로 넘어온 계정이 어느 경로로 들어왔죠" 하고 물으면, 지현은 제품 쪽에서 가입 경로를 받고 결제 쪽에서 전환 목록을 받아 스프레드시트에서 이메일 주소로 짝을 맞춥니다. 이틀이 걸리고, 다음 달에 같은 질문이 오면 다시 이틀이 걸립니다.

급하면 제품이 쓰는 저장소에 직접 조회를 돌리기도 합니다. 태오가 6개월치 문서 생성 기록을 한 번에 세어 보려고 질의를 던졌더니 그 몇 분 동안 서비스 화면이 눈에 띄게 느려졌습니다. 제품을 돌리는 저장소와 분석하는 저장소가 같으면 분석할 때마다 제품이 대가를 치릅니다.

데이터 웨어하우스는 이 둘을 한꺼번에 풉니다. 흩어진 것을 미리 한곳에 모으고, 그 사본을 제품과 떼어 놓습니다.

해결하는 문제는 셋입니다. 데이터가 흩어져 있다는 것, 분석이 제품을 느리게 만든다는 것, 같은 값을 부르는 기준이 부서마다 다르다는 것입니다.

1. 흩어진 원천을 한자리로 모읍니다. 데이터 파이프라인이 정해진 시각마다 결제·광고·상담 시스템을 돌며 데이터를 퍼 와 웨어하우스에 넣습니다. 계정 식별자를 한 가지로 맞추는 일도 이때 함께 합니다.
2. 제품이 쓰는 저장소를 건드리지 않습니다. 데이터베이스는 제품이 지금 돌아가는 데 필요한 읽기와 쓰기를 맡고, 웨어하우스는 그 사본 위에서 집계만 합니다. 6개월치를 한 번에 세는 질의가 아무리 무거워도 서비스 화면은 그대로입니다.
3. 같은 값에 대한 답을 하나로 만듭니다. 매출을 계산하는 규칙을 웨어하우스의 표 하나에 박아 두면 대시보드와 주간 보고와 투자자 자료가 모두 그 표를 봅니다. 단일 진실 원천이라고 부르는 원칙이고, 이게 없으면 같은 달 매출이 회의에 세 개 들어옵니다.

셋을 가능하게 만드는 건 넣기 전에 구조를 정해 두는 방식입니다. 결제 기록이라면 결제일·계정·요금제·금액 네 칸으로 통일해 두고, 원천이 어떤 모양으로 주든 그 네 칸에 맞춰 넣습니다. 대신 원천에 없던 칸이 생기거나 형식이 바뀌면 받아들이기 전에 손을 봐야 합니다.

웨어하우스를 세우지 않고 버티는 자리는 넷이고, 데이터의 양과 모양에 따라 갈립니다.

1. 스프레드시트 — 원천이 두세 개고 행이 수만 개 안쪽이면 이쪽이 가장 빠릅니다. 구성원 다섯 명인 회사가 웨어하우스부터 세우는 건 대개 이른 선택입니다. 행이 수십만을 넘으면 파일이 버티지 못하고, 갱신을 사람이 하니 누가 어느 사본을 보고 있는지 알 수 없습니다.
2. 제품 저장소에 직접 질의 — SQL로 운영 중인 저장소에 바로 물어보는 방법입니다. SQL 은 표 구조의 데이터에 조건을 걸어 원하는 값을 꺼내는 표준 언어입니다. 옮기는 과정이 없으니 값이 늘 최신입니다. 대신 앞에서 본 부하 문제가 그대로 남고, 결제나 광고처럼 제품 밖에 있는 데이터는 애초에 여기 없습니다.
3. 데이터 레이크 — 가공하지 않은 원본을 형식 그대로 쌓아 둡니다. 서버가 남긴 기록 파일이나 칸 구성이 제각각인 외부 응답처럼 미리 규격을 정할 수 없는 데이터가 많다면 이쪽이 맞습니다. 대신 꺼내 쓸 때마다 이게 무슨 값인지 해석하는 수고가 붙습니다.
4. 데이터 마트 — 특정 부서나 주제에 필요한 것만 잘라 놓은 작은 저장소입니다. 웨어하우스의 대체재가 아니라 대개 그 위에서 잘라 만드는 것이라, 둘 중 하나를 고를 일이 아닙니다.

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

갈아탈 시점은 셋이 겹칠 때입니다. 같은 질문이 매달 반복되고, 답을 만드는 데 원천 세 곳 이상을 뒤져야 하고, 그 작업에 하루 이상 걸리면 그때가 웨어하우스를 세울 때입니다. 하나만 해당하면 대개 아직 이릅니다.

"그 숫자 웨어하우스에 있는 값인가요, 결제 시스템에서 직접 뽑은 값인가요?"

같은 지표가 두 곳에서 다르게 나올 수 있으니 어느 쪽을 본 것인지 확인하는 질문입니다.

"그건 아직 웨어하우스에 안 올라와 있어요. 파이프라인에 붙이는 데 한 주쯤 걸립니다."

원천에는 있지만 옮겨 오는 흐름을 아직 만들지 않아 바로는 못 본다는 뜻입니다.

"웨어하우스는 어젯밤 기준이라 오늘 들어온 건 안 보여요."

적재가 하루 한 번이라 오늘 데이터는 내일 아침에야 보인다는 안내입니다.

페이지덱은 시리즈 A 직후에 웨어하우스를 세웠습니다. 그전까지 지현은 매달 초 사흘을 스프레드시트에 썼고, 수아는 계정별 결제 현황이 필요할 때마다 지현에게 부탁했습니다. 지금은 가입·문서 사용·결제·광고비가 하루 한 번 한곳으로 모이고, 수아는 자기 화면에서 바로 봅니다.

바뀐 것은 속도만이 아닙니다. 예전에는 지현이 만든 표와 수아가 만든 표에서 지난달 유료 계정 수가 달라, 회의 절반이 어느 쪽이 맞는지 가리는 데 갔습니다. 지금은 둘 다 같은 표를 봅니다.

웨어하우스를 세우면 데이터가 정확해진다고 기대하는 경우가 많습니다. 정리된 구조로 들어간다는 말이 값까지 검증된다는 말처럼 들리기 때문입니다. 실제로는 옮기고 모아 두는 도구일 뿐이라, 원천이 틀린 값을 주면 틀린 값이 그대로 정리된 모양으로 앉습니다. 그대로 두면 오히려 더 나빠집니다. 스프레드시트 시절에는 이상한 값이 눈에 띄었는데, 웨어하우스를 거친 숫자는 다들 검증을 지난 값으로 여겨 그대로 대표 보고에 실립니다.

만들어 두면 알아서 쓰인다는 기대도 자주 어긋납니다. 데이터가 한곳에 있으니 누구나 찾아 쓸 것 같지만, 표가 300개로 늘어나면 처음 보는 사람은 어느 표가 자기 질문에 맞는지 모릅니다. 어떤 표가 무엇을 담고 누가 관리하는지 적어 두는 일을 함께 하지 않으면, 사람들은 결국 데이터 담당자에게 물어보는 예전 방식으로 돌아갑니다.