사이트를 고쳤는데 왜 아직 예전 버전이 보일까요?

사이트는 정상입니다. 그 앞에 있는 복사본이 오래됐습니다

배포하면 오리진, 즉 호스팅이 실제로 읽어 들이는 서버나 스토리지 버킷에 페이지의 새 버전이 기록됩니다. 그 과정이 방문자가 오리진과 대화하고 있다는 사실을 보장하지는 않습니다. 둘 사이에는 내 브라우저, 대개 CDN, 때로는 프레임워크가 설치한 서비스 워커, 드물게는 방문자 네트워크의 프록시까지 놓여 있습니다. 각각은 복사본과 그것을 얼마나 오래 신뢰할지에 대한 규칙을 갖고 있고, 각각은 누구에게도 확인하지 않고 요청에 응답합니다.

이 문제의 특징은 불일치입니다. 나에게는 새 페이지가 보이고 고객에게는 보이지 않습니다. 같은 주소인데 두 사람이 다른 버전을 받습니다. 배포도 하지 않았는데 한 시간 뒤에 저절로 해결됩니다. 이 패턴은 익혀 둘 가치가 있습니다. 진짜로 망가진 배포는 모두에게 동시에 망가지기 때문입니다. 그러니 일부 사람에게는 문제가 없다면 빌드 로그를 읽는 대신 누가 그 요청에 응답하고 있는지를 찾으세요. 첫 규칙 아래에 있는 또 하나의 규칙이 사람들을 놀라게 합니다. 많은 캐시는 만료될 때까지 복사본을 보관하는 데 그치지 않고, 뒤에서 새것을 받아 오는 동안 만료된 복사본을 계속 내줍니다. 만료는 사용 중지를 뜻하지 않고, 이것이 페이지가 자기 수명을 한참 넘겨 살아남는 방식입니다.

고치기 전에 계층을 찾으세요

아래 단계는 비용이 적게 드는 순서로 캐시를 하나씩 지워 나갑니다. 위에서부터 내려가다가 새 페이지가 나오는 첫 단계에서 멈추세요. 그것이 답이고, 해결책은 그 계층에서의 퍼지이며 또 한 번의 배포가 아닙니다.

1. 시크릿 창에서 열어 보세요. 거기서 새 버전이 보이면 예전 복사본은 내 브라우저 안에만 있었고 방문자는 아무도 영향을 받지 않았습니다. 평소 창에서 강력 새로고침하면 끝입니다. 가장 흔한 결말이면서 가장 자주 건너뛰는 단계이고, 그래서 소동이 버그보다 오래갑니다.
2. 의미 없는 쿼리 문자열을 붙이세요. 같은 주소 끝에 ?x=1 같은 것을 붙여 불러옵니다. 공유 캐시는 대개 이것을 다른 URL로 취급해 오리진까지 받아 옵니다. 여기서 새 페이지가 나오면 오리진은 정상이고, 나와 오리진 사이의 무언가가 원래 주소로는 예전 복사본을 계속 내주고 있다는 뜻입니다.
3. 다른 네트워크에서 열어 보세요. 사무실 와이파이가 아니라 모바일 데이터를 쓰는 휴대폰으로 엽니다. CDN은 지역마다 별도의 복사본을 두기 때문에, 이 단계가 엣지 한 곳만 오래된 것인지 모든 방문자가 오래된 것을 받고 있는지를 갈라 줍니다. 그리고 외부 사람이 실제로 보는 것을 반영하는 것은 이 단계뿐입니다.
4. 오리진에 직접 물어보세요. 호스팅 관리 화면이나 서버 측 미리보기, 또는 공개 주소가 아니라 오리진을 향한 요청으로 페이지를 받아 옵니다. 오리진이 정상이고 공개 URL이 잘못됐다면 문제는 전적으로 전달 계층에 있고, 코드나 빌드를 손봐도 움직이지 않습니다.

