리액트 서버 컴포넌트는 정말 성능을 개선할까요?

원문: https://www.developerway.com/posts/react-server-components-performance

동일한 애플리케이션과 테스트 환경에서 CSR, SSR, RSC를 데이터 기반으로 비교하며, 초기 로드 성능과 클라이언트 vs 서버 사이드 데이터 패칭(Streaming + Suspense 포함)의 영향을 중심으로 살펴봅니다.

리액트 서버 컴포넌트에 대해 들어보셨나요? 아마 들어보셨을 겁니다. 지난 몇 년간 리액트 커뮤니티에서 거의 모든 화제가 그것이었죠. 하지만 제 생각에 이건 가장 오해받은 개념 중 하나입니다.

솔직히 말씀드리면, 저도 한동안 그 개념을 제대로 이해하지 못했습니다. 제 사고방식이 실용적인 편이라, 너무 개념적인 이야기로 느껴졌거든요. 게다가 서버 컴포넌트가 등장하기 훨씬 전부터, Next.js나 getServerSideProps 같은 API를 사용해 서버에서 데이터를 가져올 수 있었잖아요.
그렇다면 도대체 뭐가 다른 걸까요?

이 차이를 제대로 이해한 건, 여러 패턴을 구현 관점에서 비교해 보고, 각 렌더링 방식에서 데이터가 어떻게 패칭 되는지, 그리고 각 방식이 성능에 어떤 영향을 미치는지를 추적해 본 후였습니다.

그래서 이번 글에서 바로 그 부분을 다룹니다.
CSR (클라이언트 사이드 렌더링), SSR (서버 사이드 렌더링), 그리고 RSC (리액트 서버 컴포넌트)가 실제로 어떻게 구현되는지, 각 방식에서 자바스크립트와 데이터가 네트워크를 통해 어떻게 오가는지, 그리고 CSR → SSR → RSC로 마이그레이션 할 때의 성능 변화를 살펴봅니다.

이를 위해 제가 직접 간단하지만 실제에 가까운 멀티 페이지 앱을 만들어 실험했습니다. GitHub에서 확인하실 수 있으니, 원하신다면 동일한 실험을 직접 재현해 보셔도 좋습니다.

이 글은 여러분이 이미 Initial Load, CSR, SSR, Chrome Performance 탭의 기본적인 개념과 성능 분석 그래프를 읽는 방법을 알고 있다고 가정합니다.
만약 복습이 필요하시다면, 제가 추천하는 글들을 아래 순서대로 먼저 읽어보시는 걸 권장드립니다.

성능을 측정하기 위한 프로젝트 소개

가령, 상호작용적이고 시각적으로 아름다운 웹사이트를 만들고 싶다고 가정해 봅시다. 그 웹사이트의 한 페이지는 다음과 같은 형태를 하고 있습니다.

이 페이지의 일부 데이터는 동적으로 REST 엔드포인트를 통해 가져오는 구조입니다. 왼쪽의 Sidebar 항목들은 /api/sidebar 엔드포인트에서 가져오고, 오른쪽의 메시지 리스트는 /api/messages 엔드포인트에서 가져옵니다.

/api/sidebar는 꽤 빠르게 응답하며, 약 100ms 정도 걸립니다. 하지만 /api/messages 엔드포인트는 1s 정도 걸리는데, 이는 백엔드 최적화를 깜빡한 탓이죠. 이런 정도의 지연은 규모가 크거나 오래된 프로젝트에서는 현실적인 수치라고 할 수 있습니다.

이 글을 따라 직접 측정해보고 싶으시다면 GitHub에 공개된 프로젝트를 클론(clone)한 뒤에 의존성을 설치하고, 각 섹션 끝에 나오는 "재현 방법" 단계를 순서대로 따라가시면 됩니다.

우리가 측정할 항목 정의하기

성능과 관련하여 측정할 수 있는 요소는 셀 수 없이 많습니다. "이 웹사이트의 성능이 좋다" 또는 "나쁘다"라고 말하기 전에 "성능"이 무엇인지, "좋음"과 "나쁨"이 어떤 기준인지 명확히 정의해야 합니다.

이번 실험에서는 다양한 렌더링 방식과 데이터 패칭 기법 간의 로드 성능 차이를 확인하고자 합니다. 여기에는 리액트 서버 컴포넌트도 포함됩니다. 모든 기법을 이해하는 것을 넘어, “리액트 서버 컴포넌트는 성능 측면에서 실제로 가치가 있을까?”라는 질문에 답하기 위해서입니다.

측정에는 Chrome DevTools의 Performance 탭을 사용할 예정이며, CPU는 6배 느리게 설정하고 Network는 Slow 4G 환경을 시뮬레이션합니다. 혹시 아직 이것들에 익숙하지 않으시다면, Initial load performance for React developers: investigative deep dive에서 오늘 사용할 부분들을 간략히 정리해 두었습니다.

측정 대상은 자바스크립트가 처음으로 다운로드되는 첫 방문자와 자바스크립트가 일반적으로 브라우저 캐시에서 제공되는 재방문자 모두입니다.

측정할 구체적인 항목은 다음과 같습니다.

Largest Contentful Paint (LCP)는 사용자가 사이드바와 메시지의 "스켈레톤"으로 렌더링 된 페이지를 보는 시간과 일치합니다.
"사이드바 항목 표시" 시간은 설명이 필요 없을 정도로 간단합니다. 사이드바 항목이 엔드포인트에서 가져와 페이지에 렌더링 되는 시간입니다.
"메시지 표시" 시간은 위와 동일하지만 메시지에만 적용됩니다.
"페이지 상호 작용" 시간은 헤더의 토글이 작동하기 시작하는 시간입니다(이 부분의 중요성은 나중에 설명하겠습니다).

각 측정은 여러 번 반복하고, 중간값을 사용해 이상치를 제거합니다.

그리고 곧 HTTP/1의 동시 연결 제한 문제를 경험할 수 있습니다. 모든 로컬 Node 기반 서버(Next.js 포함)는 기본적으로 HTTP/1을 사용합니다. Chrome에서는 동시 연결 제한이 6으로 설정되어 있습니다! HTTP/1은 같은 도메인에서 6개 이상의 리소스(자바스크립트 파일 등)를 동시에 다운로드하면, 나머지는 "대기열"에 들어가게 됩니다.

하지만 실제 프로덕션 환경에서는 대부분 파일을 CDN을 통해 제공하며, 요즘은 HTTP/2 또는 HTTP/3을 사용합니다. 이 경우 모든 자바스크립트 파일이 병렬로 다운로드되므로, 로컬 테스트에서도 CDN과 유사한 동작을 재현해 일관성을 유지하고자 합니다. 저는 이를 위해 Caddy를 이용한 리버스 프록시를 사용했지만, 유사한 도구라면 무엇이든 가능합니다.

이제 모든 준비가 끝났습니다. 코드를 가지고 실험을 시작해 보겠습니다.

클라이언트 사이드 렌더링 측정

먼저 클라이언트 사이드 렌더링의 성능을 측정해 봅시다. 여러분이 태어난 연도에 따라 다르겠지만, 클라이언트 사이드 렌더링은 많은 리액트 개발자에게 기본적인 웹 경험이었거나, 지금도 그렇습니다. 만약 여러분이 Webpack 기반 프로젝트를 사용하고 있거나, Vite + router 조합으로 개발하면서 SSR(서버 사이드 렌더링)을 명시적으로 구현하지 않았다면 그건 바로 CSR(클라이언트 사이드 렌더링)을 하고 있는 것입니다.

구현 관점에서, 여러분의 브라우저가 /inbox URL을 요청하면, 서버는 다음 HTML을 응답하는 것을 의미합니다.

<!DOCTYPE html>
<html lang="en">
  <head>
    <script type="module" src="/assets/index-C3kWgjO3.js"></script>
    <link rel="stylesheet" href="/assets/index-C26Og_lN.css" />
  </head>
  <body>
    <div id="root"></div>
  </body>
</html>

head 태그에는 script와 link 요소가 있고 body 태그에는 빈 div가 있습니다. 그게 전부입니다. 브라우저에서 자바스크립트를 비활성화하면 빈 div에서 예상했듯이 빈 페이지가 표시됩니다.

이 빈 div를 아름다운 페이지로 변환하려면 브라우저가 자바스크립트 파일(들)을 다운로드하여 실행해야 합니다. 이 파일(들)에는 리액트 개발자가 작성하는 모든 내용이 포함됩니다.

// 이곳이 아름다운 앱의 진입점입니다.
export default function App() {
  return (
    <SomeLayout>
      <Sidebar />
      <MainContent />
    </SomeLayout>
  )
}

게다가 이런 것도 있습니다.

// 단순화를 위해 만들어진 API입니다.
const DOMElements = renderToDOM(<App />)
const root = document.getElementById('root')
root.appendChild(DOMElements)

리액트는 진입점 App 컴포넌트를 DOM 노드로 변환합니다. 그런 다음 id로 빈 div를 찾아 생성된 요소를 빈 div에 삽입합니다.

전체 인터페이스가 마침내 보입니다.

초기 부하에 대한 성능을 기록하면 다음과 같습니다.

