RSC란?(RCC, RSC의 렌더링 방식과 약간의 SSR)

해진·2024년 9월 20일

조각 테크 공유

목록 보기

14/16

들어가는 말

Next 13 업데이트에 app directory가 되면서, app directory 내부 모든 컴포넌트는 기본적으로 서버 컴포넌트로 동작이 됩니다. 그러나 이를 클라이언트 컴포넌트로 설정하고자 한다면 파일 최상단에 use client를 선언하면 됩니다. 그러나 매 컴포넌트마다 클라이언트 컴포넌트로 설정을 하다 보니 뭔가 잘못되었다… 이들의 차이점은 뭐고 어떨 때 서버 컴포넌트를 써야 하지?라는 물음표가 뜨게 되었습니다.

이 물음표를 느낌표로 바뀌는 과정을 정리해보려고 합니다.

RSC가 뭐지요?

RSC는 React Sever Component의 약자로 말 그래도 “서버 컴포넌트”입니다. 이를 조금 더 풀어서 보면, 서버에서 직렬화가 되는 컴포넌트 입니다.

그러면 여기서 한 가지 생각이 들 수 있습니다. “그럼 클라이언트 컴포넌트도 있나?” 네. 있습니다. 우리가 평소 써오던 일반적인 컴포넌트는 클라이언트 컴포넌트 (RCC / React Client Component)입니다.

기존의. 기본의. 그냥. 그런. 컴포넌트는 React Client Component(RCC)로 치환.그리고 React Server Componet(RSC)라는 새로운 레이어를 추가한 것.

자 그럼 컴포넌트는 서버, 클라이언트 컴포넌트가 있다는 것을 인지했습니다. 그러면 이 둘은 뭐가 다를까요? 왜 나눈걸까요? 어떤 순간에 쓰는 것이 좋을까요? 아직은 궁금한 게 더욱 많은 상황입니다.

컴포넌트란 무엇이지?(with 클라이언트 컴포넌트의 렌더링 과정)

서버 클라이언트 컴포넌트를 나누기 전, 일반적으로 우리가 사용해왔던 컴포넌트에 대해서 개념을 다시 잡고 진행해 봅시다.

컴포넌트(Component)란 데이터를 인자로 받아 그것을 가지고 jsx를 return 합니다.

function HelloWrold (user) {
	const [name, setName] = useState(user)
	
  return(
	  <H1>Welcome {name}</H1>
  )
}

위와 같은 JS 함수를 우리는 컴포넌트라고 합니다.

그럼 인자로 받는 user이라는 데이터는 props겠죠.
그리고 컴포넌트 내부에서 활용하는 데이터는 state로 관리하겠죠.

그런데 이런 “JS 함수가 렌더링 된다는 것”은 무엇일까요?

자, 다시 돌아가서 컴포넌트가 jsx를 리턴한다는 것은 모두 이해하셨을 것입니다.

그런데 이 과정에서 ‘Babel’이라는 것이 등장합니다. Babel을 만나 jsx는 해석됩니다.

무엇으로? React element로 해석이 됩니다. React element는 DOM관련 정보를 담고 있는 js 객체입니다. 다시 말해 React element 는 DOM에 표현하기 위해 필요한 정보를 담고 있는 js 객체입니다.

React element가 확장되면, fiber(node)가 되는 것입니다. fiber 즉 node는 Virtual DOM(이하 V-DOM)의 node가 됩니다. (fiber가 모여 V-DOM을 그림) 그래서 V-DOM은 fiber로 이루어진 tree로 볼 수 있습니다.

이런 V-DOM은 맨처음 빈 DOM을 반은 것 위에 반영되는 과정을 거칩니다.

이런 일련의 과정을 가지고 우리는 렌더링이라고 부릅니다!

그런데 우리가 궁금한 건 “서버”컴포넌트이고 이것이 어떻게 렌더링이 되는 것입니다.

그럼 우리가 지금까지 알던 바로 위에서 언급한 렌더링 방식은 뭐지?? 라는 생각이 살짝 들 수 있습니다.

이는 초반에 언급한 우리가 알던 기존의 컴포넌트 클라이언트 컴포넌트의 렌더링 방식입니다.

서버 컴포넌트란 무엇이지?(with 서버 컴포넌트의 렌더링 과정)

어떻게 렌더링 되고 무엇인지를 알려면 왜 만들어졌는지를 알고 접근하는 것이 더 이해가 빠를 것입니다.

Dan Abramov(댄 아브라모프)씨가 말하길 “본래 리액트 컴포넌트는 하나였다. 근데 이것을 확장하여 서버 컴포넌트라는 개념을 창조했습니다.

