💡 15. 서버로 회귀하다: RSC와 next.js 브릿지

🎯 이 섹션을 읽고 나면:

• React Server Components(RSC)가 기존의 SSR(Server-Side Rendering)과 완전히 다른 마법이라는 점을 이해한다.
• use client 최상단 지시어의 진짜 의미가 '브라우저 전용 실행'이 아니라 단절의 경계선(Network Boundary) 임을 완벽히 그려낼 수 있다.
• 컴포넌트의 책임 소재지(서버냐, 클라이언트냐)를 명확히 판별하는 시각을 갖는다. (대단원 마무리)

📋 목차

• 🤔 왜 알아야 하는가: JS 번들 다이어트의 전쟁
• 🏗️ 비유로 먼저 이해하기
• 🧩 극의 체득: RSC와 use client의 진짜 임무
  • ✅ 1. RSC의 철칙 (서버의 영토)
  • ✅ 2. use client 선언의 진짜 뜻 (도개교 내리기)
• 🏁 드디어, 대단원 총정리
• 📝 마무리(에필로그) 퀴즈

📌 이 문서를 읽기 전에

⏱️ 예상 읽기 시간: 10분 / 핵심 파트: 6분

🗺️ 이 문서의 배경 세계관: '영수네 커뮤니티'

• 영철(신입):"선배님! Next.js 13 버전부터 페이지 상단에 use client 쓰라고 계속 에러가 떠서 답답해요. 그냥 _app.tsx 젤 위에 한 번 적어두면 전부 클라이언트로 편하게 쓸 수 있는 거 아닌가요?"
• 영호(리드):"영철 님. 그걸 전부 클라이언트로 돌려버릴 거면 무거운 번들 파일을 유저 브라우저로 모두 보내겠다는 뜻입니다. 우리는 지금 10년 만에 일어난 '프론트엔드의 대륙 이동(서버사이드 영토 귀환)' 의 한가운데 서 있습니다."

🤔 왜 알아야 하는가: JS 번들 다이어트의 전쟁

지금까지 01강부터 14강까지 배운 모든 내용은 단서를 달고 있었습니다.
"이 코드는 브라우저(크롬, 사파리) 위에서 실행된다."

하지만 생각해보세요. 당신이 거대한 날씨 라이브러리 moment.js (크기: 300KB)나 Markdown 렌더링 라이브러리를 써서 화면을 그린다고 칩시다.
기존의 React 생태계(CSR, 전통적 SPA)에서는 사용자가 모바일 환경에서 내 사이트에 들어오자마자 그 무거운 코딩 파일 300KB를 몽땅 다운로드해야 비로소 실행이 시작되었습니다. "로딩 중..." 스피너가 무한정 뱅글뱅글 돕니다.

🤔 잠깐, 먼저 생각해봐
이거 우리 컴퓨터(서버) 성능 좋은데... 우리가 서버에서 저 무거운 라이브러리들 돌려서 HTML만 예쁘게 깎아낸 다음 결과물 텍스트(문자열)만 폰으로 보내주면 유저 데이터(MB)도 아끼고 로딩도 0.1초 컷 아닐까?

예. 그 생각에서 출발한 궁극의 진화가 바로 React Server Components (RSC) 입니다.

🏗️ 비유로 먼저 이해하기

🧒 5살에게 설명한다면?

1. 과거 (Client Component 위주 시대):
   식당 요리사(영철)가 손님(브라우저)에게 생고기, 야채, 칼, 도마, 가스버너(거대한 JS 번들 코드 덩어리)를 박스 채로 테이블에 한꺼번에 건네줌.
   “손님! 여기서부터는 손님 휴대폰이 직접 가스버너 켜고(useEffect), 네이버에 날씨 물어보고(fetch), 고기 구워서 햄버거 조립(렌더링)해 드세요!” -> 유저 폰이 엄청 뜨거워지고 로딩이 김.

