[ React 18+ ] RSC(React Server Componen) 파헤치기.

 

 

 

RSC는 React Server Components의 약자로, React18 버전부터 등장한 개념이다.

서버에서 컴포넌트를 렌더링 하고 클라이언트에서 이를 효율적으로 활용할 수 있게 해주는 기능으로, 서버와 클라이언트의 역할을 분리하여 사용자 경험 향상을 위해 등장한 기능이다.

 

RSC는 React의 자체적인 기능이기 때문에 꼭 Next.js를 사용하지 않고도 구현할 수 있지만, RSC는 서버-클라이언트의 상호작용이 필요하기 때문에 Node.js기반의 서버 환경이 필요하다. 그래서 Next.js를 사용하지 않는다면 Express.js 같은 라이브러리를 사용하여 HTTP 서버를 만들고, 서버-클라이언트 스트리밍,  Webpack 번들링(서버 / 클라이언트), 데이터 통신, 성능 최적화(캐싱) 등의 추가적인 설정을 직접 해야 해서 복잡도가 높아진다.

 

Next.js는 기본적으로 서버에서 fetch()하여 데이터를 받고, 렌더링까지 모두 서버 쪽에서 구현이 된다.

fetch()는 브라우저의 web API이지만, LTS버전(18 이상) Node.js에서는  fetch() API가 내장되어 있기 때문에 가능하며, 서버컴포넌트에서 node.js의 Fetch API를 사용하고, 클라이언트에서 fetch를 사용할 때는 브라우저의 fetch API를 사용한다.

 

RSC는 Next.js 13+ App Router에서만 사용할 수 있다. Next.js의 Pages Router에서 사용할 수 없는 이유는, Pages Router의 설계가 RSC의 핵심 요구사항과 맞지 않기 때문이다. 서버 중심 데이터 처리, 점진적 렌더링, 번들 최적화, Suspense 기반 동작 등을 지원하지 않기 때문에 RSC를 사용할 수 없다. 이를 해결하기 위해 설계된 것이 Next.js 13+ App Router 이다.

 

---

 

RSC 등장 배경

React Server Components(RSC)가 나온 이유는 성능 문제 해결 및 개발자의 생산성을 높이기 위해 등장하였다. 기존 React와 SSR 모델만으로는 해결하기 어려웠던 몇 가지 근본적인 한계를 극복하고 클라이언트 중심 렌더링과 서버 중심 렌더링의 장점을 결합하려는 등 다음과 같은 목적을 가지고 React.js 18에서 등장했다.

 

---

 

서버 컴포넌트와 클라이언트 컴포넌트의 차이점

특징	서버 컴포넌트	클라이언트 컴포넌트
실행 환경	서버에서 실행	브라우저에서 실행
데이터 접근	서버 자원(DB, 파일 시스템 등)에 직접 접근 가능	API 요청을 통해 서버 데이터에 접근
번들 크기 포함 여부	클라이언트로 번들되지 않음	클라이언트로 번들됨
상호작용 가능 여부	사용자 상호작용 처리 불가능	사용자 상호작용 처리 가능
사용 예	데이터 로드, SEO 친화적인 HTML 생성	버튼 클릭, 입력 이벤트 처리, 상태 관리

 

 

1. 클라이언트 중심 렌더링(CSR)의 한계 극복

 

2. 서버와 클라이언트 간의 역할을 분리하여 번들 크기 최적화

 

3. SEO와 초기 로딩 속도 개선

 

4. 점진적 하이드레이션(Hydration)을 통해 초기 렌더링 비용 감소

 

5. 서버와 클라이언트 로직을 명확히 분리해 개발자 경험 개선

 

6. 현대 애플리케이션의 복잡성과 요구 사항 충족

---

 

 

그럼 이전에는 위와 같은 문제가 있음에도 불구하고 RSC를 도입할 수 없었던 이유가 무엇일까? 그건 React의 초기 설계와 관련된 기술적 / 구조적 한계와, RSC의 주요 기능이 React.js 18에서 도입된 새로운 아키텍처와 API에 의존하기 때문이다.

 

 

기존 React의 한계점

 

1. 동시성기능 (Concurrency Features)의 부재

React.js 18 이전에는 동시성(Concurrency) 개념이 React에 존재하지 않았다. RSC는 동시성을 활용하여 서버와 클라이언트 간의 작업을 병렬로 수행하거나, Suspense를 통해 데이터를 스트리밍으로 점진적으로 렌더링 할 수 있어야 한다.

 