자바스크립트가 다운로드되는 동안 사용자는 여전히 빈 화면을 응시합니다. 모든 것이 다운로드되고 자바스크립트가 브라우저에서 컴파일 및 실행된 후에야 UI가 표시되고 LCP 메트릭이 기록되며, fetch 요청과 같은 부수 효과가 발생합니다.

물론 실제로는 훨씬 더 복잡할 것입니다. 여러 개의 자바스크립트 파일(때로는 체이닝 되어있음), CSS 파일과 Main 섹션에서 발생하는 여러 가지 작업 등이 있을 것입니다. 이 프로젝트의 실제 성능 프로파일을 기록하면 다음과 같습니다.

사이드바와 메시지 항목에 대한 데이터 패칭은 자바스크립트 내부에서 트리거 됩니다.

useEffect(() => {
  const fetchMessages = async () => {
    const response = await fetch('/api/messages')
    const data = await response.json()
  }

  fetchMessages()
}, [])

예를 들어 Tanstack Query와 같은 데이터 패칭 프레임워크가 될 수 있습니다. 이 경우 코드는 다음과 같습니다.

const { isPending, error, data } = useQuery({
  queryKey: ['messages'],
  queryFn: () => fetch('/api/messages').then((res) => res.json()),
})

하지만 실제로 이것은 그리 중요하지 않습니다. 여기서 중요한 점은 데이터 패칭 프로세스가 시작되려면 자바스크립트가 다운로드되고 컴파일되어 실행되어야 한다는 것입니다.

자바스크립트가 캐시 되지 않은 상태에서 초기 로드 수치는 다음과 같습니다.

	LCP (캐시 X)	사이드바 (캐시 X)	메시지 (캐시 X)
클라이언트 사이드 렌더링	4.1s	4.7s	5.1s

4.1s를 기다려야 화면에 무언가 를 볼 수 있다니! 누가 클라이언트에서 무언가를 렌더링 하는 것이 좋은 아이디어라고 생각했을까요?

개발 경험과 학습 곡선에 관련된 모든 것들(이것들만 해도 매우 중요한 이슈이지만)을 제외하고도, 이러한 방식에는 더 "전통적인" 웹사이트 방식과 비교하여 두 가지 주요 이점이 있습니다.

첫째는 성능입니다! 모든 것이 클라이언트 측에 있고 서버와 오고 가는 통신이 없을 때, 페이지 간 전환 속도는 믿을 수 없을 정도로 빠를 수 있습니다. 이 프로젝트의 경우, Inbox 페이지에서 Settings 페이지로 이동하는 데는 단 80ms만이 소요됩니다. 이는 거의 즉각적인 수준에 가깝습니다.

그리고 둘째는 비용입니다. 터무니없이 저렴합니다. 여러분은 정말 복잡하고, 고도로 상호 작용하며, 풍부한 경험을 제공하는 웹사이트를 구현하여 Cloudflare CDN 같은 곳에 업로드할 수 있습니다. 수백만 명의 월간 사용자가 있어도 무료 플랜(free plan)을 유지할 수 있죠. 이는 취미 프로젝트, 학생 프로젝트, 또는 잠재적 사용자는 많지만 비용이 중요한 요소인 모든 종류의 프로젝트에 완벽합니다.

게다가 서버가 없고, 유지 보수가 필요 없으며, CPU나 메모리 모니터링도 할 필요가 없고, 확장성 문제도 없다는 것은 아주 좋은 보너스입니다. 마다할 이유가 있을까요?

또한, 4s가 넘는 로딩 시간(loading times)도 겉보기만큼 끔찍하지는 않습니다. 이는 사용자가 앱을 가장 처음 방문할 때만 발생합니다. 물론 랜딩 페이지 같은 곳에서는 이것이 용납할 수 없는 수준이겠지만, 사용자가 웹사이트를 자주 방문할 것으로 예상되는 SaaS의 경우, 4s는 배포당 단 한 번만 발생하게 됩니다. 그 후에는 자바스크립트가 브라우저에 의해 다운로드되고 캐시 되어, 두 번째 및 이후 로딩 수치는 상당히 감소할 것입니다.

	LCP (캐시 X)	사이드바 (캐시 X)	메시지 (캐시 X)	LCP (JS 캐시)	사이드바 (JS 캐시)	메시지 (JS 캐시)
클라이언트 사이드 렌더링	4.1s	4.7s	5.1s	800ms	1.5s	2s

800ms는 훨씬 괜찮습니다. 그렇지 않나요?

오늘 제가 마지막으로 관심을 가질 수치는 토글 버튼이 상호작용 가능해지는 시점입니다. 이 경우에는 자바스크립트가 실행될 때 비로소 모든 것이 화면에 나타나기 때문에, 이 시간은 LCP와 일치하게 될 것입니다.

따라서 전체 테이블은 다음과 같을 것입니다.

	LCP (캐시 X / JS 캐시)	사이드바 (캐시 X / JS 캐시)	메시지 (캐시 X / JS 캐시)	토글 상호작용 (캐시 X / JS 캐시)
클라이언트 사이드 렌더링	4.1s / 800ms	4.7s / 1.5s	5.1s / 2s	4.1s / 800ms

실험을 재현하는 단계

저장소를 클론하고 npm install로 모든 의존성을 설치합니다.
백엔드 API를 실행합니다: npm run start --workspace=backend-api
프런트엔드를 빌드합니다: npm run build --workspace=client-fetch-frontend
프런트엔드를 실행합니다: npm run start --workspace=client-fetch-frontend
HTTP/2를 위한 리버스 프록시를 실행합니다: caddy reverse-proxy --to :3000
웹사이트를 https://localhost/inbox 주소로 엽니다.
측정하세요!

서버 사이드 렌더링 측정 (데이터 패칭 미포함)

사용자들이 빈 페이지를 너무 오랫동안 쳐다봐야 한다는 사실은 어느 시점부터 사람들을 짜증나게 만들었습니다. 비록 이것이 첫 방문에서만 발생하는 일이라 하더라도 말이죠. 게다가, SEO 관점에서도 최선의 해결책은 아니었습니다. 그리고 당시에는 인터넷 속도가 더 느렸고, 사용자들이 최신 맥북을 사용하고 있지도 않았죠.

그래서 사람들은 해결책을 찾기 위해 머리를 맞대기 시작했습니다. 리액트 생태계를 포기하기에는 너무나 편리했기 때문이죠.

우리는 전체 리액트 앱이 최종적으로는 다음과 같은 형태를 띠게 된다는 것을 알고 있습니다.

// 단순화를 위해 만들어진 API입니다.
const DOMElements = renderToDOM(<App />)

하지만 DOM 노드 대신 리액트가 앱의 HTML을 생성한다면 어떨까요?

const HTMLString = renderToString(<App />)

서버가 빈 div 대신 브라우저에 보낼 수 있는 실제 문자열 형태로요.

// HTMLString은 다음 문자열을 담게 될 것입니다.
<div class="...">
  <div class="...">...</div>
  ...
</div>

이론상으로 클라이언트 사이드 렌더링을 위한 매우 간단한 서버는 다음과 같습니다.

// 네, 기본적인 클라이언트 측 렌더링을 위해 필요한 것은 이것이 전부입니다.
export const serveStatic = async (c) => {
  const html = fs.readFileSync('index.html').toString()

  return c.body(html, 200)
}

단순하게 생각해 본다면 단지 한 가지 추가 단계만 추가하면 됩니다. 그것은 바로 html 변수 내의 문자열을 찾아서 바꾸는 것입니다.

// SSR이 적용된 동일한 서버입니다.
export const serveStatic = async (c) => {
  const html = fs.readFileSync('index.html').toString() // HTML 문자열 추출
  const HTMLString = renderToString(<App />)
  // 서버 응답에 주입합니다.
  const htmlWithSSR = html.replace('<div id="root"></div>', HTMLString)

  return c.body(htmlWithSSR, 200)
}

이제 자바스크립트를 기다릴 필요 없이, 전체 UI가 바로 처음에 표시됩니다.

리액트의 서버 사이드 렌더링(SSR) 및 정적 사이트 생성(SSG) 시대에 오신 것을 환영합니다. 왜냐하면 renderToString은 실제로 리액트에서 지원하는 실제 API이기 때문입니다. 이것이 바로 일부 리액트 SSG/SSR 프레임워크의 핵심 구현입니다.

만약 제가 이 방식을 현재 클라이언트 사이드 렌더링 프로젝트에 그대로 적용한다면, 이 프로젝트는 서버 측 렌더링 프로젝트가 될 것입니다. 성능 프로파일은 약간 달라질 것입니다. LCP 수치는 왼쪽으로, 즉 HTML과 CSS가 다운로드된 직후로 이동할 것입니다. 왜냐하면 전체 HTML이 초기 서버 응답으로 전송되고, 모든 것이 즉시 보이기 때문입니다.

여기서 몇 가지 중요한 사항이 있습니다.

첫째, 보시다시피 LCP 수치(페이지의 "스켈레톤"이 보이는 시점)는 극적으로 개선될 것입니다 (이것은 잠시 후에 측정해 보겠습니다).

