단일 진실 원천

한 회의에 같은 이름의 숫자가 세 개 들어오던 시절이 있었습니다. 규원이 지난달 매출을 묻자 수아는 영업 관리 도구에서 뽑은 1억 2천만 원을, 지현은 분석 도구에서 뽑은 1억 1천 4백만 원을 내놓았고, 결제사 정산서 기준으로는 1억 1천 8백만 원이었습니다.

셋 다 틀리지 않았습니다. 계산 규칙이 서로 달랐을 뿐입니다. 영업 도구는 계약이 체결된 달에 금액을 잡고, 분석 도구는 결제가 승인된 달에 잡습니다. 환불을 처리한 달에 빼는지 결제한 달로 되돌려 빼는지, 부가세를 포함하는지, 1년치를 한 번에 받은 계약을 열두 달로 나눠 적는지가 모두 갈렸습니다.

그래서 회의는 결정 대신 대조로 흘러갔습니다. 30분 동안 어느 숫자가 맞는지 따지다가 다음에 각자 뽑아 온 근거를 맞춰 보자는 말로 끝났고, 정작 하려던 판단은 다음 주로 밀렸습니다.

단일 진실 원천은 이 문제를 숫자 검증이 아니라 배치로 푸는 원칙입니다. 어느 값이 맞는지 매번 따지는 대신, 그 값에 대해 기준이 되는 자리를 하나만 정해 두고 나머지는 모두 그 자리에서 가져다 씁니다.

두 가지를 지키면 성립합니다. 계산식을 한곳에만 적어 두는 것, 그리고 값을 보여 주는 모든 화면이 원천 데이터에서 다시 세지 않고 그 결과를 가져다 쓰는 것입니다.

구분해야 하는 자리가 셋입니다. 값이 만들어지는 원천 시스템, 계산식이 적히고 결과가 보관되는 중간층, 그리고 사람이 보는 화면입니다. 하나로 못 박는 대상은 가운데입니다. 원천은 여러 개일 수밖에 없고 화면도 여러 개여야 하지만, 매출이라는 값의 계산식은 하나여야 합니다. 이 중간층을 두는 자리가 보통 데이터 웨어하우스, 곧 분석용 데이터를 정리된 구조로 모아 둔 저장소입니다.

세우는 순서는 넷입니다.

1. 지표마다 소유자를 한 명 정합니다. 정의를 고칠 권한과 고쳤을 때 알릴 책임이 그 사람에게 붙습니다.
2. 계산식을 쿼리나 코드로 한 번만 적고 이름을 붙입니다. 매출이라는 이름 아래 어떤 결제를 어느 달에 잡는지가 그 안에 들어갑니다. 이 내용을 문장으로 풀어 적어 둔 것이 지표 정의입니다.
3. 모든 화면이 그 이름을 가져다 씁니다. 보고서를 만들 때 원천 결제 기록에서 직접 합계를 내지 않습니다. 이 규칙이 깨지는 순간 두 번째 숫자가 생깁니다.
4. 고칠 때는 영향 범위를 먼저 알립니다. 어느 화면과 어느 보고서가 이 값을 쓰고 있는지 목록이 있어야 합니다.

4번이 빠지면 원천을 하나로 만들어 놓고도 같은 혼란이 돌아옵니다. 정의를 바꾸면 과거 값까지 함께 바뀌기 때문입니다. 활성 사용자에서 내부 직원 계정을 빼기로 하면 지난달 숫자가 4만에서 3만 8천으로 내려앉는데, 이 사실을 공지하지 않으면 다음 회의에서 누군가 성장이 꺾였다고 보고합니다. 그래서 정의를 고칠 때는 바꾼 날짜와 이유, 바뀐 전후 값을 같은 문서에 적어 둡니다.

숫자만의 원칙이 아닙니다. 회사가 반복해서 참조하는 값이면 어디에나 붙고, 자리는 넷으로 나눠 볼 수 있습니다.

첫째는 지표입니다. 매출, 활성 사용자, 유지율처럼 여러 팀이 같은 이름으로 부르는 값이 여기 듭니다.

