본문으로 건너뛰기
사기 방지

결제 시점의 AI 쇼핑 에이전트 사기: 실제 매출은 막지 않고 IP로 봇 사기를 차단하는 방법

결제 시점의 AI 쇼핑 에이전트 사기: 우리 조회에서 검증된 ChatGPT-User 주소는 0점, 평범한 클라우드 서버는 10점이었습니다. 에이전트를 먼저 검증한 다음 IP 점수를 매기십시오.

작성자GeoIPHub 팀게시일업데이트읽는 시간30분 분량
빛나는 결제 방패에 다가가는 와이어프레임 쇼핑 카트. 결제 시점의 AI 쇼핑 에이전트 사기를 나타냅니다

전환율이 가장 높은 결제 트래픽과 가장 비싼 사기가 이제 같은 종류의 네트워크에서 도착합니다. Adobe는 2026년 3월 미국 리테일 사이트로 유입된 AI 트래픽이 사람 방문자보다 "42% 더 잘 전환되었다"고 밝혔는데, 1년 전에는 38% 낮았습니다(TechCrunch를 통한 Adobe 데이터). 한편 자동화 트래픽은 2025년에 전체 웹 트래픽의 53%를 넘어섰습니다(Imperva 2026 Bad Bot Report).

HUMAN Security는 "에이전트 활동의 2.3%가 이제 결제 페이지에서 발생한다"고, 그리고 정상 자동화와 악성 자동화의 비율을 "겨우 0.5%포인트가 가른다"고 보고합니다(HUMAN, 2026년 3월). 행동만으로는 둘을 가를 수 없습니다.

아래에서는 실제 조회 네 건, User-Agent 일치 확인이 왜 사용자의 몫인지, 그리고 실제 에이전트 매출을 지켜 주는 점수-조치 매핑을 다룹니다.

빛의 파편으로 부서져 추상적인 데이터센터 타워 사이를 떠다니는 카드 모양. 호스팅 IP에서 오는 카드 테스트를 나타냅니다
카드 테스트는 쇼핑객의 거실이 아니라 호스팅 네트워크에서 도착합니다.

결제 시점에 데이터센터와 프록시 IP를 차단하면 양쪽 모두에서 실패하는 이유

데이터센터 일괄 차단은 허점이 많고 비용도 크기 때문에 실패합니다. 허점이 많은 이유는 값비싼 공격에 데이터센터 주소가 필요하지 않기 때문입니다. HUMAN은 "카딩 규모가 2022년 이후 250% 급증했다"고, 그리고 "로그인 후 계정 침해 시도가 전년 대비 4배 넘게 늘었다"고 밝힙니다(HUMAN). GeoIPHub는 주거용 프록시를 탐지하지 않으므로, 가정용 연결에서 오는 사기는 사용자의 속도 데이터와 결제 데이터로 잡아야 합니다. 주거용 프록시 사기 설명 글에서 그 이유를 다룹니다.

비용이 큰 이유는 판매하고 싶은 사람들까지 걸러 내기 때문입니다.

  • 실제 에이전트는 클라우드 네트워크에서 동작합니다. 아래의 검증된 ChatGPT-User 주소는 Microsoft의 AS8075에 있으며 datacenter_ip로 표시됩니다.
  • Apple iCloud Private Relay 사용자는 Cloudflare 같은 파트너 네트워크에서 운영되는 릴레이 출구 주소를 공유합니다.
  • 통신사급 NAT는 많은 가입자를 하나의 주소 뒤에 둡니다. RFC 6598은 이를 위해 100.64.0.0/10을 공유 주소 공간으로 예약합니다. Cloudflare는 "CGNAT IP는 CGNAT가 아닌 IP보다 속도 제한을 세 배 더 자주 받는다"고 측정했지만, 평균 봇 비율은 CGNAT 주소가 7%로 13.1%보다 낮았습니다(Cloudflare).

따라서 연결 유형은 가중치를 두는 입력값이지 즉시 거절하는 기준이 아닙니다. IP 기반 봇 탐지 허브는 다섯 건의 실제 조회로 각 IP 플래그가 증명할 수 있는 것과 없는 것을 보여 줍니다.

결제 호출자 넷, 조회 넷: 2026-10-23에 본 것

