자체 호스팅 사이트를 AI 에이전트에 대비시키는 방법

AI 크롤러 트래픽을 다룬 Hacker News 스레드에서 한 호스팅 관리자가 운영자 입장에서 겪는 부하를 설명했습니다. "꽤 공격적인 AI 봇 6종쯤"이 주기적으로 상품 옵션 페이지나 카테고리 페이지에 갇혀 초당 약 1건꼴로 때리기 시작하는데, 그 사이트는 "페이지 한 번 로드에 왕복 1초가 통째로 걸릴 수 있고(대부분 MySQL에서 소모)" 하는 곳이었습니다. 같은 댓글에 적힌 누적 효과는 "사이트가 매일같이 Slashdot 효과를 겪는 것에 가깝다"였습니다.

웹사이트를 AI 에이전트에 대비시키는 일은 무엇보다 용량 문제입니다. 그래서 여기서 할 일의 대부분은 서버 설정이고 콘텐츠 전략은 아주 일부입니다. 이 트래픽의 쓸모 있는 특성은 대부분 익명이 아니라는 점입니다. 트래픽을 만드는 회사들이 크롤러 이름을 공개하고, 각각의 용도를 문서화하며, 끄는 방법까지 알려줍니다. 이어지는 내용은 무엇을 설정할지, 각 수단이 실제로 무엇을 강제하는지, 그리고 제가 건너뛸 두 가지, 즉 llms.txt 게시와 AI용 schema 마크업 추가에 관한 것입니다.

요약

• AI 트래픽은 보통 학습, AI 검색 인덱싱, 사용자 요청에 따른 가져오기로 나뉩니다. OpenAI와 Anthropic은 이 용도별로 별도의 토큰을 제공하므로 각각 따로 제어할 수 있습니다. 반면 다목적 크롤러 중에는 여러 역할을 하나의 정체성으로 묶은 것도 있습니다.
• OpenAI, Anthropic, Perplexity, Common Crawl은 자동 크롤러에 대한 robots.txt 제어 방법을 문서로 공개합니다. 예외는 사용자 요청으로 동작하는 페처입니다. Anthropic은 Claude-User에도 robots.txt를 적용하고, OpenAI는 ChatGPT-User에는 규칙이 적용되지 않을 수 있다고 밝히며, Perplexity-User는 대체로 이를 무시합니다.
• robots.txt 파일은 동의를 구하는 장치이지 접근 제어가 아닙니다. RFC 9309은 이 파일에 자체적인 강제력을 부여하지 않습니다. 규칙을 지키는 봇은 이를 존중해 여러분의 부하를 줄여 줄 수 있지만, 지키지 않는 트래픽을 늦추거나 멈출 수는 없습니다.
• Ahrefs 애널리틱스 고객사의 도메인 137,210개를 통틀어, 게시된 llms.txt 파일의 97%가 2026년 5월 한 달간 요청을 단 한 건도 받지 못했습니다. 원한다면 하나 올려도 되지만, 그 주위에 도구를 만들지는 마세요.
• 구조화 데이터는 기존 검색 기능을 뒷받침하는 자리에 그대로 두세요. 다만 구글 문서는 자사 AI 기능에 특별한 스키마나 AI용 텍스트 파일이 필요하지 않다고 밝히고 있습니다.
• OpenAI, ClaudeBot, PerplexityBot, CCBot이 읽기를 원하는 핵심 콘텐츠는 서버에서 렌더링하세요. Vercel의 측정에 따르면 이 크롤러들은 JavaScript를 실행하지 않습니다. Googlebot을 통한 Gemini와 AppleBot은 예외입니다.
• 협조적인 robots.txt 규칙 너머의 강제력은 리버스 프록시, 직접 운영하는 WAF, 그리고 작업 증명 챌린지 뒤편에 있습니다. 비용 순서도 이 순서입니다.

이 글이 다루지 않는 것

여기서 다루는 것은 에이전트가 방문하는 사이트이지, 에이전트와 거래하는 사이트가 아닙니다. 인접한 네 가지 주제는 다루지 않습니다.

• 에이전트 기반 커머스와 결제 흐름. 다른 종류의 사이트에 해당하는 다른 문제입니다.
• 학습 데이터를 둘러싼 법적, 저작권 논쟁. 이는 서버 설정이 아니라 사업적 판단의 문제입니다.
• WebMCP 구현 실습. 이 표준은 아직 오리진 트라이얼 단계이기 때문입니다.
• 아래의 Cloudflare 단원 하나를 제외한 CDN별 설정.

