웹사이트를 새로 고쳤는데 개발자 도구 Network 탭에 초록색 200이 아니라 304 Not Modified가 줄줄이 표시되면, 무언가 잘못된 것처럼 보입니다. 결론부터 적으면 304 Not Modified는 오류가 아닙니다. 서버가 “요청한 파일이 마지막에 받아 간 것과 같으니 다시 내려보내지 않겠다”고 알려 주는 정상 응답입니다.
다만 이 응답이 나와서는 안 되는 자리에 나오면 화면이 갱신되지 않는 문제로 이어집니다. 수정한 CSS가 반영되지 않거나, 배포한 스크립트가 옛 버전 그대로 동작하는 상황이 대표적입니다. 이 글은 브라우저와 서버가 304 Not Modified를 주고받는 조건을 정리하고, 실제로 문제가 되는 경우를 어떤 순서로 구분하면 되는지 단계별로 설명합니다.
304 Not Modified가 정확히 뜻하는 것
HTTP 상태 코드 304는 조건부 요청에 대한 응답입니다. 브라우저는 이미 캐시에 가지고 있는 파일을 다시 요청할 때, 그 파일의 식별값을 요청 헤더에 함께 보냅니다. 서버는 이 값을 현재 파일과 비교해 내용이 같으면 본문 없이 304 Not Modified만 돌려줍니다.
본문이 없다는 점이 핵심입니다. 응답 크기가 수백 바이트에 그치므로 전송량과 대기 시간이 크게 줄어듭니다. 이미지나 폰트처럼 용량이 큰 정적 파일에서 304 Not Modified가 반복적으로 관찰된다면 캐시가 의도대로 동작하고 있다는 신호입니다.
브라우저는 304를 받은 즉시 자신의 캐시에 저장된 사본을 화면에 사용합니다. 사용자 입장에서는 200을 받았을 때와 결과가 같고, 오히려 더 빠릅니다. 그래서 Network 탭에 304가 많다는 사실 자체는 성능이 잘 잡혀 있다는 근거로 읽는 편이 맞습니다.
브라우저가 304 응답을 받는 조건
조건부 요청이 성립하려면 먼저 캐시에 사본이 있어야 하고, 그 사본에 검증에 쓸 수 있는 정보가 붙어 있어야 합니다. 서버가 응답할 때 ETag 또는 Last-Modified 헤더를 내려보내지 않았다면 브라우저는 비교할 기준이 없어 매번 전체 파일을 다시 받습니다.
또한 캐시의 신선도 기간이 지나야 조건부 요청이 발생합니다. Cache-Control의 max-age가 아직 남아 있으면 브라우저는 서버에 묻지도 않고 캐시를 그대로 씁니다. 이때 Network 탭에는 304가 아니라 disk cache 또는 memory cache로 표시됩니다.
정리하면 304 Not Modified는 “캐시가 있고, 유효 기간은 지났으며, 검증해 보니 내용이 같다”는 세 조건이 모두 맞았을 때 나타납니다. 세 가지 중 하나라도 어긋나면 200이나 캐시 표시가 대신 나옵니다.
ETag와 Last-Modified가 만드는 조건부 요청
ETag는 파일 내용을 요약한 식별자입니다. 서버가 응답에 ETag를 넣어 주면 브라우저는 다음 요청에서 If-None-Match 헤더에 그 값을 실어 보냅니다. 서버는 현재 파일의 ETag와 대조해 같으면 304 Not Modified를 반환합니다.
Last-Modified는 파일의 최종 수정 시각입니다. 브라우저는 If-Modified-Since 헤더로 이 시각을 되돌려 보내고, 서버는 그 이후 변경이 없었으면 역시 304로 답합니다. 두 방식이 함께 설정되어 있으면 일반적으로 ETag 쪽이 우선합니다.
여러 대의 서버로 트래픽을 분산하는 환경에서는 ETag가 서버마다 다르게 계산되어 캐시가 계속 무효화되는 일이 생깁니다. 이 경우 304 Not Modified 대신 200이 반복되면서 전송량이 줄지 않습니다. 원본 서버들의 ETag 생성 규칙을 통일하거나 Last-Modified 기준으로 맞추는 편이 안전합니다.
응답 표시별로 나뉘는 브라우저 캐시 상태
개발자 도구 Network 탭의 Status 열에는 숫자만 표시되는 것이 아닙니다. 같은 파일이라도 브라우저가 어떤 경로로 자원을 얻었는지에 따라 표시가 달라집니다. 이 구분을 하지 못하면 304 Not Modified와 무관한 문제를 캐시 탓으로 돌리게 됩니다.
숫자 200은 서버가 본문을 새로 내려보냈다는 뜻이고, 304 Not Modified는 서버까지 물어봤지만 본문은 받지 않았다는 뜻입니다. 반면 disk cache나 memory cache 표시는 서버에 묻지도 않았다는 뜻입니다. 세 가지는 네트워크 왕복 횟수가 서로 다릅니다.
아래 표는 화면에 표시되는 상태별로 서버 왕복 여부와 전송량, 그리고 파일을 수정했을 때 반영되는 시점을 정리한 것입니다.
| 표시되는 상태 | 서버 왕복 | 응답 본문 | 수정 반영 시점 | 확인 지점 |
|---|---|---|---|---|
| 200 OK | 있음 | 전체 전송 | 즉시 | Size 열에 실제 용량 |
| 304 Not Modified | 있음 | 없음 | 검증 결과가 같으면 유지 | Size 열에 수백 바이트 |
| 200 (disk cache) | 없음 | 없음 | 만료 시간이 지나야 반영 | Size 열에 disk cache |
| 200 (memory cache) | 없음 | 없음 | 탭을 닫을 때까지 지연 | Size 열에 memory cache |
| (from prefetch cache) | 없음 | 없음 | 미리 받아 둔 사본 사용 | Initiator 열에 prefetch |
가정 예시 — 실제 표시 문구는 브라우저 버전에 따라 다를 수 있음
표에서 보듯 수정한 파일이 화면에 나타나지 않는 문제는 304 Not Modified보다 disk cache 쪽에서 더 자주 생깁니다. 서버에 묻지 않기 때문에 서버 설정을 아무리 바꿔도 결과가 같습니다. 이 구분을 먼저 해 두면 이후 확인 순서가 크게 짧아집니다.
304 Not Modified가 오히려 문제가 되는 상황
파일을 수정해 배포했는데도 브라우저가 계속 304를 받는다면 원인은 대부분 두 가지입니다. 첫째, 배포 과정에서 파일 내용이 실제로 바뀌지 않았거나 캐시 서버가 옛 사본을 계속 들고 있는 경우입니다. 둘째, 파일 이름과 경로가 이전과 완전히 같아 브라우저가 같은 자원으로 취급하는 경우입니다.
중간에 CDN이나 리버스 프록시가 있으면 상황이 한 겹 더 복잡해집니다. 원본 서버는 새 파일을 들고 있는데 앞단 캐시가 옛 사본을 붙들고 있으면, 브라우저에게는 여전히 304 Not Modified가 돌아옵니다. 이때는 브라우저 캐시가 아니라 앞단 캐시를 비워야 해결됩니다.
실무에서 가장 확실한 대응은 파일 이름에 버전 값을 붙이는 방식입니다. 스타일시트를 style.css 대신 style.a91f3c.css처럼 내용이 바뀔 때마다 다른 이름으로 배포하면, 브라우저는 이를 새 자원으로 인식해 조건부 요청 자체를 하지 않습니다.
캐시 정책이 잘못 잡혔을 때 나타나는 증상
HTML 문서에까지 긴 max-age가 걸려 있으면 사용자는 며칠 전 화면을 계속 보게 됩니다. HTML은 매번 검증하도록 no-cache를 주고, 이름에 해시가 붙은 정적 파일에만 긴 캐시를 주는 구성이 일반적입니다.
반대로 모든 응답에 no-store가 붙어 있으면 304 Not Modified는 전혀 나타나지 않고 매번 전체 파일이 전송됩니다. 페이지가 무거워지고 재방문 속도가 눈에 띄게 느려지므로, 민감한 개인 정보를 담은 응답이 아니라면 no-store는 피하는 편이 좋습니다.
로그인 상태에 따라 내용이 달라지는 페이지에 캐시가 걸리면 다른 사용자의 화면이 노출될 위험도 있습니다. 이런 응답에는 Cache-Control에 private를 명시해 공유 캐시가 저장하지 못하도록 막아야 합니다.
개발자 도구에서 304를 확인하는 방법
브라우저에서 F12를 눌러 개발자 도구를 열고 Network 탭을 선택한 뒤 페이지를 새로 고치면 요청 목록이 채워집니다. Status 열에서 304 Not Modified를 찾아 클릭하면 오른쪽에 요청 헤더와 응답 헤더가 나타납니다.
요청 헤더에 If-None-Match 또는 If-Modified-Since가 있는지 먼저 확인합니다. 둘 다 없다면 조건부 요청이 아니므로 캐시 헤더 설정부터 점검해야 합니다. 응답 헤더에서는 Cache-Control과 ETag 값을 함께 봅니다.
Disable cache 항목에 체크하면 브라우저는 캐시를 무시하고 매번 전체 파일을 받습니다. 수정 사항이 반영되는지 확인할 때 이 항목을 켜 두면, 문제의 원인이 브라우저 캐시인지 서버 쪽인지 빠르게 갈라낼 수 있습니다.
브라우저를 거치지 않고 응답 헤더만 확인하고 싶다면 터미널에서 조건부 요청을 직접 보내 보는 방법이 있습니다. 아래는 ETag 값을 실어 보내 304 Not Modified가 돌아오는지 확인하는 예시입니다.
curl -I https://example.com/assets/style.css
curl -I -H 'If-None-Match: "a1b2c3d4"' https://example.com/assets/style.css첫 줄은 현재 응답 헤더와 ETag 값을 확인하는 명령이고, 둘째 줄은 그 값을 조건부 요청으로 되돌려 보내는 명령입니다. 응답 첫 줄에 304가 찍히면 서버가 검증을 정상적으로 처리하고 있다는 뜻입니다. 계속 200이 나온다면 ETag나 Last-Modified가 응답에 포함되지 않았을 가능성이 큽니다.
명령 결과를 파일로 남겨 두면 배포 전후를 비교하기 쉽습니다. 브라우저 화면은 확장 프로그램이나 서비스 워커의 영향을 받지만, 터미널에서 보낸 요청은 그런 변수 없이 서버 응답만 보여 줍니다.
브라우저마다 304 처리 방식이 다른가
조건부 요청과 304 Not Modified는 HTTP 표준에 정의된 동작이므로 크롬, 엣지, 파이어폭스, 사파리 모두 같은 원칙을 따릅니다. 다만 캐시를 얼마나 오래 보관하고 언제 검증할지에 대한 내부 판단은 브라우저마다 조금씩 다릅니다.
대표적인 차이는 뒤로 가기 버튼을 눌렀을 때의 동작입니다. 일부 브라우저는 페이지 상태를 통째로 보관해 두었다가 그대로 복원하므로 네트워크 요청 자체가 발생하지 않습니다. 이때는 Network 탭에 아무것도 기록되지 않아 304를 확인할 수 없습니다.
모바일 브라우저는 데이터 절약을 위해 캐시를 더 적극적으로 활용하는 경향이 있습니다. 같은 주소인데 데스크톱에서는 새 화면이 보이고 휴대전화에서는 옛 화면이 보인다면, 브라우저 차이보다 캐시 보관 기간 차이를 먼저 의심하는 편이 맞습니다.
확인이 필요할 때는 시크릿 창을 활용합니다. 시크릿 창은 별도의 캐시 공간을 사용하므로 첫 접속에서는 304 Not Modified가 나타나지 않고 모든 자원이 200으로 내려옵니다. 여기서 화면이 정상이면 캐시가 원인이라는 판단이 서게 됩니다.
프록시와 CDN이 끼어들 때의 캐시 흐름
실제 서비스에서는 브라우저와 원본 서버 사이에 여러 단계의 캐시가 놓입니다. 회사 네트워크의 프록시, 통신사 캐시, CDN 엣지 서버가 각각 사본을 들고 있을 수 있습니다. 브라우저가 받은 304 Not Modified가 어느 단계에서 만들어졌는지에 따라 대응이 달라집니다.
응답 헤더에 남는 흔적을 읽으면 구분에 도움이 됩니다. CDN은 대개 자체 헤더로 적중 여부를 표시합니다. 값이 적중으로 표시되어 있다면 원본 서버까지 요청이 가지 않았다는 뜻이므로, 원본만 갱신해서는 화면이 바뀌지 않습니다.
공유 캐시는 여러 사용자가 함께 쓰기 때문에 잘못 저장되면 파급이 큽니다. 로그인 여부에 따라 내용이 달라지는 응답에는 반드시 private를 지정하고, 개인화된 페이지는 캐시 대상에서 제외하는 규칙을 먼저 세워 두어야 합니다.
배포 직후에는 앞단 캐시를 명시적으로 비우는 절차를 함께 수행합니다. 대부분의 CDN은 경로 단위 또는 전체 단위 무효화 기능을 제공합니다. 무효화 후에도 옛 화면이 보인다면 그때 브라우저 캐시를 의심하면 됩니다.
서버 종류별 캐시 헤더 설정 위치
아파치를 사용하는 환경에서는 설정 파일이나 .htaccess에서 mod_expires와 mod_headers 모듈로 캐시 헤더를 지정합니다. 확장자별로 유효 기간을 다르게 주는 구성이 일반적이며, HTML에는 짧게, 해시가 붙은 정적 파일에는 길게 주는 방식이 무난합니다.
엔진엑스에서는 location 블록 안에서 expires 지시어와 add_header로 Cache-Control을 지정합니다. ETag는 기본적으로 켜져 있으므로 여러 대를 함께 운영한다면 값이 서버마다 달라지지 않는지 확인이 필요합니다.
워드프레스는 캐시 플러그인이 이 설정을 대신 관리하는 경우가 많습니다. 플러그인의 브라우저 캐시 항목에서 유효 기간을 조정할 수 있고, 배포 후에는 플러그인 캐시를 먼저 비워야 304 Not Modified가 갱신된 파일 기준으로 다시 계산됩니다.
어느 환경이든 설정을 바꾼 뒤에는 실제 응답 헤더를 다시 확인하는 절차가 필요합니다. 설정 파일에 적어 둔 값과 브라우저가 받는 값이 다른 경우가 생각보다 자주 있고, 그 차이는 대부분 앞단 캐시나 우선순위 규칙에서 비롯됩니다.
| 서버·구성 | 설정 위치 | 캐시 검증에 쓰이는 항목 | 주의할 점 |
|---|---|---|---|
| Apache | .htaccess 또는 httpd.conf | FileETag, ExpiresByType | 기본 ETag 값에 파일 정보가 섞임 |
| Nginx | nginx.conf의 server 블록 | etag, expires | 서버가 여러 대면 값이 어긋날 수 있음 |
| IIS | web.config의 staticContent | cacheControlMaxAge | 상위 구성에서 상속되는지 확인 |
| CDN·리버스 프록시 | 서비스 관리 화면 | Cache-Control 재작성 규칙 | 원본 서버 헤더를 덮어쓸 수 있음 |
| 워드프레스 캐시 플러그인 | 플러그인 설정 화면 | 브라우저 캐시 만료 항목 | 서버 설정과 중복 적용될 수 있음 |
가정 예시 — 실제 항목 이름은 서버 버전과 플러그인에 따라 다름
설정 위치를 확인할 때는 한 곳만 보지 말고 원본 서버부터 앞단 캐시까지 순서대로 내려오는 편이 좋습니다. CDN이 원본의 헤더를 덮어쓰고 있으면 서버 설정을 아무리 고쳐도 304 Not Modified가 나오지 않습니다.
여러 곳에서 같은 항목을 설정하고 있다면 하나만 남기고 정리하는 편이 안전합니다. 중복 설정은 서로 다른 만료 시간을 만들어 캐시 동작을 예측하기 어렵게 만듭니다.
304 Not Modified가 반복될 때의 점검 순서
아래 순서는 위에서부터 차례대로 확인하도록 정리한 것입니다. 앞 단계에서 원인이 드러나면 뒤 단계는 건너뛰어도 됩니다.
1단계 · 강력 새로 고침으로 브라우저 변수 걷어 내기
먼저 브라우저 쪽 캐시를 배제합니다. 개발자 도구를 열어 둔 상태에서 Disable cache 항목을 켜고 새로 고치면 조건부 요청 자체가 생략됩니다. 이때 화면이 정상으로 바뀐다면 서버가 아니라 브라우저 캐시가 원인입니다.
반대로 Disable cache를 켜도 화면이 그대로라면 304 Not Modified와는 무관한 문제입니다. 배포 실패나 서버 쪽 페이지 캐시를 먼저 살펴야 합니다.
2단계 · 응답 헤더에서 검증 값 확인
Network 탭에서 문제의 파일을 선택하고 Response Headers를 봅니다. ETag와 Last-Modified 중 하나라도 있어야 브라우저가 조건부 요청을 만들 수 있습니다. 둘 다 없으면 304 Not Modified는 애초에 나올 수 없습니다.
Cache-Control의 max-age 값도 함께 확인합니다. 값이 크게 잡혀 있으면 만료 전까지 서버에 묻지 않으므로 수정이 늦게 반영됩니다.
3단계 · 원본 서버 응답을 직접 확인
CDN이나 프록시를 우회해 원본 서버에 직접 요청해 봅니다. 원본은 새 파일을 주는데 앞단만 옛 파일을 준다면 캐시 무효화가 필요한 상황입니다.
원본에서도 옛 파일이 온다면 배포 자체가 반영되지 않은 것입니다. 이 경우에는 캐시 설정을 바꿔도 증상이 그대로 남습니다.
4단계 · 파일 이름과 경로에 버전 표시 붙이기
같은 경로에 같은 이름으로 배포하면 브라우저는 이전 자원과 같은 것으로 취급합니다. 파일 이름 뒤에 버전 문자열이나 해시를 붙이면 새 주소가 되어 캐시가 즉시 갈라집니다.
이 방식은 304 Not Modified를 없애는 것이 아니라, 바뀐 파일만 확실히 새로 받게 만드는 방법입니다. 바뀌지 않은 파일은 계속 캐시를 활용하므로 전송량도 늘지 않습니다.
5단계 · 서버와 플러그인 캐시 비우기
서버 쪽 페이지 캐시나 워드프레스 캐시 플러그인이 옛 HTML을 들고 있는 경우가 있습니다. 캐시를 비운 뒤 다시 확인하면 원인 범위를 한 단계 좁힐 수 있습니다.
캐시를 비웠는데도 같은 화면이 나온다면 브라우저가 아니라 중간 경로를 다시 살펴야 합니다.
6단계 · 다른 환경에서 재현되는지 확인
시크릿 창, 다른 브라우저, 다른 회선에서 같은 주소를 열어 봅니다. 특정 환경에서만 문제가 생긴다면 그 환경의 캐시나 확장 프로그램이 원인일 가능성이 큽니다.
모든 환경에서 같은 증상이 보인다면 서버나 CDN 쪽 설정을 확인하는 편이 빠릅니다.
내 상황에 맞는 304 Not Modified 판단 기준
아래 기준으로 자신의 상황을 먼저 분류하면 불필요한 설정 변경을 줄일 수 있습니다.
- 화면이 정상이고 304만 많다 — 정상입니다. 조치할 필요가 없습니다.
- 수정한 파일이 반영되지 않는다 — 파일 이름에 버전 값을 붙이거나 앞단 캐시를 비웁니다.
- 내 브라우저에서만 옛 화면이 보인다 — 강력 새로 고침으로 브라우저 캐시만 비워 확인합니다.
- 모든 방문자에게 옛 화면이 보인다 — CDN 또는 프록시 캐시 문제일 가능성이 큽니다.
- 304가 전혀 나타나지 않는다 — ETag와 Last-Modified가 응답에 포함되는지 확인합니다.
304 Not Modified를 확인하는 5단계 체크리스트
- Network 탭에서 해당 요청의 Status를 확인합니다. 304인지 disk cache인지 구분하는 것이 출발점입니다.
- 요청 헤더에 If-None-Match가 있는지 봅니다. 없다면 조건부 요청이 아니라 캐시 설정 문제입니다.
- 응답 헤더의 Cache-Control 값을 읽습니다. max-age, no-cache, private 중 무엇이 걸려 있는지 확인합니다.
- Disable cache를 켜고 다시 새로 고칩니다. 이때 화면이 정상이면 원인은 브라우저 캐시입니다.
- 다른 기기나 시크릿 창에서 같은 주소를 엽니다. 여기서도 옛 화면이면 서버 또는 CDN 캐시가 원인입니다.
304 Not Modified에서 흔히 생기는 오해 3가지
첫 번째, 304를 오류로 보는 시각입니다. 상태 코드 300번대는 오류가 아니라 리다이렉션과 조건부 응답을 담당하는 구간입니다. 개발자 도구가 304를 회색으로 표시하는 것도 실패가 아니라 본문이 없다는 뜻입니다.
두 번째, 새로 고침 한 번이면 캐시가 모두 지워진다는 생각입니다. 일반 새로 고침은 조건부 요청을 보낼 뿐이라 304 Not Modified가 그대로 돌아옵니다. 캐시를 무시하려면 강력 새로 고침이나 개발자 도구의 Disable cache가 필요합니다.
세 번째, 캐시를 끄면 문제가 사라진다는 판단입니다. 캐시를 전면 해제하면 증상은 가려지지만 페이지 속도와 서버 부하가 함께 나빠집니다. 원인을 찾아 캐시 정책을 조정하는 쪽이 결과적으로 안전합니다.
304 Not Modified 자주 묻는 질문
304가 많으면 검색 순위에 영향이 있나요
직접적인 감점 요인은 아닙니다. 오히려 조건부 요청이 잘 동작하면 페이지 로딩이 빨라져 사용자 경험 지표에 유리하게 작용합니다. 다만 HTML 문서까지 과도하게 캐시되어 새 내용이 노출되지 않으면 색인 갱신이 늦어질 수 있습니다.
강력 새로 고침은 어떻게 하나요
윈도우에서는 Ctrl과 F5를 함께 누르거나 Ctrl과 Shift를 누른 채 R을 누릅니다. 이 조작은 캐시를 무시하고 모든 자원을 다시 받으므로, 결과에 304 Not Modified 대신 200이 표시됩니다.
이미지에만 304가 뜨고 CSS에는 뜨지 않습니다
파일 종류별로 캐시 정책이 다르게 설정된 경우입니다. 웹 서버 설정이나 CDN 규칙에서 확장자별 max-age를 따로 지정하는 일이 흔합니다. 응답 헤더를 확장자별로 비교해 보면 차이가 바로 드러납니다.
워드프레스에서도 같은 방식으로 확인하나요
같습니다. 다만 캐시 플러그인이나 호스팅 자체 캐시가 한 겹 더 있는 경우가 많아, 브라우저 캐시를 비워도 변화가 없다면 플러그인 캐시부터 비워야 합니다.
ETag를 꺼야 한다는 말도 있던데 맞나요
서버가 여러 대인 환경에서 ETag가 서로 다르게 계산될 때 나오는 조언입니다. 단일 서버 환경이라면 굳이 끌 이유가 없습니다. 끄기보다 생성 규칙을 통일하는 쪽이 더 나은 선택입니다.
304인데 화면이 깨져 보입니다
이 경우 원인은 캐시가 아니라 캐시된 사본 자체가 옛 버전이라는 데 있습니다. 파일 이름에 버전 값을 붙여 새 자원으로 배포하면 해결됩니다.
모바일에서만 옛 화면이 보입니다
모바일 브라우저의 캐시가 따로 유지되기 때문입니다. 해당 기기에서 시크릿 모드로 접속해 화면이 정상이면 캐시가 원인이라고 판단할 수 있습니다.
서비스 워커를 쓰면 304 Not Modified가 사라지나요
서비스 워커가 응답을 가로채면 Network 탭에 서비스 워커에서 처리했다는 표시가 나타납니다. 이때 브라우저는 서버에 조건부 요청을 보내지 않으므로 304 Not Modified도 나오지 않습니다. 서비스 워커의 캐시 전략을 먼저 확인해야 합니다.
이미지 파일에만 옛 화면이 오래 남습니다
이미지에는 보통 만료 시간이 길게 설정됩니다. 파일을 교체해도 이름이 같으면 브라우저가 한동안 서버에 묻지 않습니다. 이름에 버전을 붙이거나 만료 시간을 줄이는 편이 확실합니다.
배포 자동화에서 304를 확인할 수 있나요
배포 스크립트 마지막에 조건부 요청을 보내 응답 코드를 기록해 두면 됩니다. 새로 올린 파일에 대해 304 Not Modified가 돌아온다면 배포가 반영되지 않았다는 신호로 볼 수 있습니다.
편집팀 노트 — 304 Not Modified를 직접 따져보며 정리한 기준
이 글을 정리하면서 편집팀은 같은 파일을 여러 조건으로 바꿔 가며 응답을 관찰했습니다. 확인 과정에서 가장 자주 헷갈린 지점은 304 Not Modified와 disk cache 표시를 같은 것으로 보는 습관이었습니다.
두 표시는 서버 왕복 여부가 다르기 때문에 대응 방법도 달라집니다. 304가 보인다면 서버는 이미 요청을 받아 판단한 것이므로 서버 설정을 살펴야 하고, disk cache가 보인다면 만료 시간을 먼저 줄여야 합니다.
또 하나 정리해 둘 기준은 304 Not Modified 자체를 없애려 하지 않는다는 점입니다. 이 응답은 전송량을 줄여 주는 정상 동작이고, 문제는 응답이 아니라 바뀐 파일이 같은 주소를 그대로 쓰는 구조에 있습니다.
그래서 편집팀은 캐시를 끄는 방식보다 주소를 바꾸는 방식을 권합니다. 배포마다 파일 이름이 달라지면 브라우저는 새 자원으로 인식하고, 바뀌지 않은 파일은 계속 캐시를 사용합니다.
핵심 요약
304 Not Modified는 실패가 아니라 캐시가 유효하다는 확인 응답입니다. 브라우저에 사본이 있고, 유효 기간이 지났으며, 서버 검증 결과 내용이 같을 때 나타납니다. 화면이 정상이라면 그대로 두는 편이 성능에 유리합니다.
문제가 되는 경우는 수정한 파일이 반영되지 않을 때뿐입니다. 이때는 브라우저 캐시, 플러그인 캐시, CDN 캐시를 순서대로 갈라내고, 근본적으로는 파일 이름에 버전 값을 붙여 배포하는 방식으로 정리하면 됩니다. 이 글은 정보 제공을 위한 정리이며, 실제 적용은 사용 중인 서버 환경에 맞춰 확인하시기 바랍니다.
함께 보면 좋은 자료와 관련 글
- AI로 윈도우 오류 진단하는 방법 — 로그에서 실패 원인을 찾아내는 절차
- 윈도우 설정 최적화 가이드 — 브라우저와 시스템 환경 정리
- MDN 웹 문서 · 304 Not Modified
- MDN 웹 문서 · ETag 헤더
본문에 적은 헤더 이름과 조작 방법은 2026년 8월 기준으로 확인한 내용입니다.
Leek의 블로그 홈으로다른 속도 최적화와 문제 해결 가이드도 홈에서 모아 보실 수 있습니다.
