5배 빨라진 프론트엔드 빌드 시간: Next.js에서 Vite + TanStack Start로 전환하기
Railway의 프론트엔드(대시보드, 문서, 마케팅 페이지 포함)는 각 빌드가 10분을 넘게 소요될 정도로 성장했다. 주요 문제점은 다음과 같다:
- 느린 빌드 속도: CI/CD 파이프라인을 지연시키며 개발자 생산성을 저하시켰다.
- App Router 호환성 문제: Next.js는 서버 중심 아키텍처에 기반하지만, Railway 제품은 클라이언트 중심이다.
- 복잡한 설정: 표준 블로그 호스팅 수준을 넘어선 커스텀 인프라 구조가 필요했다.
- 큰 번들 크기와 차가운 시작 시간: 서버 사이드 렌더링 성능에 부정적 영향을 미쳤다.
이러한 제약은 자주 배포되는 프로덕션 시스템에서는 더욱 치명적이 된다.
전환 결과
Vite + TanStack Start로 전환하면서 빌드 속도가 5배 이상 향상되어, 이제는 2분 이내에 완료된다. 팀은 하루에 수시간을 절약하며 개발 속도가 직접적으로 증가했다.
이 발표는 해커뉴스에서 206점의 평점을 받으며 188개의 댓글이 달렸다. 일부 비판자는 문제의 근본 원인이 프레임워크가 아니라 아키텍처에 있다고 주장했지만, 실제 사례를 통해 Railway의 전환이 자신의 스택에 적합함을 입증했다.
Next.js에서 벗어나는 트렌드
Railway은 대규모 프로젝트에서 늘어나는 전환 추세에 동참하고 있다:
- 켄트 C. 도드스: Next.js에서 Remix로 전환 (후에 React Router 7에 통합됨).
- 대규모 전환: 많은 프로젝트들이 더 빠른 빌드를 위해 Vite + React 또는 SvelteKit을 선택하고 있다.
Next.js는 Vercel 배포 및 일반적인 패턴에 최적화되어 있지만, 커스텀 인프라를 갖춘 대규모 클라이언트 중심 앱에서는 복잡한 설정과 거대한 번들 크기가 SSR/SSG의 장점보다 더 큰 부담이 된다.
| 지표 | Next.js | Vite + TanStack Start |
|------|---------|------------------------|
| 빌드 시간 | 10분 이상 | 2분 미만 |
| 아키텍처 | 서버 중심 | 클라이언트 중심 |
| 인프라 유연성 | 낮음 | 높음 |
언제 전환이 타당할까?
Next.js는 여전히 가장 인기 있는 리액트 프레임워크지만, 확장성은 그 한계를 드러낸다:
- 빌드 시간이 몇 분 이상이라면, 그대로 유지하는 것이 좋다.
- 빌드 시간이 10분을 넘고 자주 배포한다면, 다른 옵션을 테스트해 보라.
- 개발자 경험(DX)을 평가하라: App Router 같은 핵심 기능을 사용하지 않는다면, 당신의 스택은 이미 오래된 상태일 수 있다.
Vite는 벤더 로킹 없이 즉각적인 HMR와 빛처럼 빠른 빌드를 제공한다. TanStack Start는 추가적인 오버헤드 없이 라우팅과 상태 관리를 지원한다.
핵심 교훈
- 5배 빠른 빌드: 고속 개발 팀에게 실질적인 CI/CD 시간 절감.
- 클라이언트 중심 설계: 대시보드와 인터랙티브 제품에 더 잘 맞는 아키텍처.
- 확장성 트렌드: Vercel 외 환경에서는 Next.js의 우위가 줄어들고 있다.
- 균형 잡힌 판단: 빌드 시간이나 인프라가 병목이라면 전환이 가치 있다.
- 실제 데이터로 검증하라: 허황된 열풍을 따라가기 전에 메트릭을 먼저 확인하라.
중급 이상 개발자들에게 이는 경고 신호다: 빌드 시간을 모니터링하고, 프레임워크가 프로젝트 아키텍처와 일치하는지 확인하라. Railway의 사례는 기술 스택 최적화가 바로 생산성 향상으로 이어진다는 것을 보여준다.
— Editorial Team
아직 댓글이 없습니다.