인프런 커뮤니티 질문&답변

안녕하세요 이정환입니다.

우선 서버컴포넌트, 클라이언트 컴포넌트 모두 사전렌더링 단계에서 html로 생성됩니다. 두 컴포넌트간의 차이는 오직 JS Bundle에 해당 컴포넌트의 코드가 포함되어 브라우저에서 하이드레이션 되느냐 마느냐의 차이입니다.
(3.5 리액트 서버 컴포넌트 주의사항 챕터의 1분 45초를 참고하세요)

풀 라우트 캐시는 클라이언트, 서버 컴포넌트 관계없이 생성됩니다. 특정 페이지에 캐싱되지 않는 fetch나 동적 함수(쿠키, 헤더, 서치파람스, 파람스 등)이 사용될 경우 Dynamic 페이지로 설정되고 그렇지 않을 경우 Static Page로 설정되어 빌드 타임에 생성됩니다.

추가로 Dynamic 페이지임에도 빌드 타임에 오류가 발생하는 이유에 대해서 질문주셨는데요 Next.js는 기본적으로 빌드타임에 모든 페이지를 한번 검사합니다. 이를 통해 빌드 이후에 프로덕션으로 실행되었을 때 문제가 발생할 수 있는 부분이 있다면 빌드가 실패하게 됩니다.

안녕하세요, 인프런 AI 인턴입니다. 강기봉님께서 Next.js의 풀 라우트 캐시 및 사전 렌더링 과정에 대해서 질문을 주셨군요.

Next.js에서의 렌더링과 캐싱 개념은 초기 페이지 로드 성능을 최적화하고 사용자 경험을 개선하는 데 중요한 요소입니다. 풀 라우트 캐시는 사전 렌더링한 콘텐츠를 재사용하여 페이지 로드 속도를 높이는 전략입니다. 관련 내용을 다룬 유사한 질문과 답변이 아래에 있습니다.

1. 서버 컴포넌트와 정적 페이지의 캐싱:
   
   • 정적 페이지의 경우, 빌드 시점에 한 번 사전 렌더링하여 HTML 파일을 생성합니다. 이 HTML 파일은 서버에 저장되며, 사용자가 해당 페이지에 접근할 때마다 해당 캐시된 HTML을 브라우저에 전달합니다. 이러한 구조는 마치 CDN이 정적 자원을 제공하는 방식과 유사합니다.
     

관련 정보는 Next.js 정적 페이징과 캐시 질문에서 확인 가능합니다.

2. 클라이언트 컴포넌트와 동적 페이지의 처리:
   
   • 동적 페이지는 사용자의 요청에 따라 실시간으로 서버에서 렌더링됩니다. 사전 렌더링이 빌드 타임이 아닌 요청 시점에 이루어지며, 이런 경우 풀 라우트 캐시는 사용되지 않습니다. 각 요청마다 새로 서버에서 처리되기 때문입니다.
     

여기에서 더 자세한 설명은 Next.js 동적 페이지 렌더링 질문을 참고해주세요.

이 과정은 Next.js의 사전 렌더링 전략에 따라 다르게 적용되며, 각각의 장단점이 존재합니다. 따라서 프로젝트 요구사항에 따라 적절한 렌더링 및 캐싱 전략을 선택하는 것이 중요합니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.