지표 정의

숫자는 이름만 같으면 같은 뜻일 거라고 믿기 쉽습니다. 그 믿음이 깨지는 자리는 보통 회의실입니다.

페이지덱의 월간 회의에서 지현이 지난달 월간 활성 사용자가 4만이라고 보고했습니다. 바로 다음 순서에서 현우가 같은 달 수치를 3만 2천으로 읽었습니다. 누가 맞는지 30분을 다퉜는데, 확인해 보니 둘 다 자기 기준에서는 맞았습니다. 지현은 한 번이라도 로그인한 계정을 셌고, 현우는 문서를 열거나 쓴 계정만 셌습니다. 지현은 최근 30일을 봤고 현우는 달력상의 1일부터 말일까지를 봤습니다. 내부 직원과 테스트 계정 180개는 지현 쪽에만 들어 있었습니다.

이런 회의의 손해는 30분이 아닙니다. 그날 정하려던 안건은 유료 전환 캠페인을 이번 분기에 돌릴지였는데, 기준이 되는 숫자가 흔들리자 결정이 다음 달로 밀렸습니다.

지표 정의는 이 다툼을 회의 전으로 옮겨 두려고 만든 문서입니다. 세는 규칙을 미리 적어 두면 회의에서는 값이 맞는지가 아니라 무엇을 할지만 다루게 됩니다. 규칙이 최선인지는 그다음 문제입니다. 다른 규칙을 쓰더라도 모두가 같은 규칙을 쓰는 쪽이 먼저입니다.

지표 정의 문서 한 장에는 보통 여섯 가지가 들어갑니다.

1. 이 숫자로 내릴 결정을 한 줄로 적습니다. 왜 세는지가 없으면 나머지 다섯 줄을 판단할 기준이 없습니다. 월간 활성 사용자라면 "유료 전환 캠페인의 대상 규모를 가늠한다" 처럼 씁니다. 이 줄을 적어 두면 나중에 그 숫자를 팀 목표로 걸자는 제안이 나왔을 때 원래 용도와 맞는지 따져 볼 수 있습니다. 재는 도구가 목표가 되면 재는 기능을 잃는다는 굿하트의 법칙이 여기서 걸립니다.
2. 무엇을 하나로 세는지 정합니다. 계정 하나인지, 사람 하나인지, 기기 하나인지에 따라 값이 크게 달라집니다. 한 사람이 회사 계정과 개인 계정을 따로 쓰면 계정 기준으로는 2가 되고 사람 기준으로는 1이 됩니다.
3. 어떤 행동을 해야 세는지 정합니다. 로그인만 해도 세는지, 문서를 한 번 열어야 세는지, 글자를 입력해야 세는지를 적습니다. 페이지덱은 문서를 열거나 편집한 계정만 세기로 했습니다. 알림 메일의 링크를 눌러 들어왔다가 바로 닫은 사람까지 활성으로 세면 그 숫자로 캠페인 대상을 가늠할 수 없기 때문입니다.
4. 기간을 정합니다. 오늘부터 거슬러 30일인지, 달력상의 한 달인지를 밝힙니다. 둘은 매달 다른 값을 냅니다. 30일 기준은 매일 값이 움직이고, 달력 기준은 2월과 3월의 날짜 수가 달라 그것만으로 몇 퍼센트가 흔들립니다.
5. 무엇을 빼는지 적습니다. 내부 직원 계정, 테스트 계정, 자동화 도구의 접속이 대표적입니다. 45명 회사에서 이런 계정 180개를 빼지 않으면 초기 숫자가 실제보다 눈에 띄게 부풀려집니다.
6. 값을 어디서 가져오는지 못 박습니다. 어느 테이블의 어떤 계산식을 쓰는지를 적고, 모든 화면이 그 한곳을 보게 합니다. 이 항목이 단일 진실 원천 원칙과 만나는 자리입니다.

여섯 줄 아래에 바꾼 기록을 덧붙입니다. 언제, 왜 바꿨고, 바뀐 전후 값이 얼마였는지를 남깁니다. 정의를 고치면 과거 값도 함께 바뀌기 때문입니다.

