많은 소프트웨어 창업가가 단순한 이유로 실패합니다. 출시가 너무 늦기 때문입니다. 아무도 없는 진공 상태에서 몇 년 동안 제품을 개발하다가, 실제 고객이 처음 손을 대는 순간 무너지는 모습을 지켜보기만 합니다.

Indie Hackers 팟캐스트에서는 이런 이야기를 자주 다룹니다. 이 쇼의 공식 미션은 청취자가 스타트업 창업자들의 실수로부터 배우도록 돕는 것이지만, 진행자 Courtland Allen은 이것이 과연 가능한 일인지에 대해 자주 실존적인 고민을 토로합니다.

…사람들에게 같은 말을 입이 닳도록 해도, 결국 직접 나가서 실수를 하며 고생해 보기 전까지는 절대 귀담아듣지 않거나, 당신이 하는 말의 진짜 의미를 이해하지 못하는 것들이 있습니다.

-Courtland Allen, Indie Hackers Podcast

저는 늘 이렇게 생각했습니다. “아니야, Courtland. 그건 비효율적이잖아. 난 공짜 교훈은 챙기고, 비싼 실수는 하지 않을래, 고마워.”

이 글의 제목에서 짐작하셨겠지만, 제 계획은 통하지 않았습니다.

제품 아이디어

아이디어는 제가 여태껏 본 것 중 가장 엉망인 코드를 뚫어져라 바라보던 중에 떠올랐습니다. 작년에 만든 레시피 검색 도구에 있던 코드였습니다. 그 앱은 크게 성공하지는 못했지만 가끔 손보는 재미는 있었습니다. 코드베이스에서 늘 저를 괴롭히던 부분이 하나 있었는데, 바로 재료 파싱이었습니다.

"2 cups finely chopped red onions" 같은 문자열이 주어지면, 앱은 그중에서 2는 수량, cups는 단위 등으로 파악해야 했습니다.

파싱은 처음에는 단순했지만 새로운 예외 상황이 생길 때마다 점점 더 취약하고 복잡해졌습니다. 시간이 지나면서 로직은 정규식이라는 악몽 같은 미로로 전락했습니다. 정규식은 텍스트를 처리하는 강력하지만 악명 높게 읽기 어려운 명령어입니다.

전부를 갈아엎고 머신러닝 솔루션으로 교체하고 싶은 유혹이 들었지만, 그건 엄청난 작업이 될 것이 분명했습니다. 수익도 내지 못하는 웹사이트의 사소한 기능 하나에 몇 달의 개발 시간을 쏟을 수는 없는 노릇이었습니다.

그때 문득 이런 생각이 들었습니다. 만약 재료 파싱 자체가 사업이 되면 어떨까? 이게 저에게 문제였다면 분명 다른 개발자들도 같은 어려움을 겪고 있을 것이다. 그중에는 돈을 버는 사람도 있을 테고, 내가 그들의 문제를 해결해 준다면 기꺼이 돈을 내지 않을까? 그렇게 Zestful이라는 재료 파싱 서비스 아이디어가 탄생했습니다.

MVP가 아니었던 MVP

린 스타트업 업계에서는 흔히 “MVP”, 즉 최소 기능 제품에 대해 이야기합니다. MVP는 아이디어의 가장 단순한 버전입니다. 최대한 빨리 만들어 잠재 고객의 손에 쥐여 주고, 그들의 반응을 보고 실제 문제를 해결하는지 판단하라는 것이 정석입니다.

가장 흔한 실패담 중 하나는 자신의 아이디어를 너무 확신한 나머지 MVP를 만들지 않는 창업가에 관한 것입니다. 대신 아무도 원하지 않는 완전한 제품을 만드는 데 몇 달, 몇 년을 투자하는 것이죠.

저는 Zestful에서 MVP를 만들긴 했습니다. 끝없는 수정과 개선의 늪에 빠지지 않기 위해 사전에 출시 기준까지 명확히 정의해 두었습니다.

약 120시간의 개발 끝에 작동하는 프로토타입이 출시 기준을 충족했습니다.

