당신에겐 Next.js가 필요하지 않습니다 - 우리가 Next에서 React로 이관한 이유

1 week ago 8

ComfyDeploy 대시보드를 Next.js에서 React로 마이그레이션하여 얻은 결과:
- 빌드 시간이 3분 → 18초로 단축
- 핫 리로드가 200ms 이하로 개선됨
- 팀원들이 훨씬 더 만족스러워함
처음에 Next.js를 활용한 풀스택 애플리케이션으로 시작해서 Drizzle과 Server Actions 덕분에 타입 안정성과 깔끔한 코드로 잘 작동했으나, 다음과 같은 문제 발생:
- 특정 사용자로 인해 Vercel에서 $2,000의 높은 API 비용 발생
- API 테스트 복잡성 증가: Server Actions와 API 라우트가 혼합
- 느린 빌드 시간과 비효율적인 로컬 개발 환경
- 작은 변경에도 전체 SSR 리로드 발생
문제점
- Next.js의 복잡성 증가 : Next.js의 올인원(full-stack) 접근 방식이 앱 성장과 함께 개발 복잡성을 초래
- 우리 대시보드는 주로 React 기반이며, Next.js의 서버 기능이 필요하지 않음
Next.js에서 React로의 전환
- TanStack Router와 Rspack을 사용하여 Next.js에서 React로 전환
  - 개발 서버 시작: 2초 이내
  - Vercel 빌드 시간: 18초
- API 설정 개선, 불필요한 종속성 제거, 코드를 간소화하며 생산성 증가
성능 비교
- Next.js 15 (Turbo 모드 사용)
  - 첫 페이지 빌드: 10.4초
- React + TanStack Router + Rspack
  - 라우트 계산: 200ms 이하
  - 초기 번들 빌드: 1.67초
트레이드오프
- 잃은 것
  - 프론트엔드와 백엔드 코드의 Co-location : 프론트엔드와 백엔드를 분리하면서 경계가 명확해짐
  - Next.js의 캐싱 기능 : 실시간 업데이트 데이터가 많아 맞춤 캐싱으로 대체
  - 사전 렌더링 및 초기 로드 : Static Generation 대신 더 나은 UX 구현 - 더 이상 비활성 버튼 표시 없음
  - 서버 컴포넌트 및 액션 : 서버 컴포넌트의 "마법"을 잃었지만, 더 의도적인 API 설계로 개선
- 얻은 것
  - API 계약 설계 강화
  - 필요한 곳에서만 캐싱 구현
  - 데이터 흐름과 상태 관리를 신중히 설계
결론
- Next.js는 랜딩 페이지와 SEO 같은 작업에는 적합하지만, 대부분의 제품에는 과도한 복잡성을 초래함
- 랜딩 페이지와 SEO 작업에는 여전히 Next.js를 사용
- 대시보드는 Pure React + TanStack Router + Rspack로 전환
- API는 Python FastAPI 서버를 Google Cloud Run에서 실행하며 필요에 따라 자동으로 확장
적합한 도구 선택이 중요하며, 우리에게는 Next.js가 과도한 선택이었음