FOSS 인프라가 AI 회사로부터 공격받고 있음

 (thelibre.news)
1P by GN⁺ | ★ favorite | 댓글 1개
  • SourceHut, KDE GitLab, GNOME GitLab, LWN, Fedora, Inkscape, Diaspora, Read the Docs 등 여러 FOSS 인프라가 AI 크롤러와 AI 생성 보안 보고서로 장애·차단·운영 부담을 겪고 있음
  • 크롤러들은 robots.txt를 무시하거나 git blame·Git 로그·커밋 페이지 같은 비싼 엔드포인트를 반복 요청하고, 수만 개 IP와 위장 User-Agent로 일반 사용자 트래픽에 섞이려 함
  • GNOME은 Anubis 작업증명을 도입했지만, 약 2시간 30분 동안 81,000건 요청 중 3%만 통과해 트래픽 대부분이 봇일 가능성을 보였음
  • Edge 버전 차단, 비로그인 사용자 제한, 서브넷·국가 차단, IP 차단 목록, AI 크롤러용 robots.txt·.htaccess 같은 대응이 이어졌고 실제 사용자도 지연이나 접속 차단을 겪음
  • 공개 협업에 의존하는 오픈소스 프로젝트는 사설 서비스보다 노출면이 넓어, AI 스크래핑과 LLM 환각 보안 보고서가 유지보수자의 시간과 운영 여력을 직접 갉아먹음

여러 FOSS 인프라에서 반복된 장애

  • SourceHut의 founder 겸 CEO Drew DeVault는 LLM 회사들이 robots.txt를 존중하지 않은 채 데이터를 크롤링해 SourceHut에 심각한 장애를 일으킨다고 비판함
  • KDE GitLab 인프라는 Alibaba 범위의 IP에서 온 AI 크롤러로 과부하가 걸렸고, KDE 개발자들이 GitLab에 일시적으로 접근하지 못함
  • GNOME GitLab에는 장애를 유발하는 AI 스크래퍼를 막기 위한 Anubis 작업증명 챌린저의 기본 로딩 화면이 나타나기 시작함
  • 사례가 누적되면서 AI 스크래퍼의 공격성이 커지고, 공개 협업을 전제로 하는 FOSS 커뮤니티의 운영 부담도 늘어남

크롤러의 동작 방식과 차단 난점

  • Drew DeVault에 따르면 LLM 크롤러는 robots.txt 요구를 지키지 않고 비용이 큰 페이지까지 저장소 전체를 훑음
    • 대상에는 git blame, Git 로그의 모든 페이지, 저장소의 모든 커밋이 포함됨
    • 크롤러는 수만 개 IP에서 무작위 User-Agent를 사용하며, 각 IP는 HTTP 요청을 하나 이하로 보내 사용자 트래픽에 섞이려 함
  • 이런 방식 때문에 완화책을 만들기 어렵고, SourceHut에서는 높은 우선순위 작업이 몇 주 또는 몇 달 지연됨
  • 봇과 사람을 구분하기 어려워 실제 사용자도 간헐적으로 영향을 받았고, SourceHut 장애로 이어짐
  • Drew는 모든 AI 회사가 robots.txt나 User-Agent 보고를 같은 방식으로 다루는지는 구분하지 않음

