학습 문서/guides

Rendering Philosophy#

학습 목표#

  • Next.js가 정적·다이나믹 렌더링의 경계를 라우트가 아니라 컴포넌트 수준에서 다루는 이유를 설명한다.
  • 빌드 시점 prerendering, 라우트 수준 경계, 컴포넌트 수준 경계의 장단점을 비교한다.
  • 이 렌더링 모델이 호스팅 플랫폼에 요구하는 스트리밍·캐시 일관성·조정 능력을 구분한다.
  • 기능 충실도(functional fidelity)와 성능 충실도(performance fidelity)를 구분해 배포 대상을 평가한다.

핵심 개념 및 설명#

정적과 다이나믹은 연속선이다#

많은 웹 프레임워크는 라우트 단위로 정적 페이지와 다이나믹 페이지를 나눈다. 페이지 전체를 빌드 시점에 prerender하거나, 요청마다 서버에서 렌더링하는 식이다. 정적 파일은 CDN에 올리고 다이나믹 라우트는 서버로 보내므로 이해와 배포가 단순하다.

Next.js는 정적과 다이나믹의 경계를 라우트가 아니라 컴포넌트 수준에 둔다. 한 페이지 안에서 즉시 표시되는 static shell, 독립적으로 다시 검증되는 캐시 함수, 준비되는 대로 스트리밍되는 다이나믹 영역이 함께 존재할 수 있다. 정적 페이지도 다시 배포하지 않고 갱신할 수 있다.

Partial Prerendering, Cache Componentsuse cache, 요청 기반 revalidation이 이 모델을 구현한다. 이 기능들은 서로 떨어진 편의 기능이 아니라 정적·다이나믹 렌더링을 이분법 대신 연속선으로 다루는 하나의 모델이다.

이 모델이 가능하게 하는 것#

  • 더 빠른 체감 로딩: static shell을 먼저 표시하고 다이나믹 콘텐츠를 이어서 스트리밍한다. 사용자는 페이지 전체가 준비되기 전에 유용한 내용을 본다.
  • 점진적 캐싱: 빌드 전에 라우트 전체의 성격을 결정하지 않고 필요한 함수부터 캐싱하고 revalidation할 수 있다.
  • 세밀한 캐싱: 라우트 대신 비싼 데이터베이스 질의 같은 함수 하나를 캐싱하고, 배포 대신 태그 하나를 revalidation한다.

선택에 따르는 대가#

빌드 시점 prerendering#

모든 페이지를 빌드 시점에 정적 파일로 생성한다. 별도 런타임 인프라 없이 CDN이나 파일 서버에서 제공할 수 있어 배포가 가장 단순하다. 다이나믹 콘텐츠는 페이지가 로드된 뒤 클라이언트에서 가져와야 하며, 콘텐츠가 바뀔 때마다 다시 빌드하고 배포해야 한다.

라우트 수준 경계#

각 라우트를 정적 또는 다이나믹으로 선택한다. 인프라 구성이 명확하지만 선택은 라우트 전체에 적용된다. 사용자 인사말이나 실시간 가격처럼 작은 다이나믹 요소 하나 때문에 페이지 전체를 요청마다 렌더링하거나, 그 요소만 클라이언트에서 나중에 가져와야 한다.

컴포넌트 수준 경계#

Next.js가 택한 방식이다. 하나의 스트리밍 응답 안에서 정적 콘텐츠와 다이나믹 콘텐츠가 공존한다. 애플리케이션 코드는 별도 라우트나 클라이언트 fetching으로 쪼개지 않아도 되지만, 더 세밀해진 경계를 지원하는 복잡성은 호스팅 플랫폼이 떠안는다.

인프라에 미치는 영향#

  • 스트리밍: 서버가 초기 콘텐츠를 먼저 보내고 다이나믹 영역을 준비되는 대로 이어서 보내야 한다. 자세한 흐름은 Streaming에서 다룬다.
  • 캐시 조정: 여러 인스턴스가 실행될 때 태그나 경로 revalidation을 모든 인스턴스에 전파해야 한다. 구조는 How Revalidation Works에서 다룬다.
  • 캐시 일관성: revalidation은 HTML과 RSC payload를 함께 다시 만든다. 둘이 어긋나면 브라우저 내비게이션과 클라이언트 내비게이션이 서로 다른 내용을 보일 수 있다.
  • CDN 지연 시간으로 PPR shell 제공: 정적 shell을 별도로 저장하고 다이나믹 렌더링을 올바르게 재개하려면 플랫폼 통합이 더 필요할 수 있다.

