[React] React + SSR과 서버 컴포넌트는 뭐가 다를까?

2023년에 NextJs가 13버전으로 업그레이드 되면서 서버 컴포넌트를 도입하였습니다.

저는 해당 기술을 봤을 때, 단순히 SSR + 스트리밍을 활용하여 SPA의 문제점을 개선한다고 생각했습니다.

하지만 직접 React + SSR을 구현해보니 NextJs가 활용하는 서버 컴포넌트 + SSR은 당연히 문제점을 개선하지만, 더 나아가 근본적인 문제를 해결하려한다는 것을 이해하였습니다.

 

hydrateRoot + renderToPipeableStream를 이용한 React SSR 구현

React 18부터 제공된 renderToPipeableSteam은 리액트 컴포넌트를 스트리밍 가능하게 합니다.
정확히는 리액트 트리를 스트리밍 합니다. (renderToPipeableStream renders a React tree to a pipeable Node.js Stream.)

또한 hydrateRoot는 이렇게 서버에서 직렬화되어서 스트리밍된 HTML을 다시 리액트 컴포넌트로 역직렬화합니다.

 

다시 정리해서, 둘을 같이 사용하면

서버에서 생성된 HTML이 점진적으로 스트리밍되어 도착하는대로 렌더링되며, 하이드레이션을 통해 리액트 컴포넌트로 역직렬화됩니다.

그러면 결과적으로 SPA의 문제점인 초기 빈화면 문제가 개선됩니다

왜냐하면 SPA에서는 JS 번들이 모두 도착해야 페인트가 가능하지만, 위의 방법에서는 서버에서 생성된 HTML이 도착하는대로 그려지고, 이후 js를 통해 리액트 컴포넌트가 되므로, 사용자가 그려진 화면을 보는 시간은 더 앞당겨져 사용자 경험이 개선됩니다.

 

하지만 이는 HTML이 빠르게 렌더링되는 것일 뿐, 리액트 컴포넌트가 빠르게 생성되는건 아닙니다.

어쨋든 JS번들이 도착해야 리액트 컴포넌트가 완성되기 때문입니다.

 

서버 컴포넌트

서버 컴포넌트는 말그대로 서버에서 생성되는 리액트 컴포넌트입니다.

여기까지 보면 위와 동일한게 아닌가 싶지만, 근본적인 차이점이 있습니다.

 

서버 컴포넌트는 서버에서 생성되고 서버에서 실행되며, JS 번들에 포함되지 않습니다.

즉 서버 코드입니다.

 

그러면 앞서 언급한 문제인 JS 번들이 도착해야 렌더링이 된다는 문제의 근본적인 문제인 JS 번들 크기가 줄어듭니다.

여기에 SSR + 스트리밍을 접목시키면 사용자 입장에서는 빠르게 화면이 그려질뿐만 아니라 인터렉티브한 행동도 빠르게 가능해집니다.