Build or Buy; SaaS 도입 결정하기
유니콘 스타트업에서 SaaS 도입 결정하기
회사의 성장과 함께 각 조직이 담당하는 역할은 고도화되며, 이를 효율적으로 수행하기 위해서는 솔루션(소프트웨어)의 도움이 필요한 경우가 있습니다. 솔루션을 내부적으로 직접 개발할 것인지, 아니면 외부에 있는 솔루션을 구매 (또는 구독)하여 사용할 것인지는 고민의 대상입니다. 저도 유니콘이 된 스타트업 두 곳을 Series A 단계부터 경험하며 Build or Buy에 관한 고민을 했었습니다. 도입 후 본격적으로 사용하게 되면 연간 몇 억원을 넘어서는 Enterprise 급 솔루션의 구매 결정이다 보니 각 결정의 장/단점을 여러 각도에서 고민 하였던 것 같습니다. 한 번은 Build라는 선택을, 한 번은 Buy라는 선택을 했었는데요. 이 글에서는 그런 경험을 바탕으로 Build or Buy의 장단점을 소개 드리려 합니다.
저의 첫 번째 Build or Buy 고민은 Global SaaS 회사에서 근무할 때였습니다. 당시 회사는 Sales 인력이 30여 명에서 100여 명까지 빠르게 늘어나고 있던 시기였고, 회사 초기 CRM을 위해 자체 개발한 솔루션이 Sales 효율성의 저하를 야기하고 있었습니다. 서비스가 고도화되고 관리해야 할 Sales Rep. 과 잠재 고객 및 고객들의 수가 늘어남에 따라 확인하고 싶은 지표 중 수집/기록하지 못하는 지표들이 생겨나게 되었고, 영업팀 간의 Account 배분, 고객 Database 정합성 문제 등을 포함한 다양한 문제들이 발생하였죠. 이를 해결하기 위해 새로운 영업관리 (고객 관리) 솔루션의 개발 또는 도입이 필요하다는 결론에 도달하게 되었고, Build or Buy를 결정해야 했습니다.
Build or Buy 결정에서 첫 번째로 했던 질문은 내부적으로 원하는 솔루션을 Build 할 수 있는 리소스와 역량이 있는가였습니다. 해당 부분은 가능하다는 답변을 Tech 조직으로부터 받았고, 다음 3가지 질문을 하게 되었습니다: 1)솔루션 사용 시 회사의 특수한 Sales Process 또는 Requirement를 반영할 수 있는가? 만약 반영하지 못한다면 어떤 문제가 있는가?, 2)솔루션의 가격이 기회비용을 반영한 직접 개발 비용 대비 저렴한가?, 3)락인 효과가 있는가? Salesforce, Hubspot을 포함한 4가지의 Global CRM 솔루션들이 도입 후보였고, 모든 후보들이 첫 번째 질문에서 문제가 있었습니다.
그 당시 회사에서 필요로 했지만 CRM 솔루션에서 지원되지 않았던 필수적인 기능은 회사 플랫폼과 CRM 솔루션간의 실시간 정보 Sync였습니다. 플랫폼 내에서 발생하는 가격정보를 포함한 다양한 정보를 CRM으로 Export 하고, 해당 정보를 바탕으로 Sales가 CRM 솔루션에 추가 정보를 기입하면, 추가된 정보를 CRM 솔루션에서 플랫폼으로 가져와 반영하는 유기적인 Sync가 필요했습니다. 해당 기능이 필요했던 이유는 Sales가 가격 정보를 잠재 고객 또는 고객에게서 수집하면 바로 시스템에 반영되어야 했고, 해당 가격 정보를 기반으로 모든 Sales Rep들이 영업을 진행해야 했기 때문입니다. 해당 기능은 회사의 Business Model을 구성하는 필수적인 요소였기 때문에, 어떠한 비용을 지불하더라도 구현되어야 했던 기능이었죠. 따라서, 당시에는 추가적인 검토를 하지 않고, 직접 CRM 솔루션을 Build 하는것으로 결론을 내렸습니다.
Build or Buy에 대한 두 번째 고민은 Cloud Managed Service Provider에서 Sales 조직의 역할을 구분하고 고도화할 때 발생하였습니다. 기존에 Sales Team으로만 구성되어 있던 구조에서 Demand Generation과 Inside Sales 업무를 수행할 Team을 추가하게 되었고, 그에 따라 새로운 Team들이 업무를 수행하기 위해 필요한 소프트웨어의 구매가 필요하게 되었습니다. 이번 결정에 있어서도 전 회사와 동일한 Framework로 Build or Buy를 결정하게 되었는데요. 새롭게 추가되는 조직이라는 점 그리고 Business Model에 영향을 주는 게 아니라 영업방식에만 영향을 준다는 점 때문에 일전에 문제가 되었던 점은 이번에는 문제가 되지 않았습니다. 또한, 특수한 요구 조건이 없을시 대부분의 SaaS들이 직접 Build 하는것 보다 저렴하고, 신규 조직이다 보니 락인에 대한 우려사항이 없다는 점 때문에도 Build 보다는 Buy가 맞다는 결정을 하게 되었습니다.
대부분의 SaaS가 직접 개발하고 유지/보수하는 비용보다 훨씬 저렴하다 보니 가격적인 문제보다는, Build or Buy에 있어서 가장 중요한 질문은 “기존에 일하던 방식을 도입하는 SaaS에 맞추는 게 쉬운가”인가 아니면 “솔루션을 기존에 일하던 방식에 맞도록 만드는 게 쉬운가”인가 인 것 같습니다. 인건비의 상승, 개발자 부족, 인력 Outsourcing의 결과물의 Quality 차이가 큰 점 등을 생각하면, 앞으로 SaaS 도입률은 계속해서 올라갈 것 같다는 생각이 듭니다.
