React Flight 파헤치기: 서버 컴포넌트를 구동하는 직렬화 프로토콜

웹 개발의 세계는 끊임없이 진화하고 있습니다. 수년 동안 지배적인 패러다임은 클라이언트에 최소한의 HTML 셸을 보낸 다음, 클라이언트가 데이터를 가져와 JavaScript를 사용하여 전체 사용자 인터페이스를 렌더링하는 싱글 페이지 애플리케이션(SPA)이었습니다. 이 모델은 강력하지만, 큰 번들 크기, 클라이언트-서버 데이터 폭포 현상, 복잡한 상태 관리와 같은 문제점을 야기했습니다. 이에 대한 대응으로, 커뮤니티는 현대적인 감각을 더한 서버 중심 아키텍처로의 중요한 회귀를 목격하고 있습니다. 이 진화의 최전선에는 React 팀이 내놓은 획기적인 기능인 React 서버 컴포넌트(RSC)가 있습니다.

하지만 서버에서만 독점적으로 실행되는 이 컴포넌트들은 어떻게 마법처럼 나타나 클라이언트 측 애플리케이션에 매끄럽게 통합될 수 있을까요? 그 해답은 덜 알려졌지만 매우 중요한 기술인 React Flight에 있습니다. 이것은 여러분이 매일 직접 사용할 API는 아니지만, 이를 이해하는 것은 현대 React 생태계의 잠재력을 최대한 활용하는 열쇠입니다. 이 글에서는 React Flight 프로토콜을 심층적으로 파헤쳐 차세대 웹 애플리케이션을 구동하는 엔진의 비밀을 밝혀보겠습니다.

React 서버 컴포넌트란 무엇인가? 간단한 복습

프로토콜을 분석하기 전에, React 서버 컴포넌트가 무엇이고 왜 중요한지 간단히 복습해 보겠습니다. 브라우저에서 실행되는 기존의 React 컴포넌트와 달리, RSC는 서버에서만 독점적으로 실행되도록 설계된 새로운 유형의 컴포넌트입니다. 이들은 절대로 JavaScript 코드를 클라이언트로 보내지 않습니다.

이러한 서버 전용 실행은 몇 가지 획기적인 이점을 제공합니다:

제로 번들 사이즈: 컴포넌트의 코드가 서버를 떠나지 않기 때문에, 클라이언트 측 JavaScript 번들에 전혀 기여하지 않습니다. 이는 특히 복잡하고 데이터가 많은 컴포넌트의 경우 성능 면에서 엄청난 이점입니다.
직접적인 데이터 접근: RSC는 API 엔드포인트를 노출할 필요 없이 데이터베이스, 파일 시스템 또는 내부 마이크로서비스와 같은 서버 측 리소스에 직접 접근할 수 있습니다. 이는 데이터 가져오기를 단순화하고 클라이언트-서버 요청 폭포 현상을 제거합니다.
자동 코드 분할: 서버에서 렌더링할 컴포넌트를 동적으로 선택할 수 있기 때문에, 효과적으로 자동 코드 분할을 얻을 수 있습니다. 상호작용이 가능한 클라이언트 컴포넌트의 코드만 브라우저로 전송됩니다.

RSC를 서버 측 렌더링(SSR)과 구별하는 것이 중요합니다. SSR은 전체 React 애플리케이션을 서버에서 HTML 문자열로 미리 렌더링합니다. 클라이언트는 이 HTML을 받아 표시한 다음, 전체 JavaScript 번들을 다운로드하여 페이지를 '하이드레이션'하고 상호작용이 가능하게 만듭니다. 반면, RSC는 UI의 특별하고 추상적인 설명(HTML이 아닌)으로 렌더링되며, 이는 클라이언트로 스트리밍되어 기존 컴포넌트 트리와 재조정됩니다. 이를 통해 훨씬 더 세분화되고 효율적인 업데이트 프로세스가 가능해집니다.

React Flight 소개: 핵심 프로토콜

그렇다면 서버 컴포넌트는 HTML이나 자체 JavaScript를 보내지 않는다면 무엇을 보내는 것일까요? 바로 여기서 React Flight가 등장합니다. React Flight는 렌더링된 React 컴포넌트 트리를 서버에서 클라이언트로 전송하기 위해 특별히 제작된 직렬화 프로토콜입니다.

