점수는 어떻게 만들어지고, 왜 틀리나: 감쇠·가중치·공유 IP

아프로·2026년 10월 30일

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

목록 보기

4/10

점수는 어떻게 만들어지고, 왜 틀리나 표지

고객센터에 문의가 들어옵니다. "어제부터 로그인이 안 돼요." 확인해 보니 고객이 쓰는 모바일 통신사의 공인 IP 하나가 평판 점수 기준을 넘어 차단돼 있었습니다. 그 IP 뒤에는 이 고객 말고도 수많은 가입자가 있습니다. 공격자는 한 명이었을지도 모릅니다. 점수는 틀린 걸까요, 아니면 우리가 점수를 틀리게 쓴 걸까요? 이번 편은 점수를 움직이는 손잡이(감쇠·가중치·대역 번짐)를 직접 돌려 보고, 오탐이 생기는 네 가지 원인을 숫자로 봅니다.

이 편의 계산식은 장난감입니다

먼저 분명히 해 둡니다. 이 편의 점수 계산식은 설명용으로 글쓴이가 만든 장난감 모형이고, 어느 회사의 실제 공식도 아닙니다. 실제 평판 서비스는 대개 공식을 공개하지 않습니다. 예를 들어 AbuseIPDB는 점수를 "신고한 사용자들을 바탕으로 계산한 평가"라고만 설명합니다. 그래도 공개 문서에는 손잡이가 보입니다. AbuseIPDB는 조회 때 maxAgeInDays(1~365, 기본 30)로 며칠 치 신고를 볼지 고르게 합니다. 시간이 점수에 들어간다는 단서입니다. VirusTotal은 IP 객체의 reputation을 투표한 사용자들의 평판으로 가중한 커뮤니티 점수라고 설명합니다. 신고자마다 무게가 다르다는 단서입니다.

이 단서들을 가장 단순한 식으로 옮겨, "무엇을 돌리면 점수가 어떻게 움직이나"를 봅니다.

장난감 점수 모형의 흐름. 신고 기록, 같은 신고자·같은 날 중복 제거, 신고자 가중치, 반감기 감쇠를 거쳐 R을 합하고 100×(1−e^(−R/3)) 곡선으로 점수를 만든다. 설명용 모형 꼬리표

윗줄 ①~④를 왼쪽부터 지나면 신고 한 건이 "남아 있는 증거의 양" 하나가 됩니다. 아랫줄에서 그 양을 모두 더한 R을 곡선에 넣어 0~100점으로 만듭니다. 회색 꼬리표는 "설명용 모형"이라는 뜻입니다. 추정(노란 꼬리표)과 다릅니다.

모형은 이렇습니다(lab/score-model/toy_score.py).

점수 = 100 × (1 − exp(−R / 3))
R    = Σ (신고자 가중치 w) × 0.5 ^ (신고 나이(일) / 반감기)
       같은 신고자의 같은 날 신고는 1건으로 센다
가중치 w: 새 계정 0.2, 검증된 신고자 1.0, 미끼 서버 1.5

반감기(half-life): 신고의 무게가 절반이 되는 시간입니다. 반감기 7일이면 7일 된 신고는 0.5건, 14일 된 신고는 0.25건으로 셉니다.
곡선: R이 아무리 커져도 100을 넘지 않게 누릅니다. R=3이면 약 63점입니다. 숫자 3은 눈금을 정하려고 고른 값입니다.

모든 신고는 가짜이고, IP는 문서용 주소만 씁니다.

손잡이 ①: 시간 감쇠

같은 신고 기록을 반감기만 바꿔 계산했습니다.

cd lab/score-model
../.venv/bin/python -I toy_score.py

실제 출력(2026-10-31, macOS · Python 표준 라이브러리만):

