핵심 요약
- 앤트로픽 크롤러는 7만900번 긁고 한 번 돌려보냅니다
- llms.txt 파일의 97%는 요청을 한 건도 못 받았습니다
- 작동하는 층위는 페이지가 아니라 엔드포인트입니다
- 호출 가능한 엔드포인트 목록부터 적어 보십시오
웹사이트를 만드는 일의 전제는 오랫동안 하나였습니다. 사람이 화면을 열고, 읽고, 클릭한다는 것. 2026년 현재 그 전제가 깨지고 있습니다. 사이트를 여는 쪽이 사람만이 아니고, 사이트에서 무언가를 실행하는 쪽도 사람만이 아닙니다.
변화는 두 방향에서 동시에 일어납니다. 하나는 AI 크롤러가 웹 콘텐츠를 가져가는 방식이고, 다른 하나는 AI 에이전트가 기업 시스템에 직접 접속해 거래를 끝내는 방식입니다. 앞쪽은 이미 측정된 문제이고, 뒤쪽은 이미 규격이 나온 문제입니다.
웹사이트의 방문자 구성이 바뀌었다
클라우드플레어(Cloudflare)는 자사 네트워크를 지나는 요청으로 '크롤 대 리퍼럴 비율(crawl-to-refer ratio)'을 측정해 공개합니다. 특정 플랫폼의 사용자 에이전트가 HTML 콘텐츠를 요청한 횟수를, 같은 플랫폼이 리퍼러(Referer) 헤더에 찍힌 채 보내준 방문 횟수로 나눈 값입니다. 페이지를 몇 번 긁어가는 대가로 방문자를 몇 명 돌려보내는지를 재는 지표입니다.
2025년 6월 19일부터 26일까지의 관측에서 앤트로픽(Anthropic)의 비율은 70,900대 1이었습니다. HTML 페이지를 7만 번 넘게 가져가는 동안 사이트로 돌아온 방문은 한 건이었다는 뜻입니다. 클라우드플레어는 같은 글에서 이 수치를 두고 "이 비율들은 인터넷에서 콘텐츠를 발행하는 일의 지속 가능성에 직접 영향을 준다"고 적었습니다.
검색엔진과 웹사이트 사이에 있던 교환 관계 — 색인을 허용하는 대신 트래픽을 받는 구조 — 가 성립하지 않는 구간이 생겼습니다. 콘텐츠를 잘 쓰고 잘 노출시키는 것으로 방문자를 확보하던 설계가 이 구간에서는 작동하지 않습니다.
llms.txt가 보여준 것: 파일을 놓는 것만으로는 아무 일도 일어나지 않는다
이 문제에 대한 업계의 첫 반응은 규약 파일이었습니다. 사이트 루트에 llms.txt를 두어 AI가 읽어야 할 문서 구조를 알려주자는 제안입니다.
오리지널리티에이아이(Originality.ai)가 300만 개 이상의 웹사이트를 2025년 6월부터 2026년 5월까지 추적한 결과, llms.txt 파일은 4,088개에서 36,120개로 8.8배 늘었습니다. llms-full.txt는 23개에서 2,463개로, ai.txt는 4개에서 397개로 늘었습니다.
그런데 에이치레프스(Ahrefs)가 2026년 5월 137,000개 도메인의 서버 로그를 분석한 결과는 다릅니다. llms.txt 파일의 97%가 그달 단 한 건의 요청도 받지 못했습니다. 실제로 들어온 요청 중 AI 검색·수집 봇의 비중은 1.1%였고, 가장 많이 이 파일을 읽어간 것은 21.7%를 차지한 SEO 감사 도구였습니다.
플랫폼들의 입장도 분명합니다. 구글은 llms.txt가 검색 노출이나 순위에 "부정적으로도 긍정적으로도 영향을 주지 않는다"며 구글 검색에 "필수가 아니다"라고 밝혔습니다. 오픈AI(OpenAI)와 앤트로픽은 크롤러 관리에 대해 사이트 운영자를 robots.txt로 안내하고, llms.txt는 개발자 문서에서만 언급합니다.
파일 하나를 올려두는 대응은 측정 가능한 결과를 내지 못했습니다. 1년 사이 8.8배로 늘어난 그 파일들의 대부분은 아무도 읽지 않았습니다.
실제로 작동하는 층위는 페이지가 아니라 엔드포인트
에이전트가 실제로 쓰는 통로는 따로 만들어지고 있습니다. 그것도 문서가 아니라 API 규격의 형태로.
오픈AI와 스트라이프(Stripe)가 공동 관리하는 에이전틱 커머스 프로토콜(Agentic Commerce Protocol, ACP)은 2026년 4월 17일자 스펙을 최신 안정 버전으로 두고 있습니다. 아파치 2.0 라이선스의 공개 규격이며 현재 베타 상태입니다. 이 규격을 따르려는 판매자는 문서를 고치는 것이 아니라 두 개의 API를 구현합니다. 에이전틱 체크아웃 API와 위임 결제(Delegate Payment) API입니다. 4월 17일 변경 이력에는 장바구니, 상품 피드, 주문, 인증, 그리고 MCP가 함께 올라 있습니다.
스트라이프는 2025년 9월 29일 이 규격을 공개하면서, 판매자가 "개별 AI 에이전트마다 별도의 재고·결제 연동을 만들 필요가 없도록" 한 번만 표준에 맞추면 되게 하는 것이 목적이라고 설명했습니다. 챗GPT 안에서 결제가 끝나는 인스턴트 체크아웃은 엣시(Etsy) 판매자부터 시작해 쇼피파이(Shopify) 가맹점으로 확대되고 있습니다.
사내 시스템 쪽에는 MCP(Model Context Protocol)가 있습니다. 2024년 11월 앤트로픽이 공개한 이 규격은 현재 리눅스 재단(Linux Foundation) 산하 프로젝트로 운영됩니다. 특정 벤더의 것이 아니라는 뜻입니다.
주목할 것은 MCP의 2026년 로드맵이 무엇을 과제로 적어두었는가입니다. 네 가지 우선순위 중 하나가 '엔터프라이즈 준비'이고, 그 아래 열거된 항목은 "감사 추적, SSO 연동 인증, 게이트웨이 동작, 설정 이식성"입니다. 모델 성능이나 프롬프트 이야기가 아닙니다. 기업 시스템에 무언가를 붙일 때 늘 나오는 통합·인증·운영의 문제입니다.
에이전시가 채울 공백은 화면이 아니라 통제 장치
같은 시기의 조사 두 건이 그 공백의 크기를 보여줍니다.
컴플라이언스 기업 셸먼(Schellman)이 미국의 거버넌스 담당자 525명을 조사해 2026년 7월 29일 발표한 보고서에서, 응답자의 86%는 AI 에이전트를 시험 중이었고 그중 절반 가까이는 이미 프로덕션에 올려두었습니다. 90%는 AI 거버넌스에 예산을 배정했다고 답했고, 4분의 3가량은 AI 규정 준수 감사를 통과할 수 있다고 답했습니다. 그런데 자사 프로그램이 완전히 성숙했다고 답한 비율은 27%였습니다. 직원에게 실제로 공유되는 AI 이용 정책을 갖춘 곳은 64%에 그쳤습니다.
셸먼의 ISO·AI 부문 책임자 대니 마님보(Danny Manimbo)는 보고서에서 이렇게 정리했습니다. "개별 활동들을 규제 심사를 견디고 빠르게 바뀌는 AI 시스템의 속도를 따라갈 수 있는, 성숙하고 운영 가능한 프로그램으로 바꾸는 것이 과제다."
비용 쪽도 같은 모양입니다. 하네스(Harness)가 핀옵스·엔지니어링 리더 700명을 조사해 2026년 7월 29일 공개한 데이터에 따르면 AI에 쓰는 4달러 중 1달러가 낭비되고 있습니다. 절반이 넘는 조직에 AI 비용을 책임지는 담당자가 지정되어 있지 않았고, 예상치 못한 비용 급증의 원인을 몇 시간 안에 짚어낼 수 있는 곳은 5곳 중 1곳이었습니다. 대부분의 조직이 가격 체계가 서로 다른 세 곳 이상의 AI 제공사를 동시에 쓰고 있었습니다.
에이전트를 이미 돌리고 있는 조직이 절반인데, 그것을 통제할 장치를 갖춘 조직은 4분의 1입니다. 이 격차가 웹·디지털 에이전시가 실제로 팔 수 있는 것이 무엇인지를 규정합니다. 화면을 예쁘게 만드는 일이 아니라, 에이전트가 접근할 인터페이스를 정의하고 그 접근을 기록·인증·차단할 수 있게 만드는 일입니다. 사이트맵과 디자인 시안 자리에 접근 권한 목록과 감사 로그 설계가 들어옵니다.
한국 기업에는 무엇이 다른가
인용한 조사는 셸먼 525명, 하네스 700명 모두 미국 응답자 표본입니다. 조직 구조와 규제 환경이 다른 국내 기업에 비율을 그대로 대입할 수는 없습니다.
적용 시점도 다릅니다. ACP의 인스턴트 체크아웃은 미국 사용자와 미국 판매자부터 열렸고, 국내 커머스는 간편결제와 PG를 거치는 결제 구조가 달라 같은 방식이 곧바로 붙지 않습니다. 결제 쪽을 서둘러 손댈 이유는 아직 크지 않습니다.
반면 MCP는 지역 제약이 없습니다. 사내 데이터와 업무 시스템을 에이전트에 연결하는 층위는 지금 한국에서도 그대로 할 수 있는 일이고, 앞서 본 것처럼 그 층위의 난제는 모델이 아니라 인증·감사·설정 관리입니다. 국내 기업이 기성 솔루션 대신 자체 구축으로 기우는 흐름과도 맞물립니다. EY가 2026년 7월 미국 SVP급 이상 500명을 조사한 결과에서도 진행 중인 AI 투자를 가진 리더의 4분의 3이 기성 소프트웨어가 자사 IT 요구와 맞지 않는다고 답했습니다.
지금 점검할 것
에이전트 대응을 검토하는 조직이라면 다음 세 가지를 먼저 확인하는 편이 순서에 맞습니다.
- 자사 도메인에 들어오는 요청 중 자동화 트래픽의 비중과 그 출처. 어떤 AI 크롤러가 무엇을 얼마나 가져가는지 모르는 상태에서는 허용할지 막을지를 정할 근거가 없습니다.
- 에이전트가 접근할 수 있는 인터페이스의 목록. 문서가 아니라 실제로 호출 가능한 엔드포인트 기준으로 적어야 합니다. 목록이 비어 있다면 llms.txt를 올리는 것으로는 바뀌지 않습니다.
- AI 비용의 책임자가 지정되어 있는지. 지정되어 있지 않다면, 사용량이 늘어난 뒤에 원인을 찾는 일은 몇 시간이 아니라 몇 주가 걸립니다.
에이전트를 도입할지 말지는 이미 지난 질문입니다. 조사에 응한 조직의 86%가 이미 시험 중입니다. 남은 질문은 자사 시스템이 에이전트에게 어떻게 보이는지, 그리고 그 접근을 누가 통제하는지입니다.
출처: Cloudflare — The crawl before the fall… of referrals · llms.txt 채택률과 실제 요청 데이터(Originality.ai·Ahrefs) · Agentic Commerce Protocol 규격 · Stripe — Developing an open standard for agentic commerce · Model Context Protocol 2026 로드맵 · CIO Dive — Most US companies lack mature AI governance frameworks · CIO Dive — 1 in 4 dollars spent on AI goes to waste
