프롬프트가 작성되기 전, 이미 프로젝트 성패의 80%는 결정된다고 생각합니다.
바이브 코딩의 한계는 상상력의 한계라는 말을 자주 듣게 됩니다. 그만큼 저희는 끊임없이 기능 추가의 유혹을 받게 됩니다. 하지만 대부분의 서비스는 기능이 부족해서 실패하지 않습니다. 문제 정의가 틀렸거나, 킬러 기능 하나가 충분히 강력하지 못했거나 이 둘 중 하나인 경우가 훨씬 많습니다.
Trachemy의 교훈: 지표와의 싸움
제가 공동창업가 매칭 플랫폼 Trachemy를 런칭했을 때의 이야기입니다. Trachemy의 본질은 단순했습니다. “창업자가 만들고 싶은 아이디어를 공유할 수 있는 피치덱으로 만들어 공동창업자를 찾게 하자.”
Impressions
1M
Web Views
30K
Onboarding
250
Decks
35
런칭 한 달 만에 얻은 수치들입니다. 여기서 마지막 지표인 피치덱 생성 수는 활성 사용자와 가장 밀접하게 연결된 지표였습니다. 그래서 고민이 시작됐습니다. “활성 사용자를 늘리려면 어떤 기능을 더 만들어야 하지?” 그리고 머릿속에 익숙한 유혹이 떠올랐습니다. “AI를 붙여볼까?”
기능 확장의 함정
학습 목적 반, 사용자 테스트 반으로 대대적인 기능 확장을 시작했습니다. 아이디어를 공개하고 싶지 않은 사람, 아이디어는 없지만 공동창업자를 찾고 싶은 사람들을 위한 기능이라는 억지 가설을 세웠습니다.
결과는 어땠을까요?
들인 공에 비해 전환율은 거의 오르지 않았습니다. 지금 돌아보면 이유는 너무 명확합니다. Trachemy의 진짜 고객은 아이디어를 숨기고 싶은 사람이 아니라, 오히려 주변에 적극적으로 알리고 그 아이디어에 가슴이 뛰는 '절박한 창업자'였기 때문입니다.
무엇을 만들지 않을 것인가
바이브 코딩 덕분에 기술적 구현은 빠르고 쉬워졌습니다. 하지만 가장 중요한 자원은 여전히 변하지 않았습니다: 창업가의 시간.
특히 Solopreneur라면 “어디까지 만들 것인가”는 “무엇을 만들지 않을 것인가”에 대한 결정이기도 합니다. 기능을 더 만들기 전에, 그 기능이 누구를 위한 것인지 그리고 문제 정의의 본질을 흐리지 않는지 한 번 더 멈춰서 생각해볼 필요가 있습니다.