계층을 알아냈다면 거기서 퍼지하거나 무효화한 뒤, 내가 통제하지 않는 네트워크에서 세 번째 단계를 다시 실행하세요. 자기 컴퓨터에서 수정을 확인하는 것이, 퍼지가 듣지 않았는데도 들었다고 확신하게 되는 전형적인 경로입니다.

우리가 한 시간을 잃은 사례

우리는 고객의 페이지를 직접 호스팅하고 있어서, 이것은 독자의 문제일 뿐 아니라 우리 문제입니다. 2026년 9월 11일, 내렸다고 생각한 페이지가 내린 지 오십이 분이 지난 뒤에도 열어 보는 모든 사람에게 계속 제공되고 있는 것을 발견했습니다. 우리 쪽에서 볼 수 있는 것은 모두 정상이었습니다. 파일은 스토리지에서 사라졌고 내부 기록도 게시 해제 상태라고 표시했습니다. 그 앞에 있던 CDN이 뒤에서 재검증하는 동안 마지막 정상 복사본을 최대 하루까지 계속 내주도록 설정돼 있었던 것입니다. 즉 삭제됐다는 말은 우리 스토리지를 설명한 것이었고, 방문자가 받는 것에 대해서는 아무 말도 하지 않았습니다. 우리는 의도적으로 두 곳을 고쳤습니다. 하나는 CDN 설정에서 만료된 복사본을 아예 내주지 않도록 한 것이고, 다른 하나는 페이지 자체의 캐시 지시문이어서, 이 상한값이 다시 만든 백엔드라면 조용히 기본값으로 되돌려 놓을 설정 하나에만 의존하지 않게 했습니다.

여기서 얻은 규칙이 가져갈 만한 부분입니다. 게시했다, 수정했다, 삭제했다는 모두 오리진에 대한 주장입니다. 방문자가 받는 것은 별개의 사실이고, 그것을 정직하게 아는 방법은 낯선 사람과 같은 방식으로 페이지를 받아 오는 것뿐입니다. 같은 계층은 우리가 측정할 수 있는 것까지 바꿔 놓았습니다. 우리가 호스팅하는 페이지의 조회수는 총계가 아니라 하한으로 기록합니다. 엣지에서 응답된 요청은 집계하는 오리진에 영원히 닿지 않기 때문입니다. 게다가 만료 복사본 제공이 살아 있던 동안에는 우리 CDN 자신의 캐시 갱신 요청이 그 숫자의 대부분을 차지했고, 이름을 지정해 제외할 때까지 그랬습니다. 캐시는 사람들이 보는 것만 바꾸지 않습니다. 그들이 무엇을 봤는지에 대해 당신이 증명할 수 있는 범위까지 바꿉니다.

두 작업을 쓰는 방식도 바뀌었습니다. 게시는 파일을 먼저 올리고 기록을 나중에 합니다. 순서를 뒤집으면 아무것도 제공되지 않는데 게시 중이라고 기록하게 되기 때문입니다. 게시 해제는 파일을 먼저 지우고 기록에 표시를 나중에 합니다. 순서를 뒤집으면 아직 살아 있는 페이지를 내려갔다고 기록하게 되기 때문입니다. 뒷부분이 실패하면 우리가 보고하는 상태는, 틀려도 안전한 방향으로 틀립니다. 어느 실패가 그나마 나은지를 먼저 묻는 것이 웹사이트를 조심스럽게 운영한다는 말의 대부분이고, 그것은 AgentCeres, agentceres.com의 AI Growth Officer에 심어 둔 것과 같은 원칙입니다. 전문 역할로 이루어진 팀이 페이지와 게시물과 아웃리치의 초안을 쓰고, 외부로 나가는 작업은 기본값으로 사람의 승인을 기다립니다. 사이트를 처음 게시했다면 웹사이트를 AI로 만들어야 할까의 점검 항목이 이 글의 나머지 절반입니다.