도메인이 깨끗해 보이는 순간에도 과거는 길게 흔적을 남긴다. 먹튀 사이트 운영자들이 이름만 갈아입고 돌아오는 이유가 여기에 있다. 로고를 바꾸고 UI를 손봐도 도메인과 인프라 기록은 쉽게 지울 수 없다. 제대로 된 먹튀검증은 사이트의 현재 상태만 보는 게 아니라, 도메인이 걸어온 발자국을 더듬어야 한다. 이 글은 그 발자국을 어떻게 효율적으로, 그리고 증거력 있게 추적할지에 대한 실무 가이드다.
왜 도메인 히스토리를 보나
피해 제보가 한두 건 올라왔다고 바로 단정하는 건 위험하다. 다만 운영자가 동일하고 전형적인 먹튀 패턴과 연결된다면 얘기가 달라진다. 그 연결고리를 만드는 가장 강력한 수단이 도메인 히스토리, 즉 등록 정보, 네임서버와 IP 이동, 인증서 내역, 과거 콘텐츠의 변화다. 이 조각들을 시간 순으로 맞추면 다음 사실이 드러난다. 첫째, 누가, 언제, 어떤 인프라를 썼는지. 둘째, 관련 사이트들과의 연결성. 셋째, 갑작스러운 도메인 세탁이나 증거 인멸 시도의 타이밍. 실무에선 이 세 가지가 결합될 때 신뢰도 높은 결론을 낼 수 있다.
빠르게 훑어보기, 깊게 파보기
현장에서 의심 사이트를 받으면 보통 두 단계를 거친다. 첫 10분은 스크리닝을 한다. whois와 rdap으로 등록일과 등록대행사의 형태를 보고, name server와 IP를 확인하고, 인증서의 발급자와 SAN 목록을 살핀다. 동시에 Wayback Machine에서 과거 화면을 대략 타임라인으로 챙긴다. 이 정도면 신호가 강한지 약한지 감이 온다. 이후 신호가 강하면 수시간을 들여 패시브 DNS, 서브도메인 인벤토리, 인증서 투명성 로그, 연결된 ASN과 호스팅 사업자 내 이사 이력까지 꿰어 한 묶음으로 만든다. 이 두 단계의 리듬을 익히면 쓸데없이 에너지를 낭비하지 않는다.
데이터 소스의 신뢰도와 한계
데이터는 출처마다 왜곡과 공백이 있다. whois는 GDPR 이후로 개인 정보가 비공개 처리되는 경우가 많고, 국내외 레지스트리마다 제공 범위가 다르다. RDAP은 구조화돼 편하지만, 오래된 변동 이력을 상세히 주진 않는다. 패시브 DNS는 수집 지점과 커버리지에 따라 누락이 있다. Wayback Machine은 robots 규칙과 사이트 차단 요청 때문에 공백 구간이 생긴다. 인증서 투명성 로그는 대체로 충실하지만 와일드카드와 멀티 SAN 때문에 진짜 연결성을 과대평가할 때가 있다. 이런 한계를 알고 서로 보완하는 게 핵심이다.
현장에서 자주 쓰는 도구와 서비스
보편적인 툴로도 절반은 간다. 커맨드라인에서 whois, dig, nslookup, curl, openssl s_client로 기본 신호를 받는다. 브라우저에선 Wayback Machine, crt.sh, SecurityTrails나 WhoisXML, DomainTools 같은 상용 서비스로 히스토리와 패시브 DNS를 훑는다. VirusTotal의 도메인 탭은 수집된 서브도메인과 해시 연결을 보기 좋게 정리해준다. 무료만으로는 한계가 있지만, 케이스 규모에 따라 상용 데이터가 시간을 아껴준다.
첫 화면에서 뽑아낼 수 있는 것들
사이트에 접속했을 때 HTTP 응답 헤더부터 의미가 있다. 서버 서명과 HSTS 정책, 캐시 설정, CDN 특유의 헤더는 인프라 구성을 드러낸다. 예를 들어 Cloudflare라면 cf-ray, server: cloudflare 같은 문자열이 보인다. 오리진이 숨겨져 있을 가능성이 크니, 과거에 Cloudflare 앞단으로 옮기기 전의 오리진 IP를 패시브 DNS나 과거 스냅샷에서 찾아야 한다. TLS 인증서는 발급자와 일련번호, SAN 목록을 체크하되, 동일한 조직이 관리하는 여러 도메인을 한 번에 커버하는 발급 패턴을 보면 연결고리가 생긴다. 특히 무료 인증서라도 발급 시각과 재발급 주기를 타임라인에 얹으면 이전 프로젝트와 재활용된 흔적이 보인다.
등록 정보의 맥락 해석
whois와 RDAP에서 보는 건 단순히 등록일만이 아니다. 레지스트리, 레지스트라, 네임서버, 등록인 보호 서비스 사용 여부, 상태 코드(clientTransferProhibited 등), 갱신 주기, 그리고 대행사의 특이한 고객 패턴이다. 예컨대 짧은 기간에 비슷한 구문을 가진 도메인 여러 개가 동일 레지스트라와 동일 네임서버 범위를 공유한다면 운영 주체가 하나일 공산이 크다. 국내 피해가 많았던 케이스 중엔 등록자는 개인정보 보호로 가려져 있었지만, 동일한 프라이버시 프록시 이메일 패턴이 반복적으로 등장해 클러스터링이 가능했다. 또 등록일 직후 며칠 내에 네임서버가 두어 번 바뀌었다면, 구축 과정에서 급히 인프라를 돌렸다는 의미일 수 있다.
DNS와 인프라의 시간 축 만들기
도메인 히스토리는 결국 시간 축 싸움이다. 언제 어떤 IP에 매핑됐는지, 어느 네임서버를 썼는지, 서브도메인이 어떻게 늘고 줄었는지를 날짜별로 늘어세워야 한다. 패시브 DNS는 여기서 핵심이다. SecurityTrails나 PassiveTotal 같은 서비스에서 A, AAAA, NS, MX, TXT 레코드의 변동 내역을 뽑아 범위를 좁힌다. 이 변동을 BGP와 ASN 정보, 호스팅 사업자 공지와 교차시키면, 값비싼 전용 서버에서 저렴한 공유 호스팅으로 갑자기 옮긴 변화나, 반대로 트래픽을 감추기 위해 CDN을 앞세운 흐름이 보인다. 먹튀 패턴에선 대개 오픈 직후엔 공격을 피하려 CDN을 쓰다가, 운영 막바지엔 비용을 줄이거나 흔적 지우기 위해 다른 리셀러 네임서버로 흩어지는 일이 잦았다.
콘텐츠 히스토리, 이미지까지 챙기기
Wayback Machine은 단순한 스크린샷 저장소가 아니다. 아카이브된 HTML과 자바스크립트, 이미지 경로까지 내려받으면, 외부 스크립트 출처, 결제 위젯 도메인, 고객센터 채널 링크 같은 실마리가 튀어나온다. 과거 배너 이미지의 파일명 패턴이 새 사이트에서도 반복되는 경우가 많다. 이미지 해시를 만들어 비교하면 운 좋게 일치한다. 특정 케이스에선 footer의 고객센터 텔레그램 링크가 도메인만 바뀐 새 사이트에도 같은 핸들로 남아 있어, 두 사이트를 같은 운영팀으로 묶을 수 있었다. 이런 정황은 법적 판단의 직접 증거는 아니어도, 먹튀검증 리포트에서 독자들이 이해하기 쉽게 보여주는 데 큰 힘이 된다.
인증서 투명성 로그로 옆문 찾기
crt.sh와 Certificate Transparency 로그는 같은 시기에 발급된 인증서들을 한데 끌어올 수 있다. 와일드카드 인증서를 발급받은 시점과 SAN 항목을 보면, 운영자가 어떤 도메인을 묶어서 관리했는지 윤곽이 생긴다. 예컨대 도메인 A의 인증서에 서브도메인 pay.example-a.com이 있었고, 비슷한 시점에 도메인 B의 인증서에도 pay.example-b.com이 있었다면, 두 사이트가 같은 결제 모듈 벤더를 쓰는 단서가 된다. 더 나아가 발급 로그에 고유한 조직명이나 이메일이 노출된 경우, 그 문자열로 다른 인증서까지 확장 검색해 덩어리를 키울 수 있다.
공격자도 방어한다, 흔한 회피 전술
도메인 세탁은 빠르고 대담하다. 자주 보이는 건 disposable TLD 사용, 빈번한 네임서버 교체, Cloudflare나 Imperva로의 급격한 전환, 그리고 리버스 프록시 뒤에 숨긴 오리진의 수시 교체다. 도메인을 갈아치우면서 사용자 데이터 마이그레이션을 위해 동일한 GA 측정 ID나 페이스북 픽셀 ID를 재사용하는 실수가 종종 나온다. 이런 트래킹 ID는 소스 보기에서 금방 드러난다. 또 한 가지, DNS의 TTL을 비정상적으로 낮춰 패시브 DNS가 충분히 수집하지 못하게 만드는 수법이 먹튀검증 있는데, 이럴 땐 짧은 주기로 직접 쿼리를 던져 변화 폭을 잡거나, 사용자 제보 시간을 기준으로 앞뒤 며칠의 스냅샷을 집중적으로 모은다.
현업 워크플로, 40분 버전
아래 순서는 혼자서도 소화 가능한, 재현성 높은 빠른 점검 흐름이다.
- 도메인 소유 및 등록 이력 확인: whois, RDAP로 등록일, 레지스트라, 네임서버를 적고, 프라이버시 보호 여부와 상태 코드를 기록한다. DNS와 인프라 스냅샷: dig A/NS/MX/TXT, 패시브 DNS로 과거 IP와 NS 이동을 타임라인으로 만든다. ASN과 호스팅 사업자까지 표기한다. 과거 콘텐츠 확인: Wayback Machine에서 최소 분기별 화면을 보고, 외부 스크립트, 결제 링크, 고객센터 채널을 메모한다. 인증서와 서브도메인 인벤토리: crt.sh로 인증서 이력과 SAN 목록을 뽑고, VirusTotal이나 SecurityTrails에서 서브도메인을 모아 교차한다. 연결성 교차검증: 공통 이메일, 트래킹 ID, 이미지 해시, 동일 CDN 설정을 찾아 클러스터링하고, 참조 링크와 날짜를 붙여 도식화한다.
이 다섯 단계면 표면적으로 멀쩡한 도메인이라도, 과거의 그림자가 있는지 상당수는 드러난다.
신호의 해석, 어디서 선을 긋나
먹튀검증은 단순 체크리스트가 아니라 해석의 기술이다. 같은 데이터라도 맥락에 따라 결론이 달라진다. 예를 들어 동일한 호스팅 사업자를 쓴다고 해서 곧장 동일 운영자로 볼 수는 없다. 대형 CDN과 리셀러 네임서버는 수십만 도메인이 공유한다. 반대로 작은 리셀러의 프라이빗 네임서버와 유사한 네이밍 규칙, 인증서 발급 주기, 결제 스크립트의 도메인 패턴이 반복된다면 연결 가능성이 높다. 나는 보통 강한 신호 1개와 중간 강도 신호 2개 이상이 일치할 때 “높은 가능성”으로 표기하고, 강한 신호 없이 중간 이하가 모여 있을 땐 “추가 관찰”로 둔다. 강한 신호의 예로는 동일한 트래킹 ID, 동일한 고객센터 핸들, 동일한 결제 게이트웨이 서브도메인의 재사용을 든다.
사례 스케치, 어떻게 실마리를 엮나
몇 해 전, 스포츠북 형태의 신규 사이트가 광고를 대대적으로 집행했다. 도메인은 신규 등록, Cloudflare 앞단, whois는 프라이버시 보호. 표면만 보면 깨끗했다. Wayback Machine엔 기록이 거의 없었다. 결정적 실마리는 TLS 인증서의 SAN이었다. 와일드카드와 함께 독특한 로깅 서브도메인이 포함돼 있었고, 그 이름 규칙이 과거 먹튀로 마무리된 다른 도메인과 거의 일치했다. crt.sh에서 해당 규칙을 역으로 검색하니 같은 해 3월 비슷한 묶음이 여럿 나왔다. 패시브 DNS를 돌리니 그중 두 개가 잠시 Cloudflare 앞에서 벗어나 특정 ASN의 베어메탈 IP로 노출된 적이 있었다. 그 IP 대역을 훑자 비공개 디렉터리에 운영팀이 올려둔 테스트용 자바스크립트가 남아 있었고, 내부 슬랙 웹훅 주소 일부가 하드코딩돼 있었다. 그 슬랙 워크스페이스 아이디는 피해 제보가 많았던 과거 도메인의 번역 파일에 포함된 값과 일치했다. 이 정도면 강한 신호가 된다. 실제로 두 달 뒤, 신규 사이트 고객센터가 동일 텔레그램 핸들로 전환되며 먹튀로 마감됐다.
자동화로 시간을 아끼는 방법
반복 작업은 스크립트로 묶는 게 답이다. 입력된 도메인에 대해 순차적으로 RDAP, dig, crt.sh API, 선택한 패시브 DNS API를 호출하고, 날짜별로 이벤트 라인에 정렬해주는 작은 도구만 있어도 분석 속도가 크게 빨라진다. HTML 보고서로 뽑아 스냅샷 링크와 인증서 일련번호, A/NS 레코드 변경점을 묶어 보여주면 팀 커뮤니케이션도 매끄럽다. 단, API 호출 빈도와 이용 약관을 준수해야 한다. 과도한 스크래핑은 차단이나 법적 문제로 이어질 수 있다.
법적, 윤리적 경계선 지키기
먹튀검증이라 해도 사적 제재는 금물이다. 공개 데이터 수집은 합법적이지만, 비인가 접근이나 시스템 취약점 스캐닝은 선을 넘는다. 개인정보 노출 가능성이 있는 자료를 다룰 땐 마스킹 원칙을 지켜야 하며, 제보자의 신원 보호는 기본이다. 또한 리포트를 공개할 때는 사실로 확인된 부분과 추정에 근거한 연결을 명확히 구분하고, 반론 제기의 채널을 열어둔다. 실제로 잘못된 동일인 추정으로 인한 분쟁은 적지 않다. 도메인과 인프라 신호는 확률적 연결일 뿐 확정 판결이 아니다.
흔한 함정과 반례
CDN 앞단만 보고 인프라가 같다고 단정하면 낭패를 본다. Cloudflare, Akamai, Fastly는 모두 거대한 공유 인프라다. 이메일 MX가 구글 워크스페이스라고 해서 운영사가 같다는 뜻도 아니다. 반대로 작은 것들, 예컨대 favicon의 해시, 약관 문구의 고유한 오탈자, 특정 시간대에만 열리는 고객센터 운영 패턴이 신뢰도 높은 단서가 된다. 또 TLD 자체의 정책 변화로 whois 포맷이 크게 바뀐 시기가 있어, 그 이전과 이후 데이터를 같은 방식으로 비교하면 왜곡이 생긴다. 시간 축을 세울 때는 포맷 변화도 메모해두는 습관이 필요하다.
증거 보전과 재현성
먹튀 의심을 공론화하려면 누가 봐도 따라할 수 있게 남겨야 한다. 날짜와 시간대를 UTC로 통일하고, 각 주장 옆에 근거 URL과 캡처 파일명을 적는다. 가능한 한 원본에 가까운 형태, 예컨대 인증서 PEM, dig +trace 결과 원문, Wayback의 스냅샷 식별자처럼 변조 우려가 낮은 것들을 첨부한다. 나중에 대상 사이트가 내용을 바꿔도, 검증자는 링크와 해시를 통해 같은 화면을 재현할 수 있어야 한다. 상용 데이터의 인용은 이용 약관 범위 내에서, 스크린샷이나 요약 수치로 대체한다.
위험 신호를 짧게 점검하고 싶을 때
- 등록 초기부터 프라이버시 보호, 잦은 네임서버 변경, 짧은 TTL로 불안정한 DNS 운영을 보이는 경우 TLS 인증서의 재발급 주기가 비정상적으로 짧고, SAN에 불필요하게 많은 도메인이 묶여 있는 경우 Wayback에 공백이 많거나, 약관과 정책 페이지가 스냅샷에서 반복적으로 지워진 경우 소스 코드에 동일한 분석 스크립트 ID, 고객센터 링크, 결제 서브도메인 패턴이 과거 사례와 일치하는 경우 패시브 DNS상 오리진 IP가 알려진 고위험 호스팅 대역으로 반복 이동한 경우
이 다섯 가지는 단독으로 결론을 내리기보다, 강한 의심의 출발점으로 쓰기 좋다.
국내 환경의 특수성
국내 도메인과 호스팅 시장은 몇몇 대형 사업자 중심으로 돌아간다. 동일 사업자 내에서도 리셀러 레이어가 두껍기 때문에 단순히 네임서버 접두사만 보고 묶으면 오판할 수 있다. 또한 법적 분쟁 가능성 때문에 일부 아카이브 서비스가 국내 사이트의 스냅샷 접근을 제한하는 경우도 있다. 이런 제약을 감안해 국내 커뮤니티 제보와 현지화된 위법성 판단 기준을 병행하는 것이 안전하다. 예를 들어 전자금융 관련 문구의 표기 방식, 고객센터 운영 시간대와 상담 톤은 문화권마다 차이가 있어 해외 사례와 동일 잣대를 들이대면 빗나간다.
데이터 결합의 순서와 무게중심
모든 신호를 같은 무게로 다루지 않는다. 나는 보통 시간 축을 기준으로 세 덩어리로 나눈다. 오픈 전후 7일, 운영 중 피크 기간, 종료 직전 7일. 오픈 전후에는 인프라 구성의 급격한 변화가 많아 흔적이 가장 분명하다. 피크 기간에는 마케팅과 고객 유입 채널을 통해 외부 링크와 스크립트가 풍부해진다. 종료 직전에는 비용 절감과 흔적 지우기로 인해 리다이렉트 체인, 302 남발, 약관 페이지 삭제 같은 전형 패턴이 보인다. 같은 신호라도 어느 구간에서 나왔느냐에 따라 신뢰도가 달라진다.
기술 깊이 더 들어가기
- Reverse IP와 가상호스팅 지표: 동일 오리진 IP에서 호스팅되는 다른 도메인을 모아보면, 운영자가 테스트용으로 올려둔 숨은 사이트가 튀어나온다. 단, 공유 호스팅 환경에선 노이즈가 많으니 도메인 생성 시점이 비슷한 것만 추린다. HTTP/2, HTTP/3 설정과 ALPN: 서버가 지원하는 프로토콜 조합이 의외로 조직마다 패턴이 있다. 예전엔 TLS1.0, 1.1 잔존 여부가 좋은 구분자였다. 최근엔 H3 도입 타이밍과 QUIC 설정이 단서가 된다. 보안 헤더 채택 패턴: Content Security Policy나 Referrer Policy의 세부 지시어는 개발팀의 습관을 드러낸다. 정책 문자열이 거의 동일하다면 코드 베이스 공유 가능성을 의심해본다.
이런 지표는 단독으로 결론을 내리진 않지만, 모자이크의 빈 칸을 채우는 역할을 한다.
비용 대비 효율, 어디에 시간을 쓸까
무료 도구만으로도 60에서 70퍼센트는 판별 가능하다. 상용 데이터는 대량 케이스, 법적 리스크가 큰 공표, 또는 반박 가능성이 높은 대상에만 투입하는 게 합리적이다. 패시브 DNS의 과거 커버리지와 인증서 로그의 질은 유료가 확실히 낫다. 반면 단발성 검증에서 굳이 비싼 브랜드 모니터링을 쓸 필요는 없다. 반복되는 프로젝트라면 보고서 자동화와 스냅샷 보관 시스템에 예산을 먼저 배정하는 편이 성과로 돌아온다.
팀 협업과 역할 분담
먹튀검증은 데이터 수집, 해석, 스토리텔링의 세 축이 맞물린다. 수집 담당은 API 키 관리와 쿼리 파이프라인을 다듬고, 해석 담당은 시그널의 강약을 정량화해 기준선을 만든다. 스토리텔링 담당은 냉정한 톤으로 리포트를 구성하고, 독자가 따라 할 수 있도록 증거 링크를 정리한다. 소규모 팀이라면 역할이 겹치더라도, 최소한 리뷰 라운드 하나는 분리해 자기 득점과 편향을 줄인다. 과거 사례 라이브러리를 유지하면 새로운 도메인을 볼 때 비교가 빨라진다.
최종 리포트에 담아야 할 것
리포트는 길다고 좋은 게 아니다. 요약 섹션에 판단 등급과 핵심 근거 3개, 영향을 받는 사용자의 범위 추정, 권고 조치를 넣는다. 본문에는 타임라인, 데이터 출처 표기, 반례 검토 섹션을 둔다. 그리고 거짓 양성 가능성을 논의하는 문단을 넣는다. 이 문단이 있으면 독자가 리포트를 신뢰하기 쉽다. 마지막으로 업데이트 정책을 명시한다. 반론이나 정정 요청이 들어올 경우 검증과정을 어떻게 밟을지 투명하게 써두면 불필요한 분쟁을 줄인다.
남는 것은 습관과 기록
도메인 히스토리 추적은 기술 장비보다 습관의 문제에 가깝다. 방문 즉시 헤더를 본다, 인증서 정보를 복사해둔다, 타임라인을 먼저 그린다, 근거 없는 단정은 적지 않는다, 공백은 공백으로 남겨둔다. 이런 기본기가 쌓이면 케이스별 편차가 줄고, 먹튀검증의 품질이 고르게 유지된다. 무엇보다도, 사용자 피해를 최소화하려면 빠르면서도 신중해야 한다. 도메인 하나의 과거를 제대로 읽어내는 힘은 그 균형에서 나온다.
먹튀는 이름을 바꾸고, 도메인은 옷을 갈아입는다. 하지만 DNS는 말이 많고, 인증서는 거짓말을 못 한다. 히스토리를 읽는 사람에게 과거는 현재를 비춘다. 이 기본 원리를 잊지 않는 한, 도메인 세탁은 점점 더 어려워질 것이다.
