정리: 비교표와 고르는 법

아프로·2026년 10월 30일

IP 평판은 어떻게 만들어지고, 어떻게 써야 하나

목록 보기

9/10

정리: 비교표와 고르는 법 표지

시리즈 첫 편의 장면은 같은 IP를 네 서비스에 물었더니 "안전", "의심 25점", "위험 100점", "엔진 2개 탐지"가 나왔다는 것이었습니다. 이제 그 네 답이 왜 다른지 설명할 수 있습니다. 하나는 등록 정보를 봤고, 하나는 신고를 셌고, 하나는 미끼와 요청 문맥으로 채점했고, 하나는 남의 엔진 판정을 개수로 보여 줬습니다. 누구 말이 맞느냐가 아니라, 각자 무엇을 봤느냐의 문제였습니다. 마지막 편은 그 차이를 한 표에 모으고, 무엇부터 고를지 정합니다.

한 표로: 여섯 솔루션

솔루션 여섯을 데이터 출처, 판정 방식, 제공 형태, 강점, 맹점, 무료로 시작하는 법 여섯 줄로 비교한 표 그림

열이 솔루션, 줄이 비교 항목입니다. 각 칸은 04~09편에서 문서로 확인한 것을 짧게 줄였습니다. 강점과 맹점은 글쓴이의 정리이고, 회사의 주장은 넣지 않았습니다.

	MaxMind	AbuseIPDB	IPQS	VirusTotal	Cisco Talos	Criminal IP
데이터 출처(02편의 여섯 자리)	① 등록·라우팅 중심, minFraud는 고객 거래	③ 커뮤니티 신고. 위치·용도는 IPinfo	④ 허니팟·트랩, ⑤ 크롤러, 참여 사이트(회사 설명)	⑥ 70개 넘는 엔진·차단 목록 취합	② 수만 조직의 메일 볼륨, SpamCop 신고, 트랩	⑤ 인터넷 전체 스캔(포트·배너·인증서)
판정 방식	0/1 성격 플래그, 위치와 정확도 반경. minFraud는 거래 위험 0.01~99	신뢰 점수 0~100, 서로 다른 신고자 수와 시간 감쇠, 매일 재계산	`fraud_score` 0~100(75 의심·90 고위험), 요청 문맥을 함께 채점	엔진별 판정의 개수, 투표자 평판으로 가중한 커뮤니티 점수	이메일 -10~+10(화면은 Good·Neutral·Poor), 웹 등급 6단계	inbound·outbound 각 5단계(Safe~Critical)
제공 형태	로컬 mmdb 파일(매일·평일 갱신), 웹 서비스, minFraud API	CHECK API, 미리 만든 BLACKLIST	REST API(키·IP가 URL에)	REST API, 조회 화면	Cisco 장비 연동, 공개 조회 화면	REST API, 방향별 TI 피드(1시간), 검색 화면
강점	사용자 IP가 밖으로 안 나감, 지연이 거의 없음	서버 대역 스캔·대입 공격처럼 여러 곳이 함께 당하는 공격	가입·결제 순간의 프록시·봇 신호, 공유 회선 표시	침해 분석에서 IP→도메인→파일로 따라가기	받는 쪽 메일 장비가 본 발송 IP	근거 묶음(`issues`)과 방향, 내 자산 노출 보기
맹점	"지금 공격 중인가"는 모름. 호스팅 플래그는 나쁨이 아님	신고자가 없는 공격(앱 API 등), CGNAT 뒤 무고한 사람	사용자 정보를 보내야 함, 점수 하나로 자동 차단하기 쉬움	다수결이 아님, 같은 목록이 겹쳐 세짐, 조회가 공개 데이터셋에	메일을 안 보내는 IP는 기록 없음, 정확한 점수는 고객만	열린 포트는 공격자가 아님, 스캔 사이의 변화
무료로 시작	공개 테스트 mmdb로 코드 먼저, GeoLite 계정·라이선스 키	무료 하루 check 1,000(상업 목적 금지)	"1,000 Free Lookups"(조건 확인 필요)	공개 API 하루 500·분당 4(상업 금지)	조회 화면, 내 IP 이의 제기 티켓	무료 회원 IP 조회 월 50

표를 읽는 요령은 하나입니다. "데이터 출처" 줄이 나머지 줄을 거의 정합니다. 신고에서 출발하면 신고자가 있는 곳만 보이고, 스캔에서 출발하면 열린 것만 보이고, 등록 정보에서 출발하면 성격만 압니다. 강점과 맹점은 출처의 앞면과 뒷면입니다.

데이터가 어디서 오나: 여섯 자리 위에 다시

02편의 수집 자리 여섯(등록·라우팅, 자기 제품 관측, 신고, 미끼·트랩, 능동 스캔, 다른 엔진 취합)을 세로로, 솔루션 여섯을 가로로 놓고 각 칸에 주 출처, 보조 출처, 글쓴이 추정을 표시한 그림

