최근 폴 그레이엄의 트윗을 읽었다. 실패한 창업자라도 좋은 것을 만들었고 왜 실패했는지 이해하고 있다면 보통 존경받는다는 내용이었다.

2007년 두 형제와 함께 크라우드펀딩 스타트업 “microPledge”를 시작했을 때, 우리도 분명 좋은 것을 만들려고 했다. 어떤 프로젝트든 이용할 수 있는 크라우드펀딩 플랫폼이었는데, 특히 소프트웨어 프로젝트에 초점을 맞췄다.

그리고 우리가 왜 실패했는지는 안다고 생각한다. 첫 버전이 최소 기능 제품(MVP)이 되기는커녕 지나치게 복잡했고, 잠재 사용자들에게 테스트하거나 판매해보기도 전에 만들어 버렸다. 거기에 PayPal 관련 법적 문제가 결정타를 날렸다.

이 글에서는 우리 스타트업의 개요를 정리하고, 실수와 배운 점을 짚어보며, 기록을 위해 사건 타임라인도 남긴다. 왜 킥스타터는 성공하고 microPledge는 그렇지 못했는지도 살펴본다. 다만 microPledge가 확실히 해낸 한 가지는 우리의 커리어를 킥스타트한 것이었다.

microPledge의 개요와 탄생

2006년 1월, 형 버윈이 출근길에 microPledge 아이디어를 떠올렸다. 씨앗이 된 발상은 이런 것이었다. “이웃과 친구, 할머니까지 모두 20달러씩 모아 동네 놀이터를 만든다고 상상해보세요. 이런 새로운 시도를 가능하게 할 웹 도구만 있으면 돼요!”

얼마 지나지 않아 그는 나와 또 다른 형제 브라이언에게 연락해 함께 만들 생각이 있는지 물었다. 브라이언은 막 웹 디자인 회사를 차린 참이라 바로 합류했다. 나는 대학을 졸업한 지 2년쯤 됐을 때였고, 폴 그레이엄의 에세이를 읽으며 창업에 대한 관심이 커져 있던 터라 흔쾌히 참여했다. 마침 파이썬이라는 프로그래밍 언어도 한번 써보고 싶었다.

시기도 절묘했다. ‘크라우드펀딩’이라는 용어가 처음 사용된 것이 2006년 8월이었다. 우리는 2006년 6월부터 2007년 7월까지 약 12개월에 걸쳐 플랫폼을 만들었고, 크라우드펀딩이 막 대중적인 개념으로 떠오르던 2007년 8월에 서비스를 출시했다.

아래는 microPledge 초기 홈페이지 스크린샷이다(현재 읽기 전용 웹사이트에 보존되어 있다).

처음에는 소프트웨어 프로젝트 펀딩을 돕는 데 초점을 맞췄지만, 어떤 형태의 오프라인 프로젝트에도 활용할 수 있는 시스템을 만들고자 했다.

펀딩을 원하는 창작자는 쉽게 프로젝트를 만들 수 있었다. 프로젝트 시작 폼을 일부러 단 한 화면으로 단순하게 유지했다.

그 다음 창작자는 목표 금액을 설정하고 후원이 들어오기를 기다리면 됐다. 후원된 금액은 지급 시점까지 신탁 계좌로 옮겨 보관됐다.

결제 시스템으로는 PayPal을 사용했다. 당시 PayPal은 타인에게 돈을 지급할 수 있게 해주는 몇 안 되는 서비스 중 하나였다. 하지만 시작할 때 약관을 꼼꼼히 읽지 않았다. 요점만 말하면, PayPal은 신탁 형태로 돈을 보관하는 행위를 달가워하지 않는다. 자세한 이야기는 아래에서 하겠다.

엔젤 투자자로부터 소액의 투자를 받았다. 가족에게서 약 NZ$10,000, 지인에게서 약 NZ$60,000이었다. 당시 그 투자를 회사 지분의 3분의 1 정도로 평가했고, 창업자인 우리 세 형제는 나머지 3분의 2를 나눠 가졌다. 이 돈으로 세 명이 풀타임으로 개발하는 동안 최소한의 생활비를 충당할 수 있었다.

