[Network] HTTP 캐싱(Caching)

우아한테크코스 레벨 4 팀 프로젝트 festabook에서 학습한 내용을 정리한 글입니다.

 

✅ 브라우저 캐싱 동작 원리

1. 사용자가 웹사이트에 처음 접속하면, 브라우저는 HTML, CSS, JS, 이미지 등 모든 리소스를 서버로부터 내려받는다.
2. 이때 서버는 응답 헤더에 캐시 관련 지시어(Cache-Control, ETag 등)를 함께 포함시킨다.
3. 브라우저는 전달받은 리소스를 로컬 캐시 저장소(메모리 또는 디스크)에 저장한다.
4. 이후 동일한 리소스가 다시 요청되면 브라우저는 다음 규칙에 따라 처리한다.
   • 유효 기간이 남아 있을 경우: 서버에 요청하지 않고, 로컬 캐시를 바로 사용한다.
   • 만료되었거나 변경이 의심될 경우: 서버에 검증 요청을 보내고, 변경된 경우에만 새로 다운로드한다.

 

 

✅ 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를 서버로 전달하여 “이 버전이 아직 유효한가?”를 확인

🔽 동작 흐름

1. 서버가 리소스를 응답할 때 ETag를 함께 전송한다.
   • ETag: “44ec4bd971cc4a71…”
2. 브라우저가 같은 리소스를 다시 요청할 때, 이전에 받은 ETag 값을 요청 헤더에 포함한다.
   • If-None-Match: “44ec4bd971cc4a71…”
3. 서버는 ETag 값을 비교해 변경 여부를 판단한다.
   • 같다면: 304 Not Modified로 응답하고, 브라우저는 기존 캐시를 그대로 재사용한다.
   • 다르면: 200 OK와 함께 새로운 리소스 및 새로운 ETag 값을 내려보낸다.

 

▶ Last-Modified, If-Modified-Since

리소스의 마지막 수정 시각을 기준으로 변경 여부를 판단하는 HTTP 헤더다.

• Last-Modified: 서버가 리소스의 마지막 수정 시각
• If-Modified-Since: 브라우저가 이전에 받은 수정 시각을 서버로 보내 “그 이후로 변경된 것이 있는가?”를 확인

🔽 동작 흐름

1. 서버가 리소스를 응답할 때 마지막 수정 시각을 함께 전송한다.
   • Last-Modified: Wed, 13 Oct 2025 09:00:00 GMT
2. 브라우저가 같은 리소스를 다시 요청할 때, 이전에 받은 시간을 요청 헤더에 포함한다.
   • If-Modified-Since: Wed, 13 Oct 2025 09:00:00 GMT
3. 서버는 해당 시각 이후 리소스가 수정되었는지 비교한다.
   • 수정되지 않았다면: 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은 정확한 최신성 보장에 초점을 둔다.

 

 

✅ 캐시 무효화

리소스가 변경되었는데 이전 버전의 캐시가 남아 있으면, 사용자는 최신 데이터를 받지 못할 수 있다. 이러한 문제를 방지하기 위한 대표적인 캐시 무효화 방법은 다음과 같다.

1. Cache-Control + ETag 활용
   • Cache-Control의 no-cache나 짧은 max-age를 설정하여 브라우저가 주기적으로 서버에 검증 요청을 보내도록 한다.
   • 서버는 ETag를 통해 리소스의 변경 여부를 판단한다.
     • 변경이 없으면: 304 Not Modified로 응답하여 캐시를 재사용
     • 변경되었으면 200 OK로 새 리소스를 내려보낸다.
2. 파일명 버전 관리
   • 리소스 파일명에 버전 정보나 빌드 날짜를 포함해 새로운 버전 배포 시 URL이 달라지도록 한다.
     • ex) style.v2.css, script.20251013.js
   • 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 자료