줄이 수집 자리, 열이 솔루션입니다. 꽉 찬 원은 문서로 확인한 주 출처, 빈 원은 문서로 확인한 보조 출처, 노란 점선 칸은 글쓴이의 추정, 빈칸은 단서가 없는 곳입니다. 각 솔루션 편의 "데이터 출처 지도"를 한 장에 모았습니다.

꽉 찬 원(주 출처)이 대부분 서로 다른 줄에 흩어져 있다는 점이 요점입니다. 여섯 솔루션의 주 출처가 거의 겹치지 않습니다. 그래서 13편의 rep-hub처럼 여러 소스를 묶으면 서로의 맹점을 덮을 수 있습니다. 반대로 같은 줄에 원이 여럿 있는 ⑥(취합)은 겹쳐 세기를 조심할 곳입니다.

추정 구조 여섯 장을 한 장에

⚠️ 글쓴이의 추정입니다. 아래 구조도와 흐름은 각 회사의 공식 아키텍처가 아닙니다. 공개 문서, API 응답 필드, 제품 설명에서 보이는 단서로 글쓴이가 "이렇게 만들었을 것"이라고 그려 본 그림을 모은 것입니다. 실제 구현은 다를 수 있습니다.

글쓴이가 추정한 MaxMind·AbuseIPDB·IPQS의 구조를 02편 공통 구조(수집, 정규화, 결합, 점수, 배포, 이의 제기) 여섯 칸 위에 한 줄씩 놓은 그림. 추정 칸은 노란 점선

글쓴이가 추정한 VirusTotal·Cisco Talos·Criminal IP의 구조를 같은 여섯 칸 위에 한 줄씩 놓은 그림. 추정 칸은 노란 점선

두 그림 모두 줄이 솔루션, 열이 02편의 공통 구조 여섯 칸입니다. 흰 실선 칸은 문서로 확인한 겉모습, 노란 점선 칸은 글쓴이의 추정입니다. 주황 테두리는 그 솔루션에서 가장 두꺼워 보이는 칸입니다.

각 편에서 그린 그림을 이렇게 한 줄씩 놓으면 차이가 선명합니다.

솔루션	가장 두꺼워 보이는 칸	한 줄 추정	단서
MaxMind	배포	스냅숏을 정해진 시각에 통째로 구워 파일로 내보내는 배치	파일마다 빌드 날짜, 델타 없는 전체 교체
AbuseIPDB	점수	신고 원본을 시계열로 두고 조회 때 기간으로 잘라 세고, 목록은 미리 구움	`maxAgeInDays`, BLACKLIST 하루 5회와 `generatedAt`
IPQS	점수	IP 특징 저장소 + 요청 문맥을 합쳐 조회 때 채점	같은 IP도 `strictness`·user agent로 점수가 바뀜
VirusTotal	결합	엔진 결과를 가공 없이 중계하고, 파일·URL·도메인을 잇는 관계 그래프	엔진별 `method`, 관계 필드
Talos	수집	고객 메일 장비와 Talos가 볼륨·결과를 주고받는 닫힌 고리	수만 조직의 볼륨 정보, 장비가 연결 순간 점수를 씀
Criminal IP	결합	인터넷 스캔 위의 자산 그래프. 남의 IP를 물으면 평판, 내 도메인을 물으면 ASM	모든 근거에 `confirmed_time`, 방향별 점수와 피드

이 표의 "한 줄 추정"은 모두 추정입니다. 각 편의 "단서 → 그래서 이렇게 보인다" 표에 근거를 자세히 적었습니다.

이런 팀은 이것부터

팀 상황별로 무엇부터 붙일지 고르는 결정 그림. 먼저 지키려는 것이 웹 서비스의 사용자 요청인지, 내 서버 인프라인지, 관제와 침해 분석인지, 메일 발송인지, 내 회사 노출 자산인지로 나누고, 사용자 요청이면 사용자 IP를 밖으로 보내도 되는지로 한 번 더 나눈다

위에서 아래로 따라갑니다. 첫 갈림길은 무엇을 지키려는가이고, 웹 서비스라면 두 번째 갈림길은 사용자 IP를 밖으로 보내도 되는가(12편 ④)입니다. 맨 아래 상자는 어느 길로 가도 함께 붙이는 것입니다.

