# 책임감 있게 다운로드하기

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

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=23236](https://news.hada.io/topic?id=23236)
- GeekNews Markdown: [https://news.hada.io/topic/23236.md](https://news.hada.io/topic/23236.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-09-23T10:05:36+09:00
- Updated: 2025-09-23T10:05:36+09:00
- Original source: [blog.geofabrik.de](https://blog.geofabrik.de/index.php/2025/09/10/download-responsibly/)
- Points: 1
- Comments: 1

## Topic Body

- 이번 달 다운로드 서버의 **인프라 업그레이드**로 인해 더 빠른 다운로드 경험 제공
- **“…latest” 파일 요청 방식**이 HTTP 리디렉션으로 변경됨
- 모든 사용자가 편리하게 **최신 OSM 데이터**에 접근할 수 있도록 노력함
- 반복해서 대용량 파일을 과도하게 다운로드하는 **비정상적인 사용 사례**가 전체 서비스 성능 저하로 이어짐
- 효율적이고 책임감 있는 다운로드를 위해 **세 가지 구체적 권고사항** 제시

---

### 다운로드 서버 업데이트 및 책임감 있는 이용 권장

이번 달에는 다운로드 서버의 **인프라 강화 작업**을 진행하였음.  
이로 인해 다운로드가 **더 빨리, 더 일찍** 제공되는 환경 구축이 가능해짐.  
기술적 변경 사항으로 “…latest” 파일 요청 시 기존의 직접 전달 방식 대신 **HTTP 리디렉트** 방식으로 최신 버전 파일에 안내해줌  

### 책임감 있는 다운로드의 필요성

모든 사용자가 편하게 **최신 OSM(OpenStreetMap) 데이터**에 접근할 수 있도록 서버를 운영하고 있음.  
그러나 일부 사용자가 **동일한 대용량 파일(예: 20GB)을 하루 수백~수천 번 반복 다운로드** 하는 경우가 발생함  
- 예시로, 한 사용자가 24시간 내에 italy-latest.osm.pbf 파일을 거의 **10,000번 다운로드**한 사례가 있었음  
- 또 다른 이들은 서버 내 모든 파일을 **매일 전부 다운로드**하는 행위 반복

이러한 행동은 서버 **대역폭 한계**로 인해 전체 이용자들이 느려지는 문제 유발  
IP 대역 차단이 불가피할 경우, **무관한 이용자들까지 피해**를 입을 수 있음

### 서버 이용자에게 당부하는 세 가지 구체적 권고사항

1. 전 세계 데이터가 필요하다면, 서버에서 나누어 받아가지 말고 **planet.openstreetmap.org**에서 planet 파일을 한 번에 받는 방법 권장함
2. 대륙 또는 넓은 지역 데이터(예: Europe, North America)를 매일 갱신하고 싶을 땐 **pyosmium-up-to-date 프로그램**을 사용하여 변동분만 내려받으면 전체 트래픽의 98%를 절감하고 속도도 빨라짐
3. 자동화 스크립트를 활용할 경우에는 무엇이 다운로드되고 있는지 **모니터링**하거나, 적절한 오류 처리를 넣어 **같은 파일 무한 반복 다운로드** 같은 실수 방지 필요

### 결론

보다 **책임감 있는 다운로드 습관**을 통해 모두가 쾌적하게 최신 데이터를 이용할 수 있는 환경 조성에 동참 요청

## Comments



### Comment 44186

- Author: neo
- Created: 2025-09-23T10:05:36+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=45329414) 
* 비슷한 문제를 볼 때마다 왜 BitTorrent를 더 많이 사용하지 않는지 궁금함, 더 다양한 곳의 기본 프로토콜로 쓰이면 좋겠다고 생각함, 예를 들어 컨테이너 레지스트리나 패키지 저장소 등에서 말임
   * BitTorrent는 대중적으로 안 좋은 이미지를 가짐, 대부분 단순히 불법 다운로드와 연관시킴<br>방화벽 설정이 HTTP보다 까다로움, 네트워크 관리자에게 이런 설정을 요구하면 이상하게 볼 수 있음, 특히 BitTorrent 자체에 대한 거부감 때문임<br>BitTorrent 클라이언트는 HTTP 클라이언트보다 훨씬 복잡하고 대부분 회사 컴퓨터나 CI 파이프라인에 설치되어 있지 않음, 많은 이들이 단순히 curl 명령 한번으로 끝내길 원함<br>시드를 해야 한다는 오해가 매우 많고, 그 때문에 두려움을 느낌<br>결국 이미지와 curl만으로 모든 게 되기 때문에 BitTorrent가 저평가되고 있음이 아쉬움<br>비디오 게임 클라이언트가 업데이트에 BT를 활용하거나 PeerTube가 webtorrent를 사용하는 사례도 있지만, 여전히 많이 쓰이지는 않아 아쉬움
   * Amazon, Esri, Grab, Hyundai, Meta, Microsoft, Precisely, Tripadvisor, TomTom 등 수십 개 기업이 OpenStreetMap 데이터를 Parquet 포맷으로 S3에 무료로 제공함, 이는 수TB 데이터셋에서 MB 단위의 대역폭만 쓰며 원하는 정보만 쿼리하고 분석할 수 있도록 해 줌<br>[자세한 내용](https://tech.marksblogg.com/overture-dec-2024-update.html) 참고<br>ArcGIS Pro 사용자는 [이 플러그인](https://tech.marksblogg.com/overture-maps-esri-arcgis-pro.html)도 활용 가능함
   * 몇 년 전에 "동적 콘텐츠를 가진 토렌트"라는 개념을 본 기억이 있음, 실제로는 잘 쓰이지 않게 됨<br>이게 현실화 되길 바랐는데 보안 문제 같은 치명적인 이슈가 있었던 건지 궁금함<br>[참고 링크](https://www.bittorrent.org/beps/bep_0046.html)
   * HTTP에 비해 BitTorrent는 자체적으로 모든 곳에서 쓸 수 있는 "범용 클라이언트"가 부족했다고 생각함, SSH나 SCP처럼 친숙한 것도 아니고, 설치·설정·트래커 구성까지 손이 많이 감<br>일반적으로 대용량 파일의 잦은 다운로드 수요가 있어야 이런 구조가 의미 있음, 신뢰성과 시딩 볼륨 문제까지 고려하면 결국 도구 개발·유지비용 대비 이득이 얼마나 있는지에 귀결됨<br>Git LFS 같은 게 도움이 될까 싶은데 여기까지가 내가 아는 범위임
   * 전에 다니던 회사에서 매주 모든 개발자에게 대용량 파일을 배포해야 했음, 초반엔 rsync로 동시에 떼쓰듯 받았는데, BitTorrent로 바꾼 이후 속도 향상이 엄청 컸음
* Geofabrik같은 회사가 있어서 우리가 가끔 멋진 경험을 할 수 있음에 늘 감사함<br>API를 직접 운영하다보면 개발자들의 경솔함이나 무지에 정말 놀랄 때가 많음, 그 정도로 이상한 요청들이 잦음<br>이전에 경험하지 않고서는 누군가 이런 얘길 들려줬다면 과장이라 생각했을 것임<br>그런데 또 반대로, API 개발자들도 여러 건을 염두에 두지 않는 경우가 많음, 대부분 단일 엔티티 조작만 제공해서, 실제 유즈 케이스 상 다중 작업이 필요한 상황임에도 700번 요청을 날릴 수밖에 없음
   * 개발 숙련도 낮은 사람에게는 어느 직업이든 무책임, 무지가 있을 수 있음<br>모든 개발자가 API를 마구 두들기는 건 아님을 확신함<br>프로그래밍이 모두에게 개방되었고 최근에는 "vibe-coding" 경향도 있어 큰 틀에서 보면 어쩔 수 없음을 느낌<br>응답에 429(Too Many Requests)를 반환하거나 leaky-bucket 알고리즘을 적용해두면 주니어나 입문 개발자들도 금방 스스로 문제를 인식할 것임
   * S3의 "다운로더 과금(downloader pays)" 기능이 왜 더 널리 도입되지 않는지 이해하기 어려움, AWS 외부에서도 이런 모델이 있으면 비효율적 사용자가 자기 비용만큼만 부담하게 할 수 있을 것임<br>단점은 결제 시스템이 없는 사람은 접근이 어려워질 수도 있는데, 이때는 무료지만 제한적 속도 옵션도 남길 수 있지 않을까 생각함
   * 20GB 파일을 하루에 수천 번씩 받는 사용자가 있다는데, 왜 단순히 Rate Limit으로 제어하지 않는지 궁금함
   * 양쪽 모두 공감 능력이 더 필요하다고 생각함: 클라이언트는 인프라를 존중해야 하고, API 개발자는 사용자 관점에서 더 넓게 생각해야 함
* "한 사용자가 24시간 내에 italy-latest.osm.pbf 파일을 거의 만 번 다운로드했다"는 사례는 코드가 문제일 확률이 높음, IP당 제한을 두면 되는 일임, VPN 사용자라도 마찬가지임
* 아마 사람들이 CI 파이프라인에서 map 데이터 파일을 다운로드하고 있는 듯함, 종종 본인도 인식하지 못하는 본의 아닌 다운로드임<br>그래서 많은 서비스가 비회원의 자동 다운로드를 금지하게 되었음<br>cURL로 파일을 받으려면 먼저 회원가입을 유도하고, 과도하게 다운로드하는 사용자는 차단하거나 요금을 부과하는 것이 좋다고 생각함
   * CI라는 개념이 컴퓨팅 리소스를 낭비하는 최악의 발명품 중 하나라고 생각함, 다만 지도 데이터는 코드 라이브러리처럼 남용되는 식의 대량 다운로드가 왜 발생하는지는 잘 모르겠음
   * GPKG 파일을 웹앱이 "쿼리"하는 방식이 아닐까 의심됨, Parquet 포맷은 원하는 부분만 효율적으로 쿼리할 수 있지만 GPKG에서 똑같이 가능한지는 잘 모르겠음
   * CI 서버에서의 요청을 신뢰성 있게 판별할 수 있는지 궁금함
   * 간단한 인증(예: API 키나 이메일 기반) 정도만 있어도 좋은 절충점일 것 같음
* "동일한 20GB 파일을 수일간 하루에 수백 번 다운로드하는 유저가 있음(24시간 내 만 번 다운로드한 유저도 있음), 서버에 있는 모든 파일을 매일 다운로드하는 사람도 있다"는 사례는 rate-limiting만으로 쉽게 막을 수 있을 듯함<br>24시간 동안 파일 다운로드 횟수를 이미 세고 있으면서 제한을 두지 않는 이유가 뭔지 궁금함<br>이들이 (a) 서버 운영자의 경고글을 읽고 (b) 행동을 바꿀 거라 기대하진 않음
* 몇 년 전엔 "설마 누가 빌드 스크립트에서 매번 100MB 넘는 걸 다운받겠어?" 생각했었지만, Docker를 경험하고 나서는 그런 케이스가 매우 많음을 깨달았음
   * 컨테이너 안에 들어가면 마법이라도 된 듯이 공짜라 착각하는 사례를 종종 봄
   * Docker는 레이어 캐시를 지원하니 모든 걸 매번 다 새로 받을 필요는 없는 것 아님?
   * 그래서 나는 프로젝트 전용 이미지를 미리 CI에서 만들어놓고 CI에서만 사용함, 매번 apt-get으로 세팅하려면 시간 소모가 너무 큼
* 과도한 다운로드 유저에게는 따로 메일을 보내는지 궁금함, 2012년에 무료 Nominatim API를 사용할 때는 이메일이 필수였고, 캐싱 등으로 요청량을 줄이라는 안내 메일을 실제로 받은 적 있음
   * 로그인이 없는 상황이라면 이메일 주소를 받지 못하니 메일을 보낼 수 없음
* 나는 italy-latest 파일을 8초마다 다운받는 그 유저는 아니지만, 내가 속한 이탈리아 스타트업이 GeoFabrik을 많이 활용하고 있음, 팀원 중 누군가가 컨테이너 실험을 하다 너무 많이 다운받았을 수 있음<br>예전에 geofabrik에서 차단(밴)을 당했는데, 아직도 원인이 뭔지 몰라서 앞으로 이런 일이 반복되지 않길 바람<br>geofabrik.de 연락처로 전화·이메일도 시도해봤지만 답이 없었음, 혹시 이 문제 해결 방법이나 연락 방법을 아는 분이 있으면 알려줬으면 함
* 이런 식으로 과도하게 파일을 내려받는 사람들은 정작 이런 블로그 글은 읽지 않을 거란 생각이 듦
* bittorrent를 쓰면 좋을 유스케이스라는 생각임
   * 데이터가 변경될 경우 토렌트 클라이언트가 어떻게 자동으로 변경점만 받아올 수 있을지가 궁금함