== 1) 같은 신고 기록, 다른 반감기 ==
시나리오                                   반감기1일     반감기7일    반감기30일      감쇠없음
A 30일 전 집중 공격(검증 신고자 20명)                0.0      29.0      96.4      99.9
B 최근 이틀 꾸준히(검증 3명)                      41.7      59.4      62.3      63.2
C 오늘 미끼 서버 1회 적중                        37.3      39.0      39.3      39.3
D 새 계정 1개가 오늘 40번 신고                     6.4       6.4       6.4       6.4
E 새 계정 15개가 오늘 1번씩                      60.7      62.8      63.1      63.2

A줄을 보세요. 30일 전에 검증된 신고자 20명이 신고한 IP입니다. 반감기 1일이면 0점, 7일이면 29점, 30일이면 96점, 감쇠가 없으면 거의 100점입니다. 같은 사실에서 "깨끗함"과 "확실한 위험"이 모두 나옵니다.

어느 쪽이 맞을까요? 질문에 따라 다릅니다.

"지금 이 IP를 막아야 하나"라면 짧은 반감기가 맞습니다. 30일 전 공격자가 아직 그 IP를 쓴다는 보장이 없습니다. 클라우드 IP라면 이미 다른 고객의 서버일 수 있습니다.
"침해 분석에서 이 IP를 본 적 있나"라면 긴 기간이 맞습니다. 사건을 거슬러 올라갈 때는 오래된 기록도 증거입니다.

시간에 따른 점수 곡선

0일째에 검증된 신고자 10명이 신고하고, 그 뒤로 신고가 없는 IP의 점수를 120일 동안 따라갔습니다.

== 4) 0일째 검증 신고 10건 뒤 점수 변화(기준선 50점을 넘는 마지막 날) ==
반감기1일     0일  96.4  7일   2.6  30일   0.0  60일   0.0  120일   0.0  50점 이상 마지막 날: 2
반감기7일     0일  96.4  7일  81.1  30일  15.7  60일   0.9  120일   0.0  50점 이상 마지막 날: 15
반감기30일    0일  96.4  7일  94.1  30일  81.1  60일  56.5  120일  18.8  50점 이상 마지막 날: 68
감쇠없음      0일  96.4  7일  96.4  30일  96.4  60일  96.4  120일  96.4  50점 이상 마지막 날: 120

0일째 신고 10건 뒤 점수가 반감기 1일·7일·30일·감쇠 없음에 따라 떨어지는 네 곡선과 기준선 50점. 설명용 모형

가로축이 날짜, 세로축이 점수입니다. 검은 점선(50점)을 각 곡선이 언제 지나 내려가는지 보세요. 같은 시작점(96.4점)에서 출발해도 "막히는 기간"이 2일, 15일, 68일, 영원으로 갈립니다.

이 그림에서 두 가지를 기억합니다.

감쇠가 없는 목록은 시간이 갈수록 오탐 목록이 됩니다. 회색 점선은 영원히 96점입니다. IP는 주인이 바뀌는데 점수는 그대로입니다. 앞 시리즈 방어선 2-②에서 "만료 없는 목록은 시간이 갈수록 오탐 목록이 된다"고 쓴 이유입니다.
갱신 주기보다 감쇠가 더 중요합니다. 평판 데이터를 "실시간"으로 받아도 감쇠가 없으면 오래된 근거가 계속 남습니다. 반대로 하루 한 번 받는 목록이라도 항목마다 나이를 들고 있으면 덜 틀립니다(12편 ① 갱신 주기와 점수 감쇠).

손잡이 ②: 신고자 가중치와 중복 제거

신고 자리(02편 ③)는 넓지만 시끄럽습니다. 같은 사람이 같은 IP를 몰아서 신고하거나, 만든 지 얼마 안 된 계정 여러 개가 한꺼번에 신고할 수 있습니다. 그것을 얼마나 깎느냐가 점수를 감쇠만큼 크게 바꿉니다.

실제 출력(2026-10-31, macOS):

== 2) 중복 제거를 끄면(시나리오 D, 반감기 7일) ==
중복 제거 켬: 6.4   끔: 92.7