React 기본 요소를 이해하는 특수하고 스트리밍 가능한 JSON 버전이라고 생각하면 됩니다. 이는 서버 환경과 사용자 브라우저 사이의 간극을 메우는 '전송 형식(wire format)'입니다. RSC를 렌더링할 때, React는 HTML을 생성하지 않습니다. 대신 React Flight 형식의 데이터 스트림을 생성합니다.

왜 그냥 HTML이나 JSON을 사용하지 않는가?

당연한 질문은, 왜 완전히 새로운 프로토콜을 발명했는가 하는 것입니다. 왜 기존 표준을 사용할 수 없었을까요?

왜 HTML은 안 되는가? HTML을 보내는 것은 SSR의 영역입니다. HTML의 문제는 그것이 최종적인 표현이라는 점입니다. 컴포넌트 구조와 컨텍스트를 잃어버립니다. 전체 페이지 새로고침이나 복잡한 DOM 조작 없이는 스트리밍된 새로운 HTML 조각을 기존의 상호작용적인 클라이언트 측 React 앱에 쉽게 통합할 수 없습니다. React는 어떤 부분이 컴포넌트인지, 그들의 props가 무엇인지, 그리고 상호작용적인 '아일랜드'(클라이언트 컴포넌트)가 어디에 위치하는지 알아야 합니다.
왜 표준 JSON은 안 되는가? JSON은 데이터에는 훌륭하지만, UI 컴포넌트, JSX, 또는 Suspense 경계와 같은 개념을 기본적으로 표현할 수 없습니다. 컴포넌트 트리를 나타내는 JSON 스키마를 만들려고 시도할 수는 있겠지만, 그것은 장황하고 클라이언트에서 동적으로 로드되고 렌더링되어야 하는 컴포넌트를 어떻게 표현할 것인가의 문제를 해결하지 못할 것입니다.

React Flight는 이러한 특정 문제들을 해결하기 위해 만들어졌습니다. 다음과 같이 설계되었습니다:

직렬화 가능(Serializable): props와 상태를 포함한 전체 컴포넌트 트리를 표현할 수 있어야 합니다.
스트리밍 가능(Streamable): UI를 청크 단위로 보낼 수 있어, 클라이언트가 전체 응답을 받기 전에 렌더링을 시작할 수 있습니다. 이는 Suspense와의 통합에 필수적입니다.
React 인식(React-Aware): 컴포넌트, 컨텍스트, 클라이언트 측 코드의 지연 로딩(lazy-loading)과 같은 React 개념을 일급으로 지원합니다.

React Flight 작동 방식: 단계별 분석

React Flight를 사용하는 과정은 서버와 클라이언트 간의 조율된 춤과 같습니다. RSC를 사용하는 애플리케이션에서 요청의 생명주기를 따라가 보겠습니다.

서버에서

요청 시작: 사용자가 애플리케이션의 한 페이지(예: Next.js 앱 라우터 페이지)로 이동합니다.
컴포넌트 렌더링: React가 해당 페이지의 서버 컴포넌트 트리 렌더링을 시작합니다.
데이터 가져오기: 트리를 순회하면서 데이터를 가져오는 컴포넌트(예: `async function MyServerComponent() { ... }`)를 만납니다. 이러한 데이터 가져오기를 기다립니다.
Flight 스트림으로 직렬화: HTML을 생성하는 대신, React 렌더러는 텍스트 스트림을 생성합니다. 이 텍스트가 React Flight 페이로드입니다. 컴포넌트 트리의 각 부분—`div`, `p`, 텍스트 문자열, 클라이언트 컴포넌트에 대한 참조—이 스트림 내의 특정 형식으로 인코딩됩니다.
응답 스트리밍: 서버는 전체 트리가 렌더링될 때까지 기다리지 않습니다. UI의 첫 번째 청크가 준비되는 즉시 HTTP를 통해 클라이언트로 Flight 페이로드 스트리밍을 시작합니다. Suspense 경계를 만나면 플레이스홀더를 보내고 백그라운드에서 중단된 콘텐츠 렌더링을 계속하며, 준비가 되면 나중에 동일한 스트림으로 전송합니다.

