스택 선택이 왜 중요한가
개발 스택은 서비스 개발 속도, 유지보수 비용, 확장 가능성을 모두 결정합니다. 잘못된 스택을 선택하면 나중에 전체를 다시 만들어야 하는 상황이 생기기도 합니다.
그러나 반대로, 스택 선택에 너무 많은 시간을 쓰는 것도 문제입니다. 초기에는 완벽한 선택보다 빠른 출시가 더 중요하고, 스케일링 문제는 대부분 "트래픽이 생긴 후의 행복한 고민"입니다.
2026년 주요 프론트엔드 프레임워크 비교
Next.js
현재 가장 넓리 사용되는 React 기반 풀스택 프레임워크입니다. SSR, SSG, ISR을 모두 지원하며 Vercel과의 연동이 완벽합니다. 생태계가 크고 레퍼런스가 많아 처음 시작하는 사람에게도 적합합니다.
적합한 경우: SEO가 중요한 서비스, 풀스택 개발자 한 명이 운영하는 프로젝트, 빠른 프로토타이핑
Remix
Facebook의 React Router 팀이 만든 풀스택 프레임워크입니다. 웹 표준(Form, URL 기반 데이터 로딩)에 충실하고 중첩 라우팅이 강력합니다. Next.js보다 철학이 명확하지만 생태계는 상대적으로 작습니다.
적합한 경우: 복잡한 폼이 많은 서비스, 웹 표준을 중시하는 팀, 진보적인 기술 선택을 원하는 경우
SvelteKit
Svelte 기반의 풀스택 프레임워크입니다. 번들 크기가 작고 성능이 뛰어납니다. 런타임 가상 DOM이 없어 초기 로딩 속도가 빠릅니다. 단, React 경험이 없는 개발자에게는 진입 장벽이 낮을 수 있지만, React 생태계의 풍부한 라이브러리를 사용할 수 없습니다.
적합한 경우: 성능이 매우 중요한 서비스, Svelte 경험이 있는 팀
결론: 사이드 프로젝트에는 Next.js가 기본 선택입니다. 레퍼런스가 가장 많고, 배포 파이프라인이 단순하며, 커뮤니티에서 도움을 받기 쉽습니다.
백엔드 선택 기준
Node.js (TypeScript)
Next.js를 사용한다면 백엔드도 TypeScript/Node.js로 통일하는 것이 좋습니다. 언어를 하나로 통일하면 코드 재사용이 가능하고 맥락 전환 비용이 줄어듭니다. Express, Fastify, Hono 등 다양한 프레임워크가 있습니다.
Python
데이터 처리나 AI/ML이 핵심인 서비스라면 Python이 유리합니다. FastAPI는 Python 백엔드 중 가장 빠르고 자동 API 문서 생성을 지원합니다. 단, 프론트엔드가 TypeScript라면 언어 스위칭 비용이 생깁니다.
Go
높은 동시성 처리가 필요하거나 바이너리 크기와 성능이 중요한 서비스에 적합합니다. 그러나 학습 곡선이 있고 사이드 프로젝트 수준에서 Go의 장점이 필요한 경우는 드뭅니다.
결론: 특별한 이유가 없다면 Node.js + TypeScript로 시작합니다.
데이터베이스 선택 가이드
PostgreSQL
관계형 데이터베이스의 표준입니다. 복잡한 쿼리, 트랜잭션, 외래 키 제약 등 엄격한 데이터 무결성이 필요한 서비스에 적합합니다. Supabase, Railway, Neon을 통해 무료로 호스팅할 수 있습니다.
대부분의 서비스에 권장
MySQL
PostgreSQL과 비슷하지만 PostgreSQL이 기능적으로 더 발전해 있습니다. 레거시 프로젝트나 PlanetScale을 사용할 때 선택합니다.
MongoDB
문서 기반 NoSQL 데이터베이스입니다. 스키마가 유동적이고 JSON 형태로 데이터를 저장합니다. 콘텐츠가 구조화되어 있지 않거나 빠른 프로토타이핑이 필요할 때 유용합니다. 단, 관계가 복잡한 데이터를 다루기 어렵고 트랜잭션 처리가 PostgreSQL보다 약합니다.
모노레포 vs 멀티레포
모노레포: 프론트엔드, 백엔드, 공유 라이브러리를 하나의 저장소에서 관리합니다. Turborepo나 Nx를 사용하면 빌드 캐싱과 의존성 관리가 편합니다. 팀이 여럿이거나 코드 공유가 많을 때 유리합니다.
멀티레포: 프로젝트마다 별도 저장소를 사용합니다. 단순하고 독립적으로 관리할 수 있습니다.
결론: 혼자 운영하는 사이드 프로젝트는 멀티레포로 단순하게 시작합니다. 복잡성을 초기부터 도입할 필요가 없습니다.
TypeScript 도입 여부
2026년 기준으로 TypeScript는 더 이상 선택이 아닙니다. 특히 프로젝트가 일정 규모 이상이 되면 타입 없이는 유지보수가 매우 어려워집니다.
초기에는 타입 에러로 인해 개발이 느리게 느껴질 수 있지만, 3개월 후에는 타입이 없을 때보다 훨씬 빠르게 개발할 수 있습니다. 자동완성, 리팩토링 안전성, 버그 조기 발견이 모두 TypeScript가 주는 혜택입니다.
인프라 비용 비교
| 서비스 | 무료 플랜 | 유료 시작 | 특징 |
|---|---|---|---|
| Vercel | 취미 프로젝트 무료 | $20/월 | Next.js에 최적화 |
| Railway | $5 크레딧 제공 | 사용량 기반 | 백엔드/DB 모두 가능 |
| Fly.io | 소형 VM 3개 무료 | 사용량 기반 | 글로벌 엣지 배포 |
| Supabase | 2개 프로젝트 무료 | $25/월 | DB+Auth+Storage |
| Neon | 0.5GB DB 무료 | $19/월 | Serverless PostgreSQL |
사이드 프로젝트는 초기 월 $0~$10으로 충분히 운영 가능합니다.
확장성을 고려한 아키텍처 선택
초기부터 마이크로서비스를 도입하는 것은 과도한 설계입니다. 모놀리스로 시작하고, 병목이 생기면 분리하는 것이 올바른 순서입니다.
확장성을 고려해두어야 할 사항은 단 두 가지입니다.
- 데이터베이스는 처음부터 제대로 설계합니다: 나중에 스키마를 바꾸는 것은 매우 고통스럽습니다.
- 환경변수로 설정을 관리합니다: 하드코딩된 URL, 키값은 나중에 반드시 문제가 됩니다.
이 두 가지만 지켜도 향후 스케일링 시 대부분의 문제를 피할 수 있습니다.