검증된 에이전트 주소는 0점과 allow를 받으며, 거의 모든 클라우드 서버도 마찬가지입니다. 2026년 10월 23일 05:03:52부터 05:04:07 UTC까지 5초 간격으로 키 없는 조회 네 건을 실행했습니다.

  • ChatGPT-User: 104.208.184.193, OpenAI의 chatgpt-user.json에서 첫 번째 프리픽스인 104.208.184.192/28의 첫 번째 호스트입니다. 파일은 05:03 UTC에 가져왔습니다. IPv4 프리픽스 234개가 나열되어 있었고 IPv6는 없었으며 creationTime은 2026-10-20이었습니다.
  • Google 사용자 요청형 페처: 107.178.192.1, Google의 user-triggered-fetchers.json에 있는 107.178.192.0/27 안의 주소입니다.
  • 평범한 클라우드 서버: 45.33.32.156, Linode의 공개 테스트 호스트인 scanme.nmap.org입니다. 에이전트가 아닙니다.
  • iCloud Private Relay: 104.28.46.99, Cloudflare에 있는 Apple 릴레이 출구 주소입니다.
호출자crawler.verified / name / categoryfraud_scorerecommended_action결제 결정
ChatGPT-User, 104.208.184.193true / ChatGPTUser / ai0allow구매자의 에이전트로 인정
Google 페처, 107.178.192.1true / GoogleUserTriggeredFetcher / fetcher0allow인정
에이전트라고 주장한 클라우드 서버, 45.33.32.156false / none / none10allowStep up
Private Relay, 104.28.46.99false / none / none9allow인정

다음은 ChatGPT-User 조회 결과이며, 일부를 생략했지만 중첩 구조와 값은 수정하지 않았습니다.

GeoIPHub API
{ "ip": "104.208.184.193", "asn": { "asn": 8075, "org": "MICROSOFT-CORP-MSN-AS-BLOCK - Microsoft Corporation", "asn_type": "hosting", "connection_type": "datacenter" }, "detection": { "is_hosting": true }, "threat": { "is_crawler": true, "crawler": { "verified": true, "name": "ChatGPTUser", "operator": "OpenAI", "category": "ai", "verification_method": "ip_range_list" } }, "scoring": { "fraud_score": 0, "recommended_action": "allow", "detection_methods": ["datacenter_ip", "no_ptr_datacenter", "verified_crawler"] } }

호스팅 신호 두 개, datacenter_ip와 no_ptr_datacenter가 작동했습니다. 면책 신호인 verified_crawler가 합계를 0으로 끌어내렸습니다. 이 주소에는 실시간이든 저장된 것이든 역방향 DNS가 없으므로, OpenAI의 범위 파일이 유일한 증거입니다. Google 페처도 0점으로 같은 패턴을 보이지만, 호스트 이름이 해석되므로 no_ptr_datacenter 대신 rdns_hosting이 작동합니다.

중요한 것은 클라우드 서버 행입니다. 이 서버의 10점은 allow 구간(25 이하) 안에 있는 datacenter_ip 하나에서만 나왔습니다. 그 요청이 ChatGPT-User User-Agent를 달고 도착했더라도 점수는 여전히 allow라고 말했을 것입니다. 오직 verified: false와 name: "none"만이 그 주장이 거짓임을 보여 줍니다. 그래서 결정 열에는 allow가 아니라 step up이라고 적혀 있습니다.

릴레이 주소는 relay_ip만 방법으로 작동하여 9점을 받았습니다. 릴레이는 상한이 60이므로 Private Relay 사용자는 block에 도달할 수 없습니다. 우리 지리적 위치는 앙골라 루안다를 가리키지만, 2026-10-12에 확인했을 때 Apple의 출구 피드는 잠비아 루사카였으므로 릴레이 사용자는 국가 수준으로 판단하십시오.

05:09 UTC에는 Google의 user-triggered-agents.json에서 첫 번째 IPv4 호스트인 136.121.16.1도 조회했습니다. 이 파일은 Google-Agent를 다루며, Google은 이를 "Google 인프라에서 호스팅되는 에이전트가 사용자 요청에 따라 웹을 탐색하고 작업을 수행하는 데 사용한다"고 설명합니다(Google). 결과는 GoogleUserTriggeredAgent로 검증되었고, 점수 0, allow였습니다. fcrdns_mismatch도 작동했지만 실시간 dig로는 호스트 이름이 정방향 확인됩니다. 이는 우리 쪽 버그이며 점수에는 영향을 주지 않았고 기록해 두었습니다.

