RSC vs SSR

서론

---

Next를 사용하게 되었을 때의 렌더링 과정을 공부하던 중 좋은 글을 발견해서 그 글을 보며 정리하게 되었다
=> 원본 글에 약간의 살만 붙여 정리하는 것임을 미리 밝힙니다
(제가 참고했던 글에 대해서는 게시물 하단에 링크를 달아두었습니다)

우리가 흔히 React와 Next의 가장 큰 차이라고 하면,
CSR(Client Side Render)과 SSR(Server Side Render) 라고 답할 것이다.

SSR은 서버측에서 완성된 HTML을 보내주기 때문에 클라이언트는 그걸 받아서 곧바로 화면에 보여주기만 하면 되기에 사용자가 빈 화면을 보는 시간을 줄여줄 수 있다.
이정도의 개념은 가지고 있었지만, 조금 더 자세하게 알 필요가 있다고 생각했다.

 

Server Component

---

Next에는 Server Component와 Client Component의 개념이 존재한다

• Next 13버전이 등장하면서 굉장히 많은 변화가 있었지만, 그 중에서 가장 큰 변화는 app router 이다.
• app router 방식에서는 모든 컴포넌트가 기본적으로 서버 컴포넌트로 동작한다는 사실에 주목해야 한다.
• 클라이언트 컴포넌트를 사용하고 싶다면, 파일의 최상단에 'use client' 라고 명시해주어야 한다.

"use client";

import {useState} from "react";

const ClientComponent  =() => {

 const [state,setState] = useState()

 return <div>Test</div>
}

export default ClientComponent

 

RSC vs RCC

---

React Server Component와 React Client Component

사실 리액트에도 서버 컴포넌트의 개념은 존재했다

React Server Component는 React 18부터 도입된 개념으로, 서버에서 동작하는 컴포넌트를 지칭한다.
서버 컴포넌트가 있으니까 클라이언트 컴포넌트도 있겠지?
그렇다. 서버 컴포넌트의 개념이 도입되기 전까지 우리가 사용했던 컴포넌트는 모두 클라이언트 컴포넌트이다.

서버 컴포넌트와 클라이언트 컴포넌트의 가장 큰 차이점은 컴포넌트가 렌더링되는 장소가 서버냐 클라이언트냐의 차이 다.
서버 컴포넌트는 서버에서 한차례 해석된 후에 클라이언트로 전달되고, 클라이언트 컴포넌트는 클라이언트가 js 번들을 다운로드 받은 후에 해석하게 된다.

 

• RSC와 RCC는 렌더링되는 위치가 다르기 때문에 각각 할 수 있는 역할이 구분된다
• RSC가 최근에 나온 개념이니까 무조건 RCC보다 좋겠지? 라는 생각은 잘못된 생각이다
• RSC와 RCC를 적재적소에 배치해여 개발하려는 접근이 필수적이다

 

RSC의 동작 방식

---

RSC는 서버에서 어떤 식으로 렌더링이 되는 것일까?

RSC와 RCC를 적재적소에 배치하기 위해서는 RSC가 어떤 식으로 렌더링되는지 이해할 필요가 있다
아래와 같이 RSC와 RCC를 적절하게 혼합하여 구성한 화면이 있다고 가정하자

 

• 노란색 노드는 서버 컴포넌트를, 파란색 노드는 클라이언트 컴포넌트를 의미한다
• 사용자(브라우저)는 해당 페이지를 렌더하기 위해서 서버로 요청을 날린다
• 그러면 서버는 컴포넌트 트리를 Root로부터 실행하며 직렬회된 JSON의 형태로 재구성하기 시작한다

 

직렬화?

직렬화는 데이터 스토리지 문맥에서 데이터 구조나 오브젝트 상태를 동일하거나 다른 컴퓨터 환경에 저장(이를테면 파일이나 메모리 버퍼에서, 또는 네트워크 연결 링크 간 전송)하고 나중에 재구성할 수 있는 포맷으로 변환하는 과정

 

