react.dev는 컴포넌트를 'a JavaScript function that you can sprinkle with markup'이라고 정의합니다. DOM을 만드는 함수라고 정의하지 않습니다.

이건 RSC 이전부터 이미 그랬습니다. 같은 컴포넌트 모델(props를 받고 JSX를 반환하고 서로 합성되는 구조)이 렌더러만 바뀌면 완전히 다른 결과물을 만듭니다. react-dom은 DOM, react-native는 iOS/Android 네이티브 뷰, react-pdf는 PDF, ink는 터미널 텍스트로 렌더링합니다.

서버 컴포넌트도 마찬가지입니다. props를 받고, JSX를 반환하고, 다른 컴포넌트의 children으로 끼워지는 동일한 합성 모델을 그대로 따릅니다. 다른 건 어디서 실행되는지(서버)와 결과물이 뭐가 되는지(RSC payload로 직렬화)뿐이라, '컴포넌트'라는 이름을 그대로 씁니다.

다만 웹앱에서는 서버 컴포넌트가 만든 결과가 DOM과 아예 무관하진 않습니다. 그 payload를 클라이언트가 받아 결국 HTML/DOM으로 반영합니다. 컴포넌트 자체가 실행되는 시점·환경에 DOM/브라우저가 없다는 것이지, 최종 결과가 DOM에 안 쓰인다는 뜻은 아닙니다.

RSC와 RCC는 같은 React 컴포넌트처럼 보이지만 실행 환경이 다릅니다. RSC는 서버에서 렌더링된 결과가 React의 직렬화 가능한 형태(RSC Payload)로 클라이언트에 전달됩니다. 클라이언트는 이 payload를 받아 DOM에 반영하지만, RSC 코드 자체는 클라이언트로 오지 않습니다.

RCC는 'use client' 경계 이후에 있는 컴포넌트 트리입니다. 클라이언트 번들에 포함되고 브라우저에서 실행됩니다. RSC 안에 RCC를 자식으로 넣을 수 있지만, RCC 안에 RSC를 직접 import하면 RCC로 변환됩니다. RSC를 RCC의 children prop으로 넘기는 패턴을 쓰면 RSC 특성을 유지할 수 있습니다.

이 값을 들고 있는 대상(React의 fiber)은 setState가 호출될 때까지 계속 살아있어야 합니다. 브라우저는 탭이 열려있는 동안 JS 프로세스가 안 꺼지니 가능하지만, 서버는 요청 하나 처리하고 응답을 보내면 그 실행 컨텍스트가 끝납니다. 다음에 뭔가 바뀌었을 때 이어서 실행할 대상 자체가 남아있지 않습니다.

Server Component와 Client Component는 겉보기엔 똑같은 컴포넌트지만, 빌드 시점에 완전히 다르게 취급됩니다. 'use client'가 붙은 파일은 그 코드 전체가 client bundle에 실제로 포함되어 브라우저로 전송됩니다. onClick 핸들러가 클릭되는 순간 실행될 수 있는 건, 그 함수 코드 자체가 번들 안에 물리적으로 존재하기 때문입니다.

반면 Server Component는 정의상 코드 자체를 클라이언트로 절대 보내지 않는 컴포넌트입니다. 서버에서 실행한 결과(RSC payload)만 보내고, 소스 코드는 번들에 포함되지 않습니다. 그래서 Server Component 안에 onClick을 적어도, 그 함수가 실행될 코드 자체가 브라우저에 존재할 방법이 없습니다. Client Component처럼 코드를 번들에 넣기로 설계됐다면 가능했겠지만, Server Component는 정의상 그 번들링 과정에서 빠지는 컴포넌트입니다.

여기에 더해, 설령 함수를 런타임에 전달하려 해도 onClick은 함수이고 RSC payload는 직렬화 가능한 값(문자열, 숫자, 객체)만 담을 수 있어서 함수 자체를 서버에서 클라이언트로 전달할 방법도 없습니다.

브라우저 API(window, document, localStorage 등)를 못 쓰는 이유도 같은 계열입니다. 코드가 브라우저에서 실행돼야 접근 가능한데, 서버는 브라우저 환경 자체가 아니라서 애초에 없습니다.

useState와 원인은 같은 계열입니다. 구독 관계를 유지하려면 Provider와 그걸 구독하는 컴포넌트들이 렌더링이 끝난 뒤에도 메모리에 남아 있어야 하는데, Server Component는 요청 하나 처리하고 결과를 반환하면 그 트리가 사라집니다. 다시 값이 바뀌었을 때 알려줄 대상 자체가 없습니다.

그래서 Context를 쓰려면 Provider 자체를 Client Component로 만들고, children을 감싸는 방식으로 서버 컴포넌트와 연결합니다.

// Provider는 Client Component여야 한다
'use client';
export function ThemeProvider({ children }: { children: React.ReactNode }) {
  return <ThemeContext.Provider value="dark">{children}</ThemeContext.Provider>;
}

Server Component는 이 Provider를 그대로 import해서 렌더링할 수 있습니다. Provider 자체는 Client Component지만, 그 children으로 들어가는 Server Component는 여전히 서버에서 렌더링됩니다.

// Server Component가 Client Component인 Provider를 감싸는 건 가능하다
export default function RootLayout({ children }: { children: React.ReactNode }) {
  return <ThemeProvider>{children}</ThemeProvider>;
}

SSR(Server-Side Rendering)의 흐름은 서버에서 HTML을 만들어 클라이언트로 보내고, 클라이언트가 이 HTML에 JS를 붙이는(hydration) 과정입니다. 사용자는 JS 로딩 전에 이미 HTML을 볼 수 있지만, JS가 붙기 전까지 인터랙션이 안 됩니다.

