프론트엔드 개발을 하다보면, 정말 많이 마주하고 사용하는게 캐시다. 그 쓰임새도, 공유되는 환경도 다양하다.

캐시에 대해서 한번 정리하자는 마음으로, 웹 캐싱을 공부하고 있다. 그 중 가장 많이 사용되는 브라우저 캐시에 대해서 정리해보려 한다.

들어가기 전: 🌐 웹 캐싱 구조

웹 캐시는 차례대로 서비스 워커 캐시 → 브라우저 캐시 → CDN(or 프록시 서버 캐시) 순으로 참조되며, 모든 캐시에 유효한 응답(데이터)이 없을 경우에는 서버에 요청을 보내서 응답을 받게 된다.

브라우저 캐시?

브라우저 캐시는 웹 리소스(HTML, CSS, JS, 이미지 등)를 브라우저가 로컬에 저장해두고, 다음 요청 시 네트워크를 거치지 않고 빠르게 응답할 수 있도록 하는 메커니즘이다.

브라우저 캐시 저장 공간과 공유 환경

📦 브라우저 캐시는 어디에 저장될까?

저장 위치는 브라우저의 내부 정책, 리소스 크기, 만료 기간 등에 따라 캐시는 메모리, 디스크에 저장된다.

저장 위치	특징	예시 리소스
메모리 캐시	빠르고 휘발성 (탭 닫히면 사라짐), 탭 내부 전용	JSON 응답, 작은 리소스
디스크 캐시	브라우저 전체에서 공유, 브라우저 종료 후에도 유지	JS, CSS, 이미지 등

DevTools를 열어보면, 브라우저 캐시가 어디에 저장되어있는 지 확인할 수 있다.

크롬의 경우, 사용자 계정 별로 디스크에 캐시를 저장하고 있다.
크롬 캐시 폴더에 하위에 Default, Profile1 폴더가 있는 것을 확인할 수 있다. 바로 크롬에 로그인한 계정별 디스크 캐시를 담고 있는 폴더이다.

👨‍👩‍👧‍👦 캐시 공유 조건

캐시가 유효 기간과 저장 장소를 생각해보면, 공유되는 환경인지 판단하기 쉽다.

메모리 캐시

• 특징: 탭이 활성화되는 기간 동안 유지
• 공유: 동일한 탭내에서만 사용

디스크 캐시

• 특징: 브라우저 종료 후에도 유지,사용자 로컬에 계정별 폴더에서 저장(크롬 기준)
• 공유: 동일 기기의 동일 브라우저, 동일한 사용자 계정 간 캐시 공유

브라우저 캐시의 동작 원리

브라우저 캐시의 저장 여부와 유효 기간은 서버가, 사용 여부는 클라이언트가 결정한다.

캐시 관련 옵션

서버 응답 헤더

역할	주요 헤더
저장 여부	Cache-Control: no-store, private, public. ….
유효 기간	max-age, Expires
변경 확인	ETag, Last-Modified

🤔 max-age와 Expires의 차이?

• Cache-Control:max-age: 현재를 기준으로 유효한 기간, 캐시 유효 시간을 초 단위로 지정
• Expires: 특정 만료 날짜와 시간을 지정하며, 클라이언트와 서버 시간 차이 문제가 있을 수 있다.
• 우선 순위: max-age가 Expires보다 우선 적용

⚠️ Last-Modified 한계

• 1초보다 짧은 수정 시간을 감지하지 못한다.
• 서버 시간을 기준으로 해서, 클라이언트와 시간 차이로 인해 검증이 제대로 이루어지지 않는 오류가 발생할 수 있다.
• 서버가 동적으로 리소스를 만드는 경우, 파일안의 내용은 변경되지만 파일 자체를 변경되지 않아서 수정 사항을 반영하지 못하는 오류가 발생할 수 있다.

클라이언트 캐시 옵션

fetch(url, { cache: 'no-cache' });

