Railway가 Next.js를 걷어냈더니 빌드 시간이 10분에서 2분 이하로 줄었다는 이야기

무슨 일이 있었나요?

クラウド 배포 플랫폼으로 유명한 Railway가 자사 프론트엔드를 Next.js에서 다른 스택으로 전면 마이그레이션했어요. 그 결과 빌드 시간이 10분 이상에서 2분 이하로 대폭 줄었다고 공식 블로그를 통해 밝혔는데요. Next.js가 사실상 React 프론트엔드의 표준처럼 자리 잡은 지금, 꽤 파격적인 선택이라 주목할 만해요.

Railway는 개발자들이 앱을 쉽게 배포할 수 있게 해주는 PaaS(Platform as a Service) 서비스예요. Heroku의 현대적인 대안이라고 생각하시면 돼요. 이런 서비스의 프론트엔드, 그러니까 사용자가 실제로 접하는 대시보드와 관리 화면을 담당하는 코드가 Next.js 위에서 돌아가고 있었는데, 이걸 통째로 바꾼 거예요.

왜 Next.js를 떠났나요?

Railway 팀이 꼽은 핵심 문제는 빌드 성능과 개발 경험(DX)이었어요.

빌드 시간이 10분이 넘는다는 건 실무에서 생각보다 큰 문제거든요. 코드 한 줄 고치고 배포할 때마다 10분씩 기다려야 한다면, 하루에 배포를 여러 번 하는 팀 입장에서는 그 대기 시간이 누적되면서 엄청난 생산성 손실이 돼요. 핫픽스를 빨리 내보내야 하는 상황에서 10분 빌드는 정말 답답하죠.

개발 서버(dev server) 경험도 문제였어요. Next.js의 개발 서버가 프로젝트 규모가 커지면서 점점 느려졌다고 해요. 페이지 하나 수정하고 브라우저에서 반영되는 걸 확인하는 데 걸리는 시간, 이른바 HMR(Hot Module Replacement) 속도가 체감될 정도로 느려진 거예요. HMR이 뭐냐면, 코드를 수정하면 브라우저를 새로고침하지 않아도 변경된 부분만 실시간으로 반영해주는 기능이에요. 이게 느리면 개발할 때 흐름이 끊기거든요.

Next.js의 서버 사이드 렌더링(SSR) 기능도 Railway의 유스케이스에는 과한 면이 있었어요. SSR은 서버에서 HTML을 미리 만들어서 보내주는 방식인데, SEO(검색 엔진 최적화)가 중요한 마케팅 사이트나 콘텐츠 사이트에는 필수적이에요. 하지만 Railway의 대시보드는 로그인한 사용자만 쓰는 앱이잖아요. 검색 엔진이 크롤링할 필요가 없는 페이지인데 SSR의 복잡성을 감당하고 있었던 거예요. 배보다 배꼽이 더 큰 상황이었다고 볼 수 있어요.

어떤 스택으로 갈아탔나요?

Railway는 Vite 기반의 SPA(Single Page Application) 구조로 전환했어요. Vite가 뭐냐면, 프랑스어로 "빠르다"는 뜻인데, 이름값을 하는 차세대 프론트엔드 빌드 도구예요. Vue.js를 만든 Evan You가 개발했고, 지금은 React, Svelte 등 거의 모든 프레임워크와 함께 쓸 수 있어요.

Vite가 빠른 이유가 있어요. 기존 빌드 도구들(webpack 등)은 모든 파일을 하나로 묶는(번들링) 과정을 거치는데, Vite는 개발 모드에서 이 과정을 건너뛰고 브라우저의 네이티브 ES 모듈 기능을 직접 활용해요. 쉽게 말해서, 기존 방식이 도서관의 모든 책을 하나의 거대한 PDF로 합치는 거라면, Vite는 필요한 책만 그때그때 가져다 읽는 방식이에요. 당연히 훨씬 빠르죠.

