옛 접속주소가 되살아나는 자동완성·아이콘 잔재 지우고 최신주소 하나로 모으기

새 주소를 저장했는데도 옛 도메인이 열리던 3주

지난겨울에 들은 사례 하나를 처음부터 끝까지 따라가 본다. 이용자 K는 자주 들르던 사이트의 도메인이 바뀐다는 공지를 확인하고, 그날 바로 새 접속주소를 즐겨찾기에 넣었다. 여기까지는 흠잡을 데가 없다. 그런데 이후 3주 동안 그가 접속을 시도한 열두 번 가운데 다섯 번은 예전 도메인이 열렸다. 주소모음을 새로 정리해 놓고도 손은 옛 주소로 향한 것이다. 본인은 새 주소를 눌렀다고 기억했지만, 실제로 열린 페이지의 주소창 끝자리는 바뀌기 전 값이었다.

K가 이상하다고 느낀 계기는 화면이 아니라 속도였다. 옛 주소 쪽이 유독 빨리 뜨고 상단 배너가 예전 그대로였다. 그는 서버가 불안정한가 보다 하고 새로고침만 반복했다. 접속 이상을 일단 서버 탓으로 돌리는 이 습관이 문제를 3주나 끌었다. 주소창 문자열을 한 번만 끝까지 읽었다면 첫날에 끝났을 일이다. 뒤늦게 캡처를 확인해 보니 도메인 끝 숫자가 새 주소의 03이 아니라 예전 값인 12로 남아 있었다.

이 글은 그 3주를 원인별로 분리해 하나씩 걷어낸 기록이다. 결론부터 말하면 범인은 하나가 아니라 다섯이었다. 주소창 자동완성, 모바일 홈 화면 아이콘, 메신저 대화방에 남은 옛 링크, 회사 PC의 오래된 즐겨찾기 폴더, 그리고 기기 간 동기화. 하나씩은 사소하지만 다섯이 번갈아 작동하면 아무리 최신주소를 정확히 받아와도 접속의 절반은 과거로 돌아간다.

버려진 접속주소가 위험해지는 정확한 시점

도메인 변경 자체는 흔한 일이고, 변경 직후의 옛 주소는 대체로 아무것도 뜨지 않는 빈 페이지다. 문제는 소유권이다. 등록이 만료되면 보통 30일 안팎의 갱신 유예가 붙고, 그 뒤 삭제 대기 기간을 지나 누구나 다시 등록할 수 있는 상태가 된다. 변경 공지로부터 두세 달이면 그 주소는 완전한 남의 땅이 된다는 뜻이다. 흔한 gTLD 등록비가 연 1만~2만 원대이니, 하루 수백 건의 잔존 트래픽만 남아 있어도 주워 갈 값어치가 있는 먹잇감이 된다.

K의 옛 도메인도 그 경로를 그대로 밟았다. 처음 2~3주는 접속 오류, 그다음에는 광고만 깔린 파킹 페이지, 공지로부터 약 7주 뒤에는 예전과 거의 같은 배치의 로그인 화면이 떴다. 세 번째 단계가 가장 위험하다. 화면이 익숙하니 의심이 생기지 않고, 아이디와 비밀번호를 넣는 순간 그 조합은 다른 서비스에서 곧바로 재시도된다. 잔재 청소의 실질적 마감 기한이 변경 당일이 아니라 그 이후 한두 달인 이유가 여기 있다.

옛 주소로 들어가는 문이 몇 개인지부터 센다

첫 작업은 청소가 아니라 목록화였다. K에게 이틀 동안 접속할 때마다 어떤 경로로 눌렀는지 그 자리에서 메모하게 했다. 기억에 의존하면 즐겨찾기 하나만 떠올리지만, 실제 기록은 전혀 달랐다. 데스크톱 주소창 직접 입력 5회, 모바일 홈 화면 아이콘 3회, 메신저 대화방 링크 2회, 회사 PC 즐겨찾기 1회, 검색 결과 클릭 1회. 눈에 보이는 즐겨찾기만 손보면 나머지 열두 개 중 일곱 개의 문은 그대로 열려 있는 셈이었다.

이 이틀치 메모가 이후 작업 순서를 정해 주었다. 사용 빈도가 높은 문부터 닫아야 체감 효과가 빠르기 때문이다. 자주 쓰는 경로 두 개를 먼저 정리하자 옛 주소 접속 빈도가 절반 아래로 떨어졌고, 남은 경로는 여유 있게 처리할 수 있었다. 반대로 잘 안 쓰는 기기부터 손대면 시간은 시간대로 들고 증상은 그대로여서 중간에 포기하기 쉽다.