하지만, 우리는 여전히 동일한 자바스크립트를 정확히 동일한 방식으로 다운로드하고, 컴파일하고, 실행해야 합니다. 왜냐하면 페이지는 상호작용 가능해야 하기 때문입니다. 즉, 우리가 구현한 모든 드롭다운, 필터, 정렬 알고리즘 등이 작동해야 합니다. 그리고 우리가 기다리는 동안에도 전체 페이지는 이미 보이고 있습니다!

페이지는 이미 보이지만, 상호작용 가능하게 만들기 위해 자바스크립트 다운로드를 기다리는 그 간극은 사용자에게는 페이지가 고장 난 것처럼 보일 것입니다. 이것이 제가 "페이지가 상호작용 가능해지는" 시간을 측정하고 싶었던 이유입니다. 이 시간 동안에는 헤더에 있는 멋진 토글 버튼이 작동하지 않을 것이기 때문입니다.

또한, 위 프로파일에서는 LCP 수치만 변경되었습니다. "사이드바 항목"과 "메시지 목록"은 구조적으로 말하면 정확히 같은 위치에 있습니다. 그 이유는 우리가 코드를 단 하나도 바꾸지 않았으며, 여전히 클라이언트 측에서 해당 데이터를 패칭 하고 있기 때문입니다. 리액트 코드의 깊은 어딘가에는 여전히 다음과 같은 코드가 있을 것입니다.

const Sidebar = () => {
  useEffect(() => {
    const fetchSidebarData = async () => {
      const response = await fetch('/api/sidebar')
      const data = await response.json()
      setSidebarData(data)
    }

    fetchSidebarData()
  }, [])
}

useEffect는 비동기적인 부수 효과입니다. 이것은 앱이 브라우저에 제대로 마운트 되었을 때만 실행됩니다. 그리고 이는 브라우저가 자바스크립트를 다운로드하고 처리하며, 클라이언트 측 리액트가 작동할 때만 발생합니다. renderToString은 이를 무관한 것으로 간주하고 건너뛰게 됩니다.

결과적으로, 우리가 서버에서 페이지를 사전 렌더링했다는 사실은 사이드바 항목과 테이블 데이터가 화면에 나타나는 시간에 단 하나의 영향도 미치지 않습니다!

이제 이론적인 논의 대신 실제로 무슨 일이 일어나는지 측정해 보면, 다음과 같은 수치들을 보게 될 것입니다.

	LCP (캐시 X / JS 캐시)	사이드바 (캐시 X / JS 캐시)	메시지 (캐시 X / JS 캐시)	토글 상호작용 (캐시 X / JS 캐시)	상호작용 불가능 간극 (캐시 X / JS 캐시)
클라이언트 사이드 렌더링	4.1s / 800ms	4.7s / 1.5s	5.1s / 2s	4.1s / 800ms
서버 사이드 렌더링 (클라이언트 데이터 패칭)	1.61s / 800ms	4.7s / 1.5s	5.1s / 2s	4s / 900ms	2.39s / 100ms

보시다시피, 초기 로드 시 LCP 값은 실제로 급격하게 떨어졌습니다. 4.1s에서 1.61s로 말이죠! 이는 이론적인 추론과 정확히 일치합니다.

하지만 토글이 상호작용 가능해지는 시간은 추론에서 예상했던 대로 동일하게 유지되었습니다. 초기 로드 시 2초 이상 동안 사용자 경험이 거의 망가진 상태인 것입니다!

"상호작용이 불가능한" 이 구간은, 서버를 운영하는 비용과 더불어 클라이언트 사이드 렌더링에서 서버 사이드 렌더링으로 전환할 때 LCP 개선을 위해 감수해야 하는 대가입니다. 완전히 없앨 수 있는 방법은 없지만, 첫 실행 시 다운로드해야 하는 자바스크립트의 양을 줄임으로써 그 영향을 최소화할 수 있습니다.

실험을 재현하는 단계

클라이언트 사이드 렌더링 때와 완벽하게 동일한 단계를 따르되, 다음 단계를 추가합니다.
src/frontend/client-fetch/server/index.ts 파일로 이동하여 return c.html(simpleSSR(c, html)); 라인의 주석 처리를 제거합니다.

서버 사이드 렌더링 측정 (데이터 패칭 포함)

"상호작용 불가능" 구간을 제외하더라도, 이전 실험에는 또 다른 문제가 있었습니다. 바로 사이드바 항목과 메시지 테이블의 표시 시점에 아무런 변화도 없었다는 사실입니다. 하지만 이미 서버 영역에 들어섰다면, 왜 여기서 해당 데이터를 추출할 수 없을까요? 분명히 더 빠를 것입니다. 적어도 지연 시간과 대역폭 면에서는 훨씬 개선될 가능성이 높습니다.

정답은, 우리는 당연히 할 수 있습니다! 하지만, 우리가 이전에 했던 단순한 사전 렌더링에 비하면 구현 관점에서 훨씬 더 많은 작업이 필요할 것입니다. 첫째, 서버입니다. 우리는 그곳에서 해당 데이터를 패칭해야 합니다.

// SSR 서버에 데이터 패칭 로직 추가
export const serveStatic = async (c) => {
  const html = fs.readFileSync("index.html").toString();

  // 데이터 패칭 로직
  const sidebarPromise = fetch(`/api/sidebar`).then((res) => res.json());
    const messagesPromise = fetch(`/api/messages`).then((res) => res.json());

    const [sidebar, messages] = await Promise.all([
      sidebarPromise,
      messagesPromise,
    ]);

    ... // 나머지는 동일합니다.
};

그다음에는 리액트가 나머지 UI를 렌더링 할 때 항목들을 렌더링 할 수 있도록, 어떻게든 해당 데이터를 전달해야 합니다. 다행히도, 본질적으로 App 컴포넌트는 단순한 함수에 불과하기 때문에, 다른 일반적인 자바스크립트 함수처럼 인자를 받습니다. 우리는 이것을 props라고 알고 있습니다. 네, renderToString을 실행할 때 App 컴포넌트에 옛날 방식의 props를 전달해야 합니다!

// SSR 서버에 데이터 패칭 로직 추가
export const serveStatic = async (c) => {
  const html = fs.readFileSync('index.html').toString() // 데이터 패칭 로직
  const sidebarPromise = fetch(`/api/sidebar`).then((res) => res.json())
  const messagesPromise = fetch(`/api/messages`).then((res) => res.json())

  const [sidebar, messages] = await Promise.all([sidebarPromise, messagesPromise])

  // 패칭한 데이터를 props로 전달
  const HTMLString = renderToString(<App messages={messages} sidebar={sidebar} />)
}

그리고 우리의 App 컴포넌트는 props를 받도록 수정되어야 하며, 일반적인 prop drilling 기법을 사용하여 이 props들을 전달해야 합니다.

// 이곳이 아름다운 앱의 진입점입니다.
export default function App({ sidebar, messages }) {
  return (
    <SomeLayout>
      <Sidebar data={sidebar} />
      <MainContent data={messages} />
    </SomeLayout>
  )
}

이론적으로는 이것만으로도 이미 작동할 수 있습니다. 하지만 실제로는 여기서 몇 가지를 더 처리해야 합니다. 첫째는 "하이드레이션(hydration)"입니다. SSR 영역에서 "하이드레이션"이란, 리액트가 서버에서 보낸 기존 HTML을 재사용하여 이벤트 리스너를 부착하는 과정을 말합니다.

하이드레이션이 제대로 작동하려면, 서버에서 오는 HTML이 클라이언트 측의 HTML과 완벽하게 동일해야 합니다. 하지만 이는 불가능합니다. 클라이언트는 아직 필요한 데이터를 가져오지 못했기 때문이죠. 데이터를 가진 쪽은 오직 서버뿐입니다. 따라서 HTML을 전송할 때 그 데이터를 함께 클라이언트로 전달해야, 리액트 초기화 시점에 해당 데이터가 바로 사용될 수 있습니다.

가장 쉬운 방법은 이 데이터를 스크립트 태그 형태로 HTML에 삽입하고, 이를 window에 객체로 추가하는 것입니다.

const htmlWithData = `
    <script>window.__SSR_DATA__ = ${JSON.stringify({
    sidebar,
    messages,
  })}</script>
    ${HTMLString}`

이제 프런트엔드에서 해당 데이터가 window.__SSR_DATA__.sidebar 형태로 사용 가능해지며, 우리는 이 데이터를 읽어와서 전달할 수 있습니다.

export default function App({ messages, sidebar }) {
  // renderToString로 직접 전달한다면 props는 여기에 있을 겁니다.
  const sidebarData = typeof window === 'undefined' ? sidebar : window.__SSR_DATA__?.sidebar
  const messagesData = typeof window === 'undefined' ? messages : window.__SSR_DATA__?.messages

  return (
    <SomeLayout>
      <Sidebar data={sidebarData} />
      <MainContent data={messagesData} />
    </SomeLayout>
  )
}

그리고 이것은 실제로 작동합니다! 성능 도표는 다시 한번 변화할 것입니다.

이제 이전에는 동적이었던 항목들을 포함하여 전체 페이지가 CSS 다운로드가 완료되는 즉시 보이게 될 것입니다. 그 후에는 우리는 이전과 완전히 동일한 자바스크립트를 기다려야 하며, 그 후에야 페이지가 상호작용 가능해집니다.