라우팅 쪽에서는 React Router를 사용하는 것으로 전환했어요. Next.js의 파일 기반 라우팅 대신, 코드에서 직접 라우트를 정의하는 방식이에요. 이 부분은 취향의 영역이기도 한데, Railway 팀은 명시적인 라우트 정의가 대규모 앱에서 더 관리하기 쉽다고 판단한 거예요.

결과적으로 빌드 시간이 10분 이상에서 2분 이하로 줄었고, 개발 서버 시작 시간도 극적으로 빨라졌어요. 프로덕션 번들 사이즈도 줄어들었고요.

이게 "Next.js가 나쁘다"는 뜻일까요?

꼭 그런 건 아니에요. 이 이야기의 핵심은 도구 선택이 유스케이스에 맞아야 한다는 거예요.

Next.js는 여전히 훌륭한 프레임워크예요. 마케팅 사이트, 이커머스, 콘텐츠 중심 서비스처럼 SEO가 중요하고 첫 로딩 속도가 비즈니스에 직결되는 경우에는 SSR이 큰 장점이에요. 하지만 Railway처럼 인증된 사용자만 쓰는 대시보드 앱, 그러니까 SPA로 충분한 경우에는 SSR 프레임워크가 오히려 불필요한 복잡성과 빌드 비용을 추가하는 셈이 되는 거죠.

비슷한 흐름이 업계에서 점점 보이고 있어요. Kent C. Dodds는 Remix(현재 React Router로 통합)를 만들면서 "SSR이 필요 없는 앱에 SSR 프레임워크를 쓰지 마세요"라는 메시지를 꾸준히 전하고 있고, Shopify도 일부 내부 도구를 Next.js에서 Vite 기반 SPA로 옮겼다는 사례가 알려져 있어요. "프레임워크 피로감(Framework Fatigue)"이라는 표현이 다시 돌고 있는 이유이기도 해요.

반면에 Vercel(Next.js를 만든 회사) 쪽에서는 Turbopack이라는 새로운 번들러를 개발하면서 빌드 성능 문제를 해결하려고 하고 있어요. Next.js 15 이후로 Turbopack 지원이 강화되고 있으니, 이 쪽의 개선도 지켜볼 필요가 있어요.

한국 개발자에게 주는 시사점

한국에서도 Next.js는 프론트엔드 프로젝트의 기본 선택지처럼 쓰이고 있잖아요. 채용 공고에서도 Next.js 경험을 요구하는 곳이 정말 많고요. 그래서 이런 사례가 더 의미 있어요.

만약 지금 만들고 있는 서비스가 관리자 대시보드, 내부 도구, B2B SaaS의 로그인 후 화면처럼 SEO가 필요 없는 앱이라면, Next.js가 정말 최선인지 한번 생각해볼 가치가 있어요. Vite + React Router 조합은 설정도 단순하고, 빌드가 빠르고, 배포도 정적 파일 호스팅만으로 가능해서 인프라 비용도 줄일 수 있거든요.

물론 이미 Next.js로 잘 운영되고 있는 프로젝트를 굳이 마이그레이션할 필요는 없어요. Railway도 이 결정을 오랜 기간 고민한 끝에 내렸을 거예요. 중요한 건 "Next.js를 써야 하니까 쓴다"가 아니라, 프로젝트의 특성에 맞는 도구를 선택하는 습관이에요.

새 프로젝트를 시작한다면, 잠깐 멈추고 물어보세요. "이 앱에 SSR이 진짜 필요한가?" 이 질문 하나만으로도 아키텍처 결정이 완전히 달라질 수 있어요.

정리하면

Railway의 사례는 "유행하는 프레임워크를 따르지 말고, 문제에 맞는 도구를 고르자"는 단순하지만 중요한 교훈을 보여줘요. 여러분의 프로젝트에서는 프레임워크 선택이 빌드 시간이나 개발 경험에 병목이 되고 있진 않나요? 혹시 SSR이 필요 없는 앱에서 Next.js를 쓰고 계시다면, 어떤 점이 불편하거나 반대로 만족스러우신지 경험을 공유해주세요.