도메인이 바뀌었는데 자동입력이 뜬다면: 접속주소 변경과 저장정보 문답

주소모음에서 받은 새 접속주소를 열었더니 아이디 칸이 이미 채워져 있었다는 이야기를 자주 듣습니다. 어떤 사람은 그걸 보고 안심하고, 어떤 사람은 등골이 서늘해집니다. 둘 중 누가 맞을까요. 도메인 변경이라는 사건은 브라우저 안에 쌓여 있던 쿠키·자동입력·방문기록·캐시를 한꺼번에 흔들어 놓는데, 이 움직임을 모르면 정상인 현상을 이상하다고 의심하고 진짜 이상한 현상을 정상이라고 넘깁니다. 아래는 최신주소 교체 시기에 실제로 많이 나오는 질문들을 하나씩 답으로 풀어낸 기록입니다.

도메인이 바뀌면 이전 접속주소에 저장돼 있던 것들도 따라오나요

따라오지 않습니다. 브라우저가 값을 보관하는 단위는 사이트의 겉모습이 아니라 도메인이기 때문입니다. 쿠키는 발급한 도메인 이름에 묶여 저장되고, 다른 등록도메인으로 이동하면 전달 자체가 일어나지 않습니다. 예를 들어 이전 접속주소가 samplename21.com이고 새 주소가 samplename24.net이라면, 앞선 도메인에 30일 만료로 심겨 있던 로그인 유지 쿠키는 새 주소 쪽으로 단 한 바이트도 넘어가지 않습니다. 화면 디자인이 똑같고 로고가 같아도 브라우저 입장에서는 완전히 남남인 두 사이트입니다.

예외는 서브도메인만 바뀐 경우입니다. m1.samplename21.com에서 m2.samplename21.com으로 옮겨간 상황이라면, 쿠키가 상위 도메인 범위로 발급돼 있을 때 그대로 공유됩니다. 그래서 같은 도메인 변경이라도 등록도메인이 통째로 바뀐 이전인지, 서브도메인만 갈아끼운 이전인지를 먼저 구분해야 이후 현상들이 설명됩니다. 주소의 점을 오른쪽부터 두 칸 읽어 보는 습관, 그러니까 끝에서 두 번째 마디까지가 같은지만 확인해도 이 구분은 3초면 끝납니다.

덧붙이면 저장된 비밀번호와 자동입력 항목도 같은 원리로 도메인에 묶여 있습니다. 브라우저 비밀번호 관리자에는 사이트 이름이 아니라 주소가 키로 들어가 있어서, 새 도메인에서는 검색되지 않는 게 기본 동작입니다. 로컬스토리지, 세션스토리지, 서비스워커 캐시도 마찬가지로 도메인별 칸막이 안에 갇혀 있습니다.

새 접속주소를 열었더니 아이디가 자동으로 채워졌습니다. 정상인가요

앞의 원리대로면 새 등록도메인에서 자동입력이 뜨는 일은 일어나지 않아야 합니다. 그런데 실제로 뜬다면 가능성은 세 가지로 좁혀집니다. 첫째, 알고 보니 서브도메인만 바뀐 것이어서 브라우저가 같은 사이트로 인식한 경우. 둘째, 자동입력이 아니라 페이지 자체가 값을 미리 그려 넣은 경우. 셋째, 예전에 그 주소를 이미 방문해서 정보를 저장한 적이 있는 경우입니다.

문제는 두 번째입니다. 입력창에 회색 안내문이 아니라 검은 글씨로 아이디가 박혀 있고 클릭해도 목록이 뜨지 않는다면, 그건 브라우저가 채운 게 아니라 서버가 HTML에 값을 넣어 보낸 것일 수 있습니다. 복제 사이트가 방문자를 안심시키려고 쓰는 오래된 수법입니다. 구분법은 단순합니다. 값이 들어 있는 칸을 세 번 클릭해 전체 선택한 뒤 지웠다가 첫 글자만 다시 입력해 보세요. 브라우저 자동입력이라면 후보 목록이 내려오고, 아니라면 아무 반응이 없습니다. 페이지를 새로고침했을 때 지웠던 값이 되살아나도 같은 신호입니다.

세 번째 경우도 그냥 넘기면 안 됩니다. 기억에 없는 주소인데 저장된 항목이 있다는 건, 과거 어느 시점에 비슷한 주소를 열고 뭔가를 입력했다는 뜻입니다. 브라우저 설정의 비밀번호 목록에서 그 도메인을 검색해 저장 시점을 확인해 보면, 반년 전 다른 경로로 들어갔던 흔적이 나오기도 합니다.

반대로 자동입력이 전혀 안 뜨는 건 가짜라는 뜻인가요

