GN⁺: 당신에겐 Next.js가 필요하지 않습니다 - 우리가 Next에서 React로 이관한 이유
(comfydeploy.com)- ComfyDeploy 대시보드를 Next.js에서 React로 마이그레이션하여 얻은 결과:
- 빌드 시간이 3분 → 18초로 단축
- 핫 리로드가 200ms 이하로 개선됨
- 팀원들이 훨씬 더 만족스러워함
- 처음에 Next.js를 활용한 풀스택 애플리케이션으로 시작해서 Drizzle과 Server Actions 덕분에 타입 안정성과 깔끔한 코드로 잘 작동했으나, 다음과 같은 문제 발생:
- 특정 사용자로 인해 Vercel에서 $2,000의 높은 API 비용 발생
- API 테스트 복잡성 증가: Server Actions와 API 라우트가 혼합
- 느린 빌드 시간과 비효율적인 로컬 개발 환경
- 작은 변경에도 전체 SSR 리로드 발생
- 문제점
- Next.js의 복잡성 증가 : Next.js의 올인원(full-stack) 접근 방식이 앱 성장과 함께 개발 복잡성을 초래
- 우리 대시보드는 주로 React 기반이며, Next.js의 서버 기능이 필요하지 않음
- Next.js에서 React로의 전환
- TanStack Router와 Rspack을 사용하여 Next.js에서 React로 전환
- 개발 서버 시작: 2초 이내
- Vercel 빌드 시간: 18초
- API 설정 개선, 불필요한 종속성 제거, 코드를 간소화하며 생산성 증가
- TanStack Router와 Rspack을 사용하여 Next.js에서 React로 전환
- 성능 비교
- Next.js 15 (Turbo 모드 사용)
- 첫 페이지 빌드: 10.4초
- React + TanStack Router + Rspack
- 라우트 계산: 200ms 이하
- 초기 번들 빌드: 1.67초
- Next.js 15 (Turbo 모드 사용)
- 트레이드오프
- 잃은 것
- 프론트엔드와 백엔드 코드의 Co-location : 프론트엔드와 백엔드를 분리하면서 경계가 명확해짐
- Next.js의 캐싱 기능 : 실시간 업데이트 데이터가 많아 맞춤 캐싱으로 대체
- 사전 렌더링 및 초기 로드 : Static Generation 대신 더 나은 UX 구현 - 더 이상 비활성 버튼 표시 없음
- 서버 컴포넌트 및 액션 : 서버 컴포넌트의 "마법"을 잃었지만, 더 의도적인 API 설계로 개선
- 얻은 것
- API 계약 설계 강화
- 필요한 곳에서만 캐싱 구현
- 데이터 흐름과 상태 관리를 신중히 설계
- 잃은 것
- 결론
- Next.js는 랜딩 페이지와 SEO 같은 작업에는 적합하지만, 대부분의 제품에는 과도한 복잡성을 초래함
- 랜딩 페이지와 SEO 작업에는 여전히 Next.js를 사용
- 대시보드는 Pure React + TanStack Router + Rspack로 전환
- API는 Python FastAPI 서버를 Google Cloud Run에서 실행하며 필요에 따라 자동으로 확장
- 적합한 도구 선택이 중요하며, 우리에게는 Next.js가 과도한 선택이었음
'적합한 도구 선택이 중요하며, 우리에게는 Next.js가 과도한 선택이었음'
마지막 줄이 핵심인 것 같네요.
적합한 도구 선택을 위해서는 이런저런 실패를 많이 경험해보는 것도 중요한 것 같습니다.
SEO가 필요하다는 건 컨텐츠가 핵심이라는 건데,
UI 컴포넌트(?)와 상태가 핵심을 차지하고 있으니… SSR ISR Hydrate…같은 괴생명체가 탄생…
신기하네요. React에 비해 Next가 더 무겁나요?
Next는 프로젝트 세팅만 해본적이 있는데 엄청 간단하게 프로젝트 구축 - 개발이 시작됐었습니다.
저희는 모바일"앱" 퍼스트가 가능한 서비스들만 운영해서
SEO가 필요한 영역은 리액트(또는 그 유사 무언가들)를 아예 사용하지 않고 아주 가볍게 유지합니다.
웹은 SEO 어그로 용도로만 사용하고, 앱으로 유도...
상당히 공감하는 내용입니다.
저는 SEO 가 필요한 경우가 아니라면 절대로 Next.js 를 도입하지 않습니다.
위의 글처럼 react 만 사용할경우가 장점이 많습니다:
- Next.js 특유의 불필요한 복잡성과 패턴이 없어짐.
- 유지보수가 간결해짐
- 불필요한 SSR 비용 지출에서 자유로워짐
- Router , bundler 등 FE infra 에 해당하는 library 에 대한 선택권이 넒어짐
새로운 애플리케이션이나 사이트 전체를 React로 구축하는 경우에는 프레임워크의 사용을 권장합니다.
라고 react.dev 에서 이야기하고 있어서요~
Hacker News 의견
-
많은 사람들이 아이디어를 수십억 명의 사용자에게 확장할 수 있는지에 너무 집중하고 있음. 그래서 웹사이트에 방문자가 5명밖에 없는데도 Kubernetes를 사용하는 경우가 있음. 학생들이 Next.js를 사용하여 간단히 HTML + CSS로 작성할 수 있는 웹사이트를 만드는 경우도 봄
-
Next.js로 프로젝트를 구축했지만, 사용하기가 복잡하게 느껴졌음. 클라이언트와 서버 간의 쿠키 접근 API가 다르고, 환경 변수를
process.env.NEXT_PUBLIC_*로 접근해야 하는 등 혼란스러움. 클라이언트와 서버에서 최소한의 변경으로 작동하는 코드를 작성하고 싶었지만, 그렇지 않았음. Next.js가 제공하는 것에 비해 학습과 오버헤드가 가치가 없다고 느껴짐 -
코드베이스가 단순해지고 페이지 렌더링 속도가 빨라졌음. 커뮤니티가 불필요하게 이런 프레임워크로 밀려가는 것이 안타까움. 대부분의 사람들은
npx rsbuild init만 필요함. rspack과 rsbuild를 사용하여 간단한 라우터와 아름다운 단순성을 얻었음 -
Next.js v14 출시 이후로 사용 중이며, 매우 만족스러움. RSCs를 사용하여 클라이언트 측 JS가 꺼져 있어도 앱의 많은 부분이 잘 작동함. PHP 앱의 단순한 힘을 갖고 있으며, 타입 시스템과 인터랙티브한 상태 기반 클라이언트 컴포넌트를 뷰 트리의 "리프 레벨"에 매끄럽게 포함할 수 있음
-
Rails와 Hotwire 덕분에 React 생태계의 혼란에서 벗어날 수 있었음. 상태 관리 라이브러리, 메타 프레임워크, 데이터 페칭 라이브러리 등 너무 많은 선택지가 있음. 서버에서 오는 데이터를 페이지에 표시하는 간단한 작업을 복잡하게 만들 필요가 없음
-
NextJS를 사용하는 CMS(PayloadCMS)에서 일하고 있으며, NextJS는 사용해 본 기술 중 최악임
-
Next.js, React, Vue와 같은 무거운 프론트엔드 프레임워크/라이브러리를 사용하는 거의 모든 프로젝트가 백엔드에서 템플릿을 처리하는 라이브러리를 사용하는 것이 더 나을 것임. 때로는 EJS를 통한 클라이언트 측 렌더링이 의미가 있음. 프레임워크를 왜 사용하는지 의문임
-
SEO와 크롤링 최적화를 위해 Next.js를 사용함. 페이지가 크롤링될 필요가 없다면(예: 로그인 뒤의 대시보드), Next.js가 필요 없고 순수 React가 더 간단할 것임
-
Next.js가 기본 시작 옵션으로 자리 잡은 것에 놀라움. 2~3년 전과 비교해 큰 변화처럼 느껴짐
-
Vike를 사용하여 NextJS 앱을 대체하려고 시도 중이며, 만족스러움. 방해받지 않고 원하는 방식으로 구축할 수 있음