"사이트를 에이전트 친화적으로 만드세요(Make your site agent-ready)"라는 말이 자주 쓰이지만, 이는 사실 세 가지 서로 다른 의미를 세 가지 서로 다른 종류의 AI 에이전트에게 전달하며, 이들은 계층적으로 쌓여 있습니다. 저는 작은 도구(무료 llms.txt 검증기)를 만들고 그 위에 이 세 가지 레이어를 모두 연결했습니다. 따라서 이 글은 모호한 설명이 아닌, 코드를 그대로 복사해서 사용할 수 있는 버전입니다.

하지만 세 가지 레이어를 살펴보기 전에, 가장 밑바닥부터 시작해 보겠습니다. 왜냐하면 전체 스택이 아직 대부분의 사이트에 없는 작은 파일 하나에 의존하기 때문입니다.

첫 번째: llms.txt란 무엇이며, 왜 중요할까요?

llms.txt는 yoursite.com/llms.txt에 배치하는 일반 텍스트(plain-text) 파일로, AI 모델에게 당신의 사이트가 무엇에 관한 것인지, 그리고 어떤 페이지가 실제로 중요한지를 알려줍니다. 그게 전부입니다. 이 파일은 Markdown 형식으로 작성되며, ChatGPT, Claude, Perplexity 및 점점 늘어나고 있는 AI 에이전트 군단과 같은 AI 어시스턴트와 크롤러(crawlers)가 당신의 사이트를 이해하려고 할 때 읽게 됩니다.

이 파일이 해결하는 문제는 다음과 같습니다. 오늘날 AI가 웹사이트를 "읽으려고" 할 때, HTML 래퍼(wrappers), 탐색 메뉴, 쿠키 배너, 광고, 심지어 실행조차 되지 않을 수 있는 JavaScript 등 엉망진창인 상태를 마주하게 됩니다. AI는 무엇이 중요한지 추측해야 하며, 그 과정에서 제한된 컨텍스트 윈도우(context window)의 상당 부분을 소모합니다. 종종 추측에 실패하거나 포기하기도 합니다.

llms.txt는 대신 AI에게 깨끗하게 큐레이션된 지도를 제공합니다. 즉, 당신의 사이트가 무엇인지, 그리고 어떤 페이지가 좋은 페이지인지를 우선순위에 따라 직접 결정하는 것입니다:

# 예시 — 팀을 위한 프로젝트 관리 (Project Management for Teams)

> 예시는 프로젝트 관리 앱입니다. 이 파일은 AI 어시스턴트에게...
...

두 가지 유용한 사고 모델:

• sitemap.xml에 대응하는 AI용 버전입니다. 사이트맵(sitemap)이 _검색 엔진(search engines)_이 모든 페이지를 찾도록 돕는다면, llms.txt는 _AI 모델_이 가장 저렴한 비용으로 읽을 수 있는 형식으로 중요한 몇몇 페이지를 이해하도록 돕습니다.
• robots.txt의 반대 측면입니다. robots.txt가 크롤러가 건드리지 말아야 할 것을 말한다면, llms.txt는 당신의 사이트가 무엇인지, 그리고 가치가 어디에 있는지를 말해줍니다.

지금 이것이 중요한 이유: 사람들은 점점 더 당신의 사이트를 클릭하는 대신 AI 어시스턴트(AI assistant)로부터 당신의 제품에 대한 답변을 얻고 있습니다. 만약 AI가 당신을 저렴하고 정확하게 이해할 수 없다면, 당신을 건너뛰거나 당신을 잘못 설명하게 됩니다. llms.txt는 AI에게 정확하고 큐레이션된 요약본을 제공할 기회이며, 이를 통해 당신이 의도한 방식대로 당신이 표현되도록 할 수 있습니다. 이것은 랭킹 트릭(ranking trick)이 아니라 컨텍스트 레이어(context layer)입니다. 당신은 무엇을 속이는 것이 아니라, 단지 당신의 사이트를 기계가 읽을 수 있게(legible) 만드는 것뿐입니다.

