Next.js를 넘어서: 2025년 풀스택 자바스크립트 프레임워크의 현황
Next.js는 오랜 기간 사랑받아왔습니다. 사실 지금도 여전히 움직이고 있죠. 아마 여러분의 포트폴리오 사이트, 회사 마케팅 페이지, 그리고 배포된 줄도 몰랐던 내부 도구 세 개 이상에 사용되고 있을 겁니다. 하지만 웹 개발이라는 끊임없이 변화하는 생태계에서는 가장 사랑받는 프레임워크조차도 결국 경쟁을 맞이하고 동료가 생기기 마련입니다.
지금은 2025년입니다. 여러분은 백엔드에 자바스크립트 또는 타입스크립트 그리고 Node.js를 사용해 풀스택 무언가를 만들고 있습니다. 필요할 때는 서버 사이드 렌더링, 상황에 맞게 정적 생성, 빠른 배포, 확장 가능한 성능, 그리고 절규하고 싶지 않을 정도로 쾌적한 개발자 경험을 원하죠.
Next.js가 오랫동안 기본 선택이었지만, 여러 강력한 의견과 흥미로운 기능을 가진 다른 프레임워크들도 경쟁에 뛰어들었습니다. 현재 상황이 어떻게 돌아가는지, 주요 후보들이 어떻게 비교되는지, 그리고 이 중에 Next.js의 뒤를 잇는 차세대 프레임워크가 있는지 혹은 특정 프로젝트 유형별로 더 나은 선택지는 무엇인지 살펴보겠습니다.
Next.js: 기능은 풍부하지만 대가가 따른다
Next.js는 React 기반 풀스택 개발에서 오랫동안 대표적인 프레임워크였습니다. 서버 사이드 렌더링, 정적 생성, 점진적 재검증, 엣지 함수, API 라우트, 그리고 이제는 React 서버 컴포넌트와 스트리밍까지 약속합니다. 거의 모든 것을 할 수 있는 만능 툴 같은 프레임워크죠.
하지만 때로는 만능 도구가 빵을 자르기에 가장 편한 도구는 아닙니다.
인기에도 불구하고 Next.js는 점점 정당화하기 어려워지고 있습니다—특히 Vercel 생태계 밖에 있거나 단순함, 유지보수 용이성, 자체 호스팅을 우선시하는 팀에게는 더욱 그렇습니다.
우선, 전통적인 기업 배포 파이프라인에서 Next.js를 자체 호스팅하는 건 꽤 번거롭습니다. 이 프레임워크는 통상적인 한번 빌드 후 어디서든 배포하는 패턴에 적합하지 않습니다. 출력물이 환경 변수와 런타임 설정에 강하게 묶여 있어서, 자주 환경별로 별도의 빌드를 해야 하는 제한이 있습니다—스테이징에서 프로덕션으로 아티팩트를 신뢰하며 올리는 데 익숙한 사람들에겐 꽤나 귀찮은 일입니다.
또한 미들웨어 이야기도 있습니다. 미들웨어는 일부 웹 API와 제한된 Node.js 서브셋을 지원하는 이상한 하이브리드 런타임에서 실행됩니다. 이 어색한 중간지대는 Vercel 인프라에 맞추기 위해 만든 내부 도구처럼 느껴지며, 광범위하게 유용한 기능이라기보다는 특정 플랫폼에 치우친 모습입니다. 사실 Next.js 많은 부분이 점점 Vercel의 호스팅 모델에 의해 형성되고 있는데, Vercel에 완전히 의존한다면 훌륭하지만 그렇지 않다면 덜 매력적입니다.
개발자 경험 측면도 상황이 나아지지 않았습니다. 문서는 방대하고 일관성이 없으며 초보자가 내재화해야 할 “옛 것 vs 새 것” 결정들이 넘쳐납니다. App Router를 써야 할까요, Pages Router를 써야 할까요? getServerSideProps
를 써야 할까요, fetch
를 사용하는 서버 컴포넌트를 써야 할까요? use client
지시어는 언제 쓸까요? 캐싱은 대체 어떻게 동작할까요?
대답은 종종 “상황에 따라 다르다”이고, 이어지는 수시간의 문서 탐험이 뒤따릅니다.
결국 이 모든 것이 과도하게 설계되고 불필요하게 복잡한 프레임워크라는 인상을 줍니다. 초보자에게는 학습 곡선이 가파릅니다. React뿐만 아니라 Next.js의 라우팅 모델, 렌더링 모드, 고유한 캐싱 동작, 배포 특이점, 미들웨어 런타임까지 배워야 하기 때문입니다. 버튼 하나 제대로 작동시키기 전부터 프레임워크 특유의 API 면적이 너무 넓습니다.
이를 React Router(프레임워크 모드)와 비교해 보세요. React Router는 훨씬 더 플랫폼에 충실해 신선한 느낌을 줍니다. 웹 표준을 따릅니다. API 면적이 작고 이해하기 쉽습니다. 클라이언트와 서버에 동일한 정신 모델을 사용합니다. 그리고 중요한 점은, 모든 걸 하려고 하지 않고 잘 구조화된 빠르고 서버를 인지하는 React 앱을 예측 가능한 동작과 숨겨진 마법 없이 만들 수 있게 해줍니다.
요컨대, Next.js가 아직 채택 면에서 선두이긴 하지만 더 이상 당연한 선택은 아닙니다. 강력한 프레임워크이지만 복잡하고 점점 더 의견이 강한 프레임워크이기도 합니다. Vercel에 배포할 계획이 없거나 명료성과 이식성을 중요하게 생각한다면 다른 선택지를 고려해 볼 필요가 있습니다.
React Router (프레임워크 모드): Remix의 재탄생
Remix 기억하시나요? 웹 표준에 충실하고, 폼 처리를 다시 즐겁게 만들었으며, useEffect
가 악몽처럼 느껴지게 만든 데이터 로딩 시스템을 갖춘 똑똑한 React 프레임워크 말입니다. 이젠 React Router에 통합되어 있습니다—네, 아마 2017년부터 써왔던 그 React Router 맞습니다.
React Router의 이 새로운 프레임워크 모드는 Remix가 가진 모든 훌륭함을 라우터 API 핵심에 바로 제공해줍니다. 중첩 라우팅, 라우트별 데이터 로딩 기능, 점진적 향상을 포용하는 모델이 포함되어 있습니다.
클라이언트 측에서 fetch 호출과 useEffect의 멍청한 체조를 반복할 필요 없이, 라우트에 loader 함수를 정의하기만 하면 됩니다. 이 함수는 서버에서 실행되고 데이터를 가져와 컴포넌트를 채워줍니다. 폼 제출도 실제 <form>
엘리먼트를 사용하면 브라우저가 그대로 처리합니다. 만약 자바스크립트가 꺼져 있어도 앱이 깨지지 않고 단지 작동합니다. 놀랍지 않나요?
React Router의 프레임워크 모드는 기본적으로 정적 사이트 생성 기능을 내장하지 않지만, 스마트 캐싱을 지원하고 거의 어디서나 실행될 수 있습니다—Node.js, Deno, 엣지 런타임 등. 이식성 있고 빠르며 플랫폼에 가까운 설계를 목표로 합니다.
동적 앱을 만들면서 스트리밍, 중첩 레이아웃, 전통적인 HTML 우선 마인드를 가진다면 React Router (프레임워크 모드)는 당신이 몰랐던 최고의 선택일지도 모릅니다.
공식 사이트: reactrouter.com
SvelteKit: 자바스크립트는 줄이고 즐거움은 더하고
SvelteKit은 React나 Vue를 사용하지 않습니다. 대신 Svelte를 사용하며, 컴포넌트를 런타임 오버헤드가 전혀 없는 고도의 최적화된 자바스크립트로 컴파일합니다. 덕분에 앱이 더 빠르고, 번들 크기가 작으며, 성능 문제를 파헤쳐야 할 이유가 줄어듭니다.
SvelteKit의 라우팅은 파일 기반이고 유연합니다. 페이지를 사전 렌더링할 수도 있고, 서버 렌더링도 하며, 필요할 때는 클라이언트로 폴백할 수도 있습니다. 데이터는 서버에서 실행되는 load
함수로 로드되고, 폼 제출은 깔끔하고 직관적인 액션 함수로 처리됩니다.
어댑터 시스템 덕분에 SvelteKit은 전통적인 Node 서버부터 서버리스 플랫폼, 엣지 런타임까지 어디에나 배포할 수 있습니다. 빠른 빌드를 위해 Vite와 잘 통합되며, 많은 사람들이 신선할 정도로 간단하다고 느끼는 개발자 경험을 제공합니다.
하지만 모두가 만족하진 않습니다. React만큼 큰 생태계를 갖추지 못했고, 직접 컴포넌트를 더 자주 만들어야 하며, Svelte 경험이 있는 개발자 찾기가 조금 어렵습니다. 그러나 성능과 최소주의가 최우선이라면 SvelteKit을 넘기기 힘듭니다.
공식 사이트: svelte.dev
Nuxt 3: Vue의 동반자
Nuxt는 Vue의 Next.js라 할 수 있습니다. 최신 버전 Nuxt 3는 Vue 3의 Composition API를 풀스택 개발에 도입했습니다. SSR, SSG, 그 사이 모든 것을 지원하며 새 엔진 Nitro가 구동합니다.
파일 기반 라우팅, 내장 데이터 페칭, 서버 사이드 API 라우트, 그리고 인상적인 모듈 생태계를 갖춰 Vue 앱을 곧바로 사용할 수 있게 합니다. 인증, 분석, CMS가 필요하다면 아마도 Nuxt 모듈이 있을 겁니다.
Nuxt도 배포 면에서 유연하며, Nitro 덕분에 Node, 서버리스 플랫폼, 심지어 엣지에서도 실행 가능합니다. Vue를 선호하고 기본값이 좋으며 문서가 훌륭한 프로덕션 가능 풀스택 프레임워크를 원한다면 Nuxt가 정답입니다.
단점은 Vue 생태계가 성숙하긴 했으나 React보다는 작고, 업계 전반 모멘텀이 여전히 React 중심이라는 점입니다. 하지만 Vue 영역에서는 Nuxt가 절대 강자입니다.
공식 사이트: nuxt.com
NestJS: Swagger가 있는 백엔드 (말 그대로)
NestJS는 UI 프레임워크는 아니지만 너무 인기가 많아 무시할 수 없습니다. Node.js에서 API와 서비스를 타입스크립트 중심으로 구조화하여 빌드하는 방식을 제공합니다. 백엔드의 Angular라 생각하세요—데코레이터, 의존성 주입, 모듈 등등이 모두 포함됩니다.
앱 백엔드가 Next.js API 라우트가 감당하기 어려울 정도로 복잡할 때 훌륭합니다. WebSocket? 백그라운드 작업? 복잡한 GraphQL API? Nest가 해결해 줍니다.
하지만 자체적으로 풀스택은 아닙니다. Next, Nuxt, SvelteKit 같은 프런트엔드 프레임워크와 결합해서 사용해야 합니다. 모두에게 맞진 않지만, 서버에서 진지한 것을 구축한다면 고려할 만합니다.
공식 사이트: nestjs.com
와일드 카드들
몇몇 다른 프레임워크도 언급할 가치가 있습니다:
-
RedwoodJS: 프런트엔드는 React, 중간에 GraphQL, 백엔드는 Prisma를 사용하는 풀스택 프레임워크입니다. 매우 강한 의견을 가지고 있으며 스타트업에 적합합니다. 공식 사이트: redwoodjs.com
-
Blitz.js: 원래 Next.js 기반으로, 프런트엔드에서 서버로 직접 함수 호출을 가능하게 하여 별도의 API가 필요 없게 만든 프레임워크입니다. Rails를 타입스크립트로 옮겨놓은 느낌입니다. 공식 사이트: blitzjs.com
-
Astro: 기본적으로 정적 HTML로 페이지를 렌더링하고, 인터랙티브해야 할 부분만 하이드레이션하는 콘텐츠 중심 프레임워크입니다. 블로그, 문서, 마케팅 사이트에 이상적이고, 앱에는 덜 적합합니다. 공식 사이트: astro.build
그렇다면 "다음" Next.js는 무엇인가?
그게 질문 아닐까요?
Next.js는 여전히 채택률, 기능, 생태계에서 선두를 지킵니다. 어디 가지 않을 겁니다. 하지만 개발자들은 점점 자신들의 필요에 따라 대안을 선택하고 있습니다:
-
Next.js보다 더 단순하고 표준 기반인 무언가를 원한다면: **React Router (프레임워크 모드)**를 확인해 보세요.
-
더 작은 번들과 번개처럼 빠른 성능을 원한다면: SvelteKit을 시도해 보세요.
-
Vue의 개발자 친화성을 선호한다면: Nuxt 3을 선택하세요.
-
구조화된 백엔드 로직이 필요하다면: NestJS가 적합합니다.
Next.js의 단일한 “후계자”는 없을 수도 있습니다. 대신 우리는 다양화되는 프레임워크 풍경을 보고 있는 셈입니다—한 가지가 모든 것을 해결하기보다, 특정 요구를 더 잘 충족하는 여러 선택지가 발전하고 있습니다.
진짜 승자는? 바로 여러분입니다. 왜냐하면 오늘날 자바스크립트와 타입스크립트로 풀스택 앱을 구축할 때 그 어느 때보다도 더 많은 실용적인 선택지와 더 나은 문서가 있기 때문입니다.
최종 생각:
현대 웹 스택은 최고의 프레임워크를 고르는 것이 아니라, 올바른 프레임워크를 고르는 것입니다. 그리고 때로 올바른 프레임워크란 다음 프레임워크가 등장하기 전에 프로젝트를 실제로 끝낼 수 있는 프레임워크이기도 합니다.