== 3) 신고자 가중치를 모두 1로 두면(반감기 7일) ==
C 오늘 미끼 서버 1회 적중                   가중치 같음:  28.1
E 새 계정 15개가 오늘 1번씩                 가중치 같음:  99.3
C 오늘 미끼 서버 1회 적중                   가중치 다름:  39.0
E 새 계정 15개가 오늘 1번씩                 가중치 다름:  62.8

같은 신고 기록에서 중복 제거를 켜고 끄면 6.4점과 92.7점, 신고자 가중치를 다르게 두거나 모두 1로 두면 62.8점과 99.3점, 미끼 서버 적중은 39.0점과 28.1점이 되는 막대그래프. 설명용 모형

막대 한 쌍이 같은 사건입니다. 위 막대와 아래 막대의 차이는 계산 규칙 하나뿐입니다. 막대 길이가 점수(0~100)입니다.

D: 한 계정이 40번 신고. 중복 제거를 끄면 92.7점입니다. 한 사람의 의견이 40명의 의견처럼 셉니다. 신고 기반 평판에서 남의 IP를 목록에 올리려는 시도(경쟁사·개인을 겨냥한 오신고)를 막는 첫 장치가 신고자별 중복 제거입니다.
E: 새 계정 15개가 1번씩. 신고자 신뢰도를 두지 않으면 99.3점, 새 계정에 낮은 무게를 주면 62.8점입니다. 계정을 여러 개 만들면 중복 제거만으로는 막을 수 없어서 신고자의 이력(검증 여부, 과거 신고의 정확도)이 필요합니다.
C: 미끼 서버 1회 적중. 반대 방향입니다. 미끼 서버(02편 ④)는 오신고가 거의 없으니 무게를 더 주면 한 번의 적중으로 39점이 됩니다. 모두 같은 무게로 두면 28점입니다.

실제 서비스가 이 손잡이를 어떻게 두었는지는 대개 공개되지 않습니다. 그래서 2부의 솔루션 편에서는 "점수에 신고자 신뢰도가 들어가는가"를 문서의 단서로 확인하고, 단서가 없으면 추정이라고 표시합니다.

손잡이 ③: 대역 번짐

203.0.113.0/24를 64칸(칸 하나에 주소 4개) 격자로 그려 신고된 IP가 있는 칸과 신고 0건인 이웃 .77을 표시하고, 이웃 점수 계산과 번져도 되는 곳·번지면 안 되는 곳을 나눈 그림

왼쪽 격자가 /24 대역 하나(주소 256개)입니다. 빨간 칸에 신고된 IP가 있고, 노란 점선 칸이 신고가 한 건도 없는 이웃 203.0.113.77입니다. 오른쪽 첫 상자가 이웃이 물려받는 점수, 아래 두 상자가 번짐을 허용해도 되는지 판단하는 기준입니다. 번짐 방식은 설명용 모형이라 꼬리표를 붙였습니다.

02편의 엔터티 결합에서 봤듯, 평판은 IP 하나에서 이웃 대역으로 번질 수 있습니다. 장난감 모형에서는 "같은 /24에서 나쁜 IP의 비율 × α"를 이웃에게 얹었습니다.

실제 출력(2026-10-31, macOS):

== 5) 대역 번짐(같은 /24의 나쁜 IP 비율을 이웃에게 얹기, α=0.5) ==
203.0.113.0/24 안 나쁜 IP   1개(  0.4%) → 신고 0건인 이웃 203.0.113.77 점수   0.2
203.0.113.0/24 안 나쁜 IP   3개(  1.2%) → 신고 0건인 이웃 203.0.113.77 점수   0.6
203.0.113.0/24 안 나쁜 IP  26개( 10.2%) → 신고 0건인 이웃 203.0.113.77 점수   5.1
203.0.113.0/24 안 나쁜 IP 128개( 50.0%) → 신고 0건인 이웃 203.0.113.77 점수  25.0

대역의 절반이 나쁘면 신고 0건인 이웃도 25점을 받습니다. 이것이 맞는 경우와 틀린 경우가 있습니다.

