구상은 내가 함.
AI 정리 버전
가볍고 단순한 SPA 기반 실제 서비스 보일러플레이트
Common
+ TypeScript
+ tRPC
+ Zod
+ Vite
+ NPM Workspaces
FE
+ React
+ TanStack Query
+ TanStack Router
+ shadcn/ui
+ Tailwind CSS
BE
+ Fastify
+ Kysely
+ pg-boss
+ Better Auth
+ Pino
Infra
+ PostgreSQL
+ Docker
+ Caddy
apps/
web/ # Vite React SPA
api/ # Fastify API server
worker/ # pg-boss worker
packages/
schemas/ # Zod schemas
trpc/ # shared AppRouter types/client helpers
db/ # Kysely types/migrations
ui/ # shared shadcn/ui components optional
Caddy
├─ /trpc/* → Fastify API
├─ /api/auth/* → Fastify API
└─ /* → React 정적 파일
React는 Vite로 build 후 정적 파일로 서빙합니다. Vite는 백엔드 통합 시 개발 서버 proxy/origin 구성을 안내하고, 운영에서는 빌드 결과물을 백엔드나 웹서버가 서빙하는 방식이 일반적입니다. (vitejs)
+ 구조가 단순함
+ 컨테이너 수 적음
+ Fastify가 API와 정적 파일 서빙 모두 가능
+ TanStack Router로 앱 라우팅 명확
+ tRPC + Zod로 내부 API 타입 안전성 확보
+ pg-boss로 PostgreSQL 기반 task queue 처리 가능
- SEO 약함
- SSR/SSG 없음
- 공개 랜딩/블로그/문서 SEO는 별도 대응 필요
- 첫 HTML은 대체로 빈 앱 shell에 가까움
순수 React 버전에서 SEO를 어느 정도 챙기려면 다음 정도가 현실적입니다.
1. /, /pricing, /docs 같은 공개 페이지를 정적 HTML로 별도 작성
2. React SPA는 /app 하위에 배치
3. sitemap.xml, robots.txt, meta tag는 직접 관리
4. 강한 SEO가 필요하면 Next 버전으로 이동
즉, 순수 React 버전은 이런 서비스에 적합합니다.
내부 도구
관리자 페이지
SaaS 대시보드
로그인 후 기능 중심 앱
SEO가 핵심이 아닌 서비스
SEO/SSR/SSG가 필요한 실제 서비스 보일러플레이트
Common
+ TypeScript
+ tRPC
+ Zod
+ NPM Workspaces
FE
+ Next.js
+ React
+ TanStack Query
+ shadcn/ui
+ Tailwind CSS
BE
+ Fastify
+ Kysely
+ pg-boss
+ Better Auth
+ Pino
Infra
+ PostgreSQL
+ Docker
+ Caddy
삭제되는 것:
Next가 빌드 시스템과 라우터 역할을 가져갑니다.
apps/
web/ # Next.js
api/ # Fastify API server
worker/ # pg-boss worker
packages/
schemas/ # Zod schemas
trpc/ # shared AppRouter types/client helpers
db/ # Kysely types/migrations
ui/ # shared shadcn/ui components optional
Caddy
├─ /trpc/* → Fastify API
├─ /api/auth/* → Fastify API
└─ /* → Next.js web
Next는 self-hosting을 지원하며, Node.js 서버, Docker image, static export 방식으로 배포할 수 있습니다. Docker 배포도 공식적으로 지원됩니다. (Next.js)
Next = FE / SEO / SSR / SSG
Fastify = API / Auth / tRPC
Worker = background jobs
PostgreSQL = app data + queue
Next의 API Route나 Server Action을 메인 백엔드로 쓰지 않는 게 좋습니다.
피할 구조:
Next API 일부
Fastify API 일부
Next auth 일부
Fastify auth 일부
권장 구조:
+ SEO 좋음
+ 공개 페이지 SSG/SSR 가능
+ 랜딩/가격/문서/블로그에 적합
+ React 기반 유지
+ 별도 Astro 불필요
+ FE 라우팅/빌드/SEO 메타 관리가 통합됨
- 순수 React/Vite보다 무거움
- web 컨테이너가 별도로 필요함
- Next와 Fastify 역할 경계를 잘 지켜야 함
- TanStack Router는 사실상 제거됨
Next 공개 페이지
+ /
+ /pricing
+ /features
+ /docs
+ /blog
+ /legal
+ /changelog
Next 로그인 앱
+ /app
+ /app/projects
+ /app/settings
+ /app/jobs
Fastify
+ /trpc/*
+ /api/auth/*
| 항목 |
순수 React 버전 |
Next 버전 |
| FE 빌드 |
Vite |
Next |
| 라우팅 |
TanStack Router |
Next App Router |
| SEO |
약함 |
좋음 |
| SSR/SSG |
직접 구현 필요 |
기본 지원 |
| 배포 |
정적 파일 + Fastify/Caddy |
Next Node server + Fastify |
| 구조 단순성 |
더 단순 |
약간 복잡 |
| 대시보드 앱 |
좋음 |
좋음 |
| 랜딩/블로그/문서 |
약함 |
좋음 |
| 컨테이너 |
web 정적 서빙 가능 |
web Node 컨테이너 권장 |
| 추천 용도 |
내부 앱, MVP, 도구형 SaaS |
공개 서비스, SEO 필요 SaaS |
containers
├─ caddy
├─ api
├─ worker
└─ postgres
React build 결과는 Caddy나 Fastify가 정적으로 서빙.
containers
├─ caddy
├─ web # Next.js
├─ api # Fastify
├─ worker # pg-boss
└─ postgres
Next 때문에 컨테이너가 하나 늘어납니다. 이 정도가 배포 복잡도의 핵심 차이입니다.
선택 이유:
더 단순함
더 가벼움
보일러플레이트 만들기 쉬움
Fastify 중심 구조가 깔끔함
선택 이유:
랜딩/문서/블로그/가격 페이지에 유리함
SSR/SSG 직접 구현 안 해도 됨
React 기반 유지 가능
Astro 없이 해결 가능
당신 목적이:
최소한의 실제 서비스를 위한 보일러플레이트
다목적 서버
API 서버
DB 기반 Task Queue
FE 존재
나중에 공개 서비스 가능성 있음
이면 Next 버전이 더 범용적입니다.
단, 아키텍처는 이렇게 고정하는 게 좋습니다.
Next = Frontend only
Fastify = Backend only
Worker = Jobs only
PostgreSQL = Data + Queue
Caddy = Routing/TLS
반대로 “내부 도구나 대시보드 중심”이면 순수 React 버전이 더 낫습니다.
일단 React 쓰고, Next는 공부하면서 업그레이드하거나 하기.