어떤 AI 크롤러가 내 사이트를 두드리고 있나

GPTBot과 ClaudeBot은 모델 학습에 쓰일 수 있는 콘텐츠를 수집합니다. OAI-SearchBot과 Claude-SearchBot은 AI 검색과 검색 결과 제공을 담당합니다. ChatGPT-User와 Claude-User는 사용자의 행동에 따라 페이지를 가져옵니다. 일부 업체는 이 역할을 분리해 두었지만, 웹의 모든 크롤러가 하나의 목적에 깔끔하게 대응되는 것은 아닙니다.

준수 여부의 실제 그림은 흔한 요약이 암시하는 것보다 정밀합니다. Anthropic의 크롤러 문서 에서는 ClaudeBot, Claude-User, Claude-SearchBot이 robots.txt를 따른다고 밝힙니다. OpenAI의 봇 문서 에서는 자사 자동 크롤러가 독립적인 제어 수단을 쓴다고 하면서도, ChatGPT-User에는 robots.txt 규칙이 적용되지 않을 수 있다고 밝힙니다. 그 요청은 사람이 시작하기 때문입니다. Perplexity의 크롤러 문서 도 비슷하게 구분합니다. PerplexityBot은 웹마스터의 제어를 따르지만 Perplexity-User는 대체로 robots.txt를 무시합니다. 그러니 "AI 봇은 robots.txt를 무시한다"는 뭉뚱그린 주장은, 파일을 존중하는 문서화된 크롤러와 업체마다 동작이 다른 사용자 요청 페처, 그리고 아예 자기를 밝히지 않는 스크레이퍼를 한데 뒤섞는 셈입니다.

아래 표는 집필 시점 기준입니다. 새 토큰은 어떤 글도 따라잡을 수 없는 속도로 등장하므로, 유통기한이 짧은 출발점 지도로 여기시기 바랍니다.

AI 크롤러를 위한 robots.txt 규칙 작성

RFC 9309 에는 robots.txt의 규칙이 접근 권한 부여의 한 형태가 아니라고 명시되어 있습니다. IETF는 2022년 9월에 문법, 파싱, 캐싱을 표준화했을 뿐, 이 파일을 강제 수단으로 바꾸지는 않았습니다. 실제로 문제가 되는 세부 사항은 문법 아래에 있습니다. 파일은 UTF-8로 인코딩해야 하고, 파서는 최소 500키비바이트를 처리해야 하며, 지시문이 충돌하면 가장 구체적인 경로 일치가 이깁니다. 규칙이 파일의 어느 위치에 있는지는 아무 상관이 없습니다.

AI 봇용 robots.txt는 이미 쓰고 있는 것과 같은 파일, 같은 문법을 씁니다. 달라지는 것은 토큰 목록뿐입니다. 규칙을 의도별로 정리해 두면 업체 구성이 바뀌어도 오래갑니다. 반대하는 대상이 학습이라면, 학습용 토큰을 차단하고 인덱서는 그대로 두십시오.

# Block training, keep AI search indexing
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

표에 이름이 나온 모든 토큰에 사이트 전체 거부 신호를 보내고 싶다면, 하나의 규칙 아래로 묶으십시오. Disallow를 열한 번 반복할 필요는 없습니다.

# Send a site-wide opt-out signal to named AI tokens
User-agent: GPTBot
User-agent: OAI-SearchBot
User-agent: ChatGPT-User
User-agent: OAI-AdsBot
User-agent: ClaudeBot
User-agent: Claude-User
User-agent: Claude-SearchBot
User-agent: PerplexityBot
User-agent: Perplexity-User
User-agent: Google-Extended
User-agent: CCBot
Disallow: /

그래도 이것은 보편적인 차단이 아닙니다. Anthropic은 Claude-User에 robots.txt를 적용하지만, OpenAI는 ChatGPT-User에 규칙이 적용되지 않을 수 있다고 밝히고, Perplexity-User는 대체로 무시합니다. 이런 사용자 요청 기반 가져오기를 단지 만류하는 데 그치지 않고 확실히 막아야 한다면, 그 결정을 프록시나 WAF에서 강제하십시오.

Google-Extended는 가장 자주 오해받는 토큰이며, 검색 트래픽이 매출을 책임지고 있다면 이 구분은 중요합니다. Google의 크롤러 문서 에서는 이를 독립적인 제품 토큰으로 설명합니다. 크롤링한 콘텐츠를 검색 밖에서 Gemini 학습과 그라운딩에 쓸 수 있는지를 제어하며, 사이트의 Google 검색 포함 여부나 순위에는 영향을 주지 않는다고 밝힙니다. 이를 차단해도 Googlebot의 검색 동작은 건드리지 않습니다.

