야스코리아 접속 기록: 같은 페이지가 200과 304로 다르게 응답한 이유

야스코리아 홈이 정상으로 열렸는데도 같은 화면만 보인다면, 접속 성공 여부와 파일 버전을 나눠 봐야 해요. 실제 홈페이지에 조건을 바꿔 요청하니 200 → 304 → 200이 반복됐습니다. 두 200 응답은 본문이 같았고, 304에는 본문이 없었어요. 화면이 바뀌었는지를 상태 코드 하나로 판단하면 왜 헷갈리는지 보여 주는 결과입니다.

처음 눈에 띈 것은 페이지 크기보다 캐시 기간이었어요

당시 홈페이지 HTML은 2,499바이트였고, 응답에는 Cache-Control: public, max-age=2592000이 들어 있었어요. 2,592,000초를 86,400초로 나누면 30일입니다. 짧은 안내문이라도 캐시가 그 응답을 유효하다고 판단하는 동안 다시 사용할 수 있는 설정이에요.

여기서 30일은 “이 주소가 30일 동안 맞다”는 보증도, 글이 올라온 지 30일이라는 뜻도 아니에요. HTTP 캐시가 사본을 다시 써도 되는지 판단할 때 쓰는 시간값입니다. 또 이번 응답에는 Age가 없었으므로, 특정 브라우저에 남은 유효 시간을 이 숫자만으로 정확히 계산할 수는 없었어요. MDN의 max-age 설명도 응답의 나이와 유효 기간을 함께 보도록 설명합니다.

실제 수정 시각을 되돌려 보내자 304가 왔어요

첫 응답에는 ETag가 없었지만 Last-Modified는 있었어요. 그래서 없는 버전 태그를 만들어 넣지 않고, 서버가 보낸 수정 시각을 If-Modified-Since에 그대로 넣었습니다. 비교를 위해 그보다 훨씬 이른 날짜인 1970-01-01을 넣은 요청도 따로 보냈어요.

바이트 수는 수신한 HTML 본문만 센 값이에요. 응답 헤더, 연결 과정, CSS와 이미지는 포함하지 않았습니다. 같은 2,499바이트라고 크기만 비교한 것도 아니에요. 여섯 개의 200 응답은 SHA-256 해시가 모두 같아서 본문 바이트가 동일함을 확인했어요.

1. GET / — 날짜 조건 없음
   200 / 본문 2499 B
   Last-Modified: Sat, 17 Oct 2026 04:28:12 GMT

2. GET /
   If-Modified-Since: Sat, 17 Oct 2026 04:28:12 GMT
   304 / 본문 0 B

3. GET /
   If-Modified-Since: Thu, 01 Jan 1970 00:00:00 GMT
   200 / 본문 2499 B

세 번째 요청은 실제 방문자가 1970년 파일을 가지고 있다는 뜻이 아니에요. 비교 날짜만 바꿨을 때 응답이 달라지는지 확인하려고 넣은 대조 조건입니다. 전체 시각과 해시는 9회 요청 원본 JSON에서 볼 수 있어요.

0바이트였는데도 정상 응답인 이유

304는 조건부 요청에 대해 기존 사본을 재사용하도록 알리는 상태예요. 이때 서버가 새 본문을 다시 보내지 않는 것은 정상입니다. 브라우저가 저장해 둔 파일을 쓸 수 있기 때문에, 네트워크에서 받은 본문이 0바이트여도 화면은 보일 수 있어요. 이는 304 Not Modified의 동작과 맞습니다.

이번 측정 도구는 브라우저처럼 기존 HTML을 조합해 화면을 그리지 않았어요. 따라서 이 기록에서 직접 확인한 사실은 “304와 0바이트를 받았다”까지입니다. 실제 특정 휴대전화가 어떤 저장 파일을 화면에 썼는지는 그 기기의 네트워크 기록을 따로 봐야 해요.

또 조건을 빼고 다시 받으면 무조건 새 버전이 온다고 말할 수도 없어요. 이번 첫 번째와 세 번째 조건은 모두 200이었지만 본문은 같았습니다. 200은 본문을 받았다는 단서이고, 원하는 수정본인지 여부는 본문이나 버전 정보로 확인해야 해요.

CDN의 HIT도 “최신 내용 확인 완료”라는 뜻은 아니에요

아홉 응답의 CDN-Cache는 모두 HIT였어요. 이 값은 이번 전달 경로에서 캐시가 사용됐다는 단서입니다. 그 사본이 편집자가 방금 올린 파일과 일치하는지는 이 표지만으로 알 수 없어요. 내용이 오래됐다고 확정하는 표시도 아닙니다.

