기술 스택을 고를 때 보통 기술적 기준으로 판단한다. 성능, 생태계, 러닝 커브, 커뮤니티 크기. 그런데 비즈니스 관점에서 보면 다른 기준이 더 중요할 때가 있다.

채용, 속도, 비용, 확장성. 이 네 가지가 기술 선택에 어떤 영향을 미치는지 경험한 것을 정리한다.

채용 가능성#

최고의 기술이 아니라 채용 가능한 기술을 고르는 게 현실적이다.

Svelte가 기술적으로 뛰어나다는 건 알고 있다. 번들 사이즈가 작고, 보일러플레이트가 적고, 학습 곡선이 완만하다. 그런데 한국에서 Svelte 개발자를 구하기 어렵다. React 개발자는 넘치는데.

스타트업에서 채용 한 명이 2~3개월 걸리면, 그 기간 동안의 개발 공백이 비즈니스에 직접적인 타격이 된다. "React로 하면 2주 안에 사람을 뽑을 수 있다"는 건 기술적 장단점과는 별개의 강력한 이유다.

예전 회사에서 Elm을 쓰고 있었다. 타입 안전성은 완벽했다. 그런데 개발자가 퇴사하면 대체 인력을 찾을 수 없었다. 결국 TypeScript + React로 마이그레이션하기로 했다. 기술적으로는 후퇴처럼 보였지만, 비즈니스적으로는 올바른 판단이었다.

시장 출시 속도#

초기 스타트업에서 가장 중요한 건 속도다. 완벽한 아키텍처보다 빠른 출시가 더 가치 있다.

이 관점에서 기술 선택을 보면:

풀스택 프레임워크를 쓴다. Next.js, Remix 같은 풀스택 프레임워크는 프론트엔드와 백엔드를 하나의 코드베이스에서 관리할 수 있다. 별도의 백엔드 서버를 구축하고 API를 설계하는 시간을 줄여준다. MVP 단계에서는 이 시간 절약이 크다.

관리형 서비스를 쓴다. 인증은 Clerk이나 NextAuth, 데이터베이스는 Supabase나 PlanetScale, 배포는 Vercel. 직접 구축하면 각각 일주일씩인데, 관리형 서비스를 쓰면 하루면 된다. 비용? MVP 단계에서 대부분 무료 티어로 충분하다.

성능 최적화는 나중에. "사용자가 1000명이 되면 성능 문제가 생길 수 있어요." 맞다. 그런데 사용자가 1000명이 될 때까지 살아남는 게 먼저다. 문제가 생기면 그때 해결해도 된다. 처음부터 10만 명을 대비한 아키텍처를 설계하면 출시가 3개월 늦어진다.

운영 비용#

기술 선택은 장기 운영 비용에 직접 영향을 준다.

서버리스 vs 서버. 트래픽이 일정하면 서버가 저렴하다. 트래픽이 불규칙하면 서버리스가 합리적이다. B2B SaaS처럼 업무 시간에만 트래픽이 있는 서비스라면, 서버리스로 야간 비용을 아낄 수 있다.

데이터베이스 선택. PostgreSQL은 무료지만 운영 비용(모니터링, 백업, 스케일링)이 든다. 관리형 DB 서비스는 월 비용이 들지만 운영 부담이 없다. 개발자 1~2명인 팀에서는 관리형이 총비용(인건비 포함)이 더 저렴하다.

확장 가능성#

"나중에 바꾸면 되지"가 항상 맞는 건 아니다. 마이그레이션 비용이 큰 선택은 신중해야 한다.

언어/프레임워크는 바꾸기 어렵다. React에서 Vue로 바꾸는 건 거의 재작성이다. 이건 신중하게 선택해야 한다.

라이브러리는 바꾸기 쉽다. 상태 관리를 Redux에서 Zustand로 바꾸는 건 점진적으로 가능하다. 이건 덜 고민해도 된다.

데이터 모델은 바꾸기 어렵다. DB 스키마, API 인터페이스 — 이건 한 번 정하면 바꾸기 어렵다. 여기에 시간을 더 투자하는 게 맞다.

기술 선택의 최적해는 상황에 따라 다르다. 초기 스타트업, 성장기 스타트업, 대기업의 최적 기술 스택이 다르다. 중요한 건 기술적 멋이 아니라, 지금 이 상황에서 비즈니스에 가장 도움이 되는 선택을 하는 것이다.