쉽게 말해서 특정 개체를 다른 컴퓨터 환경으로 전송하고 재구성할 수 있는 형태로 바꾸는 과정이라고 할 수 있다.
우리가 흔히 사용하는 JSON.stringify() 함수가 직렬화를 수행하는 함수이며,
반대로 JSON.parse() 함수가 역직렬화를 수행하는 함수이다.

주의할 점은 모든 객체를 직렬화할 수는 없다는 것 이다.
대표적으로 function(함수)는 직렬화가 불가능한 객체 이다.

function이 실행 코드와 실행 컨텍스트를 모두 포함하는 개념이기 때문인데, 함수는 자신이 선언된 스코프에 대한 참조를 유지하고, 그 시점의 외부 변수에 대한 참조를 기억하고 있다.
js의 클로저가 바로 이런 현상을 가리키는 용어이기도 하다.

const a = 100;

const sample = ()=>{
    console.log(a)
}

sample() //100

이처럼 함수의 실행 컨텍스트, 스코프, 클로저까지 모두 직렬화할 수는 없기 때문에 function은 직렬화가 불가능한 객체로 분류되는 것이다

직렬화 과정은 모든 서버 컴포넌트를 실행해서 JSON 객체 형태의 트리로 재구성할 때까지 진행된다.
예를 들면 다음과 같다.

<div style={{backgroundColor:'green'}}>hello world</div> //JSX 코드는 createElement의 syntax sugar다.

> React.createElement(div,{style:{backgroundColor:'green'}},"hello world")

> {
  $$typeof: Symbol(react.element),
  type: "div",
  props: { style:{backgroundColor:"green"}, children:"hello world" },
  ...
} //이런 형태로 모든 컴포넌트를 순차적으로 실행한다.

• 다만 이 과정을 모든 컴포넌트에 대해 진행하는 것이 아니라 RCC일 경우에는 건너뛰게 된다
  • RCC의 렌더링은 클라이언트에게 넘기는 것이다
• 하지만 RCC를 서버에서 해석하지 않고 건너 뛴다고 해서 비워둔다면 실제 컴포넌트 트리와의 괴리가 발생한다
• 따라서 RCC의 경우 직접 해석하는 것이 아니라, "이곳은 RCC가 렌더링되는 위치입니다" 라는 placeholder를 대신 배치하게 된다

 

{
  $$typeof: Symbol(react.element),
  type: {
    $$typeof: Symbol(react.module.reference),
    name: "default", //export default를 의미
    filename: "./src/ClientComponent.js" //파일 경로
  },
  props: { children: "some children" },
}

RCC는 곧 함수이기 때문에, 직렬화를 할 수 없다
따라서 함수를 직접 참조하는 것이 아니라, module reference 라는 새로운 타입을 적용하고, 해당 컴포넌트의 경로를 명시함으로써 직렬화를 대신하고 있다

이러한 직렬화 작업을 마친 후 생성된 JSON Tree를 도식화하면 다음과 같은 형태이다

• 이렇게 도출된 결과물을 Stream 형태로 클라이언트가 전달을 받게 된다.
• 함께 다운로드한 js bundle을 참조하여 module reference 타입이 등장할 때마다 RCC를 렌더링해서 빈 공간을 채워놓는다.
• 그런 다음 DOM에 반영하면 실제 화면에 스크린이 보여지게 되는 것이다.

 

• placeholder로 표시되어 있던 노드들이 실제 컴포넌트로 대체가 되어 화면에 보여지게 된다

 

RSC의 제약사항

---

우리는 RSC, RCC를 함께 사용할 떄 몇가지 제약사항을 도출해낼 수 있다

 

1. RSC에서 RCC로 function과 같이 직렬화가 불가능한 객체를 props로 넘겨줄 수 없다

{
   $$typeof: Symbol(react.element),
   type: "div",
   props: { 
         children: {
           $$typeof: Symbol(react.element),
           type: {
             $$typeof: Symbol(react.module.reference),
             name: "default",
             filename: "./src/ClientComponent.js"
           },
           props: {callback:function}, // 이처럼 JSON에 function이 명시되어야만 한다.
           ...
         }
     },
   ...
 }