하지만 저는 정식으로 출시하지 않고 두 달을 더 보내며 코드를 계속 작성했습니다.

괜찮다, 이건 세일즈를 위한 코딩이니까

MVP가 “완성”된 뒤에도 왜 그렇게 오랫동안 제자리걸음을 했는지 궁금하실 겁니다. 그 두 달 동안 제 머릿속을 스쳐 간 생각들을 요약하면 이렇습니다.

1일차: 출시 기준 달성

서비스는 작동한다! 하지만 고객은 커맨드라인에서 복잡한 명령어를 입력해야만 사용할 수 있다.

Web 3.1 시대에 고객들에게 curl 명령어를 입력하는 수고를 끼치다니? 간단한 HTML 프론트엔드만 추가하면 고객이 브라우저에서 바로 서비스를 테스트할 수 있을 텐데.

5일 후

기본 프론트엔드는 작동하지만, 설명 하나 없이 덩그러니 놓인 HTML 폼만 있는 건 좀 이상하다.

폼 주변에 웹사이트를 만들어야겠다. 뭐 아주 간단한 사이트니까 하루면 되겠지.

4일 후

좋아, 이제 서비스에 웹사이트가 생겼다.

…그런데 사이트에 각 필드를 설명하는 문서 페이지가 없네. 오늘 오후에 끝내 버리자.

2일 후

이제 페이지가 너무 많아서 모바일에서는 내비게이션 바가 넘쳐 버린다.

내비게이션 바를 반응형으로 만들어야겠다. 내가 쓰는 웹 프레임워크인 Angular면 한 시간이면 되겠지.

8일 후…

마치 히드라 같았다. “마지막으로 하나만 더” 추가할 때마다 그로 인해 필요한 일이 두 가지씩 더 생겨났다. 코드 완성을 선언한 지 두 달이 지났는데도 아무것도 출시하지 못했다는 사실에 스스로도 어리둥절했다.

중요하긴 하지만 당장은 아니다

출시해야만 했습니다. 하지만 여전히 중요한 작업 목록은 끝나지 않았습니다. 남은 작업을 마치려면 5일은 더 걸릴 것 같았습니다.

그때 재미있는 일이 일어났습니다. 최대한 빨리 출시하겠다고 마음먹자 “꼭 필요한 것”과 “출시에 꼭 필요한 것”은 다르다는 사실을 깨달았습니다.

한 예가 이용 약관이었습니다. 출시할 때는 없이 시작했다가 며칠 뒤에 작성하면 어떻게 될까? 최악의 경우 법적 분쟁이 생겼을 때 불리한 입장에 놓이겠지만, 출시 며칠 만에 누가 나를 고소할 확률이 얼마나 될까?

입 다물고 출시하기

작업 목록의 각 항목마다 스스로에게 물었습니다. “이거 없이 출시하면 어떻게 되지?” 이용 약관에 대해 가졌던 것과 같은 냉정한 의심으로 모든 작업을 따져 보니, 진짜 출시 체크리스트가 드러났습니다. 24시간도 채 지나지 않아 저는 Zestful을 RapidAPI에 게시했습니다. API 마켓플레이스인 RapidAPI였습니다. 마침내 서비스가 라이브된 것입니다!

이제 진짜 승부의 순간이었습니다. 서비스는 실제 고객에게서 결제를 받을 준비를 마쳤습니다. 이제 그들이 돈을 내도록 설득하기만 하면 됐습니다.

나는 거절당하는 게 두려워 출시를 미룬 걸까?

“완성”과 “출시” 사이 두 달간의 공백 기간 동안 한 친구가 내가 고객에게 제품을 보여주는 걸 두려워하는 것 아니냐고 물었습니다. 출시를 미루게 만든 모든 작업이 사실은 거절을 피하기 위한 변명은 아니냐는 것이었습니다.

나도 그런 생각을 해 본 적은 있지만, 곧바로 일축했습니다. 예전에 영업 일을 하며 하루에 40번씩 고객에게 전화를 걸어 “아니오”라는 말을 듣던 사람이었다. 거절 따위는 두렵지 않았습니다.