구분해야 할 사본은 적어도 두 곳에 있어요. 브라우저가 보관한 파일과 CDN이 보관한 파일입니다. 브라우저에서 다시 확인을 요청해도 외부 캐시에 있는 응답을 받을 수 있고, CDN을 갱신해도 이미 열린 탭의 화면은 그대로일 수 있어요. 그래서 업데이트 문제를 확인할 때는 “캐시를 지웠다”에서 끝내지 않고 공개 주소로 받은 본문이 원하는 수정본과 같은지까지 비교하는 것이 더 분명한 확인 방법입니다.

이번 업데이트에서도 기본 주소와 파일 주소가 달랐어요

이 원고의 첫 편집본을 실제로 올린 뒤, 방문자가 여는 /와 직접 파일을 가리키는 /index.html을 각각 요청했어요. 같은 홈을 보여 줘야 하는 두 주소인데, 기본 주소에는 이전의 ?from=yaskorea가 붙은 버튼 링크가 남아 있었고 파일 주소에는 그 매개변수를 뺀 링크가 들어 있었습니다. 둘 다 200이었어요.

갱신 전에는 수정 시각도 달랐어요. 기본 주소는 2026-10-17의 파일 시각을, 파일 주소는 2026-10-24의 시각을 돌려줬습니다. 관련 주소의 캐시를 갱신한 뒤에는 두 본문의 SHA-256 해시가 같은 값으로 바뀌었어요. 크기만 우연히 같아진 것이 아니라 같은 파일 내용을 받은 겁니다.

이 사례에서 필요한 확인은 방문자에게 계속 새로고침을 부탁하는 것이 아니었어요. 운영 쪽에서 실제 진입 주소와 파일 주소를 모두 열어 차이를 찾고, 갱신 뒤 두 응답을 다시 비교해야 했습니다. 다만 이 결과를 모든 사이트의 /와 /index.html이 늘 다르게 캐시된다는 규칙으로 일반화할 수는 없어요. 갱신 전후의 시각·수정 시각·해시 기록은 별도로 남겼습니다.

내 화면에 적용할 때는 이 순서로 좁혀 보세요

1. 바뀌었어야 하는 문장이나 링크 하나를 정하세요. 제목과 배경색은 업데이트 뒤에도 유지될 수 있어요. 확인 기준이 모호하면 같은 화면인지 새 화면인지 비교하기 어렵습니다.
2. 일반 새로고침 뒤에도 같다면, 데스크톱에서 강력 새로고침을 시도하세요. Windows의 Chrome·Edge에서는 Ctrl+Shift+R을 사용할 수 있어요. 이 동작은 캐시에 재확인을 요청하는 방법이지, 외부 사이트의 잘못된 링크를 고치는 기능은 아닙니다. 새로고침과 강력 새로고침의 차이를 참고할 수 있어요.
3. 확인이 더 필요하면 개발자 도구의 Network에서 문서 요청을 보세요. 상태 코드, Last-Modified, Cache-Control과 실제 Response 내용을 함께 비교하세요. 상태가 304라는 이유만으로 오류로 분류하지 마세요. 이 HTTP 기록에는 없던 브라우저 메모리 캐시·디스크 캐시 표시는 별도로 구분해야 합니다.
4. 문제가 버튼을 누른 뒤에 시작되면 도착 페이지를 따로 확인하세요. 출발 페이지는 최신이어도 목적지에서 이동하거나 실패할 수 있어요. 최종 주소와 오류 문구를 기록하면 출발 페이지의 갱신 문제와 섞이지 않습니다.

문제 범위가 확인되기 전에 전체 기록이나 모든 사이트 데이터를 지울 필요는 없어요. 먼저 실패한 페이지와 비교 기준을 좁히면 다른 사이트의 로그인 상태를 불필요하게 건드리지 않고 확인할 수 있습니다.

이번 비교가 바꾼 확인 기준

야스코리아 주소 안내를 점검할 때, 앞으로는 “페이지가 열렸다”와 “의도한 버전이 전달됐다”를 따로 확인하려고 해요. 이번 기록의 가장 유용한 부분은 30일이라는 큰 숫자보다, 똑같은 HTML이 어떤 조건에서는 다시 전송되고 어떤 조건에서는 전송되지 않았다는 점이었습니다. 상태 코드와 눈에 보이는 화면을 함께 봐야 하는 이유가 여기에 있어요.

이 글은 2026-10-17에 게시한 소개 글을 실제 HTTP 비교 기록으로 개정한 것입니다. 측정 시점의 홈페이지 본문은 이후 편집으로 달라질 수 있어요. 응답 속도, 지역별 접속률, 외부 콘텐츠 재생 여부에 대한 점수나 보장은 포함하지 않았습니다.