• RSC는 서버에서 해석되어 직렬화된 JSON 형태로 변환된다고 했다
• 때문에 서버 컴포넌트를 설명하는 모든 요소는 직렬화가 가능해야 한다는 전제조건이 붇는다
• 만약 RSC가 Child에게 function을 props로 넘겨주게 되면, JSON에 이 사실이 명시되어야 하기 때문에 에러가 발생할 수 있다

 

하지만 RSC에서 다른 RSC로 function을 넘겨주는 것에는 문제가 없이 가능하다
서버에서 렌더링되는 RSC간의 함수 전달을 굳이 client를 넘기는 Stream에 서술할 필요가 없기 때문에 생략하거나 placeholder로 대체한 게 아닐까라고 글의 작자는 예측하고 있다

또한, next의 server action을 사용하면, RSC에서 RCC로 함수를 전달할 수도 있는데, 아래와 같이 RSC에서 'use server directive와 함께 함수를 정의하면 RCC로 넘겨줄 수 있다

const ServerComponent = ()=>{
  const add = async (a:number,b:number) =>{
    'use server'
    return a+b
  }

  return <div>
        <ClientComponent addFunc={add}/>
    </div>
}

• 다만 해당 function의 params와 return은 모두 직렬화가 가능해야 한다는 조건이 붙는다
• server action으로 선언한 함수를 RSC에서 RCC로 넘겨줄 때는 function 자체를 넘겨준다기 보다는, api의 명세를 넘겨주고, 함수를 호출하면 그때 서버에 api를 호출하고 결과값을 받아오는 것처럼 동작하여 제약사항을 우회하는 것이라 예상한다
• 자세한 내용은 Next 공식문서의 server action 부분을 참조하면 좋을 것이다

 

2. RCC는 RSC를 직접 return 해줄 수 없으며, 반드시 children prop의 형태로 넘겨주어야 한다

• 요청이 들어오면 서버에서 모든 RSC가 순차적으로 실행되며, 중간에 RCC를 만나면 placeholder로 표시해두고 넘어간다고 했다
• 즉, RCC는 실행이 되지 않기 때문에 RCC 내부에서 반환되는 RSC 또한 서버 클라이언트임에도 서버에서 실행되지 못한다
• 이러한 경우 해당 RSC는 RCC와 동일하게 클라이언트에서 동작하게 된다
• 하지만 children prop을 통해서 RSC를 넘기게 되면, 사실상 공통 부모가 렌더링되는 시점에 RSC가 실행이 되고, 그 결과값을 children으로 전달할 수 있다

function ParentClientComponent({children}) {
    ...
  return <div onChange={...}>{children}</div>;
}

function ChildServerComponent() {
    ...
  return <div>server component</div>;
}

function ContainerServerComponent() {
  return <ParentClientComponent>
            <ChildServerComponent/>
    </ParentClientComponent>;
}

• 위와 같이 ChildServerComponent는 ParentClientComponent의 자식 컴포넌트이다
• 하지만 사실상 ContainerServerComponent를 공통 부모로 갖고 있기 때문에 ContainerServerComponent가 렌더링되는 시점에 ChildServerComponent도 함께 렌더링되어 그 결과값이ParentChildComponent에 넘겨지고 있다

 

{
  // The ClientComponent element placeholder with "module reference"
  $$typeof: Symbol(react.element),
  type: {
    $$typeof: Symbol(react.module.reference),
    name: "default",
    filename: "./src/ParentClientComponent.js"
  },
  props: {
    children: {
      $$typeof: Symbol(react.element),
      type: "div",
      props: {
        children: "server component"
      }
    }
  }
}

 

RSC vs SSR

---

나는 이 글을 읽으면서 RSC와 SSR이 다른 개념이라는 것을 알게 되었다

지금까지 글을 읽은 우리는 이러한 생각을 할 수 있다

컴포넌트가 서버에서 해석돼서 클라이언트로 전달되는 게 SSR 아니야?

실제로 RSC와 SSR은 서버에서 처리한다는 공통점 외에는 해결하고자 하는 목표도 다르고, 일어나는 시점과 최종 산출물도 다른 완전히 별개의 개념 이라고 한다
따라서 반드시 둘 중 하나를 선택할 필요도 없고, 필요에 따라 RSC와 SSR을 함께 사용하면 큰 시너지를 낼 수도 있다