기존 컴포넌트 ⇒ 클라이언트 컴포넌트
새롭게 만든 것 ⇒ 서버 컴포넌트

그럼 왜 리액트에서는 컴포넌트라는 개념을 확장하여 서버 컴포넌트를 만들게 되었을까요?

서버 컴포넌트는 서버가 할 수 있는 모든 것을 할 수 있습니다.

따라서 서버의 값을 요청하는 과정을 추가적인 과정을 거칠 필요 없이 서버 컴포넌트 즉 local에서 바로 가능합니다. 이런 점은 속도 면에서도 코드 양(데이터 요청 코드 줄어듦) 적인 측면에서도 모두 리소스 절약이 될 것입니다.

서버 컴포넌트의 코드는 클라이언트로 전달되지 않습니다.

따라서 민감한 정보도 편리하게 다룰 수 있게 됩니다. 이로 신뢰도가 증가하는 컴포넌트를 개발할 수 있습니다.

RSC는 서버에서 이미 렌더링 된 다음 클라이언트에게 직렬화(serialize) 된 형태로 전달되기 때문에 클라이언트 사이드에서 추가적인 로드가 필요 없게 됩니다!

Speed, Trust 두 가지의 큰 목적을 가지고 서버 컴포넌트가 나타나게 되었습니다.

그러면 이제 서버 컴포넌트가 왜 나왔는지를 간단하게 이해했으니 이 서버 컴포넌트에 렌더링에 대해서 이해해봅시다.

Next란 React api를 가지고 렌더링을 합니다.

렌더링 워크는 청크로 나눠집니다. 나누는 것에 대한 기준으로는

라우트 세그먼트 (route segments)
서스펜스 바운더리 (Suspense Boundaries)

위 두 가지를 기준으로 렌더링 워크 됩니다. 이는 다시 말해 렌더링 워크는 청크로 나눠집니다.

그러면 이 나눠진 청크를 어떻게 쓰는지 고민을 해봐야 합니다.

이때 리액트가 나타나게 됩니다.

[서버]

리액트가 서버 컴포넌트는 렌더

서버 컴포넌트를 렌더 한다란 말은 즉, RSC payload라는 이름으로 불리는 스페셜 데이터 포멧으로 리액트는 서버 컴포넌트를 렌더링 한다는 뜻입니다.

따라서, 리액트는 서버 컴포넌트를 RSC payload로 변환하는 것입니다.

그럼 추가적으로 드는 생각이 있습니다.

