CSS를 수정했는데 화면이 그대로라면: 브라우저 캐시 확인하기

분명 CSS를 고쳐서 서버에 올렸는데, 휴대폰에서는 바뀌기 전 화면이 나옵니다. 내 컴퓨터에서는 잘 보이니 파일이 덜 올라간 건지, 방문자에게 새로고침을 부탁해야 하는 건지 헷갈립니다.

이럴 때 무조건 캐시를 지우기 전에 브라우저가 실제로 어떤 CSS 주소를 읽었는지부터 확인하는 편이 좋습니다. 서버에 새 파일이 있다는 사실과 방문자가 그 파일을 받았다는 사실은 다릅니다. 이번에는 작은 로컬 서버로 두 상황을 직접 비교했습니다.

서버를 고쳐도 브라우저는 모를 수 있습니다

브라우저는 받은 CSS를 보관했다가 다시 쓸 수 있습니다. 매번 같은 파일을 내려받지 않으니 화면을 빨리 띄우는 데 도움이 됩니다. 문제는 파일 내용만 바꾸고 주소는 그대로 뒀을 때입니다. 저장된 응답을 아직 재사용할 수 있다면 서버에 새 내용이 생겼는지 확인하지 않을 수 있습니다.

실습 서버는 CSS 응답에 아래 헤더를 붙입니다. 단순한 이 실습 조건에서 브라우저가 한 시간 동안 응답을 재사용할 수 있도록 한 설정입니다. 실제 동작은 요청의 캐시 지시나 브라우저 상태에 따라 달라질 수 있습니다.

Cache-Control: max-age=3600

캐시가 요청 주소와 저장된 응답을 연결해 재사용하는 원리는 HTTP 캐시 표준 RFC 9111에 설명돼 있습니다. 이 글에서는 CDN이나 서비스 워커를 끼우지 않고, 브라우저와 로컬 서버 사이의 차이만 살펴봤습니다.

같은 주소와 새 주소를 나눠 시험했습니다

아래 결과는 2026년 11월 2일 Chromium 브라우저에서 확인했습니다. CSS 캐시 실습 파일을 내려받으면 같은 순서로 시험할 수 있습니다. Python 3의 표준 라이브러리만 사용하며, 프로젝트의 파일이나 설정을 읽거나 수정하지 않습니다.

python3 css-cache-demo.py

터미널에 Open http://127.0.0.1:숫자/가 나옵니다. 실행할 때 비어 있는 포트를 골라 쓰므로, 출력된 주소를 그대로 브라우저에 여세요. 자기 컴퓨터에서만 접속하도록 만든 서버입니다. 끝낼 때는 실행한 터미널에서 Ctrl+C를 누릅니다.

1. 처음 열린 화면에서 INITIAL CSS 문구를 확인합니다. 브라우저가 최초 CSS를 받은 상태입니다.
2. Update server CSS 버튼을 누릅니다. 서버가 보내는 CSS 내용만 바뀌며, 현재 브라우저 화면을 직접 고치지는 않습니다.
3. 두 번째 항목의 링크를 누릅니다. 새 페이지로 이동하지만 CSS 주소는 /style.css?v=1로 같습니다.
4. 세 번째 항목의 링크를 누릅니다. 이번 페이지는 /style.css?v=2를 요청합니다.

이 순서에서는 개발자 도구의 캐시 비활성화 옵션을 켜지 않았습니다. 새로고침 버튼도 누르지 않고 링크로 이동했습니다. 새로고침은 브라우저가 재검증을 시도하는 등 일반적인 페이지 이동과 다르게 동작할 수 있어, 여기서는 조건을 섞지 않았습니다.

서버 수정 후에도 붉은 INITIAL CSS 문구가 남았습니다. 이때 서버의 CSS 요청 횟수도 늘지 않았습니다. 새 파일을 받아서 잘못 그린 게 아니라, CSS를 다시 요청하지 않은 것입니다.

다음 페이지에서는 주소의 버전을 바꿨습니다. 브라우저가 새 CSS를 요청하면서 초록색 UPDATED CSS 문구가 나타났고, 서버의 CSS 요청 횟수는 2회가 됐습니다.

이 예제의 버전 값은 ‘다른 요청 주소를 만드는 장치’입니다. 서버가 v=1과 v=2 파일을 각각 보관하지는 않습니다. 어느 주소든 새로 요청하면 그 시점의 CSS를 보냅니다. 따라서 실제 배포에서 예전 버전을 보존하는 구성까지 검증한 결과는 아닙니다.

내 사이트에서는 이 순서로 확인합니다

먼저 문제가 생긴 페이지에서 개발자 도구의 Network를 열고 CSS 요청을 찾습니다. 파일 이름만 보지 말고 Request URL 전체를 확인하세요. 고친 파일과 다른 경로를 읽거나, 예전 HTML이 예전 버전 주소를 가리키는 경우도 구분해야 합니다.