클라이언트에서

스트림 수신: 브라우저의 React 런타임이 Flight 스트림을 수신합니다. 이것은 단일 문서가 아니라 연속적인 명령어의 흐름입니다.
파싱 및 재조정: 클라이언트 측 React 코드가 Flight 스트림을 청크 단위로 파싱합니다. 이것은 UI를 구축하거나 업데이트하기 위한 설계도를 받는 것과 같습니다.
트리 재구성: 각 명령어에 대해 React는 가상 DOM을 업데이트합니다. 새로운 `div`를 만들거나, 텍스트를 삽입하거나, 또는 가장 중요하게는 클라이언트 컴포넌트를 위한 플레이스홀더를 식별할 수 있습니다.
클라이언트 컴포넌트 로딩: 스트림에 클라이언트 컴포넌트("use client" 지시문으로 표시됨)에 대한 참조가 포함되어 있을 때, Flight 페이로드에는 어떤 JavaScript 번들을 다운로드해야 하는지에 대한 정보가 포함됩니다. 그러면 React는 해당 번들이 아직 캐시되지 않았다면 가져옵니다.
하이드레이션 및 상호작용: 클라이언트 컴포넌트의 코드가 로드되면, React는 지정된 위치에 렌더링하고 하이드레이션하여 이벤트 리스너를 붙이고 완전히 상호작용 가능하게 만듭니다. 이 과정은 매우 대상이 명확하며 페이지의 상호작용적인 부분에 대해서만 발생합니다.

이 스트리밍 및 선택적 하이드레이션 모델은 종종 전체 페이지의 "전부 아니면 전무" 방식의 하이드레이션을 요구하는 기존 SSR 모델보다 훨씬 더 효율적입니다.

React Flight 페이로드 해부

React Flight를 진정으로 이해하려면, 그것이 생성하는 데이터의 형식을 살펴보는 것이 도움이 됩니다. 일반적으로 이 원시 출력과 직접 상호작용하지는 않겠지만, 그 구조를 보면 어떻게 작동하는지 알 수 있습니다. 페이로드는 줄바꿈으로 구분된 JSON과 유사한 문자열의 스트림입니다. 각 줄, 즉 청크는 정보의 한 조각을 나타냅니다.

간단한 예를 들어보겠습니다. 다음과 같은 서버 컴포넌트가 있다고 상상해 보세요:

app/page.js (서버 컴포넌트)


<!-- 실제 블로그의 코드 블록이라고 가정합니다 -->
async function Page() {
  const userData = await fetchUser(); // { name: 'Alice' }를 가져옴
  return (
    <div>
      <h1>Welcome, {userData.name}</h1>
      <p>Here is your dashboard.</p>
      <InteractiveButton text="Click Me" />
    </div>
  );
}

그리고 클라이언트 컴포넌트:

components/InteractiveButton.js (클라이언트 컴포넌트)


<!-- 실제 블로그의 코드 블록이라고 가정합니다 -->
'use client';

import { useState } from 'react';

export default function InteractiveButton({ text }) {
  const [count, setCount] = useState(0);
  return (
    <button onClick={() => setCount(count + 1)}>
      {text} ({count})
    </button>
  );
}

이 UI에 대해 서버에서 클라이언트로 전송되는 React Flight 스트림은 다음과 같을 수 있습니다 (이해를 돕기 위해 단순화됨):


<!-- Flight 스트림의 단순화된 예시 -->
M1:{"id":"./components/InteractiveButton.js","chunks":["chunk-abcde.js"],"name":"default"}
J0:["$","div",null,{"children":[["$","h1",null,{"children":["Welcome, ","Alice"]}],["$","p",null,{"children":"Here is your dashboard."}],["$","@1",null,{"text":"Click Me"}]]}]

이 암호 같은 출력을 분석해 봅시다:

