로그인 정보 입력 직전 5분, 접속주소가 진짜인지 확인하는 절차

로그인 화면이 접속주소 검증의 마지막 관문인 이유

주소를 확인하는 일은 보통 주소창을 한 번 훑는 것으로 끝난다고 여긴다. 그런데 실제 피해가 생기는 지점은 그보다 한 칸 뒤에 있다. 복제된 접속주소가 위험해지는 순간은 페이지가 열릴 때가 아니라, 아이디와 비밀번호가 전송 버튼을 통과하는 그 순간이다. 화면 구성과 로고, 하단 공지 문구까지 그대로 베껴 온 페이지 앞에서는 눈이 먼저 의심을 접는다.

그래서 최신주소를 찾아내는 절차와는 별개로, 입력창에 커서를 올린 상태에서 돌려볼 짧은 점검 순서가 따로 필요하다. 이 글은 주소모음이나 메신저에서 받은 후보 주소를 열어 로그인 화면까지 도달한 다음, 문자 하나도 입력하기 전에 5분 안에 끝내는 절차를 다룬다. 앞선 단계에서 아무리 꼼꼼히 걸렀더라도 이 마지막 관문은 따로 통과시켜야 한다.

절차를 시간 단위로 쪼개는 이유는 단순하다. 기준 없이 살펴보면 사람은 평균 8초 정도만 화면을 보고 넘어간다. 반대로 순서와 시간 예산이 정해져 있으면 같은 5분이 훨씬 촘촘해진다. 아래 순서는 특별한 도구 없이 브라우저 하나로 끝나도록 구성했다.

5분을 어떻게 쪼갤 것인가: 예산과 기록 양식

먼저 후보 접속주소를 두세 개 확보한 상태로 시작한다. 하나만 들고 있으면 비교 대상이 없어 판단이 느슨해지고, 다섯 개가 넘어가면 5분 안에 끝나지 않는다. 경험상 후보 2~3개가 판단 속도와 정확도의 균형점이다. 주소모음 페이지에서 하나, 평소 쓰던 즐겨찾기에서 하나, 최근 안내 글에서 하나를 뽑는 식이면 출처가 겹치지 않아 좋다.

시간 배분은 주소 문자열 40초, 전송 대상 도메인 60초, 오답 비밀번호 반응 90초, 세션·자동입력 신호 60초, 기록 30초 정도로 잡으면 4분 40초가 된다. 남는 20초는 마지막 판정에 쓴다. 각 단계에 배정된 시간을 넘기면 그 항목은 보류로 처리하고 다음으로 넘어가는 편이 낫다. 한 항목에 매달리다 나머지를 건너뛰는 것이 가장 흔한 실패 방식이다.

기록은 거창할 필요가 없다. 메모장에 날짜, 접속주소 뒷부분 여덟 글자, 다섯 항목의 통과 여부를 O와 X로 남기는 한 줄이면 된다. 3주 뒤 같은 주소를 다시 마주쳤을 때 이 한 줄이 재검증 시간을 절반 이하로 줄여 준다. 기록이 쌓이면 어떤 경로에서 받은 주소가 자주 탈락하는지도 자연스럽게 드러난다.

전체 순서를 먼저 익혀 두기

아래 여섯 단계는 순서 자체에 의미가 있다. 비용이 적고 확실한 판별부터 앞에 두고, 시간이 걸리거나 판단이 애매한 항목을 뒤로 뺐다. 앞 단계에서 탈락하면 뒤 단계는 볼 필요가 없으므로 실제로는 1분 안에 끝나는 경우가 절반 이상이다.

1. 주소 문자열 역순 읽기 — 끝에서부터 잘라 읽으며 등록 가능한 도메인 구간을 확정한다.
2. 연결 상태 확인 — 자물쇠 표시와 인증서 발급 대상이 그 도메인과 맞는지 본다.
3. 전송 대상 도메인 확인 — 로그인 폼이 어느 주소로 값을 보내는지 확인한다.
4. 오답 비밀번호 반응 측정 — 실제 계정과 무관한 값을 넣고 응답 방식과 시간을 본다.
5. 세션·자동입력 신호 해석 — 로그인 상태 유지 여부와 저장 정보 반응을 읽는다.
6. 판정과 한 줄 기록 — 통과, 보류, 폐기 중 하나로 정하고 메모에 남긴다.

