#28. RSC 렌더링과 Static/Dynamic Rendering

RSC 렌더링과 Static/Dynamic Rendering 정리 (App Router)

1) 먼저 용어부터: “RSC”와 “Static/Dynamic”은 다른 축입니다

• RSC(React Server Components)
  컴포넌트를 서버에서 실행/렌더링할 수 있게 해주는 React의 컴포넌트 모델입니다. Next.js App Router에서는 page/layout이 기본적으로 Server Component입니다. Next.js+1
• Static Rendering / Dynamic Rendering
  “서버에서 렌더링을 언제 하느냐 + 그 결과를 캐시하느냐”의 문제입니다.
  즉, RSC를 쓰더라도 어떤 라우트는 **정적(빌드/재검증 시점)**으로, 어떤 라우트는 **동적(요청 시점)**으로 동작합니다. Next.js+1

---

2) RSC 렌더링은 실제로 어떻게 동작하나요?

Next.js(App Router)는 서버에서 렌더링할 때 대략 이런 흐름으로 동작합니다.

1. Server Components → RSC Payload 생성
2. RSC Payload + Client Component JS 정보로 HTML 생성
3. 브라우저는 HTML을 먼저 보여주고, 이어서 RSC Payload로 트리를 맞춘 뒤, Client Components만 Hydration합니다. Next.js+1

핵심 포인트

• Server Component는 브라우저에 JS를 거의 안 보내고(번들 부담↓),
• 상호작용이 필요한 부분만 Client Component로 두어 Hydration합니다. Next.js

---

3) Static Rendering(정적 렌더링)이란?

정적 렌더링은 빌드 시점(build time) 또는 재검증(revalidation) 시점에 서버 렌더링을 해두고, 결과(HTML/RSC Payload)를 캐시해 두는 방식입니다.

• 빠른 응답, CDN 친화적
• 사용자별 개인화가 필요 없는 페이지에 적합(블로그 글, 소개 페이지 등)
• Next.js는 기본적으로 “가능하면 최대한 캐시”하려는 방향입니다. Next.js+1

---

4) Dynamic Rendering(동적 렌더링)이란?

동적 렌더링은 요청이 들어올 때마다 서버에서 렌더링하는 방식입니다.

• 사용자마다 다른 내용(로그인 정보, 쿠키 기반 개인화 등)에 적합
• 라우트 결과를 “Full Route Cache(라우트 전체 캐시)”에서 제외(=요청마다 렌더)하는 경우가 많습니다. Next.js+1

---

5) Next.js는 언제 “정적 → 동적”으로 바뀌나요?

대표적으로 다음을 쓰면 동적 동작이 필요하다고 판단해서 라우트가 동적으로 전환되거나(캐시 제외), 캐시 전략이 달라집니다.

• cookies(), headers(), searchParams 등 Dynamic API 사용
• 또는 fetch를 캐시하지 않도록 설정하는 경우 등 Next.js+1

---

6) 제어 방법 1: fetch 단위로 “캐시/재검증” 제어하기

App Router의 중요한 포인트는 페이지 전체를 SSR/SSG로 이분법 처리하기보다, fetch 요청 단위로 캐싱을 제어하는 모델을 선호한다는 점입니다. Next.js

 

예시)

// 1) 항상 최신(매 요청마다)
await fetch(url, { cache: "no-store" });

// 2) 캐시 사용(정적에 가깝게)
await fetch(url, { cache: "force-cache" });

// 3) 일정 시간마다 갱신(ISR 느낌)
await fetch(url, { next: { revalidate: 60 } }); // 60초

 

그리고 “기본 옵션을 안 줬을 때”의 동작도 렌더링 전략(정적/동적)에 따라 달라질 수 있습니다. Next.js

---

7) 제어 방법 2: Route Segment Config로 라우트 성격을 강제하기

page.tsx/layout.tsx/route.ts에 아래처럼 export 하면 라우트 레벨의 기본 동작을 지정할 수 있습니다. Next.js

 

7-1) dynamic

export const dynamic = "auto"; 
// 'auto' | 'force-dynamic' | 'error' | 'force-static'

• auto(기본): 가능한 많이 캐시하되, 필요하면 동적으로 전환 Next.js
• force-dynamic: 무조건 동적(요청마다 렌더). 모든 fetch를 사실상 no-store/revalidate:0처럼 취급하는 효과 Next.js
• error: “정적으로만” 만들고 싶을 때(동적 API나 캐시 안 되는 fetch가 나오면 에러) Next.js
• force-static: 강제로 정적. 대신 cookies/headers/useSearchParams는 “빈 값”처럼 처리될 수 있음 Next.js

7-2) revalidate

export const revalidate = 60; // 60초마다 재검증
// false | 0 | number

• false: 사실상 무한 캐시(기본 휴리스틱)
• 0: 무조건 동적(항상 새로 렌더)
• number: n초마다 재검증 Next.js

참고: 개발 모드(next dev)에서는 페이지가 항상 on-demand 렌더링되고 캐시되지 않습니다. 운영에서의 정적/동적과 다르게 보일 수 있습니다. Next.js

---

8) 실무 선택 가이드

상황추천

소개/홍보/블로그 글(개인화 없음)	Static(기본 auto) + 필요 시 revalidate
로그인 사용자별 대시보드/내 정보	Dynamic(force-dynamic 또는 동적 API/no-store)
“대부분은 캐시, 일부만 최신” 혼합	라우트는 유지하되, 특정 fetch만 no-store (하이브리드 가능) Next.js

---

9) 한 줄 요약

• RSC는 “서버에서 컴포넌트를 실행/렌더링하는 모델”이고, Next.js+1
• Static/Dynamic Rendering은 “언제 렌더링하고 캐시하느냐”의 전략입니다. Next.js+1
• App Router에서는 fetch 단위 캐싱 제어가 핵심이며, 필요하면 dynamic/revalidate로 라우트 성격을 강제할 수 있습니다. Next.js