`M` 행 (모듈 메타데이터): `M1:`으로 시작하는 줄은 모듈 참조입니다. 클라이언트에게 "ID `@1`이 참조하는 컴포넌트는 `./components/InteractiveButton.js` 파일의 기본 내보내기(default export)입니다. 이를 로드하려면 JavaScript 파일 `chunk-abcde.js`를 다운로드해야 합니다."라고 알려줍니다. 이것이 동적 임포트와 코드 분할이 처리되는 방식입니다.
`J` 행 (JSON 데이터): `J0:`으로 시작하는 줄은 직렬화된 컴포넌트 트리를 포함합니다. 그 구조를 살펴보면: `["$","div",null,{...}]`입니다.
`$` 기호: 이것은 React 요소(본질적으로 JSX)를 나타내는 특별한 식별자입니다. 형식은 일반적으로 `["$", type, key, props]`입니다.
컴포넌트 트리 구조: HTML의 중첩 구조를 볼 수 있습니다. `div`는 `h1`, `p`, 그리고 또 다른 React 요소를 포함하는 배열인 `children` prop을 가집니다.
데이터 통합: 이름 `"Alice"`가 스트림에 직접 포함되어 있는 것을 주목하세요. 서버의 데이터 가져오기 결과가 UI 설명에 바로 직렬화됩니다. 클라이언트는 이 데이터가 어떻게 가져와졌는지 알 필요가 없습니다.
`@` 기호 (클라이언트 컴포넌트 참조): 가장 흥미로운 부분은 `["$","@1",null,{"text":"Click Me"}]`입니다. `@1`은 참조입니다. 클라이언트에게 "트리의 이 위치에, 모듈 메타데이터 `M1`에 의해 설명된 클라이언트 컴포넌트를 렌더링해야 합니다. 그리고 렌더링할 때, `{ text: 'Click Me' }`와 같은 props를 전달하세요."라고 알려줍니다.

이 페이로드는 완전한 지침 세트입니다. 클라이언트에게 UI를 어떻게 구성해야 하는지, 어떤 정적 콘텐츠를 표시해야 하는지, 상호작용 컴포넌트를 어디에 배치해야 하는지, 그들의 코드를 어떻게 로드해야 하는지, 그리고 어떤 props를 전달해야 하는지를 정확히 알려줍니다. 이 모든 것이 간결하고 스트리밍 가능한 형식으로 이루어집니다.

React Flight 프로토콜의 주요 이점

Flight 프로토콜의 설계는 RSC 패러다임의 핵심 이점을 직접적으로 가능하게 합니다. 프로토콜을 이해하면 이러한 이점이 왜 가능한지 명확해집니다.

스트리밍과 네이티브 Suspense

프로토콜이 줄바꿈으로 구분된 스트림이기 때문에, 서버는 UI가 렌더링되는 대로 보낼 수 있습니다. 컴포넌트가 중단된 경우(예: 데이터를 기다리는 중), 서버는 스트림에 플레이스홀더 지침을 보내고, 페이지의 나머지 UI를 보낸 다음, 데이터가 준비되면 동일한 스트림에 새로운 지침을 보내 플레이스홀더를 실제 콘텐츠로 교체할 수 있습니다. 이는 복잡한 클라이언트 측 로직 없이 일급 스트리밍 경험을 제공합니다.

서버 로직을 위한 제로 번들 사이즈

페이로드를 보면, `Page` 컴포넌트 자체의 코드가 전혀 없다는 것을 알 수 있습니다. 데이터 가져오기 로직, 복잡한 비즈니스 계산, 또는 서버에서만 사용되는 대규모 라이브러리와 같은 의존성들이 완전히 없습니다. 스트림은 그 로직의 *결과물*만을 포함합니다. 이것이 RSC의 "제로 번들 사이즈" 약속의 근본적인 메커니즘입니다.

데이터 가져오기의 콜로케이션(Colocation)

`userData` 가져오기는 서버에서 발생하고, 그 결과(`'Alice'`)만이 스트림으로 직렬화됩니다. 이를 통해 개발자들은 데이터가 필요한 컴포넌트 바로 안에 데이터 가져오기 코드를 작성할 수 있는데, 이를 콜로케이션이라고 합니다. 이 패턴은 코드를 단순화하고, 유지보수성을 향상시키며, 많은 SPA를 괴롭히는 클라이언트-서버 폭포 현상을 제거합니다.

선택적 하이드레이션