(llms-full.txt라는 선택적인 동반 파일이 있는데, 이는 해당 페이지들의 전체 텍스트를 인라인(inline)으로 포함하여 AI가 한 번의 호출(fetch)로 모든 것을 흡수할 수 있게 합니다. 우선 llms.txt부터 시작하세요.)

그것이 기초입니다. 이제 그 위에 구축되는 세 가지 레이어를 살펴보겠습니다.

여기에 세 가지 독립적인 레이어가 있습니다. 이 중 어떤 것이든 단독으로 채택할 수 있습니다:

1. llms.txt — 당신의 사이트를 읽는 크롤러(crawlers)를 위한 컨텍스트(context).
2. WebMCP — 브라우저 내부에서 당신의 UI를 구동하는 에이전트(agent)를 위한 도구.
3. A2A — 네트워크를 통해 당신에게 접속하는 다른 에이전트를 위한 호출 가능한 엔드포인트(endpoint).

크롤러(Crawler) → 브라우저 에이전트(browser agent) → 네트워크 에이전트(networked agent). 서로 다른 에이전트, 서로 다른 메커니즘, 중복되는 부분은 전혀 없습니다.

레이어 1 — llms.txt: 크롤러를 위한 컨텍스트

가장 기본적이면서 대부분의 사이트에 가장 가치가 높은 레이어입니다. 루트(root)에 있는 일반 텍스트 형식의 llms.txt는 AI 크롤러에게 당신의 사이트가 무엇인지, 그리고 어떤 페이지가 중요한지를 우선순위에 따라 알려줍니다. 이는 호출(fetch) 시점에 읽히며, JavaScript, 프로토콜, SDK가 필요하지 않습니다. 말 그대로 마크다운(Markdown) 형식입니다:

# Example Docs

> Developer documentation for the Example API.
...

실제로 실무에서 중요한 규칙들:

• 단 하나의 # H1 제목, 하나의 > 인용구 (blockquote) 요약.
• 실제 마크다운 (Markdown) 링크가 포함된 ## 섹션.
• 절대 경로 HTTPS URL — 상대 경로 링크는 가장 흔하게 발생하는 실패 원인입니다.
• text/plain 형식으로 서빙할 것.

이것이 해당 레이어의 전부입니다. 다른 것은 하지 않더라도, 이것 하나만큼은 반드시 지키세요.

Layer 2 — WebMCP: 브라우저 내 에이전트를 위한 도구 (tools)

WebMCP를 사용하면 페이지가 브라우저 내부에서 실행되는 AI 에이전트에게 호출 가능한 **도구 (tools)**를 노출할 수 있습니다. 즉, 에이전트가 사용자의 폼 필드를 추측하며 이곳저곳 클릭하는 대신, 사용자가 정의한 타입이 지정된 액션 (typed action)을 호출하게 됩니다. 도구를 노출하는 방법에는 두 가지가 있으며, 저는 두 가지 모두를 구현했습니다.

선언적 (Declarative) 방식 — 실제 폼 (form)에 주석을 달면 브라우저가 이를 바탕으로 도구를 합성합니다. 자바스크립트 (JavaScript)가 전혀 필요 없습니다:

<form toolname="open_llms_txt_report"
      tooldescription="Validate a site's llms.txt and open its report.">
  <input name="url" toolparamdescription="Domain or URL to validate">
...

명령형 (Imperative) 방식 — 구조화된 데이터를 직접 반환하는 도구를 자바스크립트 (JavaScript)에서 등록합니다:

navigator.modelContext?.registerTool({
  name: "validate_llms_txt",
  description: "\"Validate a website's llms.txt; returns a 0-100 score and findings.\","
...

명령형 호출은 if (navigator.modelContext) 뒤에 배치하여 WebMCP가 존재하지 않는 환경에서는 아무 동작도 하지 않도록(no-op) 보호하세요. 현실적인 점검: 현재 이는 크롬 오리진 트라이얼 (Chrome origin trial) 단계이므로 실제 도달 범위는 매우 작습니다. 이를 트래픽 소스가 아닌, 미래의 신호이자 깔끔한 참조 모델로 취급하세요.

Layer 3 — A2A: 다른 에이전트를 위한 호출 가능한 에이전트

현재 리눅스 재단 (Linux Foundation) 산하에 있는 에이전트 간 (Agent2Agent, A2A) 프로토콜은 다른 에이전트들이 일반 HTTP를 통해 귀하의 서비스를 **탐색하고 호출 (discover and call)**할 수 있게 해줍니다. 브라우저도, 스크래핑 (scraping)도 필요 없습니다. 이는 공개 API (public API)에 대응하는 에이전트 간의 대응물입니다.

두 부분으로 구성됩니다: 탐색 문서 (discovery document, 즉 에이전트 카드 (agent card))와 호출 가능한 엔드포인트 (endpoint, 즉 기술 (skill))입니다.

에이전트 카드 (The agent card) — /.well-known/agent-card.json에 위치한 JSON 파일:

{
  "protocolVersion": "0.3.0",
  "name": "llms.txt Validator",
...

엔드포인트 (The endpoint) — 카드의 url은 JSON-RPC 2.0 엔드포인트를 가리킵니다. 에이전트가 message/send를 호출하면, 당신은 작업을 수행하고 Task를 반환합니다. 실제 호출 예시:

POST /a2a
{ "jsonrpc": "2.0", "id": "1", "method": "message/send",
  "params": { "message": { "role": "user",
...

…그리고 응답 — 사람이 읽을 수 있는 요약과 구조화된 데이터 (structured data)가 포함된 완료된 작업:

{ "result": { "kind": "task", "status": { "state": "completed" },
  "artifacts": [{ "parts": [
    { "kind": "text", "text": "Validated llmstxt.org: score 100/100..." },
...

에이전트는 자신이 요청한 데이터를 정확히 받게 됩니다. 시작하기 위해 프로토콜 전체가 필요하지는 않습니다. 하나의 실제 기능 (capability)을 선택하고, 하나의 기술 (skill)을 가진 카드를 제공하며, 동기식 message/send를 구현하여 완료된 Task를 반환하기만 하면 됩니다. 스트리밍 (Streaming), 작업 이력 (task history), 푸시 알림 (push notifications)은 필요할 때까지 선택 사항입니다 (capabilities.streaming: false).

단 하나의 규칙: 뒷받침할 수 없는 신호를 게시하지 마세요

어떤 감사 (audit)를 통과하기 위해 빈 에이전트 카드를 던져두거나 가짜 폼 어노테이션 (form annotations)을 넣고 싶은 유혹이 들 수 있습니다. 그러지 마세요. 당신의 카드를 가져와서 죽은 엔드포인트를 호출하거나, 아무것도 하지 않는 도구 (tool)를 호출하는 에이전트는 이후에 당신을 덜 신뢰하게 됩니다. 모든 신호는 실제 무언가로 해결되어야 합니다. (이것이 제가 만든 검증기(validator)가 WebMCP 또는 A2A 신호를 실제 작동하는 구현체가 뒷받침할 때만 "존재함 (present)"으로 보고하는 이유입니다.)

각 레이어를 검증하는 방법

• llms.txt — llms.txt validator를 통해 도메인을 실행하세요. 깨진 링크 없이 100/100 점수를 목표로 합니다.

• WebMCP — Chrome 149+ 버전에서 chrome://flags/#enable-webmcp-testing을 활성화하고 Lighthouse의 Agentic Browsing 감사를 실행하세요. 사용자의 도구들이 목록에 표시되어야 합니다.
• A2A — /.well-known/agent-card.json을 가져온 다음, 해당 파일의 url로 message/send 호출을 POST 하여 완료된 작업(completed task)을 다시 받는지 확인하세요.

이것이 전체 스택입니다: 크롤러를 위한 llms.txt, 브라우저 내 에이전트를 위한 WebMCP, 그리고 네트워크 기반 에이전트를 위한 A2A입니다. llms.txt(현재 실질적인 가치가 있는 것)부터 시작하고, 노출할 실제 액션(action)이나 서비스가 생기면 미래의 신호(forward signals)로서 WebMCP와 A2A를 추가하세요.

만약 무언가를 만드신다면 꼭 보고 싶습니다. 댓글에 여러분의 에이전트 카드(agent card)를 남겨주세요.