자동완성은 왜 새 주소에 1순위를 내주지 않는가

주소창 자동완성 순위는 대체로 방문 빈도와 최근성을 합친 점수로 매겨진다. K의 옛 주소는 8개월 동안 200회 넘게 방문한 기록이 쌓여 있었고, 새 주소는 나흘간 4회가 전부였다. 두 글자만 입력해도 목록 맨 위에 오르는 쪽은 당연히 옛 주소다. 그 상태에서 습관대로 두 글자를 치고 엔터를 누르면, 본인은 새 주소를 골랐다고 믿으면서 예전 도메인으로 들어간다. K가 겪은 다섯 번 중 세 번이 이 경우였다.

해결은 방문기록 전체 삭제가 아니라 개별 항목 제거다. 자동완성 목록에서 해당 항목에 커서를 올린 뒤 삭제 단축키를 쓰면 그 항목만 사라지고, 모바일 브라우저는 목록 항목을 길게 눌러 삭제를 고를 수 있다. 기록을 통째로 지우면 다른 사이트 로그인과 검색 편의까지 날아가서, 다음번에 또 청소해야 할 때 손이 무거워진다. 지워야 할 대상은 딱 하나, 옛 도메인 문자열이 포함된 항목뿐이다.

다만 항목을 지워도 타이핑 습관이 남으면 며칠 만에 비슷한 상황이 재현된다. 새 도메인의 앞 글자가 옛것과 겹치면 다시 헷갈리기 때문이다. K에게는 주소창 입력을 아예 중단하고 즐겨찾기 바의 항목을 클릭하는 방식으로 바꾸게 했다. 손가락이 기억하는 경로를 없애는 편이, 매번 목록을 읽고 판단하는 것보다 확실히 낫다.

홈 화면 아이콘이 박제해 둔 주소

모바일에서 홈 화면에 추가한 아이콘은 만들던 시점의 주소를 그대로 붙들고 있다. 겉에 보이는 것은 사이트 이름 라벨뿐이라, 아이콘만 봐서는 그 안에 어떤 주소가 들어 있는지 알 수 없다. K의 아이콘은 8개월 전에 만든 것이었고, 세 번의 잘못된 접속이 전부 이 아이콘에서 나왔다. 눌러서 열린 뒤 주소창을 확인하는 것 말고는 내용물을 볼 방법이 사실상 없다는 점이 이 경로의 함정이다.

그래서 아이콘은 수정이 아니라 삭제 후 재생성이 원칙이다. 새로 만들 때 이름 앞에 저장 날짜를 붙여 0413-약칭 형태로 적어 두면, 다음 도메인 변경 때 이 아이콘이 언제 만들어진 것인지 한 번에 판단된다. 날짜 접두가 없으면 6개월 뒤의 자신은 그 아이콘을 믿어야 할지 말지를 또 처음부터 확인해야 한다.

대화방과 메모에 남아 있는 링크모음

메신저 대화방은 사실상 영구 보관소다. 반년 전에 공유한 링크가 검색 한 번으로 다시 올라오고, 그때 붙은 미리보기 카드에는 예전 화면의 제목과 썸네일이 그대로 남아 있다. 카드가 멀쩡해 보이니 눌러도 된다고 판단하기 쉽다. 미리보기 카드는 링크를 처음 보낸 시점에 저장된 캐시여서, 현재 그 주소가 무엇을 보여 주는지와는 아무 상관이 없다.

K는 대화방 검색창에 옛 도메인 문자열을 넣어 4건을 찾아냈다. 본인이 보낸 2건은 삭제했고, 상대가 보낸 2건은 지울 수 없어서 그 아래에 주소가 바뀌었다는 메시지를 새로 남겨 두었다. 같은 방식으로 메모 앱과 메일함까지 같은 문자열로 검색하자 3년 전 메모에서 한 건이 더 나왔다. 검색어를 사이트 이름이 아니라 도메인 문자열로 잡는 것이 핵심이다. 이름으로 검색하면 잡담까지 딸려 나와 금방 지친다.

주소는 맞는데 옛 화면이 뜨는 착시