2. 현재 (서버 컴포넌트, Server Components):
   강력한 주방(Node.js 서버)에서 요리사(영호)가 엄청 빠른 속도로 날씨도 알아오고, 고기도 다 굽고 마크다운파싱 라이브러리 처리도 다 끝냄.
   테이블(유저 폰)에는 뭐만 배달해주느냐? 단 0.01초 만에 이쁘게 완성된 햄버거(정적인 HTML 레이아웃)만 식탁 위에 사뿐히 올려줌.
   유저는 파일 용량을 거의 안 받아도 화면을 즉각(0초 만에) 보게 됨!

이 엄청난 패러다임 때문에 Next.js 같은 신기술 위에서는 이제 "모든 컴포넌트의 기본값(Default)은 무조건 주방(서버 컴포넌트)에서 구워진다" 로 규칙이 완전히 뒤집힌 것입니다.

🧩 극의 체득: RSC와 use client의 진짜 임무

그럼 영철이의 질문으로 돌아가 봅시다. 왜 자꾸 에러가 나고 use client를 강제했을까요?

서버 주방에서 요리를 암만 잘 구워서 줬어도, "손님이 직접 버튼을 누를 때마다 발생하는 반응(onClick)" 이나 "손님의 지금 현재 마우스 위치(useState)" 는 서버 주방에서 알 턱이 없기 때문입니다!

✅ 1. RSC의 철칙 (서버의 영토)

기본적으로 아무것도 안 적으면 몽땅 서버 컴포넌트 입니다.

// 🎯 이거슨 서버 컴포넌트 (Next.js 13+ App Router 기준)
// 최상단에 아무것도 없다. 고로 나는 서버에서 빚어져 내려간다.
 
import fs from 'fs'; // 헉! 리액트 내부에서 디스크 파일 읽기가 가능해짐!
import HeavyMarkdownToHtml from 'markdown-heavy-lib'; // 300MB짜리 위험한 무거운 라이브러리!
 
// 헉! 컴포넌트 함수 앞에 async가 붙어? (useEffect 없이 await로 API 직빵 콜)
export default async function WeatherBoard() {
  const dbData = await db.query("SELECT * FROM weather"); // DB 직접 찌르기!
  const htmlResult = HeavyMarkdownToHtml(dbData.content);
 
  // 💥 중요한 혜택: 위에서 쓰인 HeavyMarkdownToHtml 라이브러리 소스코드는
  // 유저의 브라우저로 1kb도 전송(다운로드)되지 않는다! 오직 변환된 <div> 결과물만 전송!
  return <div>{htmlResult}</div>;
}

이건 기존 CSR 리액트로선 감히 상상도 못할 압도적인 능력입니다. 파일 크기 제로, 로딩 제로.

✅ 2. use client 선언의 진짜 뜻 (도개교 내리기)

그런데 위 게시판 안에 "👍 좋아요 버튼"을 달아야 합니다. 클릭하면 숫자가 올라가는 상태(useState)가 필요하죠.
서버 컴포넌트 안에서 export default function WeatherBoard 안에 onClick= 이딴 걸 쓰면 다음과 같은 에러가 빡! 터집니다.

"Error: Event handlers cannot be passed to Client Component props. (이봐! 여긴 서버 주방이라고! 유저 마우스 클릭 이벤트를 내가 여기서 어떻게 감지해!)"

이럴 때 쓰는 것이 바로 use client 입니다.
use client는 "리액트 엔진님, 요 파일부터는 주방(서버) 밖으로 보내서, 유저 폰(클라이언트) 안에서 직접 자바스크립트로 실행되게 번들을 포장 배달해주세요!" 라는 네트워크 경계선(Boundary) 커팅 지시어 입니다.

// 🎯 1. LikeButton.tsx 파일 (새로 분리)
'use client' // 여권을 발급했다. "나는 지금부터 브라우저 클라이언트 땅으로 입국할 코드다."
 