아닙니다. 오히려 그게 도메인이 실제로 교체됐을 때의 정상 반응입니다. 최신주소 안내를 받고 새 주소로 들어갔는데 아무것도 기억돼 있지 않아 당황하는 분들이 많은데, 브라우저가 처음 보는 도메인을 백지 상태로 대하는 건 설계된 동작이지 오류가 아닙니다. 이 지점에서 불안해져 검색창에 다시 주소를 찾아 헤매다가, 상단 광고나 출처 불명의 링크모음을 눌러 엉뚱한 곳으로 가는 흐름이 가장 흔한 사고 경로입니다.

그래서 도메인 변경 소식을 접하면 새 주소를 열기 전에 마음의 준비를 해 두는 편이 낫습니다. 자동입력 없음, 이전 설정 없음, 화면이 초기 상태로 보임 — 이 세 가지는 새 접속주소가 진짜일 때도 똑같이 나타납니다. 진위 판단은 이런 체감이 아니라 안내가 어디서 나왔는지, 인증서 발급 도메인이 주소창과 일치하는지 같은 객관적 단서로 해야 합니다.

쿠키가 남아서 계속 옛 접속주소로 튕기는 것 같습니다

튕김의 원인은 쿠키보다 세 가지가 더 유력합니다. 하나는 서버가 걸어 둔 리다이렉트, 하나는 브라우저에 등록된 서비스워커, 나머지 하나는 DNS 캐시입니다. 이 중 체감상 가장 끈질긴 건 서비스워커입니다. 한 번 등록되면 오프라인에서도 화면을 그려 주는 구조라, 도메인이 바뀐 뒤에도 옛 화면을 캐시에서 꺼내 보여 주면서 마치 사이트가 아직 살아 있는 것처럼 착각하게 만듭니다. 캐시 수명이 24시간으로 잡혀 있으면 하루 내내 유령 화면을 보게 됩니다.

확인 순서는 이렇게 잡으면 깔끔합니다. 먼저 시크릿창에서 같은 주소를 열어 봅니다. 시크릿창은 쿠키도 서비스워커도 없는 상태이므로, 여기서 정상적으로 새 주소가 열린다면 문제는 내 브라우저 안에 있습니다. 그다음 설정에서 해당 사이트의 저장 데이터만 골라 삭제합니다. 전체 쿠키를 지울 필요는 없고, 사이트별 데이터 삭제 항목에서 문제의 도메인만 지정하면 됩니다. 마지막으로 브라우저 DNS 캐시를 비웁니다. 도메인 레코드의 TTL이 300초로 짧게 잡혀 있어도 브라우저 자체 캐시는 그보다 오래 붙들고 있는 경우가 있습니다.

새 주소에서 이전 주소 정보를 옮겨 준다는 안내가 떴는데요

이 문구는 기술적으로 불가능한 일을 가능한 것처럼 말하고 있습니다. 앞서 봤듯 다른 도메인의 쿠키나 저장된 인증 정보를 새 사이트가 읽어 올 방법은 없습니다. 따라서 이전 정보를 가져오겠다며 아이디와 비밀번호를 다시 입력하라고 요구하는 화면은, 정보를 옮기는 게 아니라 정보를 수집하는 화면입니다. 이전 사이트에서 쓰던 값을 그대로 적어 달라는 요청은 특히 그렇습니다.

비슷한 변종으로 이전 주소 접속 기록 확인, 도메인 변경 본인확인, 주소 이전 인증 같은 문구도 돌아다닙니다. 공통점은 전부 사용자가 직접 입력하게 만든다는 점입니다. 판단이 서지 않으면 그 자리에서 결정하지 말고 창을 닫은 뒤, 평소 쓰던 안내 경로로 돌아가 같은 안내가 거기에도 있는지 확인하세요. 한쪽에만 있는 안내는 거의 예외 없이 가짜입니다.

방문기록으로 도메인이 언제 바뀌었는지 되짚을 수 있나요

가능합니다. 그리고 생각보다 정확합니다. 브라우저 방문기록에서 사이트 이름의 공통 부분, 예컨대 samplename만 검색하면 그동안 거쳐 간 주소들이 시간순으로 줄줄이 나옵니다. 21, 22, 23처럼 번호가 붙은 주소들이 각각 마지막으로 방문된 날짜와 함께 보이면, 그 간격이 곧 도메인 교체 주기입니다. 3월 12일, 5월 4일, 6월 30일에 새 번호가 처음 등장했다면 평균 교체 간격은 약 55일이고, 다음 교체가 언제쯤일지도 어림잡을 수 있습니다.

