먹튀검증 오픈소스 도구 모음집

온라인 베팅과 사설 거래 커뮤니티에서 문제가 터지는 장면은 늘 비슷하다. 홍보방에서 당일 고수익을 외치던 사이트가 갑자기 고객센터를 닫고, 출금 대기 상태로 묶인 내역만 남긴 채 사라진다. 분쟁 글이 커뮤니티를 도배하고, 텔레그램 방에는 새 도메인 공지와 함께 재가입 유도 메시지가 뜬다. 민원이 접수되기 전, 아니 사건이 커지기 전 단계에서 위험 신호를 읽어내고 퍼지는 속도를 늦추는 일, 그것이 바로 실전 먹튀검증이다. 이 글은 현장에서 반복 검증을 돌려본 경험을 토대로, 비용 부담이 적고 재현 가능한 오픈소스 도구들을 정리하고, 어떻게 엮어 쓰면 효율이 높아지는지까지 보여준다.

왜 오픈소스인가

먹튀검증은 속도와 증거력이 둘 다 필요하다. 속도가 없으면 이미 광고가 퍼지고, 증거가 없으면 소문과 비난의 공방만 남는다. 오픈소스 도구는 몇 가지 장점이 뚜렷하다. 첫째, 자동화와 확장이 쉽다. 스크립트에 맞춰 조합하고, 조직이 커질수록 파이프라인을 복제해 배포할 수 있다. 둘째, 투명하다. 검증 기록과 코드가 남으니, 나중에 분쟁이 생겨도 절차를 객관적으로 설명할 수 있다. 셋째, 비용이 예측 가능하다. 유료 API가 섞여 있더라도 핵심은 무료 컴포넌트로 굴러간다.

상업 서비스에도 유용한 것이 많지만, 여기서는 원칙적으로 오픈소스로 공개되어 있고, 로컬이나 자체 서버에서 돌릴 수 있는 것들을 중심으로 다룬다. 외부 웹 서비스는 보조 자료로만 언급한다.

기본 프레임: 무엇을 봐야 리스크가 보이나

먹튀 사이트의 외형은 세탁되기 쉽다. 템플릿을 사서 로고만 바꿔 붙이고, 공지 채널을 새로 만들어도, 깊게 들여다보면 몇 가지 신호는 자주 반복된다. 도메인 인프라가 짧은 주기로 교체되고, 과거 사칭 사이트와 연결된 인증서가 재사용되며, 결제 경로가 익명화 지갑으로 수렴한다. 광고 카피는 이름만 바꿔 돌려쓰고, 고객센터는 비영구 메신저 계정으로 운영된다. 기술적 지표와 사람 냄새 나는 단서를 함께 모아 교차 검증하면, 신뢰도 평정이 빨라진다.

범위를 무한히 넓히면 체력이 먼저 바닥난다. 실제로는 도메인과 네트워크, 웹 애플리케이션 행태, 결제 경로, 평판 신호의 다섯 묶음을 우선 본다. 그 다음 의심이 커질 때 내부 링크, 복제 콘텐츠, 커뮤니티 활동까지 확장한다. 오픈소스 도구를 고를 때도 이 다섯 축을 따라가면 낭비가 적다.

오픈소스 기반 파이프라인, 뼈대만 정확히 잡아두기

먹튀검증은 사람이 하는 일 같지만, 반복을 기계로 밀어주는 순간 속도가 달라진다. 최소한의 자동화 파이프라인을 단단히 만들어두면, 초동 점검에 드는 시간을 절반 이하로 줄일 수 있다.

다음 다섯 단계만 표준화해도 체감 효율이 크다.

수집: 대상 도메인, 앱 패키지명, 공개된 연락처와 결제 주소를 입력 받아 원시 데이터를 긁어온다. 정규화: 도메인은 루트와 서브도메인으로 분해하고, IP는 ASN, 국가, 호스팅 범주로 태깅한다. 분석: 하위도메인, 인증서, 포트, HTTP 지문, 스크립트 소스, 지갑 패턴을 룰로 평가한다. 상관: 과거 사건 DB, 내부 블랙리스트, 커뮤니티 제보와 그래프 형태로 엮어 연결 강도를 계산한다. 리포트: 스냅샷과 명령 실행 로그, 스코어와 근거 링크를 한 묶음으로 보관한다.

각 단계에 배치할 도구만 고르면 된다. 아래에서 범주별로 구체적인 선택지를 살펴본다.

도메인과 인프라: 소유, 이동, 흔적

