에이전트 중심 최적화(AEO)

https://addyosmani.com/blog/agentic-engine-optimization/

AI 코딩 에이전트가 문서를 소비하는 방식은 인간과 근본적으로 다릅니다. 아직도 사람만을 위한 문서 최적화에만 신경 쓰고 있다면, 당신의 도구들이 더 이상 보지 못하는, 점점 커지는 독자층을 그대로 놓치고 있는 셈입니다. 문서, CLI, MCP, 스킬… 지금은 AI 에이전트가 상호작용하는 인터페이스 생태계 전체를 바라봐야 합니다.

요즘 여러 개발자 포털에서 벌어지고 있는 현상을 지켜보면서, 지금보다 훨씬 더 주목받아야 한다고 느끼고 있습니다.

한 엔지니어가 Claude Code를 열고, 특정 스펙을 구현해 달라고 요청한 뒤 엔터를 누릅니다. 에이전트는 당신의 문서를 일부 가져옵니다. 필요한 내용을 조금 긁어 오고, HTML을 날(raw) 텍스트로 파싱한 다음, HTML 태그를 전부 제거하고, 토큰을 세서, 그걸 컨텍스트로 쓸지 말지 판단합니다. 혹은 컨텍스트 윈도우를 넘어서면 아무 말 없이 내용을 버려 버립니다.

당신의 애널리틱스에는 유의미한 데이터가 전혀 남지 않습니다. 스크롤 깊이는 0. 페이지 체류 시간은 400밀리초. 링크 클릭도, 튜토리얼 완료도, UI 상호작용도 없습니다. 수년 동안 최적화해 온 퍼널에는 아무것도 찍히지 않습니다.

하지만 에이전트는 분명히 그 페이지에 다녀갔습니다. 문서를 읽었습니다. 그리고 그 문서가 어떻게 구조화되어 있었느냐에 따라, 작업을 제대로 끝내기도 하고, 아니면 내용이 토큰 과다, 엉성한 구조, 잘못 설정된 robots.txt⁠ 때문에 잘못된 답을 “지어내기도” 합니다.

저는 이런 문제를 다루는 분야를 Agentic Engine Optimization, 줄여서 AEO라고 부르기 시작했습니다.

Agentic Engine Optimization이란 무엇인가?

**Agentic Engine Optimization(AEO)**은 사람뿐 아니라, AI 코딩 에이전트가 실제로 활용할 수 있도록 기술 콘텐츠를 구조화·포맷·서빙하는 방법론입니다.

비유를 들자면 SEO가 가장 가깝습니다. 우리는 검색 크롤러와 사람의 클릭 패턴에 맞춰 수년 동안 콘텐츠를 최적화해 왔습니다. AEO도 같은 개념이지만, 소비 주체가 다릅니다. 이제는 스스로 문서를 가져와 파싱하고 추론하는 AI 에이전트가 그 대상입니다.

여기서 중요한 포인트는 꽤 구체적입니다.

• 발견 가능성(Discoverability) – 에이전트가 JavaScript 렌더링 없이도 문서를 찾아갈 수 있는가?
• 파싱 가능성(Parsability) – 시각 레이아웃 해석 없이도 기계가 읽을 수 있는 형태인가?
• 토큰 효율(Token efficiency) – 일반적인 에이전트 컨텍스트 윈도우 안에 잘려 나가지 않고 들어가는가?
• 능력 신호(Capability signaling) – API를 “어떻게 호출하는지”만이 아니라, 실제로 “무엇을 할 수 있는지”까지 문서에 드러나 있는가?
• 접근 제어(Access control) – robots.txt⁠가 실제로 AI 트래픽을 허용하고 있는가?

이 중 어느 하나라도 실패하면, 에이전트는 문서를 통째로 건너뛰거나, 아주 미묘하게 잘못된 결과를 내놓게 됩니다. 까다로운 점은, 이때도 어떤 애널리틱스 이벤트도 찍히지 않아서, 당신은 문제가 생긴 줄도 모른다는 것입니다.

AI 에이전트는 실제로 어떻게 문서를 읽는가

여기서 인간과의 행동 차이를 짚고 넘어갈 필요가 있습니다. 처음 예상했던 것보다 차이가 훨씬 크기 때문입니다.

인간의 패턴