둘째는 고객 정보입니다. 한 회사의 직원 수가 영업 관리 도구와 결제 시스템과 고객 지원 도구에 각각 다르게 적혀 있을 때, 어느 쪽을 기준으로 삼을지 정해 두지 않으면 고객 규모별 분석이 도구마다 다른 답을 냅니다.

셋째는 문서입니다. 가격표, 환불 규정, 제품 결정 사항 같은 것들입니다. 결정이 메신저 대화에 흩어져 있으면 두 달 뒤에 무엇이 최종인지 아무도 모릅니다. 기준 문서를 하나 정해 두고 대화에서 내린 결정은 거기 옮겨 적습니다.

넷째는 설정값입니다. 무료 플랜의 문서 개수 한도가 서버 코드와 화면 코드와 안내 문서에 각각 박혀 있으면 한도를 올릴 때 한 곳이 빠집니다.

"그거 어디 보면 돼요" 라는 질문에 두 곳 이상을 답해야 한다면 그 자리에는 원천이 없습니다. 다만 복제를 완전히 없앨 수는 없습니다. 속도 때문에 미리 계산해 두거나 권한 때문에 따로 떠 두는 사본은 생깁니다. 지켜야 할 것은 사본을 없애는 일이 아니라 어느 쪽이 기준인지 못 박는 일입니다.

"이 숫자 어디서 뽑았어요? 웨어하우스 매출 모델 기준인가요?"

같은 이름의 값이 여럿일 수 있으니 어느 원천에서 나왔는지 확인하는 질문입니다.

"가격표는 문서 쪽이 기준이에요. 슬라이드에 적힌 값은 지난달 것입니다."

두 곳에 같은 정보가 있을 때 어느 쪽을 따라야 하는지 정해 두었다는 뜻입니다.

"활성 사용자 정의를 바꾸면 지난 분기 숫자도 같이 바뀝니다. 바꾼 날짜랑 전후 값을 문서에 남겨 주세요."

정의 변경이 과거 데이터까지 건드리니 기록을 남겨 혼란을 막자는 요청입니다.

페이지덱에서 이 원칙은 매출 숫자가 세 개 들어온 회의 뒤에 자리를 잡았습니다. 지현이 지표 열두 개의 계산식을 웨어하우스에 한 번씩만 적어 두고, 대시보드와 투자자 보고 자료가 모두 그 값을 가져다 쓰게 바꿨습니다. 수아가 영업 관리 도구에서 보던 계약 금액은 그대로 남기되, 그 숫자는 영업 진행 상황용이고 회사 매출이 아니라고 문서에 적었습니다. 규원이 묻는 매출은 이제 한 개입니다.

데이터를 한 곳에 모아 저장하는 일이라고 읽는 오해가 가장 흔합니다. 이름에 원천이라는 말이 들어가니 저장 위치를 합치는 일처럼 보입니다. 그런데 실제로 하나로 만드는 것은 저장 위치가 아니라 기준입니다. 결제 기록이 결제사와 웨어하우스와 백업에 각각 있어도 문제가 아니고, 그중 어느 것이 매출의 기준인지 정해져 있지 않은 것이 문제입니다. 저장소 통합으로 이해하면 반년짜리 이전 작업을 벌이고도 각 팀이 자기 계산식을 그대로 쓰는 상태로 끝납니다.

도구를 하나 도입하면 해결된다는 생각도 자주 봅니다. 분석 도구나 데이터 카탈로그를 들이면 그 안에 기준이 생길 것처럼 보입니다. 하지만 도구는 누가 정의를 정하고 누가 고칠 수 있는지를 대신 정해 주지 않습니다. 매출 계산식을 무엇으로 할지 합의하지 않은 채 도구를 넣으면 같은 도구 안에 매출이라는 이름의 모델이 세 개 생깁니다. 필요한 순서는 반대입니다. 소유자와 정의를 먼저 정하고 도구는 그것을 담는 그릇으로 씁니다.