비밀번호 관리자에 박힌 옛 접속주소 갱신해 최신주소와 맞추는 절차

저장된 아이디가 사라진 것처럼 보이던 아침

몇 달 만에 즐겨찾기를 눌러 들어간 화면에서 로그인 칸이 텅 비어 있었다. 평소라면 칸을 누르는 순간 비밀번호 관리자가 아이디 목록을 띄웠는데 그날은 아무 반응도 없었다. 비밀번호를 잊은 것도 아니었고 관리자 앱이 잠긴 것도 아니었다. 확인해 보니 이유는 싱거웠다. 주소창에 떠 있는 도메인이 예전에 저장해 둔 것과 달랐고, 관리자는 지금 열린 접속주소와 저장된 항목을 서로 다른 사이트로 판단하고 있었다.

이런 상황은 도메인 변경이 잦은 환경에서 거의 필연적으로 생긴다. 즐겨찾기는 부지런히 최신주소로 바꿔 두면서도, 비밀번호 관리자 안에 박힌 URL 필드는 처음 저장하던 날 그대로 남아 있기 때문이다. 즐겨찾기가 여덟 개면 관리자 항목도 여덟 개인데, 사람들은 보통 앞의 여덟 개만 관리한다. 그래서 주소는 세 번 바뀌었는데 저장된 항목의 수정일은 400일 전에 멈춰 있는 일이 벌어진다.

더 곤란한 건 방향이 반대로 뒤집힐 때다. 옛 도메인이 만료된 뒤 다른 사람이 주워 가서 비슷한 로그인 화면을 올려 두면, 관리자는 저장된 URL과 지금 주소가 일치한다고 보고 아이디와 비밀번호를 순순히 채워 준다. 자동완성이 잘 되는 것이 안전의 증거가 아니라 위험의 통로가 되는 구간이 바로 여기다. 그래서 갱신 작업은 편의를 위한 정리가 아니라 계정 정보를 어디에 흘리지 않기 위한 정리에 가깝다.

관리자는 주소를 어디까지 보고 같은 사이트라고 판단할까

대부분의 비밀번호 관리자와 브라우저 내장 저장소는 URL 전체를 글자 단위로 비교하지 않는다. 등록 가능한 최상위 도메인 바로 앞 한 칸까지, 흔히 eTLD+1이라 부르는 범위를 기준으로 같은 사이트인지를 본다. 쉽게 말해 example-toto.com과 m.example-toto.com은 같은 묶음으로 취급되지만, example-toto.net이나 example-toto7.com은 완전히 다른 사이트로 본다. 경로나 물음표 뒤 파라미터는 판단에 거의 영향을 주지 않는다.

이 규칙을 알면 자동완성이 안 뜨는 상황을 훨씬 빨리 해석할 수 있다. 서브도메인만 바뀐 경우라면 자동완성은 정상적으로 뜬다. 그런데도 목록이 비어 있다면 바뀐 것은 서브도메인이 아니라 도메인 본체이거나 확장자다. 반대로 숫자 접미어가 붙은 주소, 예컨대 뒤에 2나 77이 붙은 형태는 사람 눈에는 같은 계열로 보여도 관리자에게는 남남이다. 눈으로 비슷해 보이는 것과 프로그램이 같다고 보는 것은 기준이 다르다는 점을 먼저 받아들여야 한다.

퓨니코드 도메인에서는 한 겹이 더 있다. 한글이나 유사 문자로 보이는 주소는 내부적으로 xn--로 시작하는 문자열로 저장된다. 화면에는 예쁘게 보여도 관리자가 기억하는 값은 그 변환된 문자열이라, 겉보기가 완전히 같은 두 주소가 저장소 안에서는 전혀 다른 항목으로 쌓인다. 갱신 작업에서 중복 항목이 유난히 많이 나오는 계정은 이 경우를 의심해 볼 만하다.

작업 전 항목 수부터 센다

정리를 시작하기 전에 관리자에 들어 있는 전체 항목 수를 한 번 확인한다. 실제로 세어 보면 생각보다 많다. 한 이용자의 저장소에는 총 61개 항목이 있었고, 그중 이 주제와 관련된 항목은 14개였다. 14개를 다시 들여다보니 아이디가 서로 겹치는 중복이 5개, URL 필드가 아예 비어 있는 항목이 3개, 수정일이 300일을 넘긴 항목이 9개였다. 손댈 대상은 결국 11개로 줄었다.

이렇게 숫자를 먼저 잡아 두는 이유는 작업량을 예측하기 위해서다. 항목 하나를 열어 URL을 확인하고, 현재 도메인과 대조하고, 수정하고 저장하는 데 걸리는 시간은 익숙해지면 90초 안팎이다. 11개면 17분 내외, 중간에 실제 접속 테스트를 두어 번 끼워 넣어도 30분을 넘기지 않는다. 막연히 '언젠가 정리해야지'로 미루던 일이 30분짜리 작업이라는 것을 알면 실행 확률이 확실히 올라간다.

