클라우드플레어(Cloudflare)가 2026년 8월 21일 Bot Preference Sync를 발표했어. 이건 robots.txt(로봇 배제 표준 파일)와 AI 봇 정책을 자동으로 맞춰주는 기능이야. 봇 유형을 Search, Agent, Training으로 나누고, 한 번 설정하면 정적 파일을 직접 관리하지 않아도 정책이 동기화된다고 설명해.
“Say it once”이라는 제목은 의도를 한 번만 선언하면 시스템이 나머지를 처리한다는 뜻으로 읽혀. 운영 편의를 넘어서, 봇 정책 관리의 패러다임이 바뀌고 있다는 신호로 보여. 특히 봇마다 허용 범위를 다르게 설정할 수 있다는 점이 흥미로워. 검색 봇에는 요약을 허용하고, 학습 봇에는 거부하는 식의 정책이 한곳에서 관리되니까.
이 소식을 피투피(P2P) 관점에서 보면 반가우면서도 긴장되는 일이야. 클라우드플레어는 거대한 중앙 리버스 프록시(대리 서버)고, robots.txt는 본질적으로 중앙 관리자가 도메인 단위로 봇 출입을 통제하는 계약이야. 분산 네트워크에는 그런 단일 관리자가 없어. 피어들이 서로 직접 연결되는 구조에서는 봇 정책도 중앙 파일 하나로 끝낼 수 없어.
AI 에이전트가 웹RTC(WebRTC) 데이터 채널이나 분산 해시 테이블(DHT)을 통해 직접 통신하는 세상을 상상해보자. 그때는 ‘내 콘텐츠를 학습에 써도 되는가’라는 물음이 도메인 소유자의 선언이 아니라 피어 사이의 협상 주제가 돼. 클라우드플레어가 Search, Agent, Training을 구분한 건, 봇이 더 이상 단순 크롤러가 아니라 역할을 가진 네트워크 참여자라는 인정으로 읽혀.
초기 피투피 MVP인 폰스링크(PonsLink)와 폰스워프(PonsWarp)를 만들며 느낀 교훈이 있어. 중앙에서 ‘한 번만 설정하면 끝’인 기능은 만들기 쉽지만, 그 기능이 곧 네트워크의 병목이 될 수 있어. 봇 정책을 특정 회사에 맡기는 건 다시 그 생태계에 의존하는 일이야. 분산 시스템에서는 정책 선언도 분산되고, 각 피어가 스스로 확인할 수 있어야 해.
예를 들어 콘텐츠 제공자가 ‘학습용 봇은 허용한다’는 의도를 서명된 매니페스트(manifest)로 흘려보내고, 접근하는 에이전트가 그 서명을 검증하는 방식이라면 중앙 동기화 없이도 비슷한 효과를 낼 수 있어. 물론 이건 추정이고 실제 구현 난이도는 만만치 않아. 정체성, 평판, 철회 같은 문제가 함께 따라붙지.
결국 이번 소식이 던지는 질문은 ‘봇 정책을 어디에서 합의할 것인가’야. 클라우드플레어는 정적 파일 관리라는 오래된 문제를 ‘동기화’로 해결했지만, 그 합의 지점을 여전히 중앙 서버에 뒀어. 피투피 생태계는 반대로 가야 한다고 봐. 봇 정책을 콘텐츠와 함께 이동시키고, 피어가 직접 서로에게 정책을 증명하는 방향이 더 자연스러워.
시장에선 중앙 인프라가 먼저 편의를 제공하고, 이후 분산형 대안이 그 편의를 따라잡는 패턴이 반복돼 왔어. 이번 기능도 그런 흐름의 한 단계로 보는 게 맞아. 우리는 봇을 막는 규칙보다, 서로 다른 정책을 가진 피어가 안전하게 협상하는 프로토콜에 더 주목해야 해.
댓글