프로덕션 대시보드를 설계할 때 가장 먼저 마주치는 질문은 "어떤 컴포넌트를 쓸까"가 아니다. "어떤 렌더링 모델 위에 올릴까"다. 최근 dev.to에 올라온 두 편의 글—Next.js 16 기반 SaaS 대시보드 구현기와 TanStack Start의 React Server Components 심층 분석—을 나란히 읽으면, 이 질문의 무게가 훨씬 선명하게 느껴진다.
핵심 이슈: 같은 RSC, 다른 철학
React Server Components는 이제 선택지가 아니다. Next.js에서는 이미 기본값이고, TanStack Start도 RSC를 정식 지원하기 시작했다. 문제는 두 프레임워크가 RSC를 바라보는 시각이 근본적으로 다르다는 점이다. Next.js는 "서버 컴포넌트가 기본, 필요한 곳에만 use client"를 선언한다. 반면 TanStack Start는 RSC를 React Flight 스트림의 한 조각으로 다룬다. 프레임워크가 RSC를 소유하는 게 아니라, 개발자가 스트림을 직접 만들고 소비하는 구조다.
맥락 해석: 대시보드가 드러내는 트레이드오프
Next.js 16 기반 Pulse 대시보드 구현기는 실무에서 자주 마주치는 네 가지 문제를 깔끔하게 풀어냈다. 다크모드 플래시 없애기, CSS 변수만으로 사이드바 접기, TanStack Table과 커스텀 필터 UI 분리, Badge 컴포넌트 자동 색상 매핑—각각 독립적인 해법처럼 보이지만, 공통된 설계 원칙이 있다. 상태는 최소화하고, CSS가 할 수 있는 건 CSS에 맡긴다. 사이드바 애니메이션에 JavaScript 로직이 없고, 다크모드는 data-theme 속성 하나가 CSS 변수를 뒤집는 방식이다. 이런 접근은 Next.js의 서버 컴포넌트 친화적인 구조와도 잘 맞는다. 클라이언트 번들을 줄이고 싶은 방향성이 일치하기 때문이다.
그런데 바로 이 지점에서 TanStack Start의 RSC 구현 방식이 흥미롭게 겹친다. TanStack Start에서 RSC를 만드는 코드는 놀라울 정도로 투명하다. renderToReadableStream으로 서버 함수를 만들고, 클라이언트에서 createFromReadableStream으로 소비한다. Next.js처럼 프레임워크가 "알아서" 처리해주는 마법이 없다. 대신 개발자가 어떤 컴포넌트가 RSC인지 명시적으로 선언한다. 이 투명성은 디버깅 비용을 낮추고, 대시보드처럼 데이터 흐름이 복잡한 애플리케이션에서 특히 빛난다.
시사점: 아키텍처 선택 기준 세 가지
두 사례를 교차하면 프로덕션 대시보드 아키텍처를 고를 때 물어야 할 질문이 세 가지로 압축된다.
첫째, 팀의 RSC 숙련도. Next.js는 "쓰다 보면 RSC를 쓰게 되는" 구조다. 온보딩 마찰이 낮은 대신, 왜 이 컴포넌트가 서버에서 돌고 있는지 모른 채 개발하는 상황이 생긴다. TanStack Start는 처음부터 RSC를 선택적으로 투입하므로 학습 곡선은 가파르지만, 팀 전체의 이해도가 올라간다.
둘째, 인터랙션 밀도. Pulse 대시보드처럼 실시간 필터, 전역 검색, 테마 토글이 동시에 존재하는 UI라면 클라이언트 상태 관리가 많아진다. Next.js의 기본값은 이런 컴포넌트를 use client로 명시적으로 분리하도록 강제한다. TanStack Start는 처음부터 클라이언트 퍼스트이므로, 인터랙션이 많은 대시보드에서 정신 모델이 더 자연스럽게 맞아떨어진다.
셋째, 번들 투명성. Next.js는 빌드 최적화를 프레임워크가 담당한다. 편하지만 블랙박스다. TanStack Start는 RSC 스트림을 직접 다루므로 번들에 무엇이 들어가는지 개발자가 더 세밀하게 제어할 수 있다. Core Web Vitals를 극한까지 밀어붙여야 하는 프로젝트라면 이 차이가 크다.
전망: 프레임워크 경쟁이 아닌 패러다임 수렴
흥미로운 건 두 프레임워크가 서로 다른 방향에서 같은 지점을 향하고 있다는 사실이다. Next.js는 RSC를 기본값으로 밀면서 점점 더 세밀한 제어 수단을 추가하고 있고, TanStack Start는 클라이언트 퍼스트에서 출발해 RSC를 자연스럽게 흡수하는 중이다. 2026년에는 어떤 프레임워크를 쓰든 RSC를 피할 수 없다. 그렇다면 지금 팀이 투자해야 할 것은 특정 프레임워크의 API가 아니라, RSC의 작동 원리 자체다.
Pulse 대시보드 구현기가 보여준 CSS 변수 기반 상태 관리, TanStack Table의 관심사 분리 전략은 어떤 프레임워크를 선택하든 그대로 적용된다. 아키텍처를 고르는 것과 좋은 컴포넌트를 설계하는 것은 별개의 문제다. 프레임워크는 렌더링 모델을 결정하지만, 사용자 경험의 질은 여전히 컴포넌트 설계자의 손에 달려 있다.