초기 스타트업을 조용히 침몰시키는 SaaS 개발 실수 9가지

일부러 SaaS 제품을 잘못 만드는 사람은 거의 없습니다. 초기 스타트업을 침몰시키는 실수란, 압박 속에서 똑똑한 사람들이 내리는 조용하고 그럴듯하게 들리는 결정이며, 그 순간에는 하나같이 옳게 느껴집니다. 저희는 똑같은 아홉 가지가 창업자의 차고에서도, 자금이 넉넉한 팀에서도, 수십 개의 제품에서 반복되는 것을 지켜봤습니다. 다행인 점은 이들이 예측 가능하다는 것—즉 피할 수 있다는 것입니다. 이것은 모든 창업자가 첫 코드 한 줄을 쓰기 전에 모니터에 붙여 두었으면 하는 목록입니다.

저희는 중소기업을 위한 소프트웨어를 만들기에 아주 다른 두 시점에 불려 갑니다. 어떤 때는 첫날, 스케치와 아이디어밖에 없을 때입니다. 안타깝게도 더 흔한 것은 9개월째—창업자가 저축을 다 쓰고, 제품은 기술적으로 작동하는데도 아무도 돈을 내지 않을 때입니다. 바로 이 두 번째 전화가 저희에게 이 목록을 가르쳐 주었습니다. 부검할 때마다 일찍 입혀져 곪도록 방치된 똑같은 몇 가지 상처가 드러납니다.

이 실수들 중 어느 것도 재능의 문제가 아닙니다. 실수를 저지르는 사람들은 대개 유능하고 성실합니다. 문제는, SaaS를 만드는 일이 자기 아이디어에 들떠 있을 때는 자연스럽게 나오지 않는 매우 특수한 종류의 절제를 보상한다는 점입니다. 그러니 대체로 효력을 발휘하는 순서대로 아홉 가지를 살펴보고, 각각이 왜 그토록 유혹적인지 솔직하게 이야기해 봅시다.

1. 단 한 명의 고객과도 말하기 전에 6개월간 만들기

이것이 원죄이며 가장 비쌉니다. 창업자는 아이디어가 좋다고 확신하고—실제로 그럴 수도 있습니다—입을 다문 채 반년간 머리를 박고 만들다가, 아무도 요청하지 않은 잘 다듬어진 제품을 들고 나타납니다. 시장은 노력에 보상하지 않습니다. 누군가가 돈을 내서라도 없애고 싶어 하는 문제를 해결하는 데 보상합니다.

해법은 복잡하지 않고 그저 불편할 뿐입니다. 완성되기 전에 거친 무언가를 실제 잠재 고객에게 보여주는 것입니다. 클릭 가능한 목업, 랜딩 페이지, 심지어 이메일로 손수 수행하는 서비스의 수동 버전이라도 좋습니다. 사람들이 원한다고 확인하기 전에 만드는 한 주 한 주는, 엉뚱한 거리에 지은 집을 꾸미는 데 쓰는 한 주가 될 수 있습니다.

2. 있지도 않은 백만 명의 사용자를 위해 만들기

두 번째 실수는 전문성의 옷을 입고 있습니다. 창업자나 야심 찬 초기 엔지니어가 첫날부터 거대한 규모를 감당하도록 시스템을 설계합니다—마이크로서비스, 쿠버네티스, 다중 리전 데이터베이스, 정교한 캐싱 계층. 책임감 있어 보입니다. 하지만 사실은 함정입니다. 가장 희소한 자원인 시간을, 가질 수만 있다면 행운일 문제를 막는 데 쓰고 있는 셈입니다.

