혼자 만든 서비스를 운영하다 보면 새 기능을 만드는 일보다 이미 있는 기능을 설명하고 고치는 일이 더 많은 날이 옵니다. 저는 한동안 이 일을 모두 호의로 처리했습니다. 그러다 보니 사용자 한 명의 요청이 다음 주의 약속이 되고, 약속이 쌓일수록 정작 제품을 개선할 시간이 사라졌습니다.이번 글에서는 서비스를 접을지 말지의 문제가 아니라, 어떤 일만 남기고 어떤 요청은 계약 밖으로 둘지 정리한 과정을 적어보겠습니다. 금액을 정답처럼 제시하기보다 범위와 응답 기준을 먼저 세우는 방법에 집중합니다.유지보수와 신규 개발을 먼저 나눴습니다같은 코드베이스에서 나온 요청이라도 성격은 다릅니다. 오류를 원래 동작으로 되돌리는 일은 유지보수이고, 새로운 화면이나 업무 규칙을 추가하는 일은 신규 개발입니다. 둘을 같은 창..

사용자가 0명인 서비스의 7일 리텐션은 몇 퍼센트일까요. 계산이 되지 않습니다. 분모가 0이기 때문입니다. 그런데도 많은 개인 서비스의 관리자 화면 첫 줄에는 DAU와 리텐션 자리가 마련되어 있고, 거기에는 대개 0과 하이픈이 표시되어 있습니다.관리자 화면을 먼저 만들어두는 편이 낫다는 이야기와, 로그 다음에 필요한 것이 상태를 보는 화면이라는 이야기는 앞서 따로 쓴 적이 있습니다. 이 글은 그 다음 단계입니다. 그래서 그 화면에 정확히 무엇을 몇 개나 넣을 것인가를 목록으로 정리합니다.기준은 하나입니다. 그 숫자를 보고 내일 할 일이 바뀌는가. 바뀌지 않는 숫자는 아무리 그럴듯해도 초기에는 자리만 차지합니다. 사용자 0명 구간에서 그 조건을 만족하는 항목은 생각보다 적습니다.0명일 때 의미가 생기는 다..