당신은 Next.js가 필요하지 않다

최근 화제가 된 글. 당신은 Next.js가 필요하지 않다에 관한 내용에 대해 정리해 보았다

 

일하다 보면 이게 굳이 필요한 일인가 싶기도 하고 만들 수야 있다만 생산성과 개발 비용과 기간대비 아웃풋에 큰 차이가 없다고 생각해서 개인적으로도 그냥 React로 돌아가는 경우가 많았는데

 

여기서는 Next.js를 운영하면서 어려웠던 점이나 한계에 대해 직면하고 돌아가는 과정을 보여준다

 

예전 제이쿼리가 대세일 때 이슈가 되었던 You might not need jquery 가 생각나는 글

 

기술이라는 게 적시적소에 잘 쓰면 좋지만 만능론으로 넣어야 하는지 말아야 하는지를 판단하는 기준이 되어야 한다

 

 

You don't need Next.js

 

---

1. 서버 자원의 한계 vs. 독립 서버의 필요성

1) Vercel 서버리스 함수 한계

• Next.js에서 서버 액션(서버리스 함수)으로 API를 구성하면, Vercel의 무료/유료 플랜 제약에 쉽게 부딪힐 수 있음
• GPU가 필요한 연산(예: 머신러닝 모델 추론)이나 대규모 요청이 잦은 서비스라면 서버리스 함수로는 처리 어려움
• 실제 사례: ComfyDeploy가 고부하 API 요청을 받았을 때, 예기치 못한 2,000달러 이상의 Vercel 청구서 발생

2) 독립 서버(오토스케일링) 도입

• GPU 기반 연산이 필요한 경우, 자체 서버(혹은 GCP/AWS 등 클라우드 VM)에서 원하는 만큼 자유롭게 확장 가능
• 컨테이너 기반(예: Docker + Kubernetes, Cloud Run 등)으로 효율적 오토스케일링 구현 가능

결론: GPU 자원이 필요하거나 높은 부하의 API가 있는 경우, Next.js의 서버리스 함수보다는 독립 서버가 낫다.

---

2. 빌드 및 로컬 개발 환경의 비효율성

1) 장시간 빌드 문제

• 프로젝트 규모가 커지면 Next.js 빌드 시간이 기하급수적으로 늘어날 수 있음
• 예: 라이브러리가 많아지자 빌드가 3분, 심지어 7분 이상 걸린 사례 발생

2) 느린 로컬 개발 & SSR 리로드

• 변경 사항이 있을 때마다 SSR(서버사이드 렌더링) 과정을 다시 거치면, 브라우저가 새로고침되어 피드백이 느려짐
• 대시보드처럼 클라이언트 로직이 많은 경우, SSR 자체가 크게 필요 없을 수 있음
• 순수 React(CSR) 방식이면 훨씬 빠른 핫 리로드가 가능

결론: 대규모·복잡한 Next.js 프로젝트는 느린 빌드와 로컬 개발 환경이 생산성을 크게 떨어뜨릴 수 있다.

---

3. 대시보드 등 “SSR 불필요”한 UI

1) SSR/SSG 필요성이 낮음

• 대시보드는 로그인 사용자 전용 화면이고, SEO도 큰 의미가 없는 경우가 많음
• 실시간 업데이트나 잦은 API 호출이 필요하면, 초기 프리렌더보다 클라이언트 상태 관리가 더 중요

2) Next.js 최적화 로직 = 오버헤드

• SSR/SSG, Server Actions, 라우팅 최적화 등은 대부분 SEO, 초기 페이지 로드 속도를 위한 기능
• 대시보드 같은 “로그인 후 사용하는 내부 UI”에서는 오히려 복잡도와 빌드 시간이 늘어나는 원인

결론: 브라우저 측에서 전부 처리해도 충분한 UI(로그인 기반 대시보드 등)에는 Next.js가 필수적이지 않을 수 있다.

---

4. API 테스트 및 아키텍처 분산의 이점

1) 서버 액션 + API 라우트 혼합 시 테스트 복잡

