우아한테크코스 레벨 4 팀 프로젝트 festabook에서 학습한 내용을 정리한 글입니다.
✅ 브라우저 캐싱 동작 원리
- 사용자가 웹사이트에 처음 접속하면, 브라우저는 HTML, CSS, JS, 이미지 등 모든 리소스를 서버로부터 내려받는다.
- 이때 서버는 응답 헤더에 캐시 관련 지시어(Cache-Control, ETag 등)를 함께 포함시킨다.
- 브라우저는 전달받은 리소스를 로컬 캐시 저장소(메모리 또는 디스크)에 저장한다.
- 이후 동일한 리소스가 다시 요청되면 브라우저는 다음 규칙에 따라 처리한다.
- 유효 기간이 남아 있을 경우: 서버에 요청하지 않고, 로컬 캐시를 바로 사용한다.
- 만료되었거나 변경이 의심될 경우: 서버에 검증 요청을 보내고, 변경된 경우에만 새로 다운로드한다.
✅ HTTP 캐싱 헤더
▶ Cache-Control
서버가 리소스를 어떻게 캐시하고 관리할지 클라이언트(또는 중간 프록시)에게 지시하는 헤더다.
- max-age=3600: 리소스를 3600초(1시간) 동안 유효하다고 간주
- no-cache: 캐시된 리소스를 사용하기 전에 반드시 서버에 변경 여부를 확인 (검증 요청 후 304 Not Modified 응답 시 재사용)
- no-store: 캐시를 전혀 저장하지 않음
- public: 모든 사용자 및 공유 캐시(CDN, 프록시 등)에 저장 가능
- private: 개인 브라우저 캐시에만 저장
- must-revalidate: 캐시가 만료된 이후에는 반드시 서버 검증을 거쳐야 하며, 네트워크가 단절된 경우 만료된 캐시를 사용할 수 없음
▶ ETag, If-None-Match
리소스의 버전(변경 여부)을 비교하기 위한 헤더다.
- ETag: 서버가 리소스의 고유한 버전 식별자로 내려주는 값
- If-None-Match: 브라우저가 이전에 받은 ETag를 서버로 전달하여 “이 버전이 아직 유효한가?”를 확인
🔽 동작 흐름
- 서버가 리소스를 응답할 때 ETag를 함께 전송한다.
- ETag: “44ec4bd971cc4a71…”
- 브라우저가 같은 리소스를 다시 요청할 때, 이전에 받은 ETag 값을 요청 헤더에 포함한다.
- If-None-Match: “44ec4bd971cc4a71…”
- 서버는 ETag 값을 비교해 변경 여부를 판단한다.
- 같다면: 304 Not Modified로 응답하고, 브라우저는 기존 캐시를 그대로 재사용한다.
- 다르면: 200 OK와 함께 새로운 리소스 및 새로운 ETag 값을 내려보낸다.
▶ Last-Modified, If-Modified-Since
리소스의 마지막 수정 시각을 기준으로 변경 여부를 판단하는 HTTP 헤더다.
- Last-Modified: 서버가 리소스의 마지막 수정 시각
- If-Modified-Since: 브라우저가 이전에 받은 수정 시각을 서버로 보내 “그 이후로 변경된 것이 있는가?”를 확인
🔽 동작 흐름
- 서버가 리소스를 응답할 때 마지막 수정 시각을 함께 전송한다.
- Last-Modified: Wed, 13 Oct 2025 09:00:00 GMT
- 브라우저가 같은 리소스를 다시 요청할 때, 이전에 받은 시간을 요청 헤더에 포함한다.
- If-Modified-Since: Wed, 13 Oct 2025 09:00:00 GMT
- 서버는 해당 시각 이후 리소스가 수정되었는지 비교한다.
- 수정되지 않았다면: 304 Not Modified로 응답하고, 브라우저는 기존 캐시를 그대로 재사용한다.
- 수정되었다면: 200 OK와 함께 새로운 리소스 및 최신 Last-Modified 값을 내려보낸다.
▶ Expires
HTTP/1.0 시절의 캐시 만료일 설정 방식으로, 절대 시간을 명시한다. Cache-Control의 max-age와 Expires가 함께 사용될 때는 Expires 설정값이 무시된다.
✅ 캐싱 전략
캐싱은 동작 방식에 따라 크게 두 가지 전략으로 구분된다.
| 전략 | 설명 | 대표 헤더 |
| Strong Caching (강력 캐싱) | 만료 시간 전까지 서버와 통신하지 않음 | Cache-Control: max-age, Expires |
| Conditional Caching (조건부 캐싱) | 만료 후 서버에 변경 여부 확인 | ETag, Last-Modified |
Strong Caching은 성능 최적화, Conditional Caching은 정확한 최신성 보장에 초점을 둔다.
✅ 캐시 무효화
리소스가 변경되었는데 이전 버전의 캐시가 남아 있으면, 사용자는 최신 데이터를 받지 못할 수 있다. 이러한 문제를 방지하기 위한 대표적인 캐시 무효화 방법은 다음과 같다.
- Cache-Control + ETag 활용
- Cache-Control의 no-cache나 짧은 max-age를 설정하여 브라우저가 주기적으로 서버에 검증 요청을 보내도록 한다.
- 서버는 ETag를 통해 리소스의 변경 여부를 판단한다.
- 변경이 없으면: 304 Not Modified로 응답하여 캐시를 재사용
- 변경되었으면 200 OK로 새 리소스를 내려보낸다.
- 파일명 버전 관리
- 리소스 파일명에 버전 정보나 빌드 날짜를 포함해 새로운 버전 배포 시 URL이 달라지도록 한다.
- ex) style.v2.css, script.20251013.js
- URL이 변경되면 브라우저는 기존 캐시를 사용하지 않고 새 리소스를 다시 다운로드한다.
- 리소스 파일명에 버전 정보나 빌드 날짜를 포함해 새로운 버전 배포 시 URL이 달라지도록 한다.
✅ 의문 점
▶ 강력 새로고침은 어떻게 동작할까?
강력 새로고침은 캐시된 리소스를 완전히 무시하고, 모든 파일을 서버에서 다시 다운로드한다. 단, 캐시를 삭제하지는 않는다.
▶ 캐시는 실제로 어디에 저장될까?
브라우저는 다운로드한 리소스를 로컬 저장소(디스크 또는 메모리)에 저장한다. 예를 들어 Chrome 기준 macOS에서는 다음 경로에 저장된다.
~/Library/Caches/Google/Chrome/Default/Cache/Cache_Data