-> React.js 18 에서 추가된 동시성 기능은 React Suspense를 통해 데이터를 기다리는 동안 로딩 상태를 제공하면서, 점진적으로 UI를 렌더링 할 수 있게 해주는데, RSC는 이 점진적 렌더링을 핵심으로 한다. 또한 Streaming Rendering을 통해 서버에서 클라이언트로 데이터를 스트리밍하며, 필요한 부분만 빠르게 렌더링할 수 있다.

 

 

2. 서버 컴포넌트와 클라이언트 컴포넌트의 구분의 어려움

RSC는 서버 컴포넌트와 클라이언트 컴포넌트를 명확히 구분하여 서버에서 실행되는 컴포넌트는 클라이언트로 번들되지 않도록 설계되었다. 그러나 React.js 18 이전에는 이런 구분을 위한 기술적 지원이 없었다. (React.js 18 이후에는. server.js / .client.js 의 명시적인 파일 확장자를 통해 React가 컴포넌트를 자동으로 구분한다.)

 

-> RSC는 서버 컴포넌트와 클라이언트 컴포넌트를 명확히 구분해서 서버에서 실행되는 컴포넌트는 클라이언트로 번들되지 않도록 설계되었으나, React.js 18 이전에는 이런 구분을 위한 기술적 지원이 없었다. (이전에는 React 앱의 모든 컴포넌트가 번들링 과정에서 클라이언트로 전송되고, 브라우저에서 실행되도록 설계되어 있었기 때문에, 서버에서만 실행되도록 설계된 코드를 클라이언트로 보내지 않는 게 불가능했었음.)

 

 

3. 서버 렌더링의 제약(Old SSR Model)

React.js 18 이전의 서버 렌더링 모델은 제한된 기능만 제공되었다. 기존 SSR은 전체 HTML을 서버에서 렌더링 하고 클라이언트로 전송한 후, 클라이언트에서 이를 하이드레이션 하는 방식으로 동작했는데, 이 방식은 RSC와 충돌했다. 

-> React.js 18 이전에는 클라이언트 중심의 하이드레이션으로 동작했기 때문에 서버에서 렌더링 된 컴포넌트를 다시 클라이언트로 번들해야 했고, 모든 데이터를 서버에서 준비한 후 한 번에 클라이언트로 보내는 방식을 사용하여 RSC가 요구하는 데이터 스트리밍 방식이 지원되지 않았다.

 

 

4. React Suspense의 제한적인 지원

 React.js 16에서 도입된 React Suspense는, 18 이전에는 클라이언트에서만 제한적으로 작동하였다. 서버에서는 Suspsnse를 사용할 수 없었기 때문에 서버에서 컴포넌트가 데이터를 기다리는 동안 UI를 점진적으로 렌더링 하는 기능이 불가능했다. RSC는 Suspense를 통해 서버와 클라이언트 간의 작업을 조율하기 때문에 이를 제대로 지원하려면 18의 개선된 Suspense가 필요했다.

 

 

5. 데이터 페칭과 서버 로직의 분리 문제

React.js 18 이전에는 데이터 페칭 로직과 UI 렌더링 로직이 완전히 분리되지 않았기 때문에 컴포넌트에서 데이터 페칭을 처리하면 클라이언트에서 실행되는 코드에도 동일한 데이터 페칭 로직이 포함되는 문제가 있었다. React.js 18 이전에는 서버와 클라이언트 간 데이터 흐름이 명확하지 않았기 때문에 서버에서 데이터 페칭을 수행하면서도 클라이언트에서 불필요한 로직이 포함되는 번들 크기 증가 문제가 있었다.

 

 

6. Streaming Rendering 프로토콜의 부재

React.js 18에서는 서버와 클라이언트가 데이터와 컴포넌트를 교환할 때 사용하는 Streaming Rendering 프로토콜이 도입되어 컴포넌트를 직렬화된 데이터 형태로 클라이언트에 전송하고 클라이언트에서 이것을 효율적으로 처리하도록 돕는데, 이전에는 이런 메커니즘이 없었다. 

 

 

 

---

 

RSC 동작 원리

 

 

1. 서버와 클라이언트 컴포넌트의 분리

 

서버 컴포넌트 

- 서버에서 실행되며, 클라이언트로 번들되지 않기 때문에, 클라이언트로 전송되는 번들 크기가 줄어들어, 초기 로딩 속도가 빨라진다.

- 주로 데이터 페칭이나 CPU 집약적인 작업을 처리한다.

- HTML이나 React 요소의 "직렬화된 형태(serialized form)"로 클라이언트에 전달된다.

- React에서 파일 확장자(.server.js)로 구분한다.

 

클라이언트 컴포넌트

- 브라우저에서 실행되며, 클라이언트로 번들된다.

- 사용자와의 상호작용(interaction)을 담당한다.