초안은 그 숫자로 결정을 내릴 사람이 잡습니다. 페이지덱에서는 지현이 씁니다. 1번 줄을 쓸 수 있는 사람이 그 사람뿐입니다. 데이터 담당자가 먼저 쓰면 세는 방법은 정확해지는데 무엇에 쓸 숫자인지가 비게 됩니다.

초안이 나오면 태오가 붙어 실제로 그렇게 셀 수 있는지를 확인합니다. 여기서 대개 한 번 깎입니다. 문서를 편집한 계정만 세자고 정해 놨는데 편집 기록이 30일치만 남아 있으면 그 정의는 쓸 수 없습니다. 재고 싶은 것과 지금 로그에 남아 있는 것이 다를 때는 정의를 현실에 맞추거나, 로그를 먼저 고치고 다음 분기부터 그 정의를 쓰기 시작합니다.

읽는 사람은 그 숫자를 입에 올리는 모든 사람입니다. 대시보드에서 값을 보는 사람, 투자자 자료에 숫자를 적는 규원, 캠페인 성과를 보고하는 현우가 다 해당합니다. 그래서 문서는 데이터 담당자끼리 읽을 말로 쓰지 않습니다.

정의를 고칠 때는 고치기 전에 알립니다. 활성 사용자에서 내부 계정을 빼기로 하면 지난달 숫자가 4만에서 3만 8천으로 내려앉는데, 이 사실을 공지하지 않으면 다음 회의에서 누군가 성장이 꺾였다고 보고합니다.

"그 숫자 정의가 어떻게 되나요?"

값을 믿을지 말지 정하기 전에 세는 규칙부터 확인하겠다는 뜻입니다.

"정의를 바꿨으니 지난달 값도 같이 내려갑니다."

지표가 떨어진 게 아니라 세는 기준이 달라졌다는 예고입니다.

"이 정의로는 그 질문에 답할 수 없어요."

숫자 자체는 맞지만 지금 하려는 결정에 맞는 숫자가 아니라는 지적입니다.

페이지덱이 유료 전환 캠페인을 준비하면서 활성 사용자 정의를 다시 잡았습니다. 지현이 초안을 쓰고, 태오가 로그를 확인하고, 현우가 캠페인 대상을 뽑을 때 쓸 수 있는 기준인지를 봤습니다. 세 사람이 합의한 뒤 값은 4만에서 3만 1천으로 내려갔습니다.

숫자가 내려간 날 규원이 성장이 멈춘 거냐고 물었고, 지현이 정의를 바꾼 문서를 열어 전후 값을 나란히 보여 줬습니다. 정의 문서가 하는 일이 대개 이렇습니다. 숫자를 정확하게 만든다기보다 숫자를 두고 같은 말을 반복하지 않게 만듭니다.

정의를 데이터 담당자가 알아서 챙길 기술 문서로 여기는 경우가 많습니다. 계산식과 테이블 이름이 적혀 있으니 그렇게 보입니다. 하지만 정의의 절반은 기술이 아니라 판단입니다. 내부 계정을 뺄지, 로그인만으로 활성으로 볼지는 데이터에서 나오는 답이 아니라 이 숫자로 무엇을 할지에서 나오는 답입니다. 이 일을 통째로 넘기면 문법적으로 정확하고 아무 결정에도 쓸 수 없는 숫자가 만들어지고, 반년 뒤에 각 팀이 자기 정의로 다시 세기 시작합니다.

한 번 정한 정의는 바꾸면 안 된다고 믿는 것도 흔합니다. 바꾸면 과거와 비교가 안 되니 그럴듯합니다. 하지만 제품이 바뀌면 같은 규칙이 다른 것을 재게 됩니다. 모바일 앱을 내놓은 뒤에도 웹 접속만 세고 있으면 그 숫자는 점점 실제 사용량과 멀어집니다. 바꾸지 않는 것이 규칙이 아니라 바꾼 사실을 남기는 것이 규칙입니다. 바꾼 날짜와 이유, 전후 값을 같은 문서에 적어 두면 과거와의 비교도 유지됩니다.