Agents.txt는 접근 제어가 아니에요

DreamHost는 이제 사이트가 자체 파일을 제공하지 않은 경우 Web Hosting 플랜에 기본 robots.txt와 agents.txt 파일이 자동으로 포함된다고 문서화하고 있어요.¹

이 작은 호스팅 세부 사항은 더 큰 변화를 보여줘요. 이제 웹사이트는 검색 크롤러, AI 크롤러, 그리고 추론 시점에 깔끔한 맥락을 찾는 어시스턴트라는 최소 3개의 대상에게 동시에 말해야 해요. 파일 이름만 보면 이 변화가 단정하게 정리된 것처럼 보여요. robots.txt는 자동화된 클라이언트가 무엇을 크롤링해도 되는지 알려줘요. llms.txt는 LLM에 엄선된 지도를 제공해요. agents.txt는 에이전트를 위한 정책을 암시해요. 하지만 이 파일들 중 어느 것도 운영자에게 보호받고 있다는 느낌을 주면 안 돼요.

Agents.txt는 접근 제어가 아니에요. 크롤러 파일은 공개 정책 힌트이자 발견 보조 수단으로 다루세요. 실제 제어는 여전히 서버 측 권한 부여, 봇 신원 검증, 속도 제한, 로그, 캐시 동작, 그리고 중요한 크롤러가 현재 파일을 실제로 봤다는 증거에서 나와요.

요약

Robots Exclusion Protocol 표준은 크롤러 규칙이 “접근 권한 부여의 한 형태가 아니다”라고 말해요.² Google도 robots.txt에서 허용하지 않은 URL이라도 다른 페이지가 해당 URL로 링크하면 Search에 나타날 수 있다고 경고해요.³ DreamHost의 봇 제어 문서도 robots 파일은 준수하는 검색 엔진을 향한 제안으로 작동하며, 악성 봇은 파일을 무시하거나 오해를 부르는 사용자 에이전트를 사용할 수 있다고 설명해요.¹

AI 크롤러는 정책 차원을 더 늘려요. OpenAI는 ChatGPT 검색용 OAI-SearchBot과 학습 관련 크롤링용 GPTBot을 구분하고, ChatGPT-User는 사용자가 실행한 동작을 나타내며 이때는 robots.txt가 적용되지 않을 수 있다고 말해요.⁴ Google은 Google-Extended에 별도의 HTTP 사용자 에이전트 문자열이 없고, Google Search 포함 여부가 아니라 학습과 근거 마련 선호를 위한 robots.txt 제품 토큰으로 작동한다고 설명해요.⁵ 이제 크롤러 제어 파일에는 단순한 허용 또는 차단 스위치가 아니라 목적 단위 정책이 필요해요.

호스트, 플랫폼, 에이전트 생태계가 기대한다면 agents.txt를 사용하세요. 추론 시점의 도구가 내 최고의 페이지를 이해하길 원한다면 llms.txt를 사용하세요. 주요 크롤러가 여전히 사용하므로 robots.txt는 정확하게 유지하세요. 그런 다음 서버 경계에서 요청을 검증하고 로그를 읽어야 해요. 텍스트 파일은 의도를 표현할 수 있어요. 신뢰할 수 없는 클라이언트를 멈출 수는 없어요.

핵심 요점

사이트 소유자에게: - 크롤 정책에는 robots.txt, AI가 읽기 쉬운 맥락에는 llms.txt, 에이전트 대상 힌트가 필요할 때만 agents.txt를 게시하세요. - 비공개 경로, 비밀 파일 이름, 내부 프롬프트, 민감한 경로를 어떤 공개 크롤러 파일에도 넣지 마세요. - 변경 후에는 로그를 확인하세요. 정책 파일은 올바른 크롤러가 가져가고 동작을 바꿀 때에만 의미가 있어요.

SEO와 AIO 팀에게: - 검색 노출, 학습 허용, 사용자 요청 가져오기를 분리하세요. - 검색 크롤러와 AI 답변 노출 영역처럼 원하는 봇의 허용 목록을 명확히 작성하세요. - 크롤러 파일을 사이트맵, 표준 URL, 스키마, llms.txt 검증과 함께 다루세요.

