캐시 기본 개념과 운영 기준

캐시 기본 개념과 운영 기준

웹사이트 운영에서 캐시는 속도 개선 기능으로만 이해되기 쉽지만, 실제로는 응답 재사용 규칙 전체를 다루는 개념에 가깝습니다. HTTP 캐시는 요청에 대한 응답을 저장한 뒤 같은 요청이 다시 들어오면 기존 응답을 재사용하도록 설계되어 있으며, 이 과정은 네트워크 지연과 데이터 전송량, 원본 서버 부담을 함께 줄이는 데 쓰입니다. 다만 캐시가 효율을 높인다는 사실과 별개로, 무엇을 얼마나 오래 저장할지 기준이 없으면 오래된 화면 노출, 로그인 정보 재사용 위험, 배포 직후 반영 지연 같은 문제가 생길 수 있습니다. 따라서 운영자는 캐시를 단순 저장소가 아니라 “재사용을 통제하는 규칙”으로 이해해야 합니다. (MDN 웹 문서)

캐시의 정의

캐시는 이미 받아 둔 응답을 다시 쓰기 위한 저장 구조입니다. MDN은 HTTP 캐시를 요청과 응답을 보관했다가 이후 요청에 재사용하는 구현으로 설명하며, 일반적으로 GET 요청 응답이 주요 대상이라고 안내합니다. 이 구조가 필요한 이유는 같은 파일과 문서를 매번 원본 서버에서 다시 내려받으면 불필요한 왕복 시간이 늘어나고, 서버와 네트워크 비용도 함께 증가하기 때문입니다. 즉 캐시의 핵심은 “한 번 받은 것을 가능한 범위 안에서 다시 쓴다”는 데 있습니다. 웹사이트 속도 개선이 캐시의 대표 효과인 것은 맞지만, 본질은 저장이 아니라 재사용 판단에 있습니다. (MDN 웹 문서)

캐시는 저장보다 규칙이 중요하다

캐시 동작은 자동처럼 보이지만 실제로는 Cache-Control 같은 헤더 규칙에 의해 제어됩니다. MDN은 Cache-Control이 브라우저와 공유 캐시에서 캐싱을 어떻게 처리할지 정하는 지시문이라고 설명합니다. 따라서 캐시를 설계할 때는 저장 유무만 볼 것이 아니라, 얼마 동안 신선한지, 다시 검증이 필요한지, 브라우저에만 저장할지, 공유 캐시에도 저장할지를 함께 정해야 합니다. 캐시는 단순히 켜고 끄는 기능이 아니라 응답별 정책 설정에 더 가깝습니다. (MDN 웹 문서)

브라우저 캐시와 서버 캐시의 차이

브라우저 캐시는 사용자의 기기 안에서 동작하는 개인용 저장소입니다. 반대로 실무에서 말하는 서버 캐시는 애플리케이션 앞단이나 서버 측 계층이 응답을 저장했다가 다시 사용하는 구조를 뜻하는 경우가 많습니다. MDN은 캐시를 사설 캐시와 공유 캐시로 구분하며, 사설 캐시는 브라우저 같은 개인용 캐시를 말하고 공유 캐시는 프록시나 CDN처럼 여러 사용자 사이에서 재사용되는 캐시를 뜻한다고 설명합니다. 또 NGINX 문서는 서버 앞단에서 응답을 디스크 캐시에 저장해 같은 콘텐츠 요청마다 원본에 다시 프록시하지 않도록 할 수 있다고 안내합니다. 이 차이 때문에 브라우저 캐시는 개별 사용자 경험에, 서버 캐시는 원본 부하 감소와 응답 처리량에 더 직접적으로 연결됩니다. (MDN 웹 문서)

개인용 응답과 공용 응답을 구분해야 하는 이유