이제 수치들은 다음과 같이 나타납니다.

	LCP (캐시 X / JS 캐시)	사이드바 (캐시 X / JS 캐시)	메시지 (캐시 X / JS 캐시)	토글 상호작용 (캐시 X / JS 캐시)	상호작용 불가능 간극 (캐시 X / JS 캐시)
클라이언트 사이드 렌더링	4.1s / 800ms	4.7s / 1.5s	5.1s / 2s	4.1s / 800ms
서버 사이드 렌더링 (클라이언트 데이터 패칭)	1.61s / 800ms	4.7s / 1.5s	5.1s / 2s	4s / 900ms	2.39s / 100ms
서버 사이드 렌더링 (서버 데이터 패칭)	2.16s / 1.24s	2.16s / 1.24s	2.16s / 1.24s	4.6s / 1.4s	2.44s / 150ms

LCP 값은 안타깝게도 저하되었습니다. 이는 놀라운 일이 아닙니다. 그 이유는 리액트 부분을 사전 렌더링 하기 전에, 이제는 데이터 패칭의 Promise가 완료되기를 기다려야 하기 때문입니다.

// SSR 서버에 데이터 패칭 로직 추가
export const serveStatic = async (c) => {

  const sidebarPromise = fetch(`/api/sidebar`).then((res) => res.json());
    const statisticsPromise = fetch(`/api/statistics`).then((res) => res.json());

    // 두 요청 모두를 기다립니다.
    const [sidebar, statistics] = await Promise.all([
      sidebarPromise,
      statisticsPromise,
    ]);

    ... // 나머지 서버 코드 생략
};

그리고 우리는 무언가를 렌더링 하기 시작하려면 그 데이터가 필요하기 때문에, 이 데이터가 준비될 때까지 반드시 기다려야 합니다.

하지만 사이드바와 메시지 항목은 이제 훨씬 더 빠르게 나타납니다. 5.1s 대신 2.16s 만에 말이죠. 따라서 만약 전체 페이지 뷰에 비해 LCP 수치가 그리 중요하지 않다면, 이것은 개선이라고 불릴 수 있습니다. 또는, 우리는 최소한의 성능 저하만으로 사이드바만 미리 패칭 하고 (이 API 엔드포인트는 꽤 빠르기 때문), 메시지 부분은 클라이언트 측에 그대로 유지하는 방법도 있습니다. 이것은 사용자에게 가장 좋은 것이 무엇인지에 대한 여러분의 이해를 바탕으로 내리는 제품 결정(product decision)이 될 것입니다.

실험을 재현하는 단계

클라이언트 사이드 렌더링 때와 완벽하게 동일한 단계를 따르되, 다음 단계를 추가합니다.
src/frontend/client-fetch/server/index.ts 파일로 이동하여 simpleSSRWithHydration(c, html) 라인의 주석 처리를 제거합니다.

Next.js Pages ("구형" Next.js) 측정

현실적으로, 이전 섹션의 코드는 당연히 훨씬 더 복잡해질 것입니다. 첫째, 이것은 멀티 페이지 애플리케이션입니다. 대부분의 페이지에서는 메시지 목록이 필요하지 않을 것입니다. 게다가, 우리는 각 페이지를 개별적으로 사전 렌더링해야 합니다. 사용자가 /login URL을 로드할 때 메인 페이지의 HTML을 보여주는 것은 말이 되지 않을 것입니다.

따라서 이제 우리는 서버에 어떤 형태의 라우팅을 도입해야 합니다. 그리고 최소한 각 페이지마다 다른 진입점을 만들어야 합니다.

기본적으로 우리는 우리만의 SSR 프레임워크를 만들기 시작했습니다. 그러니 이제 기존의 것을 사용하는 것으로 전환해도 전혀 문제가 없습니다. 예를 들어, 리액트 서버 컴포넌트가 없는, "구형" Next.js 경험인 Next.js Pages Router를 사용해 봅시다. 다음 섹션에서는 서버 컴포넌트가 포함된 버전으로 전환할 것입니다.

커스텀 SSR 구현을 Next.js Pages Router로 마이그레이션 하기 위해, 패칭 로직을 getServerSideProps 안으로 옮기기만 하면 됩니다. 이것은 서버에서 페이지 데이터를 패칭 하기 위한 구형 Next.js API입니다. props drilling을 포함한 다른 모든 것은 동일하게 유지됩니다! Next.js는 우리가 직접 구현했던 renderToString 호출과 찾아 바꾸기(find-and-replace) 로직을 추상화하여 처리해 줍니다.

서버에서 데이터를 패칭 하고 싶을 때 코드는 이제 다음과 같을 것입니다.

export const getServerSideProps = async () => {
  const sidebarPromise = fetch(`/api/sidebar`).then((res) => res.json())
  const messagesPromise = fetch(`/api/messages`).then((res) => res.json())

  const [sidebar, messages] = await Promise.all([sidebarPromise, messagesPromise])

  // props를 통해서 페이지에 데이터를 전달합니다.
  return { props: { messages, sidebar } }
}

아니면 클라이언트 측 데이터 패칭을 유지하기 위해 이 코드를 단순히 주석 처리할 수도 있습니다.

성능 프로파일을 포함하여 다른 모든 것은 동일하게 유지됩니다. 이 방식은 데이터 패칭의 유무에 관계없이, 위에서 다룬 SSR 섹션과 동일한 구조를 유지해야 합니다.

측정하고 기록한 그 결과는 다음과 같습니다.

	LCP (캐시 X / JS 캐시)	사이드바 (캐시 X / JS 캐시)	메시지 (캐시 X / JS 캐시)	토글 상호작용 (캐시 X / JS 캐시)	상호작용 불가능 간극 (캐시 X / JS 캐시)
클라이언트 사이드 렌더링	4.1s / 800ms	4.7s / 1.5s	5.1s / 2s	4.1s / 800ms
서버 사이드 렌더링 (클라이언트 데이터 패칭)	1.61s / 800ms	4.7s / 1.5s	5.1s / 2s	4s / 900ms	2.39s / 100ms
서버 사이드 렌더링 (서버 데이터 패칭)	2.16s / 1.24s	2.16s / 1.24s	2.16s / 1.24s	4.6s / 1.4s	2.44s / 150ms
Next.js Pages (클라이언트 데이터 패칭)	1.76s / 800ms	3.7s / 1.5s	4.2s / 2s	3.1s / 900ms	1.34s / 100ms
Next.js Pages (서버 데이터 패칭)	2.15s / 1.15s	2.15s / 1.15s	2.15s / 1.15s	3.5s / 1.25s	1.35s / 100ms

보시다시피, 초기 로드 시 LCP 값은 "서버 데이터 패칭" 사례에 대한 저의 커스텀 구현보다 오히려 약간 더 나쁩니다. 반면에, 사이드바와 메시지는 이 사례에서 1s 더 일찍 나타납니다. "서버 데이터 패칭" 사례에서는 LCP, Sidebar, Messages 수치가 저의 커스텀 구현과 Next.js 간에 동일합니다. 하지만 "상호작용 불가능"의 간극은 Next.js에서 1s 정도 더 짧습니다.

이것은 코드 스플리팅이 다르게 수행될 때 발생하는 상황을 매우 명확하게 보여주는 유스케이스입니다. Next.js는 저의 커스텀 구현보다 훨씬 더 많은 청크로 자바스크립트를 분할합니다. 결과적으로, 제가 초기 로드를 측정했을 때 훨씬 더 많은 병렬 자바스크립트 파일들이 CSS로부터 약간의 대역폭을 "훔쳐가게" 됩니다. 이는 CSS 다운로드에 더 오랜 시간이 걸리게 만들고, LCP 값을 약간 저하시키는 결과를 낳습니다.

반면, 여러 개의 자바스크립트 파일을 병렬로 다운로드하면 전체적으로 약 1s 정도 더 빠르게 로드되어, 페이지가 상호작용 가능한 상태가 되는 시간이 훨씬 단축됩니다. 그리고 결과적으로, "상호작용 불가능" 간극을 훨씬 더 짧게 만듭니다.

실험을 재현하는 단계

저장소를 클론하고 npm install로 모든 의존성을 설치합니다.
백엔드 API를 실행합니다: npm run start --workspace=backend-api
frontend/utils/link.tsx 파일로 이동해서 Next.js Link를 주석 해제하고 커스텀 구현을 주석 처리 합니다.
src/frontend/next-pages/pages/inbox.tsx 파일로 이동하여 데이터 패칭 사례 간 전환을 위해 getServerSideProps를 주석 처리/해제합니다.
프런트엔드를 빌드합니다: npm run build --workspace=next-pages
프런트엔드를 실행합니다: npm run start --workspace=next-pages
HTTP2/3를 위한 리버스 프록시를 실행합니다: caddy reverse-proxy --to :3000
웹사이트를 https://localhost/inbox 주소로 엽니다.

리액트 서버 컴포넌트 소개

좋습니다. 이전 섹션을 요약하자면, 서버에서 데이터 패칭을 하고 사전 렌더링 하는 것은 초기 로드 성능 수치에 정말로 큰 도움이 될 수 있습니다. 하지만 여전히 몇 가지 문제가 남아있습니다.

