사용자가 아직 0명일 때 봐야 할 지표와 대시보드 최소 구성

사용자가 0명인 서비스의 7일 리텐션은 몇 퍼센트일까요. 계산이 되지 않습니다. 분모가 0이기 때문입니다. 그런데도 많은 개인 서비스의 관리자 화면 첫 줄에는 DAU와 리텐션 자리가 마련되어 있고, 거기에는 대개 0과 하이픈이 표시되어 있습니다.

관리자 화면을 먼저 만들어두는 편이 낫다는 이야기와, 로그 다음에 필요한 것이 상태를 보는 화면이라는 이야기는 앞서 따로 쓴 적이 있습니다. 이 글은 그 다음 단계입니다. 그래서 그 화면에 정확히 무엇을 몇 개나 넣을 것인가를 목록으로 정리합니다.

기준은 하나입니다. 그 숫자를 보고 내일 할 일이 바뀌는가. 바뀌지 않는 숫자는 아무리 그럴듯해도 초기에는 자리만 차지합니다. 사용자 0명 구간에서 그 조건을 만족하는 항목은 생각보다 적습니다.

0명일 때 의미가 생기는 다섯 가지

초기 구간에서 실제로 판단에 쓰이는 것은 다음 다섯 가지였습니다. 나머지는 사용자가 생긴 뒤에 붙여도 늦지 않습니다.

• 서비스가 살아 있는가: 가장 기본입니다. 응답이 오는지, 데이터베이스에 붙는지, 외부 API 키가 아직 유효한지. 사용자가 없는 시기에는 서비스가 며칠씩 죽어 있어도 아무도 알려주지 않습니다. 제가 실제로 나흘 뒤에 알아챈 적이 있습니다.

• 어디서 오류가 나는가: 총 오류 건수보다 어떤 화면과 어떤 요청에서 나는지가 중요합니다. 초기에는 오류 하나가 곧 방문자 한 명의 이탈이라, 종류별로 한 건씩만 확인해도 고칠 목록이 나옵니다.

• 첫 화면에서 어디까지 갔는가: 방문자 수보다 훨씬 유용합니다. 들어와서 아무것도 안 누르고 나갔는지, 입력창까지 갔다가 나갔는지, 실행 버튼을 눌렀는지. 세 지점만 구분해도 무엇이 막혔는지 짐작이 됩니다.

• 가입을 시도했다가 실패했는가: 가입 완료 수는 0이어도 시도 후 실패는 0이 아닐 수 있습니다. 이 숫자는 사용자가 없을 때도 발생하고, 발생하면 거의 항상 제 잘못입니다. 초기에 가장 값어치 있는 항목이라고 생각합니다.

• 내가 직접 쓴 횟수: 만든 사람이 안 쓰는 서비스는 개선 방향도 잡히지 않습니다. 주 단위로 내 계정의 사용 횟수를 세어봅니다. 두 주 연속 0이면 기능이 아니라 서비스의 존재 이유를 다시 봐야 할 시점입니다.

반대로 이 구간에서 빼도 되는 것들도 분명합니다. DAU와 MAU, 리텐션 곡선, 코호트 분석, 유입 채널별 전환율, 평균 체류 시간. 전부 나중에 중요해지지만, 지금은 0을 예쁘게 그리는 그래프일 뿐입니다.

대시보드 최소 위젯 목록

위 다섯 가지를 화면으로 옮기면 위젯 여덟 개가 됩니다. 한 화면에 스크롤 없이 들어가는 분량이고, 저는 이 이상 늘리지 않으려고 합니다.

위젯표시 내용이걸 보고 하는 일

상태 신호등웹, DB, 외부 API 각각 정상 여부와 마지막 확인 시각빨간 항목이 있으면 즉시 확인
최근 오류 10건시각, 요청 경로, 오류 종류, 발생 횟수같은 오류가 반복되면 그것부터 수정
오늘의 요청 수시간대별 막대. 내 IP는 구분해서 표시0이면 유입 문제, 나만 있으면 홍보 단계 확인
첫 화면 단계별 도달진입, 입력 시작, 실행 세 단계의 건수끊긴 단계의 화면을 다시 손봄
가입 시도와 실패시도 수, 실패 수, 실패 사유별 분류실패 사유가 있으면 그날 안에 재현
내 사용 기록최근 4주간 내 계정의 주별 사용 횟수2주 연속 0이면 방향 재검토
느린 요청 5건응답 시간 상위 경로와 소요 시간첫 화면 경로가 있으면 우선 개선
저장소 사용량DB 크기, 파일 용량, 이번 달 증가분증가 속도가 이상하면 원인 추적

