# ipinfo를 집에서 사용하기: 지연 시간을 이용해 CLI에서 IP의 위치를 찾는 방법

> Clean Markdown view of GeekNews topic #26313. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=26313](https://news.hada.io/topic?id=26313)
- GeekNews Markdown: [https://news.hada.io/topic/26313.md](https://news.hada.io/topic/26313.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-02-02T02:32:56+09:00
- Updated: 2026-02-02T02:32:56+09:00
- Original source: [blog.globalping.io](https://blog.globalping.io/we-have-ipinfo-at-home-or-how-to-geolocate-ips-in-your-cli-using-latency/)
- Points: 2
- Comments: 1

## Topic Body

- **지연 시간(latency)** 을 활용해 IP 주소를 **국가·주·도시 단위로 추정**할 수 있는 **CLI 도구**  
- **Globalping 네트워크의 3000개 이상 프로브**를 이용해, 각 IP에 대해 **ping과 traceroute 측정**을 수행하고  
- **대륙 → 국가 → 주 → 도시** 단계별로 지연 시간을 비교해 가장 낮은 값을 가진 지역을 실제 위치로 판단함  
- 테스트 결과, **폴란드·플로리다·마이애미** 등에서 ipinfo의 결과와 일치하는 정확도를 보임  
- **오픈소스 CLI 도구**로 누구나 실행 가능하며, **지연 기반 IP 위치 검증 방식의 실용성**을 입증했음  
  
---  
  
### 지연 시간 기반 IP 위치 추정 개요  
- IP 주소를 **국가, 미국 주, 도시 수준**으로 해석할 수 있는 **CLI 도구**를 제작함  
  - GitHub 저장소: [jimaek/geolocation-tool](https://github.com/jimaek/geolocation-tool)  
- ipinfo가 VPN 제공업체들이 **허위 위치 데이터를 등록**한다는 사실을 입증한 사례를 참고함  
  - ipinfo는 **대규모 프로브 네트워크**를 구축해 **모든 IP를 추적 및 ping 테스트**하여 실제 물리적 위치를 검증함  
- 이 접근법은 **공개 데이터의 오류를 배제**하고, **지연 시간과 홉(hop) 데이터**를 기반으로 신뢰도 높은 위치 판별을 가능하게 함  
  
### Globalping 네트워크 활용  
- **Globalping**은 오픈소스 커뮤니티 기반 프로젝트로, **컨테이너형 프로브를 자가 호스팅**할 수 있음  
  - 현재 **3000개 이상의 프로브**가 전 세계에 분포  
  - 사용자는 이 네트워크를 통해 **ping, traceroute 등 네트워크 테스트**를 수행 가능  
- CLI 도구는 **globalping-ts 라이브러리**를 이용해 자동화  
  - 입력된 IP를 여러 대륙에서 ping 테스트  
  - 가장 낮은 지연 시간을 보이는 대륙을 선택  
  - 이후 해당 대륙 내 여러 프로브로 세부 측정 수행  
  
### 측정 단계별 구조  
- **1단계(대륙 탐지)** : 각 대륙별 5개 프로브로 ping 테스트  
  - 예시 결과: 유럽 32.39ms, 북미 137.18ms → 유럽 선택  
- **2단계(국가 탐지)** : 선택된 대륙 내 50개 프로브로 측정  
  - 결과: 폴란드 7.29ms, 독일 13.42ms, 리투아니아 17.65ms → 폴란드로 판정  
- **3단계(미국 주 탐지)** : 미국 내 50개 프로브로 테스트  
  - NordVPN의 ‘바하마’ IP가 실제로 **플로리다(0.45ms)** 로 판정됨  
- **4단계(도시 탐지)** : 주 내 36개 프로브로 측정  
  - 결과: **마이애미(0.00ms)** , West Palm Beach, Tampa 순  
  
### 정확도와 한계  
- **Globalping의 ‘magic field’** 는 대륙 단위로 프로브를 무작위 선택하므로, 특정 국가가 누락될 수 있음  
  - 이로 인해 **인접국 오판**이 발생할 가능성 존재  
- 정확도를 높이려면 **국가·주별로 프로브를 직접 지정**하고, **프로브 수를 조절**해야 함  
  - 예: 북미의 경우 미국 200개, 캐나다 20개, 멕시코 10개 프로브 권장  
- 현재 버전은 **비인증 사용자도 실행 가능**하도록 최소 프로브 수를 사용  
  - 인증 시 시간당 500회 테스트 가능, 추가 크레딧은 **프로브 호스팅 또는 GitHub 후원**으로 확보 가능  
  
### 오픈소스 도구 실행 및 활용  
- 명령어: `geolocate $IP`  
  - `–limit` 옵션으로 단계별 프로브 수 조정 가능  
- **GitHub 문서**에서 전체 사용법 확인 가능  
- **Pull Request**를 통한 개선 제안 환영  
- **무료 크레딧 요청** 및 **프로브 호스팅 참여** 가능  
  - 프로브 호스팅: [jsdelivr/globalping-probe](https://github.com/jsdelivr/globalping-probe)  
  
### 결론  
- **지연 시간 기반 IP 위치 추정**은 충분한 관측 지점을 확보할 경우 **정확하고 실용적인 방법**  
- **Globalping 네트워크와 오픈소스 CLI 도구**를 통해 누구나 손쉽게 IP의 실제 위치를 검증 가능  
- **VPN 위치 위조 검증, 네트워크 라우팅 분석, 성능 디버깅** 등 다양한 활용 가능성 확인

## Comments



### Comment 50408

- Author: neo
- Created: 2026-02-02T02:32:57+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46834953) 
- Globalping 같은 서비스를 이용해 **지리적 위치 추정**이 가능한지 실험해본 작은 프로젝트임  
  단순한 데모 수준이라 실제 운영용으로는 부족함  
  제대로 쓰려면 각 단계마다 최소 500개의 probe가 필요함  
  익명 사용자 제한을 넘지 않으려다 보니 최적화는 일부러 피했음
  - probe 수를 줄이면서도 효율을 높이는 **gradient descent 방식**을 써볼 수 있을 것 같음  
    처음엔 여러 대륙에서 3회씩 측정하고, 가장 느린 probe를 버리고 빠른 쪽 근처에 새 probe를 추가하는 식으로 반복함  
    이렇게 하면 5단계로 나누는 대신 실시간으로 실제 위치를 ‘추적’할 수 있을 것 같음  
    latency를 **스칼라 잠재장**으로 보고 그 기울기를 이용하는 개념임
  - 이론적으로는 3개의 probe면 충분하지 않음?
- AI 없이 만든 점이 인상적임  
  커밋 메시지가 한 단어짜리라 웃겼지만 오히려 인간미가 느껴짐
  - 코드에 “══════” 구분선이 있어서 일부는 **Claude**가 생성한 것 같다는 생각이 듦
- 측정 대상 서버가 소스 IP에 따라 **인위적인 지연시간**을 추가해서 위치를 속이는 게 가능한지 궁금함
  - 충분히 가능함  
    예를 들어 [fakeroute](https://github.com/blechschmidt/fakeroute) 같은 도구로 더 정교한 속임수도 가능함  
    실용성은 거의 없겠지만 재미있는 아이디어임
  - 불가능하진 않지만, 그냥 ping 응답을 안 하는 게 훨씬 간단함
  - traceroute 자체가 해석하기 어려운 도구라 **위조가 매우 쉬움**  
    예전에 The Pirate Bay가 북한으로 이전한 척했던 사례처럼, AS가 BGP 경로에 가짜 AS를 추가해 더 그럴듯하게 만들 수도 있음  
    이런 기술이 VPN과의 **숨바꼭질 게임**으로 이어질 수도 있을 것 같음  
    관련 참고: [Reddit 토론](https://old.reddit.com/r/networking/comments/1hkm4g/lets_talk_about_traceroute/cavh7ub/?context=3#cavh7ub), [HN 사례](https://news.ycombinator.com/item?id=5319419)
  - 미국의 일부 지역 ISP(Xfinity, Charter 등)는 **Bufferbloat** 때문에 이미 인위적 지연이 생김  
    1000/30Mbps 회선에서도 2500ms까지 지연이 발생함
- DEFCON 31에서 발표한 ‘You Can’t Cheat Time’ 연구와 유사한 접근을 봤음  
  [발표 영상](https://youtu.be/_iAffzWxexA)  
  ping 기반 위치 추정의 한계는 다음과 같음:  
  IP는 이미 DB에 위치 정보가 있고, **라우팅 비대칭성**이 거리 모델을 깨며, Anycast/CDN으로 하나의 IP가 여러 지역에 존재함, ICMP는 차단되거나 우선순위가 낮음  
  나는 ping 대신 **HTTP(S) 지연시간 + ML(SVR)** 모델을 써서 3.9만 개 데이터로 학습함  
  CloudFront 뒤쪽 서버 기준 약 600km 오차였음  
  정밀도보다 중요한 건 **샌드박스 탐지**, **지오펜스 악성코드**, **IP DB 실패 시 보조 위치 신호 제공**임
  - 만약 추적을 피하고 싶다면 모든 패킷에 **무작위 지연**을 추가하거나, ping 소스별로 의도적인 지연 규칙을 만들어 원하는 위치처럼 보이게 할 수 있음
- 지연시간 변동이 큰데도 이런 방식이 작동한다는 게 놀라움  
  예전에 네덜란드 친구와 이야기하다가, 내가 영국에서 NL 콘텐츠에 더 낮은 지연으로 접근한 적이 있었음  
  아마 **피어링 품질** 차이 때문일 것임
  - IPinfo에서 일하고 있음  
    IXPs 및 주요 인터넷 기관과 협력해 **라우팅·피어링 데이터 공유 프로젝트**를 진행 중임  
    어떤 국가는 다른 대륙의 IXP와 직접 피어링해 지연이 수천 km 차이 나는 경우도 있음  
    실제로 한 국가의 두 통신사 간 트래픽이 국외를 거쳐 돌아오는 사례도 있음  
    이런 현상을 **측정 기반 지리정보 알고리즘**으로 보정하고 있음  
    궁극적으로 IXPs, 통신사, 인터넷 거버넌스 기관이 이런 문제를 해결하도록 돕는 게 목표임
  - 단순히 **지역 회선 지연** 때문일 수도 있음  
    VDSL이나 DOCSIS에서는 1km 구간에서만 5~15ms 지연이 생김  
    런던–암스테르담 간은 약 7ms 정도임
  - 아마 가까운 PoP에서 캐시된 콘텐츠를 받아서일 수도 있음  
    예전엔 네덜란드 주요 도심에도 광케이블이 부족했음
  - 내 도시에서 프랑스 서버까지 직선거리 250km인데, ping으로 계산하면 2000km로 나옴  
    즉, 실제보다 **8배 이상 부풀려진 거리**임  
    영국 서버가 더 멀지만 오히려 ping이 더 낮게 나옴  
    traceroute 기반 접근이 ping보다 현실적임
- Dimitry에게 감사함. IPinfo 팀 전체가 언급에 고마워함  
  연구원 Calvin이 NANOG96에서 **측정 기반 IP 지리정보**에 대한 발표를 진행할 예정임  
  [발표 링크](https://nanog.org/events/nanog-96/content/5678/)
- 정말 멋진 아이디어와 실행력임  
  이런 프로젝트가 HN에 더 많았으면 좋겠음
- 글을 보니 단순히 **가장 짧은 ping**을 위치로 선택하는 방식인 것 같음  
  이건 너무 단순한 접근이라 **삼각측량(triangulation)** 을 쓰면 더 정확할 듯함  
  - 글에서도 언급했듯이, 목표는 단순한 **proof of concept**이었음  
    충분한 probe와 약간의 운만 있으면 의외로 잘 작동함  
    물론 더 똑똑한 방법이 많음
  - 하지만 **패킷은 직선으로 이동하지 않음**, 그래서 단순 거리 계산은 의미가 없음
- 실제 서비스 환경에서 이런 기술을 써본 경험을 공유함  
  1. 인터넷 라우팅에서는 **삼변측량(trilateration)** 이 거의 통하지 않음  
     그래서 가장 가까운 단일 측정값을 쓰는 게 현실적임  
     유용한 데이터를 얻으려면 도시 단위로 수천 개 노드가 필요함  
  2. 이런 측정은 기존 위치 데이터를 **검증**하는 용도로 더 적합함  
  3. traceroute hop은 라우터 위치를 찾는 데 유용함  
     RIPE IPmap이 이미 대부분의 공개 라우터를 정확히 매핑함  
  4. 인프라나 서버 IP에는 잘 작동하지만, 일반 사용자 네트워크에는 한계가 있음  
     비교 도구로 [ping.sx](https://ping.sx)도 추천함
  - DEFCON 발표 영상도 참고할 만함: [https://youtu.be/_iAffzWxexA](https://youtu.be/_iAffzWxexA)
- **역방향 경로의 IP route**를 보면 주(state) 단위까지는 꽤 정확하게 맞는 경우가 많음  
  마지막 hop의 FQDN에 **공항 코드나 도시 코드**가 포함되어 있는 경우가 많아 도움이 됨
