13개 플랫폼에서 지속적으로 수집한다는 건 규모에 대한 이야기처럼 들립니다. 잘 안 보이는 부분은, 이게 수집 대상이 되는 사이트에 대해 잘 처신한다는 이야기이기도 하다는 겁니다. 그리고 바로 이 부분이 파이프라인이 첫 주에 차단당하지 않고 18개월 넘게 계속 돌아가게 만드는 실제 이유입니다.
요청에서 수집까지, 예의 규칙을 거쳐가는 개념도입니다.
두 번째 단계 뒤에 있는 관습인 robots.txt는 1994년부터 비공식적으로 쓰여 왔지만, 공식 인터넷 표준이 된 건 2022년입니다. IETF가 RFC 9309를 발표하면서 크롤러가 허용·비허용 규칙을 어떻게 해석해야 하는지, 오류를 어떻게 처리하는지, 파일을 어떻게 캐시하는지를 명문화했습니다. 이렇게 널리 지켜지던 관습이 표준화되기까지 수십 년이 걸렸다는 사실 자체가, 웹의 상당 부분이 강제보다는 이런 상호 예의로 돌아간다는 걸 보여줍니다.
세 번째 단계는 덜 표준화되어 있지만 똑같이 실용적입니다. 요청을 몰아서 보내지 않고 시간에 걸쳐 분산시키는 것이죠. 속도 제한을 무시하는 크롤러는 차단 위험만 지는 게 아닙니다. 부하가 걸린 사이트는 보통 더 느리거나, 부실하거나, 속도 제한이 걸린 응답을 돌려주기 때문에, 애써 수집한 데이터의 품질 자체가 떨어집니다. 여기서 예의는 단순히 민폐를 안 끼치는 것 이상입니다. 데이터 자체를 신뢰할 수 있게 유지하는 방법입니다.
더 공격적인 크롤러라면 이론적으로는 더 빨리 수집할 수 있습니다. Datriss는 그 이론적 속도 대신 신뢰성과 장기적인 접근권을 택합니다. 앞선 글에서 다룬 인프라 선택과 같은 트레이드오프입니다 — 최대한 가능한 것보다 실제로 필요한 것을 택하는 방식이죠.
- IETF, RFC 9309: Robots Exclusion Protocol, 2022— robots.txt를 공식 표준으로 명문화한 문서로, 이 글에서 인용했습니다.