클라우드플레어가 봇 선호 동기화(Bot Preference Sync)라는 새 기능을 블로그로 소개했다. 해당 글을 보면 이 기능은 robots.txt 파일을 검색, 에이전트, 트레이닝 용도의 AI 봇 정책과 자동으로 정렬해 준다. 즉 사이트 운영자가 robots.txt를 직접 편집하지 않아도, 봇 접근 정책을 한 번 정하면 여러 채널에 같은 기준이 적용되는 방식이다.
여기서 주목할 문장은 ‘정적 파일을 유지하지 않고 봇 접근을 관리한다’는 요지다. 전통적으로 봇 정책은 루트 도메인의 robots.txt라는 정적 파일에 적었다. 그런데 지금은 검색 봇, AI 학습 봇, 에이전트 봇의 목적이 서로 달라서 같은 파일 하나로는 감당하기 어렵다. 클라우드플레어는 그 문제를 정책을 선언적으로 관리하고 자동 동기화하는 방식으로 푼다.
처음에는 그냥 CDN(콘텐츠 전송 네트워크) 부가 기능처럼 보인다. 하지만 나는 이 기능을 ‘정책을 여러 지점에 전파하는 분산 상태 동기화 문제’로 읽는다. P2P(동등 계층) 네트워크에서는 콘텐츠가 중앙 서버 대신 노드 여러 곳에 복제된다. 같은 파일이라도 노드마다 다른 접근 조건이 붙을 수 있고, 복제가 늘수록 정책이 어디에 어떻게 반영됐는지 추적하기가 힘들어진다.
중앙 관리형 서비스는 정책을 한 곳에서 정의하고 전파하기에 편하다. 그러나 P2P 세계에서는 이 전파가 곧 합의 문제가 된다. 어떤 노드는 오래된 robots.txt를 캐시하고 있고, 어떤 노드는 새 정책을 이미 받았을 수 있다. 이번 기능이 해결하는 ‘한 번 선언하면 여러 표면에 동기화’라는 개념은, 분산 네트워크에서 정책 버전을 정렬하는 일과 본질적으로 닮아 있다.
이 기능은 분명 편리하다. 정적 robots.txt를 관리하는 대신, 운영자는 검색, 에이전트, 트레이닝 같은 정책 항목별로 허용 수준을 지정하고 나머지는 클라우드플레어가 맞춰 준다. 봇마다 다른 규칙을 일일이 파일 문법으로 쓰던 수고가 줄어드는 건 분명한 진보다.
그런데 나는 그 편리함이 다시 중앙화의 씨앗일 수 있다고 본다. 정책의 단일 원본이 클라우드플레어의 설정 화면 안에 들어가면, P2P 서비스처럼 여러 주체가 콘텐츠를 나눠 가진 구조에서는 그 화면이 통제 불가능한 외부 종속점이 된다. 봇 접근 정책은 데이터 평면과 분리되어야 하고, 이상적으로는 노드 간 서명된 정책 교환 같은 방식으로 전파될 수 있어야 한다. 중앙 솔루션이 편하다는 사실은, 분산 정책 전파가 아직 제대로 해결되지 않았다는 방증이기도 하다.
PonsLink와 PonsWarp는 피투피 여정의 가장 초기 MVP(최소 기능 제품)다. 데모 수준의 코드와 운영 감각으로 배운 것 중 하나는, ‘누가 무엇에 접근할 수 있는가’를 정책으로 분리하는 일이 항상 마지막에 어려워진다는 점이다. 연결을 만들고 메시지를 주고받는 과정에서 보면, 어느 노드가 어떤 메시지를 받을 수 있는지, 어떤 콘텐츠를 캐시해도 되는지가 라우팅과 얽혀서 금방 지저분해진다.
클라우드플레어의 이번 발표는 그 문제를 다시 상기시킨다. 접근 결정과 그 결정의 전파는 서로 다른 층이다. 봇 정책을 한 번만 선언하고 여러 서비스에 맞추는 방식은, 우리가 P2P 네트워크에서 노드 간 정책을 동기화할 때도 참고할 만한 설계다. 다만 그 원본이 특정 회사의 대시보드에 남는 한, 분산 시스템이 원하는 자율성까지 얻었다고 말하긴 이르다.
댓글