도메인이 자주 갈아치워지는지, 같은 운영자가 여러 브랜드를 돌리는지, 흔적은 인프라에서 먼저 드러난다. 기본은 WHOIS와 RDAP이다. 리눅스 환경이면 whois 클라이언트와 rdap 툴을 함께 갖추고, 파이썬을 쓴다면 python-whois와 ipwhois가 유용하다. RDAP는 개인정보 비공개가 기본인 시대에도 레지스트리와 리셀러 체인을 거슬러 올라갈 실마리를 준다. 자동화에는 OWASP Amass가 사실상 표준이다. 수동과 자동을 함께 쓸 때 진가가 나온다. Amass는 하위도메인 수집뿐 아니라 ASN, 네임서버 변천, 관계 그래프까지 한 번에 그린다. 같은 계열의 ProjectDiscovery 도구군인 subfinder, dnsx, httpx를 이어 물리면 넓고 얕은 초동 탐색을 빠르게 끝낼 수 있다.

image

포트 스캔은 nmap과 masscan 조합을 권한다. masscan으로 대역을 빠르게 훑고, 유의미한 포트만 nmap의 서비스 지문으로 재확인하면 속도와 정확도가 균형을 맞춘다. TLS 관련 단서는 testssl.sh가 믿을 만하다. 인증서 체인, 취약 암호군, OCSP, ALPN 같은 세부를 로컬에서 뽑아낸다. 인증서 재사용을 보려면 certstream 라이브러리로 실시간 CT 로그를 수집해 내부 색인에 쌓는 편이 낫다. crt.sh 같은 공개 검색기는 훌륭하지만, 로컬 색인이 있어야 과거와 현재를 함께 비교한다.

다음은 실제로 자주 쓰는 조합이다. 신규 제보 도메인이 들어오면 subfinder로 하위도메인을 긁고, httpx로 응답 서버와 타이틀, 상태 코드를 받는다. 같은 순간 testssl.sh로 인증서 먹튀검증 서브젝트와 SAN을 추출해 내부의 인증서 지문 컬렉션과 비교한다. 과거 사건에서 수집해둔 SHA256 지문과 겹치면 우선순위가 바로 올라간다. 이 과정을 한 번 돌리는 데 1분을 넘기지 않는다.

웹 동작과 크롤링: 보이는 것 너머를 본다

먹튀 사이트는 프런트만 바꾸고 백엔드는 재활용하는 경우가 많다. 자바스크립트 번들, 라우팅 규칙, 정상 플로우에서만 노출되는 API 엔드포인트가 같은 계열을 드러낸다. 정적 취득에는 curl과 wget으로 충분하지만, 렌더링 기반 사이트는 headless 브라우저가 필요하다. Playwright는 안정성과 언어 바인딩이 좋아 현장 채택률이 높다. 간단한 스크립트로 UA와 뷰포트, 스텔스 모드, 쿠키 정책을 통제할 수 있어, 초동 탐색에 안성맞춤이다. Puppeteer도 대안이지만, 다양한 브라우저 채널을 한 번에 다루기에는 Playwright가 편했다.

네트워크 흐름은 mitmproxy로 중간에서 잡는다. 브라우저를 미트엠 프록시에 물리고, 인증서 신뢰를 세팅한 뒤 회원가입과 충전 플로우를 실제로 밟는다. 여기서 결제 모듈의 외부 호출, 제3자 스크립트의 출처, 에러 처리 패턴이 드러난다. 가령 결제 시점에 특정 도메인의 iframe을 강제로 삽입한다면, 그 도메인의 과거 히스토리를 별도로 추적해야 한다. 또, DevTools 프로토콜과 mitmproxy 이벤트 훅을 함께 써서 로그인 직후 호출되는 내부 API 목록을 뽑아두면, 서버 경로 체계가 유사한 도메인을 나중에 묶어내기 쉽다.

간단한 예시로, 렌더링 후의 DOM 스냅샷과 네트워크 로그를 함께 남기는 스크립트를 자주 돌린다.

from playwright.sync_api import sync_playwright def snapshot(url, out_prefix): with sync_playwright() as p: browser = p.chromium.launch(headless=True, args=["--disable-web-security"]) ctx = browser.new_context(user_agent="Mozilla/5.0 eat-verify") page = ctx.new_page() requests = [] page.on("request", lambda r: requests.append((r.method, r.url))) page.goto(url, wait_until="networkidle", timeout=45000) html = page.content() with open(f"out_prefix.html", "w", encoding="utf-8") as f: f.write(html) with open(f"out_prefix.req", "w", encoding="utf-8") as f: for m, u in requests: f.write(f"m u\n") browser.close() snapshot("https://example-bet.site", "example-bet")