보안 팀에게: - 사용자 에이전트 문자열은 신원이 아니라 주장으로 다루세요. - 운영자가 지원하는 경우 reverse DNS나 게시된 IP 범위로 크롤러를 검증하세요. - 민감한 리소스 접근은 크롤러 예절이 아니라 인증, WAF 규칙, 애플리케이션 정책, 속도 제한으로 강제하세요.

Agents.txt로 무엇이 달라졌나요?

robots.txt는 수십 년 동안 존재해 왔어요. RFC는 서비스 소유자가 크롤러가 접근할 수 있는 URI를 판단할 수 있도록 robots.txt 파일을 제공한다고 정의해요.² 기본 파일 형태는 익숙해요.

User-agent: *
Disallow: /private-draft/
Sitemap: https://example.com/sitemap.xml

agents.txt는 다른 시점에 등장했어요. 이제 웹은 검색 엔진 크롤러만 받지 않아요. 학습 크롤러, 답변 엔진 크롤러, 광고 안전성 크롤러, 브라우저 어시스턴트의 가져오기, 사용자가 요청한 LLM 가져오기, 아카이브 크롤러, SEO 도구, 합법적인 크롤러 이름을 빌려 쓰는 스팸 봇까지 받아요.

DreamHost 문서가 중요한 이유는 적어도 하나의 주요 호스트에서 agents.txt를 틈새 아이디어가 아니라 기본 호스팅 동작으로 옮겨 놓았기 때문이에요. 해당 문서는 DreamHost가 Web Hosting 플랜에 기본 robots.txt와 agents.txt 파일을 자동으로 포함하며, 사이트 소유자가 사이트 루트에 사용자 지정 파일을 두면 어느 파일이든 덮어쓸 수 있다고 말해요.¹ 그렇다고 agents.txt가 강제 의미를 가진 표준이 되는 것은 아니에요. 다만 이 파일 이름이 실제 웹에서 더 자주 보이게 된다는 뜻이에요.

안전한 해석은 좁아야 해요.

파일 이름들은 서로 경쟁할 필요가 없어요. 함께 정책 묶음을 이뤄야 해요. 크롤러가 무엇을 요청해도 되는지, AI 시스템이 무엇을 읽어야 하는지, 에이전트가 무엇을 알아야 하는지, 서버가 실제로 무엇을 관찰했는지를 묶어서 봐야 해요.

Robots.txt는 여전히 중요하지만 보호 장치는 아니에요

팀이 크롤러 파일을 보안 경계로 사용할 때 문제가 생겨요.

RFC는 그 경계를 명확히 해요. 이 프로토콜은 자동화된 클라이언트에게 URI에 접근할 때 규칙을 존중하라고 요청하지만, 접근 권한을 부여하지는 않아요.² Google도 운영 측면에서 같은 말을 해요. 다른 페이지가 허용하지 않은 URL로 링크하면, Google은 차단된 페이지 내용을 크롤링하지 않더라도 URL 주소와 기타 공개 링크 정보를 발견하고 색인할 수 있어요.³ DreamHost는 robots 규칙이 준수하는 검색 엔진을 향한 제안으로 작동하며, 악성 봇은 파일을 무시하거나 거짓 사용자 에이전트를 사용할 수 있다고 경고해요.¹

이 사실들은 간단한 규칙으로 이어져요. 검색 결과에 복사되거나, 데이터셋에 스크랩되거나, LLM이 표시했을 때 피해가 될 만한 내용은 robots.txt, agents.txt, llms.txt 어디에도 넣지 마세요.

나쁜 크롤러 파일은 보호보다 노출을 더 많이 해요.

User-agent: *
Disallow: /internal-product-roadmap/
Disallow: /legal-private/
Disallow: /prompt-drafts/
Disallow: /customers/acme-renewal-risk/

위 파일은 모든 방문자에게 민감한 자료가 있을 법한 위치를 알려줘요. 준수하는 크롤러는 해당 경로를 피할 수 있어요. 공격자는 디렉터리 지도를 얻어요.

더 안전한 파일은 민감한 목록을 드러내지 않고 공개 크롤 정책을 말해요.

