제 노트북 폴더에는 배포까지 갔다가 조용히 멈춘 프로젝트가 여러 개 있습니다. 도메인을 사고, 로고를 만들고, 결제 모듈까지 붙였던 것도 있습니다. 그중 실제로 돈을 받아본 것은 손에 꼽습니다. 저만 그런 것도 아닙니다. 주변 개발자들과 이야기해보면 대부분 비슷한 폴더를 하나씩 가지고 있습니다.
국내 개발자를 대상으로 한 어떤 설문에서는 사이드 프로젝트로 실제 수익이 발생한 비율이 4% 정도로 나왔다고 합니다. 표본과 조사 방식에 따라 달라질 수 있는 숫자라 그대로 믿을 필요는 없습니다. 다만 체감과는 크게 어긋나지 않습니다. 시작한 사람이 100명이면 배포까지 가는 사람이 20명쯤이고, 그중 매출이 한 번이라도 찍히는 사람은 다시 그 일부입니다.
이 글은 사이드 프로젝트를 말리려고 쓴 글이 아닙니다. 저도 지금 메리톡톡이라는 창작 보조 서비스를 혼자 만들고 운영하고 있습니다. 다만 시작하기 전에 알았더라면 시간을 훨씬 아꼈을 것들이 있어서, 실패한 쪽의 공통 패턴과 시작 전에 확인할 기준을 정리해보려 합니다.
왜 대부분은 배포 직후에 멈추는가
수익이 나지 않는 프로젝트는 각자 다른 이유로 실패하는 것처럼 보이지만, 몇 년 지켜보면 패턴이 반복됩니다. 제가 직접 겪었거나 가까이서 본 것들만 추리면 다음과 같습니다.
- 수익 모델이 처음부터 없었습니다: "일단 만들고 사용자가 모이면 그때 생각하자"는 계획은 계획이 아닙니다. 사용자가 모이지 않으면 아무 일도 일어나지 않고, 모여도 결제 흐름을 나중에 붙이는 일은 생각보다 크고 지루한 작업입니다.
- 문제를 검증하지 않고 기능부터 만들었습니다: 개발자에게 가장 편한 일은 코드를 짜는 일입니다. 그래서 "이런 게 있으면 좋겠는데"라는 자기 짐작만으로 3개월을 씁니다. 정작 그 불편을 돈 내고 해결할 사람이 있는지는 배포 후에야 확인합니다.
- 배포가 끝인 줄 알았습니다: 배포는 시작점입니다. 그 뒤에 오는 것은 유입 만들기, 온보딩 다듬기, 이탈 원인 찾기 같은, 코딩보다 훨씬 지루한 일들입니다. 대부분은 여기서 흥미를 잃습니다.
- 기술 스택이 목적이 되었습니다: 새 프레임워크를 써보고 싶어서 시작한 프로젝트는 그 프레임워크를 익히는 순간 목적을 달성합니다. 학습으로는 성공이지만 서비스로는 그때 끝납니다.
- 혼자 쓰지도 않는 것을 만들었습니다: 만든 사람조차 매일 열지 않는 서비스를 남에게 매일 열게 만드는 것은 대단히 어렵습니다.
- 범위가 너무 컸습니다: 첫 버전에 회원 등급, 관리자 통계, 알림 센터까지 넣으려다 완성 자체를 못 합니다. 퇴근 후 하루 두 시간으로 감당할 수 있는 크기가 아니었던 겁니다.
여섯 가지 중 제가 가장 많이 반복한 것은 두 번째와 여섯 번째입니다. 웹소설을 쓰면서 "이런 도구가 있으면 편하겠다"고 생각한 것까지는 좋았는데, 그 편함이 저에게만 해당하는지 다른 사람에게도 해당하는지 확인하는 절차를 건너뛴 적이 많습니다.
수익이 나는 쪽은 무엇이 달랐나
해외 인디해커 중에는 하나의 큰 서비스가 아니라 작은 서비스를 여러 개 운영하면서 합산 수익으로 생활하는 사람들이 있습니다. 개별 서비스의 매출은 크지 않지만, 각각이 유지비가 적고 손이 덜 가도록 설계되어 있어서 개수를 늘릴 수 있는 구조입니다. 구체적인 매출 수치는 사람마다 편차가 크고 검증하기도 어려우니 그대로 옮기지는 않겠습니다. 다만 이런 사례에서 반복적으로 보이는 공통점은 있습니다.
- 문제가 좁고 선명합니다: "창작자를 위한 올인원 플랫폼"이 아니라 "특정 파일 형식을 특정 형식으로 바꿔주는 도구"처럼 한 문장으로 설명됩니다.
- 첫 버전이 부끄러울 만큼 작습니다: 2주 안에 배포할 수 있는 크기로 자르고, 반응을 본 뒤에 붙입니다.
- 돈 받는 지점이 처음부터 정해져 있습니다: 무료로 어디까지 주고 어디부터 받을지가 기획 단계에 들어 있습니다.
- 유지비가 매출보다 확실히 낮습니다: 서버비가 월 몇만 원을 넘기지 않도록 설계해서, 매출이 적어도 버틸 수 있게 만듭니다.
- 만드는 시간보다 알리는 시간을 더 씁니다: 개발자에게 가장 어려운 부분이 여기입니다.
시작 전에 확인할 다섯 가지 기준
다음 프로젝트를 시작하기 전에 저 자신에게 던지는 질문들입니다. 다섯 개 중 세 개 이상 "아니오"가 나오면 일단 멈추고 기획을 다시 봅니다.
| 확인 항목 | 통과 기준 |
|---|---|
| 내가 매일 쓸 것인가 | 지금 손으로 하고 있는 불편이 있고, 만들면 내가 먼저 쓴다 |
| 돈 낼 사람을 아는가 | 구체적인 사람 세 명의 얼굴이나 커뮤니티가 떠오른다 |
| 2주 안에 배포 가능한가 | 첫 버전 기능 목록이 다섯 줄을 넘지 않는다 |
| 월 유지비가 감당되는가 | 매출이 0원이어도 1년은 버틸 수 있는 비용이다 |
| 알릴 통로가 있는가 | 블로그, 커뮤니티, 지인 등 첫 사용자를 부를 곳이 있다 |
특히 두 번째 항목을 권합니다. 기능을 만들기 전에 그 불편을 겪는 사람 몇 명에게 직접 물어보는 데는 하루면 충분합니다. 그 하루를 아끼려다 석 달을 버리는 경우를 여러 번 봤습니다.
수익만이 성공 기준은 아니지만
사이드 프로젝트의 가치를 매출로만 재는 것은 좁은 시각입니다. 저도 메리톡톡을 만들면서 배운 것들이 회사 일에 그대로 도움이 되었습니다. 혼자 배포하고 운영해보면 로그를 어떻게 남겨야 하는지, 장애가 났을 때 무엇부터 봐야 하는지가 몸에 남습니다. 이건 회사에서 남이 만들어둔 인프라 위에서만 일하면 잘 안 생기는 감각입니다.
다만 목표가 수익이라면 처음부터 그렇게 설계해야 합니다. "만들다 보면 어떻게 되겠지"로 시작한 프로젝트가 나중에 수익 모델을 갖추는 경우는 거의 없습니다. 반대로 학습이 목적이라면 수익이 없다고 자책할 필요도 없습니다. 문제는 목적을 정하지 않은 채 시작해서, 나중에 아무 기준으로도 평가할 수 없게 되는 상황입니다.
마치며
정리하면 이렇습니다. 대부분의 사이드 프로젝트는 수익 모델 부재, 검증 없는 개발, 배포 후 방치, 과도한 범위 때문에 멈춥니다. 반대로 살아남는 쪽은 문제가 좁고, 첫 버전이 작고, 유지비가 낮고, 알리는 데 시간을 씁니다.
지금 당장 할 수 있는 한 가지를 고르라면, 만들려는 것을 한 문장으로 적어보고 그 불편을 겪는 사람 세 명에게 물어보는 일입니다. 코드는 그다음에 시작해도 늦지 않습니다. 오히려 그 한 문장이 안 써지면, 그건 아직 기획이 끝나지 않았다는 신호입니다.