- React에서 파일 확장자(.client.js)로 구분한다.

 

 

 

2. 서버에서 렌더링 (Rendering on Server)

 

클라이언트 요청 처리

- 사용자가 페이지를 요청하면 서버는 해당 페이지를 구성하는 서버 컴포넌트 트리를 처리한다.

 

데이터 페칭

- 서버 컴포넌트는 서버 환경에서 실행되므로 데이터베이스, REST API, GraphQL 등과 직접 통신할 수 있다.

- 데이터가 준비되면 이를 React 컴포넌트로 렌더링(Hydration)한다.

 

출력 생성

- 서버 컴포넌트는 클라이언트 컴포넌트를 호출하거나 포함할 수 있음. 하지만 클라이언트 컴포넌트는 서버에서 실행되지 않고, '참조'로만 남는다.

- 서버 컴포넌트는 클라이언트에서 사용할 수 있도록 직렬화된 JSON 형식의 데이터로 출력된다.

 

 

 

3. 직렬화된 데이터의 클라이언트 전송

 

- 서버에서 렌더링 된 결과는 JSON 형태로 (UI의 HTML, 컴포넌트 상태, 트리 구조, 클라이언트 컴포넌트의 참조 정보 등을 포함) 클라이언트에 전송된다.

// json파일 형태

{
  "type": "div",
  "props": {
    "children": [
      {
        "type": "h1",
        "props": {
          "children": "Hello World"
        }
      },
      {
        "type": "$RC", // 클라이언트 컴포넌트를 참조하는 토큰
        "id": "ClientComponent123",
        "props": {
          "data": "example data"
        }
      }
    ]
  }
}

 

- 클라이언트는 이 데이터를 React의 특수한 프로토콜을 사용하여 다시 결합하고 렌더링 한다.

 

 

 

4. 클라이언트에서의 하이드레이션(Hydration on Client)

 

HTML과 JSON 데이터 결합

- 서버에서 생성된 HTML과 JSON 데이터를 사용해 클라이언트는 초기 UI를 구성한다.

- 클라이언트 컴포넌트가 포함된 부분은 초기에는 'place holder'로 렌더링 되다가 이후 번들 파일이 로드되면 React가 하이드레이션을 통해 활성화한다.

 

점진적 하이드레이션

- 클라이언트는 필요한 부분만 점진적으로 하이드레이션(Hydration)을 수행한다.

- 사용자 상호작용이 없는 부분은 미뤄질 수 있어 성능 최적화가 가능하다.

 

 

 

5. 서버 컴포넌트와 클라이언트 컴포넌트 간의 조합

 

서버 컴포넌트 내부에서 클라이언트 컴포넌트 사용

- 서버 컴포넌트가 렌더링 되면 Client Component는 클라이언트에서 실행될 정보만 포함된 상태로 전송된다.

// JSX
import ClientComponent from './ClientComponent.client';

export default function ServerComponent() {
  return (
    <div>
      <h1>Server Rendered Content</h1>
      <ClientComponent /> {/* 클라이언트에서만 실행됨 */}
    </div>
  );
}

 

 

 

6. RSC의 특수 프로토콜

 

React는 서버와 클라이언트 간 데이터 교환을 효율적으로 처리하기 위해, 자체적인 프로토콜 사용.

- 이 프로토콜은 서버에서 JSON 형태의 데이터를 전송하면서 클라이언트에서 필요할 때만 React 요소를 재조합한다.

- 이 과정에서 컴포넌트가 서로 다른 환경에서 실행되는 것을 효율적으로 분리하고 결합한다.

- React Server Components의 특수 프로토콜은 JSON 직렬화, 컴포넌트 참조 토큰, 스트리밍 데이터를 기반으로 서버와 클라이언트 간의 역할을 최적화하기 때문에 RSC는 번들 크기를 줄이고, 초기 로딩 속도를 높이며, 사용자 경험을 개선할 수 있다.

 

 

 

7. RSC의 Lazy Loading + Suspense와의 조합

 

- 서버에서 렌더링 된 데이터와 클라이언트 컴포넌트를 효율적으로 로드하고 렌더링 할 수 있다. 이 두 가지 기능이 RSC와 결합되면, 컴포넌트를 필요한 시점에 지연로드(lazy load)하여, 네트워크 트래픽을 최소화하고, 사용자 경험을 크게 향상할 수 있다.

// JSX
import React, { Suspense } from 'react';

const LazyServerComponent = React.lazy(() => import('./ServerComponent.server'));

export default function App() {
  return (
    <Suspense fallback={<div>Loading...</div>}>
      <LazyServerComponent />
    </Suspense>
  );
}

 