RSC는 다릅니다. 서버에서 실행되고 결과가 클라이언트로 오지만, 클라이언트 JS에서 해당 컴포넌트를 hydration할 필요가 없습니다. RSC 코드 자체가 클라이언트 번들에 없기 때문입니다. 상태와 이벤트가 없으니 hydration이 필요하지 않습니다.

Next.js App Router에서는 RSC에 SSR이 함께 적용됩니다. RSC는 서버에서 실행되고, 그 결과가 HTML로 클라이언트에 먼저 내려갑니다. 클라이언트 컴포넌트 부분만 hydration이 필요합니다.

Next.js 공식 문서는 RSC payload를 'a compact binary representation of the rendered React Server Components tree'라고 정의합니다. 여기엔 세 가지가 들어 있습니다.

1. Server Component가 렌더링된 결과 (HTML 문자열이 아니라 React가 다시 조립할 수 있는 직렬화된 트리 형태)
2. Client Component가 렌더링돼야 할 위치의 placeholder와, 어떤 JS 파일을 로드해야 하는지에 대한 참조
3. Server Component에서 Client Component로 넘겨준 props

최초 페이지 로드에서는 HTML, RSC payload, JS 세 가지가 각자 다른 역할을 합니다. HTML은 인터랙션 없는 화면을 빠르게 보여주는 용도, RSC payload는 Server·Client 컴포넌트 트리를 React가 다시 맞추는(reconcile) 용도, JS는 Client Component를 hydrate해서 인터랙션 가능하게 만드는 용도입니다. 셋이 같이 와야 완전한 페이지가 됩니다.

이후 클라이언트 사이드 네비게이션에서는 다릅니다. 이때는 HTML을 다시 받지 않고 RSC payload만 새로 받아서(prefetch·캐시까지 됨), 이미 브라우저에 떠 있는 Client Component 트리는 그대로 유지한 채 Server Component 부분만 이 payload로 갱신합니다. 그래서 전체 리로드 없이 페이지를 이동하면서도 서버의 최신 데이터를 반영할 수 있습니다.

SSR 없이 SPA로 동작하면 브라우저는 빈 HTML을 받고 JS가 모두 로드된 후에야 화면을 그립니다. SSR을 쓰면 서버가 이미 렌더링된 HTML을 보내 사용자가 빠르게 내용을 볼 수 있습니다. 하지만 이 HTML은 정적입니다. 버튼이 보여도 클릭이 안 됩니다.

Hydration은 JS가 로드된 후 React가 이 HTML을 훑으며 이벤트 핸들러를 붙이고 상태를 초기화하는 과정입니다. Hydration이 끝나야 인터랙션이 가능해집니다.

Hydration 비용이 크면 사용자가 버튼을 클릭해도 반응이 없는 구간이 생깁니다. RSC가 클라이언트 번들을 줄이면 Hydration할 코드도 줄어 이 구간이 짧아집니다.

혼동하기 쉬운 지점은 '클라이언트에서 실행된다'와 '서버에서 실행 안 한다'를 같은 뜻으로 여기는 것입니다. 둘은 다른 축입니다.

Server Component는 서버에서만 실행되고 클라이언트 번들에 전혀 포함되지 않습니다. Client Component('use client')는 서버에서도 실행되고(최초 HTML을 만들기 위해) 클라이언트에서도 다시 실행됩니다(hydration으로 인터랙션을 붙이기 위해). 즉 'use client'는 실행 범위를 서버에서 클라이언트로 '옮기는' 게 아니라 클라이언트 실행을 '추가하는' 지시어입니다.

진짜 'CSR로만 동작'하는 상황은 서버가 아예 렌더링을 건너뛰고 최소한의 뼈대 HTML만 주는 경우입니다. 이건 'use client'만으로는 안 되고, next/dynamic(() => import(...), { ssr: false })처럼 명시적으로 SSR을 꺼야 발생합니다. 주로 window, document 같은 브라우저 전용 API를 초기 렌더링 시점에 쓰는 라이브러리(지도, 차트 등)에 사용합니다.

클라이언트 컴포넌트에서는 마운트 후 useEffect에서 fetch를 시작합니다. 부모가 마운트되어야 자식이 마운트되고, 자식이 마운트되어야 자식의 fetch가 시작됩니다. 중첩이 깊을수록 waterfall이 생깁니다.

RSC에서는 서버에서 여러 fetch를 동시에 실행할 수 있습니다. Promise.all로 병렬 요청이 가능하고, 서버와 DB 사이의 지연이 클라이언트와 서버 사이보다 훨씬 짧습니다. API route를 만들어 클라이언트에서 호출하는 단계가 없어집니다.

async function Dashboard() {
  // 병렬로 동시에 가져옴
  const [user, posts] = await Promise.all([
    db.users.findOne({ id: userId }),
    db.posts.findMany({ authorId: userId }),
  ]);
  return <DashboardView user={user} posts={posts} />;
}

예를 들어 markdown을 파싱해 HTML로 변환하는 라이브러리(remark, unified 등)는 수십 KB입니다. 클라이언트 컴포넌트에서 쓰면 이 라이브러리 전체가 번들에 포함됩니다. RSC에서 쓰면 서버에서 파싱이 끝나고 HTML만 클라이언트로 내려오므로 라이브러리가 번들에 포함되지 않습니다.

날짜 포맷팅(date-fns, dayjs), 코드 하이라이터(shiki, prism), 암호화 라이브러리도 마찬가지입니다. 서버에서만 실행되면 클라이언트 번들에서 완전히 제거됩니다.

이 블로그도 RSC를 씁니다. MDX 파싱과 코드 하이라이팅이 서버에서 일어나서 관련 라이브러리가 클라이언트 번들에 포함되지 않습니다.