Domain Normalization — 도메인 정규화 규칙
왜 정규화가 먼저인가
공개 커뮤니티에 올라오는 제보는 대부분 자유 텍스트다. 같은 사이트를 두고 누구는 HTTP://Example-Site.com/, 누구는 www.example-site.com, 또 누구는 모바일 주소 m.example-site.com?utm_source=kakao를 적는다. 이 표기를 그대로 세면 하나의 대상이 여러 건으로 흩어져 집계가 부풀거나 나뉜다. 그래서 도메인 정규화는 중복제거와 집계의 전제다. 표기가 달라도 같은 대상을 가리키면 동일한 정규화 키(normalized key) 하나로 수렴시켜야, 이후의 도메인 단위 집계가 표기 편차가 아니라 실제 관측에 근거하게 된다. 이 규칙은 저장소의 데이터 방법론과 같은 원칙을 따른다.
항목별 처리 규칙
정규화는 아래 순서로 적용한다. 순서가 바뀌면 결과가 달라질 수 있으므로 파이프라인 순서를 고정한다.
- 프로토콜 제거: 앞머리의
http://,https://를 떼어낸다. 스킴은 같은 대상을 다르게 보이게 할 뿐 식별에 기여하지 않는다. - 호스트 접두 정리:
www.,m.처럼 표시용 서브도메인은 제거해 대표 호스트로 모은다. 다만 서비스가 분리된 실질 서브도메인까지 합치지 않도록 접두 목록은 보수적으로 유지한다. - 대소문자 통일: 호스트는 대소문자를 구분하지 않으므로 전부 소문자로 내린다.
- 경로·쿼리·프래그먼트 절단: 첫
/,?,#이후는 잘라 호스트만 남긴다. 포트(:8080)도 제거한다. - 추적 파라미터 처리:
utm_source,utm_medium,gclid,fbclid등 유입 추적 파라미터는 대상 식별과 무관하므로 쿼리 절단 단계에서 함께 사라진다. - 트레일링 슬래시·잔여 문자: 끝의
/와 문장부호(),],",,등) 찌꺼기를 제거한다. 자유 텍스트에서 도메인 뒤에 붙는 괄호·따옴표를 걸러내기 위함이다. - 등록 가능 도메인 축약:
co.kr,or.kr같은 2단계 공개접미사를 인식해 등록 가능한 최소 단위로 맞춘다(예:a.b.co.kr→b.co.kr). 형식 검증을 통과하지 못하는 문자열은 키를 만들지 않고 버린다.
입력 → 정규화 키 (가상 예시)
| 입력(제보 원문) | 정규화 키 |
|---|---|
HTTP://Example-Site.com/ |
example-site.com |
www.Example-Site.com/event |
example-site.com |
m.example-site.com?utm_source=kakao |
example-site.com |
https://sample-bet.net/#promo |
sample-bet.net |
(sample-bet.net), |
sample-bet.net |
login.demo-play.co.kr:8080/main |
demo-play.co.kr |
위 예시의 도메인은 모두 설명용 가상값이다.
한계
정규화는 표기를 통일할 뿐, 서로 다른 도메인이 같은 운영 주체인지는 판정하지 않는다. 미러·대체 도메인 묶음은 이후 단계에서 별도 신호로 다룬다. 또한 이 데이터는 공개 제보의 표본이며 전수 조사가 아니다. 특정 도메인의 키가 존재한다는 것은 여러 출처에서 해당 표기가 관측됐다는 사실일 뿐, 그 자체로 어떤 업체를 단정하는 근거가 아니다.
본 문서는 데이터 처리 방법론을 설명하는 정보성 자료다. 불법 사설 배팅은 이용 행위 자체가 처벌 대상이 될 수 있으며, 예시 도메인·상호는 모두 가상값이다.