프록시 서버에서 캐시 최신화 방법들

 HTTP 캐시 완전 정복 가이드

웹 성능 향상에서 캐싱(Caching)은 핵심이에요.
하지만 캐시는 "얼마나 오래", "언제까지", "바뀌었는지" 등을 정확하게 판단해야 제대로 작동하죠.
HTTP는 이런 문제를 해결하기 위해 2가지 전략을 제공합니다:

• 만료 기반 캐시 (Freshness) - "이 캐시는 언제까지 유효한가?"
• 검증 기반 캐시 (Validation) - "이 캐시가 여전히 유효한가?"

이제 이 두 가지를 구현하는 HTTP 헤더들인 Expires, Cache-Control, Last-Modified, ETag을 하나하나 파헤쳐보자!

---

 1. Expires - 유효기간을 미리 정해두는 방식

Expires는 HTTP/1.0 시절부터 사용된 오래된 방식이에요.
서버가 리소스가 유효한 기한을 명확한 날짜/시간으로 알려주는 방식이죠.

Expires: Wed, 15 May 2025 10:00:00 GMT

동작 방식:

1. 브라우저가 서버로부터 응답을 받을 때 Expires 헤더를 확인해요.
2. 지정된 날짜/시간 전까지는 그 리소스를 다시 요청하지 않고 캐시된 데이터를 사용해요.

단점: 서버와 클라이언트가 시간을 다르게 설정하면 문제가 생길 수 있어요. (예: 서버는 유효하다고 보는데, 클라이언트 시계가 앞서 있어서 무시함)

---

2. Cache-Control - 더 똑똑한 캐시 설정

Cache-Control은 Expires보다 훨씬 세밀하게 캐시를 제어할 수 있는 방법으로, HTTP/1.1부터 도입됐어요.
특히 CDN이나 프록시 서버, 클라우드 환경에서 필수적으로 쓰이죠.

Cache-Control: public, max-age=3600

주요 디렉티브:

• max-age=n – 이 응답은 n초 동안 유효해요.
• public – 이 리소스는 공유 캐시(프록시 등)에서도 저장해도 돼요.
• private – 브라우저 전용 캐시. (프록시는 저장하면 안 됨)
• no-cache – 저장은 되지만, 사용 전 반드시 서버 검증해야 해요.
• no-store – 아예 저장 자체를 금지. 로그인 정보 같은 민감한 데이터에 사용.
• must-revalidate – 캐시 만료 후 반드시 서버 확인. (중간 캐시도 무시 못함)

장점: Expires는 절대 시간(서버 기준)이지만, Cache-Control은 상대 시간(응답 수신 시점 기준)이라 더 안정적이에요.

---

3. Last-Modified - 마지막 수정 시각으로 판단

Last-Modified는 서버가 "이 리소스는 언제 마지막으로 바뀌었어"라고 알려주는 헤더예요.

Last-Modified: Tue, 07 May 2025 04:30:00 GMT

동작 방식:

1. 클라이언트는 응답의 Last-Modified 값을 저장해요.
2. 다음에 같은 리소스를 요청할 때 If-Modified-Since 헤더로 서버에 확인해요.

If-Modified-Since: Tue, 07 May 2025 04:30:00 GMT

서버는 이 값 이후에 리소스가 바뀌었는지 판단해서:

• 304 Not Modified – 변경 안 됨 → 캐시 사용
• 200 OK – 변경됨 → 새로운 데이터 전송

주의: 초 단위까지만 비교하기 때문에, 수정 시간이 짧게 바뀌는 경우 반영이 안 될 수 있어요.

---

4. ETag - 가장 정밀한 변경 감지

ETag는 리소스의 고유 식별자(해시, 버전)를 지정해요. 이건 파일 내용이 1바이트만 달라도 달라지는 값이라서 굉장히 정밀해요.

ETag: "abc123xyz"

동작 방식:

1. 클라이언트는 ETag 값을 저장하고
2. 다음 요청 시 If-None-Match 헤더에 그 값을 넣어 서버에 보냅니다.

If-None-Match: "abc123xyz"

서버는 현재 리소스의 ETag와 비교해서:

• 304 Not Modified – 같음 → 캐시 사용
• 200 OK – 다름 → 새 응답 전송

장점: 정확도 최강!
단점: 서버 입장에서 ETag 계산(보통 해시 계산)이 비용이 있어요.

---

5. 요약 비교표

헤더	유형	설명	장점	단점
Expires	만료 기반	절대 만료 시간 지정	간단하고 빠름	시계 불일치 위험
Cache-Control	만료 기반	상대 만료 시간 + 고급 제어	정확하고 유연함	조금 복잡함
Last-Modified	검증 기반	마지막 수정 시각으로 판단	서버 구현 쉬움	초 단위로만 비교됨
ETag	검증 기반	고유 식별자 (해시 등)	정확도 최고	서버 계산 비용 발생

---

실전 사용 팁

• 정적 파일(CSS, JS, 이미지 등)은 Cache-Control: public, max-age=31536000 같이 오래 캐싱
• 로그인 페이지나 민감한 데이터는 Cache-Control: no-store
• 변경 가능성 있는 데이터는 ETag나 Last-Modified를 써서 검증 방식 사용
• 실무에서는 만료 + 검증을 함께 써서 최적의 효율과 정확성을 챙기는 경우가 많아요.

---

 정리

HTTP 캐시는 단순한 저장이 아니라, 언제까지, 얼마나 정확하게 사용할지를 판단하는 똑똑한 시스템이에요.
이번 글에서 다룬 4가지 헤더를 조합하면, 성능 좋고 트래픽도 아끼는 웹 서비스를 만들 수 있습니다!