프로토콜이 렌더링된 HTML 요소와 클라이언트 컴포넌트 참조(`@`)를 명시적으로 구분하는 것이 선택적 하이드레이션을 가능하게 합니다. 클라이언트 측 React 런타임은 `@` 컴포넌트만이 상호작용 가능해지기 위해 해당 JavaScript가 필요하다는 것을 압니다. 트리의 정적인 부분은 무시할 수 있어, 초기 페이지 로드 시 상당한 계산 리소스를 절약할 수 있습니다.

React Flight 대 대안: 글로벌 관점

React Flight의 혁신을 제대로 평가하려면, 전 세계 웹 개발 커뮤니티에서 사용되는 다른 접근 방식과 비교하는 것이 도움이 됩니다.

vs. 전통적인 SSR + 하이드레이션

언급했듯이, 전통적인 SSR은 전체 HTML 문서를 보냅니다. 클라이언트는 그런 다음 큰 JavaScript 번들을 다운로드하고 전체 문서를 "하이드레이션"하여 정적 HTML에 이벤트 리스너를 붙입니다. 이는 느리고 불안정할 수 있습니다. 단 하나의 오류가 전체 페이지가 상호작용 불가능하게 만들 수 있습니다. React Flight의 스트리밍 가능하고 선택적인 특성은 이 개념의 더 탄력적이고 성능이 좋은 진화입니다.

vs. GraphQL/REST API

흔한 혼동 중 하나는 RSC가 GraphQL이나 REST와 같은 데이터 API를 대체하는지 여부입니다. 답은 '아니오'입니다. 그들은 상호 보완적입니다. React Flight는 UI 트리를 직렬화하기 위한 프로토콜이지, 범용 데이터 쿼리 언어가 아닙니다. 사실, 서버 컴포넌트는 종종 서버에서 GraphQL이나 REST API를 사용하여 데이터를 가져온 후 렌더링합니다. 핵심 차이점은 이 API 호출이 서버 대 서버로 발생하여 일반적으로 클라이언트 대 서버 호출보다 훨씬 빠르고 안전하다는 것입니다. 클라이언트는 원시 데이터가 아닌 Flight 스트림을 통해 최종 UI를 받습니다.

vs. 다른 현대 프레임워크

글로벌 생태계의 다른 프레임워크들도 서버-클라이언트 분할 문제를 다루고 있습니다. 예를 들어:

Astro Islands: Astro는 유사한 '아일랜드' 아키텍처를 사용합니다. 사이트의 대부분은 정적 HTML이고 상호작용 컴포넌트는 개별적으로 로드됩니다. 이 개념은 RSC 세계의 클라이언트 컴포넌트와 유사합니다. 그러나 Astro는 주로 HTML을 보내는 반면, React는 Flight를 통해 구조화된 UI 설명을 보내 클라이언트 측 React 상태와 더 원활하게 통합할 수 있습니다.
Qwik과 Resumability: Qwik은 재개 가능성(resumability)이라는 다른 접근 방식을 취합니다. 애플리케이션의 전체 상태를 HTML에 직렬화하여 클라이언트가 시작 시 코드를 다시 실행(하이드레이션)할 필요가 없도록 합니다. 서버가 중단한 지점에서 '재개'할 수 있습니다. React Flight와 선택적 하이드레이션은 비슷한 빠른 상호작용 시간 목표를 달성하고자 하지만, 필요한 상호작용 코드만 로드하고 실행하는 다른 메커니즘을 통해 이루어집니다.

개발자를 위한 실질적인 의미와 모범 사례

React Flight 페이로드를 직접 작성하지는 않겠지만, 프로토콜을 이해하는 것은 현대 React 애플리케이션을 구축하는 방법에 대한 정보를 제공합니다.

`"use server"`와 `"use client"`를 적극적으로 활용하세요

Next.js와 같은 프레임워크에서, `"use client"` 지시문은 서버와 클라이언트 간의 경계를 제어하는 주요 도구입니다. 이것은 빌드 시스템에 컴포넌트와 그 자식들이 상호작용 아일랜드로 취급되어야 한다는 신호입니다. 그 코드는 번들링되어 브라우저로 전송되고, React Flight는 그에 대한 참조를 직렬화할 것입니다. 반대로, 이 지시문이 없거나(또는 서버 액션을 위해 `"use server"`를 사용하는 경우) 컴포넌트는 서버에 남아있게 됩니다. 효율적인 애플리케이션을 구축하려면 이 경계를 마스터해야 합니다.