사람 개발자는 문서 홈페이지에 들어옵니다. 관련 있는 섹션으로 이동하고, 헤딩을 훑어보고, 몇 문단을 읽고, 인터랙티브 콘솔에서 코드 샘플을 실행해 보고, 내부 링크를 두세 개 정도 더 따라가면서 4–8분 정도를 보냅니다. 당신의 애널리틱스는 이 모든 행동을 고스란히 기록합니다.

에이전트의 패턴

최근 연구 논문(Developer Experience with AI Coding Agents)에서는 Claude Code, Cursor, Cline, Aider, VS Code, Junie를 포함한 아홉 개 주요 AI 코딩 에이전트가 개발자 문서를 어떻게 가져가는지, HTTP 트래픽을 분석했습니다. 결과는 꽤 인상적입니다.

에이전트는 사람이 여러 페이지를 오가며 탐색할 흐름을, 한두 번의 HTTP 요청으로 압축해 버립니다. 사람이 문서 계층 구조를 몇 분 동안 클릭·탐색하는 동안, 에이전트는 단일 GET⁠ 요청으로 페이지 전체를 받아오고 바로 다음 단계로 넘어갑니다. “사용자 여정(user journey)”라는 개념 전체가 서버 단 한 번의 이벤트로 붕괴되는 셈입니다.

실질적인 결과는 이렇습니다. 클라이언트 사이드 애널리틱스 이벤트—스크롤 깊이, 페이지 체류 시간, 버튼 클릭, 튜토리얼 완료, 링크 이동, 폼 상호작용—는 전부 사라집니다. 에이전트는 이 모든 것을 우회해 버립니다.

AI 트래픽의 지문

이 연구는 서버 로그에서 AI 에이전트 트래픽을 식별할 수 있는 독특한 행동 패턴도 함께 밝혔습니다.

코딩 에이전트 외에도, AI 어시스턴트 웹 서비스들(ChatGPT, Claude, Google Gemini, Perplexity)은 사용자가 URL을 챗 인터페이스에 붙여넣을 때마다 각각 서버 사이드에서 문서를 한 번 더 가져오며, 이때 또 각자의 고유한 “지문”을 남깁니다.

무엇을 찾아봐야 할지 감이 잡히면, 이제 애널리틱스에서 AI 에이전트 트래픽을 따로 분리해 볼 수 있습니다. 제 자신의 로그를 봤을 때도, 이미 이런 트래픽이 꽤 많이 들어와 있다는 사실에 놀랐습니다.

토큰 문제: 당신의 문서는 에이전트에게 “보이지 않을” 수 있다

이제부터가 아마 이 전체 그림에서 가장 과소평가된 부분일 겁니다. 바로 **토큰 경제(token economics)**입니다.

에이전트에게는 무한한 컨텍스트가 없습니다. 실사용 환경에서 대부분 10만~20만 토큰 사이 제약이 걸려 있고, 모든 작업에서 컨텍스트 관리가 실질적인 제약 조건으로 작동합니다. 논문에서는 구체적인 예로 Cisco Secure Firewall Management Center REST API Quick Start Guide(버전 10.0)를 들고 있는데, 이 문서는 193,217 토큰—약 718,000자에 달합니다. 이 한 문서가 대부분의 에이전트가 쓸 수 있는 컨텍스트 윈도우 전체를 잠식하거나, 아예 넘겨버릴 수 있는 수준입니다.

에이전트가 이렇게 너무 긴 문서를 만나면, 결과는 대체로 좋지 않습니다.

• 아무 말 없이 뒷부분을 잘라 버리며, 중요한 정보가 통째로 날아갈 수 있고
• 문서를 통째로 포기하고, 더 짧은 다른 문서를 우선시할 수 있고
• 여러 조각으로 쪼개(chunking) 처리하려다 지연과 오류 가능성을 키울 수 있고
• 마지막에는 파라메트릭 지식에 의존하게 됩니다. 즉, **“그럴듯하게 지어낸다”**는 이야기입니다.

그래서 저는 이제 토큰 수가 문서의 1급(first-class) 메트릭이 되었다고 봅니다. 각 문서 페이지가 몇 토큰인지를 추적하지 않고 있다면, 사실상 에이전트가 “이 문서를 읽어볼지 말지” 결정하는 데 쓰는 신호 하나를 놓치고 있는 셈입니다.