• Next.js 내부에서 서버 액션과 API 라우트가 뒤섞여 있으면, 테스트 범위와 방식이 혼란스러워짐
• 서버 액션이 “마법처럼” 편해 보여도, 대규모 서비스에서 API 테스트·유지보수 난이도가 상승

2) 명시적 API 계층

• Frontend는 React, Backend는 FastAPI/Express 등 독립 서버로 분리하면 경계가 명확
• API 문서화, 버저닝, 로드 밸런싱, 확장성 측면에서 더 유연

결론: “서버 액션”으로 모든 것을 처리하기보다는, 명확히 분리된 API 서버 구조가 대규모·장기적 관점에서 더 나을 수 있다.

---

5. “프레임워크 마법”에 덜 의존할 때의 장점

1) 진짜 필요한 곳에만 최적화

• Next.js의 내장 캐싱, 서버 컴포넌트 등은 매우 편리하지만, 모든 프로젝트가 모든 기능을 필요한 것은 아님
• 필요한 기능만 직접 선택·설계하면 성능 최적화와 유지보수 측면에서 오히려 강점

2) 데이터 흐름 & 상태관리 명확성

• Next.js SSR/SSG + 클라이언트 사이드 로직이 섞이면 데이터 흐름 파악이 어려워짐
• 오히려 클라이언트 렌더링(CSR)으로 일관되게 처리하면, React/TanStack Query 등에서 상태관리를 일관성 있게 적용 가능

결론: 프레임워크가 제공하는 다양한 기능(SSR, SSG, 서버 액션 등)은 편리하지만, 남용하면 구조가 복잡해짐.
필요한 부분만 직접 설계·구현하면 오히려 더 단순하고 효율적인 구조를 만들 수 있다.

---

6. 트레이드오프: “잃는 것”과 “얻는 것”

잃는 것

1. 프론트·백엔드 동시 관리
   • Next.js에서는 하나의 폴더 안에서 Front/Back을 함께 다룰 수 있지만, 분리 시 확실한 경계와 구조 이점 생김
2. 자동 SSR/SSG
   • SEO가 중요한 페이지에는 편리하지만, SEO 필요도가 낮은 내부 대시보드엔 무의미
3. 서버 컴포넌트와 서버 액션
   • 초기엔 코드량이 줄어들어 편해 보이나, 장기적으로 명시적 API 설계가 더 나은 경우 많음

얻는 것

• 빠른 빌드와 로컬 개발
  • CSR만 쓰는 React 앱은 빌드·리로드 속도가 훨씬 빠름
• 간결한 아키텍처
  • 프론트, 백엔드 모두 자신에게 맞는 기술 스택을 독립적으로 사용
• 확장성
  • GPU 사용이나 대규모 트래픽에 유연하게 대응 가능
• 유지보수 편의
  • 테스트, 배포, 모니터링 등을 분산 처리해 더 명확한 구조

---

결론

1. “Next.js를 꼭 안 써도 되는 경우”
   • 로그인 전용 대시보드 중심 서비스 (SEO 무관)
   • 서버에서 GPU 활용 등 대규모 연산이 필요해 독립 서버가 필수일 때
   • 빌드 속도, 로컬 개발 속도가 매우 중요한 상황
   • 아키텍처를 명시적으로 분리해 유지보수·테스트를 간소화하고 싶은 경우
2. “하지만 Next.js도 훌륭함”
   • SEO가 중요한 마케팅·랜딩 페이지나 소규모 프로젝트라면 Next.js가 탁월
   • ComfyDeploy 사례처럼, “대시보드는 React & 독립 서버” + “Landing, SEO는 Next.js”라는 혼합 전략도 가능

결국 중요한 것은 ‘프로젝트 요구사항에 맞는 적절한 도구 선택’.
Next.js가 전가의 보도는 아니며, 필요 이상의 복잡성을 유발할 수도 있다.
React + 별도 백엔드를 통한 CSR 구조가 더 빠르고, 관리하기 쉽고, 유연한 방법이 될 수 있다는 점을 고려해 보자.