IPinfo의 MMDB는 어떻게 데이터 그대로 31% 작아졌나

조회 결과를 유지하고 파일 구조를 줄였다

IPinfo의 MMDB 파일이 작아진 이유는 국가·도시·ASN 같은 데이터를 덜 담았기 때문이 아니다. 회사가 공개한 기술 설명에 따르면, 여러 번 저장하던 동일한 검색 구조를 한 번만 저장하도록 바꿨다. 파일을 열기 전에 압축을 푸는 단계도 추가하지 않았다.

이 차이는 서버에 IP 데이터베이스를 배포하는 개발자에게 중요하다. 저장 공간과 전송할 바이트를 줄이면서 기존 파일을 읽던 라이브러리를 계속 쓸 수 있기 때문이다. 최적화는 조회 결과를 보존하는 작업이므로 IP 위치 정보 자체의 정확도를 높이는 기능과는 구분된다.

두 갈래가 같으면 같은 노드를 가리키게 한다

MMDB 규격은 파일을 검색 트리, 데이터 영역, 메타데이터로 나눈다. 검색기는 IP 주소의 비트를 따라 왼쪽 또는 오른쪽 가지를 선택하고, 마지막에 해당 주소의 데이터로 이동한다. 각 노드는 두 개의 참조값을 갖는다.

서로 다른 주소 범위라도 아래쪽에서 같은 구조와 데이터로 이어진다면 그 부분을 각각 저장할 필요가 없다. IPinfo의 도구는 자식 노드부터 처리하고, 왼쪽·오른쪽 참조 쌍이 정확히 같은 노드를 공유한다. 이렇게 여러 부모가 같은 하위 구조를 가리키게 하는 방식이 hash-consing이다.

단순히 두 IP의 국가명이 같다는 이유로 합치는 것은 아니다. 아래쪽의 분기 구조와 참조 대상까지 같아야 한다. 표준이 이미 허용하는 노드 참조를 이용하므로 별도의 새 파일 형식이나 전용 리더가 필요하지 않다.

31%는 전체 합계, 80%는 특정 데이터베이스의 결과다

파일마다 줄어드는 폭은 중복 구조의 양에 달려 있다. mmdbshrink README가 2026년 9월 28일 측정한 IPinfo 데이터베이스 결과는 다음과 같다.

31%는 회사가 발표한 89개 데이터베이스 전체 용량의 감소율이다. 특정 파일의 최대 감소율을 모든 MMDB에 적용할 수는 없다. 이미 중복이 제거된 파일은 같은 도구를 다시 실행해도 더 작아지지 않는다.

IPinfo 고객은 그대로 받고, 직접 만든 DB는 별도 파일로 검증한다

IPinfo는 현재 내려받는 MMDB에 최적화가 이미 적용돼 있다고 설명한다. 기존 고객이 같은 작업을 다시 수행할 필요는 없다. 직접 MMDB를 만드는 경우에는 mmdbshrink로 원본을 남긴 채 결과 파일을 만들 수 있다. 도구를 설치한 환경에서 다음 명령을 사용한다.

mmdbshrink custom.mmdb

기본 출력은 custom.shrunk.mmdb다. 쓰기가 끝나면 메타데이터와 특정 주소 경계를 대조하고, IPv4와 IPv6에서 각각 100만 개의 무작위 주소를 검사한다. 기본 검증과 모든 접두사를 순회하는 전수 대조는 구분된다.

최적화를 실행할 장비의 메모리도 먼저 계산해야 한다. README는 처리 중 최대 사용량을 입력 파일 크기의 약 6~12배로 설명한다. 작은 파일을 만들기 위한 처리 과정이므로, 결과를 읽을 때의 메모리 사용량과 같은 수치가 아니다.

자동 배포에 연결한다면 두 명령의 종료 코드 차이가 중요하다. 독립 실행 파일인 mmdbshrink는 검증 실패 시 0이 아닌 코드로 끝난다. mmdbctl shrink는 오류를 출력해도 종료 코드는 0이므로, 셸의 성공 여부만으로 배포를 진행해서는 안 된다.

직접 만든 DB는 원본을 유지하고 검증 결과와 애플리케이션에서 필요한 조회값을 대조한 뒤 교체하는 순서가 적절하다. 다운로드 크기를 줄이는 이점과 조회 결과를 그대로 유지한다는 조건을 함께 충족해야 운영에 쓸 수 있다.