여기까지 정리했는데도 K는 두 번 더 예전 화면을 봤다. 이번에는 주소창 문자열이 새 주소로 정확히 찍혀 있었다. 로컬 캐시가 만든 착시다. DNS 응답은 보통 300초에서 86400초 사이의 TTL 동안 재사용되고, 브라우저와 공유기가 각각 예전 결과를 들고 있으면 새 주소를 입력해도 한동안 옛 목적지로 향할 수 있다. HSTS 정책이 1년 단위로 걸려 있으면 프로토콜 전환까지 자동으로 이뤄져 더 헷갈린다.

구분법은 간단하다. 시크릿 창에서 같은 주소를 한 번, 와이파이를 끄고 모바일 데이터로 한 번 더 열어 본다. 두 결과가 다르면 내 기기의 캐시 문제이고, 셋 다 같은 화면이면 주소 자체를 다시 확인해야 한다. K의 경우 시크릿 창에서는 정상적인 새 화면이 떴고, 브라우저를 완전히 종료했다 켠 뒤에는 일반 창에서도 같은 화면이 나왔다. 이 확인에 든 시간은 5분이었다.

정본 하나만 남기고 나머지를 지운다

흩어진 문을 다 닫은 뒤에 한 일은 항목을 하나로 좁히는 것이었다. 즐겨찾기 바 맨 앞에 대괄호로 저장 날짜를 적은 항목 하나를 두고, 다른 폴더에 흩어져 있던 유사 항목 여섯 개를 전부 삭제했다. 항목이 둘 이상이면 접속할 때마다 어느 쪽이 최신인지 판단해야 하는데, 그 판단은 급할 때 늘 대충 이뤄진다. 하나만 남기면 판단할 일 자체가 사라진다.

갱신 방식도 바꿨다. 다음번에 주소가 바뀌면 새 즐겨찾기를 추가하는 대신 정본 항목의 URL을 편집한다. 추가하는 습관이 바로 중복의 출발점이기 때문이다. 정본 항목 이름에는 확인한 날짜를, 메모란에는 그 주소를 어디에서 받았는지를 한 줄로 적어 둔다. 두 달 뒤 이 주소가 맞는지 의심이 들 때 되짚을 근거는 그 한 줄뿐이다.

동기화가 되살려 놓은 즐겨찾기

3주 뒤 재점검에서 지웠던 항목 하나가 되살아나 있었다. 원인은 오랜만에 켠 회사 PC였다. 그 브라우저는 정리 이전 상태를 그대로 들고 있다가 로그인과 동시에 계정에 병합해 버렸고, 삭제했던 옛 주소 항목이 개인 노트북까지 다시 내려왔다. 계정 동기화를 쓰는 이상 정리는 한 기기가 아니라 계정 단위의 작업이다.

대책은 정리 전에 로그인된 기기를 전부 적어 두는 것이다. K는 노트북, 휴대폰, 태블릿까지 3대를 정리했지만 두 달에 한 번 켜는 회사 PC를 빼먹었다. 그리고 정리 사흘 뒤, 각 기기의 즐겨찾기 검색창에 옛 도메인 문자열을 넣어 결과가 0건인지 확인하는 절차를 추가했다. 이 확인은 기기당 20초면 끝나지만, 빠뜨리면 몇 주치 작업이 조용히 되돌아온다.

4주 뒤의 숫자, 그리고 다음 변경

정리를 마친 뒤 4주 동안 K가 접속을 시도한 횟수는 서른 번 남짓이었고, 옛 주소로 들어간 경우는 없었다. 전부 정본 항목 하나를 거쳤다. 전체 작업에 든 시간은 캐시 확인과 기기 점검을 포함해 40분 정도였다. 처음이라 오래 걸렸을 뿐, 문 목록을 이미 만들어 둔 다음 변경 때는 10분이면 같은 작업이 끝난다.

남은 함정은 분명하다. 지금의 최신주소도 언젠가 또 바뀐다. 잔재 청소는 한 번 끝내는 이벤트가 아니라 변경이 있을 때마다 반복하는 짧은 절차다. 그래서 K는 정본 항목 메모란에 이번에 닫은 문 다섯 개를 순서대로 적어 두었다. 다음번에는 그 순서를 그대로 다시 밟기만 하면 된다.

정리를 마치고 K가 한 말은 조금 뜻밖이었다. 가장 서늘했던 건 가짜 로그인 화면이 아니라, 3주 동안 자기가 어디에 접속하고 있었는지 스스로 몰랐다는 사실이라고 했다. 주소를 새로 받는 일보다 옛 주소를 지우는 일이 늘 뒤로 밀리는 이유도 거기에 있다. 지우는 쪽은 티가 나지 않기 때문이다.