스타트업의 74%가 조기 스케일링으로 실패한다. 당신의 Tech Stack이 문제일 수 있다.
Source: Dev.to
2011 Startup Genome Study
2011년에 Startup Genome는 Berkeley와 Stanford와 협력해 3,200개 스타트업을 조사했습니다. 그들은 대부분이 왜 실패하는지 알고 싶었습니다.
답은 나쁜 아이디어 때문이 아니었습니다. 자금 부족도 아니었고, 경쟁도 아니었습니다.
실패한 스타트업의 74 %는 조기 스케일링—제품‑시장 적합성을 찾기 전에 복잡성(인프라, 기능, 팀 규모, 프로세스…)을 추가했기 때문입니다. 같은 연구에 따르면, 실패한 스타트업은 성공한 스타트업보다 제품‑시장 적합성에 도달하기 전 3.4 배 더 많은 코드를 작성했습니다.
잠시 생각해 보세요. 살아남은 팀은 코드를 적게 쓰고 더 단순한 아키텍처를 사용했습니다. 실패한 팀은 플랫폼을 구축하느라 바빴습니다.
The Conference Talk Problem
모든 컨퍼런스 발표, 모든 트렌디한 레포, 모든 “모던 스택” 블로그 포스트는 여러분을 복잡성 쪽으로 끌어당깁니다: GraphQL, 마이크로서비스, 이벤트‑드리븐 아키텍처, 서스펜스 경계에 감싸인 클라이언트 컴포넌트 안에 중첩된 서버 컴포넌트 등.
대부분은 아직 여러분에게 없는 문제를 위한 엔지니어링입니다.
Dan McKinley(전 Etsy 수석 엔지니어)는 2015년에 이 주제에 대해 글을 썼으며, 그 프레임워크는 시간이 지나도 여전히 유효합니다. 모든 엔지니어링 팀은 대략 **세 개의 “혁신 토큰”**을 갖습니다. 이 토큰은 웹 프레임워크, 데이터베이스, 배포 파이프라인이 아니라 제품 차별화 요소에 사용하세요.
제품 혁신이 새로운 AI 기능이라면, 그곳에 토큰을 쓰세요. 여러분의 REST API는 토큰이 필요 없습니다.
Companies That Started Boring
이것은 가상의 이야기가 아닙니다.
-
Shopify는 Rails 모듈형 모놀리스를 운영합니다. 2024년 블랙 프라이데이 주말에 1,730억 건의 요청을 처리했으며, 마이크로서비스도, 맞춤 프레임워크도, Rails도 아니었습니다. 18년 동안 아키텍처를 다듬었지만 기반은 절대 바뀌지 않았습니다.
-
GitHub는 12년 동안 Rails 모놀리스를 사용했습니다. 2020년에 1,000명의 엔지니어가 되어서야 서비스를 추출하기 시작했습니다. 천 명의 엔지니어가 있었는데도 여전히 모놀리스를 사용하고 있었습니다. 서비스를 추출했을 때는 선택적으로 진행했으며… 모놀리스가 확장되지 못해서가 아니라 팀이 더 이상 내부에서 협업할 수 없었기 때문입니다.
실제 확장 문제: 사람, 서버가 아니라.
-
Stack Overflow는 9대의 온‑프레미스 서버에서 10년 넘게 운영되었습니다—수십억 페이지 뷰를 처리하는 .NET 모놀리스와 SQL Server였습니다. 이는 업계가 말하는 확장과 정반대였기에 투명하게 공개했습니다. 2025년에 데이터센터 계약이 종료되면서 클라우드로 마이그레이션했지만, 그때까지의 아키텍처는 15년 이상 의도적으로 지루하게 유지되었습니다.
-
WhatsApp은 4억 5천만 명의 활성 사용자를 32명의 엔지니어만으로 처리했으며, Facebook에 190억 달러에 인수되었습니다. 전체 엔지니어링 팀 규모는 대부분의 Series A 스타트업보다 작았습니다.
The Boring Stack Formula
당신이 솔로 개발자이거나 작은 팀으로 SaaS 제품을 만든다면, “지루함”이 실제로 어떤 모습인지 아래와 같습니다.
- 하나의 서버, 두 개의 앱 – 백엔드 API와 프론트엔드 클라이언트. 서비스 메시가 아니라 메시지 큐도 없습니다. 같은 머신에서 HTTP로 통신하는 두 프로세스.
- 관계형 데이터베이스 – 여러분의 데이터는 거의 확실히 관계형입니다(사용자 → 조직 → 구독 → 청구서). PostgreSQL은 25년 이상 안정적으로 이를 처리해 왔으며, 데이터의 5 % 정도가 문서 형태일 경우를 대비해 JSON 컬럼도 지원합니다.
- 직접 구축하지 않은 인증 – 인증은 이미 해결된 문제이며, 직접 구현하면 가장 위험합니다(세션 관리, 토큰 회전, OAuth 흐름, MFA, 비밀번호 해싱 등). Clerk, Auth0, Supabase Auth 등을 사용하세요. 여러분의 일은 제품을 만드는 것입니다.
- 마이크로서비스가 아니다 – 마이크로서비스를 운영할 팀이 없습니다. 마이크로서비스는 조직 규모의 확장 패턴이지 기술적 패턴이 아닙니다. 팀이 한 방에 모일 수 있다면, 마이크로서비스는 네트워크 호출, 배포 복잡성, 분산 디버깅을 추가할 뿐 아무 이득도 주지 않습니다.
- REST, GraphQL이 아니라 – GraphQL은 대규모 조직에 적합합니다.
Source:
multiple frontend clients consuming the same API. If you have one frontend, REST endpoints with clear request/response contracts are simpler to build, debug, and cache. You can always add GraphQL later if you actually need it.
When You’ll Outgrow This
You will. That’s fine.
A single server running FastAPI and PostgreSQL handles 10,000+ concurrent users without straining. When the bottleneck appears, it will be database queries—not the framework or the architecture.
- Add indexes.
- Add caching.
- Optimize the queries showing up in your slow‑query log.
These are straightforward problems with straightforward solutions.
If you reach the point where a single server isn’t enough, that’s a good problem. It means your product works, people are using it, and you’ll have revenue, data, and context to make informed architecture decisions instead of guesses.
The 2026 Bonus
Here’s something the Startup Genome study couldn’t have predicted in 2011.
Well‑documented, widely‑used frameworks produce measurably better results with AI coding tools. Cursor, Copilot, and Claude Code all perform better with FastAPI than with a framework that shipped six months ago. The training data is deeper, the patterns are more consistent, and the suggestions are more accurate.
Boring tech isn’t just safer. In 2026, it’s faster to build with.
한국어 번역
여러 프론트엔드 클라이언트가 동일한 API를 사용합니다. 프론트엔드가 하나라면, 명확한 요청/응답 계약을 가진 REST 엔드포인트가 구축, 디버깅, 캐시 관리가 더 간단합니다. 실제로 필요할 경우 언제든지 GraphQL을 추가할 수 있습니다.
이 구조를 벗어날 때
그럴 겁니다. 괜찮습니다.
FastAPI와 PostgreSQL을 실행하는 단일 서버가 10,000명 이상의 동시 사용자를 문제 없이 처리합니다. 병목 현상이 나타난다면 데이터베이스 쿼리가 원인일 것이며, 프레임워크나 아키텍처가 아닙니다.
- 인덱스를 추가합니다.
- 캐시를 도입합니다.
- 슬로우 쿼리 로그에 나타나는 쿼리를 최적화합니다.
이러한 문제는 직관적인 해결책을 가지고 있습니다.
단일 서버만으로는 부족해지는 시점에 도달한다면, 이는 좋은 문제입니다. 제품이 정상적으로 작동하고, 사용자가 늘어나며, 수익과 데이터, 그리고 상황을 파악할 수 있는 기반이 생겨 추측이 아닌 근거에 기반한 아키텍처 결정을 내릴 수 있게 됩니다.
2026년 보너스
2011년 Startup Genome 연구에서는 예측하지 못했던 내용입니다.
잘 문서화되고 널리 사용되는 프레임워크는 AI 코딩 도구와 함께 사용할 때 측정 가능한 더 나은 결과를 제공합니다. Cursor, Copilot, Claude Code 모두 FastAPI와 함께 사용할 때, 6개월 전 출시된 프레임워크보다 더 높은 성능을 보입니다. 학습 데이터가 더 풍부하고, 패턴이 일관되며, 제안이 더 정확합니다.
지루한 기술은 단순히 안전할 뿐만 아니라, 2026년에는 구축 속도가 더 빠른 기술이 됩니다.
이제 무언가를 만들어 보세요
당신의 아이디어가 흥미로운 부분입니다. 사용자, 시장, 제품… 바로 그곳에 흥미로운 결정이 있습니다.
데이터베이스 스키마, API 프레임워크, 배포 파이프라인… 이것들은 해결된 문제여야 하며, 당신은 해결되지 않은 문제에 집중할 수 있습니다.
저는 이 철학을 바탕으로 The Unsexy Stack 를 만들었습니다: FastAPI + Next.js 15 + PostgreSQL. 두 개의 앱, 하나의 서버, 111개의 테스트, 17개의 PDF 가이드. 당신의 길을 방해하지 않는 기반을 제공하여 buil
... the thing that matters.
But you don't need my boilerplate to apply this thinking. Pick the boring option. Write less code. Ship sooner. Your architecture doesn't need to be interesting. Your product does.
*I'm Alex Mayhew, a solo developer on Cape Cod. I write about engineering decisions that prioritize shipping over impressing. Find me on [LinkedIn](https://www.linkedin.com/in/alexmmayhew) and [GitHub](https://github.com/LecoMV).*