User-agent: *
Allow: /
Disallow: /*.md$
Sitemap: https://example.com/sitemap.xml

이 버전은 비공개 구조를 드러내지 않으면서 실제 선호를 표현해요. /prompt-drafts/가 존재한다면 서버가 인증으로 보호하고, 적절한 경우 noindex 헤더를 적용해야 해요. 크롤러 파일이 그 부담을 떠안으면 안 돼요.

AI 크롤러에는 목적 단위 정책이 필요해요

예전의 검색 크롤러 정책은 이분법처럼 느껴졌어요. Googlebot은 허용하고, 시끄러운 SEO 도구는 차단하고, 비공개 페이지는 서버 제어로 보호하는 식이었죠.

AI 크롤러 정책에는 목적이 추가돼요. 사이트 소유자는 어떤 페이지가 ChatGPT 검색 결과에는 나타나길 바라면서도, 같은 페이지가 모델 학습에는 사용되지 않길 원할 수 있어요. OpenAI의 크롤러 문서는 이 구분을 명확히 해요. OAI-SearchBot은 ChatGPT 검색 기능을 지원하고, GPTBot은 OpenAI의 생성형 AI 기반 모델 학습에 사용될 수 있는 콘텐츠를 크롤링한다고 설명해요.⁴ OpenAI는 이 설정들이 독립적이라고도 말해요. 웹마스터는 OAI-SearchBot은 허용하면서 GPTBot은 허용하지 않을 수 있어요.⁴

Google도 다른 방식으로 비슷한 경계를 그어요. Google 크롤러 문서는 Google-Extended에 별도의 HTTP 요청 사용자 에이전트 문자열이 없으며, 기존 Google 사용자 에이전트가 크롤링을 수행하고 Google-Extended는 robots.txt 제품 토큰으로 작동한다고 말해요.⁵ Google은 이 토큰이 크롤링된 사이트 콘텐츠가 향후 Gemini 모델 학습과 근거 마련을 지원할 수 있는지 제어하며, Google Search 포함 여부나 순위에는 영향을 주지 않는다고 설명해요.⁵

이 두 예시는 단순한 차단 목록이 핵심을 놓친다는 점을 보여줘요. 실제 정책 매트릭스는 이렇게 물어요.

정책 파일은 목적과 맞아야 해요. 모든 AI 사용자 에이전트를 허용하지 않은 뒤 AI 검색 노출 영역이 사이트를 무시한다고 의아해하지 마세요. 모든 AI 크롤러를 허용한 뒤 사용자 대상 검색에만 쓰려고 했던 페이지를 학습 크롤러가 소비한다고 불평하지 마세요. 목적을 분리하고, 선호를 명시하고, 동작을 검증하세요.

Llms.txt는 다른 문제를 해결해요

llms.txt는 robots.txt를 대체하지 않아요. Jeremy Howard의 제안은 /llms.txt를 LLM이 추론 시점에 웹사이트를 활용하는 데 도움이 되는 정보를 제공하는 방식으로 설명해요.⁶ 같은 제안은 llms.txt가 현재 웹 표준과 공존할 수 있다고 말해요. 사이트맵은 검색 엔진을 위해 페이지를 나열하고, llms.txt는 LLM을 위해 엄선된 개요를 제공하며, 허용된 콘텐츠에 대한 맥락으로 robots.txt를 보완할 수 있어요.⁶

이 구분은 AIO 작업에서 중요해요.

robots.txt가 답하는 질문은 “이 크롤러가 이 경로를 요청해도 되는가?”예요.

llms.txt가 답하는 질문은 “어시스턴트가 내 사이트를 읽는다면 무엇을 먼저 이해해야 하는가?”예요.

agents.txt가 답할 수 있는 질문은 “에이전트형 클라이언트가 바람직한 동작에 대해 무엇을 알아야 하는가?”예요.

이 질문들은 서로 가까이 있지만 하나의 파일로 합쳐지지는 않아요. 진지한 사이트라면 AI 발견을 릴리스 표면처럼 다뤄야 해요.

1. 명확한 제목과 설명이 있는 표준 페이지를 게시하세요.
2. 보이는 페이지와 일치하는 구조화 데이터를 추가하세요.
3. 사이트맵과 RSS 출력을 최신으로 유지하세요.
4. 엄선된 AI 맥락을 위해 llms.txt와 llms-full.txt를 게시하세요.
5. 명확한 크롤러 정책이 담긴 robots.txt를 게시하세요.
6. 플랫폼이나 에이전트 생태계가 해당 파일을 읽는 구체적인 독자를 제공할 때만 agents.txt를 추가하세요.
7. 로그를 확인해 크롤러가 변경된 파일을 요청했는지 확인하세요.

마지막 단계를 건너뛰면 AIO는 희망에 기대는 절차가 돼요. 크롤러 파일은 존재해요. 경로는 200을 반환해요. 하지만 의도한 클라이언트가 그것을 봤다는 증거는 없어요.

검증은 서버 경계에서 해야 해요

사용자 에이전트 문자열은 신원을 증명하지 않아요. 임의의 스크립트도 User-Agent: Googlebot을 보낼 수 있어요. 스크레이퍼도 User-Agent: GPTBot을 보낼 수 있어요. 헤더만 믿는 정책은 가장 위조하기 쉬운 신호에 가장 관대한 대우를 해줘요.

Google은 Google에서 왔다고 주장하는 요청을 검증하는 2가지 경로를 문서화해요. 일회성 확인에는 reverse DNS와 forward DNS를 함께 쓰고, 더 큰 시스템에는 게시된 IP 범위 매칭을 사용해요.⁷ OpenAI는 크롤러 문서에서 OAI-SearchBot, GPTBot, ChatGPT-User용 IP 주소 JSON 파일을 게시해요.⁴ 이 메커니즘이 모든 크롤러를 포괄하지는 않아요. 그래도 올바른 형태는 분명히 보여줘요. 신원에는 문자열 이상의 증거가 필요해요.

최소한의 서버 경계 정책은 다음을 기록해야 해요.

이 로그 묶음은 크롤러 정책을 의견이 아니라 증거로 바꿔요. GPTBot이 허용하지 않은 경로를 계속 요청한다면 증명할 수 있어요. 가짜 Googlebot이 주거용 프록시에서 비공개처럼 보이는 URL을 두드린다면 진짜 Googlebot을 벌주지 않고 차단할 수 있어요. OAI-SearchBot이 변경된 글을 한 번도 요청하지 않았다면, 왜 그 페이지가 ChatGPT 검색에 나타나지 않았는지 알 수 있어요.

실용적인 AI 크롤러 정책 묶음

파일부터 시작하지 마세요. 결과부터 시작하세요.

이 묶음은 각 계층에 맞는 일을 맡겨요. robots.txt는 선호를 전달해요. llms.txt는 맥락을 전달해요. agents.txt는 읽는 주체가 있을 때 에이전트 대상 의도를 전달해요. 서버는 강제해요. 로그는 증명해요.

제 사이트의 크롤러 작업도 이 구분을 따라요. 공개 정책 파일은 합법적인 크롤러를 환영하고, 크롤러가 코드 블록 예시에서 추론했던 원시 Markdown 경로를 차단해요. AI 맥락 파일은 어시스턴트가 공개 글로 들어가는 엄선된 경로를 제공해요. 야간 크롤 집계는 크롤러가 오류, 오래된 캐시, 누락된 경로, 이제 410을 반환해야 하는 오래된 URL을 봤는지 알려줘요. 정책 파일은 의도를 줘요. 로그는 그 의도가 작동했는지 판단해요.

Agents.txt에 무엇을 넣어야 하나요?

생태계가 정착하기 전까지 agents.txt는 지루하고 공개적인 내용으로 유지하세요.

좋은 후보는 다음과 같아요.

• 사이트 연락처와 정책 URL.
• robots.txt, 사이트맵, llms.txt, RSS에 대한 포인터.
• 선호하는 공개 콘텐츠 사용에 대한 설명.
• 비공개 또는 인증된 경로에는 권한 부여가 필요하다는 경고.
• 크롤 문제를 위한 지원 주소.

나쁜 후보는 다음과 같아요.

• 비밀 경로.
• 내부 프롬프트 규칙.
• 비공개 API 경로.
• 고객 이름.
• 보안 예외.
• 적대적인 클라이언트가 복사했을 때 사이트에 해를 줄 수 있는 지침.

agents.txt에 맞는 기준은 “좋은 에이전트가 이걸 고마워할까?”가 아니에요. 맞는 기준은 “나쁜 에이전트, 검색 결과, 임의의 사용자가 모두 이 파일을 읽어도 괜찮은가?”예요.

더 나은 사고방식

크롤러 파일은 공공 도로의 표지판이에요.

표지판은 “배송 입구”, “진입 금지”, “여기서 시작”이라고 말할 수 있어요. 예의 있는 운전자는 표지판을 따라요. 무모한 운전자는 무시해요. 그래도 표지판은 도움이 돼요. 대부분의 합법적인 트래픽은 명확한 지침을 원하기 때문이에요. 표지판을 잠긴 문처럼 취급하는 순간 표지판은 실패해요.

AI 크롤러는 이 표지판을 동시에 더 중요하게 만들고 덜 충분하게 만들어요. AI 시스템에는 명확한 공개 맥락, 목적별 정책, 경로 지도가 필요하므로 더 중요해요. 사용자 에이전트가 늘어나고, 학습과 검색이 분리되며, 나쁜 클라이언트가 좋은 클라이언트를 가장할 수 있으므로 덜 충분해요.

해답은 크롤러 파일을 포기하는 것이 아니에요. 해답은 권한 수준을 알맞게 낮추는 거예요. 명확한 공개 정책을 게시하세요. 누가 파일을 요청하는지 검증하세요. 무엇을 가져가는지 지켜보세요. 비공개 경계는 서버에서 강제하세요. “AI 가시성”에 관한 모든 주장은 로그와 실제 경로가 뒷받침하기 전까지 입증되지 않은 것으로 다루세요.

이것이 AIO 흉내 내기와 실제 크롤러 운영의 차이예요.

FAQ

agents.txt란 무엇인가요?

agents.txt는 일부 호스트나 도구가 사이트 루트에서 제공할 수 있는, 에이전트 대상의 새로운 텍스트 파일이에요. DreamHost는 Web Hosting 플랜의 기본 agents.txt 파일을 문서화하지만, 그 문서가 이 파일을 접근 제어 표준으로 만들지는 않아요. 특정 에이전트 플랫폼이 파일을 어떻게 읽고 적용하는지 정확히 문서화하기 전까지는 공개 힌트로 다루세요.¹

robots.txt가 AI 크롤러를 차단하나요?

준수하는 크롤러는 robots.txt를 존중할 수 있고, 주요 운영자는 자사 크롤러를 위한 특정 토큰을 문서화해요. OpenAI는 OAI-SearchBot과 GPTBot 제어를 문서화하고, Google은 Google-Extended를 학습과 근거 마련 선호를 위한 제품 토큰으로 문서화해요.⁴⁵ 그래도 robots.txt는 클라이언트를 인증하거나, 콘텐츠를 숨기거나, 파일을 무시하기로 한 봇을 멈추지 못해요.²³

llms.txt를 게시해야 하나요?

AI 어시스턴트가 공개 콘텐츠의 엄선된 지도를 찾길 원한다면 llms.txt를 게시하세요. 이 제안은 llms.txt를 사이트맵이나 robots.txt의 대체물이 아니라 추론 시점 맥락으로 설명해요.⁶ 유용한 파일은 에이전트가 실제로 이해하길 바라는 페이지를 가리켜요.

허용하지 않은 URL도 검색에 나타날 수 있나요?

네. Google은 robots.txt로 차단된 URL이라도 다른 페이지가 링크하면 나타날 수 있다고 말해요. 다만 Google은 차단된 페이지 콘텐츠를 크롤링하거나 색인하지 않아요.³ 공개 결과에서 제외되어야 하는 페이지에는 인증, 크롤 접근이 허용되는 경우 noindex, 서버 측 정책을 사용하세요.

진짜 크롤러와 가짜 크롤러를 어떻게 구분하나요?

사용자 에이전트 문자열만 보지 마세요. Google은 reverse DNS와 forward DNS 확인, 게시된 IP 범위 매칭을 문서화해요.⁷ OpenAI는 문서화된 봇을 위한 IP 주소 JSON 파일을 게시해요.⁴ 크롤러 운영자가 검증 데이터를 게시하지 않는 경우, 해당 요청은 주장으로 분류하고 동작에 따라 속도 제한이나 챌린지를 적용하세요.

공개 사이트에 가장 안전한 크롤러 파일 구성은 무엇인가요?

크롤러 정책에는 robots.txt, URL 발견에는 사이트맵, 엄선된 AI 맥락에는 llms.txt, 공개 에이전트 대상 안내가 필요할 때만 agents.txt를 사용하세요. 모든 공개 파일에서 민감한 경로를 빼세요. 그런 다음 설정이 작동한다고 말하기 전에 실제 경로, 캐시 상태, 크롤러 가져오기, 서버 로그를 검증하세요.

참고 자료