새로고침해도 어제 화면 그대로였던 접속주소: 캐시에 갇힌 최신주소를 되찾은 이틀

화요일 저녁, 평소처럼 열린 줄 알았던 접속주소

즐겨찾기에 넣어둔 주소를 눌렀을 때 화면은 어제와 똑같이 떴다. 상단 배너도, 공지 목록의 제목 순서도, 하단의 고객센터 안내 문구도 눈에 익은 그대로였다. 이상한 점은 딱 하나였는데, 로그인 칸에 정보를 넣고 버튼을 눌러도 아무 반응이 없었다는 것이다. 버튼이 눌린 듯한 효과만 잠깐 보이고 화면은 제자리에 머물렀다. 그때만 해도 서버 점검이 걸렸거나 접속자가 몰려서 잠깐 느려진 정도라고 생각했다.

사흘 전 지인에게서 주소가 바뀐 것 같다는 이야기를 들었던 기억이 났다. 그때는 내 화면이 멀쩡하게 열렸기 때문에 그냥 넘겼다. 이 판단이 이틀을 잡아먹은 원인이었다. 화면이 정상으로 보인다는 사실과 그 주소가 지금 살아 있다는 사실은 전혀 다른 이야기였고, 나는 둘을 같은 것으로 착각하고 있었다. 사람은 눈에 보이는 결과를 가장 강한 증거로 받아들이는데, 브라우저는 종종 그 눈에 보이는 결과를 스스로 만들어낸다.

이상한 신호는 속도였다: 0.3초 만에 완성된 페이지

다음 날 아침에 다시 열어보면서 처음으로 이상함을 느낀 건 속도였다. 평소 이 페이지는 배너 이미지가 늦게 채워져서 화면이 한 번 덜컹거리며 자리를 잡았는데, 그날은 주소를 누르자마자 완성된 화면이 통째로 나타났다. 체감으로 0.3초도 걸리지 않았다. 집 인터넷이 갑자기 빨라졌을 리는 없고, 오히려 다른 사이트는 평소와 같은 속도로 열리고 있었다. 한 페이지만 유독 빠르다면 그건 네트워크를 타고 온 화면이 아니라 기기 안에 저장돼 있던 화면일 가능성이 높다.

두 번째 신호는 시계였다. 페이지 상단에 표시되던 날짜 영역이 화요일에 봤던 날짜와 똑같았다. 새로고침을 눌러도 값이 바뀌지 않았다. 서버에서 새로 받아온 화면이라면 최소한 날짜나 접속자 수 같은 동적 표시는 달라져야 정상이다. 세 번째 신호는 스크롤을 내렸을 때 나온 공지 목록이었는데, 가장 위에 걸린 공지 번호가 며칠째 같은 번호에 멈춰 있었다. 이 세 가지가 겹치는 순간, 나는 이 화면을 인터넷에서 받아온 게 아니라는 쪽으로 생각을 옮겼다.

강력 새로고침과 시크릿창으로 갈라본 첫 갈림길

가장 먼저 한 일은 일반 새로고침이 아니라 캐시를 무시하는 새로고침이었다. 윈도우 기준으로 Ctrl과 Shift를 함께 누른 채 새로고침을 눌렀고, 맥에서는 Command와 Shift 조합을 썼다. 그래도 화면은 똑같이 떴다. 보통 이 단계에서 화면이 바뀌면 단순 캐시 문제로 끝나는데, 바뀌지 않는다는 건 더 깊은 층에 저장된 사본이 응답을 가로채고 있다는 뜻이었다. 이때부터는 브라우저 설정이 아니라 페이지가 심어둔 저장 장치를 의심해야 한다.

다음으로 시크릿창을 열어 같은 주소를 붙여넣었다. 결과는 완전히 달랐다. 화면은 30초 가까이 흰 상태로 멈춰 있다가 결국 연결할 수 없다는 오류 문구를 띄웠다. 같은 기기, 같은 망, 같은 글자의 주소인데 창을 하나 바꿨다고 결과가 갈렸다면 원인은 명백히 내 브라우저 쪽에 있다. 시크릿창은 기존 저장 사본을 공유하지 않기 때문에 이 비교 하나로 '주소가 죽었는지'와 '내 브라우저가 옛 화면을 보여주는지'를 단번에 나눌 수 있었다.

