프런트 엔드 아키텍처에 큰 변화를 가져온 React Server Components (RSC). 이름은 듣지만 SSR(서버사이드 렌더링)과 무엇이 다른지, 뒷면에서 어떤 처리가 움직이고 있는지를 정확하게 파악하고 있습니까? 본 기사에서는, 그 기술적인 구조를 깊이 파고, 실무에서의 활용 사례를 고찰합니다.
SSR과의 결정적인 차이
기존 SSR은 초기 로드 시 서버 측에서 HTML을 생성하여 브라우저로 반환하는 기술이었습니다. 그러나 그 후 브라우저 측에서 JavaScript를 읽고 구성 요소를 다시 실행 (하이드레이션)하여 대화 형 상태로 만들 필요가있었습니다. 즉, 컴퍼넌트의 코드 자체는 결국 브라우저에 다운로드되고 있었던 것입니다.
반대로 RSC는 ** “서버에서만 실행되며 브라우저에 절대 전송되지 않는 구성 요소”**입니다. RSC는 서버에서 처리된 후 HTML이 아닌 특수 JSON에 가까운 형식으로 직렬화되어 클라이언트로 전송됩니다. 브라우저 측은 이 데이터를 받아서 DOM에 반영시킬 뿐입니다.
번들 크기의 극적인 감소
이 메커니즘이 가져오는 가장 큰 혜택은 클라이언트 측으로 보내는 JavaScript 번들 크기를 줄입니다.
예를 들어, 마크다운을 HTML로 변환하는 무거운 라이브러리(예: marked)를 사용하는 경우를 생각해 봅시다. 이것을 RSC로 구현하면, 퍼스 처리는 모두 서버에서 행해지기 때문에, 무거운 라이브러리의 코드가 유저의 브라우저에 다운로드 되는 일은 없습니다. 이것은 모바일 환경의 성능에 혁명적인 개선을 가져온다.
Client Boundary(경계선)의 설계가 간
RSC를 다룰 때 가장 어려운 것은 서버 및 클라이언트 구성 요소의 테두리 디자인입니다.
RSC는 서버에서 작동하기 때문에 onClick과 같은 이벤트 핸들러와 상태 관리 (useState)를 가질 수 없습니다. 그들이 필요한 끝 부분 (버튼과 입력 양식) 만 클라이언트 구성 요소가되어야합니다.
「데이터 취득이나 무거운 처리는 트리의 상층(서버)에서 실시해, 유저 조작이 필요한 잎의 부분만을 클라이언트로 한다」라고 하는 트리 구조의 설계 사상이 요구됩니다.
실용적인 활용 사례
실무에서 RSC가 가장 빛나는 것은 다음과 같은 유스 케이스입니다.
- 블로그나 미디어 아티클 표시: 앞에서 설명한 마크다운 변환과 같이 정적 콘텐츠 그리기는 RSC의 독단장입니다.
- 데이터베이스에 직접 액세스: RSC는 서버 환경이므로 보안에 직접 데이터베이스에 쿼리를 던질 수 있습니다. API 계층을 하나 생략할 수 있으므로 개발의 번거로움을 줄일 수 있습니다.
- SEO 중시의 랜딩 페이지: 초기 로드가 빠르고, 여분의 JS가 없기 때문에, Core Web Vitals의 스코어 개선에 직결합니다.
RSC는 기존의 React를 대체하는 것이 아니라 클라이언트와 서버의 “역할 분담"을 명확히 하는 새로운 무기입니다. 그 구조를 올바르게 이해하고 적절하게 설계에 통합하는 것이 앞으로의 프런트 엔드 개발의 핵심이 될 것입니다.