이렇게 남긴 HTML은 trafilatura나 readability-lxml로 정제해 텍스트만 추출하고, 스크립트 경로와 CSS 파일 경로는 별도 색인에 쌓는다. 경로 패턴이 같은 사이트를 군집화하면, 브랜드만 바꿔 돌리는 계열 운영을 빨리 잡아낸다.

콘텐츠 단서와 복제 탐지

광고 카피와 공지문은 운영진의 습관을 숨기기 어렵다. 비슷한 문장과 오탈자, 날짜 표기 관례가 그대로 남는다. 오픈소스 simhash 구현체를 이용해 공지 텍스트를 지문처럼 만들고, Hamming 거리 기준으로 유사 문서를 찾는다. 파이썬에서는 simhash, datasketch, textdistance 같은 라이브러리가 있다. 단순한 shingle 크기와 해시 개수 튜닝만으로도 고유성과 재사용의 경계를 그릴 수 있다.

이미지에 박힌 워터마크나 템플릿도 단서가 된다. OpenCV와 perceptual hashing 라이브러리인 imagehash를 묶어 쓰면, 로고만 바뀐 홍보 이미지가 한 계열에서 재활용되는 패턴을 잡아낸다. 실제 현장에서는 jpeg 압축률, 크기 비율을 제각각 달리 올리기 때문에, pHash와 aHash를 함께 보고, 임계값을 다소 넉넉하게 둔다. 유사 이미지 매칭이 수십 건으로 모이면, 텔레그램과 블로그 채널 간의 공유 경로도 가늠할 수 있다.

결제 경로: 돈이 흐르는 길을 좇는다

먹튀검증의 핵심은 결제다. 충전과 출금이 어떻게 이루어지는지, 외부 결제 모듈이 누구 것인지, 암호화폐 주소가 노출되는지. 카드 결제의 경우, 프런트에서 원격 스크립트를 끌어오거나 리다이렉트하는 도메인을 잡아내면, 그 결제 대행사가 허용하는 가맹 범주와 상충하는지 점검할 수 있다. 국내외 대행사의 Acceptable Use Policy와 비교해 차이를 적는다.

암호화폐 주소가 노출되면 추적이 수월해진다. API 서비스 의존을 줄이려면, 웹3 생태계의 오픈소스 라이브러리를 직접 호출하는 편이 안정적이다. 이더리움 계열은 web3.py와 eth_utils로 트랜잭션과 토큰 전송 이력을 읽어들일 수 있다. 비트코인은 python-bitcoinlib와, 자체 노드가 없다면 esplora 호환 엔드포인트를 붙여 읽어온다. 한 번 받은 입금 주소가 여러 도메인에서 재사용되는지, 입금 이후 분산 패턴이 서비스 믹서와 유사한지, 입금 태그와 시간대가 같은 운영 시간을 가리키는지 등을 본다. 여기서는 요약 정보보다 로우 데이터가 중요하다. 트랜잭션 수, 유입 UTXO의 주소군, 라벨링 여부를 전부 적어두면, 나중에 교차 사건에서 재발견이 쉽다.

평판 OSINT와 그래프

열린 인터넷의 신호를 모아 유의미한 구조로 바꾸는 데는 SpiderFoot이 단단하다. 자체 모듈로 도메인, IP, ASN, 이메일, 소셜 링크를 추출하고, 외부 소스와 결합해 엔티티를 확장한다. 오픈소스라 로컬에서 돌리며 내부 데이터베이스와 연결하기 좋다. 위협 인텔과 사건 지표를 체계적으로 다루려면 MISP와 OpenCTI가 안전한 선택이다. 둘 다 커뮤니티가 크고, 지표 버전 관리와 공유 권한이 명확하다. 먹튀 사건의 IoC는 전통적인 악성코드류와 다르게 다룰 필요가 있지만, 해시, 도메인, 인증서, 텔레그램 채널 ID 같은 지표를 STIX로 표현해두면, 팀 간 교차 분석이 쉬워진다.