토큰 목록을 손으로 최신 상태로 유지하는 일은 오후를 보내기에 좋은 방법이 아닙니다. 커뮤니티가 관리하는 ai.robots.txt 저장소 저장소는 AI 사용자 에이전트를 추적하고 robots.txt, nginx, Caddy, HAProxy, Lighttpd, Apache용 설정을 생성해 줍니다. Apache 운영자라면 생성된 블록을 기존의 디렉터리 단위 .htaccess 규칙 옆에 두면 됩니다.

팁: user-agent 문자열을 믿지 마세요. 그것은 헤더일 뿐이고, 헤더는 공짜로 위조됩니다. Common Crawl의 CCBot 문서 는 일부 크롤러가 자신을 CCBot이라고 사칭한다고 경고합니다. IPv4라면 다음 도메인 아래에서 정방향으로 확인된 역 DNS로 검증하십시오. *.crawl.commoncrawl.orgIPv6라면 Common Crawl이 공개한 IP 대역을 쓰십시오. 그쪽은 아직 역 DNS를 지원하지 않기 때문입니다. 위에 언급한 각 업체 페이지 역시 나머지 크롤러들의 현재 IP 대역을 공개합니다. 이는 해당 업체들에 대해 문서화된 검증 경로이지, AI 크롤러 일반의 속성은 아닙니다.

llms.txt는 효과가 있을까?

현재 근거로 보면 거의 아무것도 하지 않습니다. llms.txt는 사이트 루트에 두자고 제안된 평문 파일로, 언어 모델에 콘텐츠의 정제된 요약을 제공합니다. 만들어 올리는 비용은 싸지만, 지금의 근거로는 여기에 투자할 이유가 거의 없고, 구글 문서 역시 자사 AI 검색 기능에는 필요하지 않다고 밝히고 있습니다.

형식은 아주 단순합니다. llms.txt 제안 은 2024년 9월에 나왔고, 위치는 /llms.txt이며, 사이트나 프로젝트 이름을 담은 H1 하나만이 유일한 필수 항목입니다.

결론은 측정 데이터에서 나옵니다. 도메인 137,210개를 다룬 Ahrefs 연구 에 따르면 측정 대상 도메인의 28%가 llms.txt 파일을 게시했고, 그중 97%는 2026년 5월에 요청을 하나도 받지 못했습니다. 실제로 들어온 요청 가운데 19.5%가 이름이 알려진 AI 도구에서 온 것이었습니다. Ahrefs는 파일을 가져갔다는 사실이 실제로 사용했다는 증거는 아니라고도 경고합니다.

그 데이터에 대한 제 해석은 이렇습니다. llms.txt는 그것이 겨냥한 시스템들이 널리 받아들이지 않은 관행에 거는 베팅입니다. 루트 디렉터리를 깔끔하게 두는 걸 좋아한다면 올리세요. 하지만 그 주위에 생성 파이프라인을 만들지 말고, 배포의 차단 단계로 만들지도 말고, 이것을 순위나 인용의 지렛대라고 파는 사람은 근거보다 한참 앞서 나간 것으로 보시기 바랍니다.

핵심 요점: Ahrefs 연구에서 게시된 llms.txt 파일의 97%는 2026년 5월에 요청을 전혀 받지 못했습니다.

페이지를 기계가 읽을 수 있게 만들기

Vercel의 크롤러 측정 에 따르면 OpenAI의 크롤러들, ClaudeBot, PerplexityBot, Meta-ExternalAgent, Bytespider, CCBot은 JavaScript를 실행하지 않습니다. Googlebot을 통한 Gemini와 AppleBot은 실행합니다. 렌더링하지 않는 크롤러에게는 클라이언트 하이드레이션 이후에만 나타나는 콘텐츠가 보이지 않으므로, 중요한 것은 모두 서버에서 렌더링하십시오. 마크업은 더 쉬운 문제이고, 이에 대한 구글 자신의 안내는 이례적으로 직설적입니다.

"이 기능들에 나타나기 위해 새로운 기계 판독용 파일이나 AI용 텍스트 파일, 마크업을 만들 필요는 없습니다. 추가해야 할 특별한 schema.org 구조화 데이터도 없습니다."

Google Search Central의 AI 가이드