돌이켜보면 그 시절은 정말 즐거웠다. 형제들과 함께 우리만의 스타트업을 만들고, 파이썬과 SQL, 웹 개발을 배우던 시간이었다.

우리가 실패한 이유

microPledge가 완전히 실패한 것만은 아니었다. 사용자 약 1200명, 생성된 프로젝트 100개, 총 후원액 $25,000을 기록했다. 그중 소수가 목표 금액을 달성하기도 했다. 어느 정도 traction을 얻는 듯하다가 곧 표류했고, 자금이 바닥나 결국 문을 닫았다.

아래에서는 내가 생각하는 실패 원인을 하나씩 짚어본다. 지금 되돌아보면 쉽게 보이는 것들이지만, 2006년의 젊은 소프트웨어 괴짜 세 명에게는 전혀 분명하지 않았다.

아마 대부분은 ‘스타트업 101’류 글에서 ‘하지 말아야 할 일’ 목록으로 흔히 볼 수 있는 것들일 거다. 사후 판단이란 참 좋은 것이다.

지나치게 복잡한 진행 및 지급 시스템

microPledge가 뜨지 못한 이유 중 하나는 시스템 자체가 너무 복잡했다는 점이다. 우리는 마케팅이라고는 거의 모르는 엔지니어 세 명이었다는 걸 기억해 달라. 아주 단순한 ‘버전 1’을 만드는 대신, 우리는 루브 골드버그 기계 같은 것을 만들어 버렸다. 기술적으로는 훌륭했지만 이해하기 어려웠다.

우리는 점진적 지급 시스템을 설계했다. 프로젝트 창작자가 슬라이더를 끌어 (예를 들어) “30% 완료했습니다”라고 표시하고, 진행 상황을 보여주는 증거 — 사진이나 소스 코드 — 를 업로드하는 방식이었다. 후원자에게 알림이 가면 후원자도 슬라이더를 끌어 투표하고, 투표 기간이 끝나면 창작자는 30% × 총 후원액 × 평균 투표율에 해당하는 금액을 받게 됐다.

다음은 우리 프로젝트 페이지 중 하나의 스크린샷이다(이 프로젝트는 목표액을 달성했지만 실제로 개발되지는 않았다).

여러 페이지에 걸친 창작자 FAQ 분량에서 알 수 있듯 세부 사항이 엄청나게 많았다. 게다가 본격적인 프로젝트 견적 시스템도 있었다. 누구나 프로젝트 아이디어를 제안하면 개발자들이 견적을 내고, 가장 좋은 견적이 채택되는 구조였다.

오해는 말아 달라. microPledge는 복잡한 시스템 치고 UI는 괜찮았다. 세부 사항을 다듬는 데 정말 많은 시간을 썼다! “모금 온도계”와 진행 슬라이더는 명확하고 시각적이었고, 세부 정보는 툴팁 뒤에 단계적으로 보여줬으며, 창작자와 후원자 모두 투표 과정을 안내받을 수 있었다.

우리의 실수는 더 앞선 단계에 있었다. 아무도 필요로 하지 않는 정교한 시스템을 설계했다는 점이다. microPledge보다 2년 늦게 출시된 킥스타터는 단순한 “이 프로젝트 후원하기” 버튼 하나로 성공했다. 창작자는 목표를 달성하면 후원금을 전부 받고, 아니면 한 푼도 받지 못한다. 진행 단계도, 투표도, 지급 계산도 없다.

이 복잡한 시스템을 복잡함을 위해 만든 건 아니었다. 후원자가 창작자를 믿고 실제로 제품을 만들도록 하는 신뢰 문제를 해결하고 싶었다. 하지만 알고 보니 사람들은 꽤 잘 믿어주는 편이었고, 대부분의 경우 그 믿음은 통했다! 약속을 지키지 않은 킥스타터 창작자 사례는 비교적 드물고, 그때 후원자들이 불만을 터뜨리긴 한다. 하지만 애초에 위험을 감수하고 들어간 것이고, 고작 $20 후원하고 얼마나 화를 낼 수 있겠는가?