시각화에는 graphistry나 Gephi를 자주 쓴다. 인증서, 하위도메인, IP, 결제 주소를 노드로 두고, 재사용을 엣지로 표현하면, 계열 간 거리가 눈으로 보인다. 현장에서 의미 있는 임계값은 엣지의 수가 아니라 신뢰도의 곱이다. 예컨대 인증서 지문이 같고, 하위도메인 패턴이 70퍼센트 이상 일치하며, 동일한 텔레그램 운영 계정이 발견되는 경우를 우선순위 상단에 올린다.

자동화 스캐닝, 선을 넘지 않는 선에서

취약점 스캐닝은 민감하다. 검사의 목적은 침투가 아니라 표면 행태를 확인하는 데 있다. OWASP ZAP의 Baseline 스캔은 공격 페이로드를 최소화해도, 헤더 정책과 보안 설정, 노출된 디렉터리 정도는 충분히 살핀다. ProjectDiscovery의 nuclei는 탐지 템플릿을 고르는 힘이 중요하다. 디렉토리 인덱스, 환경 파일, 테스트 엔드포인트처럼 공개되어서는 안 되는 자산 노출만 체크리스트로 운영하면, 합법성과 실용성이 만난다.

법적 위험을 줄이려면, 항상 사전 동의 범위 내에서 테스트하고, 조치가 필요한 발견은 개인 정보와 결제 정보를 가리지 않은 채 노출하지 않는다. 스냅샷과 로그는 내부 보관을 원칙으로 한다.

수집 기록과 재현성: 나중에 설명할 수 있어야 한다

사건이 불거지면 타임라인이 필요하다. 어느 시각에 어떤 도메인과 인증서를 보았는지, 어떤 페이지에서 어떤 문구를 캡처했는지. 증거가 살아있는 동안 정리해두면, 반박이 나와도 차분하게 대응할 수 있다. 로컬에서는 SQLite로 시작해도 충분하고, 사례가 쌓이면 OpenSearch 같은 검색형 데이터 저장소로 옮긴다. Jupyter 노트북을 써서 탐색형 분석을 기록하고, dvc나 git-lfs로 스냅샷과 모델 파일을 버전 관리하면, 팀원의 환경 차이로 인한 논쟁이 줄어든다.

페이지 캡처는 단일 이미지보다 전체 HTML과 에셋 해시를 함께 남겨야 한다. 나중에 동일 페이지가 부분 수정되었을 때, 무엇이 바뀌었는지를 기계적으로 비교할 수 있다. 사용한 명령과 파라미터를 그대로 복원할 수 있도록, 작은 쉘 스크립트라도 함께 저장한다.

커뮤니티와 메신저 추적

운영진은 공식 사이트보다 텔레그램, 디스코드, 카카오 채널에서 먼저 움직인다. 공지와 새로운 도메인 안내가 여기서 시작되기 때문이다. 텔레그램은 Telethon 라이브러리로 채널 메시지를 수집할 수 있다. 공개 채널과 봇의 ID를 엔티티로 취급해 내부 그래프에 연결하면, 도메인 변경 시퀀스가 그대로 정리된다. 새 도메인이 공개되는 순간을 잡아내면, CT 로그를 통해 인증서 발급과 도메인 등록의 시간차도 계산 가능하다.

블로그와 카페, 단기 홍보 페이지는 Scrapy 같은 프레임워크로 긁어두고, robots.txt와 서비스 약관을 지키는 선에서만 수집한다. yt-dlp는 영상 기반 광고에도 쓰이지만, 다운로드 자체가 민감할 수 있으니 링크와 썸네일 정도만 기록하고, 본문 인용은 캡처와 타임스탬프로 대체하는 편이 안전하다.

도구별 세부 팁과 함정

Amass는 데이터 소스 키를 적절히 섞어야 성능이 나온다. 기본 내장 소스만으로는 최신 변화가 잘 안 잡힌다. 내부에서 운영하는 수동 인풋, 예를 들어 과거 스캔에서 얻은 네임서버, 운영사 특유의 CDN 경로 등을 사용자 소스처럼 주입하면, 발견률이 단숨에 오른다. subfinder도 마찬가지로 커스텀 워드리스트의 영향이 크다.

nmap은 타이밍 파라미터가 민감하다. 대상이 해외 호스팅이고 레이턴시가 높다면, 기본 템포로는 열려 있는 포트조차 놓친다. T4와 T5는 편하나, 부정확한 결과를 만드는 경우가 있다. 실전에서는 T3로 시작해 감으로 올리는 것이 안전하다. testssl.sh는 버전 업데이트가 빈번하니, 도커 이미지로 고정 태그를 쓰고, 내부 결과 파서와 버전을 묶어둔다. 라이브 업데이트에 맞춰 파서를 바꾸면, 과거 결과와의 연속성이 깨지곤 한다.