출시 당일, 나는 첫 번째 콜드 피치를 쓰려고 앉았습니다. 나를 전혀 모르는 레시피 앱 개발자에게 이메일을 보내 내 재료 서비스를 그들의 앱에 연동해야 하는 이유를 설명해야 했습니다.

30분 동안 빈 화면만 바라보며 한 글자도 쓰지 못했습니다. 친구들에게는 수십 번이나 서비스를 설명해 봤지만 이번은 달랐습니다. 판매 포인트가 떠오를 때마다 고객의 매서운 반박이 머릿속에 그려졌습니다.

왜 그게 당신이 부르는 가격만큼의 가치가 있죠?

그게 어떻게 제 수익을 늘려 주죠?

왜 당신 서비스가 꼭 필요하죠?

맙소사. 나는 정말 거절이 두려웠던 것이다.

다른 종류의 거절

이건 예전에 하던 영업과는 전혀 달랐습니다. 그때는 기업에 광인터넷을 파는 일이었지만, 나는 광케이블을 깔거나 네트워크를 설계한 사람이 아니었습니다. 그래서 거절을 담담하게 받아들일 수 있었습니다.

하지만 지금은 내가 직접 만든 것을 팔고 있었습니다. 그것도 내가 작성한 소프트웨어였습니다. 소프트웨어를 작성하는 일은 내 정체성의 핵심입니다. 내가 가장 잘하고 가장 자부심을 느끼는 일이기도 합니다. 만약 고객에게 제품을 보여줬는데 고객이 “이거 별로네. 팔려고 한다는 건 좋다고 생각한다는 뜻이겠지. 그러니 너는 별로인 사람이네”라고 생각한다면 어떨까?

냉혹한 현실

수십 번의 피치와 몇 번의 대화를 나눈 뒤, 구매는 한 건도 없이 문득 깨달았습니다. 나는 고객이 원하지 않는 제품에 몇 달을 투자한 바로 그 개발자가 되어 있었습니다.

내 서비스를 쓸 수 있는 비즈니스는 분명 있었지만, 가장 필요로 하는 곳들은 이미 자체 솔루션을 만들어 쓰고 있었습니다. 나머지는 재미있는 서비스라는 데는 동의했지만 월 20달러라는 저렴한 비용에도 불구하고 비용을 정당화할 수 없다고 했습니다.

그리고 그 지점에서 나는 전략의 치명적인 결함을 발견했습니다. 고객에게 가장 큰 비용은 내가 청구하는 월 사용료가 아니라, 내 서비스를 연동하기 위해 자신들의 앱을 수정해야 하는 비용이었습니다.

게다가 외부 의존성이 하나 더 늘어난다는 부담도 따져봐야 했습니다. 내 서비스에 장애가 생기면 어떻게 되지? 그들의 앱도 멈추는 건가? 아니면 내 서비스가 실패했을 때를 대비해 아예 별도의 백업 운영 모드를 만들어야 하는 건가?

나는 순서를 거꾸로 했다

돌이켜 보면 내 과정은 거꾸로였습니다. 고객에게 콜드 피치를 보내는 것이 마지막 단계였지만, 사실은 코드를 한 줄 작성하기 전에 했어야 할 일이었습니다.

초기에 나는 제품을 먼저 만드는 결정을 합리화했습니다. 고객이 아이디어에는 “좋다”고 해도 막상 제품이 나오면 사지 않을 수도 있지 않은가. 나는 “좋다”는 말이 실제 구매, 즉 고객이 서비스를 결제하는 진짜 “예스”가 되기를 원했습니다.

그 논리는 지금도 어느 정도 타당하게 느껴지지만, 나는 “아니오”가 가진 가치를 간과했습니다. 고객이 컨셉 단계에서 제품을 거절한다면, 내가 제품을 만든 뒤에도 마음을 바꾸지 않을 것입니다. 모두가 “아니오”라고 한다면, 그건 아마 막다른 길이라는 뜻입니다.

Samantha Mason 편집. 일러스트: Loraine Yow.