요컨대 microPledge는 최소 기능 제품으로는 너무 정교했고, 사용자가 진짜 원하던 것에 비해 너무 복잡했다. 후원자가 원하는 건 단순한 후원 버튼 하나였고, 창작자가 원하는 건 지급이었다.

과도하게 엔지니어링된 소프트웨어

완벽주의 성향의 소프트웨어 엔지니어 세 명을 한 방에 모아두면 과도한 엔지니어링은 필연이다.

예를 들어 우리는 기성품을 쓰거나 그냥 SQL을 쓰는 대신 자체 미니 ORM을 개발했다. 스타트업으로서 우리는 프레임워크 수준의 코드를 짜는 게 아니라 일을 끝내는 데 집중했어야 했다.

당시 설정이 까다로웠던 PostgreSQL의 WAL 로깅을 쓰겠다고 설정 파일을 만지느라 많은 시간을 쏟았다. 사용자에게 “실시간 백업을 제공합니다”라고 자랑스럽게 말하고 싶었기 때문이다. 사실 pg_dump로 하루에 한 번 백업을 저장하는 5줄짜리 스크립트를 짜면 될 일이었다.

나는 무작위 SHA-1 해시의 충돌을 감지하고 처리하는 코드를 구현하느라 몇 시간을 쓴 기억이 있다. 이건 사실상 수십억 년 안에는 일어날 수 없는 일인데, 그때는 암호학적 해시에 대한 글을 좀 읽어봤어야 했다.

그리고 이 모든 걸 유료 사용자도, 제대로 된 수익 전략도 없이 했다! 스타트업의 생사는 코드의 기술적 완성도가 아니라 수익 창출에 달려 있다는 사실이 아직 체감되지 않았던 것이다.

이런 ‘과도한 복잡성’ 문제를 두 가지 모두 완화해줄 수 있었던 건, 엔지니어 사고를 가진 형제를 한 명 더 두는 대신 예술적 감각이나 비즈니스 감각을 가진 사람을 팀에 들이는 것이었을 테다.

완성된 제품이 아닌 메커니즘 강조

위에 보인 우리 프로젝트 페이지를 보면, 가장 눈에 띄는 부분은 후원자가 받게 될 제품이 아니라 후원과 진행 상황이다. 프로젝트 자체를 홍보하는 문단은 작게 한 단락뿐이다.

킥스타터 프로젝트 페이지와 비교해보자. 킥스타터는 제작 중인 제품을 홍보하는 큰 영상으로 시작해, 보통 고화질 사진과 함께 제품에 대한 긴 설명이 이어진다. 다음은 킥스타터 프로젝트 페이지 상단 모습이다.

킥스타터는 창작자가 (잠재적인) 제품을 정말 돋보이게 만들도록 돕는다. 우리 프로젝트 페이지는 그렇지 못했다. 게다가 킥스타터는 훌륭한 프로젝트 페이지를 만드는 방법을 단계별로 안내한다. 사실상 이 미니 스타트업들의 창업자가 자신의 고객에게 파는 법을 훈련시키는 셈이다.

우리가 이런 실수를 한 건 돈 내는 고객, 즉 후원자(영업 용어로는 구매자)가 아니라 창작자의 관점에서 생각했기 때문이라고 본다. 같은 맥락에서 “Kickstarter”라는 이름은 “microPledge”보다 조금 더 낫다. 후원을 뜻하는 input이 아니라 제품이라는 output을 강조하기 때문이다.

잘못된 초점 선택

microPledge가 오프라인 프로젝트도 지원하긴 했지만, 홍보 활동의 대부분은 소프트웨어 프로젝트, 특히 오픈소스 소프트웨어 펀딩 수단에 맞춰져 있었다.

우리가 잘 아는 분야였고 소프트웨어 배포가 쉬워서 그리 시작한 것이었다. 하지만 돌이켜보면 거의 확실히 잘못된 선택이었다. 오픈소스에도 돈은 있지만, 보통 크라우드펀딩이 아니라 기업 지원이나 확장 기능에서 나온다.