FAQ 스키마를 옹호하며 종종 인용되는 40% 노출 상승치는 GEO 논문 KDD 2024에 채택된 논문에서 나왔습니다. 논문은 최대 40%의 개선을 보고하지만, 실험한 개입은 인용, 인용문, 통계, 전문 용어, 매끄러운 문장 같은 콘텐츠 변경에 집중되어 있으며 FAQPage나 그 밖의 어떤 Schema.org 마크업도 아닙니다. 숫자 자체는 맞습니다. 그것을 스키마 마크업에 갖다 붙인 것이 틀렸습니다.

구조화 데이터는 기존 검색 기능을 뒷받침하고 눈에 보이는 페이지와 일치하는 자리에 두십시오. 구글은 자사 AI 기능의 자격이 일반적인 검색 색인을 거치며 별도의 마크업 요건은 없다고 밝힙니다. 다만 그것이 AI 인용을 움직인다는 근거는 아직 없습니다.

robots.txt로 부족할 때: 서버에서의 속도 제한과 WAF

지시문은 따르기로 한 봇들에게만 통합니다. 앞서 언급한 그 Hacker News 스레드에서는 여러 운영자가 그렇지 않은 트래픽을 묘사했습니다. 요청을 거대한 IP 블록 풀에 흩뿌리고 사용자 에이전트를 돌려가며 평범한 방문자처럼 보이게 만드는 크롤러들인데, 이는 단순한 IP별 제한도 사용자 에이전트 매칭도 똑같이 무력화합니다. 이는 커뮤니티의 증언으로 받아들이십시오. 스레드에서 측정치를 공개한 사람은 없습니다. 다만 robots.txt가 애초에 닿을 수 있도록 만들어지지 않은 집단을 정확히 묘사하고 있습니다.

그 사다리를 오르기 전에, 아직 협조 중인 트래픽에 쓸 수 있는 더 값싼 수단이 있습니다. 속도를 늦추는 것입니다.

User-agent: ClaudeBot
Crawl-delay: 1

팁: 차단하기 전에 먼저 속도를 조이십시오. Anthropic 문서는 ClaudeBot에 Crawl-delay를 지원한다고 밝힙니다 . 덕분에 부담은 크지만 예의 바른 크롤러를 늦추면서 계속 받아들일 수 있습니다. 같은 페이지는 IP 차단이 지속적인 거부 수단이 아니라고도 말합니다. 두 가지 모두 Anthropic에만 해당하는 이야기이며, Crawl-delay 는 보편적인 지시문이 아니므로, 각 업체의 문서를 먼저 확인하십시오.

그 너머는 전부 직접 운영해야 하는 강제 수단이며, 비용과 효과가 함께 올라가는 세 단계로 나뉩니다. 각 단계는 무언가를 얻는 대신 무언가를 내줍니다.

1단계: 리버스 프록시 지시문과 속도 제한

AI 크롤러 속도 제한은 리버스 프록시에서 시작됩니다. 스택에서 요청을 가장 먼저 보는 지점이자, 애플리케이션이나 데이터베이스가 일을 시작하기 전에 요청을 늦출 수 있는 지점입니다. NGINX의 속도 제한 문서 는 키가 비어 있는 요청은 집계되지 않는다고 명시합니다. 따라서 map 구문을 쓰면 조이고 싶은 크롤러 토큰에만 속도 제한 키를 부여하고, 일치하지 않는 요청은 다음 영역 밖에 둘 수 있습니다. limit_req_zone.

# /etc/nginx/nginx.conf, inside the http block
map $http_user_agent $ai_rate_key {
    default              "";
    ~*GPTBot             $binary_remote_addr;
    ~*OAI-SearchBot      $binary_remote_addr;
    ~*ClaudeBot          $binary_remote_addr;
    ~*Claude-SearchBot   $binary_remote_addr;
    ~*PerplexityBot      $binary_remote_addr;
    ~*CCBot              $binary_remote_addr;
}

limit_req_zone $ai_rate_key zone=ai_slowlane:10m rate=20r/m;

# /etc/nginx/sites-available/example.conf, inside the server block
location / {
    limit_req zone=ai_slowlane burst=10 nodelay;
    proxy_pass http://127.0.0.1:8080;
}