실질적인 토큰 가이드라인

지금까지 보기에, 대략 다음 정도가 기준으로 괜찮아 보입니다.

• 퀵 스타트 / 시작하기 페이지: 15,000 토큰 미만
• 개별 API 레퍼런스 페이지: 25,000 토큰 미만
• 풀 API 레퍼런스: 제품 단위가 아니라 리소스/엔드포인트 단위로 쪼개기
• 개념 가이드: 20,000 토큰 미만; 세부 내용은 한 페이지에 다 넣지 말고 링크로 분리

AEO 스택: 실제로 무엇을 만들어야 하는가

AEO는 하나의 기능이 아니라, 여러 신호와 표준이 층을 이루는 스택에 가깝습니다. 저는 이걸 기초에서 표면까지 이어지는 레이어로 이해하고 있습니다.

레이어 1: 접근 제어(robots.txt⁠)

에이전트는 보통 여기서부터 시작합니다. 콘텐츠를 가져오기 전에, 많은 에이전트는 robots.txt⁠를 먼저 확인해 어떤 경로에 접근할 수 있는지 판단합니다.

robots.txt⁠에서 알려진 AI 크롤러를 막아 두면, 에이전트는 조용히 당신의 문서 전체에 접근하지 못하게 됩니다. 트래픽도, 에러도, 경고도 없이 그냥 “없는 것처럼” 됩니다. 실제로 이런 설정 때문에, 자기네 문서가 에이전트에게 완전히 안 보인다는 사실을 전혀 모르고 있던 팀들을 여럿 봤습니다.

실질적으로 할 일은 다음과 같습니다.

• robots.txt⁠를 점검해 AI 에이전트의 user-agent를 의도치 않게 차단하고 있지 않은지 확인하기
• Anthropic, OpenAI, Google, Perplexity 크롤러 등 잘 알려진 패턴은 명시적으로 허용하는 것도 고려하기
• 더 세밀한 제어가 필요하다면, 자동화된 상호작용 허용 범위, 속도 제한, 선호 API 엔드포인트 등을 선언적으로 지정할 수 있는 새로운 스펙인 agent-permissions.json⁠을 살펴보기

레이어 2: llms.txt⁠를 통한 검색·발견(Discovery)

에이전트가 당신의 콘텐츠에 접근할 수 있다 해도, 이제는 “정확히 어떤 콘텐츠를” 찾아야 합니다. 여기서 llms.txt⁠가 등장합니다.

저는 llms.txt⁠를 AI 에이전트를 위한 사이트맵으로 생각합니다. yourdomain.com/llms.txt⁠ 경로에 두는, 플랫한 Markdown 파일로, 문서 전체를 구조 있게 정리해 주는 디렉터리 역할을 합니다. 에이전트는 이 파일 하나만 읽어도 전체 사이트를 전부 크롤링하지 않고, 어떤 문서가 어떤 상황에 필요한지 가늠할 수 있습니다.

잘 구성된 llms.txt⁠는 대략 이런 모습입니다.

# YourProduct 문서

## 시작하기
- [퀵 스타트 가이드](/docs/quickstart): 설치하고 5분 안에 첫 번째 API 호출하기
- [인증](/docs/auth): OAuth 2.0 및 API 키 인증 패턴
- [핵심 개념](/docs/concepts): 데이터 모델, 엔티티, 용어 정리

## API 레퍼런스
- [REST API 개요](/docs/api): 기본 URL, 버저닝, 페이지네이션, 에러 코드
- [Users API](/docs/api/users): 사용자 관리를 위한 CRUD 작업 (12K tokens)
- [Events API](/docs/api/events): 이벤트 스트리밍 및 웹훅 구성 (8K tokens)

## MCP 통합
- [MCP 서버](/docs/mcp): 에이전트가 직접 통합할 수 있는 Model Context Protocol 서버

좋은 llms.txt⁠의 기준은 다음과 같습니다.

• 페이지 이름만이 아니라, 그 페이지에 무엇이 있는지를 설명하는 디스크립션
• 필요한 경우 페이지별 토큰 수를 함께 표기(에이전트가 컨텍스트 예산을 가늠하는 데 도움이 됨)
• 제품 조직도(product hierarchy)가 아니라 작업(task) 중심으로 구성
• 이 파일 자체는 5,000 토큰 안팎으로 유지(인덱스 하나 읽는데만 예산을 다 써버리면 안 됨)