우리가 작성한 소스코드가 브라우저에 보여지기 위해서는 우선 컴포넌트가 실행되어 데이터가 해석되어야 하고,
해석된 데이터가 다시 HTML로 변환되는 과정을 거져야 한다

RSC는 이 중 전자(해석)에 해당하는 단계에 관여하고, SSR은 후자(HTML로 변환)에 관여한다

그렇다면, 또 이러한 생각을 할 수 있다

RSC를 쓰든, RCC를 쓰든 SSR을 사용하면 어짜피 클라이언트가 받게 되는 최종 산출물은 HTML로 동일한 것 아닌가?
그렇다면 RSC와 SSR을 함께 사용했을 때의 이점은 무엇인가?

 

Next의 SSR

---

Next에서는 SSR을 어떻게 사용하고 있을까?

이걸 이해하기 위해서 CSR과 SSR의 개념에 대해서 먼저 정리를 해보자

 

CSR vs SSR

---

CSR과 SSR의 차이

• Client Side Rendering(CSR)은 말 그대로 클라이언트에서 컴포넌트를 렌더링하는 것을 의미한다
• 서버에서 빈 HTML과 js bundle을 다운받고, 이 js 소스 코드를 클라이언트에서 해석해서 처음부터 그려나가게 된다
• 때문에 초기 로딩 속도가 느리지만, 스크린간 이동이나 인터랙션에 강점이 있다
  • 빈 HTML을 받아와서, js를 클라이언트 측에서 실행시켜서 스크린을 구성해야 하기 때문에 속도가 느리다

 

• Server Side Rendering(SSR)은 서버에서 컴포넌트를 해석해서 최종 결과물인 HTML 파일을 내려주는 것 을 의미한다
• CSR과는 반대로 초기 로딩 속도가 빠르지만, 페이지를 이동할 때마다 새로운 HTML을 요청해서 받는 시간이 필요하고, 현재 화면에서도 작은 변경사항이 발생하면 처음부터 HTML을 로드해야 하기 때문에 스크린간 이동이나 인터랙션에 약점이 있다
  • 이미 완성된 HTML을 내려줬기 때문에, 사용자와의 인터랙션을 하게 되면 사용자의 입력에 따라 새롭게 또다시 HTML을 받아와야 한다
  • 리액트는 SPA(Single Page Application)이기 때문에 페이지 이동을 하게 되면 굉장히 스무스 하지만, Next에서는 페이지 이동을 하게 되면 시간이 오래걸리고 깜빡임이 발생한다
• 사실 Next에서 우리가 사용하는 SSR은 전통적인 의미의 SSR은 아니다
• SSR과 CSR의 장점만을 취하기 위해서 일종의 절충점을 찾은 형태라고 할 수 있다
• 초기 로딩 속도가 느리다는 CSR의 단점을 보완하기 위해서 초기 로딩시에는 HTML 파일을 SSR을 통해 빠르게 받아오고, 이와 병렬적으로 js 번들도 함께 받아와서 미리 받아온 HTML과 병합하는 Hydration 과정을 거치는 것이다
• 그 결과 빠른 로딩에 강점이 있는 SSR과 인터랙션에 강점이 있는 CSR의 장점을 모두 취할 수 있게 된다
• 즉, Next의 SSR 뿐만 아니라 CSR의 특징도 많이 가지고 있으므로 RSC를 함께 사용했을 때, 그 이점이 더욱 크게 극대화 될 수 있다

 

SSR + RSC 예시

---

Next를 사용해서 만들어진 것으로 알려진 넷플릭스 페이지를 예시로 보자

• 넷플릭스 페이지에 처음 로딩하게 되면, 서버에서 이미 어느정도 완성된 HTML을 받아오는 것을 알 수 있다
• 위의 예시는 더욱 확실히 하기 위해서 JS를 Disabled 시키고 요청을 보낸 것이다

 

• React를 사용했다고 알려진 현재 내가 글을 작성하고 있는 티스토리의 홈페이지
• 티스토리 페이지에서 JS를 Disabled 시켜버리면 이처럼 빈 화면만 보게 된다
  
  • 기본적인 부분(header, meta, ...)만 채워져 있다
