React Server Components (RSC) 완벽 이해하기: 렌더링 아키텍처의 혁신

React 개발자라면 요즘 매일같이 듣는 단어가 있을 겁니다. 바로 'React Server Components(RSC)'죠.

 

"Next.js 13 이후로 그냥 기본으로 쓰는 거 아니야?" 혹은 "기존 SSR(서버 사이드 렌더링)이랑 이름만 다르고 비슷한 거겠지"라고 생각하며 무심코 넘어가셨나요? 만약 여전히 단순한 텍스트나 정적 데이터를 띄우기 위해 수백 KB의 자바스크립트 번들을 통째로 브라우저에 내려보내고 있다면, 여러분은 지금 React 렌더링 패러다임의 가장 거대한 변화를 놓치고 있는지도 모릅니다.

 

'클라이언트'와 '서버'의 경계를 허물고, 번들 사이즈 0(Zero)의 기적을 만들어내는 RSC. 오늘은 매번 헷갈리던 RSC의 진짜 정체와, 왜 이것이 단순한 기능 추가를 넘어 프론트엔드 아키텍처의 완전한 혁신인지 살펴보겠습니다.

기존 SSR과 RSC의 결정적 차이

많은 개발자가 SSR과 RSC를 혼동합니다. Next.js의 getServerSideProps 같은 기존 SSR은 서버에서 HTML을 완성하여 내려주지만, 상호작용을 위해서는 결국 전체 자바스크립트 번들을 다운로드하고 하이드레이션(Hydration) 과정을 거쳐야 했습니다.

반면, RSC는 렌더링 결과를 HTML이 아닌 직렬화된 특별한 JSON 형태(React Flight 포맷)로 스트리밍합니다.

- SSR: 완성된 '그림(HTML)'을 주고, 나중에 '생명(JS)'을 불어넣음.
- RSC: 서버에서 연산이 끝난 정적인 부분은 JS 코드를 아예 클라이언트로 보내지 않음. 오직 인터랙션이 필요한 부분(Client Component)만 분리하여 로드.

 

핵심 개념: "use client"와 렌더링 경계 (Boundary)

"use client" 지시어는 컴포넌트를 클라이언트에서 렌더링하라는 뜻이 아닙니다. 정확히는 "이 지점부터 서버와 클라이언트의 경계를 나눈다"는 선언입니다.

- 서버 컴포넌트는 클라이언트 컴포넌트를 import 할 수 있습니다. (트리의 잎사귀 역할)
- 주의할 점: 클라이언트 컴포넌트 내부에서는 서버 컴포넌트를 직접 import 할 수 없습니다. 단, children prop을 통해 서버 컴포넌트를 전달받아 렌더링하는 것은 가능합니다. (Composition 패턴)

 

실무 활용: 데이터 페칭(Data Fetching)과 Streaming

RSC의 진가는 비동기 데이터 처리에서 나타납니다. useEffect나 React Query 없이, 컴포넌트 자체를 async/await로 선언하여 서버에서 직접 DB나 API를 호출할 수 있습니다.

// app/users/page.tsx (Server Component)
import { Suspense } from 'react';
import UserList from './UserList'; // 👈 Client Component
import Loading from './Loading';

// 비동기 컴포넌트
export default async function UsersPage() {
  // 브라우저가 아닌 서버 환경에서 직접 DB 쿼리 실행
  const users = await db.query('SELECT * FROM users'); 

  return (
    <main>
      <h1>사용자 목록</h1>
      {/* 데이터가 로딩되는 동안 UI를 먼저 스트리밍 */}
      <Suspense fallback={<Loading />}>
        {/* 직렬화 가능한 데이터(users)만 Client Component로 전달 */}
        <UserList initialData={users} />
      </Suspense>
    </main>
  );
}

 

<Suspense>와 결합된 RSC는 데이터가 준비되는 대로 UI 조각을 클라이언트에 점진적으로 스트리밍하므로, TTFB(Time To First Byte)와 FCP(First Contentful Paint) 지표를 획기적으로 개선합니다.

 

마무리하며: RSC, 프론트엔드의 새로운 표준이 될까?

React Server Components가 가져다주는 이점—제로 번들 사이즈, 직관적인 서버 데이터 페칭, 그리고 빠른 초기 로딩—은 분명 강력합니다. 단순히 컴포넌트를 그리는 방식을 넘어, 브라우저와 서버가 어떻게 협력해야 하는지에 대한 근본적인 패러다임 전환이죠.

 

물론 은탄환은 아닙니다. RSC를 실무에 도입하다 보면 서버와 클라이언트의 렌더링 경계(Boundary)를 나누는 설계 고민부터, 머리를 아프게 하는 복잡한 캐싱(Caching) 전략까지 기존과는 전혀 다른 낯선 문제들을 마주하게 됩니다.

하지만 이 초기 러닝 커브를 넘어서고 나면, 이전의 렌더링 방식으로 돌아가기 힘들 만큼 효율적인 아키텍처를 경험하실 수 있을 것입니다.

 

여러분의 프로젝트는 지금 어디쯤 있나요?

이미 Next.js App Router와 RSC를 실무에 적극적으로 도입해 보셨나요, 아니면 아직은 기존 Page Router나 순수 SPA에 머물며 도입 시기를 재고 계신가요?

 

RSC를 적용하며 겪었던 뼈아픈 트러블슈팅 경험이나(특히 캐싱 이슈 🤯!), 반대로 "이건 정말 신세계다!" 싶었던 점이 있다면 아래 댓글로 자유롭게 공유해 주세요. 다양한 환경에서 고민하는 개발자분들의 생생한 이야기가 궁금합니다!