세는 김에 한 가지를 더 기록해 둔다. 각 항목의 마지막 수정일이다. 이 날짜들은 나중에 점검 주기를 계산할 때 원자료가 된다. 항목 9개의 수정일이 각각 다르다면 그 간격의 평균이 곧 내가 지금까지 실제로 유지 관리해 온 주기이고, 대개 그 값은 스스로 생각했던 것보다 훨씬 길다.

갱신 대상 항목을 골라내는 정렬 순서

전체를 무작정 훑는 대신 정렬을 두 번 바꿔 가며 훑으면 훨씬 빠르다. 첫 번째는 수정일 오래된 순이다. 목록 맨 위에 올라오는 항목들이 옛 도메인을 품고 있을 확률이 가장 높다. 두 번째는 이름순이다. 비슷한 이름이 나란히 붙어 있으면 중복 항목이 한눈에 드러나고, 어느 쪽이 살아 있는 주소인지 비교하기 좋다.

정렬 다음에는 URL 필드가 비어 있는 항목을 따로 표시해 둔다. 이 항목들은 자동완성이 절대 뜨지 않으면서 저장소 용량만 차지하고, 나중에 '분명히 저장했는데 안 나온다'는 착각을 만드는 주범이다. 앱에서 저장한 계정이나, 예전에 텍스트로 옮겨 붙이며 만든 항목에서 자주 나온다. 이런 항목은 삭제하지 말고 URL을 채워 넣어 되살리는 쪽이 낫다. 비밀번호 자체는 유효할 수 있기 때문이다.

실제 갱신 순서

1. 현재 살아 있는 주소를 먼저 확정한다 — 갱신의 기준이 될 주소를 먼저 검증해 둔다. 확인되지 않은 후보 주소를 기준으로 저장소를 고치면 오염이 통째로 퍼진다. 주소창에 실제로 열린 최종 도메인을 그대로 복사해 둔다.
2. 복사한 주소에서 군더더기를 잘라낸다 — 물음표 뒤 파라미터, 해시 뒤 조각, 로그인 경로는 지우고 도메인까지만 남긴다. 실무에서는 이 한 줄이 URL 필드의 표준형이 된다.
3. 항목 하나를 열어 기존 URL과 눈으로 대조한다 — 앞에서 두 글자, 뒤에서 확장자까지 끊어 읽는다. 다르면 갱신 대상, 같으면 수정일만 오래된 정상 항목이다.
4. URL 필드를 교체하되 기존 값을 메모란에 옮겨 둔다 — 옛 주소는 나중에 이력 대조에 쓰인다. 지우지 말고 메모 첫 줄에 날짜와 함께 남긴다.
5. 여러 URL을 지원하는 관리자라면 보조 필드를 활용한다 — 모바일 전용 서브도메인처럼 정상적으로 함께 쓰이는 주소는 두 번째 URL로 추가한다. 확인되지 않은 후보 주소는 넣지 않는다.
6. 저장 후 그 자리에서 자동완성을 시험한다 — 해당 사이트를 새 탭에서 열고 로그인 칸을 눌러 목록이 뜨는지 본다. 뜨지 않으면 URL 표기가 어딘가 틀린 것이다.
7. 11개를 다 끝낸 뒤 저장소를 내보내기 한다 — 암호화된 파일 형태로 백업해 두면 다음 도메인 교체 때 직전 상태를 비교할 수 있다.

순서에서 가장 자주 건너뛰는 항목이 네 번째다. 옛 주소를 지워 버리면 편해 보이지만, 몇 달 뒤 '이 도메인 예전에 쓰던 것 맞나'를 판단할 근거가 사라진다. 메모란에 날짜와 함께 남겨 둔 옛 주소 서너 줄은, 나중에 만료 재등록된 도메인이 다시 나타났을 때 그것이 과거의 잔재인지 새 사칭인지를 가르는 결정적 자료가 된다.

자동완성을 거꾸로 시험지로 쓰기

갱신을 끝내고 나면 뜻밖의 도구가 하나 생긴다. 저장소의 URL이 정확한 값으로 맞춰져 있는 상태에서는, 자동완성이 뜨는지 여부가 곧 도메인 일치 여부를 알려 주는 신호가 된다. 어디선가 받은 접속주소를 열었는데 로그인 칸에서 아이디 목록이 뜨지 않는다면, 그 주소는 내가 검증해 둔 도메인과 최소한 eTLD+1 수준에서 다르다는 뜻이다.

이 신호는 사람의 눈보다 엄격하다. 알파벳 l과 숫자 1이 바뀐 주소, 확장자만 다른 주소, 하이픈이 하나 더 들어간 주소는 육안으로 몇 초를 들여다봐도 놓치기 쉽지만 관리자는 즉시 남으로 판단한다. 자동완성이 안 뜬다는 건 불편함이 아니라 경고음이라고 해석을 바꿔 두면, 별도 검사 도구 없이도 1차 걸러내기가 된다.

