POOOLING FOREST
6억 달러 유니콘의 파산이 남긴 교훈: 스케일업보다 중요한 것 - 6억 달러 투자 유치 후 파산한 Ÿnsect의 사례를 통해 스타트업이 경계해야 할 '검증 없는 스케일업'과
Product Strategy

6억 달러 유니콘의 파산이 남긴 교훈: 스케일업보다 중요한 것

6억 달러 투자 유치 후 파산한 Ÿnsect의 사례를 통해 스타트업이 경계해야 할 '검증 없는 스케일업'과 '포커스의 부재'에 대한 깊은 통찰을 공유합니다.

김형철

CEO / PM

안녕하세요. 풀링포레스트 CEO 김형철입니다.

최근 프랑스의 곤충 스마트팜 스타트업 'Ÿnsect(인섹트)'가 파산 절차에 들어갔다는 소식을 접하고 많은 생각에 잠겼습니다. 한때 로버트 다우니 주니어가 방송에 나와 극찬하고, 누적 6억 달러(약 8천억 원) 이상의 투자를 유치하며 승승장구하던 기업이었습니다. 겉으로 보기에 그들은 완벽해 보였습니다. '지구 식량난 해결'이라는 거대한 비전이 있었고, 막대한 자본이 있었으며, 최고의 인재들이 모여 있었으니까요. 하지만 결과는 참담했습니다. 그들의 실패 과정을 복기하다 보니, 비단 하드웨어 제조 스타트업만의 이야기가 아니라 우리 같은 소프트웨어 기업, 특히 PM과 엔지니어들이 매일 마주하는 의사결정의 문제와 맞닿아 있다는 사실을 뼈저리게 느꼈습니다.

Ÿnsect의 가장 치명적인 실수는 '검증되지 않은 가설 위에 거대한 성을 쌓은 것'이었습니다.

그들은 곤충 단백질이 미래의 식량이 될 것이라는 대전제 하에, 초기부터 '기가 팩토리(Giga-factory)'라 불리는 세계 최대 규모의 생산 시설을 짓는 데 막대한 자금을 쏟아부었습니다. 하지만 정작 그들이 주력하려던 가축 사료 시장은 마진이 박한 원자재 시장이었고, 값비싼 곤충 단백질은 기존 대두나 어분 사료와 가격 경쟁이 되지 않았습니다. 단위 경제성(Unit Economics)이 나오지 않는 구조였음에도 불구하고, 그들은 공장부터 지었습니다.

이 지점에서 우리 소프트웨어 개발 조직의 모습을 돌아보게 됩니다.

저 역시 풀링포레스트 초기 시절, 비슷한 실수를 저지를 뻔했습니다. 당시 우리는 아직 고객의 니즈가 명확히 확인되지 않은 신규 기능을 기획하면서, 트래픽이 폭주할 것을 미리 걱정했습니다. "만약 100만 명이 동시에 접속하면 어떡하지?"라는 행복한 고민에 빠져, 복잡한 MSA(Microservices Architecture)를 설계하고 오버스펙의 클라우드 인프라를 구축하려 했습니다.

당시 엔지니어링 팀과는 "일단 모놀리식으로 빠르게 배포해서 반응부터 보자"와 "나중에 뜯어고치기 힘드니 처음부터 완벽하게 짜자"는 의견이 팽팽히 맞섰습니다. 다행히 우리는 전자를 택했고, 결과적으로 그 기능은 시장 반응이 미비하여 몇 달 뒤 폐기되었습니다. 만약 그때 우리가 Ÿnsect처럼 '소프트웨어 기가 팩토리'를 짓는 데 리소스를 다 썼다면, 지금의 풀링포레스트는 없었을지도 모릅니다.

Ÿnsect의 또 다른 패착은 '우유부단함'이었습니다. 그들은 가축 사료, 반려동물 사료, 그리고 인간용 식품 시장 사이에서 명확한 우선순위를 정하지 못했습니다. 심지어 매출 기여도가 낮은 인간용 식품 시장 진출을 위해 또 다른 기업을 인수하기도 했습니다. 스타트업에게 '포커스(Focus)'는 생존의 문제입니다. 모든 시장을 만족시키려다 보면, 결국 그 누구의 문제도 해결하지 못하는 제품이 탄생합니다.

우리가 제품을 개발할 때도 마찬가지입니다. B2B와 B2C를 동시에 잡겠다거나, 관리자 기능과 엔드 유저 기능을 동시에 고도화하겠다는 욕심은 프로젝트를 진흙탕으로 밀어 넣습니다. Ÿnsect가 뒤늦게 마진율이 높은 반려동물 사료 시장으로 피벗(Pivot)을 시도했지만 이미 거대 공장에 자금이 묶여 늦었던 것처럼, 소프트웨어 프로젝트 역시 기술 부채와 레거시 코드가 산더미처럼 쌓인 뒤에는 방향을 틀기가 너무나 고통스럽습니다.

Ÿnsect의 사례를 통해 우리가 얻어야 할 인사이트는 명확합니다.

  • 스케일업보다 PMF가 먼저입니다: Ÿnsect는 비즈니스 모델이 검증되기도 전에 '산업화'를 시도했습니다. 우리도 코드를 짜기 전, 인프라를 확장하기 전에 이것이 진짜 고객이 돈을 낼 만한 가치인지 검증해야 합니다. MVP(Minimum Viable Product)의 정신을 잊지 말아야 합니다.

  • 단위 경제성을 무시하지 마십시오: 개별 트랜잭션에서 이익이 나지 않는 구조라면, 규모를 키울수록 손실만 커집니다. 클라우드 비용, API 호출 비용 등 개발 리소스도 철저히 비용 관점에서 바라봐야 합니다.

  • 유연성을 유지하십시오: Ÿnsect의 기가 팩토리는 시장 변화에 대응할 수 없는 거대한 족쇄가 되었습니다. 소프트웨어 아키텍처도 마찬가지입니다. 너무 견고하고 복잡한 설계는 오히려 비즈니스의 기민함을 해칠 수 있습니다.

"우리는 문샷(Moonshot)에는 투자하지만, 공장에는 투자하지 않는다." 어느 경영대학원 교수가 Ÿnsect 사태를 두고 한 말입니다.

원대한 비전은 중요합니다. 하지만 그 비전을 지탱하는 것은 결국 냉철한 현실 인식과 촘촘한 실행 계획입니다.

지금 여러분이 만들고 있는 기능, 혹은 설계하고 있는 아키텍처가 혹시 '검증되지 않은 기가 팩토리'는 아닌지 한 번쯤 멈춰 서서 고민해 보는 시간이 되었으면 합니다. 막막할 때는 언제나 '고객'과 '데이터'라는 기본으로 돌아가는 것이 가장 빠른 길임을, 저 역시 다시 한번 되새깁니다.

오늘도 불확실성 속에서 확신을 만들어가는 모든 메이커 분들을 응원합니다.

지금 읽으신 내용, 귀사에 적용해보고 싶으신가요?

상황과 목표를 알려주시면 가능한 옵션과 현실적인 도입 경로를 제안해드립니다.