출시 2주 뒤 회의에서 누군가 묻습니다. “새 기능을 쓴 사람 가운데 몇 명이 끝까지 마쳤나요?” 대시보드를 열어 보니 시작 단추를 누른 기록은 있는데 마친 기록이 없습니다. 기록하지 않은 행동은 나중에 되살리기 어렵습니다. 지금부터 넣어도 지난 2주는 비어 있습니다.
이런 일은 분석을 못해서가 아니라 기록을 설계하지 않아서 생깁니다. 이 글에서는 출시 전에 무엇을 어떻게 기록할지 정하는 일, 곧 계측 설계를 차례대로 정리합니다. 지표를 어떻게 정의하는가는 다루지 않고, 그 지표를 계산할 재료를 빠짐없이 남기는 방법에 집중합니다.
알고 싶은 질문에서 시작하기
계측 설계에서 흔한 첫 실수는 화면을 보면서 “여기 단추가 있으니 누르면 기록하자”로 시작하는 것입니다. 이렇게 하면 기록은 많은데 정작 필요한 답은 못 얻습니다. 순서를 거꾸로 잡습니다.
- 출시 뒤 답해야 할 질문을 적습니다. 다섯 개에서 열 개 정도로 시작합니다. “새 사용자 가운데 첫 주문서를 끝까지 만든 사람은 얼마나 되는가”, “어느 단계에서 가장 많이 그만두는가”처럼 씁니다.
- 질문마다 어떤 결정에 쓰는지 적습니다. 답을 알아도 바뀌는 것이 없는 질문은 뺍니다.
- 질문에 답하려면 어떤 행동이 기록돼야 하는지 적습니다. “끝까지 만든 비율”을 알려면 시작한 행동과 마친 행동 둘이 다 있어야 합니다.
- 행동을 나눠 볼 기준을 적습니다. 요금제별로, 기기별로, 들어온 경로별로 나눠 보고 싶다면 그 값이 기록에 붙어 있어야 합니다. 이것이 뒤에서 말할 속성입니다.
질문 하나가 이벤트 두세 개와 속성 몇 개로 풀리면 잘된 것입니다. 어떤 질문에도 이어지지 않는 이벤트는 넣지 않습니다. PMI의 PMBOK® 지침서는 측정의 함정 가운데 하나로 허영 메트릭을 듭니다. 보기에는 그럴듯한데 다음에 무엇을 할지는 알려 주지 않는 숫자입니다. 지침서는 재는 일에도 시간과 품이 드니 쓸모 있는 것만 재라고도 말합니다. 사용 기록도 같습니다.
이벤트 이름 규칙과 속성 고르기
이벤트는 “사용자가 무엇을 했다”를 한 줄로 남긴 기록입니다. 이름이 사람마다 다르면 같은 행동이 여러 이름으로 쌓여 나중에 합치기 어렵습니다. 규칙은 무엇이든 좋지만 하나로 정하고 문서에 적어 둡니다. 예를 들면 다음과 같습니다.
- 대상과 행동을 순서대로 씁니다.
order_created,order_submitted,invite_sent처럼 “무엇이 어떻게 됐다” 꼴입니다. 흔히 대상과 행동(object-action) 순서라고 부릅니다. - 시제를 하나로 맞춥니다. 일어난 일을 적는 것이므로 과거형으로 통일하면 읽기 쉽습니다.
- 소문자와 밑줄만 씁니다.
OrderCreated와order_created가 섞이면 도구에 따라 다른 이벤트로 셉니다. - 화면 위치나 단추 색을 이름에 넣지 않습니다.
blue_button_clicked는 화면이 바뀌면 뜻을 잃습니다. 위치가 필요하면 속성으로 붙입니다. - 같은 행동은 이름 하나로 둡니다. 웹과 앱에서 같은 주문 제출이면 이름은 같게 두고
platform속성으로 나눕니다.
속성은 이벤트에 붙는 부가 정보입니다. 고를 때는 “이 값으로 나눠 볼 일이 있는가”를 묻습니다. 속성마다 이름, 자료형(글자, 숫자, 참과 거짓), 들어갈 수 있는 값을 정해 둡니다. plan 속성에 어떤 곳은 basic, 어떤 곳은 Basic 요금제가 들어가면 집계가 갈라집니다. 값이 정해져 있는 속성은 허용 값 목록을 명세서에 적습니다.
계측 명세서 만들기
위에서 정한 것을 표 한 장에 모은 것이 계측 명세서입니다. 기획자와 개발자, 분석 담당이 같은 표를 보고 일하게 하는 것이 목적입니다. 아래는 지어낸 주문 관리 서비스의 예입니다.
표는 가로로 밀어서 볼 수 있습니다.
| 이벤트 | 언제 생기나 | 속성 | 담당 | 확인 방법 |
|---|---|---|---|---|
order_started |
새 주문서 화면이 열렸을 때 | entry_point(목록, 알림, 검색), is_first_order(참과 거짓), plan, platform |
주문 화면 개발자 | 시험 환경에서 세 경로로 열어 기록 3건 확인 |
order_step_reached |
주문서의 각 단계 화면이 열렸을 때 | step(품목, 배송, 결제) |
주문 화면 개발자 | 단계를 차례로 넘기며 값 확인 |
order_submitted |
서버가 저장 성공을 돌려줬을 때 | item_count(숫자), is_first_order(참과 거짓), plan, platform |
주문 서버 개발자 | 저장 실패 때는 기록이 없는지 확인 |
invite_sent |
초대 메일 발송 요청이 성공했을 때 | invite_count(숫자) |
계정 서버 개발자 | 여러 명 초대 때 1건으로 남는지 확인 |
이 표로 앞에서 적은 두 질문에 답할 수 있는지 봅니다. 첫 주문서를 끝까지 만든 비율은 is_first_order가 참인 시작과 제출의 수로 계산합니다. 어느 단계에서 그만두는지는 “떠났다”를 따로 기록하지 않고 단계마다 닿은 수의 차이로 계산합니다. 화면을 떠나는 순간은 창을 닫으면 기록이 빠지기 쉬워서, 닿은 순간을 남기는 쪽이 더 믿을 만합니다. 요금제처럼 사용자에게 딸린 값은 이벤트마다 붙이지 않고 사용자 정보로 따로 두는 방법도 있습니다. 어느 쪽으로 할지 명세서에 적어 둡니다.
칸마다 이유가 있습니다.
- 언제 생기나가 가장 중요합니다. “제출 단추를 눌렀을 때”와 “서버가 저장에 성공했을 때”는 다른 숫자를 만듭니다. 실패한 제출까지 세면 완료율이 실제보다 높게 나옵니다. 한 문장으로, 누가 읽어도 같은 순간을 떠올리게 적습니다.
- 담당은 만들 사람과 깨졌을 때 고칠 사람을 정합니다. 담당이 비어 있는 이벤트는 깨져도 아무도 모릅니다.
- 확인 방법은 출시 전에 무엇을 해 보면 맞게 들어온 것인지 적는 칸입니다. 이 칸이 다음 절의 검증 목록이 됩니다.
명세서에는 판 번호와 고친 날짜를 적고, 이벤트를 더하거나 뜻을 바꿀 때는 표를 먼저 고친 뒤 코드를 고칩니다.
출시 전 검증과 출시 뒤 깨짐 감시
명세서대로 만들었다고 해서 명세서대로 기록되는 것은 아닙니다. 출시 전에 다음을 확인합니다.
- 명세서의 확인 방법을 하나씩 해 봅니다. 시험 환경에서 실제로 행동하고, 기록이 한 번만, 정해진 이름으로, 속성이 다 채워져 들어오는지 봅니다.
- 두 번 기록되거나 빠지는 경우를 찾습니다. 화면을 새로 고쳤을 때, 뒤로 가기를 눌렀을 때, 연결이 끊겼다 이어졌을 때가 흔한 자리입니다.
- 질문에 실제로 답해 봅니다. 시험 기록만으로 처음 적은 질문의 답을 계산해 봅니다. 계산이 안 되면 빠진 이벤트나 속성이 있는 것입니다.
- 시험 기록과 실제 기록을 나눕니다. 내부 사람의 사용이 실제 숫자에 섞이지 않도록 환경이나 계정으로 구분합니다.
출시 뒤에는 계측이 조용히 깨집니다. 화면을 고치다가 기록 코드가 빠져도 서비스는 멀쩡히 돌아가기 때문입니다. 핵심 이벤트 몇 개는 하루 건수를 지켜보다가 갑자기 0이 되거나 크게 달라지면 알림이 오게 해 둡니다.
개인정보: 꼭 필요한 것만
사용 기록은 사람의 행동을 남기는 일이므로 설계 단계에서 선을 긋습니다.
- 질문에 답하는 데 필요한 것만 기록합니다. 나중에 쓸지 몰라서 모으는 값은 넣지 않습니다.
- 사람을 알아볼 수 있는 정보는 속성에 넣지 않습니다. 이름, 전자우편 주소, 전화번호, 주소가 그렇습니다. 사용자를 구분해야 하면 내부에서 만든 식별 번호를 씁니다. 다만 식별 번호에 묶인 기록도 개인정보로 다뤄야 할 수 있으므로, 이름과 연락처만 빼면 끝난다고 보지 않고 담당자와 확인합니다.
- 자유롭게 적는 글은 그대로 기록하지 않습니다. 검색어나 메모 내용에는 개인정보가 섞여 들어오기 쉽습니다. 글 자체가 아니라 글자 수나 입력 여부로 바꿔 기록할 수 있는지 봅니다.
- 수집하는 항목이 이용자에게 알린 범위 안에 있는지 확인합니다. 판단이 서지 않으면 출시 전에 개인정보 담당자나 법무 담당자에게 명세서를 보여 주고 확인받습니다.
바로 쓰는 명세서 한 장
새 기능을 출시하기 전에 명세서 한 장을 채우고, 아래 목록으로 빠진 것이 없는지 점검합니다.
- 출시 뒤 답할 질문을 적고, 질문마다 어떤 결정에 쓰는지 적었습니다
- 질문마다 필요한 이벤트와 속성을 이었고, 질문에 이어지지 않는 이벤트는 뺐습니다
- 이벤트 이름이 정한 규칙(대상과 행동, 과거형, 소문자와 밑줄)을 따릅니다
- 이벤트마다 “언제 생기나”를 한 문장으로 적었습니다
- 속성마다 자료형과 허용 값을 적었습니다
- 이벤트마다 담당과 확인 방법이 있습니다
- 사람을 알아볼 수 있는 정보가 속성에 없고, 수집 항목이 알린 범위 안에 있습니다
- 시험 환경에서 확인 방법을 다 해 보고, 시험 기록으로 질문의 답을 계산해 봤습니다
- 핵심 이벤트의 하루 건수에 알림을 걸었습니다
- 명세서에 판 번호와 고친 날짜를 적었습니다
계측 설계는 기록을 많이 남기는 일이 아니라, 답할 질문을 먼저 정하고 그 답에 필요한 기록만 정확히 남기는 일입니다. 출시 전에 이 한 장을 채워 두면 출시 뒤 회의에서 “그 숫자는 없습니다”라고 말할 일이 줄어듭니다.
참고
- PMBOK® 지침서 8판 한국어판, 2.1.6.7 프로젝트 성과 감시 및 통제, 2.1.6.7.1 측정의 함정. 허영 메트릭이라는 말과, 쓸모 있는 것만 잰다는 생각만 따랐습니다. 문장은 옮기지 않았습니다.
- PMI와 PMBOK은 Project Management Institute의 등록 상표입니다.
- 그 밖에는 참고 자료 없이 직접 썼습니다. 본문의 주문 관리 서비스와 이벤트 이름은 설명을 위해 지어낸 예입니다.
- 지표를 정의하는 방법은 이 블로그의 「프로덕트 지표의 이해」, 기록한 데이터로 실험하는 방법은 「A/B 테스트와 실험 문화」 글을 함께 보세요.