조정해야 할 값 쌍은 burst=10 nodelay입니다. 평균 속도를 넘는 요청은 버스트를 즉시 소진할 수 있고, 그마저 넘어선 요청은 기본값으로 503 을 돌려받습니다. 너무 빡빡하게 잡으면 정상적인 크롤러를 크롤링 도중에 튕겨내게 되는데, 이는 장애보다 진단이 오래 걸리는 문제입니다. Caddy는 같은 두 가지 개념을 matcher와 handler로 표현합니다. 둘 중에서 고르는 중이라면, 설정 파일을 나란히 비교한 글이 합성 벤치마크의 처리량 숫자보다 유용합니다.

이 단계의 한계는 저속 차선이 여전히 선언된 사용자 에이전트에 의존한다는 점입니다. Chrome 사용자 에이전트를 걸친 스크레이퍼는 이 크롤러 전용 키를 완전히 우회합니다. 그런 트래픽을 잡으려면 IP나 경로 행동에 기반한 더 넓은 속도 제한, 또는 아래의 WAF 단계가 필요합니다.

2단계: 직접 운영하는 웹 애플리케이션 방화벽

WAF는 판단 근거를 헤더 하나에서, 요청 패턴과 경로와 속도를 함께 읽는 규칙 집합으로 옮깁니다. 트래픽이 스스로를 밝히지 않게 된 순간부터 필요한 것이 바로 이것입니다. 자기 서버에서 돌리면 규칙과 로그가 자기 디스크에 남아, 새벽 세 시에도 grep할 수 있습니다. BunkerWeb 이 그런 프로젝트 하나이고, SafeLine 가 또 하나입니다. 호스트가 프로젝트의 아키텍처와 자원 요구 사항을 충족하면 둘 다 VPS에서 돌아갑니다. 설치 수고를 덜어드리려고 두 가지 모두 원클릭 버전을 제공하지만, 패키징이 흥미로운 부분은 아닙니다.

그것이 이 단계의 비용이기도 합니다. 규칙에는 유지 보수가 필요하고, 집요한 스크레이퍼를 잡을 만큼 촘촘하게 조인 규칙은 언젠가 사람도 잡습니다. SafeLine의 Monitor, Balanced, Strict 모드는 그 절충을 명시적으로 드러냅니다. WAF가 자동으로 403 응답을 돌려주게 하기 전에, 오탐을 찾아낼 만큼 충분히 오래 트래픽을 관찰하는 것부터 시작하십시오.

3단계: 작업 증명 챌린지

Anubis는 신원 확인 문제를 통째로 건너뜁니다. 챌린지를 걸기로 한 트래픽에 대해, 오리진이 응답하기 전에 그 요청이 약간의 연산 비용을 치르게 만듭니다. 정책 시스템은 일치 규칙에 따라 요청을 허용하거나 거부하거나 챌린지에 걸 수도 있습니다. 프로젝트 README는 이를 스크레이퍼 봇으로부터 상위 리소스를 보호하기 위해 챌린지를 중심으로 만든 Web AI Firewall Utility라고 부릅니다. 모든 봇이 자기 신원을 정확히 밝힐 것을 요구하지 않고도 작동합니다.

프로젝트 스스로 이 접근을 핵무기 같은 대응이라 부르는데, 그 유보는 정당합니다. 그 비용은 정책이 챌린지를 거는 모든 트래픽에 부과되며, 규칙이 지나치게 넓으면 느린 기기를 쓰는 사람이나 정상적인 크롤러까지 포함될 수 있습니다. 이 단계는 정말로 적대적인 트래픽을 위해 아껴 두십시오. 열성적인 크롤러는 대개 속도 제한으로 풀 문제이고, 속도 제한은 이미 갖추고 있습니다.

폭주에 대비한 사양 산정

크롤러 부하는 대개 몰아쳐서 들어오지만, 그것이 CPU를 먹는지 데이터베이스를 먹는지 I/O를 먹는지는 애플리케이션과 크롤링되는 URL에 달려 있습니다. 위의 WordPress 사례에서 운영자는 1초의 페이지 처리 시간 대부분을 MySQL로 추적해 냈습니다. 즉 그 특정 사건은 트래픽 문제의 옷을 입고 나타난 데이터베이스 병목이었습니다.

이로써 사양 산정은 자원 배분의 문제가 되는데, 그것도 불편한 문제입니다. 여유분에는 계속 돈을 내지만, 그 값어치는 당신이 통제할 수 없는 급증 때에만 드러납니다. 그래도 급증에 대비해 확보하십시오. BunkerWeb이 애플리케이션 및 데이터베이스와 같은 호스트를 쓴다면, 8GB를 스택 전체에 대한 권장치로 받아들이지 마십시오. BunkerWeb의 퀵스타트 가이드는 테스트용이거나 서비스가 아주 적은 배포에는 2 vCPU와 8 GB RAM을, 여러 서비스를 보호하는 프로덕션 환경에는 최소 4 vCPU와 16 GB RAM을 권장합니다. 그 위에 애플리케이션 자체의 최대 CPU 사용량, 데이터베이스 메모리, I/O 여유분을 더하십시오.