주의할 점은 보관 기간입니다. 크롬 계열은 방문기록을 대략 90일까지만 남기기 때문에, 반년 전 이력은 이미 사라졌을 수 있습니다. 그래서 새 주소로 갈아탈 때마다 날짜와 주소를 메모 한 줄로 따로 적어 두는 사람이 결국 이깁니다. 기록이 다섯 줄만 쌓여도 다음 안내를 받았을 때 그게 주기상 납득되는 시점인지, 아니면 교체한 지 일주일 만에 또 바뀌었다는 수상한 이야기인지 바로 판단이 섭니다.

다운로드 기록도 보조 단서가 됩니다. 특정 시점에 그 도메인에서 받은 파일이 있다면, 그 날짜가 해당 주소가 살아 있던 구간의 하한선을 알려 줍니다.

비밀번호 관리자에 같은 사이트가 여러 개 쌓였는데 어떻게 정리하죠

도메인이 바뀔 때마다 새 항목이 생기니 1년쯤 지나면 비슷한 이름이 예닐곱 개씩 남습니다. 이걸 방치하면 나중에 자동입력 후보가 여러 개 뜨면서, 어느 것이 최신주소인지 구분이 안 되는 상황이 옵니다. 더 나쁜 건 과거에 잘못 들어갔던 가짜 주소까지 목록에 남아 있는 경우입니다. 목록만 보고는 그게 한때 진짜였던 주소인지 처음부터 가짜였는지 알 수 없습니다.

정리 기준은 단순하게 잡습니다. 지금 살아 있다고 확인된 주소 하나만 남기고, 나머지는 삭제하되 삭제 전에 주소 문자열과 저장 날짜를 따로 옮겨 적습니다. 그 기록이 앞 절에서 말한 교체 이력 메모가 됩니다. 삭제를 망설이는 이유가 혹시 나중에 필요할까 봐라면, 그 걱정은 메모가 대신 해결해 줍니다. 관리자에는 최신 하나, 메모에는 전체 이력 — 이 구조가 가장 덜 헷갈립니다.

시크릿창으로 열면 뭐가 다르길래 자꾸 권하나요

시크릿창은 쿠키·캐시·자동입력·확장프로그램이 대부분 빠진 상태의 브라우저입니다. 그래서 같은 주소를 일반 창과 시크릿창에서 나란히 열어 비교하면, 지금 보고 있는 화면 중 어디까지가 서버가 보낸 것이고 어디까지가 내 브라우저가 만들어 낸 것인지 갈라집니다. 일반 창에서는 로그인 상태처럼 보이는데 시크릿창에서는 첫 화면이 나온다면, 그 로그인 상태는 옛 도메인의 잔재이거나 캐시된 화면입니다.

반대로 시크릿창에서도 아이디가 미리 채워져 있다면 이야기가 달라집니다. 브라우저가 기억한 게 아니라 서버가 그렇게 보냈다는 뜻이고, 이건 앞에서 말한 위험 신호에 해당합니다. 확장프로그램이 주소를 바꿔치기하고 있는지도 이 비교로 걸러집니다. 일반 창에서만 다른 곳으로 열린다면 브라우저 안에 원인이 있습니다.

도메인 변경 공지 자체가 가짜일 수도 있나요

가능합니다. 오히려 주소 교체기의 혼란을 노린 위조 공지가 가장 손쉬운 미끼입니다. 진짜 교체가 한 번 일어나면 사람들이 새 주소를 찾아 움직이는데, 그 틈에 비슷한 형식의 안내를 뿌리면 평소보다 훨씬 잘 먹히기 때문입니다. 그래서 공지 하나만 보고 결정하지 말고, 평소 알고 있던 다른 경로에서도 같은 내용이 같은 주소로 안내되는지 확인하는 절차가 필요합니다. 두 경로가 서로 다른 주소를 가리키면 둘 다 보류하는 게 맞습니다.

먹튀검증 쪽 게시물은 이때 주소가 진짜인지 대조하는 참고 자료 정도로만 쓰면 충분합니다. 그 기록에 적힌 도메인과 내가 받은 주소의 철자가 한 글자라도 다르면, 판단을 더 진행하기 전에 그 차이부터 설명돼야 합니다. 마지막으로 인증서를 봅니다. 주소창 자물쇠를 눌러 인증서에 적힌 도메인이 지금 주소와 정확히 같은지 확인하는 데 10초면 됩니다.

정리하면 도메인 변경 주간의 점검은 세 줄로 요약됩니다.

• 저장정보는 따라오지 않는다 — 자동입력이 사라진 건 정상이고, 살아 있으면 이유를 설명할 수 있어야 합니다.
• 옛 화면은 캐시가 만든다 — 시크릿창 비교로 서버의 응답과 브라우저의 기억을 분리합니다.
• 안내는 두 곳에서 겹쳐야 한다 — 한 경로에만 있는 새 주소는 채택을 미룹니다.