이런 팀	이것부터	이유와 주의
웹 서비스, 사용자 IP를 밖으로 보내기 어렵다	MaxMind 로컬 DB + 계정 신호	요청마다 조회해도 지연이 거의 없고 IP가 안 나감. 성격 플래그는 기록·추가 인증 재료로만(14편)
가입·쿠폰·이벤트 어뷰징이 문제다	IPQS를 가입·결제 순간에만	모든 요청이 아니라 몇 화면에. 75·90 구간도 내 트래픽으로 다시 잼
서버에 SSH·로그인 대입과 스캔이 쏟아진다	AbuseIPDB(유료 요금제 또는 사내 관제용)	75 이상 + 데이터센터 대역은 TTL 차단 후보. 모바일·CGNAT은 막지 않음. 무료 키는 상업 목적 금지
보안 관제·침해 분석을 한다	VirusTotal(사람이 조회) + Criminal IP(근거·방향)	로그인 경로 자동 판정에는 쓰지 않음. 고객 IP를 VirusTotal에 묻지 않음
메일을 대량으로 보낸다	Postmaster·SNDS + DMARC 보고서 (+ Talos 평판 등급)	내 발송 IP를 지켜보는 쪽. 10·11편
우리 회사 노출 자산이 궁금하다	Criminal IP ASM	내가 소유한 자산만. 남의 자산은 보지 않음(09편)
이미 Cisco 메일·웹 보안 장비를 쓴다	장비의 Talos 평판 정책부터	따로 붙일 것 없이 장비 설정을 먼저 점검

어느 칸을 골라도 공통으로 붙이는 것이 있습니다.

평판 조회를 한곳으로(13편). 척도 맞추기, 이유 목록, 캐시, 시간 제한, 서킷 브레이커.
차단하지 말고 마찰부터(14편). IP 평판만으로는 추가 인증·검토까지, 차단은 계정 신호가 있을 때.
섀도 모드로 먼저 재기(14편). 내 트래픽의 오탐 사례를 읽고 나서 켜기.

첫 장면 다시 읽기: 같은 IP, 다른 대답

00편의 네 대답을 이제 직접 만들어 볼 수 있습니다. 13편의 rep-hub에 CGNAT 공인 IP 역할인 203.0.113.7을 물었을 때, 소스마다 따로 낸 등급입니다.

실제 출력(2026-10-31, macOS, lab/results/13-rephub-check.txt의 한 줄. ms는 매번 다름):

sources: {"maxmind": {"status": "ok", "level": "unknown", "cached": false, "ms": 0.11}, "abuseipdb": {"status": "ok", "level": "review", "cached": false, "ms": 30.67}, "ipqs": {"status": "ok", "level": "watch", "cached": false, "ms": 26.49}, "virustotal": {"status": "ok", "level": "low", "cached": false, "ms": 37.74}, "talos": {"status": "ok", "level": "low", "cached": false, "ms": 26.78}, "criminalip": {"status": "ok", "level": "low", "cached": false, "ms": 26.71}}

합친 결과는 13편에 옮긴 대로 "level": "review"이고, 이유는 abuseipdb:score=34,reports=6,reporters=3, ipqs:shared_connection, combine:shared_ip_possible 등 8개입니다.

같은 IP인데 등급이 넷으로 갈렸습니다. 이유는 비교표의 첫 줄에 있습니다.

MaxMind는 모릅니다. 이 실험실의 로컬 DB는 테스트용이라 이 주소가 없습니다. 실제 DB였다면 "모바일 통신사 회선"이라는 성격을 줬을 것입니다. 나쁜지 아닌지는 말하지 않습니다.
AbuseIPDB는 review입니다. 신고 6건, 신고자 3명. 그 뒤의 공격자 한 명이 남긴 사건입니다. 같은 주소를 쓰는 다른 사람들의 일은 아닙니다.
IPQS는 watch입니다. 점수는 48이지만 shared_connection을 켭니다. "여럿이 쓰는 연결"이라는 단서를 함께 줍니다.
VirusTotal·Talos·Criminal IP는 low입니다. 엔진 목록에도, 메일 기록에도, 스캔 근거에도 이 주소의 흔적이 없습니다. "깨끗하다"가 아니라 "본 적 없다"에 가깝습니다.

rep-hub는 이것을 review 하나로 묶고, 공유 IP 힌트 때문에 그 이상 올리지 않습니다. 14편의 정책 ③은 이 IP에 1점만 주고 계정 신호를 봅니다. 그래서 이 주소 뒤의 정상 사용자 300명은 대부분 아무 일도 겪지 않았습니다. 누구 말이 맞는지 고르는 대신, 각자 본 것을 근거로 남기고 행동은 신원 신호와 함께 정한다. 이 시리즈의 결론이 이 한 문단입니다.

다음 단계

시리즈를 다 읽은 뒤 바로 해 볼 수 있는 순서입니다. 모두 무료로 시작할 수 있습니다.