옵션	의미	서버 요청 여부	캐시 저장 여부
no-store	저장도 사용도 금지	✅ 항상 요청	❌ 저장하지 않음
no-cache	사용 전 재검증	✅ 조건부 요청	✅ 서버가 허용하면 저장
must-revalidate	만료되면 반드시 재검증	✅ 네트워크 없으면 실패 가능	✅ 서버가 허용하면 저장
reload	무조건 새 요청	✅ 항상 요청	✅ 서버가 허용하면 저장
force-cache	캐시 무조건 사용	❌	⛔ 새로 저장하지 않음 (기존 캐시만 사용)
only-if-cached	캐시 없으면 실패	❌	⛔ 새로 저장하지 않음 (기존 캐시만 사용)

🤔 캐시 유효 기간이 만료되었지만, 클라이언트에서 force-cache, only-if-cached요청을 하고 있다면?

브라우저는 서버의 캐시 정책을 따르지만, 클라이언트 설정이 우선 적용된다.

force-cache옵션을 사용했다면, 만료된 캐시라도 이를 강제로 사용한다.

only-if-cached옵션은 캐시가 있다면 사용하는 것으로, 만료된 캐시를 사용할 수 없고 서버에 재요청을 하지 않기 때문에 net::ERR_CACHE_MISS 오류가 난다.

캐시 정책 판단 순서

클라이언트가 캐시 사용을 요청한다면 어떤 프로세스를 거치게 될까?

1️⃣ 브라우저가 캐시 저장소(메모리, 디스크)에서 해당 리소스를 조회

• 존재하지 않음 → 서버에 새 요청, 응답을 캐시에 저장 (서버가 허용 시)
• 존재함 → 다음 단계 진행
  

2️⃣ 서버의 응답 헤더 기반으로 유효성 판단 (Cache-Control, Expires)

• 아직 만료되지 않음 → 서버 요청 없이 즉시 캐시 사용 (완전 캐시)
• 만료됨 → 다음 단계 진행 (재검증 가능 여부 확인)
  

3️⃣ 서버가 재검증 정보를 제공하는가? (ETag, Last-Modified)

• 제공함 → 브라우저는 조건부 요청 전송 (If-None-Match, If-Modified-Since)
• 제공하지 않음 → 서버에 새 요청 진행
  

4️⃣ 재검증 진행, 서버 응답 결과 확인

• 304 Not Modified → 기존 캐시 재사용
• 200 OK → 새 리소스로 캐시 갱신 (서버가 저장 허용 시)
  

5️⃣ 재검증 진행하지 않는 경우

• 캐시가 만료되었고 재검증도 불가능한 경우 → 서버로부터 새 리소스를 받아 캐시에 저장 (서버가 허용 시)

🙋 재검증 단계 관련 질문

💭 If-None-Match, If-Modified-Since 의 비교값은 어떻게 설정하는거지?

If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT
If-None-Match: W/"67ab43", "54ed21", "7892dd"

변경 여부를 판단하기 위해, If-None-Match, If-Modified-Since에는 이전 리소스의 값이 들어가야한다.

리소스가 캐시될 때, 서버 응답 헤더에 있던 ETag, Last-Modified가 값이 저장된다.

재검증 단계에서 브라우저는 ETag 또는 Last-Modified가 있다면 캐싱된 리소스를 활용해 자동으로 If-None-Match 또는 If-Modified-Since를 클라이언트의 요청 헤더에 추가한다.

💭 no-cache, must-revalidate 모두 리소스를 재검증하는데 무슨 차이인거지?

no-cache는 '캐시된 리소스를 사용할 수 있지만, 사용 전에 서버에서 리소스를 재검증 받아야 해!'라는 옵션이다. 만약 중간에 네트워크가 끊긴다면, 서버에 재검증을 받지 못했지만 브라우저가 자체적으로 판단해 캐싱된 리소스를 재사용할 수 있다. 이를 '느슨한 정책'이라한다.

반면, must-revalidate는 재검증을 무조건 강제하는 것으로 네트워크가 끊기면, 캐싱된 리소스를 사용할 수 없다.

그래서 리소스 재검증을 엄격하게 적용하고 싶을 때 두 옵션을 같이 사용하곤 한다.

최신 리소스를 위한 캐시 관리 전략

🧐 사용자에게 최신 리소스를 안정적으로 전달하려면 어떻게 해야 할까?
브라우저 캐시의 장점은 성능이지만, 때로는 이 캐시 때문에 변경된 파일이 반영되지 않는 문제가 생기기도 한다.
이를 해결하기 위한 대표적인 방법이 바로 캐시 무효화와 캐시 버스팅이다.

