팀 앤더슨(Tim Anderson) 작성, 2025년 1월 2일
원문 : https://devclass.com/2025/01/02/next-js-backlash-like-using-a-sledgehammer-to-hang-a-picture-frame-says-disillusioned-dev-team/
한 개발팀이 Next.js에서 순수 React로 전환한 후, 느린 빌드 속도, Next.js 15의 문제점, 그 외 여러 이슈를 지적하며 이 프레임워크가 대부분의 애플리케이션에 과도하게 복잡하고 무겁다는 주장을 펼쳤다.
AI 애플리케이션과 워크플로우를 실행 및 배포할 수 있는 오픈소스 ComfyUI용 서비스인 ComfyDeploy의 창시자인 베니 콕(Benny Kok)은 풀스택 Next.js를 사용한 프로젝트가 얼마나 문제를 일으켰는지에 대해 게시글을 올렸다. 그는 "로컬 개발이 끔찍했다"며, 코드 변경 시마다 서버 사이드 렌더링(SSR)이 전체적으로 다시 로드되었다고 밝혔다. 애플리케이션 빌드에는 최대 7분이 소요되었다고 한다.
콕은 최근 릴리스된 Next.js 15로 업그레이드를 시도했으나, 호환성 문제로 인해 일주일 만에 포기했다. 그는 Rust로 작성된 증분 번들러인 Turbopack을 사용하는 터보 모드(Turbo Mode)의 Next.js 15에서도 첫 번째 페이지를 빌드하는 데 10초 이상이 걸렸으며, 전체 빌드는 여전히 7분이 소요되었다고 말했다. 배포 환경에서는 이런 시간이 큰 문제가 아닐 수도 있지만, 코드 디버그 개발 주기에서는 매우 번거로웠다. 콕은 "오타를 수정하는 것조차 커피 한 잔 마실 시간을 줬다"고 비꼬았다.
콕은 Next.js 대신 순수 React로 마이그레이션하고, TanStack Router와 Rust로 작성된 Rspack 번들러를 보완적으로 사용하기로 결정했다. 그 결과, M3 Max 맥북 프로에서 초기 개발 번들 시간이 1.67초로 줄어들었다고 밝혔다.
그는 “가끔은 적을수록 더 많은 것을 이룰 수 있다”며, "우리의 경우, Next.js를 덜 사용했더니 더 빨리 배포하고, 더 빨라졌으며, 개발자들이 더 행복해졌다"고 말했다. Next.js의 고급 기능을 인정하면서도, "대부분의 제품에서는 Next.js가 액자 하나 걸기 위해 대형 해머를 사용하는 것과 같다"고 비유했다.
한 팀의 경험이 전체적인 판단 기준이 될 수는 없지만, 다른 개발자들도 Next.js가 지나치게 복잡하고 느리다는 의견에 동의하는 듯하다. 콕의 게시물에 한 개발자는 “우리 코드베이스도 동일한 결정을 내렸을 때 극적으로 단순해졌고, 페이지 렌더링 속도도 빨라졌다”고 댓글을 남겼다. 또 다른 개발자는 “Rails와 Hotwire 덕분에 React 생태계의 혼란에서 완전히 벗어날 수 있었다”고 말했다.
2024년 State of JavaScript 설문 조사에서는 Next.js가 메타 프레임워크(애플리케이션 렌더링 및 제공에 초점을 맞춘 프레임워크)에서 54%의 사용률로 압도적인 우위를 점하며, 23%의 Astro, 그리고 그 뒤를 잇는 Nuxt, Gatsby, SvelteKit 등을 제쳤다. 하지만 프레임워크 사용자의 긍정적인 감정(사용자 유지율)을 기준으로 보면, Next.js는 하위 두 번째로 떨어지며 Astro와 SvelteKit은 사용자 만족도를 꾸준히 유지했다고 조사 작성자들은 밝혔다.
흥미로운 점은 React 자체 개발자들이 Next.js를 App Router와 같은 최신 기능을 구현하기에 가장 완전한 프레임워크로 추천한다는 것이다. React 문서에서는 순수 React 대신 프레임워크를 사용할 것을 권장하지만, Next.js가 가장 완전하다고 해도 개발자 경험이 프레임워크 선택에 더 중요한 영향을 미칠 수 있다는 점이다.
