2nd/10_Wiki/Topics/Frontend/Next.js를 활용한 하이브리드 렌더링 및 React Server Components 도입.md

# [[Next.js를 활용한 하이브리드 렌더링 및 React Server Components 도입|Next.js를 활용한 하이브리드 렌더링 및 React Server Components 도입]]

## 📌 Brief Summary
[[Next.js|Next.js]]를 활용한 하이브리드 렌더링은 단일 애플리케이션 내에서 페이지와 컴포넌트의 특성에 맞춰 CSR, SSR, SSG, ISR 등의 렌더링 방식을 혼합하여 사용하는 유연한 아키텍처입니다 [1, 2]. 여기에 React Server Components(RSC)가 도입되면서, 서버에서만 실행되고 클라이언트로는 [[JavaScript|JavaScript]] 번들을 전혀 전송하지 않는 렌더링이 가능해졌습니다 [3-5]. 이를 통해 개발자는 초기 로딩 속도를 대폭 개선하고 클라이언트의 연산 부담을 줄이며, 데이터베이스에 직접 안전하게 접근하는 최적화된 웹 애플리케이션을 구축할 수 있습니다 [6-8].

## 📖 Core Content
*   **Next.js 하이브리드 렌더링 전략**
    Next.js와 같은 최신 프레임워크는 모든 페이지에 단일 렌더링 방식을 강제하지 않고 여러 방식을 혼합(Hybrid)하여 사용할 수 있게 합니다 [1, 9]. 예를 들어, 마케팅 및 문서 페이지에는 가장 빠른 속도를 제공하는 SSG를, 실시간 재고 데이터가 필요한 상품 페이지나 뉴스 기사에는 SSR을, 검색 엔진 최적화(SEO)가 필요 없고 상호작용이 많은 사용자 대시보드에는 CSR을 적용하는 등 각 페이지 요구사항에 맞는 렌더링을 선택할 수 있습니다 [1, 2].

*   **[[React Server Components (RSC)|React Server Components (RSC]]의 특징과 장점**
    RSC는 클라이언트 측 JavaScript 번들에 0바이트(Zero bytes)의 코드를 추가하는 서버 전용 컴포넌트입니다 [3, 5, 10]. 브라우저로 코드가 전송되지 않으므로, 데이터베이스에 직접 쿼리하거나 로컬 파일 시스템을 읽고, 민감한 환경 변수나 API 키에 접근하는 등의 서버 전용 작업을 안전하게 수행할 수 있습니다 [6, 7, 10]. 또한, 클라이언트 측에서 실행되지 않기 때문에 하이드레이션([[Hydration|Hydration]]) 과정 자체가 필요하지 않아 더욱 빠른 화면 표시와 최적화가 가능합니다 [4, 11, 12].

*   **서버 컴포넌트와 클라이언트 컴포넌트의 혼합 (Mixing Components)**
    RSC 모델에서는 상호작용이 필요 없는 무거운 컴포넌트는 서버에 두고, 버튼, 폼 입력 등 브라우저 상태([[State|State]])와 이벤트 핸들러(onClick 등)가 필요한 인터랙티브한 부분만 클라이언트 컴포넌트로 분리할 수 있습니다 [10, 13, 14]. 클라이언트 컴포넌트는 파일 최상단에 `"use client"` 지시어를 명시하여 선언합니다 [10, 15]. 중요한 규칙은, 서버 컴포넌트는 클라이언트 컴포넌트를 렌더링(포함)할 수 있지만, 클라이언트 컴포넌트는 서버 컴포넌트를 직접 임포트할 수 없다는 단방향(Server → Client) 의존성 원칙이 적용된다는 것입니다 [15-17].

*   **작동 방식 및 React Flight 프로토콜**
    RSC는 렌더링 시 단순히 순수한 HTML만 반환하는 것이 아닙니다 [18]. 서버는 정적인 부분의 HTML과 클라이언트가 전체 컴포넌트 트리를 조립하는 데 사용하는 '직렬화된 React 명령어(React Flight 프로토콜)'를 브라우저로 함께 스트리밍(Streaming)합니다 [4, 12, 19].

*   **프로덕션 도입 시 주의점 및 최적화**
    RSC를 사용한다고 해서 모든 성능 문제가 자동으로 해결되는 것은 아닙니다 [20]. 데이터 페칭 의존성이 순차적으로 구성되어 있다면, 브라우저에서 발생하던 워터폴(Waterfall) 현상이 서버에서 그대로 발생할 수 있습니다 [21, 22]. 따라서 데이터를 병렬로 페칭(Fetching)하도록 아키텍처를 설계해야 합니다 [23, 24]. 또한, `"use client"` 지시어를 남용하여 너무 많은 컴포넌트를 클라이언트로 전환하게 되면, 대규모 JavaScript 번들이 브라우저로 전송되어 RSC의 이점이 사라지므로 클라이언트 경계를 최소한으로 얕게 유지해야 합니다 [25, 26].

## 🔗 Knowledge Connections
- **Related Topics:** [[Client-Side Rendering (CSR)|Client-Side Rendering (CSR]], Server-Side Rendering (SSR), Static Site Generation (SSG), Incremental Static Regeneration (ISR), [[Hydration|Hydration]], React Flight 프로토콜
- **Projects/Contexts:** [[Next.js App Router|Next.js App Router]]
- **Contradictions/Notes:** 소스에서는 React Server Components가 번들 크기를 줄이고 데이터 액세스를 개선하는 강력한 수단이지만 결코 '은탄환'은 아니라고 지적합니다. 잘못 구성될 경우 캐싱 복잡성을 더하거나 서버 측 워터폴(Server-side Waterfall)을 일으켜 성능 병목 지점만 클라이언트에서 서버로 옮기는 결과를 낳을 수 있으므로 철저한 설계가 필수적입니다 [20, 22, 27].

---
*Last updated: 2026-04-25*