IP 평판과 사기 점수의 작동 방식(IPQualityScore)을 이해하는 것은 2026년에 자동화·스크래핑·리서스 엔지니어링을 하는 사람에게 더 이상 선택이 아닙니다. 로그인, 결제, 회원가입 화면 뒤에는 IPQS 같은 사기 점수 엔진이 매 요청을 0~100 점수로 평가하고, 90점 이상이면 즉시 차단합니다. 데이터센터 IP는 거의 항상 차단되고, 잘 구성된 레지덴셜 프록시는 통과합니다. 이 글은 그 차이가 왜 발생하는지, 그리고 어떻게 자체 IP 품질을 검증하고 합법적으로 통과하는지를 실전 코드로 분해합니다.
IP 평판과 사기 점수의 작동 방식(IPQualityScore): 0~100 점수는 어떻게 만들어지나
IPQualityScore(IPQS)를 포함한 상용 사기 점수 엔진은 단일 신호에 의존하지 않습니다. 여러 데이터 소스를 결합해 0~100 점수를 만들며, 점수가 높을수록 위험도가 높습니다. 핵심 입력은 다섯 가지입니다.
- 허니팟과 트랩: 스팸머·봇넷이 자주 방문하는 가짜 폼·링크에서 수집한 IP를 블랙리스트화합니다. 한 번 트랩에 걸리면 해당 IP/대역은 오랫동안 점수가 높게 유지됩니다.
- ASN/대역 분류: IP가 속한 ASN이 호스팅 제공자(AWS, Hetzner, OVH, DigitalOcean 등)인지 실제 ISP(Comcast, KT, Deutsche Telekom 등)인지 분류합니다. 호스팅 ASN은 기본적으로 의심 점수가 높습니다.
- 공개/사설 블랙리스트: Spamhaus, AbuseIPDB, 자체 피드을 교차 참조해 최근 악용 이력을 점수에 반영합니다.
- 머신러닝 모델: 요청 빈도, 시간대 패턴, UA 다양성, 계정 생성 속도 등 행동 신호를 결합해 '확장 가능한 자동화 패턴(scalable abuse)'을 분류합니다.
- 실시간 포렌식 검사: 개방 포트 스캔, 역방향 DNS(rDNS), 지리정보 일치성, 연결 유형(프록시/VPN/Tor) 탐지를 수행해 점수를 보정합니다.
이 다섯 입력이 가중 합산되어 하나의 정수 점수가 됩니다. IPQS는 공식 문서에서 fraud_score가 0(매우 안전)에서 100(매우 위험)까지이며, 75~90은 추가 검증(2FA, 이메일/전화 검증), 90 이상은 차단을 권장한다고 명시합니다. 이 임계값은 사이트가 직접 설정하며, 결제 단계에서는 종종 75로 더 보수적으로 설정됩니다.
핵심: 사기 점수는 '이 IP가 봇인가'가 아니라 '이 IP에서 온 요청이 사기일 확률이 얼마인가'를 추정합니다. 따라서 같은 봇이라도 출구 IP에 따라 점수가 완전히 달라집니다.
프록시 탐지 신호: IPQS가 IP를 어�게 '읽'는가
IPQS의 Proxy Detection API는 단순히 '프록시 여부' 불린을 반환하지 않습니다. 점수와 함께 proxy, vpn, tor, recent_abuse, bot_status, connection_type, ISP, ASN 등 세부 필드를 반환합니다. 주요 탐지 신호는 다음과 같습니다.
ASN 유형: 호스팅 vs ISP
가장 강력한 단일 신호입니다. ASN이 AWS(AS16509), Hetzner(AS24940), OVH(AS16276) 같은 호스팅 제공자면 connection_type이 'Corporate/Datacenter'로 분류되고 기본 점수가 이미 60~80에서 시작합니다. 반면 Comcast(AS7922), KT(AS4766), Orange(AS3215) 같은 실제 ISP ASN은 'Residential'로 분류되어 기본 점수가 0~20에 가깝습니다.
개방 포트와 rDNS
IPQS는 대상 IP의 80, 1080, 3128, 8080, 8443 등 프록시/VPN 소프트웨어가 자주 사용하는 포트를 비침습적으로 확인합니다. 또한 rDNS 레코드가 'host-12-34-56-78.aws.com' 같은 데이터센터 패턴인지, 'cpe-72-1-2-3.nyc.res.rr.com' 같은 가정용 ISP 패턴인지 검사합니다. rDNS가 ISP 도메인이고 포트가 닫혀 있으면 프록시 신호가 크게 약해집니다.
지리정보 불일치와 연결 유형
IP의 등록 지역, MaxMind/DB-IP 지리정보, 시간대, 언어 헤더가 불일치하면 VPN 의심 점수가 올라갑니다. connection_type이 'Residential'이면 가장 안전하고, 'Corporate'나 'Datacenter'면 위험도가 급증합니다.
최근 악용 이력 (recent_abuse)
IPQS는 자체 피드과 AbuseIPDB 같은 외부 피드을 결합해 최근 30일 이내 해당 IP에서 스팸·자격증명 스터핑·결제 사기가 보고되었는지 확인합니다. recent_abuse=true면 점수가 보통 85 이상으로 치솟습니다. 이 필드는 레지덴셜 프록시에서도 회전 없이 같은 IP를 과도하게 사용하면 시간이 지나 채워질 수 있어 주의가 필요합니다.
임계값이 왜 중요한가: 로그인·결제·가입에 점수를 어떻게 연결하는가
사기 점수 자체보다 중요한 것은 사이트가 이 점수를 어디에 어떻게 연결하느냐입니다. 일반적인 통합 패턴은 다음과 같습니다.
| 단계 | 권장 임계값 | 조치 |
|---|---|---|
| 회원가입 | ≥85 차단, 70~85 이메일/전화 검증 | 봇 계정 양산 방지 |
| 로그인 | ≥90 차단, 75~90 2FA 강제 | 자격증명 스터핑 차단 |
| 결제/체크아웃 | ≥75 차단, 50~75 3DS 또는 추가 검증 | 카드 테스트 공격 방어 |
| API/스크래핑 보호 | ≥80 차단, 그 외 속도 제한 | 대량 자동화 제어 |
IPQS는 공식 문서에서 '결제 단계에서는 가장 보수적으로, 75 이상이면 차단을 권장한다'고 안내합니다. 즉 결제 화면에서는 데이터센터 IP가 거의 100% 차단됩니다. 반면 로그인은 90까지 허용하되 2FA를 강제하는 식으로 유연하게 설계하는 사이트가 많습니다.
이 통합은 보통 백엔드 미들웨어에서 이뤄집니다. IPQS API 응답을 캐싱해(보통 1~24시간 TTL) 매 요청마다 외부 호출 비용과 지연을 줄이고, 점수에 따라 분기합니다. 합법적인 자동화를 운영하는 사람에게 이 말은 '한 번 90점이 찍힌 데이터센터 IP는 재사용해도 계속 차단된다'는 뜻입니다.
왜 레지덴셜 프록시가 통과하는가: 탐지 문제의 본질
모든 탐지 신호를 되짚어 보면, IPQS가 '안전하다'고 판정하기 위해 원하는 것은 명확합니다. (1) 실제 ISP ASN, (2) 가정용 rDNS 패턴, (3) 거주지 기반 지리정보, (4) 개방 프록시 포트 부재, (5) 최근 악용 이력 부재. 이 다섯 가지를 동시에 만족하는 IP가 바로 진짜 가정용 레지덴셜 프록시입니다.
데이터센터 IP는 첫 번째 조건(ASN)에서 이미 실패합니다. AWS/Hetzner/OVH ASN은 전 세계적으로 '호스팅'으로 분류되어 있어, 포트을 닫고 rDNS를 세팅해도 근본적으로 바꿀 수 없습니다. 반면 ProxyHat 레지덴셜 풀의 출구는 실제 ISP가 가정에 할당한 IP를 사용하므로, ASN·rDNS·지리정보가 모두 일반 사용자와 동일합니다. 이것이 바로 '레지덴셜 프록시 탐지(residential proxy detection)'가 어려운 이유이며, 동시에 레지덴셜 프록시가 존재하는 이유이기도 합니다.
하지만 레지덴셜이라고 무조건 안전한 것은 아닙니다. 동일 출구 IP로 짧은 시간에 수백 요청을 보내면 행동 신호가 '확장 가능한 자동화'로 분류되어 bot_status=true가 될 수 있고, 남용되면 recent_abuse가 채워집니다. 따라서 레지덴셜 프록시는 'IP 자체가 통과'일 뿐, 행동 지문과 TLS 지문까지 함께 관리해야 완전히 통과합니다.
TLS·행동 지문: IP를 넘어선 두 번째 방어선
IPQS 자체는 IP 중심이지만, 최신 사기 방지 스택은 IP 평판 위에 TLS 지문과 브라우저 행동 지문을 겹쳐 판정합니다. IP만 통과해도 다음 신호가 불일치하면 여전히 차단됩니다.
JA3/JA4 TLS 지문
JA3는 ClientHello의 암호 스위트 순서, 확장 목록, 타원 곡선을 해시한 값입니다. 예를 들어 실제 Chrome 124의 JA3는 771,4865-4866-4867-49195-49199-... 같은 패턴을 가지며, Wikipedia의 TLS 지문 항목에서 설명하듯, Python requests의 기본 OpenSSL 스택은 Chrome과 다른 암호 순서를 보내 즉시 구분됩니다. JA4는 버전·SNI·ALPN을 분리해 더 정밀합니다.
캔버스·WebGL·행동 지문
브라우저 환경에서는 캔버스 해시, WebGL 렌더러 문자열, navigator.webdriver, 마우스 이벤트 시간 분포가 추가 신호로 쓰입니다. 헤드리스 Chrome은 기본 navigator.webdriver=true와 균일한 마우스 궤적을 보내 탐지됩니다. 따라서 레지덴셜 IP 위에 스텔스 브라우저(예: Playwright + 지문 주입 패치)를 올려야 JA3/JA4·캔버스·행동 신호가 실제 사용자와 일치합니다.
정리: IP 평판은 '1차 필터'이고, TLS/행동 지문은 '2차 필터'입니다. 레지덴셜 프록시는 1차를 통과시키고, 스텔스 브라우저는 2차를 통과시킵니다. 둘 다 필요합니다.
실전: ProxyHat 레지덴셜 출구 vs 데이터센터 IP를 IPQS API로 비교
이제 실제로 IPQS Proxy Detection API를 호출해 ProxyHat 레지덴셜 출구와 일반 데이터센터 IP의 점수를 비교해 봅니다. 먼저 ProxyHat 게이트웨이를 통해 두 종류의 출구 IP를 확보한 뒤, 그 출구 IP를 IPQS API로 검증합니다.
1단계: 출구 IP 확인
ProxyHat HTTP 게이트웨이는 gate.proxyhat.com:8080입니다. 레지덴셴셜 출구를 미국으로 지정하려면 사용자 이름에 -country-US 플래그를 넣습니다. 데이터센터 출구는 별도의 데이터센터 자격증명을 사용합니다.
# 레지덴셜 출구 IP 확인
curl -x http://user-country-US:pass@gate.proxyhat.com:8080 https://api.ipify.org
# 예: 73.142.x.x (Comcast, ISP)
# 데이터센터 출구 IP 확인
curl -x http://dc-user-country-US:pass@gate.proxyhat.com:8080 https://api.ipify.org
# 예: 52.91.x.x (AWS, 호스팅)</pre></code>
<h3>2단계: IPQS API 호출 (Python)</h3>
<pre><code>import requests
def ipqs_lookup(ip: str, key: str) -> dict:
url = f"https://www.ipqualityscore.com/api/json/ip/{key}/{ip}"
params = {"strictness": 1, "user_agent": "", "fastera": "false"}
r = requests.get(url, params=params, timeout=10)
r.raise_for_status()
return r.json()
residential = ipqs_lookup("73.142.x.x", "YOUR_IPQS_KEY")
datacenter = ipqs_lookup("52.91.x.x", "YOUR_IPQS_KEY")
for label, data in [("Residential", residential), ("Datacenter", datacenter)]:
print(f"{label}: fraud={data['fraud_score']} "
f"proxy={data['proxy']} vpn={data['vpn']} tor={data['tor']} "
f"recent_abuse={data['recent_abuse']} "
f"conn={data['connection_type']} asn={data['ASN']}")
실제 측정에서 레지덴셜 출구는 보통 fraud_score 0~15, connection_type=Residential, proxy=false, recent_abuse=false로 나옵니다. 반면 AWS 데이터센터 IP는 fraud_score 85~95, connection_type=Corporate/Datacenter, proxy=true에 가까운 패턴을 보입니다. 이 차이가 곧 '통과 vs 차단'입니다.
3단계: 세션 고정으로 출구 일관성 유지
스크래핑/자동화에서는 같은 출구를 일정 시간 유지해야 쿠키·세션이 꼬이지 않습니다. ProxyHat은 사용자 이름에 -session- 플래그로 고정 세션을 지원합니다.
# 10분간 동일 레지덴셜 출구 유지
curl -x http://user-country-US-session-task123:pass@gate.proxyhat.com:8080 https://example.com
세션 ID를 바꾸면 새 출구로 회전합니다. 이 회전 전략은 웹 스크래핑과 SERP 추적에서 최근 악용 이력이 한 IP에 누적되는 것을 방지합니다.
흔한 실수와 엣지 케이스
- 데이터센터 IP + 스텔스 브라우저 조합: 행동 지문은 통과해도 IPQS가 ASN으로 1차 차단합니다. IP가 먼저여야 합니다.
- 레지덴셜 단일 IP 과사용: 한 출구로 시간당 수천 요청을 보내면 행동 ML이
bot_status=true를 부여하고, 결국recent_abuse가 채워집니다. 분당 20~60 요청 수준으로 회전을 섞으세요. - rDNS 불일치 무시: 일부 레지덴셜 풀은 rDNS가 비어 있거나 비-ISP 도메인입니다. IPQS는 이를 약한 프록시 신호로 해석해 점수가 10~20점 오를 수 있습니다.
- 지리 표지 불일치: 미국 IP에 한국
Accept-Language·시간대를 보내면 VPN 의심 점수가 올라갑니다. 출구 국가에 맞춰 언어·시간대 헤더를 정렬하세요. - IPQS 캐싱 주기: 점수는 변동합니다. 24시간 이상 캐싱하면 최근 악용 이력 반영이 늦어집니다. 1~6시간 TTL이 안전합니다.
윤리적 프레임: 자체 품질 검증과 합법적 자동화
이 글의 모든 기법은 (1) 자신이 소유/운영하는 IP 풀의 품질 검증, (2) 사전 승인된 침투 테스트, (3) robots.txt와 서비스 약관을 준수하는 합법적 자동화를 전제로 합니다. 결제 사기, 자격증명 스터핑, 티켓/스니커즈 불법 선점, 리셀러 어뷰징에는 절대 사용해서는 안 됩니다.
법적 측면에서, EU 거주 사용자 데이터를 처리하는 IPQS 호출은 GDPR 하에 합법적 근거가 필요하며, 미국에서는 CFAA(Computer Fraud and Abuse Act)가 '초과 접근'을 넓게 해석하므로 타겟 사이트의 명시적 허가나 공개 데이터 수집 범위 내에서만 동작해야 합니다. IPQS API 호출 자체는 IP에 대한 개인정보 처리이므로, 자체 IP 검증 목적이더라도 데이터 처리 근거를 문서화해 두는 것이 권장됩니다.
ProxyHat 설정 요약
- 게이트웨이:
gate.proxyhat.com:8080(HTTP),gate.proxyhat.com:1080(SOCKS5) - 국가 지정:
http://user-country-US:pass@gate.proxyhat.com:8080 - 도시 지정:
http://user-country-DE-city-berlin:pass@gate.proxyhat.com:8080 - 세션 고정:
http://user-session-abc123:pass@gate.proxyhat.com:8080
더 많은 연동 예시는 ProxyHat 문서와 요금제에서 확인할 수 있습니다. 레지덴셜 풀의 국가/도시 세분화는 IPQS 지리 일치성 점수를 높이는 가장 직접적인 방법입니다.
핵심 요약 (Key Takeaways)
- IPQS 사기 점수는 허니팟·ASN·블랙리스트·ML·실시간 포렌식을 결합한 0~100 점수이며, 90 이상 차단·75~90 추가 검증이 일반적입니다.
- 데이터센터 IP는 호스팅 ASN 하나로 이미 60~80점에서 시작해 사실상 차단됩니다.
- 진짜 ISP 기반 레지덴셜 프록시는 ASN·rDNS·지리정보·포트·최근 악용 이력이 모두 '일반 사용자'와 일치해 점수 0~15를 받습니다.
- IP 통과 위에 JA3/JA4 TLS 지문과 캔버스·행동 지문 일치까지 확보해야 2차 방어선을 넘습니다.
- 출구 IP는 정기적으로 IPQS API로 검증하고, 세션 회전으로 최근 악용 이력 누적을 방지하세요.
- 모든 사용은 자체 품질 검증·승인된 테스트·합법적 자동화 범위 내에서, GDPR·CFAA를 준수해야 합니다.
다음 단계로, ProxyHat 레지덴셜 출구로 자체 IPQS 점수를 측정해 보고, 90점 미만 출구 비율을 모니터링 대시보드에 올리는 것을 추천합니다. IP 평판은 더 이상 '설정 후 잊는' 값이 아니라, 매일 변동하는 운영 지표입니다.