지루한 단일 데이터베이스 모놀리식은 처음 수천 명의 사용자까지, 그리고 첫 매출을 훌쩍 넘겨 여러분을 거뜬히 실어 나릅니다. 규모에서 중요해지는 아키텍처 결정은 시작 시점에 예견할 수 있는 것이 거의 결코 아니며, 때 이른 복잡성은 제품의 변경을 더 느리게 만듭니다—초기에는 바로 그것이 여러분을 진짜로 죽이는 유일한 것입니다. 상상 속 백만 번째가 아니라 다음 열 명의 고객을 위해 만드세요.

3. 최소도, 실행 가능도, 제품도 아닌 MVP

모두가 MVP를 만드는 데 동의합니다. 실제로 하는 사람은 거의 없습니다. 대신 출시되는 것은 창업자가 상상할 수 있는 모든 기능으로 가득 찬 비대한 '버전 1'입니다. 기능을 덜어내는 것이 야망을 덜어내는 것처럼 느껴지기 때문입니다. 그 결과는 세 배의 시간이 걸리고, 세 배의 비용이 들며, 배우기가 더 어렵습니다—비대한 제품이 실패하면 어느 부분이 잘못됐는지 알 수 없기 때문입니다.

진짜 MVP는 누군가가 돈을 낼 만큼만 충분히 한 가지를 잘 해냅니다. 그게 전부입니다. 절제란 무엇을 포함할지 정하는 것이 아니라 무엇을 빼낼지 정하는 것입니다. 미루는 '당연한' 기능 하나하나가 되찾는 한 주이며, 추측이 아니라 실제 사용자로 답할 수 있는 질문이라는 것을 알면서 말입니다.

범위에 대한 빠른 점검

어떤 기능이든 첫 빌드에 들어가기 전에, 저희는 창업자에게 한 가지 질문에 소리 내어 답하게 합니다. "이것 없이 출시한다면, 단 한 명의 유료 고객이라도 제품 사용을 거부할까?" 정직한 답이 '아니오'라면, 그 기능은 대기입니다. '필수' 기능 목록의 얼마나 많은 부분이 이 한 문장 앞에서 증발하는지 보면 놀랄 것입니다.

• 기능이 사용자를 위해서가 아니라 투자자를 감탄시키기 위해 존재한다면, 대기.
• 기능이 사용자 20명 중 1명 미만이 마주칠 예외 상황을 처리하는 것이라면, 대기.
• 아직 아무도 바꿔 달라고 요청하지 않은 동작을 설정하는 설정 화면을 만들고 있다면, 대기.
• '경쟁사가 가지고 있다'가 목록에 오른 유일한 이유라면, 대기.
• 그것을 없애도 단 한 건의 판매도 막지 못한다면, 대기.

4. 결제와 온보딩을 뒷전으로 다루기

창업자는 핵심 기능에 애정을 쏟다가, 출시 2주 전에야 고객에게 가입하고 결제하고 실제로 사용을 시작할 방법이 필요하다는 것을 떠올립니다. 결제는 허둥지둥 덧붙여집니다. 온보딩은 로그인 화면과 어깨 한 번 으쓱하는 것입니다. 그러나 '관심 있는 방문자'에서 '결제하고 활성화된 사용자'로 가는 경로야말로 여러분의 사업이며—바로 거기서 매출 대부분이 조용히 새어 나갑니다.

정말 뛰어난 핵심 기능을 갖추고도, 가입 후 무엇을 해야 할지 아무도 알아내지 못해 첫 5분 안에 가입자 대부분을 잃는 제품을 저희는 봐 왔습니다. 구독, 체험, 일할 계산, 결제 실패, 해지, 갓 만든 계정의 빈 화면 경험—이것들은 서류 작업이 아닙니다. 고객이 머무를지 결정하는 그 순간의, 바로 진짜 제품입니다.

5. 멀티테넌시를 잘못하기(또는 건너뛰기)