import { useState } from 'react';
 
export default function LikeButton() {
  const [likes, setLikes] = useState(0); // 폰에서 돌아갈 로직
  return <button onClick={() => setLikes(c => c+1)}>❤️ {likes}</button>;
}

이제 서버에서 도는 거대한 게시판(WeatherBoard) 안에, 클라이언트에서 상호작용할 작은 조각(LikeButton)을 구멍 송송 파서 끼워 넣으면 환상적인 하이브리드 아키텍처가 완성됩니다.

// 🎯 2. WeatherBoard.tsx 파일 (서버 주방)
// (use client 구문 없음. 고로 서버)
import LikeButton from './LikeButton'; // 브릿지 결합!
 
export default async function WeatherBoard() {
  return (
    <div>
      <h1>오늘의 날씨 (서버에서 DB 긁어옴)</h1>
      <p>구름 많음</p>
 
      {/* 🚀 여기 하위부터는 클라이언트 폰에서 자바스크립트가 돌기 시작한다 🚀 */}
      <LikeButton />
    </div>
  );
}

우리는 이것을 "나뭇잎(Leaf) 끝단으로 클라이언트 컴포넌트를 몰아내라 (Push client components to the leaves)" 라고 부릅니다.
무거운 렌더링 트리의 기둥과 가지(Layout, Data Fetching, Markdown 렌더)는 튼튼한 서버에서 맡아 다 그려버리고, 나뭇잎 끝에서 살랑거리는 버튼 인터랙션 부스러기들만 떼어내서 유저 브라우저(폰)에 전송하는 환상적인 성능 최적화 구조.

이것이 프론트엔드의 다음 목적지, 브릿지 하이브리드 패턴 입니다.

🏁 드디어, 대단원 총정리

지금까지 신입 '영철'이가 겪은 모든 리액트의 함정과, 리드 '영호'가 알려준 시니어의 통제 기술을 목도했습니다.

1. 상태 관리의 착각 (가이드 1~4): 상태는 렌더링 스냅샷이다. 불변성은 화면을 새로 그리기 위한 신호탄이다. 함부로 전역 도구를 치덕치덕 바르기 전에 "State Colocation(밑동으로 밀어내기)"을 실천하라.
2. 이펙트와 라이프사이클 미드 (가이드 5~8): useEffect는 마운트 시점 콜백을 모아두는 장소이 아니라, 리액트 외부 영역(DOM API, 서버 동기화)과 수위를 맞추는 동기화 지점다.
3. 최적화 강박의 해체 (가이드 9~11): useMemo나 useCallback으로 막장 방어를 짜기 전에, "컴포넌트 쪼개기 + Children 합성 + Context State/Action 분단" 이라는 영호의 근원적 아키텍처 수술법을 들이밀어라.
4. 차세대 디자인 캡슐화 (가이드 12~14): 제어권을 부모로 다 내던지고(IoC), 컴파운드 블록을 역할별로 나누고, Headless Hook로 로직 코어를 완벽히 적출하면 그 어떤 디자인이 바뀌어도 두렵지 않다.
5. 서버로 귀환 (현재 가이드 15): 이제 리액트는 브라우저라는 감옥을 탈출해 서버까지 집어삼켰다. 영호와 영철이는 바야흐로 RSC 라는 새로운 대륙에 도달했다.

단언컨대, 당신이 15강까지의 코드를 눈으로 좇으며 고개를 끄덕였다면, 당신은 이미 단순한 '코더'를 넘어 시스템의 병목을 진단하고 부숴버리는 '5년 차 프론트엔드 설계자'의 뇌를 장착한 것입니다.

그동안 기나긴 대장정을 함께한 영수네 커뮤니티 전대원에게 박수를 보냅니다! 코딩의 축복이 당신의 빌드 파이프라인과 함께하기를.

📝 마무리(에필로그) 퀴즈

