캐시란? 수정한 웹페이지가 그대로 보이는 이유

안녕하세요. 사랑받는 IT 프로덕트의 첫걸음, 똑똑한개발자입니다.

오늘의 인사이트 요약

• 캐시는 받은 데이터를 저장했다가 다시 사용하는 방식입니다.

• no-cache는 재검증, no-store는 저장 금지를 뜻합니다.

• 수정 내용이 안 보이면 파일 주소와 응답부터 비교합니다.

캐시(cache)는 한 번 가져온 데이터를 저장해 두었다가 다시 사용하는 방식입니다. 웹에서는 이미지나 스타일 파일, 서버 응답 등을 매번 새로 받지 않고 재사용해 로딩 시간과 전송량을 줄일 수 있습니다. 대신 저장된 내용이 아직 유효하다고 판단되면 수정 전 화면이 보일 수 있습니다.

새로고침으로 해결되는 경우도 있지만, 캐시는 사용자 브라우저에만 있지 않습니다. 서버 앞에서 콘텐츠를 전달하는 CDN이나 애플리케이션 내부에도 저장된 데이터가 있을 수 있습니다. 오늘은 웹 캐시의 동작과 수정 내용 확인 방법을 알아보겠습니다.

1. 웹 캐시는 어디에 저장되나요?

브라우저 캐시와 공유 캐시의 차이

브라우저 캐시는 사용자의 브라우저에 응답을 보관합니다. 같은 이미지를 다시 요청할 때 저장한 파일을 이용할 수 있죠. 여러 사용자의 요청에 응답하는 CDN 등은 공유 캐시를 둘 수 있습니다. 내 브라우저 데이터를 지워도 공유 캐시에 예전 응답이 남아 있다면 같은 내용이 다시 전달될 수 있습니다.

캐시에 저장됐다는 사실과 오래됐다는 판단은 다릅니다. HTTP 캐시는 응답 헤더의 정책 등을 보고 저장한 응답을 바로 써도 되는지, 서버에 다시 확인해야 하는지 결정합니다. 예를 들어 Cache-Control의 max-age는 응답을 신선하다고 볼 시간을 초 단위로 지정합니다. 시간이 지나면 무조건 파일을 삭제하기보다 재검증 후 다시 활용할 수도 있습니다.

화면마다 갱신 시점이 다른 이유

웹페이지는 HTML뿐 아니라 이미지·스크립트·데이터 응답으로 구성됩니다. 이들이 서로 다른 주소와 정책을 쓰면 일부만 이전 버전으로 남을 수 있습니다. 제목은 바뀌었는데 사진은 그대로이거나, 새 디자인에 예전 기능이 함께 나타나는 식입니다. 화면 전체가 한 번에 저장되고 갱신된다고 생각하면 원인을 찾기 어렵습니다.

예를 들어 보겠습니다.
상품 소개 문구와 대표 사진을 수정했는데 문구만 바뀌었다면, 페이지 저장 여부와 사진 파일 응답을 따로 확인할 수 있습니다. 같은 파일 주소의 사진을 교체했는지, HTML이 새 사진 주소를 가리키는지가 서로 다른 점검 대상입니다.

저장 위치와 유효기간을 구분하면 어떤 요청을 조사할지 정하기 쉽습니다. 개인 캐시와 공유 캐시의 동작, 만료된 응답을 다시 확인하는 흐름을 더 자세히 알고 싶다면 MDN의 HTTP 캐시 안내를 참고해 보세요.

2. no-cache와 no-store는 어떻게 다른가요?

no-cache는 저장 자체를 막지 않습니다

이름 때문에 헷갈리지만 no-cache는 응답을 저장하지 말라는 뜻이 아닙니다. 저장한 응답을 사용하기 전에 서버에 재검증하도록 요구합니다. 서버가 내용이 바뀌지 않았다고 응답하면 이전 데이터를 다시 쓸 수 있으므로, 매번 본문 전체를 새로 내려받는 것과도 다릅니다.