이곳에는 HTML, CSS, JS, 이미지 등의 리소스가 브라우저 내부 규칙에 따라 해시된 파일명으로 저장된다.
▶ Cache-Control의 기본 동작은 무엇일까?
HTTP에서 Cache-Control 헤더를 명시하지 않으면, public이 기본값이라고 오해하기 쉽지만 실제로는 명시적인 기본값이 없다.
다만 브라우저는 다음과 같은 암묵적 규칙을 따른다.
| 리소스 유형 | 기본 캐시 동작 (헤더 없을 때) |
| 정적 리소스 (CSS, JS, 이미지 등) | 브라우저가 자체적으로 일정 시간 캐싱할 수 있음 |
| 동적 리소스 (HTML 등, Set-Cookie 포함) | 대부분 캐시하지 않음 (no-store처럼 동작) |
즉, Cache-Control을 서버가 내려주지 않으면 브라우저와 프록시가 보수적으로 판단하여 캐시 여부를 결정한다. 그래서 실무에서는 항상 서버가 명시적으로 Cache-Control을 지정해야 한다.
▶ ETag와 Last-Modified는 같은 역할을 하지 않나?
- ETag는 파일의 버전 또는 해시값을 기준으로 비교한다.
- 파일 내용이 한 바이트라도 바뀌면 다른 값으로 인식된다.
- Last-Modified는 파일의 마지막 수정 시각을 기준으로 비교한다.
- 초 단위까지만 비교하므로, 짧은 시간 내 여러 번 수정된 경우엔 변화를 감지하지 못할 수 있다.
즉, ETag는 더 정밀한 변경 감지 방식이다. 실무에서는 일반적으로 Last-Modified보다 ETag가 우선적으로 사용된다.
▶ no-cache는 비효율적인가?
Cache-Control: no-cache로 설정하면 브라우저는 캐시된 리소스를 사용하기 전에 항상 서버에 검증 요청을 보낸다. 처음에는 매번 서버와 통신하기 때문에 비효율적이라고 생각했다.
하지만, 이 방식은 항상 최신 상태를 보장하면서도, 리소스가 변경되지 않은 경우에는 서버가 304 Not Modified로 응답해 데이터 전체를 재다운로드하지 않는다. 따라서 네트워크 낭비가 크지 않으며, 안정성과 효율성을 모두 확보할 수 있는 캐싱 방식이다.
📍 참고 자료
- 우아한테크코스 레벨 4 자료
'CS > Network' 카테고리의 다른 글
| [Network] Namespace란 무엇일까 (1) | 2026.01.19 |
|---|---|
| [Network] Web Server, WAS, SSR, CSR (0) | 2025.11.16 |
| [Network] XSS, CSRF (1) | 2024.08.27 |
| [Network] 멀티플렉싱, 디멀티플렉싱 (0) | 2024.08.26 |
| [Network] 서브넷 마스크, 게이트웨이 (1) | 2024.08.26 |