이식성과 충실도#

Next.js는 Node.js 서버 프로세스로 실행할 수 있으며 단일 프로세스에서도 모든 기능이 올바르게 동작한다. 스트리밍이 없으면 응답이 버퍼링되지만 기능 자체는 계속 동작한다. CDN 캐싱, 엣지 컴퓨팅, 공유 캐시는 성능을 높이고 다중 인스턴스 환경의 일관성 간극을 줄인다.

기능 충실도(functional fidelity)는 Next.js 기능이 플랫폼에서 올바르게 동작하는지를 뜻한다. 어댑터 테스트 스위트 통과 여부로 판단하는 이분법적 기준이다. 성능 충실도(performance fidelity)는 PPR shell의 CDN 제공이나 ISR의 빠른 전파처럼 기능이 최적의 성능 특성을 달성하는 정도다. 플랫폼 구조에 따라 달라지는 연속적인 기준이다.

기능 충실도를 달성한 플랫폼은 완전히 지원되는 배포 대상이며, 성능 충실도가 플랫폼 간 차이를 만든다.

CDN 기능 호환성#

많은 CDN은 엣지 컴퓨팅, 키-값 저장소, 블롭 저장소 같은 기본 요소를 제공한다. 그러나 PPR을 끝까지 재개하는 지원은 아직 발전 중이며 플랫폼별 구현이 필요할 수 있다. 현재 다수의 커뮤니티 어댑터는 CDN 고유 기능을 사용하기보다 Next.js를 Node.js 서버로 배포한다.

예제 및 데모 설계#

  • Phase 1 상태: 구현 예정
  • 동일한 페이지에서 정적 상품 설명, use cache로 캐싱한 추천 목록, 사용자별 장바구니를 각각 구분한다.
  • 네트워크 타임라인에서 static shell이 먼저 도착하고 다이나믹 영역이 뒤이어 채워지는 과정을 표시한다.
  • 단일 서버, 스트리밍을 버퍼링하는 프록시, 공유 캐시를 둔 다중 인스턴스를 전환해 기능 충실도와 성능 충실도의 차이를 비교한다.

연습 문제#

  1. Next.js 렌더링 모델의 정적·다이나믹 경계는 어디에 놓이는가?
  • A. 애플리케이션 전체
  • B. 배포 전체
  • C. 라우트 전체
  • D. 컴포넌트
정답 보기

정답: D. 한 라우트 안에서 정적 shell, 캐시 함수, 다이나믹 영역이 공존할 수 있다.

  1. 기능 충실도와 성능 충실도에 관한 설명으로 옳은 것을 모두 고르시오.
  • A. 기능 충실도는 어댑터 테스트 통과 여부로 판단할 수 있다.
  • B. 성능 충실도는 모든 플랫폼에서 동일하다.
  • C. 스트리밍이 버퍼링돼도 기능은 동작할 수 있다.
  • D. 기능 충실도를 달성하지 않아도 완전히 지원되는 배포 대상이다.
정답 보기

정답: A, C. 기능 충실도는 올바른 동작, 성능 충실도는 최적의 성능 특성을 뜻한다.

챕터 요약#

  • Next.js는 정적·다이나믹 렌더링을 컴포넌트 수준의 연속선으로 다룬다.
  • 이 모델은 빠른 static shell, 점진적 캐싱, 세밀한 revalidation을 가능하게 한다.
  • 애플리케이션의 단순성을 얻는 대신 호스팅 플랫폼은 스트리밍과 캐시 조정을 담당한다.
  • HTML과 RSC payload는 같은 정책으로 함께 캐싱하고 revalidation해야 한다.
  • 배포 플랫폼은 기능 충실도와 성능 충실도를 나누어 평가해야 한다.

이 문서의 실습 데모