요즘 프론트엔드 커뮤니티에서 꽤 불편한 이야기가 돌고 있습니다. Inngest가 Next.js에서 TanStack으로 마이그레이션하며 로컬 개발 시간을 83% 단축했다는 사례, OpenPanel과 Documenso의 유사한 이탈 경험들. 이걸 읽을 때마다 솔직히 한 가지 생각이 머릿속을 떠나지 않습니다. "그 프로젝트, Next.js가 진짜 필요했나?"
dev.to의 jrdan_dev가 정리한 분석이 이 질문을 꽤 날카롭게 건드립니다. Next.js는 본질적으로 서버사이드 렌더링에 특화된 opinionated 프레임워크입니다. SSR, ISR, SSG—Vercel이 대중화한 이 개념들은 블로그, 뉴스 포털, 랜딩 페이지, SEO가 핵심인 이커머스처럼 콘텐츠를 미리 렌더링할 수 있고, 검색 노출이 비즈니스 생존과 직결되는 서비스에 최적화되어 있습니다. 즉, 도구의 설계 의도 자체가 명확합니다.
문제는 여기서 발생합니다. 우리가 Next.js를 선택한 진짜 이유가 뭐였냐는 거죠. "리액트 쓸 건데 Next.js가 요즘 대세잖아요"—사실 이게 많은 팀의 실제 선택 이유 아니었나요? 사용자 인증 이후에만 의미 있는 화면, 복잡한 필터와 모달이 얽힌 인터랙션, 로그인 상태에 따라 거의 모든 UI가 달라지는 대시보드형 서비스. 이런 제품에서 SSR은 기술적 의무가 아닌 불필요한 복잡도입니다. 정적으로 생성할 수 있는 게 없고, SEO는 사실 별로 중요하지 않고, 중요한 건 상태 관리와 인터랙션의 반응성이니까요.
여기서 TanStack의 포지셔닝이 선명해집니다. TanStack은 SSR을 전제가 아닌 옵션으로 둡니다. 기본 흐름은 route → query → mutation → invalidation. 컴포넌트가 서버 컴포넌트인지 클라이언트 컴포넌트인지 매번 고민할 필요가 없습니다. 클라이언트 퍼스트로 시작하고, 서버 렌더링은 의식적으로 선택하는 구조. 이게 사실 많은 프로덕트에서 더 자연스러운 아키텍처일 수 있습니다.
그런데 이 프레임워크 선택 문제는 단순히 Next.js vs TanStack의 이분법으로 끝나지 않습니다. velog의 웹·앱 통합 아키텍처 분석이 여기서 중요한 레이어를 추가해줍니다. 실제 서비스에서 웹과 모바일 앱을 같은 서버와 DB로 운영할 때—API 버저닝, 인증 모델(쿠키+세션 vs JWT), 트래픽 패턴 차이, 배포 주기 차이—이 모든 변수들이 프레임워크 선택보다 훨씬 복잡한 아키텍처 판단을 요구합니다. 프레임워크를 고르기 전에, 이 서비스가 어떤 클라이언트 환경에서, 어떤 데이터 패턴으로, 어떤 트래픽을 받을 것인지 먼저 설계해야 한다는 거죠. 웹은 SEO 유입과 동시 트래픽 스파이크, 앱은 백그라운드 요청과 실시간 WebSocket—이 차이를 고려하지 않은 채 "Next.js 쓰면 SEO 되잖아요"로 프레임워크를 결정하는 건, 아키텍처 설계를 프레임워크에 떠넘기는 것과 같습니다.
그리고 현실에서 이 판단이 얼마나 어려운지를 velog의 React Todo List 구현 기록이 다른 각도로 보여줍니다. useState로 CRUD를 구현하고, styled-components의 Transient Props로 DOM 경고를 잡고, 불변성을 지키며 배열 상태를 갱신하는 이 과정들. 클라이언트 상태 관리의 본질은 여기 있습니다. SSR이 없어도, App Router가 없어도, 복잡한 서버 컴포넌트 구조가 없어도 이 로직은 완벽하게 작동합니다. 인터랙션 중심 서비스에서 Next.js의 구조적 복잡도를 굳이 얹는 것, Figma에서 볼 때는 몰랐는데 실제 구현하면 Server Component/Client Component 경계 때문에 상태 끌어올리기가 꼬이는 상황—개발자라면 한 번쯤은 겪어봤을 겁니다.
포트폴리오 영감 플랫폼 stash-or-pass.com 사례도 흥미롭습니다. 스와이프 UI로 포트폴리오를 탐색하고, 리더보드로 커뮤니티 평가를 보여주는 이 서비스—SEO가 중요할 수도 있지만, 핵심 UX는 인터랙션 중심의 클라이언트 경험입니다. 이런 서비스를 설계할 때 가장 먼저 물어야 할 질문이 바로 "SSR이 필요한가, 아니면 빠른 인터랙션이 필요한가"입니다. 리더보드 데이터는 캐싱으로 충분할 수 있고, 스와이프 인터랙션은 클라이언트에서 전부 처리될 수 있습니다. 프레임워크 선택이 UX 설계보다 앞서면 안 됩니다.
결국 핵심은 이겁니다. Next.js가 나쁜 도구가 아닙니다. App Router 마이그레이션의 혼란, Vercel 락인 우려, 보안 이슈들을 논외로 해도—Next.js는 여전히 SEO 크리티컬한 서비스에서 강력합니다. 문제는 '트렌드'가 '아키텍처 판단'을 대체하는 순간 생깁니다. Lighthouse 점수 좋게 나오길 원하면서 거의 모든 페이지가 로그인 게이트 뒤에 있는 서비스를 만드는 것, 정적 생성을 원하면서 실시간으로 바뀌는 데이터를 보여주는 것—이런 모순을 프레임워크 선택 단계에서 걸러내야 합니다.
앞으로의 방향은 분명합니다. Next.js에서 TanStack으로의 이탈은 반(反)Next 운동이 아닙니다. 아키텍처 먼저, 프레임워크 나중이라는 당연한 원칙이 뒤늦게 현장으로 돌아오는 과정입니다. 서비스의 SEO 의존도, 인터랙션 복잡도, 클라이언트 다양성, 팀의 유지보수 역량—이 변수들을 먼저 정의하고, 그 답에 맞는 도구를 고르는 것. 그게 '유행을 따른 선택'과 '아키텍처를 기반으로 한 선택'의 차이입니다. 그리고 그 차이가, 몇 년 후 83% 개발 시간을 날려가며 마이그레이션하느냐 아니냐를 가릅니다.