킥스타터 같은 다른 후원 사이트들은 실제 물리적인 프로젝트에 집중하는 경향이 있다. 일반 사람들에게 소프트웨어보다 하드웨어 기기나 새로운 형태의 신발에 돈을 보태게 하는 것이 훨씬 쉽다.

사용자가 진짜 필요로 하는 것을 파악하지 못함

또 다른 큰 실패 원인은 시장 반응을 살피지 않고, 실제 사용자가 진짜로 원하는 것이 무엇인지 테스트해보지 않은 채 시스템을 만들었다는 점이다.

물론 홍보를 아예 안 한 건 아니었고, 주로 도움이 될 것 같다고 생각한 소프트웨어 프로젝트 창작자들에게 알렸다. 예를 들어 microPledge 서빙에 사용한 Apache용 mod_wsgi 확장의 관리자 그레이엄 덤플턴과 꽤 교류했다. 그를 설득해 microPledge에서 기부 전용 프로젝트를 진행하게 했고, 그 과정에서 귀중한 피드백을 받았다.

그리고 2007년 9월에는 뉴질랜드 신문인 Dominion Post에 잠깐 소개되기도 했다(해당 기사는 자매 뉴스 사이트인 Stuff.co.nz에도 게재됐다).

그렇다 해도 우리는 12개월을 개발에 쏟기 전에, 훨씬 이른 단계부터 잠재적 프로젝트 창작자와 실제 후원자들에게 영업을 했어야 했다. 그 피드백을 바탕으로 제품을 자주 개선했어야 했다. 그러지 못한 가장 큰 이유는 아마도 우리에게는 코딩이 재미있었고, 전화기를 드는 일은 그렇지 않았기 때문일 것이다.

PayPal 법적 문제

출시 몇 달 만에 이미 상황이 썩 좋지 않다는 걸 알 수 있었다. 하지만 관에 마지막 못을 박은 건 출시 1년 뒤 PayPal과의 법적 분쟁이었다.

microPledge의 자금 흐름은 이랬다. PayPal로 후원을 받은 뒤 그 돈을 신탁 계좌로 옮기고, 프로젝트가 진행됨에 따라 창작자에게 지급했다.

발목을 잡은 건 바로 “신탁으로 돈을 보관”하는 부분이었다. 이건 정말 우리 잘못이었다. PayPal의 서비스 약관을 꼼꼼히 읽지 않았고, 신탁 보유는 그들이 금지한 행위 중 하나였다.

PayPal이 이를 알게 된 건 신용카드 사기꾼이 우리 사이트를 통해 자금 세탁을 시도하면서였다. PayPal이 이를 적발했고, 그 과정에서 우리를 감사하다가 신탁 보유 사실을 알게 됐다.

우리는 선의였고 당연히 약속대로 지급했지만, PayPal이라는 이름에 ‘친구(pal)’는 별로 없다는 걸 알게 됐다. 신탁 보유 사실을 알게 되자마자 그들은 즉시 우리 계정을 동결했고, 지원 센터에 여러 번 전화해 사정을 설명해도 6개월 동안 돈을 묶어뒀다.

우리는 좌절했고 사용자들도 당연히 화가 났다. 여러 대안을 고민하고 다른 결제 업체도 알아봤지만, 어차피 microPledge는 기대했던 traction을 얻지 못한 상태였기에, 6개월간의 동결은 사실상 사망 선고나 다름없었다.

회사 IP 매각 시도

결국 백기를 든 뒤 방향을 바꿔 microPledge 후원 시스템을 관심 있는 곳에 팔아보려 했다. 하지만 지적 재산은 가치가 별로 없다는 걸 알게 됐다. 관심을 보이는 곳은 몇 군데 있었지만 구매자는 나타나지 않았다.

그것도 사실상 헐값에 내놓은 것이었다. 그저 비용을 조금이라도 회수하려는 시도였다. 우리의 “Prospectus”에서 인용하자면, 잠재 구매자는 다음 중 하나를 구매할 수 있었다.