맞는 경우: 한 고객이 /24를 통째로 쓰는 호스팅 대역, 신고를 무시하는 이른바 방탄 호스팅(bulletproof hosting). 공격자가 IP를 바꿔도 같은 대역 안에서 바꿉니다.
틀린 경우: 통신사 가정용·모바일 대역, 클라우드 공용 대역, CDN. 이웃끼리 아무 관계가 없습니다. 01편의 등록·라우팅 정보(회선 성격)가 "번짐을 허용할지"를 정하는 재료입니다.

왜 틀리나: 주소는 사람이 아니다

손잡이를 잘 돌려도 틀리는 경우가 있습니다. 원인은 점수가 아니라 "IP = 사람"이라는 가정입니다.

오탐의 네 원인을 네 칸에 나눈 그림. 한 IP 많은 사람(CGNAT·NAT·공용 와이파이), 한 사람 많은 IP(IPv6), 빌린 정상 IP(주거 프록시), 주인이 바뀌는 IP(클라우드 IP 재사용)와 아래쪽 클라우드 IP 재사용의 가상 타임라인

네 칸의 주황 소제목이 각 원인의 한 줄 요약입니다. 맨 아래 줄은 클라우드 IP 재사용을 시간 순서로 그린 가상의 예입니다. 왼쪽 레드 칩의 사건이 오른쪽 노란 칩에서 엉뚱한 사람(나)의 피해로 끝납니다.

원인 1: 한 IP, 많은 사람(CGNAT)

통신사는 공인 IPv4 주소가 모자라서 CGNAT(Carrier-Grade NAT)로 여러 가입자가 공인 주소 하나를 나눠 쓰게 합니다. RFC 6598은 CGNAT 장비와 가입자 장비 사이에 쓰라고 100.64.0.0/10을 공유 주소 공간(Shared Address Space)으로 따로 떼어 두었습니다. 회사 NAT, 학교, 공용 와이파이도 같은 모양입니다. RFC 6269(IP 주소 공유의 문제)는 주소를 나눠 쓰면 로그인을 여러 번 실패한 한 사람 때문에 다른 사용자까지 막힐 수 있다고 적습니다.

정상 사용자 100명과 공격자 1명이 CGNAT의 공인 IP 하나로 로그인 API에 접속하고, IP·계정·IP+기기 기준 규칙별로 공격자 차단 여부와 함께 막힌 정상 사용자 수, 손실을 비교한 표. 설명용 모형

왼쪽 점 101개가 사람(그린 100명은 정상, 레드 1명은 공격자), 가운데가 CGNAT, 오른쪽이 내 로그인 API입니다. 아래 표는 같은 트래픽을 세 가지 기준으로 셌을 때의 결과입니다. 숫자는 lab/score-model/cgnat_cost.py의 실제 출력입니다.

장난감 계산으로 비용을 셉니다. 가정은 모두 가짜 값입니다.

정상 사용자 100명: 한 시간에 로그인 2회, 실패 확률 10%
공격자 1명: 한 시간에 300회(남의 계정 목록을 돌리는 크리덴셜 스터핑), 실패 확률 99%
규칙: 한 시간에 실패 20회 이상이면 24시간 차단

../.venv/bin/python -I cgnat_cost.py

실제 출력(2026-10-31, macOS · 난수 시드 고정):

한 시간 동안 로그인 실패: 정상 사용자 합계 17회, 공격자 297회 (난수 고정)
규칙: 한 시간 실패 20회 이상 → 24시간 차단

[IP 기준] 차단 키 1개 | 공격자 막힘=True | 함께 막힌 정상 사용자 100명 → 2,400 사용자·시간 손실
[계정 기준] 차단 키 0개 | 공격자 막힘=False | 함께 막힌 정상 사용자 0명 → 0 사용자·시간 손실
  (계정 기준은 공격자가 계정을 바꿔 가며 시도하면 못 잡는다 → 계정마다 실패 1회)
[IP + 기기 지문 기준(가정: 기기 구분 가능)] 차단 키 1개 | 공격자 막힘=True | 함께 막힌 정상 사용자 0명 → 0 사용자·시간 손실