- React.lazy는 동적으로 컴포넌트를 로드(코드 스플리팅)하는 기능으로, 필요할 때만 해당 컴포넌트의 코드를 네트워크를 통해 가져와서 렌더링 한다. (초기 번들 크기 축소 및 앱의 초기 로딩 속도 향상)

- Suspense는 React.lazy와 함께 사용되며, 컴포넌트가 로드되는 동안 로딩상태(Placeholder)를 보여주는 역할을 하여 결과적으로 React는 비동기적으로 컴포넌트를 로드하고, 컴포넌트 로드가 완료될 때까지 Suspense가 대체 UI를 렌더링 한다.

 

 

---

 

 

RSC 흐름 정리

 

1. 서버 컴포넌트는 서버에서 실행되고, 클라이언트 컴포넌트는 필요할 때만 로드됨.

 

2. React.lazy를 사용해 클라이언트 컴포넌트를 동적으로 가져옴.

 

3. Suspense를 통해 컴포넌트 로드가 완료될 때까지 로딩 상태를 제공.

 

4. React는 스트리밍 데이터와 Suspense를 결합하여 UI를 점진적으로 렌더링 함.

 

 

---

 

 

RSC 장점

 

 

성능 최적화

• JavaScript 번들 크기 감소 : 서버 컴포넌트는 브라우저에서 실행되지 않으므로, 클라이언트로 전달되는 JavaScript 번들 파일에서 완전히 제외되고, 이에 따라 초기 로딩속도가 빨라진다.
• 사용자 경험 향상 : 서버에서 HTML을 스트리밍 방식으로 클라이언트에 전달하여 초기 로딩 속도를 크게 개선하고, 사용자가 데이터를 기다리는 동안에도 화면의 일부를 먼저 볼 수 있어 사용자 경험이 크게 향상된다. 
• 보안 강화 : 서버에서만 실행되기 때문에 민감한 로직이나  API 키 같은 정보는 서버에서만 실행되기 때문에 브라우저에 노출되지 않음.
• 효율적인 렌더링 : 서버에서 필요한 데이터를 바로 처리하고, UI를 생성하기 때문에, 클라이언트가 데이터를 가져오고 렌더링 하는 부담이 줄어든다. 

 

개발자 경험(DX) 개선

• 서버와 클라이언트의 명확한 역할 분리 : 서버 컴포넌트와 클라이언트 컴포넌트를 구분하여 유지보수가 쉬워지고, 데이터 처리와 UI로직이 명확히 분리되어 코드가 더 간결해진다.
• 데이터 페칭 로직 간소화 : 데이터는 서버 컴포넌트에서 직접 가져오기 때문에 클라이언트에서 별도의 데이터 요청 로직이나 상태 관리가 필요하지 않다.
• SEO 친화적 : 서버에서 HTML을 생성하기 때문에 검색 엔진이 쉽게 콘텐츠를 크롤링할 수 있어 SEO 최적화에 유리하다.
• 리팩토링 용이 : 클라이언트와 서버의 역할이 명확히 나뉘어 코드 변경 시 영향 범위가 줄어든다.

 

유연한 UI 개발

• 클라이언트와 서버의 조합 : 클라이언트 컴포넌트와 서버 컴포넌트를 혼합하여 사용할 수 있다. 예를 들어, 서버에서 데이터를 미리 렌더링 하고 클라이언트에서 상호작용을 추가하는 방식이 가능해진다. 
• 점진적 업그레이드 가능 : 기존 React 앱에서도 일부 컴포넌트를 RSC로 전환하며 점진적으로 적용할 수 있고, 전체 리팩토링이 필요하지 않아 기존 프로젝트에 쉽게 도입이 가능하다.

 

최신 웹 아키텍처와의 부드러운 통합

• RSC는 최선 웹 아키텍처(Edge Computing, CDN, Serverless 등)와 잘 맞는다.
• Vercel이나, Netlify 같은 서버리스 플랫폼과의 연동에서 최적화된 성능 제공

 

 

---

 

기존 React와 RSC의 개선점 정리

기존 React	RSC 개선점
클라이언트에서 모든 컴포넌트를 실행	서버에서 HTML을 생성, 클라이언트에 결과만 전송
초기 로딩 속도가 느림	스트리밍 렌더링으로 초기 화면을 빠르게 표시
데이터 페칭과 UI 결합	데이터는 서버 컴포넌트에서만 처리, 클라이언트에 불필요한 로직 제거
JavaScript 번들 크기 큼	클라이언트에 필요한 JavaScript만 전송
SEO에 불리함	서버에서 생성된 HTML로 SEO 최적화

 

 

---