이는 하루 아침의 조회 다섯 건이지 벤치마크가 아닙니다. 범위는 이동하므로 값을 그대로 가져다 쓰기 전에 다시 실행하십시오.

User-Agent 일치 확인은 API가 아니라 사용자 코드의 몫입니다

API는 주소를 어느 봇이 소유하는지 증명하고, 요청이 같은 봇을 주장했는지는 사용자 코드가 증명합니다. IP 조회는 User-Agent를 보지 못하므로 GeoIPHub는 위조된 에이전트를 스스로 표시할 수 없습니다. 결제 핸들러가 헤더를 가지고 있으므로 비교는 거기서 해야 합니다.

양쪽의 이름은 서로 다릅니다. OpenAI의 User-Agent 토큰은 ChatGPT-User이고 API는 하이픈 없는 ChatGPTUser를 반환합니다. Google의 토큰은 Google-Agent이고 API는 GoogleUserTriggeredAgent를 반환합니다. 문자열을 그대로 비교하면 실패하므로 작은 매핑을 두십시오.

GeoIPHub API
// User-Agent token mapped to threat.crawler.name as the API returns it (seen 2026-10-23) const AGENT_NAMES = { "ChatGPT-User": "ChatGPTUser", "Google-Agent": "GoogleUserTriggeredAgent", }; // Returns null when the request makes no agent claim, // true when the claim matches a verified range, false when it doesn't. function agentClaimHolds(userAgent, lookup) { const token = Object.keys(AGENT_NAMES).find((t) => userAgent.includes(t)); if (!token) return null; const c = lookup.threat.crawler; return c.verified === true && c.name === AGENT_NAMES[token]; }

false 결과는 위 표의 클라우드 서버 행에 해당합니다. 점수와 관계없이 step up하거나 거부하십시오. 위조된 GPTBot 테스트를 포함한 nginx와 Express 전체 집행 코드는 AI 크롤러를 차단해야 할지 다룬 가이드에 있습니다.

에이전트의 IP에 점수를 매기기 전에 서명을 검증하십시오

유효한 프로토콜 자격 증명이나 서명은 어떤 IP 신호보다 우선합니다. 범위 파일보다 "누가 보냈는가"에 더 확실히 답하는 메커니즘이 세 가지 있습니다.

Agentic Commerce Protocol (ACP). Stripe는 2025년 9월 29일에 ACP를 발표하며 "Stripe와 OpenAI가 공동 개발한" 개방형 표준이라고 밝혔고, 사양 저장소는 Apache-2.0 라이선스입니다. Agentic Checkout RFC는 Authorization 베어러 토큰, API-Version, 그리고 모든 POST의 Idempotency-Key를 필수로, Signature와 Timestamp를 권장으로 표시합니다. Stripe는 자사의 Shared Payment Token이 "특정 판매자와 장바구니 총액으로 범위가 제한된다"고 밝히며, 이는 도난당한 토큰으로 살 수 있는 것을 제한합니다.

Web Bot Auth. 에이전트는 RFC 9421 HTTP Message Signatures(Standards Track, 2024년 2월)에 따라 각 요청에 서명합니다. Cloudflare의 Web Bot Auth 글은 Signature, Signature-Input, Signature-Agent 헤더와 서명자가 공개한 Ed25519 키를 사용합니다.

카드 네트워크의 에이전트 프로그램. Visa는 HTTP Message Signature 표준을 기반으로 "Cloudflare와 협력하여" Trusted Agent Protocol을 만들었으며, 신뢰할 수 있는 에이전트를 "악성 자동화와 불량 봇"과 구별하기 위한 것입니다(Visa, 2025년 10월 14일). 같은 날의 Cloudflare 발표는 "Mastercard가 Web Bot Auth를 Mastercard Agent Pay에 통합하고 있다"고 말합니다.