레이어 3: skill.md⁠를 통한 능력 신호(Capability signaling)

llms.txt⁠가 “어디에 무엇이 있는지”를 알려준다면, skill.md⁠는 당신의 제품이 무엇을 할 수 있는지를 알려줍니다.

이 차이는 처음 생각보다 꽤 중요합니다. 에이전트가 문장의 행간을 읽으며 기능을 추론하게 두는 대신, skill.md⁠는 의도(Intent)와 엔드포인트·리소스를 명시적으로 매핑해 줍니다.

예를 들어, 어떤 인증 서비스에 대한 skill.md⁠는 다음과 같을 수 있습니다.

---
name: auth-service
description: 사용자 인증, OAuth 2.0 플로우, 세션 관리를 처리합니다
---

## 내가 할 수 있는 것들
- OAuth 2.0(authorization code, client credentials, PKCE)을 통한 사용자 인증
- JWT 토큰 발급 및 검증
- 사용자 세션 관리 및 리프레시 토큰 회전 관리
- SSO 프로바이더(SAML, OIDC) 연동

## 필요한 입력값
- 클라이언트 ID와 클라이언트 시크릿(개발자 콘솔에서 발급)
- 리다이렉트 URI(사전 등록 필수)
- 요청 스코프(read:user, write:data, admin)

## 제약 사항
- 레이트 리밋: 애플리케이션당 분당 1000건의 토큰 요청
- 토큰 만료: 액세스 토큰 1시간, 리프레시 토큰 30일
- 공개 클라이언트의 경우 PKCE 필수

## 주요 문서
- [OAuth 2.0 가이드](/docs/oauth): 코드 샘플이 포함된 전체 플로우 walkthrough
- [토큰 레퍼런스](/docs/tokens): 토큰 구조, 클레임, 검증
- [Postman 컬렉션](/docs/postman): 바로 사용할 수 있는 요청 템플릿

이렇게 해야 에이전트가 단지 문서를 가져와 읽는 것을 넘어, 사용자의 의도를 실제로 만족시킬 수 있는 API인지를, 컨텍스트 예산을 쓰기 전에 판단할 수 있습니다.

레이어 4: 에이전트 파싱을 위한 콘텐츠 포맷팅

설령 검색·발견과 능력 신호가 완벽하더라도, 정작 콘텐츠 자체가 에이전트에게 읽기 좋은 형식이어야 합니다. 여기에는 제가 보기에 중요한 점들이 몇 가지 있습니다.

HTML만이 아니라 Markdown도 함께 제공하라. 많은 문서 플랫폼은 URL 끝에 .md⁠를 붙이거나 쿼리 파라미터를 통해 원본 Markdown에 접근할 수 있는 기능을 제공합니다. 이 규칙을 노출해 주세요. 에이전트는 HTML보다 Markdown을 훨씬 더 적은 토큰으로 처리할 수 있습니다(태그 노이즈, 내비게이션 크롬, 푸터 잡음이 모두 사라지기 때문입니다).

“읽기”가 아니라 “스캔하기”에 맞춰 구조화하라. 에이전트는 줄 단위로 정독하지 않고, 구조를 파싱합니다.

• 헤딩 계층 구조를 일관되게(H1 → H2 → H3, 중간 단계 건너뛰지 않기)
• 각 섹션의 첫 부분에 배경 설명보다 결과와 요지를 두기
• 설명 바로 뒤에 해당 내용을 보여주는 코드 예제를 배치하기
• 파라미터 레퍼런스는 문단 나열보다 테이블로 구성하기(토큰 면에서도 더 압축적)

내비게이션 노이즈를 없애라. HTML에 들어 있는 사이드바, 브레드크럼, 푸터 링크는 Markdown/텍스트 파싱 시 전부 노이즈입니다. 파싱용 콘텐츠 경로에서는 이런 요소를 최대한 제거하세요.

핵심 내용을 앞에 배치하라. 어떤 페이지든 처음 500 토큰 안에서 “이 페이지가 무엇인지, 무엇을 할 수 있는지, 시작하려면 무엇이 필요한지”가 바로 드러나야 합니다. 에이전트는 서론이 길게 이어지는 걸 참아줄 만큼 인내심이 많지 않습니다.

