먹튀검증의 규칙은 늘 늦게 온다. 피해가 먼저 생기고, 커뮤니티가 화를 내고, 그 뒤에야 조각난 스크린샷과 소문이 떠돈다. 현장에서 몇 년간 검증 업무를 하며 배운 것은 간단하다. 정황 증거는 소음일 뿐, 표준화된 데이터와 재현 가능한 절차만이 사건을 끝낸다. 이 글은 그 판단 아래 만들어 온 표준 프로토콜의 형태와, 실제로 적용하면서 맞닥뜨린 문제, 유효했던 장치, 그리고 아직 비어 있는 틈에 대한 기록이다.
문제를 다시 정의하기
먹튀는 단순한 사기 행위가 아니다. 신뢰가 약한 환경에서 반복되는 유동성 위기, 기술과 운영의 부실, 일부러 설계된 탈출 경로, 그리고 규제의 회색지대가 합쳐진 현상이다. 돈이 걸리니 사용자들은 예민하고, 플랫폼은 방어적이며, 제3자는 늘 늦게 안다. 이 간극을 줄이는 방법은 절차의 표준화다. 누가 검증하든 같은 데이터를 같은 방식으로 수집하고, 동일한 기준으로 해석하며, 결과를 동일한 포맷으로 공개해야 한다. 사람에 의존하는 검증은 빠를 수 있지만, 재현성이 떨어진다. 프로토콜은 그 반대다. 느린 대신 같은 결론을 낳는다.
현장을 조금 구체화하자. 우리가 다루는 대상은 결제 모듈을 탑재한 온라인 서비스, 주로 예치금과 출금을 다루는 사이트들이다. 사건의 60퍼센트 이상은 출금 지연에서 시작한다. 운영팀이 말하는 사유는 세 가지로 모인다. 지급 대행사의 점검, 부정 이용 탐지, 환수 작업. 표면적 설명만으로는 진위를 가리기 어렵다. 그래서 프로토콜은 다음의 세 가지 축을 고정한다. 자금, 신원, 행위. 자금은 예치와 보유, 신원은 실체와 통제권, 행위는 약속과 이행의 로그다.
검증의 대상과 경계 설정
프로토콜이 다루는 항목을 명확히 하면 불필요한 논쟁을 줄일 수 있다. 예를 들어 게임의 공정성, 확률 공개 같은 이슈는 중요하지만, 먹튀검증의 핵심 스코프에서 벗어난다. 우리의 목적은 사라질 가능성을 가늠하고, 사라진 뒤 피해 확산을 막는 것이다. 따라서 범위는 다음과 같이 묶였다. 운영 실체의 연속성, 유동성 커버리지, 결제 체인의 투명성, 약관과 정책의 일관성, 고객 요청 처리의 지연 패턴, 로그의 위변조 가능성. 이 다섯 축이면 실제 현장의 80퍼센트를 다룰 수 있다. 나머지 20퍼센트는 사건마다 튄다. 그 자리는 메모와 부록으로 남긴다.
표준 프로토콜의 구성 요소
프로토콜은 문서만으로 서 있지 않는다. 수집 도구, 데이터 스키마, 평가 모델, 공개 포맷, 감사를 위한 추적성까지 한 묶음이어야 한다. 첫 버전은 과감하게 단순했다. 열 개의 신호만 본다. 다만 각각의 신호는 측정 기준과 실패 조건을 엄격히 적었다.
첫째, 운영자 신원과 통제권. 법인 등록 여부나 사업자 번호 같은 건 가장 약한 증거다. 우리가 보는 것은 도메인, CDN, 이메일 MX, 결제 상점 ID의 매핑 일치다. 최소 세 축이 일치하면, 운영의 연속성을 통과한 것으로 표기한다. 통제권 이전의 흔적은 보통 네임서버 변경, TLS 인증서 발급 이력, 상점 ID 재발급 타이밍에서 드러난다.
둘째, 자금 분리. 고객 예치금과 운영 비용이 분리돼 있다는 주장만으로는 부족하다. 토스, 카카오페이 등 PG 정산 대금의 귀속 계좌와, 고객 출금 송금 계좌의 명의가 같으면 감점이다. 외부 수탁 계좌 사용, 신탁 계약서 사본, 월별 잔액 증빙 캡처를 받지만, 스크린샷은 위조가 쉽다. 그래서 두 군데 이상의 은행 내역을 날짜 범위별로 샘플링받고, 금액 합이 거래 로그와 틀어지는지를 본다.
셋째, 기술적 탄력성. 평균 응답 시간, 오류율, 배포 주기, 로그 보존 기간, 백업 복구 리허설 여부 같은 운영 지표는 부실을 가늠하게 한다. 첫 적용기에서 하루 평균 요청 80만 건 규모의 서비스는 p95 응답 시간 420ms, 오류율 0.7퍼센트로 측정됐다. 문제는 숫자 자체가 아니라 변동성이다. 응답 시간의 표준편차가 큰 곳은 대개 현금 흐름도 불안하다. 배포가 stop the world인지, 롤링인지 같은 사소한 질문들이 쌓이면 그림이 나온다.
넷째, 행위 로그와 분쟁 처리. 입금, 베팅, 환수, 출금의 타임라인이 이어져야 한다. 구조적으로 끊기는 곳은 대부분 문제가 있다. 요청이 제출된 뒤 승인까지 걸린 시간이 24시간을 넘는 비율이 한 달 평균 2퍼센트를 넘으면 경고를 준다. 분쟁 처리의 평균 소요 시간을 자체 보고로 받되, 표본 추출로 고객센터 티켓과 대조한다.
다섯째, 외부 신호. 커뮤니티 제보, 제휴사 피백, 제재 이력이다. 여기는 위험하다. 여론의 파도는 왜곡을 만든다. 그래서 외부 신호는 보조로만 쓴다. 다만 같은 시점에 제휴사 두 곳 이상에서 정산 지연을 말하면, 내부 데이터가 멀쩡해도 즉시 심층 검토로 돌린다.
각 신호는 0에서 3 사이의 점수로 모델링했다. 0은 결함, 1은 부족, 2는 기준 충족, 3은 모범. 가중치는 현금 흐름과 연속성에 먹튀검증 더 높게 줬다. 첫 해에는 자금 40, 신원 25, 행위 20, 기술 10, 외부 5. 가중치는 사건을 겪으며 조정했다. 예를 들어 단기 유동성 쇼크가 잦은 업계에서는 유동성 커버리지를 50까지 올린 적도 있다.
데이터 수집과 진위 검증
먹튀검증의 절반은 수집, 나머지 절반은 진위 검증이다. 운영자가 제공하는 모든 데이터는 의심한다. 자동화가 가능한 지점부터 고정했다. DNS, TLS, WHOIS, ASN, CDN 에지 위치 변경은 공개 소스에서 바로 끌어온다. 카드 매입사의 상점 ID 매칭은 제휴를 통해 휴리스틱을 만들었다. 상점 ID는 마스킹된 상태로 제공받고, 테스트 결제 100원으로 승인 코드를 맞춰보는 방법이 효과적이었다.
로그는 난점이 많다. 스크린샷은 거절한다. CSV 원본을 받고, 해시를 함께 적어 두고, 무작위 샘플의 IP, UA, 타임스탬프 상식성 검사를 한다. 로그인 성공과 베팅 요청, 잔고 변경, 출금 요청의 타임라인을 한 계정 기준으로 끌어보면 금방 어색한 지점이 보인다. 예를 들어 서울 시각 새벽 3시에 베팅 후 3분 내에 출금을 요청했는데, 승인까지 28시간이 걸린 표본이 대량으로 나타났던 케이스가 있다. 거기서 유동성 이상 신호를 잡아냈다.
진위 검증은 외부 문서가 특히 어렵다. 신탁 계약서, 서버 호스팅 계약, 보안 인증서 같은 것들이다. 원본을 받는 일은 거의 없다. 그래서 검증 루틴을 바꿔, 문서에서 주장하는 사실을 역으로 증명하게 했다. 예를 들어 백업 데이터센터가 따로 있다면, 백업 구간에서 생성되는 오브젝트 스토리지의 access log에서 특정 패턴을 보여달라고 요청한다. 인증서는 유효기간과 발급기관을 눈으로 보지 않고, 서버에서 직접 핸드셰이크를 잡아 추출한다.
표준 워크플로우
프로토콜을 쓰는 사람은 보통 두 부류다. 플랫폼 운영팀과 제3자 검증팀. 서로의 언어가 다르다. 워크플로우를 짧게 고정하면 오해가 준다.
- 요청 접수와 스코핑 합의, 검증 범위와 제외 항목, 샘플 기간을 서면 합의한다. 자동 수집 단계, DNS, TLS, WHOIS, 공개 로그, 성능 측정 에이전트를 배포해 72시간 측정한다. 운영자 제공 자료 수령, 자금 증빙, 거래 로그, 정책 문서, 백업 및 복구 관련 증명 자료를 받는다. 교차 검증과 심층 인터뷰, 샘플 불일치 지점에 대해 담당자와 2회 인터뷰를 진행한다. 평가 모델 적용과 결과 공개, 점수, 근거, 한계, 후속 조치를 표준 리포트 포맷으로 게시한다.
다섯 단계 사이에 소소한 반복이 많다. 특히 세 번째에서 네 번째 사이에 왕복이 잦다. 우리는 일정 압박을 줄이는 대신, 특정 항목이 합리적 의심 상태로 남으면 리포트에 그대로 적는다. 확실하지 않은 것을 확실한 것처럼 쓰는 순간 프로토콜은 신뢰를 잃는다.
점수 대신 서술을 택한 항목들
숫자는 편리하지만, 오히려 오독을 만든다. 몇몇 항목은 점수화를 포기하고 서술형으로 남겼다. 첫째, 내부 통제와 권한 분리. 지표화가 어렵다. 배포 권한이 두 사람에게 분리되어 있는지, 재무와 정산의 승인 권한이 분리되어 있는지, 변경 이력이 남는지, 이런 것들은 체크박스로 만들기 쉽지만 실제 운영의 디테일을 놓친다. 둘째, 커뮤니케이션의 진정성. 한 달 동안의 운영팀 답변을 타임라인으로 재구성해서 리포트에 첨부한다. 늦더라도 정확한 답이 오는 팀과, 빠르지만 빈말이 많은 팀은 결과가 다르다. 셋째, 위기 대응 리허설. 유동성 쇼크를 가정한 모의 훈련을 실제로 했는지와 그 결과다. 문서만으로는 알 수 없어서, 실연을 요청한다. 여기에는 점수를 매기지 않는다. 독자가 스스로 읽고 판단하게 둔다.
적용기 1 - 신규 플랫폼의 온보딩
작년 봄, 막 론칭한 신규 플랫폼이 먼저 연락을 해 왔다. 홍보 포인트로 먹튀검증 통과를 쓰고 싶다고 했다. 첫 면담에서 요구한 것은 명확했다. 표준 워크플로우를 그대로 적용하되, 결과 리포트의 공개 범위를 사전에 합의하자. 공개 가능한 항목과 비공개 항목을 나눴다. 테스트 결제는 하루 30건, 7일간 분산했다. 트래픽은 평균 분당 150건 수준이라 측정 노이즈가 컸다. 그래서 에이전트로 부하를 높이지 않고, 사용자 세션 내 지연만을 추적했다.
결과는 선방이었다. 보유 예치금 대비 유동성 커버리지가 1.7배였다. 일반적으로 1.2배 이상을 기준으로 본다. 다만 출금 약관이 모호했다. 특정 국면에서 24시간 유예 조항이 있는데, 국면의 정의가 추상적이었다. 약관 문구 수정을 권고했고, 한 달 뒤 개정판을 받아 재검을 했다. 이 케이스는 점수와 서술 모두 긍정적이었고, 공개 이후 유입도 늘었다고 들었다. 무엇보다 운영팀이 프로토콜 언어를 빠르게 채택했다. 다시 검증을 요청할 때 필요한 자료가 첫 회보다 40퍼센트 빨리 도착했다. 표준은 이렇게 누적 이득을 만든다.
적용기 2 - 출금 지연 논란 중인 중견사
가장 어려운 건 한창 논란 중인 플랫폼이다. 여론의 압력이 프로토콜의 균형을 흔든다. 특정 중견사는 출금이 3일 넘게 지연됐고, 커뮤니티에서 먹튀로 찍혔다. 의뢰는 제휴사에서 들어왔다. 우리는 바로 자동 수집을 돌렸다. DNS 변경은 없었고, TLS도 최신이었다. 서버는 싱가포르와 도쿄에 분산, 성능 노이즈는 없었다. 내부 로그를 받아 보니 출금 승인 큐가 누적되어 있었고, 승인 스크립트의 실패율이 갑자기 치솟았다. 당일 새벽에 배포된 신 버전에서 서명 키 로테이션 과정의 경합 조건을 놓친 것이 원인이었다.
문제는 여기서 끝나지 않았다. 그날 낮 결제 대행사 한 곳이 부정 이용 증가를 이유로 모니터링 레벨을 올렸고, 승인률이 20퍼센트 가까이 내려갔다. 현금 흐름이 동시에 악화됐다. 기술적 결함과 유동성 충격이 겹쳤다. 프로토콜은 두 축을 따로 기록한다. 첫째는 기술 사건 보고서와 재현 절차, 둘째는 유동성 회복 계획과 실제 회복 속도. 이 팀은 48시간 내로 기술 결함을 해소했고, 유동성은 5일 차에 정상화됐다. 우리는 먹튀 의혹이라는 결론을 유보했고, 사건 로그와 수정 타임라인을 리포트로 올렸다. 한편으로 약관의 지연 배상 조항이 없었다. 지연 보상 정책을 소급 적용하도록 권고했고, 실제로 평균 3천 원의 포인트 보상이 이뤄졌다. 이것이 신뢰를 회복했다고 말하긴 어렵다. 다만 먹튀라는 단어는 사라졌다. 프로토콜은 누명을 벗겨주는 데도 필요하다.
악성 행위자의 적응과 프로토콜의 내성
표준이 알려지면 공격자도 읽는다. 몇 가지 적응 패턴은 이미 관찰됐다. 가장 흔한 것은 로그 조작이다. 타임스탬프 조작은 해시와 일관성 검사를 통과하기 쉽다. 그래서 세션 레벨의 상관관계를 본다. 로그인과 요청 사이의 네트워크 지연 분포는 조작하기 어렵다. 두 번째는 자금 분리의 위장이다. 계좌를 여러 개로 쪼개고, 단기 대출로 잔고를 부풀리는 방식이다. 이건 잔액 스냅샷만으로는 잡히지 않는다. 주간 단위의 잔액 추이와 출금 요청량의 공분산을 본다. 급박한 구간에서의 상관성이 무너지는지 본다. 세 번째는 제3자 감사의 사칭이다. 검증사가 존재하지 않는데 스탬프 이미지를 붙이는 경우다. 우리는 리포트를 모두 해시와 함께 공개 레지스트리에 올린다. 해시 공개는 무료이며, 누구나 대조할 수 있다. 스탬프 이미지는 의미가 없다. 해시만 믿는다.
프로토콜의 내성을 높이려면 자동 검증과 인간의 직감이 만나는 지점을 늘려야 한다. 자동화는 같은 실수를 반복하지 않게 한다. 직감은 새로운 실수를 빨리 잡는다. 첫해에 자동화 커버리지는 40퍼센트였고, 지금은 60퍼센트 정도다. 80퍼센트를 넘기려면 운영자와 더 깊은 통합이 필요하다. API를 표준화해 주기적으로 상태를 받아와야 한다. 일부 팀은 이미 시작했다. 매주 월요일 9시에 유동성, 큐 길이, 지연 비율을 푸시한다. 우리는 그 숫자를 믿지 않는다. 그 숫자가 과거의 숫자와 이어지는지를 본다.
공개 리포트 포맷과 독자의 권리
먹튀검증의 결과는 한 번 읽히고 잊히기 쉽다. 하지만 사건의 수명은 길다. 그래서 리포트는 단순한 뉴스거리가 아니라 기록이어야 한다. 포맷은 세 부분으로 나눈다. 첫째, 평가 요약. 점수와 서술, 특이 사항. 둘째, 증거의 출처와 재현 절차. 누구나 같은 결과를 낼 수 있도록 파라미터와 샘플을 적는다. 셋째, 한계와 미해결 질문. 이 항목은 중요하다. 무엇을 모르는지 밝히지 않으면 신뢰는 생기지 않는다.
독자의 권리도 명시한다. 오탈자나 데이터 오류를 발견하면 정정 요청을 넣을 수 있고, 우리는 정정 로그를 공개한다. 리포트는 버전이 있다. 바뀌었으면 왜 바뀌었는지, 무엇이 바뀌었는지 적는다. 이 단순한 절차 덕에 논쟁이 줄었다. 논쟁은 사라지지 않는다. 대신 같은 자리를 맴돌지 않는다.
운영팀을 위한 자가 점검 항목
검증받지 않아도, 스스로 점검할 수 있는 최소 항목을 적어 둔다. 특히 성장기에 유용하다.
- 고객 예치금 계좌와 운영비 계좌를 은행 레벨에서 분리하고, 월별 잔액 스냅샷을 이중 보관한다. 출금 승인 큐의 길이와 평균 처리 시간을 대시보드로 상시 노출하고, 24시간 초과 비율을 자동 알림으로 묶는다. 배포 파이프라인의 권한을 분리하고, 롤백 절차를 2주 간격으로 리허설한다. 약관의 지연 조항, 분쟁 처리 절차, 지연 보상 정책을 명시하고, 변경 이력을 공개한다. 검증 요청이 오기 전, DNS, TLS, WHOIS, 상점 ID 등 운영 식별자의 일치 여부를 스스로 대조한다.
이 다섯 가지만 지켜도, 위기 때 결정이 빨라진다. 평소의 버릇이 위기에서 드러난다.
규제와 표준의 만남
규제가 표준을 대체하지는 못한다. 반대로 표준도 규제를 대체할 수 없다. 규제는 최저선을 만든다. 표준은 모범을 만든다. 협력의 여지는 분명하다. 예를 들어 유동성 커버리지의 공개 기준을 감독당국과 합의할 수 있다. 잔액 그 자체가 아니라 커버리지 비율과 산식만 공개하면 사업의 기밀을 해치지 않는다. 또 하나는 정정 로그의 공개다. 소비자 분쟁에서 리포트의 버전 관리가 증거로 쓰일 수 있다. 이 부분은 법률가들과 함께 논의해야 한다.
커뮤니티와 제보 시스템
먹튀검증의 현장은 커뮤니티가 만든다. 제보가 검증의 촉수가 된다. 하지만 제보는 오염되기 쉽다. 다중 계정으로 과장된 서사를 만들기도 하고, 경쟁사의 이익이 개입되기도 한다. 그래서 제보 시스템에 다음의 장치를 달았다. 실명 인증은 하지 않는다. 대신 제보의 품질에 따라 신뢰 점수를 쌓는다. 과거 제보가 검증 결과와 일치한 정도에 따라 가중치를 부여한다. 동일한 이슈를 여러 사람이 독립적으로 제보하면 신뢰가 급상승한다. 템플릿을 고정해, 날짜, 금액, 요청 ID, 응답 메시지, 상담 로그 스크린샷의 네 가지를 필수로 받는다. 템플릿이 없으면 제보는 사연이 되고 만다. 사연은 마음을 움직이지만, 검증에는 도움이 되지 않는다.
성능, 비용, 그리고 현실적 타협
이상적인 프로토콜은 비싸다. 소규모 팀은 감당하기 어렵다. 그래서 cost-aware 모드를 따로 뒀다. 자동 수집을 중심으로 하고, 운영자 제공 자료의 범위를 줄인다. 대신 시간 창을 넓힌다. 72시간이 아니라 2주를 본다. 비용은 평균 40퍼센트 낮아지고, 정밀도는 10퍼센트 정도 떨어진다. 우리가 본 손익분기점은 월 활성 사용자가 5만 명 정도다. 그 이하의 팀에게는 cost-aware가 차선이다. 검증의 빈도도 줄인다. 분기 1회로도 충분하다.
시간 비용도 있다. 첫 검증은 길다. 운영팀의 고생이 많다. 그래서 사전 안내서를 만들었다. 필요한 자료, 포맷, 예시를 담았다. 첫 적용 이후, 두 번째부터는 준비 시간이 절반으로 줄었다. 툴도 개선했다. 로그 검증기는 원래 스프레드시트로 돌렸는데, 지금은 오픈소스 CLI 툴로 바꿨다. CSV를 넣으면 필드 검증, 타임라인 재구성, 상식성 검사까지 한 번에 뽑는다. 누구나 쓸 수 있다. 도구의 공개는 이해관계자 모두의 부담을 줄인다.
실패한 시도와 배운 점
모든 시도가 성공하진 않았다. 한때 블록체인 기반의 증빙을 도입하려 했다. 자금 잔액 증빙과 로그 해시를 체인에 올려 불가역성을 담보하자는 발상이었다. 도입은 쉬웠다. 문제는 읽는 사람이 없었다. 사업자는 비용을 걱정했고, 독자는 체인 익스플로러를 보지 않는다. 또 다른 실패는 과도한 익명성 요구를 수용했던 일이다. 운영자 신원 노출을 극도로 꺼리는 팀을 위해 대리인을 내세운 적이 있다. 결과적으로 내부 통제 질문을 깊게 묻지 못했고, 리포트의 핵심이 빠졌다. 이후 기준을 바꿨다. 비공개는 허용하되, 검증팀과 1대1로는 실명 확인을 원칙으로 했다.
먹튀검증을 문화로 만드는 일
프로토콜은 기술이지만, 먹튀검증은 결국 문화다. 운영팀이 불편함을 감수하고, 제휴사가 압박 대신 협력을 택하고, 커뮤니티가 즉단 대신 근거를 요구할 때 비로소 자리를 잡는다. 이 문화는 느리다. 대신 한번 자리 잡으면 단단하다. 한 플랫폼과는 분기마다 리포트를 업데이트하며 2년을 함께했다. 그 사이 운영팀의 퇴사와 재편이 세 번 있었다. 그래도 운영의 연속성은 유지됐다. 문서와 절차가 사람을 이겼다. 이게 표준의 힘이다.
다음 단계 - 인터페이스의 표준화
지금까지는 문서와 절차 중심이었다. 다음은 인터페이스의 표준화다. 운영팀이 주기적으로 상태를 밀어줄 수 있도록 간단한 API를 정의했다. 세 가지 엔드포인트면 충분하다. 유동성 커버리지, 출금 큐 상태, 장애 공지. 인증은 간단한 키 교환과 서명으로 처리하고, 페이로드는 스키마를 고정한다. 사소해 보이지만, 이 API가 보급되면 실시간 모니터링과 주간 리포트 사이의 틈이 줄어든다. 커뮤니티도 이 데이터를 구독할 수 있다. 공개 가능한 범위만 나간다. 잔액이 아니라 비율과 지연률만. 이미 두 팀이 파일럿 중이다. 첫 달에는 알림이 너무 잦았다. 임계값을 현실적으로 조정했다. 중요한 건 소음이 아니라 신호다.
마무리 대신 남겨두는 질문
먹튀검증은 완결되지 않는다. 새로운 결제 수단이 나오고, 데이터 보존 규칙이 바뀌고, 공격자는 다른 옷을 입는다. 표준 프로토콜은 살아 있어야 한다. 현재 버전은 유동성 편향이 있다. 기술적 취약점 탐지와 위기 커뮤니케이션 평가가 덜 다듬어졌다. 또 하나, 소규모 팀을 위한 경량 프로토콜을 더 다듬어야 한다. 문턱이 높으면 표준은 엘리트의 장난이 된다. 엘리트의 장난은 현장을 구하지 못한다.
먹튀검증의 목적은 낙인을 찍는 일이 아니다. 사라질 가능성을 낮추고, 사라졌을 때 피해를 제한하며, 거짓을 말하기 어렵게 만드는 것이다. 표준은 딱 그만큼의 힘이 있다. 힘의 크기는 거창하지 않다. 대신 꾸준하다. 규칙을 세우고, 지키고, 고치는 일. 이 느린 리듬이 현장을 조금씩 바꿔 왔다. 앞으로도 그럴 것이다.