점검 중이라던 접속주소가 파킹 페이지였던 사흘: 최신주소를 되찾은 기록

목요일 밤 11시, 즐겨찾기 속 접속주소에 '점검 중' 한 줄만 떴다

즐겨찾기 폴더 맨 위에 두고 몇 달 동안 아무 문제 없이 열렸던 토토사이트 주소였다. 그날 밤에는 익숙한 첫 화면 대신 회색 배경 가운데에 '서비스 점검 중입니다. 잠시 후 다시 방문해 주세요'라는 문장 하나만 떠 있었다. 로고도, 메뉴도, 점검 종료 예정 시각도 없었다. 서버 작업이 보통 새벽에 잡힌다는 걸 알고 있었으니 그날은 창을 닫고 잤다.

문제는 다음 날 오전에도, 퇴근길에도 같은 화면이 반복됐다는 점이다. 새로고침을 해도 같고, 캐시를 지우고 시크릿창으로 열어도 같았다. 그때까지도 나는 '길어지는 점검'이라고 생각했다. 돌아보면 이 짐작이 사흘을 통째로 날린 원인이었다. 점검 문구는 서버 운영자만 쓸 수 있는 특권이 아니라, 도메인을 손에 넣은 누구든 HTML 몇 줄로 띄울 수 있는 문장이다.

사흘째 저녁, 같은 화면을 네 번째로 마주하고 나서야 주소 자체를 의심했다. 확인할 대상은 '점검이 언제 끝나는가'가 아니라 '이 접속주소가 아직 원래 서버를 가리키는가'였다. 질문을 바꾸고 나니 확인할 것이 명확해졌다. 아래는 그날 밤 실제로 밟은 순서다.

문구를 읽는 대신 페이지 구조를 먼저 봤다

가장 먼저 한 일은 페이지 소스 열기였다. PC 브라우저에서 Ctrl+U를 누르면 바로 보인다. 진짜 점검 페이지라면 보통 원래 사이트의 흔적이 남는다. 같은 CSS 경로, 같은 이미지 서버 도메인, 같은 파비콘 파일명 같은 것들이다. 그런데 이 페이지는 전체가 40줄도 되지 않는 단일 문서였고, 외부에서 불러오는 자산이 하나도 없는 인라인 스타일 덩어리였다.

더 걸린 건 하단에 숨어 있던 스크립트 한 줄이었다. 광고 트래픽 중개에 흔히 쓰이는 외부 도메인에서 js를 불러오면서, 파라미터에 내가 접속한 도메인 이름을 그대로 실어 보냈다. 점검 중인 서비스가 방문자를 광고 네트워크에 넘길 이유는 없다. 점검 문구와 광고 트래킹 스크립트의 조합은 도메인 파킹 페이지의 전형적인 생김새다. 탭 아이콘도 원래의 심볼이 아니라 브라우저 기본 문서 아이콘이었고, 시크릿창에서 다시 확인해도 마찬가지였다.

네임서버와 등록 갱신일이 같은 날짜를 가리켰다

다음은 도메인이 어디를 향하는지였다. 네임서버를 조회해보니 내가 몇 달 전 메모해 둔 값과 달라져 있었다. 이전에는 흔한 클라우드 CDN 계열 네임서버였는데, 조회 결과에는 도메인 매매·파킹 서비스가 쓰는 이름이 찍혔다. 네임서버 이름에 parking, sale 같은 단어가 들어가면 그 도메인은 지금 판매 혹은 광고 수익용으로 걸려 있다는 뜻이다.

등록정보도 대조했다. 최초 등록일은 2019년으로 그대로였지만 최근 갱신일이 사흘 전, 정확히 점검 화면이 처음 뜬 날짜였다. 도메인 상태가 그날 움직였다는 의미이고, 만료 후 방치되다 제3자에게 넘어갔거나 소유 계정이 바뀐 쪽에 무게가 실렸다. 서버만 점검하는 상황이라면 등록정보가 흔들릴 이유가 전혀 없다.

TTL 값도 확인했다. 원래 1800초였던 A레코드 TTL이 300초로 내려가 있었다. 주소를 자주 갈아 돌릴 준비를 한 상태이거나, 파킹 업체의 기본 설정값이다. 네임서버 이름, 갱신일, TTL이라는 세 신호가 한 방향을 가리키면 그건 점검이 아니다. 조회 세 번에 5분, 사흘째가 아니라 첫날 밤에 했어야 할 일이었다.