Playwright는 탐지 회피 옵션이 많아도, 각 사이트의 봇 차단 정책이 다르다. 한 번에 성공하지 않는다고 해서 사람이 직접 본 화면과 다르다는 결론을 서두르지 말 것. 보통은 대기 조건을 networkidle에서 domcontentloaded로 낮추고, 타이머를 몇 초 늘리는 것만으로 충분하다. mitmproxy는 TLS 1.3와 HTTP/2 환경에서 간헐적으로 프레임이 누락되는 경우가 있으니, 중요한 플로우는 브라우저 개발자도구의 HAR도 함께 남기는 습관이 필요하다.

사례 워크스루: 새 도메인, 의심 점수 70에서 출발

하루 저녁, 커뮤니티 제보로 example-bet.site 같은 주소가 올라왔다고 하자. 먼저 RDAP로 등록일을 확인한다. 등록 3일 차, 네임서버는 프리미엄 DNS가 아니라 무명의 리셀러다. subfinder로 하위도메인을 긁으니 www, help, api, payment 네 가지가 보인다. httpx로 타이틀을 뽑아보니 help는 제로보드 계열 기본 페이지와 유사한 타이틀을, payment는 별도 도메인으로 리다이렉트한다.

testssl.sh로 인증서를 살피니 SAN에 stage.example-bet.site가 있다. 브라우저에서 stage를 열면 접근 거부가 뜨지만, DNS A 레코드는 공개다. 같은 IP에 붙은 또 다른 도메인 두 개가 포트 443을 열고 있으며, 타이틀은 각각 슬롯 이벤트, 라이브 카지노 대회 홍보 페이지로 나타난다. 과거 사건 DB에서 인증서 지문을 대조하니, 2달 전의 별도 사건과 동일하다. 의심 점수는 50에서 70으로 올라간다.

Playwright로 회원가입을 시도한다. 인증 메일 없이 가입이 완료되고, 충전 버튼을 누르면 외부 도메인의 iframe이 삽입된다. mitmproxy 로그에서 결제 모듈 호출 URL을 추려내니, 정식 결제 대행사 문서에 등재된 도메인이 아니다. iframe 내부에서 비트코인과 USDT 주소를 보여주고, 카피 후 입금을 유도한다. 화면의 주소 문자열을 정규식으로 추출해 내부 지갑 DB에 넣는다. web3.py로 트랜잭션을 조회하니, 최근 1주일 간 120여 건의 소액 입금이 확인된다. UTXO 클러스터링 기준으로 과거 사건과 일부 겹치는 주소군이 있고, 밤 10시에서 새벽 2시에 유입이 집중된다.

콘텐츠 지문을 위해 공지 사항을 수집한다. simhash를 돌리니 두 달 전 사건의 공지와 거리 6으로, 사실상 동일한 문구다. 이미지hash로 홍보 배너를 비교하니 pHash 거리도 작다. 이쯤이면 내부 정책상 잠정 블랙 태그를 달고, 대외 리포트는 중립적 표현으로 정리한다. 등록일, 인증서 재사용, 비공식 결제 모듈, 암호화폐 주소의 재사용, 공지 텍스트의 유사도를 근거로 적는다. 제보 채널에서는 도메인 계열 전환 가능성을 경고하고, 방문 시 회원정보 입력 자체를 삼가라고 안내한다.

점수화와 우선순위

사람의 직감은 빠르지만 일관된 기준으로는 약하다. 간단한 룰 기반 점수화만 적용해도, 제보가 몰릴 때 판단 순서를 잡아준다. 예를 들어 다음과 같은 가중치를 둔다. 등록 7일 이내 도메인 10점, 인증서 지문 재사용 20점, 비공식 결제 모듈 25점, 암호화폐 주소 재사용 15점, 하위도메인 패턴 유사 10점, 공지 텍스트 유사 10점. 60점을 넘으면 심화 검증으로 승격, 80점 이상은 대외 경고 후보로 분류한다. 이 점수는 기계가 아니라 사람을 돕는 신호다. 사정 변수가 있는 항목, 예컨대 호스팅 회사의 갑작스런 마이그레이션이나 정상 서비스의 테스트 도메인은 감점 근거도 함께 둔다.

