3.3 KiB
3.3 KiB
category, tags, title, description, last_updated
| category | tags | title | description | last_updated | |||
|---|---|---|---|---|---|---|---|
| Architecture |
|
Next.js Caching Architecture | Next. | 2026-05-04 |
Next.js Caching Architecture
📌 Brief Summary
Next.js의 캐싱 아키텍처는 React 서버 컴포넌트(RSC) 및 서버 액션(Server Actions)과 긴밀하게 연동되어 애플리케이션의 데이터를 서버에 저장하고 무효화(Invalidate)하는 메커니즘입니다 [1, 2]. 개발자는 다양한 데이터를 서로 다른 태그(Tag)로 캐시하고, 데이터가 업데이트될 때 해당 태그를 무효화하는 방식으로 동작을 제어할 수 있습니다 [3]. 이를 통해 무거운 데이터의 잦은 재요청을 방지하고 빠른 렌더링 성능을 확보하는 것이 핵심 목적입니다 [3, 4].
📖 Core Content
- 태그 기반 캐시 무효화 (Cache Invalidation with Tags): Next.js에서는 데이터를 가져올 때 개별 데이터에 고유한 태그를 할당하여 캐시할 수 있습니다 [3]. 데이터의 변경이나 업데이트가 발생하면 서버 액션 내에서
revalidateTag함수를 호출하여, 특정 태그와 연결된 캐시 데이터를 방출(eject)하도록 지시할 수 있습니다 [2, 5]. - RSC 트리 전체 리렌더링:
revalidateTagAPI는 Next.js에게 '무엇을 다시 로드할지'를 알려주는 것이 아니라, 단지 '캐시에서 무엇을 제거할지'만을 알려줍니다 [5]. 그 결과, 이 함수가 호출되면 Next.js는 현재 페이지의 모든 것을 다시 로드해야 하므로 전체 RSC 트리가 리렌더링됩니다 [3, 5]. - 캐시 적중을 통한 성능 방어: 전체 컴포넌트 트리가 리렌더링되는 구조적 특성에도 불구하고, 서버에 데이터가 올바르게 캐시되어 있다면 캐시된 데이터에 대한 후속 요청들은 매우 빠르게 실행되어 성능 저하를 방지할 수 있습니다 [3].
⚖️ Trade-offs & Caveats
- 과도한 데이터 재요청 위험성:
revalidateTag를 호출하여 캐시를 무효화하면 전체 컴포넌트 트리가 리렌더링되면서 연관된 모든 데이터의 재요청이 발생합니다 [4, 5]. 만약 서버에 모든 데이터가 적절히 캐시되어 있지 않다면, 오히려react-query와 같은 클라이언트 측 상태 관리 도구가 필요로 하는 두 번의 왕복 시간(Round trip)보다 단일 서버 왕복 시간이 더 오래 걸리는 심각한 성능 저하를 초래할 수 있습니다 [4]. - 서버 액션의 직렬 실행 병목: 데이터 업데이트와 캐시 무효화에 사용되는 서버 액션은 한 번에 하나만 실행될 수 있는 직렬(Serial) 실행 제약을 가집니다 [6]. 네트워크가 느리거나 지연이 발생할 경우 작업들이 대기열(Queue)에 쌓이게 되어 사용자 경험을 크게 훼손할 수 있습니다 [6].
- 캐싱 API의 잦은 변경과 변동성: 소스 자료 작성 시점 기준으로 Next.js는 완전히 다른 캐싱 API와 기본값을 포함한 새로운 버전을 출시하는 중이었습니다 [1]. 이는 캐싱 아키텍처의 세부 동작 방식이나 최적화 전략이 버전에 따라 급격히 달라질 수 있는 기술적 불안정성을 내포하고 있음을 의미합니다 [1].
Last updated: 2026-05-03