ACP 호출에서는 RFC에 따라 ChatGPT가 사용자의 결제 엔드포인트를 호출하므로, 접속 IP는 구매자가 아니라 에이전트 플랫폼의 것입니다. 그 경로에서는 자격 증명을 검증하고, IP 점수는 직접 들어오는 웹 트래픽에 남겨 두십시오. IP, rDNS, Web Bot Auth로 AI 크롤러와 에이전트 검증하기 가이드가 각 검사를 단계별로 안내합니다.

진짜 에이전트라도 IP 허용 목록만으로는 취약한 이유

직접 관리하는 허용 목록은 에이전트 주소가 공유되고 계속 이동하기 때문에 깨집니다. Cloudflare는 이렇게 분명히 말합니다. "제품이나 사용자 그룹을 대표하는 IP 주소 범위에 기대는 논리는 취약하다." 또한 연결이 "프라이버시 프록시와 VPN의 경우처럼 여러 사용자에게 공유될 수 있고" 클라우드 범위는 "시간이 지나며 바뀐다"고 덧붙입니다(Cloudflare).

OpenAI 자체 파일이 그 이동을 보여 줍니다.

가져온 날짜chatgpt-user.json의 IPv4 프리픽스creationTime
2026-10-062302026-09-25
2026-10-232342026-10-20

2026-10-06의 수치는 GPTBot, OAI-SearchBot, ChatGPT-User 비교에서 가져왔습니다. OpenAI는 ChatGPT-User에 대해서도 "이러한 동작은 사용자가 시작하므로 robots.txt 규칙이 적용되지 않을 수 있다"고 밝힙니다(OpenAI).

우리 쪽도 지연이 있습니다. GeoIPHub는 공식 범위 파일 19개를 다시 가져오고 조회 데이터베이스를 매일 재구축하므로, 새 프리픽스가 검증되기까지 최대 이틀 정도 걸릴 수 있습니다. 범위 일치는 강한 보강 증거로 취급하고, 에이전트가 서명을 보낸다면 서명을 우선하십시오.

AI 쇼핑 에이전트 사기: 결제 단계의 위협

결제 시점의 AI 쇼핑 에이전트 사기는 세 가지 공격이 이끌며, 그중 어느 것도 한 명의 구매자가 장바구니 하나를 주문하는 정상 에이전트 주문처럼 보이지 않습니다.

  • 카드 테스트(열거). 소액 또는 승인 전용 시도가 높은 거절률로 몰려듭니다. Visa는 열거 공격이 "연간 11억 달러의 사기 손실"을 초래하며 "열거된 계정의 33%가 5일 이내에 사기를 겪었다"고 밝힙니다(Visa, 2024년 5월).
  • 계정 탈취. 도난당한 로그인으로 저장된 카드를 사용해 구매합니다. Imperva는 금융 서비스가 "계정 탈취 사건의 46%"를 차지했다고 밝힙니다(Imperva 2026). 계정 탈취 방어 가이드가 로그인 측면을 다룹니다.
  • 스캘핑. 수요가 높은 한정판 출시에서 한정 재고를 쓸어 담는 봇입니다.

여러 주소로 분산된 카드 테스트는 IP별 카운터를 무력화하므로, ASN별과 BIN별로 거절 건수와 서로 다른 카드 수도 함께 세십시오.

0에서 100까지의 점수를 결제 조치에 매핑하기

0에서 100까지의 점수는 각 구간이 고정된 조치에 대응될 때에만 결제 시점에서 유용합니다. GeoIPHub의 설명 가능한 위험 점수가 IP 측 입력을 다루며, scoring.detection_methods가 작동한 모든 신호를 알려 줍니다. 나머지는 사용자 코드와 결제 데이터가 채웁니다.

입력결정에 미치는 영향
유효한 ACP 자격 증명 또는 Web Bot Auth 서명신뢰 경로, 낮은 마찰
crawler.verified가 true이고 이름이 User-Agent와 일치호스팅 신호를 무효화
검증된 일치가 없는 에이전트 User-Agent점수와 관계없이 step up 또는 거부
호스팅 네트워크(datacenter_ip)소폭 상승, 현재 단독으로는 10
VPN 또는 Tor 출구큰 폭 상승, 대개 block
릴레이(relay_ip)소폭 상승, 상한 60
IP별, ASN별 카드, BIN, 거절 속도큰 폭 상승
IP 국가가 청구 국가와 다름상승, 국가 수준에서 판단

