사이드 프로젝트 세 번 실패하고
얻은 진짜 교훈들
런칭도 못 해본 것부터 쓸쓸하게 접은 것까지, 모두 고백합니다
솔직히 말하면 나는 사이드 프로젝트를 꽤 좋아하는 편이다. 퇴근하고 노트북 앞에 앉아서 "이거 만들면 대박 나겠는데?"라는 생각으로 시작하는 그 설레는 감각. 개발자라면 한 번쯤은 경험해봤을 것이다.
문제는, 나는 그 설렘이 식기 전에 프로젝트를 완성한 적이 거의 없었다는 거다. 지금까지 제대로 기억나는 실패만 세 번. 오늘은 그 세 번의 이야기를 털어놓으려 한다. 부끄럽지만, 아마 이 글을 읽는 누군가는 "나도 똑같았는데..."라고 고개를 끄덕일 것 같다.
첫 번째 실패 — 아무도 원하지 않는 걸 만들었다
GitHub 이슈도 있고 Jira도 있는데, 왜인지 "개발자한테 딱 맞는 태스크 앱이 없다"고 생각했다. 완전한 착각이었다.
그때 나는 Next.js로 풀스택 앱을 만들기로 했다. 프론트는 내가 매일 쓰는 스택이니 자신 있었다. 문제는 기능을 계속 추가하다가 끝이 없어졌다는 거다. 마크다운 에디터, 포모도로 타이머, 깃허브 연동, 태그 필터링... 어느 순간 MVP가 아니라 올인원 앱을 만들고 있었다.
4개월째 되던 날, 지인 개발자 몇 명에게 베타 테스트를 부탁했다. 피드백은 충격적이었다. "그냥 노션 쓰면 되지 않나요?" 그 한 마디가 프로젝트를 끝냈다. 아무도 원하지 않는 걸 혼자 4개월 동안 만들고 있었던 거다.
만들기 전에 먼저 물어봐야 한다. "이런 게 있으면 쓸 것 같아?"라는 질문 하나가 4개월을 아껴준다.
두 번째 실패 — 혼자 다 하려다 번아웃
Spotify API를 활용한 서비스였다. 기술적으론 재밌었는데, 마케팅도 디자인도 혼자 하려다 결국 무너졌다.
두 번째 프로젝트는 나름 교훈을 반영했다. 먼저 지인들한테 "이런 서비스 쓸 것 같아?"라고 물었고 반응도 괜찮았다. Spotify API는 생각보다 재미있었고, Next.js + TypeScript + Prisma로 착착 쌓아가는 맛도 있었다.
근데 문제는 다른 곳에 있었다. 프론트, 백엔드, DB 설계, UI 디자인, SNS 홍보, 심지어 썸네일 제작까지. 전부 나 혼자였다. 퇴근 후 2~3시간씩 매달렸는데 5개월쯤 되니까 몸이 거부반응을 일으켰다. 회사 일도 버겁고, 주말에도 노트북 앞에 앉아있으니 번아웃이 왔다.
결국 소프트 런칭은 했다. 근데 사용자가 30명 수준에서 멈췄고, 유지보수할 에너지가 없어서 그냥 도메인 갱신을 안 했다. 서비스는 그렇게 증발했다.
사이드 프로젝트의 무덤은 번아웃이다. "내가 다 할 수 있어"는 착각이고, 지속 가능한 페이스 설계가 없으면 어떤 프로젝트도 오래 못 간다.
잘 못하는 부분은 과감하게 포기하거나 도움을 구해야 한다. 디자이너 친구, 마케터 지인, 아니면 그냥 노션 템플릿. 혼자 다 하는 건 로망이지, 현실이 아니다.
세 번째 실패 — 만들었는데 아무도 몰랐다
채용공고 데이터를 크롤링해서 기술 스택 트렌드를 시각화하는 대시보드. 만든 건 꽤 쓸만했는데 아무도 몰랐다.
세 번째는 자신 있었다. 이번엔 진짜 사람들이 원할 만한 걸 만들었다고 생각했다. 주니어 개발자들이 취업 준비할 때 "요즘 뭘 배워야 해?"라는 질문을 자주 하잖아. 채용공고 수백 개를 파싱해서 리액트, 뷰, 스프링 같은 기술들의 언급 빈도를 시각화하는 대시보드였다.
기술적으로는 꽤 공들였다. Vercel에 배포하고, 오픈그래프도 설정하고, 심지어 구글 서치 콘솔도 등록했다. 그런데 런칭하고 2주가 지났는데도 Google Analytics 대시보드는 조용했다. DAU가 문자 그대로 0이었다.
뭐가 문제였을까. 나는 코드는 짰는데 마케팅은 안 했다. 트위터(현 X)에 글 하나 올리고 끝이었다. 에브리타임, 오픈카톡방, 개발자 커뮤니티, 디스콰이엇... 이런 채널들을 전혀 활용하지 않았다. 좋은 제품도 아무도 모르면 존재하지 않는 것과 같다는 걸 그때서야 뼈저리게 느꼈다.
배포가 끝이 아니다. 배포는 시작이다. 런칭 계획에 마케팅 채널 최소 5개 이상을 반드시 포함시켜야 한다.
세 번의 실패에서 건진 5가지 교훈
실패마다 배운 게 달랐고, 쌓이다 보니 이제는 나름의 원칙이 생겼다. 정리해보면 이렇다.
-
1고객 인터뷰를 먼저, 코드는 나중에 아이디어가 생기면 일단 주변 5명에게 물어본다. "이런 게 있으면 쓸 것 같아?"가 아니라 "지금 이 문제 때문에 불편한 점이 있어?"라고 물어야 진짜 수요를 알 수 있다. 프로블렘 핏 없이는 프로덕트 마켓 핏도 없다.
-
2MVP는 진짜 미니멀해야 한다 내가 생각하는 MVP와 진짜 MVP 사이엔 항상 기능이 10개 이상 끼어 있었다. "이것만 있으면 쓸 수 있어"가 아니라 "이것만 있어도 쓸 수 있어"의 수준으로 줄여야 한다. 런칭 전 기능 목록에서 반은 지워라.
-
3지속 가능한 루틴을 설계해야 한다 매일 3시간은 현실적으로 불가능하다. 대신 주 4회 1시간이 훨씬 오래 간다. 에너지 관리가 프로젝트 관리다. 번아웃 오면 모든 게 의미 없어진다.
-
4배포 전에 채널을 먼저 확보한다 런칭 전에 디스콰이엇 팔로워, 오픈카톡방, 개발자 커뮤니티 인맥을 미리 준비해두어야 한다. 빈 필드에 공을 차는 것과 관중 앞에서 차는 건 다르다. 누가 볼지 먼저 생각하자.
-
5실패를 빠르게 인정하고 다음으로 넘어간다 망했다고 느끼면 빨리 인정하는 게 낫다. 죽어가는 프로젝트에 붙잡혀 있으면 에너지만 소모된다. 실패는 포트폴리오이자 경험치다. 부끄러운 게 아니다.
그래서, 또 할 거냐고?
당연히 한다. 세 번 다 실패했지만, 그 과정에서 Next.js 풀스택을 실전으로 다졌고, Spotify API 연동도 해봤고, 데이터 크롤링 파이프라인도 구축해봤다. 회사에서 주어진 업무만 하면 절대 못 해볼 경험들이었다.
사이드 프로젝트의 성공 기준을 "수익 창출"에만 두면 너무 빨리 포기하게 된다. "이 경험이 나한테 얼마나 남았나"로 기준을 바꾸면, 실패도 꽤 수익률이 좋다. 지금 네 번째를 준비 중인데, 이번엔 앞의 실수를 안 반복할 자신이 조금은 있다.
혹시 사이드 프로젝트 경험이 있으신가요?
어떤 이유로 접었는지, 또는 어떻게 살아남았는지
댓글로 이야기 나눠요 👇