레이어 5: 토큰 수 노출(Token surfacing)

이건 이름만 거창하지, 실제로는 구현이 단순하지만 효과가 큰 레이어입니다. 바로 문서 페이지마다 토큰 수를 보여주는 것입니다. 이상적으로는 llms.txt⁠ 인덱스와 각 페이지 자체(메타데이터나 헤더)에 모두 노출하는 편이 좋습니다.

이 정보가 있어야 에이전트가 현명한 결정을 내릴 수 있습니다.

• “이 페이지는 8K 토큰이니까, 통째로 컨텍스트에 넣어도 되겠군”
• “이 페이지는 150K 토큰이니, 관련 섹션만 골라서 가져와야겠다”
• “이 페이지는 내 컨텍스트 윈도우를 넘으니, llms.txt⁠에 있는 요약본만 참조하자”

구현은 간단합니다. 서버 사이드에서 문자 수를 세고, 대략 4로 나누어 토큰 수를 추산한 뒤, 메타 태그나 HTTP 응답 헤더로 노출하면 됩니다.

레이어 6: “Copy for AI”

이건 인프라라기보다는 UX 브리지에 가깝지만, AEO의 일부로 넣을 가치가 있다고 생각합니다. 바로 Copy for AI 버튼입니다.

지금 IDE 안에서 AI 어시스턴트와 함께 작업하는 개발자가 문서를 컨텍스트로 넣고 싶을 때, 대개 렌더링된 HTML에서 복사·붙여넣기를 합니다. 이 과정에서 내비게이션 노이즈, 푸터, 온갖 불필요한 요소까지 그대로 딸려 들어갑니다. “Copy for AI” 버튼이 있다면, 깔끔한 Markdown만 클립보드에 복사되므로, 에이전트가 받는 컨텍스트 품질이 체감될 만큼 좋아집니다.

Anthropic, Cloudflare를 비롯한 여러 팀이 이미 이와 유사한 버튼을 도입했습니다. 구현 난이도에 비해 신호 대비 노이즈 비율을 크게 개선해 주는 요소입니다.

AGENTS.md: 새로 떠오르는 디폴트

여기서 따로 짚고 싶은 파일이 있습니다. 바로 AGENTS.md⁠입니다.

예전 README.md⁠가 리포지토리를 처음 여는 인간 개발자들에게 사실상 “기본 진입점”이 됐듯이, AGENTS.md⁠는 점점 AI 에이전트에게 그 역할을 맡기고 있습니다. 코딩 에이전트가 프로젝트를 열면, 루트 디렉터리에서 AGENTS.md⁠를 찾고, 그 안의 지침을 이후 모든 작업에 끌어다 씁니다.

이에 대해 별도로 글을 쓰기도 했습니다. 요약하자면, 좋은 AGENTS.md⁠에는 다음 내용이 포함됩니다.

• 프로젝트 구조와 주요 파일 위치
• 관련 API나 서비스 문서로 바로 가는 링크
• 사용 가능한 개발 샌드박스와 테스트 환경 정보
• 에이전트가 알고 있어야 할 레이트 리밋과 제약 조건
• 코드베이스에서 선호하는 패턴과 관례
• MCP 서버가 있다면 그 링크

Cisco DevNet은 이미 GitHub 오픈소스 프로젝트 템플릿의 기본 파일로 AGENTS.md⁠를 채택했습니다. 새로 만든 프로젝트에는 프로젝트별 콘텐츠, OpenAPI 문서 링크, DevNet 샌드박스와 테스트 환경 링크가 미리 채워진 AGENTS.md⁠가 기본으로 포함됩니다.

AI 리퍼럴 트래픽 모니터링

지금 당장 할 수 있는 일 중 하나는, 애널리틱스에서 AI 리퍼럴 트래픽을 별도 세그먼트로 트래킹하기 시작하는 것입니다.

관찰할 만한 주요 리퍼럴 소스는 다음과 같습니다.

labs.perplexity.ai/referral
chatgpt.com/(none)
chatgpt.com/organic
link.edgepilot.com/referral
platform.openai.com/referral
perplexity/(not set)
claude.ai/referral
copilot.microsoft.com/referral
gemini.google.com/referral