다음으로 해당 요청의 응답 본문에 내가 고친 규칙이 있는지 봅니다. 없다면 CSS 우선순위부터 고치기보다 배포 파일과 캐시 경로를 확인해야 합니다. 반대로 새 규칙이 이미 들어 있다면 선택자, 미디어 쿼리, 다른 스타일의 덮어쓰기를 살펴볼 차례입니다.

브라우저 캐시를 제외한 결과를 비교하려면 Network의 Disable cache를 사용할 수 있습니다. Chrome 공식 안내에 나온 진단 방법입니다. 개발자 도구를 연 상태에서 사용하고, 검사가 끝나면 옵션을 꺼둔 일반 방문 조건에서도 다시 확인하세요.

이 옵션을 켰을 때만 새 스타일이 보인다면 브라우저 캐시가 원인일 가능성을 좁힐 수 있습니다. 그렇다고 CDN이나 서비스 워커까지 모두 우회했다는 뜻은 아닙니다. 응답 본문과 각 계층의 설정을 함께 봐야 합니다. 특히 CDN을 쓰는 사이트는 원본 서버의 파일만 확인하고 끝내지 않는 게 좋습니다.

방문자에게 캐시 삭제를 부탁하는 대신

작은 사이트라면 HTML이 가리키는 CSS 주소에 배포 버전을 붙이는 방식부터 적용할 수 있습니다. 예를 들어 아래처럼 바꿉니다. 바뀌는 것은 CSS 파일 자체만이 아니라 HTML 안의 링크라는 점이 중요합니다.

<!-- 이전 HTML -->
<link rel="stylesheet" href="/styles.css?v=20261026">

<!-- 새로 배포할 HTML -->
<link rel="stylesheet" href="/styles.css?v=20261102">

버전 값은 예시입니다. 매 접속마다 현재 시각을 붙이면 같은 내용도 계속 다른 주소가 돼 캐시의 이점을 잃을 수 있습니다. 변경된 배포를 구분할 수 있는 값을 정하고, HTML과 CSS를 한 배포 단위로 확인하는 편이 낫습니다.

이 방식도 HTML이 예전 상태로 남아 있으면 소용이 없습니다. 방문자가 받은 HTML에 새 링크가 들어 있는지까지 확인해야 합니다. CDN이 쿼리 문자열을 캐시 키에서 빼도록 설정돼 있다면 버전 값만 바꿔도 기대한 결과가 나오지 않을 수 있습니다.

파일이 많아지면 빌드 도구가 내용 해시를 넣은 파일 이름을 만들게 하는 방법도 있습니다. 예를 들어 styles.내용해시.css처럼 내용이 바뀔 때 주소도 바뀌게 하는 방식입니다. 이 경우 새 HTML에서 참조할 자산을 먼저 준비하고, 이전 HTML이 필요한 동안 예전 자산도 유지하는 배포 순서를 검토하세요.

no-cache와 no-store도 구분해야 합니다

캐시 문제를 겪었다고 모든 응답을 저장하지 않도록 바꿀 필요는 없습니다. 공개 CSS와 로그인한 사람의 개인정보 응답은 요구 조건부터 다릅니다. 아래 구분을 출발점으로 삼되, 실제 응답의 전체 헤더와 서비스 구조에 맞춰 설정해야 합니다.

이 차이는 RFC 9111의 응답 캐시 지시를 기준으로 정리했습니다. 이름 때문에 no-cache를 ‘저장 금지’로 읽기 쉽지만 no-store와는 다릅니다. 이미 여러 곳에 저장된 사본을 한 번에 지우는 명령으로 생각해서도 안 됩니다.

다음 배포에서는 두 종류의 방문을 확인합니다

배포 직후 새 브라우저에서만 확인하면 기존 방문자의 문제를 놓칠 수 있습니다. 이번처럼 이전 CSS를 이미 받은 브라우저를 남겨두고, 새 HTML을 받았을 때 새 주소를 요청하는지도 확인해보세요.

• 실제 HTML이 새 CSS 주소를 가리키는지 확인했습니다.
• CSS 응답 본문에 수정한 규칙이 있는지 확인했습니다.
• 이전 화면을 본 브라우저와 처음 접속하는 브라우저를 모두 시험했습니다.
• 캐시 비활성화 옵션을 끈 상태에서도 결과를 확인했습니다.

캐시가 원인인지도 모른 채 새로고침만 반복하면 무엇이 고쳐졌는지 남지 않습니다. 먼저 요청 주소와 응답 내용을 확인하고, 그다음 배포 버전과 캐시 설정을 나눠 보세요. 방문자에게 매번 캐시를 지워달라고 안내하는 것보다 재현과 수정 결과를 확인하기 쉬워집니다.