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

서비스를 만들다 보면 로그를 먼저 생각하게 됩니다. 문제가 생겼을 때 원인을 찾아야 하고, 어떤 요청에서 실패했는지 확인해야 하기 때문입니다. 저도 닷넷 프로젝트를 만들 때 Serilog 같은 구조화 로깅 도구를 자주 떠올립니다. 하지만 로그를 남기기 시작하면 곧 다른 질문이 생깁니다. 로그는 문제가 생긴 뒤에 뒤져보는 기록에 가깝습니다. 그렇다면 지금 서비스가 어떤 상태인지, 오늘 어떤 일이 있었는지, 사용자가 실제로 어떤 흐름을 지나고 있는지는 어디에서 봐야 할까요. 이 지점에서 작은 대시보드나 상태 확인 화면이 필요해집니다. 거창한 분석 시스템이 아니라, 운영자가 매일 한 번쯤 열어보고 서비스의 현재 상태를 감각할 수 있는 화면입니다. 혼자 운영하는 서비스일수록 이런 화면이 생각보다 중요합니다. 로..

작은 서비스를 만들 때 처음부터 관리자 화면을 신경 쓰는 일은 조금 과해 보일 수 있습니다. 사용자에게 보이는 기능도 아직 충분하지 않은데, 운영자만 보는 화면을 먼저 만든다는 것이 뒤로 미뤄도 되는 일처럼 느껴지기 때문입니다.저도 예전에는 비슷하게 생각했습니다. 우선 사용자가 보는 화면을 만들고, 데이터가 쌓이면 그때 관리자 기능을 붙이면 된다고 봤습니다. 하지만 혼자 서비스를 만들고 운영하는 시간이 길어질수록, 관리자 화면은 나중에 붙이는 부가 기능이 아니라 서비스를 오래 붙잡기 위한 기본 도구에 가깝다는 생각을 하게 됩니다.특히 메리톡톡처럼 창작자의 흐름을 돕는 서비스를 만들 때는 더 그렇습니다. 사용자가 어떤 지점에서 막히는지, 어떤 데이터가 쌓이고 있는지, 문제가 생겼을 때 어디를 먼저 봐야 하..