여기에 더해, 앞서 언급한 axios/1.8.4⁠, curl/8.4.0⁠, got(sindresorhus/got)⁠, colly⁠와 같은 HTTP 서명도 서버 로그에서 함께 모니터링해야, 리퍼러 없이 바로 들어오는 에이전트 트래픽까지 잡아낼 수 있습니다.

이렇게 AI 트래픽 세그먼트를 따로 구축해 두면, 지금까지 이야기한 변화들이 실제로 효과를 내고 있는지 보여 줄 선행 지표를 확보하게 됩니다.

개발자 경험(DX)에 대한 더 넓은 시사점

잠시 한 발짝 물러서서 보면, AEO는 단순한 기술 체크리스트를 넘어서는 변화를 가리키고 있다고 느낍니다.

웹 역사 대부분에서, 개발자 포털은 사람의 인지 패턴에 맞춰 설계되어 왔습니다. 점진적 공개(progressive disclosure), 시각적 계층 구조, 인터랙티브 예제, 단계별 튜토리얼 등은 모두, 매 단계에 인간이 직접 개입한다는 전제를 깔고 있습니다.

하지만 에이전트 중심 환경에서는 이런 전제들이 하나씩 깨져 나갑니다.

• 시각적 계층 구조는 의미를 잃습니다. 에이전트는 레이아웃이 아니라 텍스트만 읽습니다.
• 점진적 공개는 장애물이 됩니다. 에이전트는 필요한 정보를 한 번에 다 얻고 싶어 합니다.
• 인터랙티브 예제의 가치는 줄어듭니다. 정적/혹은 API 형태의 동등한 표현이 없으면 소용이 없습니다.
• 사용자 여정은 붕괴합니다. 여러 챕터로 나뉜 튜토리얼이 에이전트에게는 하나의 컨텍스트 로드로 압축됩니다.

이 말이 사람 중심 설계가 쓸모없어졌다는 뜻은 아닙니다. 사람은 여전히 문서를 읽습니다. 다만 이제는 점점 더 AI 어시스턴트의 컨텍스트 안에서 문서를 읽게 된다는 점이 중요합니다. 즉, 궁극적 수혜자는 인간이지만, 직접적인 소비자는 에이전트인 경우가 점점 많아지는 것입니다.

앞으로 정말 잘 만든 문서는, 사람과 에이전트 양쪽을 동시에 만족시켜야 할 가능성이 큽니다. 사람에게는 훑어보기 좋고 구조가 명료하며, 에이전트에게는 기계가 읽기 좋고 토큰 효율적인 문서 말입니다.

AEO 점검 체크리스트

지금 당장 어떤 문서 사이트가 에이전트 친화적인지 평가해야 한다면, 저는 다음을 살펴보겠습니다.

검색·발견(Discovery)

• 루트에 llms.txt⁠가 존재하고, 문서 전체에 대한 구조화된 인덱스를 제공하는가
• robots.txt⁠가 알려진 AI 에이전트 user-agent를 실수로 막고 있지 않은가
• agent-permissions.json⁠이 자동화 클라이언트의 접근 규칙을 정의하고 있는가
• 코드 리포지토리에 관련 문서로 연결되는 AGENTS.md⁠가 존재하는가

콘텐츠 구조

• 문서 페이지를 렌더링된 HTML뿐 아니라 깨끗한 Markdown 형태로도 제공하는가
• 각 페이지는 첫 200단어 안에 명확한 “결과/목표” 문장을 담고 있는가
• 헤딩은 일관되고 계층 구조를 지키고 있는가
• 코드 예제는 설명 바로 뒤에 이어지는가
• 파라미터 레퍼런스는 중첩된 문단 대신 테이블로 제공되는가

토큰 경제(Token economics)

• 문서 페이지별 토큰 수를 추적하고 있는가
• 30,000 토큰을 넘는 단일 페이지는 없거나, 있다면 명확한 청킹 전략이 있는가
• 주요 페이지의 토큰 수를 llms.txt⁠에서도 노출하고 있는가
• 각 페이지의 토큰 수가 메타 태그나 HTTP 헤더 등 페이지 메타데이터로 제공되는가

능력 신호(Capability signaling)