• CSR에서는 빈 HTML을 보내준 다음 js 번들을 클라이언트 측에서 해석해서 화면을 구성한다고 했는데, js를 막아버리니 이와 같이 빈 화면만 보게 되는 것이다

 

RSC의 장점

---

RSC가 어떻게 동작하는지 모두 이해했으니, RSC의 장점을 쉽게 납득할 수 있을 것이다

 

Zero Bundle Size

---

서버 측에서 미리 모두 해석을 해서 직렬화된 JSON 형태로 전달하기 떄문에 어떠한 Bundle도 필요하지 않다

RSC의 소스 파일 뿐만 아니라, RSC에서만 사용하는 외부 라이브러리의 경우에도 번들에 포함될 필요가 없기 때문에 번들 사이즈를 획기적으로 감량할 수 있다

이러한 부분은 Next의 TTI(Time To Interactive) 개선에도 크게 기여할 수 있는데, 이전에 살펴봤듯이 Next에서 SSR을 사용한다고 하더라도 초기 로딩속도에 이점이 있을 뿐 CSR과 동일한 사이즈의 js 번들을 다운받아야 하기 때문에 TTI는 여전히 CSR 대비 큰 메리트가 없었기 때문이다

하지만 RSC를 도입하면 다운받아야 하는 번들 사이즈가 줄어들게 되므로, TTI 개선에 기여할 수 있다

 

No More getServerSideProps / getStaticProps

---

Next 13 버전으로 변경되면서 더이상 getServerProps / getStaticProps라는 함수를 이용하지 않게 되었다

사실 나는 Next 12 버전을 사용해본 적이 없기 때문에 피부로 와닿지는 않지만, 이전이 훨씬 불편했을 것이란 건 예상해볼 수 있었다
기존에는 Data fetch 등을 수행할 때는 반드시 getServerSideProps 또는 getStaticProps 함수를 page 최상단에서 수행하고, 이를 page에 props로 넘겨서 사용해야 했다

이 과정은 순수 React와는 괴리가 있어서 처음 Next를 사용하는 사람들에게 낯설 뿐만 아니라, 무조건 최상단에서 fetch한 후에 page에 props로 넘겨줄 수 밖에 없는 구조 때문에 data를 하위 컴포넌트에서 사용하려면 props drilling이 불가피했다.

반면 RSC는 그 자체가 서버에서 렌더링되기 때문에, 컴포넌트 내부에서 Data Fetch를 시도해도 괜찮다
즉, data가 필요한 컴포넌트에서 직접 data fetch가 가능해졌고, Next 13의 app router에서는 기본적으로 모든 컴포넌트가 RSC이기 때문에, 더 이상 getServerSideProps 또는 getStaticProps는 불필요한 함수가 되었다

 

Automatic Code Splitting

---

원래는 Code Splitting을 하기 위해서는 React.Lazy나 dynamic import를 사용해야 했다

import dynamic from 'next/dynamic'

const DynamicComponent = dynamic(() => import('../components/hello'))

• 하지만 RSC에서 RCC를 import하는 케이스에서는 자동적으로 RCC를 dynamic import하게 된다
• RCC는 서버에서 해석하지 않고, placeholder만 남겨둔다고 했는데, 그렇기 때문에 굳이 RSC가 렌더링될 때 RCC를 즉시 import할 필요가 없기 때문이다

 

Progressive Rendering

---

Next 13부터는 컴포넌트가 서버에서 한차례 렌더링되며, 그 결과물로 직렬화된 JSON이 생성된다고 했다

• 그리고 클라이언트는 그 결과물을 Stream의 형태로 수신하게 된다

// Tweets.server.js
import { fetch } from 'react-fetch' // React's Suspense-aware fetch()
import Tweet from './Tweet.client'
export default function Tweets() {
  const tweets = fetch(`/tweets`).json()
  return (
    <ul>
      {tweets.slice(0, 2).map((tweet) => (
        <li>
          <Tweet tweet={tweet} />
        </li>
      ))}
    </ul>
  )
}