요청 처리나 쿼리 실행이 CPU에 묶여 있을 때는 클럭이 높은 코어가 도움이 되고, 동시에 더 많은 작업을 진행해야 할 때는 코어 수가 도움이 됩니다. 크롤러 트래픽만 보지 말고 최대 동시성, p95 응답 시간, 데이터베이스 CPU와 I/O 대기, 캐시 미스율을 기준으로 사양을 잡으십시오.

이 계층을 직접 운영하려면 그 아래의 머신에 두 가지가 필요합니다. 하나는 root 권한입니다. 위의 모든 수단이 결국 직접 편집하는 설정 파일과 재시작하는 서비스이기 때문입니다. 다른 하나는 규칙이 제 일을 하는 동안 폭주가 사이트를 무너뜨리지 않을 만큼의 여유입니다. 이를 위해 서버 사양을 잡거나 옮기는 중이라면, Cloudzy의 Linux VPS Linux VPS는 이 스택이 요구하는 root 권한을 제공하며, 장기 사양을 확정하기 전에 프록시와 WAF 구성을 시험해 볼 수 있게 해 줍니다.

루트 액세스, NVMe, AMD EPYC 성능을 갖춘 Linux VPS에서 개발하세요.

Linux 요금제 보기

Cloudflare의 새로운 AI 트래픽 기본값

Cloudflare는 AI 트래픽을 Search, Agent, Training 세 범주로 나눴습니다. 2026년 7월 AI 트래픽 발표2026년 9월 15일부터, Cloudflare에 새로 들어오는 도메인은 광고를 노출하는 페이지에서 Training과 Agent가 기본적으로 차단되고 Search는 계속 허용됩니다. 기존 고객은 그전에 설정을 바꿀 수 있으며, 이 제어 기능은 모든 요금제에서 제공됩니다.

여기서 빌려올 대목은 Cloudflare가 자기 발표문에서 스스로 짚은 복잡한 문제입니다. Cloudflare의 분류에서 Googlebot, Applebot, Bingbot은 각각 검색 업무와 학습 업무를 겸하고 있어서, Training 범주를 차단한 고객은 그 크롤러들까지, 그리고 지키고 싶었던 검색 동작까지 함께 차단하게 됩니다. 다목적 크롤러를 하나의 역할만 가진 것처럼 다루는 모든 범주 단위 통제에는 똑같은 함정이 도사리고 있습니다.

사이트가 Cloudflare 뒤에 있지 않다면, 이 가운데 어느 것도 당신이 당길 수 있는 레버가 아닙니다. 그래도 다가오고 있다는 사실은 알아 두십시오. 9월에 트래픽 패턴이 움직일 것이기 때문입니다. 당신의 수단은 여전히 robots.txt 토큰과 앞서 다룬 프록시 계층입니다.

WebMCP: 지켜볼 만하지만, 아직 만들어 붙일 때는 아니다

WebMCP는 Model Context Protocol의 브라우저 쪽 짝입니다. Model Context Protocol은 에이전트가 추측하는 대신 구조화된 도구를 호출하도록 하는 규약입니다. Chrome의 WebMCP 오리진 트라이얼 발표는 목표를 곧바로 짚습니다. 에이전트가 버튼이나 입력 필드가 무슨 일을 하는지 추측하게 두는 대신, 사이트가 구조화된 함수와 주석 달린 컨트롤을 노출해 에이전트가 곧장 호출하게 하자는 것입니다.

에이전트에게 당신의 사이트에서 읽는 것 말고 할 일을 주려는 첫 번째 그럴듯한 시도이고, 그래서 이 글에서 가장 흥미로운 대목입니다. 동시에 실험적이고 미완성입니다. 2026년 6월에 열린 Chrome 149 오리진 트라이얼입니다. 명세를 지켜보십시오. 아직 프로덕션 의존성을 만들지 말고, 용량 계획에서도 빼 두십시오.

자주 묻는 질문

User-agent: GPTBot
Disallow: /

grep -ohE 'GPTBot|ClaudeBot|CCBot|PerplexityBot|OAI-SearchBot|ChatGPT-User' \
  /var/log/nginx/access.log | sort | uniq -c | sort -rn