이것은 재앙이 되기 직전까지는 멀쩡해 보이는 실수입니다. SaaS란 많은 고객이 하나의 시스템을 공유한다는 뜻이며, 그들의 데이터를 어떻게 분리하느냐—멀티테넌시—는 토대가 되는 결정입니다. 잘못하면 고객을 제대로 격리하지 못하는 무언가를 만들거나, 더 나쁘게는 한 회사가 다른 회사의 데이터를 볼 수 있는 버그를 출시하게 됩니다. 테넌트 간 데이터 유출만큼 모든 고객을 한꺼번에 잃는 빠른 방법은 없습니다.

이국적인 구성은 필요 없습니다. 대부분의 초기 제품에는 모든 테이블과 모든 쿼리에 엄격하게 강제되는 테넌트 ID를 갖춘 하나의 공유 데이터베이스로 충분합니다—단, 그 격리가 토대에 내장되어 테스트되어 있고, 나중에 뿌려진 것이 아니라는 조건에서요. 실수는 단순한 방식을 고르는 것이 아닙니다. 실수는 의식적으로 결정하지 않고, 이미 운영에 올라간 뒤에야 그 틈을 발견하는 것입니다.

6. 사용자가 무엇을 하는지 볼 방법 없이 깜깜이로 출시하기

출시합니다. 사람들이 가입합니다. 그리고… 침묵. 그들이 어떤 기능을 만지는지, 어디서 막히는지, 왜 떠나는지 전혀 모릅니다. 그래서 추측합니다. 직감이나, 가장 목소리 큰 고객 이메일, 혹은 자신의 직관에 기대어 다음 기능을 만듭니다—몇 달간 자기 제품 안에 있고 나면, 그 직관은 여러분이 가진 가장 믿을 수 없는 계기입니다.

기본적인 제품 분석과 피드백을 모으는 간단한 방법은 성장기의 사치가 아닙니다. 그것이 여러분이 키를 잡는 방법입니다. 그것 없이는 사업이 아니라 비싼 의견을 운영하는 셈입니다. "두 달을 들여 만든 기능을 사용자 80%가 한 번도 열지 않는다"처럼 단순한 사실을 아는 것만으로도, 깜깜이로 만드는 또 두 달보다 가치가 큽니다.

7. 보안과 백업을 '나중'으로 미루기

속도는 초기의 종교이며, 대체로 그것이 옳습니다. 그러나 나중에 끼워 넣으면 재앙적으로 비싼 것이 몇 가지 있고, 보안이 그 목록의 맨 위입니다. 비밀번호를 제대로 저장하는 것, 누가 무엇에 접근할 수 있는지 잠그는 것, 그리고—부디—작동하고 테스트된 백업을 갖추는 것은 시간이 날 때 추가하는 선택적 기능이 아닙니다. 그것은 여러분이 그 위에 짓는 바닥입니다.

이 범주의 잔인한 점은, 그렇지 않게 되는 바로 그 순간까지는 무사히 넘어간다는 것입니다. 1년 동안 모든 게 괜찮다가, 한 번의 침해, 한 번의 실수로 인한 대량 삭제, 한 번의 랜섬웨어 아침이 그 1년간 쌓아 온 신뢰와 데이터를 지워 버립니다. 저희는 보안 부서를 요구하는 것이 아닙니다. 처음부터 기본이 갖춰져 있기를 요구하는 것입니다. 사고 후에 추가하는 비용은 망한 회사의 수로 측정되기 때문입니다.

8. 잘못된 단계에 잘못된 구축자를 고용하기

비개발자 창업자는 잔인한 선택에 직면합니다. 이걸 실제로 누가 만드는가? 두 가지 전형적인 실수는 서로 거울상입니다. 하나는, 겉보기엔 맞지만 테이프로 붙여 놓아 무언가를 바꿔야 하는 순간 무너지는 결과물을 내놓는, 가능한 한 가장 싼 프리랜서를 고용하는 것입니다. 다른 하나는 과잉 고용—고객을 단 한 명도 벌지 못한 제품을 만들기 위해 전원 시니어로 된 팀에 전액 급여를 주는 것입니다.