정상 사용자만 있을 때 IP 기준 규칙:
  정상 100명의 실패 합계 17회 → 기준 20회 안 넘음
  같은 IP 뒤 정상 사용자    50명이면 실패 기댓값   10.0회/시간 → 통과
  같은 IP 뒤 정상 사용자   100명이면 실패 기댓값   20.0회/시간 → 경계: 시간대마다 넘었다 안 넘었다
  같은 IP 뒤 정상 사용자   300명이면 실패 기댓값   60.0회/시간 → IP 차단
  같은 IP 뒤 정상 사용자  1000명이면 실패 기댓값  200.0회/시간 → IP 차단

세 가지를 읽습니다.

IP 기준은 공격자를 막지만, 정상 100명을 함께 막습니다. 24시간 차단이면 2,400 사용자·시간의 손실입니다. 공격자 한 명을 막는 값으로 너무 비쌉니다.
계정 기준만으로는 이 공격을 못 막습니다. 크리덴셜 스터핑은 계정마다 한 번씩만 시도합니다. 계정마다 실패 1회라 어느 계정도 기준을 넘지 않습니다. 그래서 IP를 아예 버리면 안 되고, 다른 신호와 묶어야 합니다. 표의 셋째 줄은 "같은 IP 안에서 기기를 구분할 수 있다면"이라는 가정의 결과이고, 실제로 기기를 구분하는 방법(쿠키, 기기 지문, 행동)은 14편에서 다룹니다.
공격자가 없어도 걸립니다. 같은 IP 뒤 정상 사용자가 늘면 실패 횟수의 합이 저절로 기준을 넘습니다. 300명이면 기댓값만으로 차단입니다. 큰 통신사의 CGNAT 주소 하나 뒤에 몇 명이 있는지는 밖에서 알 수 없습니다.

평판 점수도 똑같이 당합니다. CGNAT 주소 하나에 신고가 쌓이면 그 점수는 그 주소 뒤 모두의 점수가 됩니다. 앞 시리즈 방어선 2-②의 실험실에서도 CGNAT 주소 두 개 뒤의 정상 사용자 50명이 IP 기준 규칙에 한 덩어리로 걸릴 뻔했습니다.

원인 2: 한 사람, 많은 IP(IPv6)

IPv6 주소에서 앞 64비트가 네트워크, 뒤 64비트가 인터페이스 ID임을 보이고, 같은 /64 안에서 주소를 바꾸는 요청 300번을 /128로 세면 못 잡고 /64로 묶으면 잡는다는 비교와 너무 넓게 묶을 때의 주의

맨 위 상자의 주황 부분이 같은 /64(한 가입자)입니다. 그 뒤가 매번 바뀝니다. 가운데 두 상자가 같은 요청 300번을 어떤 단위로 세느냐의 차이이고, 맨 아래 노란 상자가 반대 방향의 함정입니다.

IPv6 주소는 128비트입니다. 대부분의 유니캐스트 주소에서 뒤 64비트는 인터페이스 ID입니다(RFC 4291은 이것을 64비트로 정합니다). 앞 64비트가 네트워크, 즉 한 망입니다. RFC 6177은 가입자에게 최소 /64 하나, 대부분은 그보다 훨씬 많이 주라고 하고, 가정에는 /56 같은 크기를 예로 듭니다. 크기를 하나로 정하지는 않습니다.

그 결과 가입자 한 명이 바꿔 쓸 수 있는 주소가 /64 하나에만 2의 64제곱 개입니다. 같은 실행의 IPv6 부분입니다.

IPv6: 한 가입자가 /64를 받을 때(공격자가 /64 안에서 요청마다 주소를 바꿈, 2001:db8:1:2::/64)
  서로 다른 /128 주소 300개, 주소당 최대 시도 1회 → /128 기준 규칙은 아무도 못 막음
  /64로 묶으면 묶음 1개에 시도 300회 → /64 기준 규칙은 잡음
  예시 주소: 2001:db8:1:2:69ad:24e3:4de9:7bfe, 2001:db8:1:2:944f:9aeb:5727:e3b1

