Chrome 디스크 캐시 정리 방법 — 강력 새로고침으로 안 될 때

 

배포 후 강력 새로고침(Ctrl+Shift+R)을 해도 이전 버전이 보인다면, 디스크 캐시가 원인일 수 있다.
특히 JavaScript의 fetch()로 가져오는 데이터는 강력 새로고침으로 캐시가 우회되지 않는다.

---

왜 강력 새로고침으로 안 되는가

강력 새로고침은 브라우저가 직접 로드하는 리소스만 캐시를 우회한다.

요청 유형	강력 새로고침 시
HTML 문서	O — 서버에서 새로 받음
<script>, <link>, <img> 등	O — 서버에서 새로 받음
JavaScript 코드 내 fetch()	X — 디스크 캐시 그대로 사용
JavaScript 코드 내 dynamic import()	X — 디스크 캐시 그대로 사용

React, Next.js, Vue 같은 SPA/SSR 프레임워크는 페이지 로드 후 JS에서 fetch()로 데이터를 가져오는 구조가 많다. 이 요청들은 강력 새로고침과 무관하게 디스크 캐시에 남은 이전 응답을 그대로 사용할 수 있다.

---

방법 1. Clear site data (가장 추천)

해당 사이트의 캐시만 선택적으로 정리하는 방법이다. 다른 사이트에는 영향이 없다.

 

f12(개발자도구) - Application - Storage - clear site data 누르면 디스크 캐시가 무효화된다.

1. F12를 눌러 개발자 도구 열기
2. 좌측 탭에서 Application 클릭
3. 좌측 사이드바에서 Storage 클릭
4. 삭제할 항목에 체크:
   • Cache storage — Service Worker 캐시
   • Application cache
   • Cookies
   • IndexedDB
   • Local storage
   • Session storage
5. 하단의 "Clear site data" 버튼 클릭

일일이 localStorage, Cookies 등을 각각 들어가서 지울 필요 없다. Storage 메뉴에서 체크 후 한 번에 정리할 수 있다.

---

방법 2. Disable cache + 새로고침 (개발 중 유용)

개발자 도구가 열려 있는 동안 모든 캐시를 비활성화하는 방법이다.

1. F12를 눌러 개발자 도구 열기
2. Network 탭 클릭
3. 상단의 "Disable cache" 체크박스에 체크
4. 페이지 새로고침 (F5 또는 Ctrl+R)

이 상태에서는 fetch() 요청도 디스크 캐시를 우회한다.

주의: 개발자 도구를 닫으면 다시 캐시가 활성화된다. 영구적인 해결이 아닌 개발/디버깅 중 임시 사용 목적이다.

---

방법 3. 인터넷 사용 기록 삭제 (가장 확실하지만 광범위)

모든 사이트의 캐시를 한꺼번에 삭제하는 방법이다.

1. Ctrl+Shift+Delete 또는 설정 → 개인정보 및 보안 → 인터넷 사용 기록 삭제
2. 기간: "전체 기간" 선택
3. "캐시된 이미지 및 파일" 체크
4. "데이터 삭제" 클릭

모든 사이트의 디스크 캐시가 삭제된다. 다른 사이트에서 로그인이 풀리거나 저장된 설정이 초기화될 수 있으므로, 가능하면 방법 1(Clear site data)을 사용하는 것이 좋다.

---

방법 4. 주소창에서 특정 사이트 캐시 삭제

개발자 도구 없이 간단하게 처리하는 방법이다.

1. 주소창 왼쪽의 자물쇠 아이콘 (또는 사이트 정보 아이콘) 클릭
2. "사이트 설정" 클릭
3. "데이터 삭제" 클릭

해당 사이트의 캐시, 쿠키, 저장소가 모두 삭제된다.

---

방법 비교

 

방법	범위	fetch() 캐시 해결	로그인 유지 (타 사이트)	사용 시점
Clear site data (Application 탭)	해당 사이트만	O	O	특정 사이트 문제 해결
Disable cache (Network 탭)	현재 탭 (DevTools 열린 동안)	O	O	개발/디버깅 중
인터넷 기록 삭제 (Ctrl+Shift+Del)	모든 사이트	O	X (쿠키 포함 시)	전체 초기화 필요 시
사이트 설정 → 데이터 삭제	해당 사이트만	O	O	DevTools 없이 간단 처리

---

개발자를 위한 근본적 해결

사용자에게 캐시를 지우라고 안내하는 것보다, 코드나 서버 설정으로 해결하는 것이 좋다.

fetch()에 cache 옵션 지정

// 디스크 캐시 무시, 항상 서버에서 가져옴
fetch('/api/data', { cache: 'no-store' })

// 디스크 캐시에 있어도 서버에 재검증 (304 가능)
fetch('/api/data', { cache: 'no-cache' })

 

cache 옵션	동작
default	브라우저 기본 정책 (Cache-Control 헤더 따름)
no-store	캐시 완전 무시, 항상 서버에서 요청
no-cache	캐시 있어도 서버에 재검증 (변경 없으면 304)
reload	캐시 무시하고 서버 요청, 응답은 캐시에 저장
force-cache	만료되었어도 캐시 사용

서버 응답 헤더로 제어

 

Cache-Control 값	효과
no-store	fetch() 응답이 디스크에 저장되지 않음
no-cache	저장은 되지만 사용 전 매번 서버에 재검증
max-age=0, must-revalidate	즉시 만료, 재검증 필수

no-cache와 no-store의 차이:

• no-cache — "저장해도 되지만, 쓰기 전에 서버한테 물어봐" → 변경 없으면 304 (빠름)
• no-store — "아예 저장하지 마" → 매번 전체 응답을 받아야 함 (확실하지만 느림)

Next.js Middleware에서 RSC 캐시 제어

Next.js App Router를 사용하는 경우, RSC(React Server Component) payload가 fetch()로 전달되기 때문에 디스크 캐시 문제가 발생할 수 있다. Middleware에서 RSC 요청에 대해 캐시를 제어할 수 있다.

// middleware.ts
import { NextResponse } from 'next/server'

export function middleware(request) {
  const response = NextResponse.next()
  // RSC 요청에 대해서만 캐시 재검증 강제
  if (request.headers.get('rsc') === '1') {
    response.headers.set('Cache-Control', 'no-cache, must-revalidate')
  }
  return response
}

---

마무리

"강력 새로고침 했는데 안 돼요"라는 상황의 대부분은 JS fetch()의 디스크 캐시 때문이다.

• 즉시 해결 — 개발자 도구 Application 탭 → Storage → Clear site data
• 개발 중 — Network 탭 → Disable cache 체크
• 근본 해결 — 서버 응답에 적절한 Cache-Control 헤더 설정

사용자에게 "캐시 비워봐"라고 안내하기 전에, 서버 측에서 캐시 정책을 올바르게 설정하는 것이 최선이다.