내가 만든 스타트업 MVP, 실패했던 진짜 이유
정부지원금으로 만든 서비스, 아무도 쓰지 않았다: 유저 0명의 현실
안녕하세요~~ :)
스타트업 현장에서 3년째 사업개발을 하고 있는 킵고잉걸입니다.
오늘은 조금 부끄러운 이야기를 해보려 해요.
제가 만든 서비스가 아무도 쓰지 않았던 그 시절의 이야기예요ㅎㅎ
그 시점엔 진짜 열정 하나로 버텼어요.
시장 조사도 끝냈고, 정부지원사업에도 선정됐고, 개발까지 완성했는데...
막상 오픈하고 나니 사용자는 단 한 명도 없었어요...ㅠㅠ
"왜 아무도 안 써요?"에서 시작된 자괴감
서비스를 오픈한 날, 친구들에게 링크를 보냈어요.
"드디어 완성됐어!! 한 번 써봐줘 :)"
하지만 며칠이 지나도 회원가입 수는 3명,
그마저도 팀원이었어요ㅠㅠ
처음엔 "홍보가 부족해서겠지"라고 생각했어요.
그래서 SNS 광고도 돌리고, 홍보 글도 쓰고, 커뮤니티에 올렸어요.
그런데 놀랍게도, 유입은 조금 생겼는데 정착은 0명이었어요.
그제서야 알겠더라고요...
이건 마케팅의 문제가 아니라, 서비스 자체의 문제구나.
우리가 착각했던 '필요'의 정체
돌이켜보면, 그 서비스는 '누군가 필요로 할 것 같은' 기능들의 집합체였어요.
진짜로 "필요한 사람"을 만나본 적이 없었어요.
사용자 인터뷰를 하지 않은 채,
"이 정도면 다들 편하겠지?"라는 팀 내부의 논리로만 기획했죠.
결국 우리는 문제 해결이 아닌 문제 추측만 하고 있었던 거죠.
이때 저는 사업개발자로서 처음으로 '검증'이라는 단어의 무게를 실감했어요.
시장 검증의 진짜 핵심은 '해석'에 있다
많은 초기 창업자들이 MVP를 만들고 나서 "사용자 수"를 지표로 봐요.
하지만 그건 검증이 아니라 측정에 불과해요.
검증은 숫자보다 '패턴'을 보는 일이에요.
예를 들어,
첫 방문 이후 재방문이 있었는가
사용자가 기능을 어떻게 이해했는가
이탈한 순간이 언제인가
이런 사용자 흐름의 이유를 해석하는 과정이 진짜 검증이에요.
그리고 이건 단순히 GA(구글 애널리틱스) 수치만으로는 절대 보이지 않아요.
MVP 실패 후 깨달은 구조의 문제
그 프로젝트가 망한 이유를 하나하나 뜯어보니,
우리 팀은 개발보다 의사결정의 타이밍에서 실패하고 있었어요.
우리는 사용자 피드백을 모으기 전에 MVP를 완성했고,
정작 데이터를 분석할 땐 수정할 여유도 자원도 없었어요.
MVP는 완성이 아닌 '테스트 도구'인데,
우린 그걸 작품처럼 만들고 생각해버렸던 거예요ㅠㅠ
그 후, 사용자 인터뷰를 시스템으로 바꿨다
다음 프로젝트부터는 완전히 다른 접근을 했어요.
개발 전에 '기획-인터뷰-검증'을 짧은 주기로 반복했어요!
예를 들어,
노션으로 간단한 와이어를 만든 뒤,
잠재 사용자 5명에게 보여주고,
기능 이해도와 사용 의도를 기록했어요.
이 과정을 두 번만 반복해도
"누가 왜 쓸지"가 명확해지더라고요.
이 단계가 생기니,
서비스 설계도 훨씬 명확해졌고,
실제 개발 비용도 줄었어요!ㅎㅎ
협업으로 배운 진짜 MVP 설계법
그 경험 이후, 외주개발을 진행할 때
저는 '속도보다 구조'를 먼저 보게 됐어요.
이때 함께 일했던 외주개발사는 똑똑한개발자였어요.
이 팀은 단순히 "무엇을 만들어드릴까요?"가 아니라,
"이 기능이 실제로 검증된 흐름인가요?"를 먼저 물었어요.
예를 들어, 한 번은
"관리자 페이지를 먼저 개발할까요?"라는 제 질문에
그쪽 PM이 이렇게 답했어요.
"유저가 실제로 쓸 시나리오가 완성된 후에,
그 데이터를 관리하는 기능을 만드는 게 더 효율적이에요."
그 말이 정말 와닿았어요.
'만드는 순서'가 검증 순서와 같아야 한다는 걸 그때 처음 배웠거든요.
똑똑한개발자는 MVP 단계의 프로젝트를 많이 다뤄봤기 때문에,
불필요한 기능이나 리소스를 줄이고
'실행 가능한 검증 구조'를 함께 설계해주는 게 강점이에요.
덕분에 이후 진행한 SaaS 프로젝트에서는
베타테스트 유저 50명 확보까지 불과 2주밖에 걸리지 않았어요! :)
시장은 '완성된 서비스'보다 '문제를 해결하는 팀'을 본다
스타트업을 하다 보면
"완성된 걸 보여줘야 인정받는다"는 생각에 사로잡히기 쉬워요.
하지만 진짜 시장은 완성도를 보는 게 아니라,
문제를 어떻게 풀고 있는가를 봅니다.
MVP는 그 과정을 증명하기 위한 임시 장치일 뿐이에요.
그걸 예쁘게, 완벽하게 만들 이유는 없어요.
이제는 이렇게 한다
지금은 새로운 아이디어가 생기면
개발보다 먼저 사람부터 만나봅니다.
"이런 서비스가 있으면 쓰시겠어요?"
"쓰신다면, 어떤 상황에서 쓸 것 같으세요?"
미리 이와 같은 질문들을 해보기만 해도,
리스크를 충분히 줄여낼 수 있어요!
그리고 이렇게 정리된 피드백을 기반으로
개발팀과 짧은 실험 중심의 구조를 짭니다.
이게 바로 제가 세 번째 프로젝트부터 실패하지 않은 이유입니다ㅎㅎ
실패 덕분에 얻은 현실 감각
처음 서비스를 만들던 시절엔
"내가 하고 싶은 걸 만드는 게 창업"이라고 믿었어요.
하지만 지금은
창업은 '누군가의 문제를 대신 해결해 주는 일'이라고 생각하게 됐어요!
누가 써주지 않았던 그 서비스 덕분에
저는 '사업개발자'로서 한 단계 단단해질 수 있었어요!
그리고 지금도 저는 여전히,
"다음엔 누가 진짜로 쓸까?"를 스스로에게 묻는 중이에요 :)
오늘은 조금은 개인적인 이야기를 해봤는데요!
제 이야기를 통해서 도움받으실 부분이 분명히 있을 거라고 생각해요~
오늘도 감사합니다!
공감과 댓글도 부탁드려요~ㅎㅎ