엔드포인트가 아닌 컴포넌트 단위로 생각하세요

RSC를 사용하면 컴포넌트 자체가 데이터 컨테이너가 될 수 있습니다. `/api/user`라는 API 엔드포인트를 만들고 그것을 가져오는 클라이언트 측 컴포넌트를 만드는 대신, 내부적으로 데이터를 가져오는 단일 서버 컴포넌트 ``을 만들 수 있습니다. 이는 아키텍처를 단순화하고 개발자들이 UI와 그 데이터를 하나의 응집력 있는 단위로 생각하도록 장려합니다.

보안은 서버 측의 관심사입니다

RSC는 서버 코드이므로 서버 권한을 가집니다. 이것은 강력하지만 보안에 대한 엄격한 접근 방식이 필요합니다. 모든 데이터 접근, 환경 변수 사용, 내부 서비스와의 상호작용이 여기서 일어납니다. 이 코드를 백엔드 API처럼 엄격하게 다루십시오: 모든 입력을 살균하고, 데이터베이스 쿼리에는 준비된 문을 사용하며, Flight 페이로드로 직렬화될 수 있는 민감한 키나 비밀을 절대 노출하지 마십시오.

새로운 스택 디버깅하기

RSC 세계에서는 디버깅이 달라집니다. UI 버그는 서버 측 렌더링 로직이나 클라이언트 측 하이드레이션에서 비롯될 수 있습니다. 서버 로그(RSC용)와 브라우저의 개발자 콘솔(클라이언트 컴포넌트용)을 모두 확인하는 데 익숙해져야 합니다. 네트워크 탭도 그 어느 때보다 중요해졌습니다. 원시 Flight 응답 스트림을 검사하여 서버가 클라이언트에 정확히 무엇을 보내고 있는지 확인할 수 있으며, 이는 문제 해결에 매우 유용할 수 있습니다.

React Flight와 함께하는 웹 개발의 미래

React Flight와 그것이 가능하게 하는 서버 컴포넌트 아키텍처는 우리가 웹을 위해 구축하는 방식에 대한 근본적인 재고를 나타냅니다. 이 모델은 두 세계의 장점을 결합합니다: 컴포넌트 기반 UI 개발의 단순하고 강력한 개발자 경험과 전통적인 서버 렌더링 애플리케이션의 성능 및 보안.

이 기술이 성숙함에 따라, 우리는 훨씬 더 강력한 패턴이 나타날 것으로 기대할 수 있습니다. 클라이언트 컴포넌트가 서버에서 안전한 함수를 호출할 수 있게 해주는 서버 액션은 이 서버-클라이언트 통신 채널 위에 구축된 기능의 대표적인 예입니다. 프로토콜은 확장 가능하므로, React 팀은 핵심 모델을 깨지 않고도 미래에 새로운 기능을 추가할 수 있습니다.

결론

React Flight는 React 서버 컴포넌트 패러다임의 보이지 않지만 필수적인 중추입니다. 이것은 서버에서 렌더링된 컴포넌트 트리를 클라이언트 측 React 애플리케이션이 이해하고 풍부하고 상호작용적인 사용자 인터페이스를 구축하는 데 사용할 수 있는 지침 세트로 변환하는 매우 전문화되고 효율적이며 스트리밍 가능한 프로토콜입니다. 컴포넌트와 그들의 값비싼 의존성을 클라이언트에서 서버로 이동시킴으로써, 더 빠르고, 더 가볍고, 더 강력한 웹 애플리케이션을 가능하게 합니다.

전 세계 개발자들에게 React Flight가 무엇이고 어떻게 작동하는지 이해하는 것은 단지 학문적인 연습이 아닙니다. 이는 이 새로운 서버 주도 UI 시대에 애플리케이션을 설계하고, 성능 트레이드오프를 결정하며, 문제를 디버깅하기 위한 중요한 정신 모델을 제공합니다. 변화는 진행 중이며, React Flight는 앞으로 나아갈 길을 닦는 프로토콜입니다.