다만 이 시험지는 저장소가 깨끗할 때만 유효하다. 과거에 '일단 저장' 버튼을 눌러 미검증 주소가 여러 개 들어가 있으면, 가짜 주소에서도 자동완성이 떠 버려 신호가 무의미해진다. 그래서 정리 과정에서 출처가 기억나지 않는 항목은 URL을 비워 두거나 삭제하는 편이 낫다. 시험지의 값어치는 저장소에 들어간 주소를 내가 전부 설명할 수 있을 때 생긴다.

한 사이트에 항목이 세 개로 늘어났을 때

정리하다 보면 같은 계정인데 항목이 여러 개인 경우를 반드시 만난다. 도메인이 바뀔 때마다 브라우저가 '새 비밀번호를 저장할까요'라고 물었고, 그때마다 확인을 눌렀기 때문이다. 앞서 예로 든 저장소에서도 한 계정에 항목이 3개였고, 각각의 URL은 서로 다른 세 도메인을 가리키고 있었다. 비밀번호는 셋 다 같았다.

이럴 때는 가장 최근에 로그인에 성공한 항목 하나만 남기고 나머지는 지우되, 지우기 전에 URL을 옮겨 적는다. 남길 항목의 메모란에 '이전 도메인: A(2024년 저장) / B(2025년 저장)' 식으로 쌓아 두면 항목 수는 3분의 1로 줄면서 이력은 보존된다. 비밀번호가 항목마다 다르다면 지우기 전에 어느 쪽이 지금 통하는지 반드시 확인한다. 통하지 않는 비밀번호를 남기고 통하는 쪽을 지우는 사고가 의외로 흔하다.

다음 갱신 시점을 숫자로 잡기

메모란에 옛 주소와 날짜가 쌓이면 교체 간격을 계산할 수 있다. 한 사례에서는 저장 이력이 2025년 3월, 5월, 9월, 그리고 이번 갱신까지 네 번이었고 간격은 각각 61일, 122일, 70일이었다. 평균은 84일, 가장 짧았던 간격은 61일이다. 점검 주기는 평균이 아니라 최단 간격을 기준으로 잡는다. 61일의 3분의 1인 약 3주마다 한 번 열어 보는 일정이면, 교체가 일어나도 최대 20일 안에는 알아채게 된다.

3주 주기가 부담스럽다면 조건을 붙인 방식도 된다. 평소에는 신경 쓰지 않다가, 자동완성이 한 번이라도 뜨지 않는 순간을 점검 신호로 삼는 것이다. 이 방식의 장점은 캘린더 알림 없이도 굴러간다는 것이고, 단점은 그 순간이 하필 급할 때 찾아온다는 것이다. 두 방식을 섞어 분기에 한 번 정기 점검을 넣고 나머지는 신호에 맡기는 정도가 현실적이다.

브라우저 저장소와 전용 관리자를 함께 쓸 때

전용 관리자를 쓰면서 브라우저 내장 저장 기능도 켜 둔 사람이 많다. 이 조합에서 갱신 작업이 반쪽으로 끝나는 일이 자주 생긴다. 전용 관리자 쪽은 깨끗하게 정리했는데 브라우저 안에 옛 주소 항목이 그대로 남아 있으면, 로그인 칸을 눌렀을 때 두 곳이 동시에 후보를 내밀고 그중 하나는 여전히 과거를 가리킨다.

정리 순서는 전용 관리자를 먼저 끝내고, 그다음 브라우저 설정의 저장된 비밀번호 목록을 열어 같은 계열 항목을 전부 지우는 쪽이다. 지운 뒤에는 브라우저의 비밀번호 저장 제안 기능 자체를 꺼 두는 것도 방법이다. 저장소가 하나로 모여 있어야 앞에서 말한 자동완성 시험지가 제대로 작동한다. 저장 위치가 둘이면 신호도 둘이 되고, 둘이 다른 말을 하는 순간 판단 근거가 사라진다.

석 달 뒤에 남은 것

정리를 마치고 석 달쯤 지나 도메인이 한 번 더 바뀌었을 때, 같은 상황이 전혀 다르게 흘러갔다. 즐겨찾기가 열리지 않는다는 것을 알아챈 시점은 여전히 비슷했지만, 새 주소를 확인한 뒤 손댈 항목은 3개뿐이었고 전부 합쳐 6분이 걸렸다. 중복을 미리 줄여 두었고, 메모란에 이력이 쌓여 있어 무엇을 고쳐야 하는지 찾는 시간이 사라졌기 때문이다.

그리고 한 번, 자동완성이 뜨지 않는 로그인 화면을 만났다. 주소를 다시 확인해 보니 확장자가 한 글자 다른 별개의 도메인이었다. 눈으로는 스쳐 지나갔을 차이를 저장소가 먼저 짚어 준 셈이다. 비밀번호 관리자를 정리한다는 건 결국 계정 관리가 아니라 주소 관리였고, 그 효과는 편의보다 판별 쪽에서 더 크게 돌아왔다.