그다음 구간을 조치에 매핑합니다.

구간점수결제 조치
allow0~25통과. 단, 에이전트 주장이 검증에 실패한 경우는 제외
review26~503-D Secure
step_up51~753-D Secure와 속도 검사
block76~100거절하거나 수동 검토를 위해 보류

상한이 공유 주소를 block에서 지켜 줍니다. 릴레이 주소는 상한이 60이므로 점수만으로 거절될 수 없고, API가 통신사급 NAT로 식별하는 주소에는 상한 50이 적용됩니다. ACP도 자체 카드 테스트 신호를 담고 있습니다. delegate-payment RFC는 card_testing 유형의 risk_signals를 blocked, manual_review, authorized 중 하나의 조치와 함께 보냅니다. 이는 에이전트 플랫폼이 채우며, 사용자의 점수는 별개의 검사로 남습니다. 로그인, 가입, 결제의 IP 위험 점수 임계값 글은 이 구간을 다섯 개의 다른 주소로 테스트합니다.

차단하지 말고 단계를 올리십시오: 3-D Secure는 책임을 이전합니다

중간 구간은 거절하는 대신 3-D Secure로 보내십시오. step up은 매출을 지키고 대개 차지백 위험을 옮깁니다. Trust Payments의 3-D Secure v2 책임 가이드는 인증에 성공하면 "대부분의 경우 사기성 차지백에 대해 카드 발급사가 책임을 진다"고 밝힙니다. 또한 "거래 인증의 성공이 책임 이전이나 승인 성공을 보장하지는 않는다"고 경고합니다.

step up은 실제 구매자에게 통과할 길을 주고, 카드 테스터에게는 카드를 가지고 있음을 증명하게 만듭니다. 그 중간 구간에 다른 누가 들어오는지는 VPN 탐지 오탐 가이드가 다룹니다.

승인된 에이전트 문제는 기술이 아니라 법의 문제입니다

더 어려운 질문은 에이전트가 애초에 구매해도 되는지입니다. 2026년 3월 9일 미국 캘리포니아 북부 연방지방법원은 Perplexity에 대해 Amazon에 예비 금지명령을 내렸습니다. The Register는 판사가 Perplexity의 Comet 에이전트가 "Amazon 사용자의 허락을 받아 접속하지만 Amazon의 승인 없이 접속한다"고 썼다고 보도합니다(The Register). Perplexity가 항소했고, 2026년 8월 4일 제9순회항소법원은 금지명령을 취소하고 사건을 지방법원으로 돌려보냈으며, 사건은 아직 진행 중입니다.

그 판결이 문제를 해결한 것은 아닙니다. IP 검사는 누가 요청을 보냈는지 알려 줍니다. 그 발신자가 구매해도 되는지는 이용약관이 말해 줍니다.

결제 시점에서 IP 검사가 실패하는 곳

IP 신호는 결제 전체 그림의 일부만 다루며, 알려진 한계는 다음과 같습니다.

  • 주거용 프록시 탐지 없음. 가정용 연결에서 오는 사기는 사용자의 속도 데이터와 결제 데이터가 필요합니다.
  • User-Agent 가시성 없음. API는 위조된 에이전트를 표시하지 않으며, 그 역할은 사용자 코드의 이름 일치 확인입니다.
  • 범위 지연과 DNS 공백. 새 프리픽스가 검증되기까지 약 이틀이 걸릴 수 있으며, 오늘 아침에는 잘못된 fcrdns_mismatch를 한 건 확인했습니다.
  • 통신사급 NAT는 현재 범위로 표시되지 않습니다. 2026-10-22에 100.64.0.1을 조회했을 때 CGNAT로 표시되지 않았습니다. 아직은 그 플래그를 기반으로 규칙을 만들지 마십시오.

규칙을 바꾼 뒤에는 iOS Safari, 모바일 통신사, Private Relay 같은 세그먼트별로 오탐을 추적하십시오. IP 지리적 위치는 실제로 얼마나 정확한가 글은 도시보다 국가가 나은 이유를 설명합니다.

결제 핸들러에 적용하기