1. 전체 웹 소프트웨어에 대한 라이선스, 가격 US$7,500. 소스 코드에 대한 완전한 권리와 수정 권한 포함.
2. 상기 내용 모두에 더해 플랫폼에 대한 완전한 소유권(독점권, 재판매 권리 등 포함). 가격은 협의 — US$35,000 이상 제안.

Flippa.com에서 회사 자체를 팔아보기도 했다. 역시 별 진전이 없었다. 결국 모든 매각 시도는 흐지부지됐고, 몇 년 뒤 micropledge.com 도메인을 만료시키는 것으로 마무리됐다.

우리가 배운 것

실패는 좋은 스승이고, 우리는 그 몇 년 동안 많은 것을 배웠다.

비즈니스

스타트업 측면에서 우리가 배운 것은 위의 “우리가 실패한 이유” 목록을 뒤집은 것과 다름없다.

• 죽을 만큼 단순한 버전 1부터 시작하라(KISS 원칙).
• (돈 내는) 고객이 원하는 결과물을 강조하라.
• 돈이 되는 시장에 집중하라. 오픈소스는 아닐지도 모른다.
• 먼저 팔아라 — 코드를 한 줄도 쓰기 전에.
• 결제 시스템 약관을 꼼꼼히 읽어라. :-)

이 모든 과정을 통해 귀중한 비즈니스 경험도 얻었다. 형 브라이언이 microPledge의 모회사인 Brush Technology를 설립했는데, microPledge 실패 후 몇 년 동안 버윈과 내가 함께 운영을 도왔고, 지금도 소프트웨어·전자 컨설팅 회사로 운영되고 있다.

microPledge 몇 년 뒤 우리는 또 다른 스타트업인 Hivemind를 시작했다. 벌통을 위한 전자 모니터링·보고 시스템이라는 실체 있는 제품을 만들었다. 양봉가에게 파는 일은 어려웠지만, 이 스타트업은 훨씬 잘 풀렸고 앞서 배운 교훈 여러 가지를 실제로 적용했다.

기술

소프트웨어 공학을 정식으로 배운 적 없는 프로그래머로서, 스타트업 경험에서 얼마나 많이 배웠는지는 한참 뒤에야 깨달은 것 같다.

기술적으로는 웹 개발(HTTP, HTML 폼, 그리고 위험할 정도로 쓸 줄 알게 된 CSS와 JavaScript)을 배웠다. 파이썬 개발과 관계형 데이터베이스, SQL(특히 PostgreSQL)도 익혔다. 시작할 당시에는 브라이언이 이 분야에서 가장 많이 알고 있었겠지만, 우리 모두 많이 배웠다고 생각한다.

웹 프레임워크에 대해서도 배웠다. Django를 검토했지만 결국 web.py라는, 에런 스워츠가 만든 마이크로 프레임워크를 선택했다. 아직도 활발히 유지보수되고 있어 놀랍다. 나는 지금도 웹 도구는 작고 가벼운 것을 선호한다. 프레임워크보다 라이브러리에 가까운 쪽이 좋다.

또 하나 배운 건 내가 “diff 테스트”라고 부르는 것이다. 버윈의 아이디어였지만 그만의 독창적인 것은 아닐 거다. “스냅샷 테스트”나 “골든 파일 테스트”라고도 불리는 걸로 안다. 기본 아이디어는 테스트의 예상 출력을 파일로 저장해 소스 관리에 커밋해 두는 것이다. 그 다음 테스트 대상 코드를 실행해 출력을 새 파일에 쓰고, 테스트는 그 파일을 스냅샷과 diff하는 것으로 끝난다. 이후 많은 프로젝트에서 이 기법을 써왔는데, 특히 데이터 변환 작업에 아주 좋다.

하지만 아마 가장 중요하게 배운 건 팀워크였다. 팀으로 소프트웨어를 만드는 법, 일을 나누고 체계화하는 법, 좋은 도구를 쓰는 것의 중요성 같은 것들이다. microPledge는 내가 팀 단위로 개발하고 리비전 컨트롤을 써본 첫 경험이었다. 이런 멘토링의 대부분은 중견 소프트웨어 회사에서 몇 년간 일한 큰형 버윈에게서 왔다.