♻️ 캐시 무효화

캐시 무효화란, 더 이상 유효하지 않은 캐시를 사용하지 않도록 만드는 것이다.

방식	제어 위치	예시
서버	응답 헤더	no-store, must-revalidate, ETag, max-age
클라이언트	요청 옵션	no-cache, reload, 새로고침 등

🚀 캐시 버스팅

변경된 파일을 다른 이름으로 저장/요청하여 캐시를 무시하고 새로 받도록 하는 전략이다. 이는 정적 자원을 최신화할 때 사용한다.

그 방법으로는 해시 기반 파일명을 사용하거나, 쿼리 스트링 방식으로 리소스를 요청한다. 단, 쿼리 스트링방식은 쿼리 스트링이 무시되는 서버 설정으로 인해 오래된 캐시를 사용할 수 있어서 주의가 필요하다.

쿼리 스트링이 무시되는 경우

서버가 쿼리 스트링을 무시하는 정책을 사용할 수 있고, 쿼리 스트링이 있는 정적 리소스 URL 요청을 무조건 원본 파일로 연결하도록 설정되어 있을 수도 있다.

만료된 캐시 관리

stale 상태

캐시가 만료되면 바로 삭제되지 않고, "stale(만료됨)" 상태로 유지된다.
즉시 삭제되지 않는 이유는 성능 최적화와 유연한 재사용 가능성 때문이다.

즉시 삭제되지 않는 이유

♻️ 재검증 후 재사용될 수 있다!

캐시 재검증 단계에서 서버가 304 Not Modified응답을 주면, 클라이언트는 만료되었더라도 기존 캐시를 재사용할 수 있게 된다.
만약 만료 기간이 지났다고 즉시 삭제하게 된다면, 재검증 요청조차 못하고 무조건 새로 리소스를 받아야해 불필요한 네트워크 비용이 들 수 있다.

💸 삭제도 비용이다!

디스크는 CPU/RAM보다 훨씬 느리고 복잡한 외부 장치이기 때문에, 캐시를 쓰고 삭제하는 작업에 시간과 자원이 많이 든다.

위의 이유로 만료된 캐시를 즉시 삭제하지 않고, 특정 조건이 만족하면 LRU(Least Recently Used) 정책 등으로 우선순위 낮은 캐시부터 제거한다.

🧹 캐시 삭제

캐시 삭제 조건

다음 중 하나의 조건이 만족하면, 우선순위에 따라 캐시를 삭제한다.

• 디스크 용량이 부족
• 오래 사용되지 않았음
• 사용자가 브라우저 설정에서 삭제

캐시 삭제 우선 순위

우선순위	설명
1️⃣ 가장 오래 사용하지 않은 캐시 (LRU)	Least Recently Used – 접근 안 된 순서 기준으로 삭제
2️⃣ 만료된 캐시	유효 기간(max-age, Expires)이 지난 캐시
3️⃣ 크기가 큰 리소스	큰 파일은 공간 확보를 위해 먼저 제거될 수 있음
4️⃣ 낮은 신뢰도/우선순위 사이트의 캐시	자주 방문하지 않는 사이트, 로컬 리소스 등

LRU 정책에 따라 캐시가 만료되지 않았는데, 오래 사용되지 않았으면 삭제될 수 있다.

마무리

브라우저 캐시가 어디에 저장되고, 어떻게 동작하는 지를 정리해봤다.
개발을 공부하면서 모든 기술을 다 알기보다는, 왜 그렇게 동작하는지를 이해하는 것이 더 중요하다는 것을 느끼고 있다.
기술은 계속 변하고, AI 시대에는 정보의 양보다 동작 원리와 개념을 이해하는 힘이 더 오래가는 것 같다.

이 글이 브라우저 캐시에 대한 완벽한 정답은 아니더라도,
다양한 상황에서 캐시가 어떻게 적용되고 동작하는지 판단할 수 있는 도움이 되었으면 좋겠다. 🙏

---

참고 자료

• 서비스 워커 캐싱 및 HTTP 캐싱
• 웹 브라우저의 Cache 전략 & 헤더 다루기