어떤 프로젝트에 Next.js가 필요할까? React + Vite로 충분한 이유
들어가며
회사에서 백오피스 프로젝트를 리팩토링하는 중에 기술 스택을 정해야 하는 시점이 왔다. React를 쓴다는 건 확정이었고, 문제는 Next.js를 쓸 것인가, Vite를 쓸 것인가였다.
요즘은 React 프로젝트를 시작한다고 하면 거의 반사적으로 Next.js를 떠올리는 분위기가 있다. 공식 문서에서도 프레임워크 사용을 권장하고 있고, 커뮤니티에서도 Next.js가 사실상 표준처럼 여겨지는 느낌이다.
하지만 "많이 쓰니까"라는 이유만으로 기술을 선택하면, 나중에 불필요한 복잡도를 떠안게 되는 경우가 꽤 있다. 우리 프로젝트 상황을 하나씩 따져본 결과, React + Vite 조합이 훨씬 합리적이라는 결론에 도달했다.
그 판단 과정을 정리해본다.
우리 프로젝트의 상황
먼저 프로젝트의 조건부터 짚고 가자.
백오피스(어드민) 프로젝트다. 외부 사용자가 아닌, 내부 직원들만 로그인해서 사용하는 도구.
자체 인프라 서버가 이미 구축되어 있다. API 서버도, 배포 환경도 자체적으로 갖추고 있는 상태.
MFE(Micro Frontend) 아키텍처를 채택하고 있다. 여러 프론트엔드 모듈이 독립적으로 빌드·배포되는 구조.
이 세 가지 조건이 기술 스택 선택에 결정적인 영향을 줬다.
Next.js가 강력한 순간
Next.js를 선택하지 않았다고 해서, Next.js가 나쁜 도구라는 얘기가 아니다. Next.js는 분명히 강력한 프레임워크고, 제대로 빛을 발하는 상황이 있다.
SSR/SSG가 필요한 경우 — 블로그, 커머스, 마케팅 랜딩 페이지처럼 검색 엔진에 노출되어야 하고, 초기 로딩 속도가 사용자 이탈에 직접적인 영향을 주는 서비스에서 Next.js의 서버 사이드 렌더링은 확실한 이점이 있다.
별도 백엔드 없이 빠르게 만들고 싶을 때 — Next.js의 API Routes를 활용하면 프론트와 백엔드를 한 프로젝트에서 관리할 수 있다. 사이드 프로젝트나 MVP를 빠르게 만들어야 할 때 이건 꽤 매력적이다.
서버 컴포넌트의 이점을 누릴 수 있는 경우 — 데이터 페칭이 복잡하고, 클라이언트에 내려보내는 JS 번들 크기를 줄여야 하는 대규모 서비스에서는 React Server Components가 의미 있는 선택지가 된다.
핵심은 이런 이점들이 우리 프로젝트에도 해당되느냐는 것이다.
백오피스에서 Next.js가 과한 이유
SEO가 필요 없다
백오피스는 로그인한 사람만 접근하는 내부 도구다. 구글에 노출될 필요가 전혀 없다. SSR의 가장 큰 존재 이유 중 하나가 사라지는 셈이다.
초기 로딩 속도가 크리티컬하지 않다
일반 사용자 대상 서비스라면 첫 화면이 0.5초만 늦어도 이탈률이 올라간다. 하지만 백오피스 사용자는 업무를 하러 들어온 사람들이다. SPA의 초기 로딩이 조금 더 걸리더라도, 그게 서비스 이탈로 이어지지 않는다. 오히려 한 번 로드된 이후의 화면 전환 속도와 인터랙션 반응성이 더 중요하다.
자체 서버가 이미 있다
Next.js에는 API Routes라는 기능이 있다. 간단히 말하면, 프론트엔드 프로젝트 안에서 백엔드 API를 같이 만들 수 있는 기능이다. 예를 들어 /api/users라는 엔드포인트를 Next.js 프로젝트 내부에 파일 하나 만드는 것만으로 생성할 수 있다. 별도 백엔드 서버 없이 프론트 하나로 풀스택을 구성할 수 있다는 게 핵심이다.
이게 유용한 상황은 명확하다. 사이드 프로젝트를 혼자 빠르게 만들 때, 또는 MVP 단계에서 백엔드 개발자 없이 프론트 개발자가 간단한 API까지 처리해야 할 때. 이런 경우에는 확실히 편하다.
하지만 우리처럼 이미 자체 API 서버가 구축되어 있는 환경에서는 이야기가 다르다. 백엔드 팀이 관리하는 API 서버가 이미 돌아가고 있는데, 여기에 Next.js의 API Routes까지 사용하면 API가 두 군데에 나뉘게 된다. "이 API는 백엔드 서버에 있고, 저 API는 Next.js 쪽에 있고" — 이런 상황이 되면 어디서 뭘 관리하는지 혼란스러워지고, 디버깅할 때도 양쪽을 다 확인해야 한다. 쓰지 않으면 그만인 기능이지만, 프레임워크에 포함되어 있다는 것 자체가 팀원들에게 "이것도 쓸 수 있는 건가?"라는 혼선을 줄 수 있다.
결국 이미 잘 돌아가는 백엔드가 있는데 Next.js의 서버 기능까지 얹는 건, 쓰지도 않을 엔진을 하나 더 달아놓는 것과 비슷하다. 무겁기만 하고 실질적인 이득이 없다.
배포 복잡도가 올라간다
여기서 한 가지 짚고 넘어갈 게 있다. "React + Vite도 JavaScript고, Next.js도 JavaScript인데, 왜 Next.js만 Node.js 런타임이 필요하다는 거지?"라는 의문이 들 수 있다. 둘 다 JS인 건 맞는데, 그 JS가 어디에서 실행되느냐가 다르다.
React + Vite로 만든 SPA는 빌드하면 HTML, JS, CSS 파일이 나온다. 이 파일들은 사용자의 브라우저에서 실행된다. 서버는 이 파일들을 그냥 "여기 있으니까 가져가"하고 넘겨주기만 하면 된다. 마치 이미지 파일을 서빙하는 것과 본질적으로 같다. 그래서 Nginx 같은 정적 파일 서버만 있으면 충분하고, 서버 쪽에서 JavaScript를 해석하거나 실행할 일이 없다.
반면 Next.js의 SSR은 서버에서 JavaScript를 실행해야 한다. 사용자가 페이지를 요청하면, 서버가 React 컴포넌트를 직접 실행해서 HTML을 만들어낸 다음 그 결과물을 사용자에게 보내는 구조다. 서버에서 JS를 실행하려면 당연히 그 JS를 이해하고 돌릴 수 있는 환경, 즉 Node.js 런타임이 서버에 깔려 있어야 한다.
정리하면 이렇다.
React + Vite: JS가 브라우저에서 실행됨 → 서버는 파일만 전달 → 정적 파일 서버면 충분
Next.js (SSR): JS가 서버에서도 실행됨 → 서버에 Node.js 런타임 필요 → 서버 프로세스 관리 필요
Node.js 런타임이 서버에 필요하다는 건 단순히 "Node.js를 설치한다"로 끝나는 게 아니다. 서버 프로세스가 죽으면 재시작해야 하고, 메모리 관리도 해야 하고, 트래픽이 몰리면 스케일링도 고려해야 한다. 정적 파일 서빙은 이런 걱정이 거의 없다. 파일이 그냥 거기 있으니까.
우리처럼 자체 인프라에서 운영하는 백오피스 프로젝트에 이런 서버 관리 부담까지 얹을 이유가 없었다.
React + Vite가 적합한 이유
반대로 React + Vite 조합은 우리 상황에 딱 맞았다.
빌드 결과물이 단순하다
Vite로 빌드하면 결과물은 HTML, JS, CSS 정적 파일이 전부다. 이걸 자체 서버에서 그대로 서빙하면 끝이다. 배포 파이프라인이 단순해지고, 서버 사이드 런타임을 신경 쓸 필요가 없다.
MFE 구조와 잘 맞는다
각 마이크로 프론트엔드 모듈을 독립적으로 빌드하고 배포해야 하는 상황에서, Vite 기반 SPA는 모듈 간 경계가 깔끔하다. 각 모듈이 독립된 정적 파일 세트로 나오니까, 빌드와 배포를 모듈 단위로 자유롭게 가져갈 수 있다.
개발 경험이 빠르고 가볍다
Vite의 개발 서버 기동 속도는 체감이 확 될 정도로 빠르다. HMR(Hot Module Replacement)도 거의 즉각적이라 개발 사이클이 짧아진다. 프로젝트 규모가 커져도 이 빠릿함이 크게 떨어지지 않는다는 점도 장점이다.
학습 비용이 낮다
Next.js는 프레임워크인 만큼 고유한 컨벤션과 개념이 많다. App Router, Server Components, 서버 액션, 라우팅 규칙 등 Next.js만의 학습 범위가 꽤 넓다. 반면 Vite는 빌드 도구일 뿐이라, React 자체에 집중할 수 있다. 팀원 온보딩 관점에서도 진입 장벽이 낮다.
정리
판단 기준 | Next.js | React + Vite |
|---|---|---|
SEO 필요 여부 | SEO가 중요한 서비스에 적합 | SEO 불필요한 내부 도구에 적합 |
서버 인프라 | 자체 서버가 없을 때 유용 | 자체 서버가 있으면 오히려 깔끔 |
배포 방식 | Node.js 런타임 필요 | 정적 파일만 서빙하면 끝 |
MFE 호환성 | 가능은 하지만 설정이 복잡 | 모듈별 독립 빌드·배포에 유리 |
개발 속도 | 기능은 많지만 무겁다 | 가볍고 빠르다 |
기술 선택에서 중요한 건 "이 기술이 요즘 핫한가"가 아니라 "우리 프로젝트 상황에서 이 기술의 장점이 실제로 발휘되는가"다.
Next.js가 제공하는 SSR, 서버 기능, 최적화 기능들은 분명 강력하다. 하지만 그 강점이 발휘되지 않는 환경에서는 그냥 복잡도만 올리는 짐이 된다. 백오피스 + 자체 인프라 + MFE 구조라는 우리 조건에서는, React + Vite가 더 실용적인 선택이었다.
도구는 상황에 맞게 고르는 거지, 좋은 도구를 무조건 가져다 쓰는 게 아니다.
참고 자료
Next.js 공식 문서 - Server-side Rendering — Next.js SSR의 동작 방식과 getServerSideProps 사용법
Next.js 공식 문서 - Edge and Node.js Runtimes — Next.js에서 사용하는 Node.js 런타임과 Edge 런타임의 차이
Vite 공식 문서 - Getting Started — Vite의 핵심 개념과 빌드 도구로서의 역할
Vite 공식 문서 - Building for Production — Vite의 프로덕션 빌드 과정과 정적 파일 출력 방식
Vite 공식 문서 - Deploying a Static Site — Vite로 빌드된 정적 사이트 배포 가이드