private 지시문은 응답을 브라우저 같은 사설 캐시에만 저장하도록 하고, public이나 s-maxage는 공유 캐시 활용과 연결됩니다. MDN은 로그인 뒤 개인화된 응답에 private를 넣지 않으면 공유 캐시에 저장되어 다른 사용자에게 재사용될 수 있다고 설명합니다. 따라서 마이페이지, 주문 내역, 관리자 화면처럼 사용자별 내용이 다른 페이지는 속도보다 분리 보관이 우선입니다. 반대로 이미지, 폰트, 공용 스크립트처럼 사용자마다 달라지지 않는 파일은 공유 캐시 활용 효과가 더 큽니다. (MDN 웹 문서)

CDN 캐시의 역할

CDN 캐시는 원본 서버와 사용자 사이에 있는 공유 캐시입니다. MDN은 공유 캐시가 클라이언트와 원본 서버 사이에 존재하며 여러 사용자에게 같은 응답을 재사용할 수 있다고 설명합니다. 이 구조 덕분에 자주 요청되는 정적 파일은 사용자와 더 가까운 지점에서 응답할 수 있고, 원본 서버는 같은 파일을 반복 전송하는 부담을 줄일 수 있습니다. 특히 방문자가 여러 지역에 분산되어 있거나 이미지, 스크립트, 폰트 같은 정적 자산 요청이 많은 사이트일수록 CDN 캐시의 효율이 커집니다. (MDN 웹 문서)

CDN은 모든 것을 자동으로 캐시하지 않는다

CDN을 붙였다고 모든 페이지가 자동으로 캐시되는 것은 아닙니다. 예를 들어 Cloudflare 공식 문서는 기본적으로 파일 확장자 기준으로 특정 자산을 캐시하며, HTML과 JSON은 기본 설정에서 캐시하지 않는다고 설명합니다. 또한 s-maxage는 공유 캐시에서 응답이 얼마나 신선한지 정하는 지시문으로, 브라우저용 max-age와 별도로 CDN 정책을 나눌 때 쓰입니다. 운영자가 CDN 캐시를 이해해야 하는 이유는 캐시 유무보다 “어떤 응답을 어떤 계층에서 재사용할 것인가”를 분리해서 설계해야 하기 때문입니다. (Cloudflare Docs)

수정 내용이 바로 보이지 않는 이유

수정한 CSS나 이미지, 문서가 바로 보이지 않는 가장 흔한 이유는 캐시된 응답이 아직 신선한 상태로 남아 있기 때문입니다. 브라우저는 유효한 캐시가 있으면 네트워크 요청 없이 저장된 응답을 그대로 재사용할 수 있습니다. 또 no-cache는 “저장하지 말라”가 아니라 “재사용 전 원본 서버에 검증하라”는 뜻이므로, 운영자가 의미를 반대로 이해하면 배포 후 동작을 잘못 해석하기 쉽습니다. MDN은 ETag와 Last-Modified를 통해 브라우저가 서버에 변경 여부를 확인하고, 변경이 없으면 304 Not Modified로 기존 사본을 계속 쓰게 된다고 설명합니다. 따라서 수정 직후 반영이 늦어 보이는 현상은 캐시 자체의 오류보다 신선도와 재검증 정책의 결과인 경우가 많습니다. (web.dev)

파일명을 바꾸지 않으면 오래된 자산이 남기 쉽다

정적 파일은 긴 max-age와 immutable을 함께 쓰는 경우가 많습니다. MDN은 버전이나 해시가 포함된 URL을 사용하고, 내용이 바뀌면 새 URL로 교체하는 방식을 현대적인 모범 사례로 설명합니다. 반대로 같은 URL을 유지한 채 파일 내용만 바꾸면 브라우저와 CDN이 오래된 파일을 계속 재사용할 수 있습니다. 그래서 정적 자산 배포에서는 파일 교체보다 파일명 변경, 즉 캐시 버스팅이 더 안정적인 운영 기준이 됩니다. (MDN 웹 문서)

캐시 삭제가 필요한 상황

