RSC, 왜 등장하게 되었나?

SSR의 경우 서버에서 렌더링을 마친 페이지를 클라이언트로 전송한다. 즉 CSR의 단점이었던 초기 렌더링 시간을 단축시켜주지만, TTI 까지 사이트가 작동하지 않는 단점이 생기게 된다. (CSR의 경우는 자바스크립트를 통해 컴포넌트들을 생성하기 때문에, HTML 요소와 이벤트가 함께 생성된다.)

React의 SSR의 경우 렌더링 된 컴포넌트를 자바스크립트와 이어주는 작업을 Hydration 을 통해 진행하게 되는데, 정적인 컴포넌트와 상호작용이 필요한 컴포넌트 모두 상관없이 리액트 번들에 포함되게 되며, Hydration이 진행이 된다는 것이다. 컴포넌트 렌더링 과정에서 역할을 나누어 사용자와의 상호작용과 함께 동작하는 컴포넌트와 서버 측에서 렌더링이 완료된 후 제어가 필요없는 정적 컴포넌트를 생각하게 되었다.

사용방법

파일명을 name.server.js 로 형성하면 해당 파일의 컴포넌트의 리액트 서버 컴포넌트로 전환된다. RSC 렌더링을 요청하면, React 측에서 직접적으로 DB에 접근하여 리액트 렌더링 작업을 진행한다. 이때 완성된 렌더링 형식은 JSON형식과 유사한 Stream을 클라이언트에게 응답하게 된다. 클라이언트 측에서는 응답을 기반으로 컴포넌트 트리를 형성한다.

결과적으로 서버는 렌더링 결과만 전송하므로,리액트의 번들 파일을 획기적으로 줄일 수 있으며,그만큼 서비스는 효율적인 운영되는데 도움을 준다.

RSC 와 SSR의 차이

RSC는 한 페이지에서 컴포넌트 마다 클라이언트 컴포넌트와 서버 컴포넌트로 렌더링할지 선택하는 것이 가능하다. 단 서버사이드 렌더링의 경우는 전체 페이지 내의 모든 컴포넌트를 서버측에서 렌더링한 결과를 반환한다.

SEO 및 TTV를 중점적으로 본다면 SSR이 더욱 좋고, TTI와 리액트의 번들 크기 등을 생각한다면 RSC가 효과적이다.

참고
리액트 선 넘네... 웹 생태계 바뀔까?
React Server Component: SSR최적화하는법 2분만에 알아보기