KDE와 GNOME의 대응

  • KDE sysadmin 팀의 Ben에 따르면 KDE GitLab에 DDoS를 일으킨 IP들은 모두 MS Edge라고 주장했고, 중국 AI 회사들 때문이었음
    • Ben은 OpenAI와 Anthropic 같은 서구 LLM 운영자는 적어도 올바른 User-Agent를 설정한다고 봄
    • 임시 해결책은 봇들이 주장한 Edge 버전을 차단하는 방식이었음
    • 봇들이 User-Agent를 바꿔 섞이려는 경향이 있어 최종 해결책으로 쓰기 어려움
  • GNOME은 작년 11월부터 문제를 겪었고, 로그인하지 않은 사용자가 머지 리퀘스트와 커밋을 보지 못하게 속도 제한을 걸었음
    • 이 조치는 실제 비로그인 사용자에게도 문제를 일으킴
  • 이후 GNOME은 Anubis로 전환함
    • Anubis는 브라우저에 계산 과제를 제시하고, 브라우저가 시간을 들여 풀이를 서버에 보내면 접근을 허용함
    • 개발자는 이를 “핵 대응에 가까운 조치”라고 표현했으며, AI 스크래퍼 봇이 robots.txt 같은 표준을 따르지 않아 강제된 선택이었다고 봄
  • Anubis도 사용자 영향을 남김
    • 같은 장소에서 많은 사람이 링크를 열면 더 높은 난도의 과제가 제공될 수 있음
    • 한 사용자는 1분 지연을, 다른 사용자는 휴대폰에서 약 2분 대기를 겪음
    • GitLab 링크가 채팅방에 붙거나 Triple Buffering GNOME 머지 리퀘스트가 Hacker News에 올라 관심을 받았을 때 이런 상황이 발생함
  • GNOME sysadmin Bart Piotrowski가 공유한 수치에 따르면 약 2시간 30분 동안 총 81,000건 요청 중 3%만 Anubis 작업증명을 통과함
    • Anubis 통과 비율: {p:3}
    • 이는 트래픽의 97%가 봇일 가능성을 시사함

LWN, Fedora, Inkscape의 차단 사례

  • LWN을 운영하는 Jonathan Corbet은 AI 스크래퍼 봇의 DDoS 때문에 사이트가 “가끔 느릴 수 있다”고 사용자에게 알림
    • 실제 사람 독자에게 제공되는 트래픽은 전체의 작은 일부에 불과하다고 함
    • 봇들은 한때 수백 개 IP에서 동시에 접근했고, 자신을 봇으로 식별하지 않았으며, robots.txt만 읽지 않았다고 함
  • Fedora 프로젝트 sysadmin Kevin Fenzi도 AI 스크래퍼 문제를 겪음
    • 한 달 전에는 pagure.io가 살아 있도록 유지하기 위해 대응해야 했음
    • 이후 상황이 악화되어 여러 서브넷을 차단했고, 실제 사용자도 영향을 받음
    • 절박한 상황에서 브라질 전체를 차단했으며, 이 차단은 아직 유지 중인 것으로 이해됨
  • Neal Gompa는 국가 전체 차단도 한계가 있으며, Fedora 인프라가 AI 스크래퍼 때문에 “몇 주 동안 정기적으로 다운”됐다고 지적함
  • Inkscape도 지난주 같은 문제를 겪음
    • Martin Owens는 작년의 일반적인 중국 DDoS가 아니라, 여러 회사가 spider 설정을 무시하고 브라우저 정보를 위장한 상황이라고 봄
    • 그는 Prodigius 차단 목록을 만들었고, AI를 하는 대기업에서 일하면 Inkscape 웹사이트에 더 이상 접근하지 못할 수 있다고 말함

IP 차단 목록과 공동 대응 시도

  • Frama software의 BigGrizzly도 나쁜 LLM 크롤러에 flooded 되었고, 위장 User-Agent를 쓰는 460,000개 IP 차단 목록을 만들었음
    • 그는 이 목록을 공유할 수 있다고 함
  • ai.robots.txt 프로젝트는 AI 회사와 관련된 웹 크롤러의 공개 목록을 만들려는 더 포괄적인 시도임
    • Robots Exclusion Protocol을 구현한 robots.txt를 제공함
    • 목록에 있는 AI 크롤러 요청에 오류 페이지를 반환하는 .htaccess 파일도 제공함