결론

내가 얻은 가장 큰 교훈은 실패로부터의 배움 그 자체가 이후 커리어에 매우 값졌다는 점이다. 특히 내 커리어에는 파이썬으로 웹 앱을 개발한 기술적 경험과 (작은) 팀에서 소프트웨어를 만드는 법을 배운 것이 큰 도움이 됐다.

지금 우리가 아는 걸 알고 microPledge를 만들었다면 성공했을까? 나는 성공 확률이 꽤 높았을 거라고 생각한다. 훨씬 단순한 시스템을 만들고, 제대로 된 사람들에게 홍보했을 테니까.

다만 여전히 갖지 못했을 한 가지가 있다. 실리콘밸리에서의 존재감이다. 폴 그레이엄 일행이 Y Combinator를 보스턴에서 실리콘밸리로 옮긴 데는 이유가 있다. 뉴질랜드 같은 작은 나라에서는 이런 스타트업을 위한 자금 조달이 훨씬 어렵다. 그래도 지역적인, 더 작은 규모의 성공은 거둘 수 있었을 거라고 생각한다.

킥스타터는 — 박수를 보내고 싶다 — 단순하고 명확했고, 자금 메커니즘이 아니라 창작자가 팔려는 제품에 시스템의 초점을 맞춤으로써 성공했다.

다시 스타트업을 할 것이냐고? 지금까지는 “아니요. 한동안은 더 안정적인 회사에서 일하고 싶어요”라고 생각해 왔다. 하지만 이 글을 쓰면서 스스로 놀랐고 다시 영감을 받았다. 어쩌면 다시 할 때가 된 건지도 모르겠다!

타임라인

아래는 microPledge 타임라인이다(주로 나 자신을 위한 기록!).

• 2006년 1월: 버윈이 출근길에 초기 아이디어를 떠올림
• 2006년 1월: 최초 Subversion 커밋
• 2006년 2월: 세 형제의 μPledge(당시 원래 이름)에 대한 첫 회의. 회의록 인용: “(헛된 꿈일지도 모르지만) 6개월 안에 뭔가 출시할 수 있을 거라 상상한다.”
• 2006년 3월: 웹 프레임워크 결정 — Django보다 “학습 곡선이 1/6”이고 훨씬 가볍게 느껴진 web.py를 선택
• 2006년 6월: 첫 코드 커밋 — 코드 구조와 미니 ORM 작업 시작
• 2006년 7~12월: 초기 코드 작업 — 데이터 모델, HTML 생성, 서버 설정
• 2007년 1월: PayPal 연동 코드
• 2007년 2~3월: 페이지 템플릿, 프로젝트 페이지, 진행 슬라이더 등
• 2007년 3월: microPledge 특허 출원서 작성
• 2007년 4~5월: 후원 및 투표, 자금 인출, 로그인, 개발자가 10% 패널티를 물고 철회할 수 있는 기능
• 2007년 5월: Amazon S3를 이용한 파일 업로드 및 프로젝트 썸네일
• 2007년 6~7월: 집중적인 테스트와 버그 수정, PostgreSQL WAL 백업, 서버 설정 완료
• 2007년 8월: 출시! 보도자료 배포, Slashdot.org에 제출, 여러 오픈소스 프로젝트에 연락
• 2007년 9월: Dominion Post에 기사 게재
• 2008년 9월: 신탁 계좌에 돈을 보관했다는 이유로 PayPal이 계정 정지
• 2008년 10월: 1200명의 사용자에게 “microPledge를 계속 유지하기 위해” 각 $10 후원을 요청(다른 결제 업체로 전환하기 위해)
• 2009년 12월: microPledge 소프트웨어 또는 IP 판매 시도
• 2010년 2월: Flippa.com에서 회사 매각 시도
• 2013년 2월: micropledge.com 도메인을 만료시킴 — 한 시대의 끝.