지키려는 화면을 적습니다. 가입, 로그인, 결제, 이벤트, API 중 어디가 문제인지, 그 화면에서 실수의 값이 무엇인지(14편의 표).
로그에서 IP 분포를 봅니다. 모바일 통신사 비율, 데이터센터 비율, 해외 비율. 공유 IP가 많을수록 IP 기준 대응이 위험합니다(03편).
로컬 DB부터 붙입니다. GeoLite 계정을 만들고, 공개 테스트 mmdb로 짠 코드를 실데이터로 바꿉니다. 성격 플래그를 기록에만 남깁니다(04편).
외부 소스는 한 화면에만 섀도로. 가장 손해가 큰 화면에서, 약관이 허락하는 요금제로 시작합니다(12편 ⑤).
rep-hub 같은 한곳 조회를 둡니다. 이유 목록과 캐시, 시간 제한, 서킷 브레이커를 처음부터 넣습니다(13편).
2~4주 뒤 오탐 사례를 읽고, 추가 인증부터 켭니다. 차단은 맨 나중이고, 반드시 TTL과 푸는 버튼을 함께 둡니다(14편).
메일을 보낸다면 따로 챙깁니다. 발송 IP 평판은 받는 쪽이 매깁니다. DMARC 집계 보고서와 Postmaster·SNDS로 지켜봅니다(10·11편).

이 시리즈에서 잰 숫자 다시 보기

시리즈 4부의 실습이 이어지는 흐름. 여러 평판 소스가 rep-hub로 모여 등급과 이유가 되고, 화면별 정책이 행동을 정하고, 섀도 모드가 정상 사용자와 봇에 대한 결과를 잰다. 각 단계에서 잰 대표 숫자를 붙임

왼쪽에서 오른쪽으로 13편과 14편의 실습이 이어집니다. 아래 숫자는 모두 이 실험실의 녹화 응답과 가짜 트래픽에서 잰 값입니다. 실제 서비스의 오탐률이 아닙니다.

무엇을	잰 값	편
캐시를 켜면	적중률 92.5%, 외부 호출 15,000 → 1,132번(요청 3,000건)	13
좋음 TTL 6시간 → 1시간	새 공격을 늦게 본 요청 1,512 → 136건, 외부 호출 약 2배	13
외부 소스 하나가 응답하지 않을 때	시간 제한만 있으면 서버 p50 300.8ms, 브레이커를 켜면 49.1ms	13
장애 때 fail-open vs fail-closed	봇 review 이상 61.5% → 40.4% / 정상 review 이상 39.0% → 100%	13
"review 이상이면 차단"	정상 사용자 330명 차단(CGNAT 300, VPN 30), 봇 탐지 67.7%	14
IP 평판 + 계정 신호	정상 마찰 3.7%, 차단 2명, 봇 탐지 96.4%	14
IP 평판이 더한 몫	계정 신호만 76.1% → 함께 96.4%(대부분 데이터센터 봇)	14

오탐과 한계

비교표는 문서 기준입니다. 실제 정확도, 응답 시간, 오탐률은 비교하지 않았습니다. 유료·키가 필요한 API는 이 시리즈에서 한 번도 부르지 않았습니다.
추정 구조는 추정입니다. 여섯 장 모두 공개 문서와 응답 필드에서 끌어낸 그림이고, 어느 회사도 이 구조를 확인해 주지 않았습니다.
요금·한도·약관은 자주 바뀝니다. 표의 숫자는 2026-10-31 기준입니다. 도입 전에 공식 페이지를 다시 보세요.
"이런 팀은 이것부터"는 출발점입니다. 한 팀에 여러 칸이 해당하면 여러 개를 쓰고, 그때는 13편처럼 한곳에서 묶습니다.
개인정보·국외 이전·약관 부분은 법률 자문이 아닙니다(12편).

실무 체크

솔루션을 고르기 전에 "무엇을 지키나"와 "사용자 IP를 밖으로 보내도 되나"부터 답합니다.
고른 솔루션의 주 출처가 내 위협과 맞는지 비교표의 첫 줄로 확인하고, 맹점은 다른 소스나 계정 신호로 덮습니다.
도입은 rep-hub 같은 한곳 조회 → 섀도 모드 → 한 화면의 약한 행동부터 켜기 순서로 합니다.

정리

IP 평판 점수가 서로 다른 것은 오류가 아니라 출처의 차이입니다. 등록 정보, 자기 장비, 신고, 미끼, 스캔, 취합은 각자 다른 것을 봅니다.
여섯 솔루션의 주 출처는 거의 겹치지 않습니다. 그래서 묶으면 서로를 보완하지만, 척도 맞추기와 겹쳐 세기 조심이 필요합니다.
점수는 판정이 아니라 재료입니다. 화면마다 다른 사다리에서 추가 인증까지 쓰고, 강한 대응은 계정 신호와 함께 씁니다.
고르는 순서는 "무엇을 지키나 → IP를 밖으로 보내도 되나 → 그 위협을 보는 출처는 누구인가"입니다.