당신의 프로젝트에 정말 Next.js가 필요했나요?
Source: Dev.to
Introduction
최근에 Next.js에서 TanStack으로 프로젝트를 마이그레이션하는 팀들을 점점 더 많이 보게 됩니다. 로컬 개발 시간을 83 % 줄인 Inngest, OpenPanel, Documenso 같은 사례가 점점 흔해지고 있습니다. 이런 이야기를 읽을 때마다 저는 항상 생각합니다: 처음부터 Next가 정말 올바른 선택이었을까?
Pages Router에서 App Router로의 마이그레이션, 개발자 경험에 미치는 영향, Vercel 락인 논쟁, 그리고 그 과정에서 떠오른 몇몇 보안 이슈 등 어려움은 잘 알고 있습니다. 하지만 아마도 핵심은 “Next가 나쁘다”는 것이 아니라, 이 프로젝트들이 처음부터 Next를 정말 필요로 했는가? 하는 점일 것입니다.
What Next.js Is Designed For
Next.js는 서버‑사이드 렌더링(SSR)에 큰 초점을 맞춘 React 애플리케이션을 만들기 위한 의견이 강한 프레임워크입니다. SSR, ISR, SSG 등 Vercel이 대중화한 여러 렌더링 방식을 위해 설계되었습니다.
초기 목표는 명확했습니다:
- 가능한 한 많이 미리 렌더링하기
- SEO 최적화를 위해 HTML 제공
- 로딩 시간 단축
- 빌드 후 매우 높은 성능 제공
이상적으로는 정적 페이지를 생성하고, 필요할 때 캐시를 무효화하며, 더 빠른 페이지를 제공하는 것이었습니다.
Typical Use Cases
- 블로그
- 뉴스 포털
- 랜딩 페이지
- 공개 카탈로그가 있는 마켓플레이스
- SEO에 중점을 둔 전자상거래
즉, 콘텐츠를 미리 렌더링할 수 있고 SEO가 성공에 필수적인 제품들입니다.
When Next.js May Not Be the Best Fit
서버 측에 최적화된 도구를 완전히 동적인, 클라이언트‑의존 시스템에 적용하면 문제가 발생합니다:
- 복잡한 인터랙션이 많은 내부 시스템
- 다중 필터, 모달, 복잡한 로컬 상태, 빈번한 데이터 업데이트가 있는 애플리케이션
- 거의 모든 것이 로그인 상태와 사용자의 최근 행동에 따라 달라지는 제품
이 경우 정적으로 생성할 수 있는 것이 거의 없으며, SEO는 우선순위가 아니고 미리 렌더링된 HTML도 의미가 없습니다. 중요한 것은 상태 관리와 인터랙티비티입니다.
TanStack as an Alternative
TanStack은 전통적인 SPA 모델에 더 가깝게 설계되었으며, SSR은 선택적인 기능일 뿐 아키텍처의 전제조건이 아닙니다. 표준 워크플로는 간단합니다:
- 라우트
- 쿼리
- 뮤테이션
- 무효화
컴포넌트가 서버 측인지 클라이언트 측인지 지속적으로 고민할 필요가 없습니다. 애플리케이션은 기본적으로 클라이언트‑퍼스트이며, 서버 렌더링을 사용하겠다는 선택은 의식적인 결정일 뿐 시작점이 아닙니다.
Closing Thoughts
지금 일어나고 있는 현상이 “Next에 대한 거부”라기보다는, 아키텍처와 제품에 기반한 결정보다 현재 상황에 맞는 프레임워크를 선택한 결과일 수도 있습니다(React가 더 우아한 솔루션을 제공하는 경쟁자를 갖게 된 점은 칭찬할 만하지만, 이는 또 다른 글의 주제입니다).
저는 이제 막 개인 블로그에 생각을 쓰고 공유하기 시작했습니다. 새로운 아이디어와 피드백을 언제든 환영합니다! 방문해 주세요: