많은 소프트웨어 창업가들이 단순한 이유로 실패한다. 출시가 너무 늦기 때문이다. 이들은 아무도 없는 진공 상태에서 몇 년을 제품 개발에만 매달리다, 실제 고객이 처음 제품을 만지는 순간 와르르 무너지는 모습을 보게 된다.

Indie Hackers 팟캐스트에는 이런 이야기가 가득하다. 이 팟캐스트가 내세우는 목표는 스타트업 창업자들의 실수로부터 청취자가 배우도록 돕는 것이지만, 진행자 코틀랜드 앨런은 그게 과연 가능한 일인지에 대해 자주 실존적인 고민을 털어놓는다:

…얼굴이 파랗게 질리도록 같은 얘기를 수없이 반복해줘도, 사람들은 직접 나가서 실수하며 힘겹게 깨닫기 전까지는 당신의 말을 듣지 않고, 당신이 하는 말을 제대로 이해하지 못합니다.

-코틀랜드 앨런, Indie Hackers Podcast

나는 늘 이렇게 생각했다. “아니에요, 코틀랜드. 그건 비효율적이잖아요. 전 공짜 교훈은 챙기고, 비싼 실수는 안 할래요.”

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

제품 아이디어

아이디어는 내가 여태껏 본 것 중 가장 흉한 코드를 멍하니 바라보고 있을 때 떠올랐다. 지난해 직접 만든 레시피 검색 도구에 있던 코드였다. 그 앱은 크게 성공하지 못했지만, 가끔 손보는 재미는 있었다. 코드베이스에서 늘 나를 괴롭히던 부분이 하나 있었다. 바로 재료 파싱이었다.

예컨대 "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시간도 채 지나지 않아 나는 RapidAPI라는 API 마켓플레이스에 Zestful을 공개했다. 내 서비스가 라이브된 것이다!

이제 진짜 승부의 순간이었다. 내 서비스는 실제 고객으로부터 결제를 받을 준비가 됐다. 이제 그들을 설득해 구매하게 하기만 하면 됐다.

출시를 미룬 게 거절이 두려워서였을까?

‘완성’과 ‘출시’ 사이의 두 달간 표류하던 시기에, 친구 한 명이 내가 고객에게 제품을 보여주기 두려운 것 아니냐고 물었다. 출시를 늦추는 이 모든 작업들이 사실은 거절을 피하려는 수단 아니냐는 것이었다.

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

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

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

그게 당신이 매긴 가격을 지불할 가치가 왜 있죠?

그게 제 수익을 어떻게 늘려주는데요?

제가 왜 당신이 필요한 거죠?

이런. 나는 거절이 두려웠던 것이다.

다른 종류의 거절

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

하지만 지금은 내가 만든 것을 팔고 있었다. 그것도 내가 만든 소프트웨어였다. 소프트웨어를 만드는 일은 내 정체성의 핵심이다. 내가 가장 잘하고 가장 자부심을 느끼는 일도 그것뿐이다. 고객에게 제품을 보여줬을 때 고객이 이렇게 생각할지도 모른다. “이거 별로네. 팔려고 한다는 건 좋다고 생각한다는 건데, 결국 너라는 사람도 별로라는 거네.”

냉혹한 현실

수십 번의 피치와 몇 번의 대화, 그리고 0건의 구매 끝에, 나는 깨달았다. 나는 고객이 원하지 않는 제품에 몇 달을 쏟아부은 바로 그 개발자가 되어 있었다.

내 서비스 같은 걸 쓸 수 있는 업체도 있긴 했지만, 가장 필요했던 업체들은 이미 자체적으로 만들어 쓰고 있었다. 나머지는 서비스가 멋지긴 하지만 비용을 정당화할 수 없다고 했다. 서비스 가격이 월 20달러에 불과했는데도 말이다.

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

게다가 그들은 외부 의존성이 하나 더 늘어나는 데 따른 비용도 따져봐야 했다. 내 서비스에 장애가 생기면 어떻게 되지? 앱이 멈추나? 아니면 내 서비스가 죽었을 때를 대비해 아예 별도의 우회 동작 모드를 만들어둬야 하나?

나는 거꾸로 했다

돌아보면, 내 과정은 거꾸로였다. 고객에게 콜드 피치를 보내는 건 마지막 단계였지만, 사실 코드 한 줄 쓰기 전에 했어야 했다.

초기에 나는 제품을 먼저 만들기로 한 결정을 합리화했다. 고객이 아이디어에는 “좋다”고 해도 실제로는 제품을 사지 않을 수 있다고 생각했다. 나는 고객이 실제로 돈을 내고 서비스를 구매하는 ‘진짜 예스’를 원했다.

그 논리 자체는 지금도 타당하게 느껴지지만, 나는 ‘아니오’의 가치를 간과했다. 고객이 컨셉 단계에서 제품을 거절한다면, 내가 제품을 만들고 난 뒤에 마음이 바뀔 리 없다. 만약 모두가 “아니오”라고 한다면, 그건 아마도 막다른 길이라는 뜻이다.

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