IPv6에서 주소 하나 단위의 평판은 거의 늘 빈칸입니다. 평판 DB에 주소를 올려도 다음 요청은 새 주소에서 옵니다. 그래서 IPv6는 /64로 묶어 세고, 평판을 조회할 때도 대역 단위 값이 있는지 봅니다. 반대로 /48이나 /32로 너무 넓게 묶으면 이웃 가입자까지 함께 막습니다. 통신사마다 가입자에게 주는 크기가 다르므로, 내 트래픽에서 "한 계정이 몇 개의 /64를 쓰나"를 재 보는 것이 출발점입니다.

원인 3: 빌린 정상 IP(주거 프록시)

주거 프록시(residential proxy)는 일반 가정의 회선을 거쳐 요청을 보내 주는 서비스입니다. 가정용 공유기나 앱에 들어간 프록시 기능을 통해 회선을 빌리는 경우가 있고, 집주인이 그 사실을 모를 수도 있습니다. 평판의 관점에서 문제는 둘입니다.

신호가 사라집니다. 01편의 등록·라우팅 정보로 보면 "통신사 가정용 회선"이라 정상처럼 보입니다. 데이터센터 판별로는 잡히지 않습니다.
막으면 집이 막힙니다. 그 IP를 막으면 그 집의 정상 가족이 막힙니다. 회선은 계속 바뀌므로 공격자는 다음 집으로 갑니다.

그래서 주거 프록시는 IP 평판만으로 다루기 어렵습니다. 일부 서비스는 주거 프록시를 따로 표시하는 칸을 둡니다(예: MaxMind Anonymous IP DB의 is_residential_proxy, 04편). 이 시리즈는 주거 프록시를 쓰는 법은 다루지 않고, 방어에서 어떻게 다룰지(마찰 더하기, 다른 신호와 합치기)만 다룹니다(14편).

원인 4: 주인이 바뀌는 IP(클라우드 IP 재사용)

클라우드의 공인 IP는 반납되면 다른 고객에게 갑니다. 어제 공격자가 쓰고 반납한 IP를 오늘 내 서버가 받을 수 있습니다. 그 IP에는 어제의 신고가 그대로 남아 있습니다. 그 결과가 그림 맨 아래 줄입니다. 내 서버가 보내는 웹훅이 거래처의 평판 필터에 막힙니다.

이 원인은 두 방향으로 대비합니다.

받는 쪽(내가 평판으로 막는 쪽): 클라우드 대역의 신고는 반감기를 짧게 둡니다. 01편의 클라우드 공개 대역 파일로 "클라우드 IP인가"를 알 수 있으니, 클라우드 IP의 오래된 신고는 덜 셉니다.
보내는 쪽(내 서버가 막히는 쪽): 새로 받은 공인 IP는 쓰기 전에 공개 평판 화면에서 한 번 확인하고, 거래처 연동에 쓰는 출구 IP는 고정해 두고 이의 제기 창구(02편의 6단계)를 미리 알아 둡니다. 이메일 발송 IP는 같은 이유로 더 조심합니다(10편).

정리하면: "나쁜 IP"는 시간과 장소의 사건이다

원인	무엇이 틀리나	줄이는 법
CGNAT·NAT	한 명의 잘못이 모두의 점수	IP 단독 차단 금지, 계정·기기 신호와 묶기, 차단 대신 추가 인증
IPv6	주소 단위 평판이 늘 빈칸	/64로 묶어 세기, 너무 넓게 묶지 않기
주거 프록시	정상 가정 회선처럼 보임	주거 프록시 표시 칸 활용, 행동 신호와 합치기
클라우드 IP 재사용	어제의 신고가 오늘의 고객에게	클라우드 대역은 짧은 반감기, 내 출구 IP 관리
감쇠 없음	오래된 근거가 영원히	항목마다 나이, TTL 있는 차단
몰아 신고	한 사람의 의견이 여럿처럼	신고자별 중복 제거, 신고자 신뢰도
대역 번짐	무관한 이웃이 점수를 받음	회선 성격에 따라 번짐 허용 여부 결정