// Tweet.client.js
export default function Tweet({ tweet }) {
  return <div onClick={() => alert(`Written by ${tweet.username}`)}>{tweet.body}</div>
}

// OuterServerComponent.server.js
export default function OuterServerComponent() {
  return (
    <ClientComponent>
      <ServerComponent />
      <Suspense fallback={'Loading tweets...'}>
        <Tweets />
      </Suspense>
    </ClientComponent>
  )
}

M1:{"id":"./src/ClientComponent.client.js","chunks":["client1"],"name":""}
S2:"react.suspense"
J0:["$","@1",null,{"children":[["$","span",null,{"children":"Hello from server land"}],["$","$2",null,{"fallback":"Loading tweets...","children":"@3"}]]}]
M4:{"id":"./src/Tweet.client.js","chunks":["client8"],"name":""}
J3:["$","ul",null,{"children":[["$","li",null,{"children":["$","@4",null,{"tweet":{...}}}]}],["$","li",null,{"children":["$","@4",null,{"tweet":{...}}}]}]]}]

• 위 문자열은 클라이언트가 수신하는 스트림의 한 예시를 나타낸 것이다.
• 여기서 짚고 넘어갈 부분은 데이터가 ‘스트림’ 형태로 전달된다는 사실이다.
• 즉, 스크린의 모든 화면정보를 수신할 때까지 기다릴 필요 없이, 클라이언트는 먼저 수신된 부분부터 반영하기 시작하여 화면에 띄워줄 수 있게 된다.
• 위 스트림 문자열을 보면 S2 지점에 suspense가 서술되어 있다.
• 그리고 J0를 보면 뒤쪽에 children으로 “@3”이 참조되어 있는 것을 볼 수 있다.
• 하지만 스트림의 어디를 봐도 “@3”에 대한 정의는 나와있지 않다.
• 이는, 아직 data fetch가 완료되지 않았기 때문에 fallback이 보여지는 상황이기 때문에 @3를 placehoder로 사용하고 있기 때문이다.
• 만약 data fetch가 완료되면 “@3”이 “J3”로 대체되고, “J3”는 참조하고 있던 “M4”에 해당하는 client component에 data를 넘겨주면서 화면에 보여지게 된다.
• 따라서 RSC를 React.Suspense와 함께 사용한다면 모든 데이터를 기다릴 필요 없이 먼저 그릴 수 있는 부분을 반영하여 뷰를 로드한 뒤, data fetch가 완료되면 그 결과가 즉각적으로 스트림에 반영됨을 알 수 있다.

 

컴포넌트 단위 refetch

---

전통적인 SSR의 경우에는 완성된 HTML을 내려주기 때문에, 작은 변경사항이 발생하더라도 전체 페이지를 전부 새로 그려서 받아와야 했다

• 반면 RSC는 최종 결과물이 완성된 HTML이 아니라, 직렬화된 스트림의 형태로 받아오기 때문에, 클라이언트에서 스트림을 해석하여 virtualDOM을 형성하고, Reconciliation을 통해 뷰를 갱신하는 과정을 거치게 된다
• 화면에 변경사항이 생겨서 서버에서 새로운 정보를 받아와야 하는 상황이 생기더라도, 새로운 스크린으로 갈아끼우는 것이 아니라 기존 화면의 State 등 Context를 유지한 채로 변경된 사항만을 선택적으로 반영할 수 있게 된다

 

느낀점

---

Next의 렌더링 과정을 조금 더 깊게 공부해보면서 느낀 점

• RSC와 SSR이 완전히 구분되는 개념이라는 것이 가장 새롭게 알게 된 개념이었다
  • Next는 이 둘을 적절히 조화시켜서 사용하기 때문에 더 큰 시너지를 만들어낸다
• 단순히 클라이언트 컴포넌트 내부에서 서버 컴포넌트를 사용할 때는 child props로 전달하라는 얘기만 알고 사용하고 있었는데, 이제는 그 이유를 알게 되었다

결론: Next 외않씀?

 

Reference

---

Next) 서버 컴포넌트(React Server Component)에 대한 고찰

[번역] React Server vs Client Component in Next.js 13

React(라이브러리)