Diaspora와 Read the Docs의 트래픽 수치

  • Diaspora 인프라에 대한 Dennis Schubert의 분석에서는 전체 웹 트래픽의 상당 부분이 AI 회사 봇으로 나타남
    • OpenAI User-Agent 봇이 전체 웹 트래픽의 4분의 1을 차지함
    • Amazon은 15%, Anthropic은 4.3%를 차지함
    • 전체 요청의 약 70%가 AI 회사에서 온 것으로 집계됨
  • Schubert는 이 봇들이 한 번 크롤링하고 떠나지 않고 6시간마다 다시 오며, robots.txt를 신경 쓰지 않는다고 말함
    • 속도 제한을 걸면 다른 IP로 전환함
    • User-Agent 문자열로 차단하면 봇이 아닌 User-Agent 문자열로 바꾼다고 함
    • 이를 인터넷 전체에 대한 DDoS라고 표현함
  • Read the Docs는 “AI crawlers need to be more respectful”라는 글에서 모든 AI 크롤러를 차단하자 트래픽이 75% 감소했다고 밝힘
    • 트래픽 감소율: {p:75}
    • 트래픽은 하루 800GB에서 200GB로 줄어듦
    • 이로 인해 월 약 1,500달러를 절감함
    • 크롤러들이 며칠 안에 수십 TB 데이터를 내려받는 사례도 있었음
    • 여러 IP를 사용하기 때문에 완전히 차단하기 어려움
  • Schubert에 따르면 Google과 Bing 같은 “정상” 크롤러는 합쳐도 1% 미만의 일부에 불과함

AI 생성 보안 보고서가 만든 유지보수 부담

  • 문제는 스크래퍼에 그치지 않고 AI 생성 버그 보고서로도 번짐
  • Curl 프로젝트의 Daniel Stenberg는 “The I in LLM stands for Intelligence”라는 글에서 AI가 생성한 버그 보고서 문제를 다룸
    • Curl은 버그 바운티 프로젝트를 운영함
    • 최근 많은 버그 보고서가 AI로 생성되었고, 겉보기에는 그럴듯해 개발자가 확인하는 데 시간을 소모함
    • 하지만 보고서에는 AI에서 기대되는 전형적인 환각이 들어 있음
  • CPython, pip, urllib3, Requests 등의 보안 보고서 triage 팀에 있는 Seth Larson도 비슷한 문제를 겪음
    • 오픈소스 프로젝트에 극히 저품질이고 스팸성인 LLM 환각 보안 보고서가 늘어남
    • 이런 보고서는 처음 보면 합법적일 수 있어 보이기 때문에 반박하는 데 시간이 필요함
  • 보안 보고서 대응은 비용이 크고, 그럴듯하지만 만들어진 버그 보고서에 대응하는 일은 유지보수자에게 큰 추가 부담을 줌
  • Larson은 취약점 탐지에 AI나 LLM 시스템을 쓰지 말라고 요청함
    • 현재 시스템은 코드를 이해할 수 없고, 보안 취약점 탐지에는 코드 이해와 의도·일반적 사용 방식·맥락 같은 인간 수준 개념 이해가 필요하다고 함