여덟 개 중에서 하나만 고르라면 상태 신호등입니다. 나머지는 며칠 늦게 알아도 되지만, 서비스가 죽어 있는 것은 늦게 알수록 손해가 그대로 쌓입니다. 두 번째로 고르라면 가입 시도와 실패입니다. 이 둘만 있어도 초기 운영은 굴러갑니다.

어렵지 않게 채우는 방법

이 위젯들은 전용 분석 도구 없이도 채울 수 있습니다. 도구를 붙이는 데 드는 시간이 위젯을 직접 만드는 시간보다 긴 경우가 많습니다.

• 상태 신호등: 각 의존성을 한 번씩 호출해보는 확인용 경로를 하나 만들고, 대시보드에서 그 결과를 표시합니다. 외부 감시 서비스를 붙이면 더 좋지만, 없어도 화면을 열 때마다 확인은 됩니다.

• 오류와 느린 요청: 이미 남기고 있는 로그를 집계하면 됩니다. 요청 경로, 상태 코드, 소요 시간 세 가지만 구조화된 형태로 남겨두면 나머지는 질의로 뽑힙니다.

• 단계별 도달: 화면에서 이벤트 이름과 시각만 남기는 테이블 하나를 둡니다. 이름, 시각, 세션 식별자 세 칸이면 충분합니다. 처음부터 스키마를 정교하게 잡으려 하면 이 단계에서 진도가 멈춥니다.

• 가입 실패: 실패 처리 코드 안에서 사유를 함께 기록합니다. 검증 실패, 중복, 외부 인증 오류 정도로만 나눠도 원인 파악에는 충분합니다.

표시 방식은 숫자와 목록이면 됩니다. 그래프는 시간대별 요청 수 하나만 있어도 되고, 그마저도 없어도 판단에는 지장이 없습니다. 대시보드를 예쁘게 만드는 데 시간을 쓰기 시작하면 그것 자체가 또 하나의 프로젝트가 됩니다.

지표를 늘릴 시점

언젠가는 위 여덟 개로 부족해집니다. 저는 다음 신호가 보이면 항목을 늘립니다.

• 내가 아닌 사람이 이틀 연속 사용했을 때: 이 시점부터 재방문이라는 개념이 성립합니다. 방문자 식별과 재방문 여부를 추가합니다.

• 주간 활성 사용자가 두 자리가 됐을 때: 비율 지표가 의미를 갖기 시작합니다. 가입 전환율과 기능별 사용률을 넣습니다.

• 기능이 세 개를 넘겼을 때: 어떤 기능이 쓰이고 어떤 기능이 방치되는지 봐야 정리를 할 수 있습니다. 기능별 사용 건수를 추가합니다.

• 돈이 오가기 시작했을 때: 결제 성공과 실패, 환불은 다른 어떤 지표보다 먼저 봅니다. 이때부터는 대시보드의 성격 자체가 달라집니다.

반대로 사용자 수가 늘었다는 이유만으로 지표를 늘리지는 않습니다. 새 지표를 넣을 때는 그것을 보고 무엇을 결정할지 한 줄로 적어보고, 적히지 않으면 넣지 않습니다. 이 규칙 하나로 대시보드가 잡동사니가 되는 것을 꽤 막았습니다.

마치며

사용자 0명 구간에서 볼 것은 생존 여부, 오류 위치, 첫 화면 이탈 지점, 가입 시도와 실패, 내 사용 횟수 다섯 가지입니다. 위젯으로는 여덟 개면 충분하고, 늘릴 때는 정해진 신호를 기다립니다.

오늘 할 수 있는 한 가지는 이겁니다. 지금 관리자 화면에 있는 숫자들을 하나씩 보면서 "이 값이 두 배가 되면 내가 무엇을 다르게 하는가"를 물어보는 것입니다. 답이 없는 칸은 지워도 됩니다. 지운 자리에 상태 신호등을 넣으면 그날부터 화면이 쓸모 있어집니다.