캐시 삭제나 무효화가 필요한 대표 상황은 배포 직후 잘못된 자산이 남아 있을 때, 긴 TTL을 준 파일을 긴급 수정해야 할 때, 서버 캐시가 이전 페이지를 계속 응답할 때입니다. NGINX 문서는 오래된 캐시 파일을 제거하지 않으면 웹페이지의 새 버전과 이전 버전이 동시에 제공될 수 있어 캐시 퍼지가 필요하다고 설명합니다. 또한 MDN은 이미 중간 캐시에 저장된 응답을 표준 Cache-Control만으로 즉시 지우는 지시문은 없다고 설명합니다. 즉 브라우저 캐시는 사용자 측 삭제나 사이트 지시가 필요하고, CDN이나 리버스 프록시 캐시는 서비스별 퍼지 기능이나 서버 측 무효화 절차가 필요합니다. (docs.nginx.com)

삭제보다 정책 재설계가 더 중요하다

운영 현장에서는 캐시를 자주 비우는 것보다 애초에 잘못 남지 않게 설계하는 편이 더 안정적입니다. 자주 바뀌는 HTML, API 응답, 관리 화면은 no-cache나 짧은 수명 정책을 검토하고, 절대 바뀌지 않는 정적 자산은 버전 URL과 긴 max-age를 사용하는 방식이 일반적입니다. 브라우저 캐시만 지워도 CDN이나 서버 캐시가 남아 있을 수 있고, 반대로 CDN만 퍼지해도 사용자 브라우저에 남은 파일은 계속 보일 수 있으므로, 어느 계층의 캐시가 문제인지 먼저 구분해야 합니다. (MDN 웹 문서)

과도한 캐시의 문제

캐시는 부족해도 문제지만 과해도 문제가 됩니다. 첫째, 개인화된 응답에 private를 빠뜨리면 공유 캐시를 통해 다른 사용자에게 잘못 재사용될 위험이 있습니다. 둘째, 바뀔 수 있는 파일에 긴 max-age나 immutable을 주면 수정 사항이 늦게 반영됩니다. 셋째, stale-while-revalidate는 성능에 유리하지만, 재검증이 끝날 때까지 오래된 응답을 잠시 다시 쓸 수 있으므로 최신성이 중요한 화면에는 신중해야 합니다. 따라서 캐시 정책은 “길게 저장할수록 좋다”가 아니라 “바뀌지 않는 것만 길게 저장한다”는 원칙으로 접근해야 합니다. (MDN 웹 문서)

운영자가 기억해야 할 핵심

운영 기준은 단순하게 잡는 편이 좋습니다. 공용 정적 자산은 버전 URL을 사용한 뒤 긴 max-age와 immutable을 검토합니다. HTML 문서나 자주 바뀌는 데이터는 짧은 수명 또는 재검증 중심 정책을 사용합니다. 로그인 뒤 보이는 개인화 응답은 private나 필요 시 no-store를 우선 검토합니다. CDN을 함께 쓰는 환경이라면 브라우저 정책과 공유 캐시 정책을 분리하기 위해 s-maxage 같은 지시문도 살펴볼 필요가 있습니다. 결국 캐시 운영의 핵심은 “무조건 빠르게”가 아니라 “응답 성격에 맞는 저장 범위와 유효 기간을 나누는 것”입니다. (MDN 웹 문서)

맺음말

캐시는 같은 응답을 다시 활용해 속도와 비용을 함께 개선하는 기술입니다. 다만 브라우저 캐시, 서버 캐시, CDN 캐시는 위치와 역할이 서로 다르며, 수정 반영 지연과 오래된 화면 노출도 대부분 이 차이를 구분하지 못할 때 커집니다. 운영자는 캐시를 단순 성능 옵션이 아니라 응답별 정책 설계로 다뤄야 합니다. 어떤 파일을 오래 보관할지, 어떤 화면은 매번 검증할지, 어떤 응답은 아예 저장하지 않을지를 분리해서 정하면 캐시의 장점은 살리고 부작용은 줄일 수 있습니다. (MDN 웹 문서)