2025년 3월 28일 금요일
로봇 제외 프로토콜(REP)에 관한 이전 게시물에서는 robots.txt 및 URI 수준 컨트롤과 같은 REP의 다양한 구성요소를 사용해 이미 할 수 있는 작업을 살펴봤습니다. 이 게시물에서는 REP가 끊임없이 진화하고 있는 자동 클라이언트와 인간 웹 간의 관계에서 어떤 역할을 할 수 있는지 살펴봅니다.
REP(특히 robots.txt)는 2022년에 RFC9309로 표준이 되었습니다.
하지만 중요한 일은 이미 표준이 되기 전에 완료되었죠. REP는 1994년부터 2022년이라는 긴 시간 동안 테스트되면서 큰 인기를 누렸고 수십억 개의 호스트, 거의 모든 주요 크롤러 운영자(악성코드 스캐너와 같은 적대적인 크롤러 제외)에서 REP를 채택하게 되었습니다. REP는 간단하면서도 다양한 용도로 사용할 수 있는 문법을 적용해 환경설정을 표현하는 직관적이며 우아한 솔루션입니다.
25년 동안 원래 형태에서 거의 진화하지 않았으며 크롤러에서 보편적으로 지원하는 규칙만 고려해 본다면 오로지 allow 규칙만 사용된다고 볼 수 있습니다.
그렇다고 다른 규칙이 없는 것은 아닙니다. 크롤러 운영자는 자체적인 규칙을 만들 수 있습니다. 예를 들어 'clean-param' 및 'crawl-delay'와 같은 규칙은 RFC9309에 포함되어 있지 않습니다. 하지만 일부 검색엔진에서는 이 규칙을 지원합니다. Google 검색에서는 지원되지 않지만요.
'sitemap' 규칙 역시 RFC9309에 포함되어 있지 않지만, 모든 주요 검색엔진에서 지원됩니다. 충분한 지원이 있으면 REP의 공식 규칙이 될 수 있습니다.
REP는 실제로 '업데이트'를 받을 수 있기 때문입니다. REP는 널리 지원되는 프로토콜이며 인터넷과 함께 성장해야 합니다. 그러나 REP를 변경하는 것이 불가능하지는 않지만 간단하지도 않습니다. 간단할 수가 없죠. REP는 광범위하게 지원되고 있기 때문입니다. 그리고 표준이 변경되는 다른 모든 상황에서와 마찬가지로, 변경사항이 게시자와 크롤러 운영자 모두의 프로토콜 사용자 대다수에게 이롭다는 합의가 있어야 합니다.
REP는 간편하고 광범위하게 사용되므로 새로운 크롤링 환경설정을 적용하는 데 적합합니다. 예를 들어 수십억 명의 게시자가 이미 robots.txt 및 문법에 익숙하므로 robots.txt를 변경하는 것이 자연스럽습니다. 한편 크롤러 운영자들은 이미 강력하고 잘 테스트된 파서와 매처를 보유하고 있습니다. Google 역시 자체 robots.txt 파서를 오픈소스로 제공합니다. 따라서 새 규칙이 도입되더라도 파싱 문제가 발생할 가능성이 매우 낮습니다.
REP URI 수준 확장 프로그램, X-robots-tag HTTP 헤더, 이에 상응하는 메타 태그도 마찬가지입니다. 선택 해제 환경설정을 전달하는 새 규칙이 필요하다면 확장하는 것은 간단합니다. 그렇다면 어떻게 해야 할까요?
독자 여러분이 할 수 있는 가장 중요한 일은 아이디어를 공개적으로 이야기하고 지지하는 사람들을 모으는 것입니다. REP는 공개 표준이므로 어느 당사자도 일방적으로 이를 변경할 수 없습니다. 물론 당사자 측에서 새로운 기능에 대한 지원을 구현할 수는 있지만, 이것이 표준이 되지는 않습니다. 하지만 이러한 변경사항에 관해 이야기하고 크롤러 운영자와 게시 생태계 모두에게 이 변경사항이 모든 사람에게 이롭다는 점을 보여주면 합의가 이루어지고 표준이 업데이트될 수 있는 길이 열립니다.
마찬가지로 프로토콜에 누락된 부분이 있으면 공개적으로 이야기해 보세요. sitemap은 콘텐츠 크리에이터와 검색엔진 모두에게 유용하기 때문에 robots.txt에서 광범위하게 지원되는 규칙이 되었으며, 이로 인해 이러한 확장이 채택되는 길이 열리게 되었습니다. 새로운 규칙에 대한 아이디어가 있다면 robots.txt 사용자와 크리에이터에게 이 규칙에 관해 어떻게 생각하는지 물어보고, 그들과 힘을 합쳐 잠재적 문제를 해결하고 제안서를 작성하세요.
모두를 위한 변화를 이끌어내고 싶다면, 그만한 수고를 들일 가치가 있습니다.