여섯 단계 중 3번과 4번은 다른 주소 점검 방법에서 거의 다루지 않는 항목이다. 겉모습이 완벽하게 복제된 페이지일수록 이 두 곳에서 차이가 드러난다. 나머지 네 단계는 이미 익숙한 확인법이지만, 순서 안에 놓였을 때 비로소 빠뜨리지 않게 된다.

1단계: 주소창 문자열을 끝에서부터 잘라 읽기

주소를 앞에서부터 읽으면 눈에 먼저 들어오는 익숙한 단어에 판단이 끌려간다. 반대로 끝에서부터 읽으면 확장자와 그 바로 앞 단어, 즉 실제 등록된 도메인 구간이 먼저 확정된다. 슬래시가 나오기 전까지가 도메인이고, 그중 마지막 점 두 조각이 실제 소유자를 가리킨다. 앞에 붙은 어떤 단어도 이 구간을 바꾸지 못한다.

같은 이름이 앞쪽과 뒤쪽 어디에 붙어 있는지에 따라 전혀 다른 주소가 된다는 점은 몇 번을 강조해도 지나치지 않다. 이 40초 동안 한 글자씩 소리 내어 읽는 습관만 들여도 복제 주소의 상당수가 여기서 걸린다. 숫자 0과 알파벳 o, 대문자 I와 소문자 l이 섞여 있는지도 이때 함께 확인한다.

2단계: 로그인 폼이 값을 보내는 곳 확인하기

주소창이 멀쩡해도 입력값은 다른 서버로 갈 수 있다. 화면을 그대로 복사해 놓고 전송만 가로채는 구조가 그렇다. 확인 방법은 생각보다 간단하다. 페이지에서 오른쪽 클릭 후 소스 보기를 열고, 찾기 기능으로 action 이라는 문자열을 검색한다. 그 뒤에 이어지는 값이 현재 주소창의 도메인과 다르거나, 낯선 외부 주소를 가리키면 즉시 중단한다.

값이 슬래시로 시작하는 상대 경로라면 같은 도메인으로 전송된다는 뜻이므로 정상 범위다. 반대로 http로 시작하는 절대 주소가 적혀 있고 그 도메인이 주소창과 다르다면, 그 차이 자체가 설명을 요구하는 신호다. 소스 보기가 막혀 있거나 스크립트로만 처리되어 확인이 불가능한 경우에는 이 항목을 보류로 두고 다음 단계의 결과에 더 무게를 준다.

이 단계에 60초를 배정한 이유는 검색 한 번이면 끝나기 때문이다. 페이지가 지나치게 무겁거나 소스가 수천 줄이어도 찾기 기능은 1초면 결과를 준다. 시간이 모자란다면 검색어를 password로 바꿔 입력창 부근만 살펴보는 방법도 있다.

3단계: 일부러 틀린 비밀번호를 넣어 반응 보기

겉모습만 복제한 페이지는 입력값을 검증할 서버가 없다. 그래서 아무 값이나 받아서 저장하거나, 다음 화면으로 그냥 넘겨 버리거나, 로딩만 하염없이 돌린다. 진짜 서버는 다르다. 대개 0.3초에서 1.5초 사이에 명확한 실패 메시지를 돌려주고, 실패 횟수를 세며, 몇 회 이상이면 추가 확인을 요구한다. 이 반응 차이가 가장 확실한 판별 지점이다.

측정할 값은 세 가지다. 응답까지 걸린 시간, 메시지의 구체성, 재시도 시 동작이다. 3초가 넘도록 아무 반응이 없거나, 실패인데도 내부 페이지로 넘어가거나, 틀린 값을 계속 넣어도 횟수 안내가 전혀 없다면 입력값을 검증하지 않는 껍데기 페이지일 가능성이 높다. 반대로 즉시 거절 메시지가 뜨고 두 번째 시도에서 문구가 달라지면 뒤에 실제 처리 로직이 있다는 뜻이다.

이 테스트가 가진 한계

오답 테스트는 입력값을 그대로 진짜 서버로 중계하는 방식에는 통하지 않는다. 중계형 구조에서는 틀린 값이 진짜 서버로 전달되어 진짜 실패 메시지가 돌아오기 때문에 반응만 봐서는 구분할 수 없다. 그래서 이 단계는 단독 판정 근거가 아니라 1단계와 2단계를 통과한 뒤에 덧붙이는 확인으로만 쓴다.

4단계: 세션과 자동입력이 보내는 신호 읽기