룰은 고정되어 있지 않다. 분기마다 사건을 회고하고, 실제 먹튀로 결론난 케이스에서 어떤 신호가 강했는지 다시 회귀한다. 도구도 그에 맞춰 진화시킨다. 인증서 재사용의 가중치가 떨어지면, 대신 텔레그램 운영 계정의 재사용이나 CDN 경로 패턴에 점수를 배분한다.

운영 관점의 팁: 작은 팀, 큰 효과

도구는 많지만 사람은 적다. 작은 팀에서 큰 효과를 내려면, 소유권을 분명히 하고 의존성을 줄여야 한다. 한 사람이 모든 파이프라인을 관리하면 병목이 생긴다. 수집, 분석, 리포트의 세 파트를 나누고, 각 파트의 스크립트와 도커 컴포즈 파일을 분리 배포해두면 누구든 교체 투입이 가능하다. 베이스라인 데이터는 밤 사이에 배치로 갱신하고, 주간으로는 인증서 지문과 하위도메인 색인을 완전 재생성한다. 낮에는 신규 제보와 심화 검증에만 집중한다.

리포트는 사람이 읽는 문서로 끝나지 않게 한다. 모든 근거는 재현 가능한 링크와 커맨드 라인으로 남긴다. 예를 들어 nmap 결과는 XML로, testssl.sh는 JSON으로. Playwright 캡처는 HTML과 HAR를 한 쌍으로. 시간이 지나면, 이런 자취가 팀의 집단지성으로 변한다.

최소 필수 장비를 간단히 정리

도구 이름만 늘어놓아도 현기증이 난다. 초심자 팀이 먼저 깔아두면 좋은 최소 장비를 짧게 정리한다.

    인프라 탐색: OWASP Amass, subfinder, httpx, nmap, testssl.sh 웹 행태 관찰: Playwright, mitmproxy 콘텐츠 분석: trafilatura, simhash, imagehash 평판과 인텔: SpiderFoot, MISP 또는 OpenCTI 데이터와 자동화: SQLite 또는 OpenSearch, Jupyter, docker-compose

여기에 Telethon과 web3.py를 보조로 붙이면, 결제 경로와 커뮤니티 신호까지 수집 범위가 넓어진다. 필요에 따라 masscan, nuclei, Scrapy를 추가한다.

법과 윤리, 그리고 현실적 한계

먹튀검증은 회색지대와 자주 맞닿는다. 합법 플랫폼을 사칭하는 사설 사이트가 섞여 있거나, 개인 정보와 결제 정보가 얽힐 수 있다. 따라서, 접근 권한이 필요한 시스템에는 손대지 않고, 공개면 공개인 만큼만 수집한다. 과도한 요청으로 대상 서버에 부하를 주지 않도록 타이밍과 동시성도 보수적으로 둔다. 결과 공개는 신중해야 한다. 확정적 단어 대신, 관찰된 사실과 근거를 중심으로, 리스크 평가가 어떻게 나왔는지를 투명하게 적는다. 반론 제기가 오면, 로그와 스냅샷으로 차분하게 대응한다.

오픈소스 도구는 만능이 아니다. 상업 데이터베이스가 제공하는 역추적 기능이나, 사설 정보망의 제보 속도를 대체하기 어렵다. 그렇다고 핵심이 약해지지는 않는다. 공개 로그와 인증서, 도메인, 콘텐츠 지문만으로도, 먹튀 의심을 조기 경보하는 체계는 충분히 만들 수 있다. 중요한 것은 루틴과 기록, 그리고 팀의 합의다.

끝맺음 대신, 작은 습관

먹튀검증의 무게는 사건이 아니라 습관에서 온다. 제보 도메인을 받으면 항상 같은 순서로 초기 스캔을 돌리고, 결과를 같은 자리에 쌓는 습관. 인증서 지문을 수집하고, 텔레그램 공지를 텍스트화해 simhash를 갱신하는 습관. 리포트에는 캡처 한 장만 올리지 말고, HTML과 HAR, 명령 로그를 함께 첨부하는 습관. 습관은 오픈소스 도구를 기술에서 체계로 바꾼다.

먹튀검증은 결국 신뢰의 문제다. 신뢰를 쌓는 도구는 화려하지 않아도 된다. whois와 nmap, Playwright와 mitmproxy, simhash와 OpenCTI 같은 검증된 오픈소스 조합이면 충분하다. 중요한 것은, 같은 실수를 반복하지 않도록, 도구가 남긴 자취를 팀의 자산으로 바꾸는 일이다. 그 자산이 쌓일수록, 먹튀는 같은 방식으로 우리를 속이기 어려워진다.