RSC payload가 뭘까? 리액트 서버 컴포넌트 트리를 그리기 위한 바이너리입니다.
- 서버 컴포넌트의 렌더링 결과물이 존재
- placeHolder 존재 ⇒ 빈자리 표시(빈자리 === 클라이언트 컴포넌트, 클라이언트 컴포넌트가 어디 위치에서 렌더 될 것인지 나타내는 것.
- 서버 컴포넌트가 클라이언트 컴포넌트에게 전달하는 props 존재

요약하자면 “서버 컴포넌트는 리액트가 렌더 한다”라는 것입니다.

⇒ “렌더한다”라는 것은 결국 RSC를 RSC payload로 만드는 과정입니다.

Next가 RSC payload + 클라이언트 JS instruction 활용해 HTML을 렌더

이 과정 또한 서버에서 일어납니다.

그다음은 클라이언트가 넘겨받게 됩니다.

[클라이언트]

서버에서 전달받은 HTML을 즉시 보여줌

이것이 preview에 보이는 요소일 것입니다. 이니셜 페이지로 처음 새로고침을 눌렀을 때 보입니다.

RSC payload 활용

reconsile(재조정)을 위해서 RSC payload기능을 활용합니다.

RSC payload를 활용하여, 비어있던 클라이언트 컴포넌트 부분을 채워 넣습니다. 이렇게 온전하게 구성된 트리가 바로 리액트 컴포넌트 트리가 됩니다. 그리고 이것은 V-Dom이 되고 V-Dom이 실제 Dom을 업데이트하기도 합니다.

Hydrate(수화)

이는 Next를 사용하셨으면 종종 들어보셨을 것입니다.

바로 인터렉션을 가능하게 하는 부분이지요. JS 인스트럭션을 가져와 단순한 HTML에 다양한 이벤트나 setState함수 등을 붙입니다. 그저 태그만 있던 것들에 다양한 인터렉션이 가능하게 해줍니다.

요약

[서버]

리액트가 서버 컴포넌트는 렌더: 서버 컴포넌트를 RSC 페이로드로 변환하는 것.
Next가 HTML을 렌더: RSC payload + 클라이언트 JS instruction 활용해 html을 렌더링

[클라이언트]

서버에서 넘겨받은 HTML 보여줌
RSC payload 활용하여 클라이언트 컴포넌트 부분 채움
Hydrate

위 과정을 거치며 서버 컴포넌트는 렌더링 됩니다.

Next.js 공식 문서에는 RSC와 RCC의 명확하게 구분이 되어있습니다.

자 그럼 RSC와 RCC의 차이점과 방식에 대해서는 슬슬 이해가 가기 시작하기 시작합니다.

그런데 저는 여기까지 공부를 해오면서 다시금 궁금해지는 한 부분이 있었습니다. 그렇다면 SSR은 도대체 뭐지..? 라는 생각이 들기 시작했습니다.

SSR은 미리 HTML을 서버에서 그려서 클라이언트에 내려주고, 그것으로 인해 필요한 키워드가 이미 HTML에 담겨와서 SEO도 가능한 것이고, 사용자가 느끼기에 페이지가 빨리 불러온다고 느껴 사용자 경험도 나아지고… 그런데 이런 건 RSC에서도 동일하게 해주는거 아니야?라는 물음표가 마구 들기시작했습니다.

그렇다면 둘을 비교하며 생각해 봅시다.

SSR은 뭐죠?(SSR VS RSC)

SSR과 RSC는 “서버에서 렌더링이 된다”라는 점만 같고 원하는 것, 진행방식, 목적은 모두 다릅니다.

이때부터는 react가 아주 조금 원망스러워지기도 해요.
서버 컴포넌트, 서버 사이드 랜더링이라는 이름이 해당 개념을 이해하는데 큰 벽이 되거든요.
따라서 우리는 클라이언트 컴포넌트는 하이드레이션이 필요한 컴포넌트로 이해하는게 더 쉽다고 생각합니다! (하이드레이션이 필요 없는 컴포넌트는 서버 컴포넌트!)

[SSR]

목적: 인터랙티브 하지 않은 정적인 HTML을 최대한 빠르게 브라우저에게 전달하여 초기 페이지가 뜨는 속도를 향상시킨다.
RSC 에서의 렌더링은 서버 측에서 React 컴포넌트의 로직을 실행하는 과정
최종 목적은 HTML 생성이 아닌 컴포넌트 로직 처리하고 결과 생성
서버에서 데이터를 가져오거나 다른 서버 사이트 로직 처리하여, 클라이언트에 전송되는 데이터와 JS 번들 사이즈 최소화에 초점

[RSC]

목적: 서버가 하는 작업들을 동일하게 할 수 있는 컴포넌트를 구현
SSR에서의 렌더링은 서버에서 React 컴포넌트를 사용하여 완전한 HTML 페이지를 생성하는 과정
클라이언트가 HTML을 받으면 React는 Hydration과정 진행
초기 페이지 로딩 시간 단축, SEO 향상에 초점

우리는 서버라는 공통점을 찾기보다는 Rendering, Component라는 차이점과 각자의 목적에 집중을 해보면 이해가 더 빠를 수 있을 것입니다.

또한, 차이점으로는

RSC의 코드는 클라이언트에게 전달되지 않음
- SSR의 코드는 JS 번들에 포함되어 모두 클라이언트로 전송
RSC의 컴포넌트는 페이지 레벨과 상관없이 모두 서버에 접근 가능

따라서, RSC는 SSR의 대체가 아닌 보완 추가적인 요소로 사용 가능합니다.

SSR로 초기 HTML 페이지를 빠르게 보여줌
RSC로 클라이언트에게 불필요한 JS 코드를 뺀다(서버 컴포넌트를 통해) 이것으로 JS 번들 사이즈를 줄이기 가능

두 방식을 적절하게 사용하면 사용자에게 기존보다 훨씬 빠르게 인터랙티브한 페이지를 제공할 수 있을 것입니다.

마무리 말

Next로 개발을 진행하며, 이름은 알지만 실제적으로 어떻게 동작하는지 무엇을 위해 나왔는지는 이해하지 못하는 것들이 꽤나 많았습니다. SSR, RSC 등을 렌더링 과정부터 살펴보며 이해를 해보니 SSR과 RSC가 무엇이 다른지, 왜 쓰는지 인지할 수 있었습니다.

무조건적으로 좋다기보다는 해당 기술이 필요할 때 사용한다는 개념으로 적재적소에 잘 활용하는 법을 익혀야겠습니다.