FOSS에 더 크게 작용하는 구조적 부담

  • FOSS 프로젝트는 상용 제품보다 자원이 적은 경우가 많음
  • 커뮤니티 주도 프로젝트는 인프라의 더 많은 부분이 공개되어 있어 크롤러에 노출됨
  • 공개 이슈·보안 보고·협업 인프라가 필요하기 때문에 AI 스크래퍼와 AI 생성 이슈가 동시에 부담으로 작용함
  • 결국 장애 대응, 차단 정책, 사용자 피해 완화, 허위 보안 보고서 검토가 오픈소스 유지보수자의 시간을 소모함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 여기 사례도 있음: https://about.readthedocs.com/blog/2024/07/ai-crawlers-abuse... 원문에도 인용된 글인데, 대규모 인터넷 인프라를 운영하는 지인들은 다 비슷한 일을 겪고 있음
    이 글은 그런 사례를 한곳에 잘 모아줌. 글을 쓸 때도 말했지만, 이들은 그냥 신뢰 자산을 완전히 불태우는 중임
    이 분야의 주요 스타트업 하나는 우리와 직접 협업했고, 비용을 환불해 줬으며, 크롤러 버그도 고쳤음. 반면 Facebook은 이메일에 답하지 않았고, User Agent의 링크는 404였음. 회사 엔지니어가 글을 보고 올바른 이메일을 알려줬지만, 거기로 3번 보냈는데도 답이 없었음

    • AI 기업들은 신뢰 자산이 중요하지 않다는 태도로 움직이는 듯함. 1000억 달러 자본을 가진 800파운드 고릴라처럼 하고 싶은 대로 함
      원하든 원하지 않든 AI는 모든 제품에 들어갈 것이고, 원하든 원하지 않든 모든 데이터를 흡수할 것이라는 태도임
    • “크롤러 하나가 2024년 5월에 압축된 HTML 파일 73TB를 내려받았고, 대역폭 비용이 5,000달러 넘게 들었다”는 부분에서 다시 읽게 됐음
      전용 서버 위주로 월 수백 TB 트래픽을 처리하는 인프라를 운영하는데, 트래픽 비용은 TB당 대략 0.50~3달러 수준임. 지역에 따라 달라지긴 하지만 AWS 송신 트래픽 비용은 정말 미친 수준임
    • 답이 없으면 이메일 대신 외상매입금 팀에 청구서를 보내면 됨
    • 3번 이메일을 보내도 답이 없었다면, 그 시점부터 크롤링은 버그나 실수가 아니라 DDoS로 봐야 하는 것 아닌가?
    • 그냥 동적으로 생성한 쓰레기 정보를 먹이면 어떨까? 아무 정보도 안 주는 것보다 더 재미있을 듯함

  • 내 프로젝트가 미리보기 이미지에 이렇게 나오는 걸 보니 정말 비현실적임. 대단하네! 써보고 싶다면 여기 있음: https://github.com/TecharoHQ/anubis
    지금까지 보기로는 실제로 동작하는 것 같음. 내 블로그에서 운영 환경에서 어떻게 실패하는지 보려고 xeiaso.net에 배포해 둠

    • 사람에게 지금 무엇을 해야 하고, 그 페이지에서 무슨 일이 일어나는지 설명을 조금 넣어주면 좋겠음
      로딩 애니메이션 위젯 같은 게 있긴 하지만, 몇 주 전 Gnome 이슈 트래커에서 처음 봤을 때는 작업 증명이 20초쯤 걸렸고 무슨 상황인지 몰랐음. 처음에는 차단됐거나 캡차가 로드되지 않은 줄 알았음
      지금은 무엇인지 알지만, “봇인지 확인 중” 페이지만 단독으로 보면 100% 명확하진 않아 보임
    • 이 방식이 정말 마음에 듦. 인터넷이 서부 개척 시대처럼 굴러가는 건 괜찮지만, 책임 소재가 없는 건 싫음
      사이트를 계속 무료로 열어두고 싶은 쪽이 경제적 부담을 크롤러에게 넘기는 좋은 방법임. 데이터를 원하면 가져가는 쪽에서 돈을 쓰면 됨
      검색 엔진에서 빠질 수 있다는 단점은 있지만, 서비스를 전역 또는 P2P 인덱서에 등록하지 못할 이유도 없음
    • 마음에 듦, 늘 그렇듯 잘 만들었음
      그리고 https://news.ycombinator.com/item?id=43422781 관련해서, 원하는 잡코인의 극소액을 계산하는 방식을 붙이면 암호화폐의 실제로 유용한 활용처가 하나 더 생길지도 모르겠음
    • Anubis는 유명해지지 않는 동안만 통할 것임. 유명해지면 크롤러들이 GPU/ASIC으로 작업 증명을 처리하기 시작할 테고, 그러면 끝장임
    • 가끔 무작위로 당신이 만든 걸 마주치게 되는 게 좋음. 블로그 형식의 설명 방식도 좋아해서 Anubis를 더 살펴볼 생각임

  • 이 속도라면 자유·오픈소스 인프라만의 문제가 아님. 물론 그게 탄광 속 카나리아라 특히 공감하지만, 결국 익명 인터넷 접근 전체의 문제임
    사이트를 인증 벽 뒤에 둘 수는 있지만, 새 봇들은 예전과 달리 캡차를 풀고 실제 사용자를 흉내 냄. 특히 주거용 IP와 가짜 User Agent를 쓰거나, 기사에 나온 것처럼 Playwright 같은 것에 연결된 실제 User Agent까지 쓰면 더 그렇다
    결국 사이트들이 신용카드, Worldcoin, 또는 그만큼 우울한 대체물을 요구하기 시작하는 것 말고 뭐가 남겠나

    • 이미 절반쯤 와 있음. OpenStreetMap 매핑을 하면서 자체 웹사이트가 없는 지역 업체를 찾아볼 때마다 체감함
      이들은 Facebook, Instagram, X 등을 디지털 명함처럼 씀. 평소 Facebook이나 Instagram을 쓰지 않고 X도 접었으며 계정도 없는데, 그런 링크를 따라가면 일부 정보만 보이다가 계정을 만들든지 나가라는 대화상자가 뜨거나 알 수 없는 오류가 나옴
      사적 커뮤니티에 가입하는 건 괜찮지만, 공개적으로 보일 거라 생각하고 올린 정보에 이런 장벽이 생기는 건 정말 짜증남
    • 조용한 부분을 크게 말하자면, 이게 우울한 가장 큰 이유 중 하나는 단순한 훼손이 아니라 관련된 악당들에게 복리로 이득이 쌓이는 훼손이기 때문임. 콘텐츠를 긁어가는 건 시작일 뿐임
      비용 증가로 사이트가 영원히 내려간다? 훌륭함, 사람들이 모든 문서에 AI를 써야 하니까. 캡차에서 물러나 신용카드나 전화번호를 넣게 만든다? 훌륭함, 인터넷의 익명성이 그만큼 줄어드니까
      데이터 유출로 사기가 늘어난다? 훌륭함, 그걸 막으려면 AI가 필요할 테니까. 악의적 행위자에게는 거의 모두가 이기는 판임
      인터넷의 발칸화는 오래전부터 논의돼 왔음. 그런 위협이나 이미 통제 불능의 쓰레기장이라는 사실이 상황을 더 악화시키는 데 어느 정도 신중함을 만들 것 같지만, 사람들이 감당할 수 있는 괴롭힘과 마찰의 한계를 밀어붙이는 일은 어차피 중요하지 않음. 실제 선택권이 없기 때문임
    • 잘 모르겠음. 작은 브라우저 게임을 운영하는데, 서버가 LLM 스크레이퍼에게 주기적으로 완전히 두들겨 맞고 있지만, 봇이 만든 것처럼 보이는 신규 계정은 아직 하나도 못 봤음
      신규 가입률도 눈에 띄게 변하지 않았음. 게임과 위키 모두에서 그렇고, 스크래핑 트래픽은 대부분 위키로 몰렸음. 스크래핑이 줄지 않으면 위키는 거의 완전한 인증 벽 뒤로 넣어야 할 가능성이 큼
    • 다음 X개의 요청을 하려면 이만큼의 토큰을 처리해야 한다는 식이 될 수 있음. 물론 꽤 유토피아적으로 들리긴 함
    • 꼭 인증 벽 뒤에 둘 필요는 없음. 각 요청마다 익명 소액결제 서비스를 쓰는 것도 충분히 가능함
      방문자가 너무 많아지는 게 웹사이트의 존립 위기가 되는 인터넷이라면, 우리가 사는 인터넷은 오래 살아남을 수 있는 구조가 아니라는 뜻임

  • 예전에 검색 엔진이 이런 일을 일으켰을 때 업계는 법적 규제가 만들어지는 걸 피하려고 합의했고 robots.txt 명세를 만들었음. 그래서 법적 틀이 만들어지지 않았음
    지금은 그 합의에 참여하지 않은 새 세대의 굶주린 인덱서들이 있고, 경쟁 압박 때문에 가능한 한 많은 데이터를 긁어모으려 하며, robots.txt를 그냥 무시함
    어쨌든 입법이 이뤄졌어야 했고, robots.txt를 무시하는 쪽은 차단·벌금·속도 제한 등을 받았어야 함

    • 이 계획이 마음에 드는지는 모르겠음. 불법 AI가 합법 AI보다 더 많은 지식과 유용성을 갖게 해서는 안 됨
      전면 금지 말고도 다른 선택지는 있음
    • 미국 하원이나 의회 의원 중 robots.txt가 뭔지 아는 사람이 한 명이라도 있으면 놀랄 것 같음
    • 미국이나 EU의 법이 중국, 태국, 러시아에서 오는 트래픽을 어떻게 막을 수 있겠나? 기껏해야 인터넷을 파편화할 텐데, 그건 “최선”도 아니고 끔찍한 생각임

  • 나도 최근 공격을 받았음 [0]. 여러 오픈소스 패키지 코드를 올려두는 작은 Forgejo 인스턴스라 공개돼 있어야 하는데, 완전히 망가졌고 생성된 ZIP 아카이브로 디스크가 꽉 찼음
    같은 일을 겪은 건 나뿐만이 아님. 내 경우 Alibaba Cloud IP 대역을 차단하자 공격이 일단은 잦아들었음
    Forgejo 인스턴스를 운영한다면 DISABLE_DOWNLOAD_SOURCE_ARCHIVES를 true로 설정하는 걸 강력히 권함. 크롤러가 여전히 CPU를 꽉 물고 늘어지겠지만, 적어도 디스크가 ZIP 파일로 가득 차지는 않을 것임
    [0] https://blog.nytsoi.net/2025/03/01/obliterated-by-ai

    • “생성된 ZIP 아카이브로 디스크가 꽉 찼다”는 건, 즉석에서 ZIP 파일을 만드는 나쁜 소프트웨어 설계임
    • 차라리 공개 인터넷에서 서비스되도록 제대로 설계된, 잘 만든 소프트웨어로 바꾸는 편이 나을 수도 있음
      ZIP 파일을 생성하고, 통째로 디스크에 쓴 다음, 한 번에 클라이언트로 보내는 설계는 완전히 끔찍하고 쓸 수 없는 방식임. 제대로 된 설계라면 메모리를 최소로 쓰고 디스크를 전혀 쓰지 않으면서 점진적으로 생성해 클라이언트로 전송해야 함
      이런 말도 안 되는 설계가 있다는 건 개발자들이 효율성을 거의 무시했다는 신호이고, 비슷한 치명적 문제가 잔뜩 있을 가능성이 큼
      예를 들어 Forgejo 소스 코드를 대충 보면, 모든 Git 작업에 전용 라이브러리를 쓰는 대신 “git” 프로세스를 띄우는 것처럼 보임. 확인하진 않았지만, 그런 작업들이 해당 연산을 수행하는 가장 효율적인 방식과는 매우 멀어도 놀랍지 않음
      이렇게 극도로 부실한 소프트웨어를 돌리면 CPU가 100%에 고정되고 서버가 사용할 수 없게 되는 것도 놀랍지 않음

  • 여기서 큰 결론은 Google과 광고 전반의 웹 지배력이 사라지고 있다는 것임
    봇을 막는 유일한 방법은 캡차인데, 이러면 검색 인덱서도 사이트를 색인하지 못함. 결국 검색 엔진이 사이트를 색인하지 못하고, 더 이상 가치를 제공하지 못하게 됨
    현재 LLM에 들어 있는 지식이 말라붙는 데 약간의 시차는 있겠지만, 더 이상 누구도 자동화된 방식으로 웹을 긁을 수 없게 될 것임
    다 타버릴 것 같음

    • 실제로는 늑대와 토끼 개체군 같은 랴푸노프 안정성이 될 것 같음. 이 시나리오에서 우리는 토끼임
      AI 개체수가 줄면 인간 콘텐츠가 늘고, 이는 AI에게 더 많은 먹이가 되어 AI가 다시 늘어남. 그러면 인간 표현이 묻히고, 인간은 더 조용해짐. AI 먹이가 줄어 AI가 감소하면, 소음이 줄고 인간이 다시 커짐. 이 순환이 지겹게 반복됨
    • 개인적으로는 이것이 Web Environment Integrity의 실제 동기 중 하나였다고 봄. Google은 색인할 수 있게 하고 다른 곳은 못 하게 하는 것임
      우리는 곤란한 양자택일에 끼어 있음. 고착화된 기존 강자를 원하나, 아니면 저렴하고 열린 호스팅을 원하나?
    • Google은 이미 사이트를 긁어가서 검색 결과에 바로 답을 보여줌. 트래픽을 중요하게 생각하고 광고 지면을 팔고 싶다면, 이제 왜 Google에 내 사이트가 색인되길 원해야 하나?
      광고 기반 사이트 상당수는 어두워질 것임. 방문자는 봇뿐일 테니까
    • 인증 기반 크롤링으로 이동해야 한다면 기존 검색 엔진의 입지가 더 강화될 것임. 초대받은 크롤러만 접근할 수 있게 되기 때문임
      간단한 도구가 있다면 대부분은 Google, Bing, 그리고 많아야 한두 곳만 허용할 것임
    • 최고의 캡차 우회 기술을 가진 AI 기업이 이길 것이고, 더 정교한 방식으로 LLM 출력에 광고를 삽입할 것임

  • 작은 방해 공작에 관심 있는 사람이 있다면, 내 마이크로블로그의 진짜 정보를 어느 정도 “익사”시키는 데 성공한 것 같음
    LLaMa로 실제 글 하나당 수십 개의 상반된 글을 만들고, 사람이 클릭하지 않도록 보이지 않게 링크했음. 말하자면 Bannon식으로 쓰레기로 구역을 범람시키는 것임

    • 이런 접근이 쓰이는 걸 본 적은 있는데 성공률은 잘 모르겠음. 논리적으로는 그럴듯함
      사람이 실제로 볼 수 없는 경로를 명시적으로 참조하고, 그 경로를 치는 트래픽은 봇으로 보는 것임. 봇들은 참지 못함
    • 맞음. 다만 robots.txt에 꼭 추가해서 나쁜 로봇만 피해를 보게 해야 함
    • 어제 이걸 읽고, 더 큰 규모에서 완화하는 방법을 생각해 봤음. 웹사이트가 무작위 가상 경로나 엔드포인트를 만들어 봇을 로컬에서 제공되는 Library of Babel[0]로 몰아넣고, 쓸모없는 텍스트로 스파이더를 오염시키는 방식임
      봇이 긁고 싶은 정확한 엔드포인트를 알고 있는 잘 구조화된 사이트에는 통하지 않겠지만, 더 탐색적인 스파이더 스레드는 늦출 수 있을 것 같음
      [0] https://libraryofbabel.info/
    • 쓰레기로 범람시키는 것 말고, ZIP 폭탄 같은 걸 제공하거나 계산 자원을 낭비시키는 식의 직접적인 방해 공작은 어떨까?

  • VideoLAN임
    우리도 마찬가지로 포럼과 Gitlab이 AI 회사 봇들에게 두들겨 맞고 있음
    대부분은 robots.txt를 지키지 않음

    • 이를 해결하려고 취한 조치를 문서화했나?

  • 미친 일임. 결국 검색 엔진에 색인되지 않는 웹 버전으로 가게 될지 궁금함. 90년대 브라우징처럼 웹사이트들이 서로 링크를 걸어야 알려지는 방식에 더 가까운 웹 말임
    LLM 스크래핑에 대한 해법이 접근을 허용하기 전에 브라우저에 작업 증명을 시키는 것이라는 점이 마음에 듦. 새 사이트들이 이런 걸 도입하기 시작할지 궁금함
    그러면 검색 엔진에는 색인되지 않겠지만, 지식재산권을 보호하는 데는 도움이 될 것임

  • 지금까지 생각해 본 적은 없지만, LLM 제품과 클라우드 컴퓨팅 서비스를 둘 다 제공하는 회사들이 이중으로 수익을 얻는다는 건 미친 일임
    팔 수 있는 LLM 제품을 얻고, 동시에 증가한 부하의 송신 트래픽 비용과 컴퓨팅 비용도 가져감. 이렇게 보면 비효율적인 LLM 스크래핑을 신경 쓸 유인이 어디 있나? 엉망인 채로 둘수록 다른 제국인 클라우드 스토리지 송신 비용으로 돈을 버는 구조임

답변달기