Q1. 영철이가 App Router의 최상단 layout.tsx에 습관처럼 'use client'를 붙이면 어떤 문제가 생기나요?

✅ 정답: 상위 경계 아래의 많은 하위 컴포넌트가 클라이언트 번들로 따라 내려가 JS 다운로드와 hydration 비용이 커진다

💡 상세 해설:

• 원리 설명: 'use client'는 파일 하나의 편의 플래그가 아니라 서버와 클라이언트를 가르는 번들 경계입니다. 영호가 말한 것처럼 데이터 조회, 마크다운 변환, 정적 레이아웃은 서버에 남기고 버튼이나 입력처럼 브라우저 상호작용이 필요한 leaf만 클라이언트로 내려야 합니다.
• 오답 피드백: 에러가 사라진다는 이유로 경계를 위로 올리면 RSC의 장점인 작은 번들, 서버 데이터 접근, 낮은 hydration 비용을 잃습니다.
• 📌 핵심 기억법: 클라이언트 경계는 편의가 아니라 비용입니다.

Q2. 서버 컴포넌트 내부에서 직접 처리하면 안 되는 것은 무엇인가요?

✅ 정답: useState, useEffect, onClick처럼 브라우저 상태와 사용자 이벤트에 의존하는 상호작용 로직

💡 상세 해설:

• 원리 설명: 서버 컴포넌트는 브라우저의 현재 클릭, 포커스, 창 크기, 로컬 상태를 알 수 없습니다. 영숙이 요구한 좋아요 버튼처럼 사용자가 직접 만지는 부분은 작은 Client Component로 분리해야 합니다.
• 오답 피드백: 서버 컴포넌트가 HTML을 만들 수 있다고 해서 브라우저 이벤트까지 감지할 수 있는 것은 아닙니다.
• 📌 핵심 기억법: 서버는 준비하고, 클라이언트는 반응합니다.

Q3. 서버 컴포넌트가 클라이언트 컴포넌트에 값을 넘길 때 확인해야 할 가장 중요한 조건은 무엇인가요?

✅ 정답: 네트워크 경계를 지나갈 수 있도록 직렬화 가능한 데이터만 props로 전달해야 한다

💡 상세 해설:

• 원리 설명: RSC 경계는 함수 호출 경계가 아니라 서버에서 브라우저로 전달되는 데이터 경계입니다. 함수, DB 커넥션, 클래스 인스턴스처럼 실행 환경에 묶인 값은 그대로 넘길 수 없습니다.
• 오답 피드백: 영수네 커뮤니티 게시글 데이터처럼 JSON으로 표현 가능한 값은 괜찮지만, 서버에서만 의미 있는 리소스를 클라이언트에 들고 가려 하면 경계가 무너집니다.
• 📌 핵심 기억법: props는 실행 코드가 아니라 전달 가능한 데이터입니다.

🐣 영철이의 퇴근 일기

15강 대장정을 마무리하며 가장 크게 바뀐 생각은 하나다. use client는 에러를 없애는 주문이 아니라 영수네 커뮤니티의 서버와 사용자 브라우저 사이에 놓는 실제 경계선이었다. 예전의 나는 "버튼 하나 때문에 귀찮으니 위에 붙이면 되겠지"라고 생각했지만, 이제는 그 한 줄이 영숙이 만든 화면의 로딩감과 영수가 보는 운영 비용까지 바꾼다는 걸 안다.

💡 "무거운 데이터 접근과 정적 구조는 서버에 남기고, 사용자가 직접 만지는 작은 조각만 클라이언트로 내려보내라."

영호는 오늘도 답을 대신 주기보다 판단 기준을 남겼다. 렌더링, 상태, 이펙트, 합성, 접근성, 그리고 RSC까지 지나오면서 나는 React를 문법 묶음이 아니라 비용과 책임을 배치하는 도구로 보기 시작했다. 이제 적어도 "어디에서 실행되어야 하는가"를 먼저 묻는 개발자가 되었다.