• 각 서비스/API마다 skill.md⁠가 존재하고, “호출 방법”뿐 아니라 “무엇을 할 수 있는지”를 설명하는가
• 각 스킬 문서에 기능, 필요한 입력, 제약 조건, 핵심 문서 링크가 포함되어 있는가
• 가능하다면 에이전트가 직접 붙을 수 있는 MCP 서버를 제공하는가

애널리틱스

• 웹 애널리틱스에서 AI 리퍼럴 소스를 별도 세그먼트로 분리하고 있는가
• 서버 로그에서 알려진 AI 에이전트 HTTP 서명을 모니터링하고 있는가
• AI 대 사람 트래픽 비율에 대한 기준선을 갖고 있는가

UX 브리지

• 문서 페이지에 “Copy for AI” 버튼이 있는가
• URL 규칙(예: .md⁠ 추가)을 통해 Markdown 원본에 접근할 수 있는가

툴링

이런 점검을 자동화하기 위해, 저는 agentic-seo라는 가벼운 감사(audit) 도구를 만들었습니다. 이 도구는 사이트를 스캔해 llms.txt⁠ 존재 여부, robots.txt⁠의 에이전트 차단 여부, 토큰 수, Markdown 제공 여부 등을 확인합니다. Lighthouse의 “에이전트 버전” 정도로 보시면 됩니다. 사이트가 에이전트에게 얼마나 준비되어 있는지 알려주는 도구입니다.

어디서부터 시작할까

이제 이 목록을 보고 어디부터 손대야 할지 막막하다면, 저는 다음 순서를 추천합니다.

1. robots.txt⁠를 점검하라. 10분이면 끝나고, 조용히 에이전트를 틀어막는 상황을 막을 수 있습니다.
2. llms.txt⁠를 추가하라. 몇 시간 투자로 검색·발견성을 즉시 개선할 수 있습니다.
3. 토큰 수를 측정·노출하라. 주말 프로젝트로 할 수 있는 일 중 가장 레버리지가 큽니다.
4. 가장 중요한 API 3개에 대해 skill.md⁠를 작성하라. 에이전트가 가장 먼저 찾게 될 만한 것부터 시작하세요.
5. “Copy for AI” 버튼을 추가하라. 구현은 간단하지만 신호 품질이 크게 올라갑니다.
6. AI 트래픽 모니터링을 설정하라. 지금까지의 모든 작업을 정당화해 줄 데이터를 얻게 됩니다.

마무리

SEO가 우리에게 알려준 교훈은 분명했습니다. 좋은 콘텐츠만으로는 충분하지 않다. 실제 트래픽 패턴에 맞게, 그 콘텐츠를 발견 가능하게 만들어야 한다는 것이죠. 저는 AEO가 같은 교훈을, 단지 소비 주체가 다른 시대에 다시 상기시켜 주는 것이라 생각합니다.

AI 코딩 에이전트는 이미 문서 트래픽에서 무시할 수 없는 비중을 차지하고 있습니다. 이들은 인간 독자와는 근본적으로 다른 방식으로 행동합니다. 그리고 대부분의 개발자 포털은 아직 이들을 염두에 두고 설계되지 않았습니다.

여기서 먼저 움직이는 팀은 분명한 이점을 갖게 될 것입니다. 그들의 API는 에이전트가 우선적으로 추천하고, 성공적으로 통합하고, 다시 찾아오게 되는 대상이 될 겁니다. 반대로 그렇지 못한 팀은, 문서 품질과 실제 에이전트 작업 성공률 사이에 점점 벌어지는 간극을 보게 될 것입니다. 이 간극은 조용히, 그리고 디버깅하기 상당히 어려운 방식으로 나타납니다.

긍정적인 소식도 있습니다. 에이전트를 위해 문서를 개선하는 대부분의 작업은, 사람에게도 문서를 더 좋게 만듭니다. 두 대상이 요구하는 역량은 생각보다 겹치는 부분이 더 많습니다.

llms.txt⁠부터 시작하세요. skill.md⁠를 하나 만들어 보세요. robots.txt⁠를 점검하고, 토큰 수를 측정해 공개하세요. 이 대부분은 주말 정도에 충분히 해볼 수 있는 일이고, 그에 따른 효과는 이미 현실에서 나타나고 있습니다.