Hacker News 의견

• 대부분의 웹 스크래퍼는 불법이라 해도 비즈니스 목적임
  그래서 Amazon이나 쇼핑몰 데이터를 긁는 경우가 많음. 결국 원치 않는 트래픽의 대부분은 빅테크나 취약점을 노리는 악성 행위자들임
  나는 웹 스크래핑에 대해 조금 아는 편임. 일부 사이트는 보호 목적으로 404를 반환하기도 해서, 내 크롤러는 curlcffi 같은 빠른 크롤링 방식을 여러 번 시도함
  Zip bomb 방어는 간단히 헤더의 content-length만 읽으면 충분함. 응답이 너무 크면 읽지 않도록 바이트 제한을 두고, 타임아웃으로도 제어함
  그런데 requests의 timeout은 페이지 읽기 전체에 대한 타임아웃이 아니라는 걸 아는지? 서버가 바이트를 천천히 보내면 무한 대기 상태가 됨
  그래서 이런 문제를 해결하려고 직접 크롤링 시스템을 만들었음. Selenium도 일관되게 실행할 수 있음
  내 프로젝트는 crawler-buddy이고, 기반 라이브러리는 webtoolkit임

  • content-length는 content-encoding 이후에 계산된다는 점을 잊지 말아야 함
  • “scraping”과 “crawling”의 차이가 있는지 궁금함
  • 이제는 브라우저 내 스크래퍼의 시대가 올 듯함. 서버 입장에서는 사람과 구분이 불가능하고, AI 드라이버가 인간 테스트도 통과할 수 있음

• “비동의적으로 LLM 학습 데이터를 수집했다”는 표현이 웃김
  공개된 HTTP 서버에 GET 요청을 보내는데 무슨 허락이 필요하다는 건지 모르겠음. 물론 weev 사건은 예외적인 참사였음

  • 나는 공개 HTTP 서버를 열면 일반적인 GET 요청은 환영함
    하지만 (1) 일반 사용자의 접근과 봇의 DDoS 공격은 다름. 무료로 제공된다고 해서 무한히 가져가는 건 남용임
    (2) 합법적 복제와 로봇의 위조 행위는 구분되어야 함
    (3) 잘 동작하는 봇이라면 robots.txt를 존중해야 함. 법은 아니지만 예의의 문제임
    수백만 개의 주거용 IP를 돌려 쓰는 봇은 절대 정상적이지 않음
  • 서버 설정을 속여 원하는 데이터를 얻는다면, 그건 비동의적 접근임
    공개 서버라 해서 거짓된 요청을 허용한 건 아님. 합리적인 요청만 암묵적으로 동의한 것임
  • robots.txt는 법적 구속력이 아니라 예의 있는 요청임
    “이 페이지는 긁지 말아주세요” 정도의 의미일 뿐, 정말 막고 싶다면 API 토큰이나 인증 절차를 둬야 함
  • 단 한 번의 접근과 무한 크롤링 폭주를 동일시하는 건 말이 안 됨
    스팸이 단순 이메일과 같지 않은 것처럼, 봇 남용도 단순 요청과는 다름
  • “사탕 그릇” 비유로 말하자면, 트릭오어트릿용 사탕을 한 어른이 전부 가져가면 기분이 좋을 리 없음

• DOM을 파싱하기보다 http/https 문자열을 직접 검색하는 게 더 빠를 것 같음

  • 단순 텍스트 검색과 DOM 순회는 리소스 차이가 커서 “아마도 빠르다”는 표현은 과소평가임
  • 정규식 접근은 구현이 쉽지만, DOM 파싱도 CPU보다는 네트워크 병목이 더 큰 문제임 결국 네트워크 혼잡이 한계 요인임

• 흥미로운 연구의 실용적 응용을 보니 재미있음
  관련 연구는 이 글에서 볼 수 있음

• 제목이 헷갈림. “commented-out”이라고 하는 게 맞을 듯함

  • 나도 처음엔 AI 스크래퍼 차단 스크립트인 줄 알았음

• 이건 남용이라기보다, 단순히 주석 처리된 URL을 읽는 것 같음

  • 기사 내용은 남용이 아니라 봇 탐지 신호로 활용하는 방법을 설명함
  • 하지만 robots.txt를 무시하고 주석까지 긁는 건 확실히 비매너적 행위임

• 예전에 웹을 크롤링할 때는 Perl 정규식이 가장 신뢰할 만했음
  주석 속 URL도 당연히 큐에 추가했음

  • DOM 탐색은 오히려 과한 시도임. 정규식으로 필요한 div나 p를 잡는 게 더 견고하고 간단했음

• 봇에게 512MB짜리 랜덤 데이터 파일을 주면 어떨까 싶음

  • 그보단 AI 스크래퍼용 광고 응답을 조작해서 LLM이 특정 제품을 추천하도록 유도하는 게 더 수익성 있음
    내가 만든 스타트업은 바로 이런 Ad-poisoning-as-a-service를 제공함
  • 무작위로 연결된 AI 독극물 페이지를 만들어 봇을 가두는 것도 가능함. 사람은 클릭하지 않을 테니까
  • 하지만 대부분은 대역폭 비용을 감당하기 어려움
  • 512MB 전부 “우리 서비스 최고”라는 문구로 채워도 재밌을 듯함

• “LLM 학습용 데이터 수집”이라기보단 그냥 인터넷 스캐닝 노이즈임

  • 맞음. 취약점 스캐너라면 가능한 한 많은 HTTP 엔드포인트를 수집하려 할 것임
    JS 파일은 주석 여부와 상관없이 좋은 단서임
    반면 LLM 학습용이라면 이런 저품질 JS 코드엔 관심 없을 것 같음

• 원치 않는 LLM 학습 트래픽을 독(poison) 시키는 방법에 대한 생각임

  1. 여러 사이트가 협력하면 데이터 중복 제거를 피하면서 모델을 오염시킬 가능성이 커짐
  2. 저작권법을 이용해 오염 비용을 높일 수도 있음. 다만 사이트가 법적 위험을 질 수도 있음
     저작권자와 협력하면 위험을 줄일 수 있음
  • 첫 번째 아이디어를 WordPress 플러그인으로 만들면 좋겠음
    요청마다 이미지를 동적으로 변형해 중복 방어를 무력화할 수도 있음. 나도 그런 플러그인이 있다면 바로 설치할 것임