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

매달 카드 결제 알림이 옵니다. 서버비 몇만 원, 도메인 갱신비 몇만 원. 금액이 크지 않아서 그냥 넘깁니다. 그런데 그 서비스에 마지막으로 접속한 게 언제였는지는 기억나지 않습니다. 이런 상태로 2년을 끌어본 적이 있습니다.혼자 만든 서비스를 접는 일이 어려운 이유는 비용이 아니라 감정입니다. 밤을 새워 만든 기억이 있고, 처음 가입자가 생겼을 때의 기분이 남아 있습니다. 그래서 "언젠가 다시 손보면 되지"라는 말로 판단을 계속 미룹니다. 그 사이에 유지비는 계속 나가고, 무엇보다 다음 작업에 쓸 수 있었던 관심이 조금씩 새어 나갑니다.이 글은 접으라고 권하는 글이 아닙니다. 접을지 말지를 기분이 아니라 기준으로 정하자는 이야기입니다. 아래 여섯 가지를 확인하고, 그 결과에 따라 유지·전환·종료 중 하..

제 노트북 폴더에는 배포까지 갔다가 조용히 멈춘 프로젝트가 여러 개 있습니다. 도메인을 사고, 로고를 만들고, 결제 모듈까지 붙였던 것도 있습니다. 그중 실제로 돈을 받아본 것은 손에 꼽습니다. 저만 그런 것도 아닙니다. 주변 개발자들과 이야기해보면 대부분 비슷한 폴더를 하나씩 가지고 있습니다.국내 개발자를 대상으로 한 어떤 설문에서는 사이드 프로젝트로 실제 수익이 발생한 비율이 4% 정도로 나왔다고 합니다. 표본과 조사 방식에 따라 달라질 수 있는 숫자라 그대로 믿을 필요는 없습니다. 다만 체감과는 크게 어긋나지 않습니다. 시작한 사람이 100명이면 배포까지 가는 사람이 20명쯤이고, 그중 매출이 한 번이라도 찍히는 사람은 다시 그 일부입니다.이 글은 사이드 프로젝트를 말리려고 쓴 글이 아닙니다. 저도..