프로덕트 애널리스트

팀이 작을 때는 숫자를 제품 담당자가 직접 뽑았습니다. 프로덕트 매니저가 저녁에 데이터베이스에 질의를 써서 지난주 수치를 받아 보는 식입니다. 사람이 적고 질문도 적을 때는 그럭저럭 돌아갑니다.

구성원이 마흔 명을 넘고 기능이 열 개를 넘으면서 두 가지가 동시에 걸렸습니다. 하나는 시간입니다. 질문 하나에 이틀이 걸리니 궁금한 것이 있어도 묻지 않고 넘기게 되고, 결정은 다시 회의에서 목소리 큰 쪽으로 기울었습니다. 다른 하나는 숫자가 서로 안 맞는 일이었습니다.

페이지덱 분기 회의에서 그 장면이 나왔습니다. 지현이 지난달 활성 사용자를 42,000명이라고 말했고, 현우는 같은 달을 38,000명이라고 말했습니다. 둘 다 직접 뽑은 숫자였습니다. 지현은 문서를 한 번이라도 연 사람을 셌고, 현우는 문서를 고친 사람만 셌습니다. 어느 쪽도 틀리지 않았는데 회의의 남은 40분은 두 숫자 중 무엇이 맞는지 다투는 데 썼습니다.

숫자를 빨리 뽑는 일과 그 숫자가 무엇을 센 것인지 하나로 정해 두는 일을 한 사람이 맡으면서 이 자리가 생겼습니다.

하루는 대개 어제 숫자를 확인하는 데서 시작합니다. 주요 지표를 한 화면에 모아 둔 대시보드를 열어 전날과 눈에 띄게 다른 값이 있는지 봅니다. 가입이 평소의 60퍼센트로 떨어졌다면 실제로 줄었는지, 기록을 남기는 쪽이 고장 나서 안 잡힌 것인지부터 가릅니다. 뒤쪽인 경우가 생각보다 잦습니다.

그다음은 들어온 질문을 처리하는 일이고, 이 자리의 일은 대개 다섯 단계로 흐릅니다.

1. 질문을 답할 수 있는 형태로 바꿉니다. "결제 전환이 왜 떨어졌어요" 는 그대로는 답이 없습니다. 어느 달과 비교해 몇 퍼센트인지, 전체가 떨어졌는지 특정 유입 경로만 떨어졌는지로 쪼개야 데이터로 답이 나옵니다.
2. 데이터가 믿을 만한지 확인합니다. 사용자 행동을 기록으로 남기는 이벤트 수집이 어긋나 있으면 그 위에서 뽑은 숫자는 전부 틀립니다. 결제 버튼을 누른 기록이 앱에서만 남고 웹에서 안 남고 있었다면 그 사실을 먼저 알려야 합니다.
3. 뽑습니다. 단계별로 얼마나 빠져나가는지 보는 퍼널 분석으로 어느 칸에서 사람이 사라지는지 찾거나, 쓰던 사용자가 계속 돌아오는 정도인 리텐션을 집단별로 갈라 봅니다.
4. 실험을 설계하고 판정합니다. 두 안을 무작위로 나눠 보여 주고 결과를 비교하는 A/B 테스트에서는 표본이 몇 명이어야 하는지, 며칠 돌려야 하는지, 차이가 우연일 가능성이 얼마인지를 미리 정합니다.
5. 전달합니다. 질의 결과를 그대로 넘기지 않고 한 장으로 씁니다. 무엇을 물었는지, 무엇이 나왔는지, 그래서 무엇을 하라는 것인지 세 줄이 들어갑니다.

시간이 가장 많이 드는 곳은 3번이 아니라 1번과 2번입니다. 질의를 쓰는 일은 30분이면 끝나는데, 무엇을 세는 것인지 합의하고 그 기록이 맞는지 확인하는 데 이틀이 갑니다.

가장 자주 붙는 사람은 제품을 맡은 지현입니다. 만들 후보를 고를 때 근거를 대고, 만든 뒤에 제품 지표가 움직였는지 판정합니다.

나머지 넷은 목적이 다릅니다.

1. 태오 — 기록을 심는 쪽입니다. 새 기능에 어떤 이벤트를 어떤 이름으로 남길지 개발 전에 함께 정합니다. 출시 뒤에 정하면 그 기능의 첫 달 데이터가 없어서 초기 반응을 영원히 못 봅니다.
2. 현우 — 실험을 가장 많이 돌리는 쪽입니다. 가입 화면 문구나 메일 제목을 바꿔 보는 일이 잦아서, 판정 기준을 미리 맞춰 두는 대화가 이 사람과 제일 많습니다.
3. 수아 — 계약 전에 고객이 실제로 쓰는지를 묻습니다. 기업 고객 한 곳의 사용량이 두 달 동안 줄고 있다는 사실은 갱신 협의를 여는 신호가 됩니다.
4. 규원 — 분기마다 전체 그림을 받습니다. 개별 기능의 수치가 아니라 팀 전체가 보는 대표 지표 하나가 어디로 가고 있는지를 봅니다.

회사가 더 커지면 제품 밖의 숫자까지 보는 데이터 분석가와 갈라지고, 분석용 데이터를 미리 정리해 두는 자리도 생깁니다.

"이 질문은 애널리스트한테 먼저 넘기죠. 지금 숫자로 답이 되는 질문인지부터 봐야 해요."

물음을 데이터로 답할 수 있는 형태로 바꿔 달라는 요청입니다.

"그 수치는 이벤트가 절반만 심겨 있어서 못 씁니다. 다음 배포 뒤에 다시 보죠."

기록 자체가 불완전해 지금 뽑은 값이 실제와 다르다는 뜻입니다.

"실험 기준부터 정하고 돌립시다. 며칠 뒤에 어느 숫자를 보면 되는지요."

결과를 보고 판정 기준을 고르지 않도록 미리 못 박자는 말입니다.

페이지덱에서는 이 자리가 회의를 닫는 쪽에 있습니다. 새 기능 후보를 놓고 논의가 갈리면 지현이 숫자를 요청하고, 다음 회의에서 그 한 장을 먼저 읽고 시작합니다. 숫자가 결정을 대신하지는 않습니다. 후보 셋 중 둘이 겨냥한 사용자 집단이 애초에 300명뿐이라는 사실이 나오면, 남은 하나로 논의가 좁혀지는 식입니다.

질의를 대신 써 주는 자리로 보는 경우가 가장 많습니다. 결과물이 표와 그래프라서 뽑는 일이 전부처럼 보입니다. 하지만 실제로 값을 만드는 부분은 질문을 다시 쓰는 데 있습니다. "전환이 떨어진 이유" 를 묻는 사람에게 필요한 답은 이유가 아니라 어느 단계에서 얼마나 떨어졌는지인 경우가 많습니다. 뽑아 주는 사람으로만 쓰면 요청은 밀려 있는데 결정은 여전히 감으로 나는 상태가 됩니다.

데이터가 답을 준다고 여기는 것도 흔합니다. 숫자는 무엇이 일어났는지 알려 주지만 왜 그런지는 알려 주지 않습니다. 결제 화면에서 40퍼센트가 나갔다는 사실은 데이터로 나오고, 그들이 가격 때문에 나갔는지 카드 등록이 번거로워서 나갔는지는 나오지 않습니다. 그래서 이 자리는 사용자에게 직접 묻는 일과 짝으로 굴러갑니다. 숫자만 보고 결론을 내면 고치기 쉬운 쪽을 원인으로 고르게 됩니다.