SSR의 가장 큰 문제는 "상호작용 불가능 간극"입니다. 즉, 페이지가 이미 보이지만 자바스크립트가 여전히 다운로드 및 초기화되고 있는 시간이죠. 이 간극을 단축시키는 유일한 방법은 상호작용에 필요한 자바스크립트의 양을 줄이는 것입니다. 우리는 이미 Next.js Pages로 마이그레이션 하면서 코드 스플리팅을 수행했고, 이 영역에서 1s 이상의 개선을 확인했습니다. 코드 스플리팅 외에 여기서 더 할 수 있는 일이 있을까요? 우리는 과연 그 모든 자바스크립트가 필요하기는 한 걸까요?

SSR의 두 번째 문제는 데이터 패칭입니다. 현재 상황에서, 메시지가 나타나는 대기 시간을 줄이기 위해 서버에서 메시지를 미리 패칭 하려 한다면, 이는 초기 로드 시간과 사이드바 항목이 나타나는 시간 모두에 부정적인 영향을 미치게 됩니다.

이것은 현재 서버 렌더링이 동기적인 프로세스라는 사실 때문입니다. 우리는 모든 데이터가 준비될 때까지 먼저 기다린 다음, 그 데이터를 renderToString에 전달하고, 그 결과물을 클라이언트에 전송합니다.

하지만 만약 우리 서버가 더 똑똑해질 수 있다면 어떨까요? 패칭 요청들은 Promise이며, 비동기 함수입니다. 기술적으로, 우리는 다른 작업을 시작하기 위해 그들을 기다릴 필요가 전혀 없습니다. 다음과 같이 할 수 있다면 어떨까요?

그 패치 Promise들을 기다리지 않고 실행합니다.
해당 데이터가 필요 없는 리액트 요소들의 렌더링을 시작하고, 준비가 되면 즉시 클라이언트에게 전송합니다.
사이드바 항목의 Promise가 반환되고 해당 데이터를 사용할 수 있게 되면, 사이드바 부분을 렌더링 하고, 서버 페이지에 주입한 다음, 클라이언트에게 전송합니다.
메시지 항목에도 동일하게 적용합니다.

기본적으로, 클라이언트 사이드 렌더링에서 가지고 있던 데이터 패칭의 정확히 동일한 구조를 서버에서 적용하는 것입니다.

이것이 이론적으로 가능하다면, 미친 듯이 빠를 수 있습니다. 우리는 가장 단순한 SSR 속도로 플레이스홀더가 있는 초기 렌더링 페이지를 제공할 수 있으며, 자바스크립트가 다운로드되고 실행되기 훨씬 이전에 사이드바와 메시지 항목들을 볼 수 있을 것입니다.

이를 위해서는 리액트가 단순하고 동기적인 renderToString을 포기하고, 렌더링 프로세스를 청크 단위로 재작성해야 합니다. 그리고 이 청크들을 렌더링 된 구조에 어떻게든 주입할 수 있어야 하며, 이 청크들을 클라이언트에게 독립적으로 제공할 수 있어야 합니다.

이것은 상당히 어려운 작업입니다! 그리고 이미 완료된 작업이기도 합니다. 왜냐하면 이 설명이 바로 리액트 서버 컴포넌트와 스트리밍이 조화롭게 작동하는 방식을 묘사하고 있기 때문입니다.

이 모든 것이 어떻게 맞물려 작동하는지 이해하려면, 우리는 세 가지 핵심 개념을 이해해야 합니다.

리액트 서버 컴포넌트

우선, 리액트 서버 컴포넌트입니다.

일반적인 리액트 컴포넌트는 페이지에 HTML 태그를 배치하는 역할만 하는 경우가 상당히 많습니다. 예를 들어, 이 프로젝트의 사이드바 컴포넌트는 다음과 같이 보입니다.

