CloudFront를 붙인 뒤 같은 파일을 두 번 열었다. 두 번째 응답에서 X-Cache: Hit from cloudfront를 기대했는데 여전히 Miss from cloudfront다. ‘CDN이 일을 안 하나?’ 싶지만, URL을 다시 열었다는 사실만으로 같은 캐시를 조회했다고 볼 수는 없다.
CloudFront의 Miss와 Hit는 무엇을 뜻할까?
CloudFront는 요청을 받은 엣지의 캐시에서 쓸 수 있는 응답을 찾는다. Hit는 그 캐시에서 유효한 객체를 찾았다는 뜻이고, Miss는 그 요청에 맞는 유효한 객체를 찾지 못했다는 뜻이다. 여기서 중요한 말은 ‘그 요청에 맞는’이다. 같은 파일처럼 보여도 캐시 키가 다르면 별개의 응답으로 취급한다.
예를 들어 S3의 assets/guide.txt를 CloudFront로 제공한다고 하자. 다음 표는 요청이 같은 엣지에 도착하고, GET /assets/guide.txt의 캐시 키가 같다는 가정 아래의 흐름이다.
| 요청 순간 | 엣지에서 확인한 상태 | 가능한 X-Cache |
|---|---|---|
| 처음 조회 | 해당 키의 유효한 사본이 없음 | Miss |
| TTL 안에 다시 조회 | 같은 키의 유효한 사본이 있음 | Hit |
| TTL이 지난 뒤 조회 | 이전 사본의 유효 기간이 끝남 | Miss 가능 |
같은 파일을 다시 요청해도 중간 조건이 달라지면 표의 두 번째 줄을 기대할 수 없다. 이것은 설명용 조건 비교이지 실제 AWS 배포의 측정 결과가 아니다.
같은 URL인데 왜 계속 Miss가 나올까?
먼저 요청의 호스트와 경로가 정말 같은지 비교한다. 그다음 해당 캐시 동작에 연결된 캐시 정책을 확인한다. 정책에 따라 쿼리 문자열, 헤더, 쿠키의 값이 캐시 키에 포함될 수 있다. 예컨대 ?lang=ko와 ?lang=en을 키에 포함하도록 했다면 두 요청은 서로 다른 자리를 찾는다. 반대로 쿼리 문자열을 키에 넣지 않았다면 값만 바뀌었다고 별도 Miss가 되는 것은 아니다. AWS의 캐시 키 설명이 이 구분의 기준이다.
캐시 키가 같아도 엣지 위치가 다르거나 객체가 만료·제거되었다면 다시 Miss가 날 수 있다. 특히 TTL이 짧으면 다음 요청 전에 객체가 만료될 수 있다. Cache-Control과 배포의 캐시 정책이 실제로 얼마나 오래 유효하게 만드는지 함께 봐야 한다. AWS의 캐시 만료 설명은 만료 후 오리진에 최신 버전을 확인하는 흐름도 다룬다.
그래서 Miss 한 줄만 보고 ‘오리진이 매번 전체 파일을 다시 전송했다’고 단정할 수 없다. 오리진 확인, 다른 캐시 계층, 요청 정책이 끼어들 수 있다.
브라우저의 304와 X-Cache는 같은 신호일까?
아니다. 304 Not Modified는 브라우저가 가진 사본을 다시 써도 되는지 확인하는 HTTP 응답 상태이고, X-Cache는 CloudFront 응답의 캐시 처리 단서다. 서로 다른 질문에 답하므로 같은 화면에 304와 Miss가 함께 보이거나 304와 Hit가 함께 보일 수 있다.
브라우저 개발자 도구에서 304를 봤다면 요청 헤더의 If-None-Match·If-Modified-Since, 응답의 ETag·Last-Modified도 함께 확인하자. 브라우저 캐시가 관여한 재검증을 CloudFront가 고장 났다는 증거로 읽지 않기 위해서다. Age가 보이면 캐시된 응답이 얼마나 오래되었는지 읽는 데도 도움이 된다.
Miss가 반복될 때는 어떤 순서로 확인할까?
- 무엇을 비교하나? 브라우저의 ‘메모리·디스크 캐시’ 표시가 아니라 실제 네트워크 응답의
X-Cache를 본다. 같은 호스트·경로·요청 방식인지 확인한다. - 같은 캐시 키인가? 연결된 캐시 정책에서 쿼리 문자열·헤더·쿠키가 키에 들어가는지 본다. 단순히 주소창 문자열만 비교하지 않는다.
- 아직 유효한가? 오리진의
Cache-Control, 배포의 TTL 설정, 응답의Age를 함께 본다. 만료된 뒤의 Miss는 캐시 실패와 다른 이야기다. - 같은 엣지에서 본 결과인가? 다른 지역·네트워크의 결과를 한 캐시의 연속 요청처럼 비교하지 않는다. 원인 판단이 필요하면 요청 로그와 캐시 정책을 함께 대조한다.
반대로 Hit가 보인다고 배포가 언제나 최신 파일을 제공한다는 뜻도 아니다. 오래된 콘텐츠를 막아야 한다면 객체의 갱신 주기와 TTL을 먼저 설계해야 한다. ‘캐시가 잘 된다’와 ‘지금 이 버전이 맞다’는 서로 다른 점검이다.
핵심 요약
Miss는 해당 요청에 맞는 유효한 엣지 캐시 응답이 없다는 뜻이고, Hit는 있다는 뜻이다. 같은 URL을 다시 열었는데 Miss가 반복된다면 캐시 키 → TTL → 엣지 위치 → 브라우저의 304 재검증 순서로 나눠 보자. 두 번째 요청이 무조건 Hit라는 암기보다, 무엇이 같은 요청인지 확인하는 편이 훨씬 빠르다.