정직한 답은 여러분이 지금 어디에 있느냐에 전적으로 달려 있습니다. 아이디어를 검증하려면, 초기 제품을 전에 만들어 봤고 무엇을 빼야 할지 정확히 아는, 작고 노련하며 실용적인 팀을 원합니다. 검증된 제품을 키우려면, 다른 본능을 지닌 다른 사람들을 원합니다. 구축자를 단계에 맞추는 것 자체가 하나의 기술이며—여기서 잘못하면 이 목록의 어떤 기술적 결정보다도 많은 돈을 낭비합니다.

9. 출시를 결승선으로 다루기

마지막 실수는 가장 슬픕니다. 그토록 많은 노고 뒤에 오기 때문입니다. 팀은 출시일을 목표로 삼고, 거기에 도달하기 위해 모든 것을 쏟아붓고, 계획도 예산도 그다음을 위한 에너지도 없이 지친 채 도착합니다. 그러나 출시는 결승선이 아닙니다. 그것은 유일하게 중요한 단계의 시작입니다. 실제 사용자에게서 배우고, 주마다 개선해 나가는 단계 말입니다.

SaaS 제품은 결코 '완성'되지 않습니다. 첫 버전은 가설이며, 출시 후 몇 달은 그것이 얼마나 틀렸는지를—좋은 의미에서—알아내는 때입니다. 그것을 미리 계획하고, 약간의 활주로와 많은 호기심을 비축해 두는 창업자가 바로 흔들리는 출시를 진짜 사업으로 바꾸는 사람들입니다. 출발선에 닿기 위해 모든 것을 써 버린 사람들은 대개 그 너머로 멀리 가지 못합니다.

아홉 가지 모두를 실제로 피하는 법

실수 목록을 읽는 것은 쉽습니다. 마감의 압박 속에서, 내 돈을 걸고 내 아이디어를 가슴에 품은 채 그것들을 피하는 것은 정말로 어렵습니다. 그래서 잘 해내는 창업자들이 대개 어떻게 움직이는지, 그 짧은 버전을 소개합니다—규칙으로서가 아니라 훔칠 만한 습관으로서요.

1. 1
   만들기 전에 검증하라

   본격적인 코드를 쓰기 전에, 거친 무언가를 실제 잠재 고객 앞에 두고 그들이 돈을 낼지 확인하라. 하기엔 싸고, 건너뛰면 잔인하다.
2. 2
   가장 작은 진짜 제품을 골라라

   제품이 반드시 해야 할 한 가지를 정의하고, 나머지 모두를 가차 없이 미뤄라. '버전 1'이 의도적으로 포함하지 않는 것을 적어 두어라.
3. 3
   지루하게 만들고 테넌트를 격리하라

   작동하는 가장 단순한 아키텍처를 쓰되, 고객 간 데이터 분리는 첫날부터 토대가 되는 테스트된 결정으로 삼아라.
4. 4
   돈의 경로를 일찍 설계하라

   가입, 온보딩, 결제를 서류 작업이 아니라 핵심 제품으로 다뤄라. 첫 5분이 나머지가 보일지 말지를 결정한다.
5. 5
   계측을 넣고, 배우기 위해 출시하라

   기본 분석과 피드백을 갖춰 출시하고, 출시 이후 단계를 위한 활주로를 남기며, 첫 버전을 답이 아니라 질문으로 다뤄라.

거의 아무것도 코딩 실력에 관한 것이 아님을 눈치채세요. 그것은 판단—무엇을 만들고, 무엇을 건너뛰고, 언제 할지를 아는 것—에 관한 것입니다. 기술적으로 유능한 그토록 많은 팀이 그래도 실패하는 제품을 내놓는 이유가 바로 이것입니다. SaaS의 어려운 부분은 결코 엔지니어링이 아니었습니다. 그것은 절제였습니다.

자주 묻는 질문