export const TopbarForSidebarContentLayout = () => {
  return (
    <div className="lg:bg-blinkNeutral50 lg:dark:bg-blinkNeutral800">
      <nav
        aria-label="Main Navigation"
        className="h-auto lg:h-16 px-6 flex items-center justify-between absolute top-3 lg:top-0 right-0 lg:right-0 left-12 lg:left-0 lg:relative"
      >
        <div className="text-3xl blink-text-primary italic font-blink-title">
          <a href="#">My Dashboards</a>
        </div>
        <div className="gap-3 hidden lg:flex">
        ... // 나머지 코드 생략

보시다시피, 단순히 div와 link 태그들의 묶음일 뿐입니다. 하지만 이 모든 것은 여전히 자바스크립트이며, 바로 이 코드가 "상호작용 불가능 간극"을 야기하는 모든 자바스크립트 파일에 포함됩니다. 하지만 여기에는 어떤 상호작용도 없습니다! 이 컴포넌트에서 우리가 실제로 필요한 유일한 것은 div, link, 그리고 다른 태그들뿐입니다. 즉, HTML 형태의 레이아웃인 거죠.

이 코드가 자바스크립트 번들에 포함되는 유일한 이유는 리액트가 Virtual DOM을 구성하는 데 이 코드가 필요하기 때문입니다. Virtual DOM이란 페이지에 렌더링 되는 모든 것의 계층적 표현입니다.

여러분이 리액트에서 <TopbarForSidebarContentLayout />처럼 컴포넌트를 "렌더링"할 때마다, Element를 생성하는 것입니다. 이러한 멋진 HTML 유사 구문의 밑바탕에는 단순히 여러 속성을 가진 객체가 있으며, 그중 하나가 "type"입니다. "type"은 문자열 일 수 있으며 이 경우 DOM 요소를 나타냅니다. 혹은 함수일 수 있으며 이 경우 리액트는 그 함수를 호출하고, 함수가 반환하는 요소들의 묶음을 추출하여, 그것들을 통합된 트리로 병합합니다.

// TopbarForSidebarContentLayout 요소들
{
    "type": "div",
    "props": {
        "children": [
            {
                "type": "nav",
                "props": {
                    "className": "...",
                    ...
                }
            }
        ]
    }
}

현재 SSR 구현에서, 이것이 Next.js Pages이든 저의 커스텀 구현이든 관계없이, 리액트 컴포넌트로부터 이 트리를 추출하는 프로세스는 두 번 발생합니다. 첫 번째는 서버에서 사전 렌더링을 수행할 때입니다. 그리고 두 번째는 클라이언트 측 리액트를 초기화할 때 완전히 처음부터 다시 발생합니다.

하지만 그럴 필요가 없다면 어떨까요? 만약 우리가 서버에서 그 트리를 처음 생성했을 때, 그것을 보존하고 클라이언트에게 보낼 수 있다면 어떨까요? 리액트가 그 객체로부터 Virtual DOM 트리를 다시 생성할 수만 있다면, 우리는 일석이조의 효과를 얻을 수 있습니다.

우리는 이 컴포넌트를 자바스크립트 번들에 보낼 필요가 없어지므로, 자바스크립트의 크기를 줄일 수 있습니다.
우리는 그 모든 함수들을 반복적으로 호출하고 그 반환 값들을 트리로 변환하는 작업을 할 필요가 없어지므로, 자바스크립트를 컴파일하고 실행하는 데 걸리는 시간을 줄일 수 있습니다.

그 데이터를 클라이언트에게 어떻게 보낼까요? 우리는 이미 이전에 SSR로 패칭 한 데이터를 통해 이미 방법을 알고 있습니다! 바로 <script> 태그 안에 데이터를 삽입하고, 이를 window 객체에 추가하는 방식입니다.

// 서버 응답에서 다음을 반환합니다.
const htmlWithData = `
    <script>window.__REACT_ELEMENTS__ = ${JSON.stringify({
      "type": "div",
      "props": { "children": [...] }
    })}</script>
    ${HTMLString}`;

우리가 방금 이론적인 가능성으로 발명한 것이 바로 리액트 서버 컴포넌트입니다.

만약 제가 제 프로젝트를 서버 컴포넌트를 기반으로 하는 Next.js App Router로 마이그레이션 한다면, 서버에서 제공되는 HTML에서 다음과 같은 것을 보게 될 것입니다.

<script>
  self.__next_f.push([1,"6:[\"$\",\"div\",null,{\"className\":\"w-full h-full flex flex-col lg:flex-row\",\"children\":[\"$\",\"div\",null,{\"className\":\"flex flex-1 h-full overflow-y-auto flex..."
</script>

이것은 약간 수정되었지만 여전히 알아볼 수 있는 객체들의 트리이며, 페이지에 무엇이 렌더링 되어야 하는지를 명시적으로 나타냅니다. 만약 여러분의 Next.js App Router 프로젝트가 있다면, Chrome의 Elements 탭에서 맨 아래를 살펴보세요.<script> 태그 중 하나에서 위와 동일한 구조를 보게 될 것입니다.

이것이 바로 여러분이 문서에서조차 서버 컴포넌트는 서버가 필요 없다는 내용을 볼 수 있는 이유입니다. 정말로 필요 없습니다! 여러분은 그 구조를 빌드 타임에 생성할 수 있습니다. 그것은 "실행 중인" 서버일 필요가 없습니다. 참고로 이것을 RSC payload라고 부릅니다.

이론적으로, 이것이 서버 컴포넌트에 대해 알아야 할 전부입니다. 이것들은 "서버" 측에서 미리 실행되는 컴포넌트이며, 이들의 코드와 이들이 사용하는 모든 라이브러리는 서버 측에 남아 있습니다. 오직 생성된 RSC payload, 즉 위에서 언급한 이상한 구조만이 클라이언트에게 전송됩니다.

서버 컴포넌트와 함께 자주 접하게 되는 이점들 중 하나는 번들 크기의 감소입니다. 이론적으로, 모든 코드와 라이브러리가 서버에 남아 있고, 최종 구조만 클라이언트에 전송된다면, 다운로드되는 자바스크립트의 양은 눈에 띄게 줄어들 것입니다. 그리고 우리는 너무 많은 자바스크립트가 미치는 영향을 이미 알고 있으므로, 이는 좋은 아이디어처럼 들립니다.

실제 성능은 조금 있다가 측정해 보겠습니다.

비동기 컴포넌트

서버 컴포넌트와 일반적으로 함께 다뤄지는 두 번째 중요한 개념은 비동기 컴포넌트입니다. 여러분의 예상대로 일반적인 컴포넌트에 async 키워드가 붙은 것뿐입니다. 이제 다음과 같이 데이터 패칭을 위한 코드가 완전히 유효한 코드가 됩니다.

const PrimarySidebar = async () => {
  const sidebarResponse = await fetch("/api/sidebar");
  const sidebarData = await sidebarResponse.json();

  return <div>{sidebarData.map(...)}</div>
};

이것은 오직 서버에서만 지원됩니다. 적어도 이 글을 작성하는 시점에는 그렇습니다. 렌더링 프로세스 중에 리액트는 비동기 컴포넌트를 발견하고, Promise가 반환될 때까지 기다린 다음, 그 결과로부터 RSC payload를 생성합니다. 그리고 이 payload를 RSC 구조 내에서 있어야 할 곳으로 전송하고, 다음 단계로 계속 진행합니다.

스트리밍

스트리밍은 서버 컴포넌트와 일반적으로 함께 다뤄지는 세 번째로 중요한 개념입니다. 이것은 앞서 이론적인 연습으로 설명했던 것을 정확히 구현합니다.

일반적인 SSR 구현에서, 서버는 먼저 전송할 모든 HTML을 문자열로 생성한 다음, 이를 하나의 큰 청크로 클라이언트에게 전송합니다.

반면, "스트리밍" SSR 구현에서는, 서버가 먼저 Node.js Stream을 생성합니다. 그런 다음, 리액트의 renderToPipeableStream API를 사용하여 리액트 앱을 Node 스트림을 통해 청크 단위로 렌더링 합니다.

참고로, 이 프로세스에서 청크의 경계는 리액트 컴포넌트나 비동기 컴포넌트가 아닙니다. 그것은 Suspense로 감싸진 컴포넌트들입니다. 이 점은 매우 중요하니 기억해 두십시오. 우리가 측정을 시작할 때 그 중요성을 보게 될 것입니다.

저의 경우처럼 여러 페이지로 구성된 앱에 대한 이 기능의 실제 구현은 정말로 복잡합니다. 공식 문서에서도 이를 잘 다루지 못하고 있습니다. 부끄러울 정도로 오랜 시간을 들여서 작동하게 만들려고 했는데, 결국에는 정말 복잡한 파일 여러 개에 반쯤 망가진 상태였을 겁니다. 이는 "일반적인" SSR에서와 같은 단순한 renderToString이 아닙니다.

따라서 여기서는 곧바로 프레임워크를 사용하는 것이 더 쉽습니다. 현재 Next.js App Router는 리액트 서버 컴포넌트 및 스트리밍의 사실상 동의어이며, 최근 몇몇 다른 프레임워크들도 이를 지원하기 시작했습니다. 예를 들어, React Router는 최근 서버 컴포넌트에 대한 실험적인 지원을 출시했습니다. 하지만 이 분야에서는 여전히 Next.js가 지배적입니다.

Next.js App Router 측정 (Lift-and-Shift 마이그레이션 후)

Next.js App Router 환경에서 기존 측정 결과와의 의미 있는 비교를 하려면, 어떻게든 스트리밍 및 서버 컴포넌트의 영향을 격리하고 기준선을 설정해야 합니다. 왜냐하면 Next.js의 장점이자 단점은 엄청난 양의 다양한 최적화, 캐싱, 가정, 변환 등 정말로 많은 일을 처리한다는 점이기 때문입니다.

만약 제가 앱 전체를 당장 재작성한다면, 그 비교는 공정하지 않을 것입니다. 왜냐하면 이점이나 성능 저하가 프레임워크 자체의 고유한 작업 때문인지, 아니면 서버 컴포넌트/스트리밍이 훌륭하거나 끔찍하기 때문인지 구분할 방법이 없기 때문입니다.

하지만 기존 앱을 Next.js Pages에서 마이그레이션 하는 가능한 프로세스를 상상한다면, 의미 있는 무언가를 추출할 수 있다고 생각합니다.

그러니 합리적으로 접근해 봅시다. 저에게는 Next.js Pages와 클라이언트 측 데이터 패칭으로 구현된 기존의 큰 앱이 있습니다. 이 앱은 현재까지 테이블에서 두 번째 행에 해당하는, 가장 작은 LCP를 가진 앱입니다. 저는 이 앱을 완전히 새로운 멘털 모델과 완전히 새로운 데이터 패칭 방식을 가진 새 프레임워크로 마이그레이션해야 합니다. 저는 무엇을 해야 할까요?

첫째, 가능한 한 기능 변경 없이 그대로 옮기고(Lift-and-Shift) 앱이 작동하며 아무것도 문제없는지 확인해야 합니다. 이 실험의 맥락에서 이것은 라우팅을 약간 재구현하고, 모든 진입 파일에 use client를 사용하도록 강제하는 것을 의미합니다. 이렇게 하면 App Router가 모든 곳에서 클라이언트 컴포넌트로 작동하게 될 것입니다.

결과적으로, 이것은 새 프레임워크 자체의 영향을 격리할 것입니다. 여기서 발생하는 모든 이점이나 성능 저하는 프레임워크 자체 때문일 것이며, 이는 아직 서버 컴포넌트나 스트리밍을 사용하지 않았기 때문입니다! 부수적인 이점으로, 이것은 큰 코드 변경 없이 "구형" Next.js에서 "신형" Next.js로 마이그레이션 할 가치가 있는지 여부도 보여줄 것입니다.

이러한 방식으로, 앱은 Next.js Pages에서 사전 렌더링되었을 때와 마찬가지로, 클라이언트 측 데이터 패칭을 했을 때처럼 정확히 동일하게 동작할 것입니다. 다음은 측정 결과입니다.

	LCP (캐시 X / JS 캐시)	사이드바 (캐시 X / JS 캐시)	메시지 (캐시 X / JS 캐시)	토글 상호작용 (캐시 X / JS 캐시)	상호작용 불가능 간극 (캐시 X / JS 캐시)
클라이언트 사이드 렌더링	4.1s / 800ms	4.7s / 1.5s	5.1s / 2s	4.1s / 800ms
서버 사이드 렌더링 (클라이언트 데이터 패칭)	1.61s / 800ms	4.7s / 1.5s	5.1s / 2s	4s / 900ms	2.39s / 100ms
서버 사이드 렌더링 (서버 데이터 패칭)	2.16s / 1.24s	2.16s / 1.24s	2.16s / 1.24s	4.6s / 1.4s	2.44s / 150ms
Next.js Pages (클라이언트 데이터 패칭)	1.76s / 800ms	3.7s / 1.5s	4.2s / 2s	3.1s / 900ms	1.34s / 100ms
Next.js Pages (서버 데이터 패칭)	2.15s / 1.15s	2.15s / 1.15s	2.15s / 1.15s	3.5s / 1.25s	1.35s / 100ms
Next.js App router (Lift-and-Shift)	1.28s / 650ms	4.4s / 1.5s	4.9s / 2s	3.8s / 900ms	2.52s / 250ms

여기서 LCP 값은 1.28s로 떨어졌는데, 이는 지금까지의 값 중에서 가장 작은 값입니다. Next.js Pages와 비교하여 약 500ms의 개선을 보였는데, 이는 엄청난 발전입니다! 🎉 하지만 다른 모든 것은 약 700ms 정도 악화된 것으로 보이는데, 이것 역시 크지만 부정적인 방향에서의 변화입니다 🥺.

왜 이런 결과가 나왔는지 조사하는 것은 엄청나게 재미있을 수 있고, 여러분이 성능 프로파일을 얼마나 잘 읽는지에 대한 좋은 테스트가 될 수 있으므로, 저는 여러분이 직접 시도해 보기를 강력히 권장합니다 😉. 만약 여러분이 이를 재현하려는데 이런 현상이 발생하지 않는다면, 브라우저 때문일 수 있습니다. Chrome을 사용하고 있는지 확인하세요.

그 해답은 다음과 같습니다.

첫째, Next.js App Router는 CSS가 로드된 후에야 모든 자바스크립트를 지연시키는 것으로 보입니다. Pages 버전은 그렇지 않았고 CSS와 자바스크립트를 병렬로 로드했습니다. 결과적으로, 자바스크립트 로딩이 약간의 대역폭을 "훔쳐갔고", Pages에서는 CSS가 더 느리게 로드되어 LCP 값을 지연시켰습니다. 이것이 LCP에서 500ms를 얻은 이유입니다. 그리고 다른 모든 것에서 약 700ms를 손해 본 이유이기도 합니다. 이 정보는 Network 섹션에서 찾을 수 있습니다.

게다가, App Router는 Pages 버전보다 최소 100ms 정도 더 많은 작업량을 처리하며 메인 스레드에서 매우 바쁘게 작동하는 것으로 보입니다. 이는 LCP 외의 다른 모든 것을 더욱 지연시킵니다. 마지막 100ms는 여기저기서 발생하는 무작위적인 변동일 수도 있습니다.

종합적으로 봤을 때, 그 효과는 다소 미미하다고 할 수 있습니다. 아마도 추가적인 리팩토링을 하면 더 나아질 수도 있을 것입니다.

여기서 다음 단계는 서버 컴포넌트로 가능한 한 많이 마이그레이션 하는 것입니다. 앱은 여기저기 상태를 사용하고 있으므로, 앱 전체를 서버 컴포넌트로 합리적으로 구성할 수는 없습니다. 제가 전략적인 위치에 use client를 제거했을 때 (재현 단계 참고), 그 효과는 흥미로웠습니다.

자바스크립트의 크기는 줄어들었습니다. 좋습니다. 일부 페이지에서는 아주 조금만 줄었고 (홈 페이지는 단 2% 정도), 일부 페이지에서는 크게 줄었습니다 (로그인 페이지는 KB 값에서 B 단위로, 거의 0에 가까워졌습니다). 그러나 대부분의 공유 청크는 전혀 변하지 않았고, Inbox 페이지에서 저에게 중요한 모든 지표에 대한 성능 영향은 없었습니다.

따라서 데이터 패칭을 재작성하지 않은 상태에서, 서버 컴포넌트 그 자체만으로는 저의 앱에서 어떠한 성능 영향도 미치지 않았습니다. 그리고 저는 use client가 너무 많은 고민 없이 여기저기 무작위로 붙어 있고 결국 대부분의 페이지의 최상단까지 거슬러 올라가는 대부분의 실제 복잡한 앱에서도 동일할 것이라고 생각합니다.

실험을 재현하는 단계

백엔드 API를 실행합니다: npm run start --workspace=backend-api
frontend/utils/link.tsx 파일로 이동해서 Next.js Link를 주석 해제하고 커스텀 구현을 주석 처리 합니다.
src/frontend/next-app-router/src/app 폴더로 이동하여, 모든 page 파일 상단에 use client를 추가하여 모든 것을 클라이언트 컴포넌트로 강제 전환합니다. 이후, 합리적인 양의 서버 컴포넌트로 되돌리려면 (아직 데이터 패칭은 제외), 모든 use client를 제거합니다.
프런트엔드를 빌드합니다: npm run build --workspace=next-app-router
프런트엔드를 실행합니다: npm run start --workspace=next-app-router
HTTP2/3를 위한 리버스 프록시를 실행합니다: caddy reverse-proxy --to :3000
웹사이트를 https://localhost/inbox 주소로 엽니다.

Next.js App Router 측정 (서버 컴포넌트 및 데이터 패칭 포함)

마이그레이션의 다음 단계는 데이터 패칭 방식을 클라이언트에서 서버로 재작성하는 것입니다.

기본적으로 다음 코드 대신에,

const Sidebar = () => {
  useEffect(() => {
    const fetchSidebarData = async () => {
      const response = await fetch('/api/sidebar')
      const data = await response.json()
      setSidebarData(data)
    }

    fetchSidebarData()
  }, [])
}

이렇게 작성해야 합니다.

const Sidebar = async () => {
  const response = await fetch("/api/sidebar");
  const data = await response.json();

  return <div>{data.map(...)}</div>
};

실제로는 이 과정이 조금 더 복잡했습니다. 저는 모든 사용처를 추적하여 상위 체인에 있는 모든 단일 컴포넌트가 서버 컴포넌트인지, 즉 파일 상단에 use client가 없는지 확인해야 했습니다. 그렇지 않으면, 이 코드가 무한 루프를 일으키기 때문입니다. 따라서 이는 약간의 창의적인 사고와 리팩토링을 요구했습니다.

그리고 마침내 저는 결국 성공했고 측정할 준비가 되었습니다! 다음은 그 수치들입니다.

	LCP (캐시 X / JS 캐시)	사이드바 (캐시 X / JS 캐시)	메시지 (캐시 X / JS 캐시)	토글 상호작용 (캐시 X / JS 캐시)	상호작용 불가능 간극 (캐시 X / JS 캐시)
클라이언트 사이드 렌더링	4.1s / 800ms	4.7s / 1.5s	5.1s / 2s	4.1s / 800ms
서버 사이드 렌더링 (클라이언트 데이터 패칭)	1.61s / 800ms	4.7s / 1.5s	5.1s / 2s	4s / 900ms	2.39s / 100ms
서버 사이드 렌더링 (서버 데이터 패칭)	2.16s / 1.24s	2.16s / 1.24s	2.16s / 1.24s	4.6s / 1.4s	2.44s / 150ms
Next.js Pages (클라이언트 데이터 패칭)	1.76s / 800ms	3.7s / 1.5s	4.2s / 2s	3.1s / 900ms	1.34s / 100ms
Next.js Pages (서버 데이터 패칭)	2.15s / 1.15s	2.15s / 1.15s	2.15s / 1.15s	3.5s / 1.25s	1.35s / 100ms
Next.js App router (Lift-and-Shift)	1.28s / 650ms	4.4s / 1.5s	4.9s / 2s	3.8s / 900ms	2.52s / 250ms
Next.js App router (서버 패칭)	1.78s / 1.2s	1.78s / 1.2s	1.78s / 1.2s	4.2s / 1.3s	2.42s / 100ms

결과는 매우 흥미롭습니다. 여기서 무슨 일이 일어났는지 아시겠나요?

보시다시피, LCP 값은 그대로 옮긴(Lift-and-Shift) 버전과 비교하여 약 500ms 정도 악화되었습니다. 그리고 사이드바 및 메시지 항목 수치는 일치되었습니다. 사실, 이 패턴은 이전에 서버 데이터 패칭이 적용된 Next.js Pages의 패턴을 정확히 반복하고 있습니다. 자바스크립트 다운로드 지연으로 인해 LCP가 낮아지고 상호작용 불가능 구간이 길어진다는 점만 고려한 채 말이죠.

스트리밍 섹션에서 제가 스트리밍 청크가 Suspense에 의해 보호되며, 이를 기억하는 것이 매우 중요하다고 언급했던 것을 기억하십니까? 바로 이것이 그 이유입니다. 만약 여러분이 이 스트리밍 청크들을 Suspense (또는 Next.js의 경우 loading.ts)로 표시하는 것을 잊으면, 리액트는 전체 앱을 하나의 거대한 청크로 취급합니다.

그 결과, 렌더링 시 리액트는 트리에서 마주치는 모든 비동기 컴포넌트를 클라이언트에게 일찍 보내려는 시도 없이 그냥 await하게 됩니다. 그리고 앱은 우리가 클라이언트에게 무언가를 보내기 전에 모든 데이터를 받을 때까지 기다렸던 Next.js Pages나 저의 커스텀 구현과 동일하게 동작합니다.

이 문제를 해결하려면, 우리는 비동기 Server Components를 <Suspense>로 감싸야합니다.

// 렌더링 과정 중 어딘가에서, 사이드바의 경우도 마찬가지입니다.
<Suspense fallback={<div>Loading inbox...</div>}>
  <InboxWithFixedBundlePage messages={messages} />
</Suspense>

이제 우리가 알고 있는 대로 동작할 것입니다. 리엑트는 Suspense 내부의 비동기 컴포넌트가 데이터 패칭을 완료하기를 기다리지 않고, "핵심 경로"에 있는 모든 것을 먼저 렌더링 할 것입니다. 이것이 바로 첫 번째 청크가 됩니다. 그런 다음, 서버는 이 청크를 클라이언트에 전송하고, suspended 된 컴포넌트들을 기다리는 동안 연결을 유지합니다. 즉, Promise들이 반환되기를 기다리며 여유롭게 대기하는 것입니다.

사이드바 데이터가 완료된 후, 해당 Suspense 경계가 처리되고, 또 다른 청크가 준비되어 클라이언트에게 공급됩니다. 메시지 항목도 마찬가지입니다.

올바른 구현에 대한 측정 결과는 다음과 같습니다.

	LCP (캐시 X / JS 캐시)	사이드바 (캐시 X / JS 캐시)	메시지 (캐시 X / JS 캐시)	토글 상호작용 (캐시 X / JS 캐시)	상호작용 불가능 간극 (캐시 X / JS 캐시)
클라이언트 사이드 렌더링	4.1s / 800ms	4.7s / 1.5s	5.1s / 2s	4.1s / 800ms
서버 사이드 렌더링 (클라이언트 데이터 패칭)	1.61s / 800ms	4.7s / 1.5s	5.1s / 2s	4s / 900ms	2.39s / 100ms
서버 사이드 렌더링 (서버 데이터 패칭)	2.16s / 1.24s	2.16s / 1.24s	2.16s / 1.24s	4.6s / 1.4s	2.44s / 150ms
Next.js Pages (클라이언트 데이터 패칭)	1.76s / 800ms	3.7s / 1.5s	4.2s / 2s	3.1s / 900ms	1.34s / 100ms
Next.js Pages (서버 데이터 패칭)	2.15s / 1.15s	2.15s / 1.15s	2.15s / 1.15s	3.5s / 1.25s	1.35s / 100ms
Next.js App router (Lift-and-Shift)	1.28s / 650ms	4.4s / 1.5s	4.9s / 2s	3.8s / 900ms	2.52s / 250ms
Next.js App router (Suspense 없는 서버 패칭)	1.78s / 1.2s	1.78s / 1.2s	1.78s / 1.2s	4.2s / 1.3s	2.42s / 100ms
Next.js App router (Suspense를 포함한 서버 패칭)	1.28s / 750ms	1.28s / 750ms	1.28s / 1.1s	3.8s / 800ms	2.52s / 50ms

좋습니다. 이제 멋지고 엄청나게 빠른 모습입니다! 물론 "상호작용 불가능" 간극은 예외입니다. 그 부분은 여전히 모든 측정치 중에서 가장 나쁜 상태로 남아있습니다.

사실, 이것은 너무 빨라서 모든 수치들이 다시 하나로 합쳐졌습니다. 저는 어딘가에서 어떤 형태의 배칭이 이루어지고 있으며, 이 세 가지 수치가 같은 청크에 포함된 것으로 추측합니다.

하지만 만약 제가 /api/sidebar의 시간을 3s로, /api/messages의 시간을 5s로 늘린다면, 점진적 렌더링의 모습이 뚜렷하게 보일 것입니다. 비록 사용자들에게는 더 빠를 뿐 클라이언트 사이드 렌더링과 정확히 동일하게 보일지라도 말입니다.

하지만 성능 프로파일은 매우 재미있어집니다.

네트워크 섹션에서 보이는 아주 긴 HTML 바가 보이시나요? 저것은 서버가 데이터를 기다리는 동안 연결을 계속 열어두고 있다는 것을 의미합니다. 이를 더 "전통적인" SSR과 비교해 보세요.

HTML은 완료되는 즉시 작업이 끝납니다. 기다릴 필요가 없습니다.

실험을 재현하는 단계

이전 섹션과 동일한 단계를 따르되, 다음 단계를 추가합니다.
src/frontend/next-app-router/src/app/inbox/page.tsx 파일로 이동하여, Suspense를 제외하고 렌더링 함수 내의 관련 import 및 모든 코드를 주석 처리/해제하여 서버 데이터 패칭이 포함된 "고장 난" 스트리밍 경험을 테스트합니다.
위 파일과 src/frontend/next-app-router/components/primary-sidebar-rsc.tsx 파일에서 Suspense를 주석 해제하여 이 문제를 해결합니다.

TL; DR (요약)

좋습니다. 그렇다면 이

~~연구 보고서~~

아티클의 요약은 무엇일까요? 여기 모든 측정값이 담긴 최종 테이블입니다.

	LCP (캐시 X / JS 캐시)	사이드바 (캐시 X / JS 캐시)	메시지 (캐시 X / JS 캐시)	토글 상호작용 (캐시 X / JS 캐시)	상호작용 불가능 간극 (캐시 X / JS 캐시)
클라이언트 사이드 렌더링	4.1s / 800ms	4.7s / 1.5s	5.1s / 2s	4.1s / 800ms
서버 사이드 렌더링 (클라이언트 데이터 패칭)	1.61s / 800ms	4.7s / 1.5s	5.1s / 2s	4s / 900ms	2.39s / 100ms
서버 사이드 렌더링 (서버 데이터 패칭)	2.16s / 1.24s	2.16s / 1.24s	2.16s / 1.24s	4.6s / 1.4s	2.44s / 150ms
Next.js Pages (클라이언트 데이터 패칭)	1.76s / 800ms	3.7s / 1.5s	4.2s / 2s	3.1s / 900ms	1.34s / 100ms
Next.js Pages (서버 데이터 패칭)	2.15s / 1.15s	2.15s / 1.15s	2.15s / 1.15s	3.5s / 1.25s	1.35s / 100ms
Next.js App router (Lift-and-Shift)	1.28s / 650ms	4.4s / 1.5s	4.9s / 2s	3.8s / 900ms	2.52s / 250ms
Next.js App router (Suspense 없는 서버 패칭)	1.78s / 1.2s	1.78s / 1.2s	1.78s / 1.2s	4.2s / 1.3s	2.42s / 100ms
Next.js App router (Suspense를 포함한 서버 패칭)	1.28s / 750ms	1.28s / 750ms	1.28s / 1.1s	3.8s / 800ms	2.52s / 50ms

클라이언트 사이드 렌더링은 예상대로 초기 로드 관점에서는 최악입니다. 하지만 페이지가 나타나는 즉시 상호작용이 가능해집니다. 게다가, 여기서는 모든 서버 기반 전환과 비교했을 때 페이지 간 전환 속도가 가장 빠릅니다.

서버 사이드 렌더링을 도입하면 초기 로드 수치를 극적으로 개선할 수 있지만, "상호작용 불가능" 간극이라는 대가를 치르게 됩니다. 이 간극은 페이지는 이미 보이지만, 자바스크립트로 작동하는 아무것도 동작하지 않는 시간입니다. 이 간극의 크기는 페이지 초기화에 필요한 자바스크립트의 크기에 좌우됩니다.

서버에서 데이터를 패칭 하면 초기 로드 속도는 느려지지만, 전체 페이지 경험을 훨씬 더 일찍 볼 수 있게 됩니다.

"전통적인" SSR에서 RSC와 스트리밍으로, 즉 Next.js Pages에서 Next.js App Router로 마이그레이션 하는 경우, 주의하지 않으면 성능이 악화 될 수 있습니다. 어떠한 개선 효과를 보려면 데이터 패칭 로직을 서버 중심으로 재작성해야 하며, Suspense 경계를 잊지 않아야 합니다. 이는 상당히 중요한 개발 노력이 필요하며 전체 앱의 재설계가 필요할 수 있습니다.

Next.js Pages에서 Next.js App Router로 마이그레이션 하면 자바스크립트 다운로드 지연으로 인해 "상호작용 불가능" 간극이 더 나빠질 수 있습니다. 하지만 이는 브라우저에 따라 다를 수도 있습니다.

앱이 클라이언트 컴포넌트와 서버 컴포넌트로 혼합되어 있는 경우, 서버 컴포넌트 단독으로는 성능이 개선되지 않습니다. 번들 크기를 측정 가능한 성능 영향이 있을 만큼 충분히 줄이지 못하기 때문입니다. 스트리밍과 Suspense가 중요한 요소입니다. 주된 성능 이점은 데이터 패칭을 서버 컴포넌트 우선 방식으로 완전히 재작성하는 데서 나옵니다.

그건 그렇고, Preply의 엔지니어링 팀은 INP를 개선하려는 과정에서 정확히 동일한 결론에 도달했습니다. 성능 조사 및 사례 연구를 읽는 것을 좋아하신다면, Stefano Magni의 다음 아티클을 강력히 추천합니다.

How Preply improved INP on a Next.js application (without React Server Components and App Router)

🚀 한국어로 된 프런트엔드 아티클을 빠르게 받아보고 싶다면 Korean FE Article을 구독해주세요!

'👨‍💻 web.dev > translates' 카테고리의 다른 글

브라우저가 자바스크립트 타이머를 스로틀링(throttle) 하는 이유는 무엇일까요? (2)	2025.10.23

handhand.log

리액트 서버 컴포넌트는 정말 성능을 개선할까요?

성능을 측정하기 위한 프로젝트 소개

우리가 측정할 항목 정의하기

클라이언트 사이드 렌더링 측정

서버 사이드 렌더링 측정 (데이터 패칭 미포함)

서버 사이드 렌더링 측정 (데이터 패칭 포함)

Next.js Pages ("구형" Next.js) 측정

리액트 서버 컴포넌트 소개

리액트 서버 컴포넌트

비동기 컴포넌트

스트리밍

Next.js App Router 측정 (Lift-and-Shift 마이그레이션 후)

Next.js App Router 측정 (서버 컴포넌트 및 데이터 패칭 포함)

TL; DR (요약)

'👨‍💻 web.dev > translates' 카테고리의 다른 글

💬 댓글

티스토리툴바

리액트 서버 컴포넌트는 정말 성능을 개선할까요?

성능을 측정하기 위한 프로젝트 소개

우리가 측정할 항목 정의하기

클라이언트 사이드 렌더링 측정

서버 사이드 렌더링 측정 (데이터 패칭 미포함)

서버 사이드 렌더링 측정 (데이터 패칭 포함)

Next.js Pages ("구형" Next.js) 측정

리액트 서버 컴포넌트 소개

리액트 서버 컴포넌트

비동기 컴포넌트

스트리밍

Next.js App Router 측정 (Lift-and-Shift 마이그레이션 후)

Next.js App Router 측정 (서버 컴포넌트 및 데이터 패칭 포함)

TL; DR (요약)

'👨‍💻 web.dev > translates' 카테고리의 다른 글

📚 관련글

💬 댓글

티스토리툴바