정리하면 화요일부터 내가 보고 있던 화면은 실제 접속의 결과가 아니었다. 주소는 이미 응답하지 않는 상태였고, 브라우저는 마지막으로 받아둔 화면을 꺼내 보여주며 아무 일도 없는 것처럼 굴고 있었다. 로그인만 되지 않았던 이유도 여기서 설명된다. 화면을 그리는 파일은 저장돼 있었지만 로그인 요청은 실제 서버로 나가야 했고, 나갈 곳이 사라진 요청은 조용히 실패했던 것이다.

브라우저가 아니라 '설치된 앱'이 문제였던 지점

강력 새로고침으로도 화면이 유지된 이유는 그 사이트를 몇 달 전 휴대폰 홈 화면과 PC 바탕화면에 바로가기 형태로 추가해 뒀기 때문이었다. 요즘 웹페이지는 브라우저 안에 작은 중계 프로그램을 심어 두고, 네트워크가 느리거나 끊겼을 때 미리 저장한 화면을 대신 내보내는 기능을 쓴다. 오프라인에서도 앱처럼 열리게 만드는 장치인데, 도메인이 바뀐 상황에서는 이 친절함이 그대로 함정이 된다. 접속이 끊긴 사실 자체를 사용자에게 숨겨 버리기 때문이다.

PC에서는 개발자 도구를 열어 저장소 항목을 확인했다. 등록된 중계 프로그램이 하나 살아 있었고, 저장된 파일 묶음의 생성 시각이 8일 전으로 찍혀 있었다. 숫자를 보는 순간 지인이 주소가 바뀐 것 같다고 말한 시점과 거의 맞아떨어진다는 걸 알았다. 휴대폰에서는 같은 도구를 쓰기 어려우니 대신 홈 화면 바로가기를 삭제하고 브라우저에서 주소를 직접 입력해 열어봤는데, 이쪽도 곧바로 오류 화면으로 바뀌었다.

다른 기기, 다른 망에서 같은 주소를 열어본 결과

원인을 내 기기 안으로 좁혔더라도 한 번은 바깥에서 확인해야 한다. 같은 주소를 한 번도 연 적 없는 태블릿에서 열어봤고, 여기서는 캐시가 있을 수 없으니 결과가 바로 나왔다. 화면은 뜨지 않았고 서버를 찾을 수 없다는 메시지가 떴다. 이어서 휴대폰 데이터로 망을 바꿔 다시 시도했지만 같은 결과였다. 기기 두 대와 망 두 개에서 동일하게 실패했다면 주소 자체가 응답하지 않는다고 결론 내려도 무리가 없다.

이 교차 확인이 없으면 엉뚱한 곳으로 샌다. 집 공유기의 차단 설정이나 통신사 망 정책 때문에 특정 주소만 막히는 경우도 실제로 있기 때문이다. 그런 경우라면 다른 망에서는 멀쩡히 열려야 한다. 반대로 어떤 환경에서도 똑같이 실패하면 남는 설명은 도메인이 내려갔거나 옮겨 갔다는 것뿐이다. 기기 두 대와 서로 다른 망 두 개, 이 정도만 대조해도 판단의 정확도는 크게 올라간다.

화면 속 날짜와 공지 번호로 캐시 시점을 역산하다

내 화면이 언제 멈춘 것인지 알아야 그 사이에 무슨 일이 있었는지 추적할 수 있다. 저장된 파일의 생성 시각이 8일 전이라는 정보 외에, 화면 자체에도 시점을 알려주는 흔적이 남아 있었다. 공지 목록의 맨 위 글 번호가 1442번에서 멈춰 있었고, 하단 안내 문구에 적힌 갱신 날짜도 8일 전 날짜였다. 두 숫자가 같은 날을 가리킨다면 그 시점 이후로 내 브라우저는 바깥 세상과 아무 대화도 하지 않았다는 뜻이다.

캡처해 둔 화면이 있다면 이 역산은 더 쉬워진다. 나는 마침 지난달에 공지 화면을 캡처해 둔 게 있었는데, 그때 번호가 1428번이었다. 한 달 사이 14개가 올라왔으니 대략 이틀에 하나꼴이다. 멈춘 번호가 1442번이라면 화면이 굳은 시점은 캡처일로부터 약 4주 뒤, 즉 8일 전과 어긋나지 않는다. 이렇게 두 가지 방법으로 같은 날짜가 나오면 추정이 아니라 확인이 된다.

도메인은 이미 바뀌어 있었다: 확인 경로를 되짚기

