1️⃣ 클라이언트 라우터 캐시란?
클라이언트 라우터 캐시는 브라우저 측에 저장되는 캐시로, Next.js에서 페이지 이동을 보다 효율적으로 처리하기 위해 일부 데이터를 보관하는 기술이다.
이 캐시는 한 번 접속한 페이지의 공통 레이아웃 컴포넌트와 서버 컴포넌트 데이터(RSC Payload)를 브라우저에 저장하여, 페이지 이동 시 동일한 데이터를 다시 서버로부터 요청하지 않도록 최적화한다.
즉, 서버 렌더링 기반 구조를 유지하면서도, 클라이언트 측에서 가능한 데이터는 최대한 재활용하는 전략이라고 이해하면 된다.
2️⃣ 왜 클라이언트 라우터 캐시가 필요한가?
예를 들어, 브라우저에서 index 페이지에 접속한 후 search 페이지로 이동한다고 가정해 보자.
1. index 페이지 접속
브라우저는 Next.js 서버로부터 다음 데이터를 전달받는다.
- 정적으로 생성된 HTML
- 클라이언트 컴포넌트 번들
- 서버 컴포넌트 데이터를 포함하는 RSC Payload
이 RSC Payload에는 다음과 같은 데이터가 포함된다.
- 루트 레이아웃
- 서치바 레이아웃
- index 페이지를 구성하는 서버 컴포넌트 데이터
2. search 페이지 이동
search 페이지는 dynamic 페이지라고 가정하자.
즉, 실시간 데이터를 생성한다.
이 경우에도 서버는 새로운 RSC Payload를 전달하는데, 그 안에는 다음이 포함된다.
- 동일한 루트 레이아웃
- 동일한 서치바 레이아웃
- search 페이지의 서버 컴포넌트 데이터
결과적으로 브라우저는 동일한 레이아웃 데이터를 두 번 요청하게 된다.
이것은 네트워크 낭비이자 성능 비효율이다.
3️⃣ 클라이언트 라우터 캐시의 역할
이 문제를 해결하기 위해 Next.js는 브라우저에 클라이언트 라우터 캐시를 생성한다.
작동 방식
- 서버로부터 전달받은 RSC Payload를 브라우저에 저장
- 공통 레이아웃 및 이미 로드된 서버 컴포넌트 데이터를 캐싱
- 페이지 이동 시, 변경된 데이터만 서버에 추가 요청
즉,
- 공통 데이터 → 캐시에서 재사용
- 새로운 데이터 → 서버에 요청
✅ 결과
- 서버 요청 감소
- 동일한 레이아웃 데이터를 반복 요청하지 않음
- 페이지 이동 속도 증가
- 브라우저가 저장된 데이터를 즉시 사용
- 네트워크 최적화
- 중복 데이터 전송 제거
4️⃣ 클라이언트 라우터 캐시 확인하기 (실습)
1. 개발 환경 준비
npm run devNext.js 앱의 개발 모드를 실행한다.
2. 공통 레이아웃 컴포넌트 수정
(with-searchbar)/layout.tsx 파일에서 searchbar 레이아웃을 수정한다.
return (
<div>
{/* 렌더링 시간을 출력 */}
{new Date().toLocaleString()}
{children}
</div>
);3. 동작 확인
✅ index 페이지 접속
- 브라우저에서 index 페이지 접속
- searchbar 레이아웃에 렌더링 시간이 출력됨
✅ search 페이지 이동
- 검색어를 입력하고 search 페이지로 이동
- searchbar의 렌더링 시간이 변하지 않음
이유
searchbar 레이아웃은 클라이언트 라우터 캐시에 저장되어 있기 때문이다.
즉, 서버에서 다시 받아오지 않고 브라우저 캐시 데이터를 재활용한다.
✅ 새로고침
search 페이지에서 새로고침을 하면 searchbar의 렌더링 시간이 변경된다.
이유
- 새로고침 시 브라우저 메모리 기반 캐시가 초기화됨
- 서버로부터 RSC Payload를 다시 요청
5️⃣ 클라이언트 라우터 캐시의 한계
1️⃣ 새로고침 시 캐시 초기화
- 브라우저 새로고침
- 탭을 닫았다가 다시 열기
이 경우 캐시는 모두 초기화된다.
즉, 새로고침 이후에는 캐싱 효과가 없다.
2️⃣ 탭 간 캐시 공유 불가
같은 브라우저라 하더라도,
- 다른 탭에서는 캐시가 공유되지 않는다.
- 각 탭은 독립적인 메모리 공간을 사용한다.
3️⃣ 서버 컴포넌트만 캐싱
클라이언트 라우터 캐시는 서버 컴포넌트 데이터(RSC Payload)만 저장한다.
- 클라이언트 컴포넌트의 내부 상태
- 브라우저 상태 기반 데이터
이러한 정보는 캐싱 대상이 아니다.
6️⃣ 정확한 작동 방식
1️⃣ 페이지의 전체 RSC Payload 캐싱
클라이언트 라우터 캐시는 단순히 레이아웃만 저장하는 것이 아니다.
각 페이지에서 서버로부터 전달받은 RSC Payload 전체를 저장한다.
이 데이터에는 다음이 포함된다.
- 공통 레이아웃
- 해당 페이지를 구성하는 서버 컴포넌트 데이터
- 공유 컴포넌트 데이터
2️⃣ 페이지 이동 시 데이터 활용 방식
공통 데이터
- 캐시에 저장된 데이터를 그대로 사용
- 예: 루트 레이아웃, 서치바 등
새로운 데이터
- 캐시에 없는 데이터만 서버에 요청
- 변경된 서버 컴포넌트 데이터만 수신
3️⃣ 캐싱의 주요 목표
- 서버 요청 최소화
- 네트워크 부하 감소
- 중복 데이터 제거
- 사용자 경험 개선
- 빠른 페이지 전환
7️⃣ 요약 및 결론
클라이언트 라우터 캐시는 브라우저 측에서 서버 컴포넌트 데이터를 저장함으로써 서버 요청을 줄이고 페이지 이동 속도를 최적화하는 기술이다.
핵심 포인트
- 공통 레이아웃 데이터 재활용
- RSC Payload 전체를 저장
- Next.js에 기본 내장 (추가 설정 필요 없음)
- 새로고침 및 탭 간 공유는 불가
결론적으로,
클라이언트 라우터 캐시는 공통 레이아웃 데이터뿐만 아니라 특정 페이지에 필요한 서버 컴포넌트 데이터(RSC Payload) 전체를 저장한다.
페이지 이동 시:
- 중복되지 않은 데이터는 추가 요청
- 이미 캐시에 저장된 데이터는 재활용
이를 통해 성능을 최적화한다.
특히 공통 레이아웃 데이터가 페이지 이동 간 반복적으로 사용되는 구조에서는, 클라이언트 라우터 캐시의 이점이 더욱 두드러진다.
