직접 만들 제품의 스택을 고민하는 한편으로, 외주 개발 고객에게 제안할 기술 스택도 함께 검토하고 있었습니다. 외주 스택은 금방 정해졌습니다. 모바일은 React Native나 Flutter, 프론트엔드 SPA는 React, SSR이 필요하면 Next.js, 백엔드는 Spring이나 NestJS. 인프라는 빠른 MVP나 투자 유치용 데모 단계에는 슈파베이스, 정식 서비스에는 AWS. 현업에서 대중적이고 익숙한, 당연해 보이는 선택이었습니다.
몇 가지 고민이라면 1인 외주 개발자가 안드로이드와 iOS 두 네이티브를 모두 소화하기 어렵다는 점과, Flutter나 Spring 대신 React Native와 NestJS를 골라 TypeScript로 스택을 통일해 두면 고객이 나중에 인력을 충원하거나 제품을 확장할 때 더 낫지 않을까 하는 점이었습니다.
그런데 정작 외주 개발 고객이 누구인지는 따져 보지 않았습니다.
이미 외부 투자를 받은 스타트업이라면 자체 인력을 꾸리거나 규모 있는 외주 개발사를 선택합니다. 1인 외주 개발자가 백엔드부터 웹과 모바일, 백오피스까지 하나로 묶어 턴키로 제공한다면, 찾아올 고객은 그쪽이 아닙니다. 외부 투자 없이 제품을 키우는 부트스트래퍼(Bootstrapper)이거나, 투자 유치를 위한 데모 제품이 필요한 쪽일 가능성이 큽니다.
결국 내 고객은 스스로 0 to 1을 만들어 내려는, 지금의 나와 비슷한 상황일 가능성이 큽니다. 제품을 만들며 쌓이는 노하우와 스택을 외주에도 그대로 쓰는 것이 최선이지 제품과 외주의 스택을 둘로 나누는 것은 추가 학습 시간과 관리 비용만 늘릴 뿐입니다.
그렇다고 제품의 기술 스택 후보였던 Laravel과 .NET 중 하나를 선택할 수는 없습니다. 제품을 납품하는 것과 고객이 그 제품으로 서비스를 운영하는 것은 다른 문제입니다. 서비스 운영에는 지속적인 기능 업데이트가 따르고, 성장에 맞춘 아키텍처 변경과 대규모 리팩토링도 필요해집니다. 그 과정에서 인력 구성 역시 바뀔 수밖에 없습니다. 국내 개발 인력 시장은 특정 스택으로 상당히 편중되어 있어서, 마이너한 기술 스택은 인력 충원이나 외주 개발사 섭외를 어렵게 만듭니다. 자칫 업데이트 시기를 놓쳐 경쟁 제품에 뒤처질 수 있습니다.
제품 자체가 사업의 속도를 따라가지 못해 병목이 되어서는 안 됩니다. 가능한 한 대중적인 기술 스택을 선택하거나, 적어도 다른 스택으로 전환하기 용이한 상태를 만들어 두어야 합니다. Laravel과 .NET보다 TypeScript 풀스택이 이 조건에 더 잘 맞습니다. 인력 시장이 넓어 충원이 수월하고, 서비스 성장에 맞추어 기술 스택을 점진적으로 확장하고 전환하기에도 유리합니다.
결과적으로 개인적인 취향은 뒤로 미루기로 했고, 고객에게 권할 스택을 그대로 제품에 쓰기로 했습니다.