상품 이미지를 새 파일로 덮어썼는데 홈페이지에는 이전 사진이 남아 있습니다. 이때 전체 캐시부터 비우면 원본 교체 문제인지, 중간에 보관된 복사본 문제인지 구분하기 어려워집니다. 같은 이미지 경로를 유지하는 상황이라면 먼저 원본과 실제 응답을 비교하고, 바꿔야 할 캐시의 범위를 정하는 편이 낫습니다.
원본 교체와 화면 반영 사이의 세 지점
이 글은 원본 저장소 앞에 CloudFront를 두고, 같은 경로의 이미지 파일을 교체하는 구성을 예로 들겠습니다. 원본은 실제 파일을 제공하는 저장소나 웹서버이며, CloudFront의 엣지 캐시는 이용자가 물리적으로 가까이 있는 CDN에서 응답 복사본을 보관합니다. 브라우저에도 별도의 복사본이 남을 수 있습니다.
먼저 개발자 도구의 Network에서 화면이 실제로 요청한 이미지 URL을 확인합니다. 파일명뿐 아니라 대소문자와 쿼리 문자열까지 기록합니다. 반응형 이미지의 srcset이나 썸네일 변환 때문에 작업자가 교체한 파일과 화면이 불러온 파일이 다를 수도 있습니다.
그다음 권한이 있는 관리 경로에서 원본 파일의 내용을 확인합니다. 원본 자체가 이전 이미지라면 업로드 대상과 배포 경로를 먼저 바로잡습니다. 비공개 저장소는 공개로 바꾸지 말고 기존 관리 권한으로 확인합니다.
요약: 화면이 요청한 경로와 실제 교체한 원본이 같은지부터 맞춥니다.
캐시 응답을 구별하는 확인 순서
원본이 새 이미지인 것을 확인했다면 브라우저 개발자 도구에서 캐시를 비활성화한 상태로 해당 이미지를 다시 요청합니다. memory cache나 disk cache 표시가 있었는지, 실제 네트워크 응답이 발생했는지 함께 봅니다. 이 조작은 브라우저 저장본을 배제하기 위한 것이며 CloudFront의 원본 재조회를 강제하는 수단은 아닙니다.
실제 응답에서는 X-Cache, Age, Cache-Control을 확인합니다. 캐시 적중 표시와 Age는 중간 캐시를 살피는 단서지만, 그 자체로 이미지가 구버전이라는 증거는 아닙니다. 반환된 이미지 내용도 원본과 비교해야 합니다. 브라우저 캐시를 배제하자 새 이미지가 보인다면 CloudFront 무효화를 반복할 이유는 줄어듭니다.
CloudFront의 보관 시간은 캐시 정책의 TTL과 원본 응답 헤더의 영향을 받습니다. TTL은 복사본의 유효기간입니다. AWS 문서에 따르면 이용자 요청의 Cache-Control이나 Pragma 헤더만으로 CloudFront가 원본을 다시 조회하도록 강제할 수는 없습니다. 새로고침 결과만으로 어느 계층이 바뀌었는지 단정하지 않는 이유입니다.
요약: 헤더는 캐시 위치를 추적하는 단서이고, 최종 판정은 이미지 내용과 함께 내립니다.
같은 경로를 유지할 때의 무효화 범위
원본은 새 이미지인데 CloudFront가 이전 내용을 반환하고, 자연 만료까지 기다릴 수 없다면 해당 경로의 무효화를 검토합니다. CloudFront 무효화는 엣지의 저장본을 제거하는 기능이며 이용자의 브라우저 캐시까지 지우지는 않습니다. AWS는 잦은 교체에는 버전이 들어간 파일명을 사용하는 방법도 권장합니다.
예를 들어 실제 요청이 /images/banner.jpg라면 해당 배포에서 /images/banner.jpg를 대상으로 삼습니다. 무효화 경로는 배포 기준이며 대소문자를 구분합니다. 원본 저장소 내부의 폴더 경로를 그대로 넣기 전에 이용자 요청 경로와 원본 경로 설정의 관계를 확인해야 합니다.
쿼리 문자열로 캐시가 나뉘는 구성에서는 해당 변형도 범위에 포함해야 합니다. /images/banner.jpg*는 변형을 함께 지정하는 방법이지만 같은 접두어의 다른 파일까지 포함할 수 있습니다. 와일드카드는 끝에 사용합니다. 전체 배포를 뜻하는 /*를 관성적으로 선택하기보다 이번 변경 대상만 특정하는 편이 영향 범위를 설명하기 쉽습니다.
요약: 원본 갱신 확인, 반영 시급성, 정확한 경로가 무효화 판단의 세 조건입니다.
완료 상태 이후의 재확인
무효화 요청을 생성한 뒤에는 처리 상태가 Completed인지 확인하고, 브라우저 캐시를 배제한 실제 요청으로 이미지 내용을 다시 대조합니다. 완료 표시는 무효화 처리의 완료이며, 모든 이용자 화면이 이미 새로 그려졌다는 의미는 아닙니다. 기록에는 배포 식별자, 대상 경로, 완료 시점과 확인한 이미지 내용을 남깁니다.
그래도 이전 이미지가 반환된다면 같은 작업을 반복하기 전에 요청 도메인이 해당 배포를 가리키는지, 그 경로가 선택하는 원본이 맞는지 확인합니다. 이미지 변환 경로나 URI 재작성도 확인 대상입니다. AWS는 viewer request의 Lambda 함수가 URI를 바꾸는 경우 변경 전후 URI를 모두 무효화하도록 안내합니다.
요약: 완료 상태와 실제 콘텐츠 검증을 한 쌍으로 기록합니다.
자주 묻는 질문
주소 뒤에 ?v=2만 붙이면 해결되나요?
항상 그렇지는 않습니다. 해당 쿼리 매개변수를 캐시 키에 포함하는지 확인해야 합니다. 같은 파일 경로에 임의 매개변수만 덧붙이는 방법을 모든 구성의 갱신 수단으로 삼기는 어렵습니다.
원본의 캐시 시간을 줄이면 기존 저장본도 바로 바뀌나요?
새 응답에 적용할 정책 변경과 이미 저장된 응답의 처리는 구분해야 합니다. 긴급 교체라면 설정 변경만으로 반영을 단정하지 말고, 기존 경로의 무효화 필요성을 별도로 판단합니다.
버전 파일명으로 바꿀 때도 확인할 점이 있나요?
새 파일을 올리는 데서 끝나지 않고 HTML이나 애플리케이션의 참조 주소도 새 경로로 바꿔야 합니다. 참조 문서가 이전 상태로 캐시되어 있다면 이용자는 계속 이전 경로를 요청할 수 있습니다.
결론
제 판단으로는 이 작업의 출발점은 캐시 삭제 버튼이 아니라 요청 경로를 검증하는 일입니다. 원본 내용과 요청 경로가 맞고, 브라우저 저장본을 배제해도 이전 이미지가 내려오며, 반영을 기다릴 수 없을 때 해당 경로를 무효화합니다. 이후에는 완료 상태와 실제 이미지까지 확인해야 교체 작업을 종료할 수 있습니다.