존재하지 않는 서브도메인을 붙여보는 30초 실험

여기서 쓴 방법은 단순한데 결과가 선명했다. 도메인 앞에 있을 리 없는 서브도메인을 붙여 접속해 본 것이다. asdf1234, zzz, test99처럼 아무 문자열이나 넣었다. 정상 운영되는 서버라면 이런 요청은 오류 페이지를 내거나, 인증서 이름 불일치 경고로 막히거나, 기본 안내 화면으로 떨어진다.

그런데 세 개 모두 똑같은 회색 '점검 중' 화면을 띄웠다. 와일드카드로 모든 서브도메인을 한 페이지에 받아내고 있다는 뜻이고, 이건 파킹 설정의 지문 같은 특징이다. 점검 페이지를 직접 만든 운영 측이라면 없는 서브도메인까지 같은 문구로 받아줄 이유가 없다. 반대 사례도 기억해 둘 만하다. 나중에 겪은 진짜 점검에서는 루트 주소만 안내 문구가 뜨고 없는 서브도메인은 인증서 경고를 냈는데, 여섯 시간 뒤 정상화됐다.

인증서 발급 시각이 남긴 타임스탬프

주소창 자물쇠를 눌러 인증서를 열었다. 유효 상태였지만 발급일이 사흘 전이었다. 원래 쓰던 인증서는 갱신 주기상 두 달 전에 발급된 것이었고, 나는 그 화면을 캡처해 둔 기록이 있었다. 발급 기관도 달랐다. 인증서가 유효하다는 건 '이 서버가 이 도메인을 통제한다'는 증명일 뿐, '원래 운영자가 그대로'라는 증명이 아니다. 여기서 많은 사람이 자물쇠 표시만 보고 안심한다.

인증서 투명성(CT) 로그로 같은 도메인의 발급 이력도 훑었다. 2019년부터 두세 달 간격으로 꾸준히 찍혀 있던 기록이 사흘 전부터 다른 기관, 그리고 와일드카드 형태로 바뀌어 있었다. 앞서 확인한 와일드카드 응답과 정확히 맞물리는 흔적이었다. 이 지점에서 점검이 아니라 주소가 손을 옮긴 상황이라고 결론 냈다. 기다릴 대상이 아니라 폐기할 대상이었다.

아카이브와 검색 캐시로 마지막 정상 화면을 짚었다

웹아카이브에서 해당 도메인의 스냅샷을 열어봤다. 점검 화면이 뜨기 나흘 전 스냅샷에는 원래 첫 화면이 남아 있었고, 사흘 전 스냅샷부터 지금의 회색 페이지로 바뀌어 있었다. 교체 시점이 24시간 안쪽으로 좁혀졌다. 아카이브는 수집 빈도가 낮은 도메인이면 비어 있을 수 있지만, 한 번이라도 잡혀 있으면 '언제부터 달라졌나'를 날짜로 확정해 준다.

검색 결과 캐시도 대조했다. 검색엔진이 들고 있던 제목과 설명은 여전히 옛 화면의 텍스트였다. 이게 흔한 함정이다. 검색 결과가 멀쩡해 보여도 실제로 열리는 페이지는 이미 남의 손일 수 있다. 캐시 문구는 과거에 찍힌 사진이고 현재 상태가 아니다. 마지막 정상 스냅샷에서 건진 건 화면만이 아니었다. 당시 하단에 적혀 있던 안내 방식, 즉 공지가 올라오던 경로를 다시 확인했고 새 주소를 찾는 출발점이 거기서 나왔다.

사흘을 기다린 비용을 숫자로 계산해 봤다

정리하면 이렇다. 도메인이 손을 옮긴 시점은 목요일 낮, 내가 점검이라 믿은 기간은 목요일 밤부터 일요일 저녁까지 약 72시간이다. 그 사이 원래 운영 측 안내는 이미 이틀 전에 다른 경로로 올라와 있었다. 사흘 내내 나는 죽은 주소를 새로고침하며 살아 있는 안내를 놓친 셈이다.