서버 측 결제 엔드포인트에 네 단계로 연결하십시오.

  1. ACP 자격 증명이나 Web Bot Auth 서명을 먼저 검증하고, 유효한 것에는 신뢰 경로를 줍니다.
  2. 무료 API로 앱에 IP 사기 탐지 추가하기 가이드처럼 접속 IP를 조회합니다.
  3. User-Agent 매핑을 threat.crawler.name과 대조합니다. 실패한 에이전트 주장은 step up하거나 거부합니다.
  4. scoring.recommended_action을 구간 표에 매핑하고, 그 위에 카드 및 ASN 속도를 더합니다.

결정이 이상해 보일 때는 IP 주소를 조사하는 방법의 단계를 따라 이유를 확인하십시오. 이번 주에 ChatGPT-User라고 주장한 자신의 결제 로그 주소 하나로 시작하십시오. 조회해서 crawler.name을 그 주장과 비교해 보십시오.

FAQ

봇을 막으려면 결제 시점에 모든 데이터센터 또는 프록시 IP를 차단해야 합니까?

아니요. 실제 에이전트는 클라우드 네트워크에서 동작합니다. 2026-10-23에 Microsoft의 AS8075에 있는 검증된 ChatGPT-User 주소는 0점, allow를 받았습니다. 일괄 차단은 Private Relay와 통신사급 NAT 사용자도 거부합니다. 점수에서 호스팅에 가중치를 두고 중간 구간은 3-D Secure로 보내십시오.

결제 단계에서 정상적인 AI 쇼핑 에이전트와 사기 봇을 어떻게 구별합니까?

먼저 신원을 검증하십시오. ACP 자격 증명이나 RFC 9421에 따른 Web Bot Auth 서명이 그것입니다. 없다면 IP를 조회하여 threat.crawler.verified와 봇 이름을 얻고, 그 이름을 요청이 주장한 User-Agent와 코드에서 대조하십시오.

IP 허용 목록만으로는 AI 에이전트에 왜 취약합니까?

Cloudflare는 크롤링 서비스의 연결이 프라이버시 프록시나 VPN처럼 공유될 수 있고 클라우드 범위는 시간이 지나며 바뀐다고 지적합니다. OpenAI의 chatgpt-user.json은 우리가 2026-10-06과 2026-10-23에 가져온 사이에 IPv4 프리픽스가 230개에서 234개로 늘었습니다.

0에서 100까지의 IP 위험 점수를 결제 결정에 어떻게 매핑해야 합니까?

allow(25 이하)는 통과시키고, review(50 이하)와 step_up(75 이하)은 3-D Secure로 보내며, block(75 초과)은 거절하거나 보류하십시오. 검증에 실패한 에이전트 주장은 점수와 관계없이 step up합니다.

3-D Secure로 step up하는 것이 차단보다 전환율에 더 큰 해가 됩니까?

차단은 확실하게 매출을 잃지만, step up은 실제 구매자에게 통과할 길을 줍니다. Trust Payments는 인증에 성공하면 대부분의 경우 사기성 차지백에 대한 책임이 발급사에 있다고 밝히지만, 이것이 보장되는 것은 아닙니다.

AI 에이전트가 내 쇼핑몰에서 구매하는 것을 차단하는 것은 합법입니까?

승인 여부에 달려 있으며, 이것은 법률 자문이 아닙니다. 2026년 3월 연방 법원은 Perplexity에 대해 Amazon에 예비 금지명령을 내렸고, 판사는 Perplexity의 Comet 에이전트가 사용자의 허락을 받아 Amazon에 접속했지만 Amazon의 승인은 받지 않았다고 판단했습니다. 제9순회항소법원은 2026년 8월 그 금지명령을 취소했으며, 사건은 아직 진행 중입니다.

작성자

GeoIPHub 팀

GeoIPHub API를 만드는 팀

GeoIPHub IP 인텔리전스 API와 스캐너를 만드는 GeoIPHub 팀이 작성했습니다. 초안은 AI의 도움을 받아 준비하고 팀이 편집합니다. API 예시는 예시용으로 표시된 경우를 제외하고 라이브 API에 대한 실제 조회 결과입니다.

이 글 공유하기
더 많은 글

관련 글