평소 쓰던 주소에서 로그인 상태가 유지되고 있었다면, 같은 서버의 새 접속주소에서도 대개 그 상태가 이어지거나 최소한 계정 관련 화면이 익숙하게 열린다. 도메인이 완전히 바뀌면 저장된 값이 따라오지 않는 것이 정상이지만, 같은 운영 주체라면 안내 문구나 이관 절차가 함께 붙는다. 아무 설명 없이 처음 방문한 사람처럼 모든 것이 비어 있다면 그 자체로 질문거리다.

비밀번호 관리자의 침묵도 신호다. 저장해 둔 값이 있는데 입력창을 눌러도 제안이 뜨지 않는다면, 관리자가 보기에 지금 도메인이 저장 시점과 다르다는 뜻이다. 사람 눈은 속아도 문자열 대조는 속지 않는다. 물론 진짜 도메인 변경일 때도 같은 침묵이 발생하므로, 이것은 탈락 근거가 아니라 한 번 더 확인하라는 표시로 받아들인다.

5단계: 세 갈래 판정과 한 줄 기록

점수를 매기기보다 세 갈래로 나누는 편이 실전에서는 빠르다. 다섯 항목이 모두 통과면 사용, 한 항목이 보류이고 나머지가 통과면 다른 경로로 받은 주소와 대조한 뒤 결정, 한 항목이라도 명백한 탈락이면 그 자리에서 폐기한다. 특히 1단계나 2단계 탈락은 다른 항목이 아무리 좋아도 되돌릴 수 없다.

폐기한 주소는 지우지 말고 따로 모아 둔다. 같은 문자열이 몇 주 뒤 다른 경로로 다시 올라오는 일이 잦고, 그때 목록에 있으면 5분이 5초로 줄어든다. 통과한 주소는 즐겨찾기 이름 뒤에 확인한 날짜를 붙여 저장한다. 날짜가 붙어 있으면 다음에 열 때 재검증이 필요한 시점인지 바로 판단된다.

실제로 12분이 걸렸던 어느 저녁

한 이용자가 메신저 단체방에서 새 접속주소를 받았다. 첫 40초는 문자열 읽기에 썼고, 확장자 앞 단어가 평소와 한 글자 다르다는 점을 발견했지만 실제 도메인 변경일 수도 있어 보류로 두었다. 소스에서 action 값을 찾으니 상대 경로였고 여기서는 걸리는 것이 없었다.

문제는 세 번째 단계에서 드러났다. 존재하지 않는 아이디와 임의의 비밀번호를 넣었더니 4초쯤 로딩이 돌다가 내부 안내 화면으로 넘어갔다. 두 번째로 전혀 다른 값을 넣어도 같은 결과였다. 실패 메시지가 한 번도 뜨지 않았다는 사실이 결정적이었다. 여기까지 걸린 시간은 3분 남짓이다.

나머지 9분은 다른 경로를 확인하는 데 썼다. 즐겨찾기에 남아 있던 이전 주소를 열어 같은 방식으로 틀린 값을 넣었더니 0.8초 만에 거절 메시지가 떴고, 두 번째 시도에서는 남은 횟수 안내까지 붙었다. 단체방 주소는 폐기 목록으로 옮겨졌고, 그 한 줄 기록은 열흘 뒤 같은 문자열이 다른 방에서 돌 때 다시 쓰였다.

이 절차가 뚫리는 지점과 그때의 보루

앞서 언급한 중계형 구조는 이 절차의 3단계와 4단계를 모두 통과할 수 있다. 입력값이 진짜 서버로 흘러가니 반응도 진짜고, 화면도 진짜에서 가져온 것이기 때문이다. 이런 경우 남는 방어선은 결국 1단계, 주소 문자열 그 자체다. 중계하는 쪽도 자기 도메인 위에서만 페이지를 띄울 수 있으므로 문자열은 반드시 다르다.

그래서 순서를 바꾸지 않는 편이 좋다. 뒤쪽 단계가 화려해 보여도 가장 단단한 근거는 맨 앞에 있다. 뒤 단계들은 앞 단계가 애매할 때 판단을 보태는 역할이고, 앞 단계가 명확히 어긋나면 뒤는 볼 이유가 없다. 이 위계를 지키면 절차 전체가 훨씬 빨라진다.

다음에 새 접속주소를 마주하면 타이머를 5분으로 맞추고 순서대로 내려가 보기를 권한다. 몇 번 반복하면 시간이 3분 아래로 줄고, 어느 순간부터는 주소창을 보는 첫 40초만으로 대부분의 판단이 끝나게 된다.