더 신경 쓰이는 손실은 시간이 아니라 노출이었다. 72시간 동안 나는 남의 통제 아래 있는 도메인에 네 번 접속했고, 그중 두 번은 브라우저 자동입력 말풍선이 뜨는 걸 무심히 지나쳤다. 저장된 로그인 정보가 옛 도메인에 묶여 있으면, 주소가 넘어간 뒤에도 브라우저는 그 화면에 정보를 채워 넣을 준비를 한다. 그 페이지에 입력창이 없어서 아무 일도 없었을 뿐, 로그인 폼을 흉내 낸 첫 화면이었다면 결말이 달랐다.

그래서 판정 기준을 시간으로 못 박았다. 같은 주소가 12시간 넘게 완전히 동일한 정적 화면만 띄우면 점검 가정을 버리고 조회부터 시작한다. 6시간이면 흔한 점검, 12시간이면 의심, 24시간이면 사실상 다른 종류의 문제다. 기다림에 상한선을 두지 않으면 공백기는 알아서 늘어난다.

점검 페이지, 파킹 페이지, 차단 화면은 다르게 생겼다

세 가지는 겉보기에 모두 '사이트가 안 열린다'지만 원인이 앉아 있는 층이 다르다. 진짜 점검은 서버가 의도적으로 띄운 화면이라 원래 사이트의 자산이 섞이고, 없는 서브도메인은 다른 응답을 낸다. 파킹은 도메인 층위에서 갈린 상태라 자산이 전무하고 와일드카드로 전부 받아내며 광고 스크립트가 붙는다.

차단은 또 다르다. 망이나 보안 장비, DNS 단계에서 막힌 경우여서 모바일 데이터처럼 다른 망으로 열면 결과가 바뀐다. 점검과 파킹은 어느 망에서 열어도 같은 화면이다. 그래서 첫 30초에 할 일은 두 가지로 줄어든다. 망을 바꿔 한 번 열어보고, 없는 서브도메인을 붙여보는 것. 이 둘만으로 세 갈래가 거의 갈라진다.

먹튀검증 자료를 뒤지는 건 그다음이다. 이때 검증 정보는 어디가 좋은지 고르려고 보는 게 아니라, 특정 도메인이 언제부터 다른 이름으로 언급되기 시작했는지 날짜를 맞춰보는 용도로만 쓴다. 주소 이력을 날짜 단위로 남기는 기록이 있으면 교체 시점 추정이 훨씬 빨라지고, 링크모음에 올라온 후보들 중 어느 것이 그 시점 이후 등장했는지도 구분된다.

그 뒤로 바꾼 주소 기록 방식과, 다시 만났을 때의 첫 10분

사흘을 날린 뒤로 즐겨찾기에 주소만 두지 않는다. 같은 폴더에 메모 하나를 함께 저장한다. 내용은 네 줄이다. 마지막 정상 접속 날짜, 그때의 네임서버 이름, 인증서 발급 기관과 발급일, 파비콘 모양. 새 화면이 떴을 때 대조할 기준선이 없으면 모든 판단이 느낌으로 흐른다. 메모는 접속이 잘 되는 평온한 날에 한 달에 한 번 갱신한다. 사고가 난 날 처음 기록을 만들려 하면 비교할 과거가 남아 있지 않다.

기준선이 생기자 판정이 3분으로 줄었다. 두 달 뒤 비슷한 화면을 다시 만났을 때는 자물쇠를 눌러 발급 기관이 메모와 같다는 걸 확인하고, 없는 서브도메인이 인증서 경고를 내는 것까지 보고 진짜 점검이라고 결론 냈다. 다섯 시간 뒤 정상화됐고, 나는 그동안 엉뚱한 후보 주소를 찾아 헤매지 않았다. 순서는 이렇게 굳었다. 다른 망에서 열기, 없는 서브도메인 붙이기, 인증서 발급일 보기, 네임서버 조회. 5~7분이면 끝나고 네 신호 중 둘 이상이 메모와 어긋나면 폐기 대상으로 분류한다.

마지막으로 옛 주소를 즐겨찾기에서 지우기 전에 화면을 한 번 캡처해 날짜와 함께 남긴다. 같은 도메인이 나중에 다른 얼굴로 되살아날 때 대조 자료가 되기 때문이다. 실제로 그 회색 점검 페이지는 2주 뒤 광고 링크가 빼곡한 화면으로 바뀌었다. 점검이 끝나기를 기다렸던 그 주소의 정체가, 캡처 두 장을 나란히 놓고 보니 그제야 눈으로 확인됐다.