캐시 용어를 외웠는지가 아니라, 현재 프로젝트의 캐싱 모델을 식별하고 계층별 책임(캐시 선언·수명·무효화·요청 시점)을 나눠 설명할 수 있는지 가르려는 질문이다.
Next.js 최신(16+) 기준에서는 Cache Components를 켠 뒤 use cache로 함수·컴포넌트 단위 캐시를 선언하는 모델이 기본 축이다. 캐시 수명은 cacheLife로, 무효화는 cacheTag와 revalidate 계열 API로 끊고, 요청 시점에만 알 수 있는 데이터(cookies·headers·searchParams)는 Suspense 경계 안에서 동적 영역으로 처리한다. 그래서 작업 순서가 'fetch 옵션부터 조정'이 아니라, '정적 셸에 무엇을 묶고 어디서부터를 요청 시점 스트리밍으로 풀지'를 먼저 잡는 흐름이 된다. Cache Components를 쓰지 않는 프로젝트는 이전 모델(fetch cache·revalidate, unstable_cache, route segment config)로 그대로 동작하므로, 이 질문을 만났을 때 가장 먼저 확인할 것은 우리 코드가 어느 모델 위에 있는지다.
캐시 정책을 바꿔 LCP·서버 부하가 어떻게 움직였는지 측정해 본 경험이 있다면 모델 변경 효과 사례로 연결할 수 있다
stale 이슈를 cacheLife·cacheTag 무효화로 풀어 본 적이 있다면 신선도 정책 설계 관점으로 말할 수 있다
팀 문서에 '현재 캐싱 모델'과 어떤 화면이 정적·동적인지 명시해 본 경험이 있다면 협업 혼선을 줄인 사례로 엮을 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.