TanStack은 복잡성 증가, 유연성 감소, 미미한 성능 향상, 그리고 개발 속도 저하를 결정적인 요인으로 꼽으며 자사 라이브러리에서 React Server Components(RSC) 사용을 공식적으로 중단했습니다. TanStack의 라이브러리는 널리 채택되어 있으며 종종 생태계의 실질적인 표준을 설정하기 때문에, 이번 결정은 React 기반 도구를 구축하는 모든 이들에게 중요한 의미를 갖습니다.
RSC가 매력적으로 보였던 이유
React Server Components는 무거운 데이터 페칭(data-fetching)과 렌더링 작업을 서버로 옮겨, 클라이언트 번들 크기를 줄이고 페이지 로드 속도를 높이는 방법으로 등장했습니다. TanStack 팀은 자사의 data-grid 및 query 라이브러리의 사용자 경험을 개선하기 위해 이 방식을 시도했습니다.
중단하게 된 이유
- 복잡성 – RSC 코드를 디버깅하려면 별도의 사고 모델이 필요했습니다. 팀은 감당할 수 있는 수준보다 더 많은 시간을 서버 측 렌더링 문제를 추적하는 데 소비했습니다.
- 유연성 – 많은 서드파티 라이브러리가 순수 클라이언트 환경을 가정합니다. RSC의 서버 전용 실행 방식은 해당 의존성들을 재작성하거나 shim을 적용하지 않고서는 통합하기 어렵게 만들었습니다.
- 성능 – 측정된 속도 향상은 미미했습니다. 서버와 클라이언트 경계를 조율하는 데 드는 오버헤드가 대부분의 실제 시나리오에서 얻을 수 있는 미미한 이득보다 컸습니다.
- 속도 – 더 단순한 클라이언트 전용 패턴을 사용하면 팀이 업데이트를 더 빠르게 배포할 수 있습니다. RSC를 사용하면 모든 변경 사항에 대해 서버와 클라이언트 모두에서 검증이 필요하여 릴리스 주기가 느려졌습니다.
더 넓은 관점에서의 영향
TanStack과 같은 선도적인 툴킷이 RSC에서 물러난다면, 다른 프로젝트들도 그 열풍을 재고할 수 있습니다. 이번 결정은 트레이드오프(trade-off)를 잘 보여줍니다. 최첨단 기능은 개발 생산성과 장기적인 유지보수에 해를 끼치는 숨겨진 비용을 초래할 수 있습니다. 빠른 반복(iteration)과 폭넓은 라이브러리 호환성을 우선시하는 기업들도 이와 같은 행보를 따를 수 있습니다.
반론
일부 개발자들은 특정 사용 사례, 특히 서버 측 데이터 처리가 페이로드 크기를 획기적으로 줄일 수 있는 경우에 여전히 RSC의 가치를 보고 있습니다. 이 방식은 진화할 수 있으며, 향후 도구들이 TanStack이 식별한 문제점들을 해결할 수도 있습니다. 현재로서는 의견이 엇갈리고 있습니다.
향후 주목해야 할 점
- 도구 업데이트 – 디버깅 및 통합 지원이 개선되면 복잡성 장벽이 낮아질 수 있습니다.
- 커뮤니티 피드백 – 더 많은 팀이 성능 데이터를 공유함에 따라 비용 대비 편익 방정식이 바뀔 수 있습니다.
- 대안 패턴 – 점진적 서버 렌더링 기술이나 하이브리드 접근 방식이 절충안을 제시할 수 있습니다.
요약: TanStack의 React Server Components 사용 중단은 새로운 기술이 항상 더 나은 것은 아니라는 점을 상기시켜 줍니다. 개발자는 새로운 패턴을 도입하기 전에 약속된 이득과 자신의 워크플로우에 미칠 실제 비용을 반드시 따져보아야 합니다.
출처: https://tanstack.com/blog/we-stopped-using-rsc-on-tanstack-com