오탐과 한계

이 편의 모형은 장난감입니다. 계수(가중치 0.2·1.0·1.5, 곡선의 3, 번짐의 α=0.5)는 설명을 위해 고른 값입니다. 실제 서비스의 공식이나 계수를 추정한 것이 아닙니다.
CGNAT 계산도 가정입니다. 실패 확률 10%, 공격 속도 300회/시간은 고른 값입니다. 내 서비스의 기준선은 내 로그로 정합니다(14편 섀도 모드).
"IP + 기기 구분"은 이상적인 경우입니다. 실제 기기 구분은 쿠키 삭제, 앱 재설치, 지문 위조로 흔들립니다.
오탐을 0으로 만드는 설정은 없습니다. 감쇠를 짧게 하면 오탐은 줄지만 같은 IP로 돌아온 공격자를 늦게 봅니다. 반감기는 "얼마나 틀려도 괜찮은가"를 정하는 선택입니다.

실무 체크

평판 기반 차단에는 반드시 만료(TTL)를 둡니다. 클라우드 대역은 더 짧게 둡니다.
IP 단위 규칙을 만들 때 "이 IP 뒤에 사람이 여럿일 수 있나"(통신사 모바일·CGNAT 대역인가)를 먼저 봅니다. 그런 대역에서는 차단 대신 추가 인증이나 속도 제한을 씁니다.
IPv6 트래픽은 /64로 묶어서 세고, 내 로그에서 한 계정이 쓰는 /64 개수를 재 둡니다.

정리

같은 신고 기록도 반감기에 따라 0점에서 100점 가까이까지 갈립니다. 감쇠 없는 목록은 시간이 갈수록 오탐 목록이 됩니다.
신고자별 중복 제거와 신고자 가중치가 감쇠만큼 점수를 바꿉니다(모형에서 6.4점 ↔ 92.7점).
대역 번짐은 호스팅 대역에서는 쓸모 있고, 가정용·클라우드 공용·CDN 대역에서는 오탐을 퍼뜨립니다.
오탐의 네 원인은 CGNAT, IPv6, 주거 프록시, 클라우드 IP 재사용입니다. 모두 "IP = 사람"이 아니어서 생깁니다.
CGNAT 뒤 101명 중 공격자 1명을 IP로 막으면 정상 100명이 함께 막힙니다. IP는 버리지 말고 다른 신호와 묶어 씁니다.

출처와 확인 날짜

모든 링크는 2026-10-31에 확인했습니다.

AbuseIPDB API 문서(abuseConfidenceScore 설명, maxAgeInDays 1~365·기본 30): https://docs.abuseipdb.com/
VirusTotal IP 주소 객체(reputation은 투표자 평판으로 가중한 커뮤니티 점수): https://docs.virustotal.com/reference/ip-object
RFC 6598 IANA-Reserved IPv4 Prefix for Shared Address Space(100.64.0.0/10, BCP 153, 2012-04): https://www.rfc-editor.org/rfc/rfc6598.html
RFC 6269 Issues with IP Address Sharing(13.1절 등, 주소 공유 시 차단의 부작용): https://www.rfc-editor.org/rfc/rfc6269.html
RFC 4291 IP Version 6 Addressing Architecture(2.5.1절, 인터페이스 ID 64비트): https://www.rfc-editor.org/rfc/rfc4291.html
RFC 6177 IPv6 Address Assignment to End Sites(BCP 157, 2011-03, 최소 /64·가정 /56 예): https://www.rfc-editor.org/rfc/rfc6177.html
MaxMind GeoIP Anonymous IP 데이터베이스(is_residential_proxy 등): https://dev.maxmind.com/geoip/docs/databases/anonymous-ip
앞 시리즈, 방어선 2-② IP 평판·위협 인텔리전스의 쓸모와 한계: https://velog.io/@bumicklee/realtime-detect-08-ip-reputation
실행 결과: lab/results/03-toy-score.txt, 03-cgnat-cost.txt, lab/score-model/decay_timeline.csv