no-store는 캐시가 해당 응답을 저장하지 않도록 지시합니다. 다만 지금부터 이 헤더를 추가했다고 해서 같은 주소로 이미 저장된 모든 응답이 자동 삭제되는 것은 아닙니다. 기존 캐시가 어떻게 갱신되는지까지 확인해야 하며, 개인화된 응답의 저장 정책도 내용과 서비스 요구에 맞게 설계해야 합니다.

private은 공유 캐시에 저장하지 않도록 합니다

private은 브라우저 같은 개인 캐시의 저장을 허용하면서 공유 캐시에는 저장하지 않도록 지시합니다. 로그인한 사용자별로 내용이 달라질 때 공유 저장 여부를 검토하는 데 필요한 구분입니다. private을 썼다는 사실만으로 인증이나 접근 제어가 완성되는 것은 아니며, 누가 내용을 받을 수 있는지는 서버에서 별도로 판단합니다.

헤더를 많이 붙일수록 최신 화면이 보장되는 것은 아닙니다. 저장 허용·재사용 조건·공유 범위가 각각 무엇인지 보고 필요한 정책을 선택해야 합니다. 각 지시어의 정확한 의미와 조합 예시는 MDN의 Cache-Control 문서에서 비교하실 수 있습니다.

3. 수정 내용이 안 보일 때 무엇을 확인하나요?

주소와 실제 응답을 함께 비교합니다

먼저 수정한 내용이 공개용 주소에 반영됐는지 확인합니다. 관리자 미리보기와 공개 페이지가 다르거나, 다른 배포 환경을 보고 있을 수도 있습니다. 이 경우 캐시를 반복해서 비워도 해결되지 않습니다. 확인한 주소와 수정 시각을 함께 남기면 개발 담당자와 같은 화면을 비교하기 쉽습니다.

브라우저 개발자 도구의 Network에서 문제가 있는 파일 요청을 찾고, 응답 내용과 Cache-Control을 살펴볼 수 있습니다. 요청한 파일 주소가 이전과 같은지도 비교하세요. 이미지 변경 문제라면 이미지 요청을, 화면 데이터 문제라면 해당 데이터를 가져오는 요청을 살펴봐야 합니다. 페이지 HTML 응답 하나만으로 모든 파일의 상태를 판단하지 않습니다.

브라우저 캐시를 끈 결과는 원인을 좁히는 단서입니다

개발자 도구에서 브라우저 캐시를 비활성화했을 때 바뀐 내용이 보인다면 로컬 저장이 영향을 줬을 가능성을 살펴볼 수 있습니다. 그래도 예전 내용이 오면 CDN과 서버의 응답을 이어서 비교해야 합니다. 서비스 워커나 애플리케이션이 별도로 데이터를 저장하는 경우에는 그 저장 방식도 확인 대상입니다.

장기 캐시하는 스타일·스크립트 파일은 변경 시 파일명이나 URL에 버전 식별자를 넣어 새 파일로 요청하게 만들 수 있습니다. 그러나 HTML이 계속 예전 파일을 가리키면 새 주소를 만들기만 해서는 부족합니다. 배포할 때는 페이지가 참조하는 주소와 실제 파일 버전도 함께 확인해 보세요.

화면 수정이 실제 사용까지 이어지도록

수정은 끝났는데 사용자마다 다른 화면을 보고 있다면 어디부터 확인해야 할지 난감할 수 있습니다. 똑똑한개발자는 웹·앱의 기획·디자인·개발·운영을 함께 다룹니다. 화면에서 보이는 문제와 실제 데이터가 전달되는 흐름을 연결해 살펴보는 데서 개선 범위를 정할 수 있습니다.

웹사이트의 수정 반영과 운영 방식을 정비하고 싶다면 아래 똑똑한개발자 링크로 편하게 문의해 주세요. 현재 서비스에서 어떤 부분을 확인할지 함께 이야기 나누겠습니다. 감사합니다. :)