# 공격적인 AI 스크래퍼가 위키 운영을 꽤 힘들게 만들고 있음 > Clean Markdown view of GeekNews topic #29744. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29744](https://news.hada.io/topic?id=29744) - GeekNews Markdown: [https://news.hada.io/topic/29744.md](https://news.hada.io/topic/29744.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-05-22T09:17:48+09:00 - Updated: 2026-05-22T09:17:48+09:00 - Original source: [weirdgloop.org](https://weirdgloop.org/blog/clankers) - Points: 5 - Comments: 2 ## Topic Body - **AI 스크래퍼** 트래픽은 공개 위키의 비용과 안정성을 흔들며, 완화하지 않으면 인간 활동 전체보다 약 10배 많은 컴퓨팅 자원을 쓸 수 있음 - 봇은 GPTBot 같은 식별 가능한 User Agent를 넘어 **최신 Chrome**처럼 헤더를 꾸미고, 하루 100만 개 IP를 돌리는 주거용 프록시로 우회함 - 위키는 문서보다 훨씬 많은 **이전 판본·편집 화면·특수 페이지** URL을 노출해, 순진한 크롤링이 캐시를 우회하고 일반 요청보다 50~100배 비싸질 수 있음 - Cloudflare Challenge, Anubis, 수작업 방화벽, **인간 행동 요청** 기반 탐지는 효과가 있지만 오탐과 유지 부담, 독자 마찰을 함께 만듦 - 로그인 강제나 전체 챌린지 같은 극단적 차단은 신규 기여를 줄일 수 있어, 운영자 간 **공개 논의**와 봇 수집 유인을 바꾸는 API 접근이 필요함 --- ### AI 스크래퍼가 위키 운영에 주는 부담 - LLM 학습 데이터를 위한 봇 스크래핑이 전례 없는 규모로 늘어나며 공개 웹사이트의 비용과 안정성을 흔들고 있음: 관련 문제는 [FOSS infrastructure is under attack by AI companies](https://thelibre.news/foss-infrastructure-is-under-attack-by-ai-companies/), [Are AI bots knocking cultural heritage offline?](https://www.glamelab.org/products/are-ai-bots-knocking-cultural-heritage-offline/), [Smart TV web crawler AI](https://www.theverge.com/column/885244/smart-tv-web-crawler-ai)에서도 다뤄짐 - [Weird Gloop](https://weirdgloop.org)은 [Minecraft Wiki](https://minecraft.wiki), [OSRS Wiki](https://oldschool.runescape.wiki/), [League Wiki](https://wiki.leagueoflegends.com/) 같은 대형 게임 위키를 호스팅하며, 최근 3년 동안 **봇 트래픽 대응**에 점점 더 많은 시간을 쓰는 중 - 지속적으로 완화하지 않으면 봇은 수천만 건의 인간 페이지뷰와 하루 수만 건의 편집을 포함한 나머지 전체보다 약 **10배 많은 컴퓨팅 자원**을 사용할 수 있음 - Wikimedia Foundation도 크롤러가 운영에 미치는 영향을 다룬 [글](https://diff.wikimedia.org/2025/04/01/how-crawlers-impact-the-operations-of-the-wikimedia-projects/)을 냈고, 주요 위키 팜은 다양한 수준의 장애를 겪었으며 일부 소규모 독립 위키는 완전히 오프라인이 됨 - 올해 위키 생태계의 서버 문제 중 약 **95%** 는 나쁜 스크래퍼가 원인인 것으로 추정됨 ### 사람처럼 보이려는 스크래퍼 - GPTBot, ClaudeBot, PerplexityBot 같은 주요 AI 회사의 “공식” 봇은 robots.txt를 지키지 못한 적도 있지만, 보통 User Agent 문자열에서 식별할 수 있어 [Cloudflare의 AI 봇 차단](https://developers.cloudflare.com/bots/additional-configurations/block-ai-bots/)이나 nginx로 막기 쉬움 - 웹마스터가 User Agent 기반으로 AI 스크래퍼를 차단하기 시작하면서, 봇이 **사람 트래픽처럼 위장**할 강한 동기가 생김 - 최근 위키에 도달하는 AI 스크래퍼 트래픽 대부분은 최신 Google Chrome처럼 보이도록 헤더를 보내며 요청을 정교하게 구성함 - 과거에 쓰던 명확한 “봇 또는 실제 사람” 신호가 사라져 차단이 어려워짐 ### 수천만 IP와 프록시 우회 - 2023년 전에는 문제 있는 스크래핑의 95%가 단일 IP 주소나 작은 데이터센터 서브넷에서 발생해 IP 또는 ISP 특성 기반 차단이 대체로 효과적이었음 - [주거용 프록시](https://cloud.google.com/blog/topics/threat-intelligence/disrupting-largest-residential-proxy-network)를 쓰면 신용카드만으로 수백만 IP 주소 네트워크를 통해 스크래핑 요청을 세탁할 수 있음 - 위키는 하루에 **100만 개 IP**를 순환하는 스크래퍼 실행에 맞닥뜨리기도 하며, Comcast, AT&T, Charter 같은 주거용 ISP에서 온 합법적인 요청처럼 보임 - 해당 고객은 자신의 IP가 주거용 프록시의 출구 노드로 쓰이는지 모를 가능성이 큼 - 일부 악성 행위자는 [facebookexternalhit 링크 미리보기](https://datadome.co/threat-research/how-facebook-was-used-as-a-proxy-by-web-scraping-bots/)나 Google Translate를 이용해 요청이 Google/Facebook 서버에서 온 것처럼 만들고, 실제 출처를 가림 - Google Translate URL 도구를 통해 들어오는 요청의 **99.99%** 가 악용성인 경우도 있어, 한때 모든 위키에서 해당 도구를 깨야 했음 ### 위키에 특히 비싼 “멍청한 URL” 크롤링 - 많은 AI 스크래퍼는 위키 홈페이지를 방문한 뒤 그 페이지의 모든 링크를 방문하고, 다시 그 페이지들의 모든 링크를 방문하는 방식으로 URL을 고름 - [robots.txt](https://runescape.wiki/robots.txt)와 사이트맵이 스크래핑할 가치가 있는 URL을 알려주는데도 이를 인식하지 않는 것처럼 보임 - OSRS Wiki에는 약 **4만 개의 문서**가 있으며, 이 URL들이 사이트의 유용한 정보 대부분을 구성함 - 하지만 [이전 판본](https://oldschool.runescape.wiki/w/Scrambled!?diff=prev&oldid=14947138), [편집 화면](https://oldschool.runescape.wiki/w/Mythical_Cape_Store?action=edit§ion=1), [특수 페이지](https://oldschool.runescape.wiki/w/Special:LongPages?limit=50&offset=50)까지 포함하면 탐색 가능한 URL은 최소 **10억 개**에 달함 - 이런 순진한 크롤링은 끝나지 않으며, LLM 학습 데이터로 유용하지 않은 URL에 많은 자원을 쓰는 것으로 보임 - 이상한 요청은 실제 사용자 요청이 타는 [MediaWiki 파서 캐시](https://www.mediawiki.org/wiki/Manual:Parser_cache) 같은 캐시 계층을 우회해 서비스 비용을 키움 - 캐시 적중 요청은 보통 처리 시간이 **20밀리초 미만**이지만, 오래된 diff 같은 요청은 자주 **1~2초**가 걸림 - “하루 800만 봇 요청”, “봇이 대역폭 65% 사용” 같은 상위 지표는 문제를 과소평가함 - 실제 병목은 대개 CPU 용량이며, 이상한 쿼리 파라미터가 붙은 봇 요청은 처리 비용이 일반 요청보다 **50~100배** 비쌀 때가 많음 ### 평균 지표로는 드러나지 않는 트래픽 스파이크 - 월간 봇 요청은 약 **2억 5천만 건**, 초당 평균 약 **100건** 수준이지만 이는 장기 평균일 뿐임 - 스크래퍼는 짧은 시간 동안 초당 **1,000건 이상**의 요청을 보내는 경우가 잦고, 전통적인 DDoS 공격과 거의 구분하기 어려움 - 장기적으로 봇이 전체 CPU 사용량의 약 **50%** 만 차지하더라도, 악성 트래픽 스파이크가 위키의 느려짐과 장애 중 약 **95%** 를 유발함 ### 누가 하는지 알기 어려운 구조 - 트래픽을 “AI 스크래퍼”라고 부르지만, 모두 Google Chrome처럼 위장하기 때문에 실제 책임 주체나 위키 데이터를 무엇에 쓰는지 알기 어려움 - 가능한 주체는 데이터 브로커, frontier lab의 중복 수집, 주거용 프록시에 접근할 수 있는 독립 프로젝트 등으로 열려 있음 - 진입 장벽이 실제로 얼마나 낮아졌는지도 불명확함 - 더 나은 방식이 있다면 실제 수집 주체와 직접 연락해 덜 비효율적인 방법을 찾고 싶어 함 ### 지금까지 효과가 있었던 대응 - ## Cloudflare Challenge와 Anubis - 웹사이트를 Cloudflare challenge나 [Anubis](https://github.com/TecharoHQ/anubis) 같은 도구 뒤에 두는 방식이 최근 1년 사이 인터넷에서 널리 쓰이게 됨 - 어느 정도 효과는 있지만, 일부 봇이 챌린지를 꾸준히 통과하는 시기가 있음 - Cloudflare와 봇 개발자 사이에 보이지 않는 군비 경쟁이 있는 것으로 보이며, Cloudflare가 약 **90%** 는 이기지만 남은 10%가 운영상 힘든 구간을 만듦 - 실제 독자는 위키에 도달하기 전에 챌린지를 보는 것을 싫어함 - 대부분의 사람에게 영향을 주지 않으려면 어떤 트래픽에만 챌린지를 걸지 판단하는 좋은 휴리스틱 규칙이 필요하지만, 자동화 트래픽을 안정적으로 탐지하는 일 자체가 어려움 - ## 수작업 방화벽 규칙 - 대부분의 운영자는 자기 인프라와 과거 공격에 맞춘 **수작업 방화벽 규칙**을 갖고 있음 - 이런 필터는 보통 특정 User Agent 문자열, IP 그룹, ASN에 기반함 - Weird Gloop은 대부분을 Cloudflare/CDN 수준에서 처리하지만, 다른 위키는 nginx나 웹서버 측에서 처리하기도 함 - 현재는 User Agent/IP만으로는 충분하지 않은 경우가 많아, HTTP 버전, 헤더, TLS cipher, [ja4](https://github.com/FoxIO-LLC/ja4) 관련 해시 같은 더 복잡한 요청 속성을 봐야 함 - ## “사람은 하는데 봇은 하지 않는 것” 찾기 - 유용한 관점은 **사람들이 집합적으로 하는 행동** 중 봇이 하지 않는 것을 찾는 방식임 - MediaWiki 기반 위키에는 실제 브라우저 사용자가 위키를 쓸 때 자주 만드는 여러 유형의 HTTP 요청이 있고, 봇은 보통 이를 만들지 않음 - 헤더, ja4 해시 등으로 분리 가능한 트래픽 덩어리가 많은 문서를 방문하면서도 전형적인 “사람” 요청을 만들지 않는다면, 해당 트래픽에 챌린지를 적용할 강한 신호가 됨 - 봇 트래픽에 **없는 인간 행동 요청**을 보는 방식은 강력함 - “빠진” 트래픽을 분석해 어떤 트래픽에 챌린지를 걸지 결정 트리 기반 휴리스틱을 자동 제안하는 시스템을 만들기 시작함 - 테스트에서는 거의 모든 스크래퍼를 잘 찾아내는 것으로 보였지만, NoScript 사용자, 스크린 리더 사용자, 예상 밖 기기 사용자처럼 특이한 탐색 습관을 가진 사람에게 어떤 오탐이 생길지는 명확하지 않음 - 자체 ML/데이터 분석 인프라를 만들고 영구 유지하는 일도 부담으로 남음 - ## 더 이국적인 탐지 기법 - [TCP/TLS 타이밍 불일치](https://www.osti.gov/servlets/purl/2530825)로 주거용 프록시를 식별해 성공한 사례가 있음 - [주거용 프록시 IP의 실시간 데이터베이스](https://spur.us/platform/residential-proxy-detection)를 판매하는 회사도 있음 - 다만 [대부분의 주거용 프록시는 실제 사람도 동시에 사용](https://blog.cloudflare.com/residential-proxy-bot-detection-using-machine-learning/#detecting-residential-proxies-using-network-and-behavioral-signals)하기 때문에 이를 실행 가능한 차단 신호로 얼마나 쓸 수 있는지는 불명확함 - Cloudflare나 대형 클라우드 제공자처럼 막대한 트래픽의 패킷 수준 네트워크 정보를 가진 주체라면 대규모로 좋은 휴리스틱을 만들 수 있을 것처럼 보임 - 하지만 연간 비용이 여섯 자리 수에 달하는 상용 봇 탐지 제품을 포함해, 상용 제품의 휴리스틱에 감명받은 운영자를 만나지 못함 ### 독자에게 나쁜 극단적 선택지 - AI 스크래퍼를 막는 “핵 옵션”은 실제 사용자에게 훨씬 더 파괴적임 - 흔한 방식 중 하나는 생성 비용이 클 수 있는 페이지를 보려면 로그인을 요구하는 것임 - [Fandom은 몇 달 전 모든 위키에 이런 조치](https://community.fandom.com/wiki/User_blog:Fandom/New_Measures_to_Reduce_Bot_Activity)를 적용함 - 다른 방식은 모든 트래픽에 Cloudflare challenge를 제공하는 것임 - 웹마스터 입장에서는 이해할 수 있지만, 위키와 커뮤니티의 장기 건강에는 나쁨 - 16년간 위키 커뮤니티를 만들며 얻은 핵심 교훈은 새 기여자를 끌어들이는 가장 좋은 방법이 **마찰 제거**라는 점임 - 편집을 더 쉽게 만들고, 위키 내부 구조를 더 쉽게 탐색하게 하며, 독자와 편집자를 가르는 진입 장벽을 낮춰야 함 - 극단적 안티봇 기법은 새 마찰을 만들고 예측 가능한 결과를 낳음 - Fandom이 계정 없는 독자 **95% 이상**에게 “내부 페이지”를 숨긴 뒤, Fandom 전체의 신규 사용자 기여가 약 **40% 감소**한 것으로 나타남 - 이런 트레이드오프를 가치 있다고 보기 어려움 ### 앞으로의 방향 - Weird Gloop은 여전히 위키 호스팅을 계속하고 있으며, [Fandom에서 벗어나려는 위키를 돕는 일](https://weirdgloop.org/blog/why-were-helping-more-wikis-move-away-from-fandom)도 계속하고 있음 - 장기적으로는 “AI Overviews”가 위키 독자를 위키 기여자로 전환하는 파이프라인을 죽일 수 있지만, 이는 별도의 문제로 남겨둠 - 일부 지인은 봇의 물결이 Weird Gloop에 유리할 수도 있다고 보지만, 사람들이 쉽게 위키를 호스팅할 수 없다면 인터넷은 더 나빠짐 - 위키를 안정적으로 호스팅하려면 온콜 로테이션, ML 엔지니어, 엔터프라이즈 제품이 필요해지는 시나리오는 독립 위키 커뮤니티에 매우 나쁜 소식임 - 봇 소유자와 웹마스터의 군비 경쟁은 스크래핑의 구조적 유인을 바꾸는 영리한 방법이 나오기 전까지 계속될 가능성이 큼 - [Cloudflare의 새 crawling API](https://developers.cloudflare.com/changelog/post/2026-03-10-br-crawl-endpoint/)는 봇이 robots.txt를 무시하고 문제를 일으키는 자체 시스템을 만드는 것보다 API를 쓰는 편이 더 쉽다면 구도를 바꿀 수 있음 - 스크래핑이 아예 일어나지 않는 것이 더 낫지만, 이미 벌어진 일을 되돌리기는 어려움 ### 공개 논의와 협력의 필요성 - 수천 명의 운영자가 각자 웹사이트를 운영하며 봇에 대응할 더 영리한 기법을 찾고 있음 - 다른 시스템 관리자들과의 비공개 대화에서는 구체적이고 좋은 아이디어가 있었고, Slack, Discord, 작은 그룹 안에서도 많은 논의가 오갈 가능성이 큼 - 실제 운영상의 구체 사항을 두고 더 많은 **공개 논의**가 필요함 - 많은 시스템 관리자는 자신이 겪는 문제가 다른 운영자와 거의 동일하다는 사실을 충분히 알지 못함 - 모두가 자신만의 방어 방법을 공개하고 싶어 하지는 않으며, 공개하면 우위를 잃을 수 있다는 걱정도 있음 - 그래도 사람들이 머리를 맞대도록 돕는다면 전술 일부의 효과가 줄어드는 위험도 감수할 만함 - AI 스크래퍼를 다루는 시스템 관리자는 자신에게 맞는 공간에서 효과가 있었던 방법을 공유하는 편이 좋음 - 봇 문제 해결 제품을 판매하는 회사는 인위적이지 않은 상황에서 [precision and recall](https://en.wikipedia.org/wiki/Precision_and_recall) 비율에 대한 실질적 데이터가 담긴 사례 연구를 더 공개해야 함 - 구매 결정을 하는 사람들은 체크박스를 채우는 것이 아니라 실제 결과를 중요하게 봄 - 위키나 독립 웹사이트를 운영하며 봇 탐지를 논의하고 싶다면 [이메일 또는 Discord 메시지](https://weirdgloop.org/contact/)로 연락할 수 있음 ## Comments ### Comment 58053 - Author: xguru - Created: 2026-05-22T11:14:24+09:00 - Points: 1 기본적으로 긱뉴스도 엄청 많은 크롤러가 오고 있어서, 다양한 방식을 도입해서 차단도 하고, 비용을 최적화 하고 있습니다. 중국쪽 ai 봇들은 정말 엄청 심각하게 크롤링을 하더라고요. 근데 정작 cdn 쪽에서 차단하려면 비용이 발생하는것도 문제긴 합니다. ### Comment 58037 - Author: neo - Created: 2026-05-22T09:17:49+09:00 - Points: 1 ###### [Lobste.rs 의견들](https://lobste.rs/s/k21pdb/aggressive_ai_scrapers_are_making_it) - Anubis의 단점을 보완하려고 **대기 증명(proof-of-wait)** 챌린지를 써봤는데 꽤 효과가 있었음 기본적으로 전역 요청률이 기준치보다 낮으면 필터를 끄고, 기준치를 넘으면 사용자가 계속 진행하기 전 N초 기다리게 함 그 뒤 해당 IP에 묶인 토큰을 발급해 만료 시간 안에서 소량의 요청만 허용하고, 토큰 자체도 속도 제한을 둠 성공 요청이 계속 들어오면 대기 시간이 점점 늘어남 꽤 성공적이었고, 모바일 기기가 과도하게 불리해지지 않도록 **완만하게 성능 저하**되며, JavaScript 없이도 동작함 - marginalia.nu에서 이 방식이 동작하는 걸 봤는데, 휴대폰 배터리를 작업 증명으로 낭비하지 않아서 마음에 듦 - 공개 코드의 일부라면 이걸 구현한 **소스 코드 링크**를 받을 수 있을지 궁금함 - 멋짐. 이런 방식을 TLS의 일부로 만들려는 노력이 있는지 궁금함. 작업 증명 챌린지에 대해 [draft-venhoek-tls-client-puzzles-00](https://www.ietf.org/archive/id/draft-venhoek-tls-client-puzzles-00.html)가 하려는 것과 비슷한 느낌임 이런 건 TLS나 심지어 운영체제의 IP 스택처럼 훨씬 **아래 계층**에 있어야 할 것 같음 대기 증명을 깊게 생각해본 적은 없지만, 합법 사용자에게는 자동 스크래퍼보다 대기가 훨씬 더 나쁘게 작용하지 않나? 사람은 기다림에 짜증을 내지만, 스크래퍼는 토큰을 저장해두고 N초 뒤 돌아오면 됨 작업 증명도 양가감정이 있지만, 적어도 스크래퍼에게는 규모에 비례하는 실질 비용을 부과함 - 설정이 간단한지 궁금함. 내 위키에도 관심 있음 - 유용한 접근으로 보임. 자세한 내용을 정리할 계획이 있는지 궁금함 대기 증명은 [작업 증명에 우려가 있는 사람들](https://www.fsf.org/blogs/sysadmin/our-small-team-vs-millions-of-bots)을 안심시킬 수도 있겠음 - 특정 특수 페이지는 한 번 로그인해서 해당 쿠키가 설정된 클라이언트만 접근하게 하고, 아니면 거부하는 방식도 꽤 잘 동작함 대부분의 크롤러가 위키를 훑기 위해 특수 페이지를 노리므로, 로그인 사용자로 제한할 수 있음 이 설정에서는 위키가 사용자 생성을 허용하지 않음 <If "%{REQUEST_URI} =~ m#^/wiki/index\.php(?:/.*)?$# && %{HTTP_COOKIE} !~ /[-a-zA-Z_]+UserID=/ && ( %{REQUEST_URI} =~ m#^/wiki/index\.php/Special(?::|%3A)(MobileDiff|History|Contributions|CreateAccount|ExportTranslations|MessageGroupStats|LanguageStats|Translate|RecentChanges|Log|RecentChangesLinked|WhatLinksHere)(?:/.*)?$#i || %{QUERY_STRING} =~ /(Special(%3A|:)(MobileDiff|History|Contributions|CreateAccount|ExportTranslations|MessageGroupStats|LanguageStats|Translate|RecentChanges|Log|RecentChangesLinked|WhatLinksHere)|action=(edit|history|info|pagevalues|purge|formedit)|oldid=)/i )"> ErrorDocument 403 "Access denied, please login." Require all denied </If> 이걸로 우리 시스템 부하가 크게 줄었음. 이전에는 특수 페이지를 심하게 크롤링해서 위키가 못 쓸 정도가 되는 피크가 자주 있었음 그 밖에는 알려진 AI 크롤러 사용자 에이전트를 바로 403으로 막고, Alibaba나 Amazon Cloud 같은 특정 IP 대역도 차단함 재미있게도 저쪽이 이를 알아챘음. Diff 보기로 페이지를 훑다가 제한하니 MobileDiff 보기로 같은 시도를 했음 몇 번 오가긴 했지만, 몇 달 전부터는 이 방식으로 순조롭게 돌아감 - 사용자 에이전트 기반 차단은 사실상 할 수 있는 일 중 거의 최악에 가까움 사용자 에이전트로 막으면 크롤러는 사람처럼 보이는 사용자 에이전트로 다시 시도하며 사이트를 탐색함 차단 트리거가 사용자 에이전트라고 판단하면 **지옥 모드**로 들어가 식별이 훨씬 어려워지고 사이트를 죽을 때까지 두들김 IP 대역 차단도 도움이 되지만, 모바일 악성코드 프록시로 크롤링하므로 충분하지 않고 전부 잡을 수 없음 애초에 막지 않으면 대체로 비교적 얌전하게 남아 있음 그래서 차단 대신 저렴하게 생성한 쓰레기 데이터를 먹여 지옥 모드를 유발하지 않는 게 요령이고, 나는 https://iocaine.madhouse-project.org/ 를 씀 - 참고로 MediaWiki 권한으로도 할 수 있음. 기본값을 모든 권한 거부로 두고, 익명 사용자에게 기본 이름공간의 페이지 읽기 정도만 다시 추가하면 고양이와 쥐 게임이 없어짐 다만 그렇게 하면 MediaWiki가 직접 응답을 서빙해야 하므로, Apache에서 처리하는 이점도 있음 - 바로 알아챘는지가 궁금함. 스크래퍼 작성자들이 이미 여러 **대체 기법**을 준비해뒀고, 403을 받기 시작하면 봇이 다음 트릭을 순서대로 시도했을 거라고 봄 - 곁가지지만 **Weird Gloop**은 훌륭한 서비스임. 운영하는 위키 품질이 매우 높고, 팬들이 만든 콘텐츠를 Fandom의 끔찍한 플랫폼에서 옮겨오는 일은 세상에 도움이 됨 - [Gergely Nagy, a.k.a. algernon](https://gergo.csillger.hu/)이자 [iocaine](https://iocaine.madhouse-project.org/) 개발자가 이 문제를 한동안 다뤄왔고, Weird Gloop에 유용한 통찰을 갖고 있을 가능성이 큼 - 이렇게 말하긴 싫지만, **사람 행동에 맞춰 튜닝**하자는 제안은 나중에 발목을 잡을 것 같음 봇이 페이지의 모든 정적 자산까지 요청하기 시작할 테고, 그게 사람을 식별하는 행동의 일부라고 가정함 흥미로운 게임이군요, Falken 교수님 - 스크래퍼가 일반적인 `<a href=...>` 링크를 재귀적으로 따라가며 이런 페이지에 도달한다면, 기록 차이처럼 비싸고 캐시되지 않는 페이지를 `<form method="POST" action=...>` 제출로만 접근 가능하게 해서 부드럽게 다른 곳으로 유도할 수 있지 않을까 싶음 아무것도 차단하지 않고, 사실상 스크래퍼 입장에서도 거의 무한한 **중복 정보**를 재귀적으로 섭취하지 않게 해주므로 이익임 일반 사용자도 차이를 거의 못 느낄 수 있고, 수고 대비 효과가 괜찮을 듯함. 익명 사용자에게는 Anubis보다 나을 수 있음 이건 스크래퍼가 `method="POST"`인 HTTP 폼을 제출하지 않는다는 가정에 달려 있음 그게 대체로 사실이 아니라면, AI 스크래퍼가 익명 편집을 대량 제출해 Wikipedia 내용을 무작위 쓰레기로 바꿨다는 헤드라인을 이미 봤을 것 같음 - 그렇게 하면 응답도 **캐시 불가**가 되어, CDN에 의존한다면 문제가 될 수 있음 봇이 `<form method="GET">`도 누를지 궁금함. 이러면 캐시와 잘 맞고 크롤러에는 추가 로직을 요구할 수 있음 - 내 작은 블로그 트래픽의 95%는 **Singapore와 China의 LLM 스크래퍼**에서 옴 - 몇 년이나 지났는데도 아무도 IP를 뒤져서 연락하고 직접 찾아갈 수 있는 작은 ISP의 IP 하나를 못 찾았나? 그 사용자에게 찾아가 컴퓨터를 점검해도 되는지 정중히 묻지도 않았나? 실제로 어떤 소프트웨어가 크롤링하는지 아무도 밝혀내지 못했나? 사이트 운영자들이 이 정도도 못 한다면 더는 신경 쓰고 싶지 않음. 실제로 지저분한 **사람 간 접촉**을 피하려고 안간힘을 쓰니 봇을 얻는 것임 그리고 주거용 봇넷에서 돌아가는 봇은 가끔 CAPTCHA나 Anubis를 통과할 만큼의 연산 자원을 당연히 갖고 있음 서버 쪽에서 영구적으로 이기는 건 불가능함. 그 컴퓨터의 사용자도 합법 트래픽을 만들기 때문임 그러니 **원격 증명**을 원하는 게 아니라면 그 IP들로 찾아가야 함 - 주거용 봇넷의 규모를 과소평가하는 것 같음 - 문제는 수만 개의 서로 다른 IP에서 트래픽이 온다는 것임 전 세계를 운전해 다니는 기름값 같은 현실 문제를 빼더라도, 엄청난 **외판원 문제**가 됨 - 정말 놀라울 정도로 형편없는 견해임 봇 몇 개가 시스템 관리자에게 조금 더 얌전하게 굴도록 주말 내내 어디든 운전해 가면 된다는 발상은, 특히 대부분이 대형이거나 외국계 ISP에서 온다는 점을 생각하면 웃길 뿐임 뭘 피웠는지 궁금할 정도임 요즘 어떤 소프트웨어가 크롤링하느냐고? 누군가 챗봇에게 “이걸 스크래핑하는 걸 만들어줘”라고 시키고, 각 스크래퍼가 개별적으로 만들어지는 식임 - “아무도”라는 질문은 누가 그 일을 할 능력과 동기 또는 책임을 갖는지 말할 수 있을 때만 합리적임 그렇지 않으면 그냥 추상적으로 온 우주를 탓하는 셈임 - 작은 ISP에 연락해서 찾아간다는 건 현실성이 낮음 대부분의 서비스 제공자는 자기 IP가 어떤 웹사이트 스크래핑에 쓰이는지 전혀 신경 쓰지 않는다고 장담할 수 있음 게다가 그 제공자들이 IP에 연결된 주소를 알려줄 일도 없다고 장담함 훨씬 잘 먹히는 건 Alibaba, AWS 같은 여러 제공자와 관련된 **ASN 트래픽을 통째로 버리는 것**임 항상 가능한 선택지는 아님. 예를 들어 Atom 피드가 있는 블로그라면 피드 리더도 함께 막을 수 있음 하지만 많은 경우 쓰레기 트래픽의 80%를 없앨 수 있음 - 이런 동작이 왜 발생하는지 아는 사람이 있나? 특히 **스파이크**가 왜 생기는지 궁금함 - 들은 가설로는 봇넷이 신뢰성이 낮고, 주거용 프록시로 봇넷 접근을 파는 사람들이 그 불안정성을 **중복 요청**으로 보완한다는 것임 사실인지는 모르겠지만 적어도 그럴듯함 인프라를 더 잘 이해하지 못하면 말하기 어려움. 명령·제어 한계일 수도 있음 봇넷이 DDoS용으로 만들어졌다면 구조상 세밀한 제어가 부족할 수도 있음