React Server Component가 무엇인가요?
RSC(React Streaming Component)는 React 18에서 소개된 새로운 개념으로 크게 두가지의 특징을 가지는 컴포넌트입니다.
- 컴포넌트 단위로 server에서 랜더링
- 클라이언트에게 스트리밍 전송
18버전 이전의 React 모든 컴포넌트들은 Client에서 랜더링 되었으며, 만약 Next.js와 같은 프레임워크를 사용하여 SSR을 수행하더라도 페이지 단위로만 가능했습니다. RSC는 기존의 SSR방식을 보완하여 더 세밀한 컴포넌트 단위의 렌더링을 가능하게 해주었습니다. 이를 활용한다면 페이지 내부에 특정 컴포넌트만 클라이언트에게 랜더링을 맡김으로써 전체적인 페이지 성능에 미치는 영향을 최소화할 수 있습니다.
게다가 RSC는 클라이언트에게 JSON 형식으로 스트리밍되어 전송됩니다. 이를 통해 클라이언트 측에서 HTML을 동적으로 바꿔주는 하이드레이션 단계를 생략할 수 있습니다. 이는 자바스크립트 코드 양을 줄여 로드 시간을 단축시켜 전반적인 사용자 경험(UX)을 향상시킬 수 있습니다.
React Server Component 등장 배경은 무엇인가요?
만약 위의 설명처럼 SSR이 로드 시간을 줄여줘 UX를 개선해준다면 모든 페이지를 서버에서 랜더링 해주면 되는것이 아닐까? 하는 의문이 생길 수 있습니다. 왜 React에서는 SSR/CSR을 동시에 활용하는 기능을 제공하게 되었는지를 랜더링 방식의 역사와 함께 살펴보도록 합시다.
1. SSR(ex, PHP)
초기 웹 애플리케이션은 모든 페이지를 서버 측에서 렌더링하는 방식이었습니다. 이는 매 요청마다 완전한 HTML 페이지를 제공하여 SEO에 유리하고, 초기 로딩 시간이 빠르다는 장점이 있었습니다. 하지만 페이지 이동 시마다 새로고침이 발생하고, 사용자 경험에 부정적인 영향을 미치는 깜빡임 현상이 발생했습니다.
2. CSR/SPA(ex, React, Angular)
위의 단점을 해결하고자 모든 페이지를 한번에 받아와 부드러운 사용자 경험을 제공하는 방식인 SPA가 등장했습니다. 그렇지만 최초의 빈 html을 제공하기 때문에 SEO의 문제, first contentful paint 시간이 오래걸린다는 단점, 클라이언트와 서버 통신을 자주 하면서 발생하는 여러가지 문제들(번들 크기, 보안…) 등 다양한 이슈가 존재했습니다.
3. RSC/RCC
따라서 현재 react에서는 RSC/RCC의 개념을 등장시켰습니다. 이를 활용한다면 서버 측 렌더링의 장점을 유지하면서도 클라이언트 측 렌더링과의 혼합을 가능하게 하여 더 효율적인 랜더링이 가능하도록 해줄수 있습니다.
마무리하며
이와 같이 React Server Component를 통해 랜더링 방식의 진화를 살펴보며 서버 측 렌더링(SSR), 클라이언트 측 렌더링(CSR), 그리고 이를 혼합한 방식의 등장 배경과 장단점에 대해 알아보았습니다.
프론트엔드 생태계는 계속해서 복잡해지고 규모가 커지는 추세에 있습니다. 이러한 변화 속에서 프론트엔드 개발자들은 최고의 사용자 경험을 제공하기 위해 노력하고 있습니다. React의 이러한 발전은 웹 애플리케이션의 성능과 사용자 경험을 향상시키는 데 큰 역할을 할 것으로 기대됩니다.