시점을 잡고 나니 그 다음은 단순했다. 평소 참고하던 주소 안내 글 두 곳을 열어 보니 한 곳은 9일 전에 새 주소를 올려두고 있었고, 다른 한 곳은 여전히 옛 주소를 걸어 둔 채였다. 두 곳의 안내가 갈릴 때는 늦게 갱신된 쪽을 의심하는 게 순서다. 새 주소를 올린 글의 수정 이력을 보니 본문 아래에 변경 사유와 시각이 함께 적혀 있었고, 그 시각이 내 화면이 굳은 날과 하루 차이였다.

후보 주소를 손에 넣었다고 바로 쓰지는 않았다. 등록 정보 조회로 생성일을 확인했더니 11일 전에 만들어진 도메인이었고, 인증서 발급 기록도 같은 주에 잡혀 있었다. 도메인 교체 직후라면 이 정도 신선함은 자연스럽다. 다만 신선하다는 건 진짜라는 증거가 아니라 사칭 주소도 똑같이 갖는 특징이므로, 옛 주소에서 쓰던 파비콘과 페이지 구조, 고객센터 표기 방식이 이어지는지까지 눈으로 맞춰봤다.

캐시를 지우고 최신주소로 갈아타기까지

갈아타는 작업은 지우는 순서가 중요하다. 먼저 홈 화면과 바탕화면의 바로가기를 삭제했고, 브라우저 설정에서 해당 사이트의 저장 데이터를 개별적으로 삭제했다. 전체 기록을 통째로 비우면 다른 사이트 로그인까지 전부 풀려 불편해지니 사이트 단위 삭제를 쓰는 편이 낫다. 그 다음 브라우저를 완전히 종료했다가 다시 열었는데, 중계 프로그램은 창이 하나라도 남아 있으면 해제되지 않는 경우가 있어 이 단계를 건너뛰면 지운 게 되살아난다.

정리가 끝난 뒤 옛 주소를 다시 열어보니 이번엔 곧바로 오류 화면이 떴다. 캐시가 실제로 걷혔다는 확인이다. 그제야 즐겨찾기에서 옛 항목을 지우고 새 주소를 등록했는데, 이름을 그냥 사이트 이름으로 두지 않고 뒤에 등록한 날짜를 붙였다. 다음에 또 화면이 이상할 때 이 날짜만 보면 내가 언제부터 이 주소를 쓰고 있었는지 바로 계산이 된다.

같은 일이 반복되지 않도록 바꾼 두 가지 습관

첫째, 홈 화면 바로가기로 들어가는 방식을 접었다. 앱처럼 열려서 편하긴 했지만 주소창이 보이지 않는다는 점이 결정적인 단점이었다. 지금 내가 어느 주소에 있는지 확인할 수 없는 상태로 매일 들어가고 있었던 셈이다. 대신 브라우저 즐겨찾기 막대에 올려두고 열 때마다 주소창의 글자를 한 번씩 읽는 쪽으로 바꿨다. 0.5초 더 걸리는 대신 이번 같은 이틀을 날리지 않는다.

둘째, 일주일에 한 번은 시크릿창으로 같은 주소를 열어본다. 저장 사본을 거치지 않는 경로로 한 번씩 찔러보는 것만으로 캐시에 가려진 변화가 곧바로 드러난다. 시간은 10초면 충분하고, 결과가 평소와 다르면 그때부터 확인에 들어가면 된다. 이 습관을 들이고 나서는 주소가 바뀌었다는 소식을 남에게 듣기 전에 내가 먼저 알아채는 일이 생겼다.

체크리스트에는 잘 안 적히는 한 가지

주소를 확인하는 방법을 다룬 글은 대체로 '화면이 안 열릴 때'를 전제로 한다. 그런데 이번 경우처럼 화면이 멀쩡히 열리는데도 실제로는 접속이 끊겨 있는 상태가 존재한다. 이 구간이 위험한 이유는 사용자가 아무 의심도 하지 않는다는 데 있다. 화면이 열리니 확인할 이유가 없고, 확인하지 않으니 며칠이 지나며, 그동안 검색 결과와 커뮤니티에는 옛 주소를 노린 유사 주소가 자리를 잡는다.

그래서 나는 판단 기준을 화면이 아니라 반응으로 옮겼다. 로그인이 되는지, 검색 기능이 동작하는지, 페이지에 표시된 시각이 실제 시각과 맞는지 같은 것들은 서버와 대화해야만 나오는 결과라서 캐시가 흉내 내지 못한다. 화면은 저장할 수 있어도 응답은 저장할 수 없다는 차이가 이번 사례의 핵심이었다. 접속이 이상하다 싶을 때 눈으로 화면을 훑는 대신 서버가 답해야만 되는 동작을 하나 눌러보는 것, 이틀을 헤맨 뒤 남은 건 이 습관 하나였다.