에이전틱 엔진 최적화 (AEO)

• AI 코딩 에이전트의 문서 소비 방식이 인간과 근본적으로 다르기 때문에, 사람 중심 최적화만으로는 점점 더 많은 AI 트래픽이 분석 도구에 잡히지 않고 사라짐
• 에이전트는 문서를 단일 HTTP 요청으로 가져와 토큰 수를 세고 컨텍스트 창에 맞지 않으면 조용히 폐기하므로, 스크롤 깊이·체류 시간·클릭 같은 기존 분석 지표가 전혀 기록되지 않음
• 이에 대응하기 위해 문서를 에이전트가 실제로 사용할 수 있게 구조화·포맷·제공하는 Agentic Engine Optimization(AEO) 개념이 제시됨
• AEO의 핵심은 발견 가능성, 파싱 용이성, 토큰 효율성, 기능 시그널링, 접근 제어이며, 이 중 하나라도 실패하면 에이전트는 콘텐츠를 건너뛰거나 잘못된 출력을 생성
• 초기에 대응하는 팀은 자사 API가 에이전트에 의해 추천·통합되는 우위를 확보하게 되며, 에이전트를 위한 문서화가 결과적으로 인간 독자에게도 더 나은 문서를 만들어냄

AEO란 무엇인가

• Agentic Engine Optimization(AEO) 은 AI 코딩 에이전트가 실제로 활용할 수 있도록 기술 콘텐츠를 구조화·포맷·제공하는 실천 방식
• SEO가 검색 크롤러와 인간 클릭 패턴에 맞춰 최적화였다면, AEO는 자율적으로 콘텐츠를 가져오고 파싱·추론하는 AI 에이전트라는 새로운 소비자를 대상으로 함
• 핵심 고려 요소
  • Discoverability – JavaScript 렌더링 없이 에이전트가 문서를 찾을 수 있는가
  • Parsability – 시각적 레이아웃 해석 없이 머신 판독 가능한가
  • Token efficiency – 일반적인 에이전트 컨텍스트 창 안에 잘림 없이 들어가는가
  • Capability signaling – API가 "어떻게 호출하는지"가 아니라 "무엇을 하는지"를 알리는가
  • Access control – robots.txt가 AI 트래픽을 실제로 허용하는가

에이전트가 문서를 읽는 방식

• 인간 패턴: 문서 홈에 도착해 섹션 이동, 제목 훑기, 코드 샘플 실행, 내부 링크 2~3개 이동, 세션당 4~8분 체류 → 분석 도구가 모두 기록
• 에이전트 패턴: Claude Code, Cursor, Cline, Aider, VS Code, Junie 등 9개 주요 코딩 에이전트의 HTTP 트래픽을 분석한 논문에 따르면, 여러 페이지 탐색이 1~2개의 HTTP 요청으로 압축됨
  • 단일 GET 요청으로 전체 페이지 수신 후 이동, "user journey" 개념이 서버사이드 단일 이벤트로 붕괴
  • 스크롤 깊이, 체류 시간, 버튼 클릭, 튜토리얼 완료, 링크 이동, 폼 상호작용 등 클라이언트사이드 이벤트 전체가 비가시화

AI 트래픽의 지문(fingerprints)

• 서버 로그에서 에이전트 트래픽을 식별할 수 있는 고유 시그니처 존재
  • Aider: Headless Chromium(Playwright), On-demand GET, Mozilla/Safari 풀 user-agent
  • Claude Code: Node.js/Axios, On-demand GET, axios/1.8.4
  • Cline: curl, GET + OpenAPI/Swagger 스윕, curl/8.4.0
  • Cursor: Node.js/got, HEAD probe → GET, got (sindresorhus/got)
  • Junie: curl, 순차 다중 페이지 GET, curl/8.4.0
  • OpenCode: Headless Chromium(Playwright), On-demand GET
  • VS Code: Electron/Chromium, Electron 마커 포함 Chromium 스타일
  • Windsurf: Go/Colly, colly
• 코딩 에이전트 외에도 ChatGPT, Claude, Google Gemini, Perplexity 같은 AI 어시스턴트 웹 서비스도 사용자가 URL을 공유할 때 서버사이드 fetch를 발생시키며 고유 지문 생성

토큰 문제: 문서가 에이전트에게 보이지 않을 수 있음

• 에이전트는 대부분 100K~200K 토큰의 실질적 한계를 가지며, 컨텍스트 관리는 모든 작업에서 활성 제약
• 논문 사례: Cisco Secure Firewall Management Center REST API Quick Start Guide(Version 10.0)는 193,217 토큰, 약 718,000 문자로, 단일 문서만으로 대부분 에이전트의 가용 컨텍스트 창을 소진하거나 초과
• 문서가 너무 길 때 발생 가능한 상황
  • 조용한 잘림으로 중요한 정보 손실
  • 더 짧은 문서를 선호해 해당 문서 건너뜀
  • 청킹 시도로 지연·오류 표면 증가
  • 파라메트릭 지식으로 폴백 — 즉, 환각 생성
• 결론: 토큰 수가 이제 문서의 1급 지표, 페이지별 토큰 추적이 필수

실용적 토큰 목표

• Quick start / getting started 페이지: 15,000 토큰 미만
• 개별 API 레퍼런스 페이지: 25,000 토큰 미만
• 전체 API 레퍼런스: 제품이 아닌 리소스/엔드포인트 단위로 청킹
• 개념 가이드: 20,000 토큰 미만, 세부 내용은 임베드가 아닌 링크로 연결

AEO 스택: 실제로 구축해야 할 것

• AEO는 단일 기법이 아니라 기초부터 표면까지 층을 이루는 시그널·표준의 집합

Layer 1: 접근 제어 (robots.txt)

• 많은 에이전트가 콘텐츠를 가져오기 전에 robots.txt를 먼저 확인하므로, 잘못 설정되면 오류 없이 조용히 문서 접근 차단
• 실행 단계
  • AI 에이전트 user-agent에 대한 의도치 않은 차단 감사
  • Anthropic, OpenAI, Google, Perplexity 크롤러 등 잘 알려진 패턴의 명시적 허용 검토
  • 더 세밀한 제어가 필요하면 agent-permissions.json(자동 상호작용 허용 범위, rate limit, 선호 API 엔드포인트 등을 선언하는 신생 스펙) 활용

Layer 2: 발견을 위한 llms.txt

• yourdomain.com/llms.txt에 호스팅되는 Markdown 형식 평면 파일로, AI 에이전트용 사이트맵 역할
• 구조화된 문서 디렉터리와 설명을 제공해, 에이전트가 전체 사이트를 크롤링하지 않고도 관련 콘텐츠 파악 가능
• 예시 구조: Getting Started(Quick Start Guide, Authentication, Core Concepts), API Reference(REST API Overview, Users API 12K 토큰, Events API 8K 토큰), MCP Integration(MCP Server)
• 좋은 llms.txt의 특징
  • 페이지 이름이 아닌 무엇을 찾을 수 있는지 알려주는 설명
  • 유용한 경우 페이지별 토큰 수 포함
  • 제품 계층이 아닌 작업(task) 단위 구성
  • 자체 크기 5,000 토큰 미만 유지(인덱스가 예산 초과 금지)

Layer 3: skill.md를 통한 기능 시그널링

• llms.txt가 "어디에 있는가"를 알린다면, skill.md는 제품이 "무엇을 할 수 있는가"를 알림
• 에이전트가 산문 문서에서 기능을 추론할 필요 없이 의도(intention)를 엔드포인트·리소스에 선언적으로 매핑
• 인증 서비스 예시 구성
  • What I can accomplish: OAuth 2.0 인증(authorization code, client credentials, PKCE), JWT 토큰 발급·검증, 세션·리프레시 토큰 회전 관리, SSO 연동(SAML, OIDC)
  • Required inputs: Client ID/Secret, 사전 등록된 Redirect URI, 요청 스코프(read:user, write:data, admin)
  • Constraints: 애플리케이션당 분당 1000 토큰 요청, 액세스 토큰 1시간·리프레시 토큰 30일, 퍼블릭 클라이언트는 PKCE 필수
  • Key documentation: OAuth 2.0 Guide, Token Reference, Postman Collection
• 에이전트가 전체 문서를 읽는 컨텍스트 예산을 쓰기 전에 API가 사용자 의도를 충족할 수 있는지 판단 가능

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

• HTML만이 아닌 Markdown 제공 — URL에 .md 추가나 쿼리 파라미터로 원본 Markdown 접근을 허용, 태그·내비게이션·푸터 잡음이 없어 토큰 오버헤드가 극적으로 감소
• 읽기가 아닌 스캔용으로 구조화
  • 일관된 제목 계층(H1 → H2 → H3, 건너뛰기 없음)
  • 각 섹션은 배경이 아닌 결과(outcome)로 시작
  • 코드 예제는 설명 직후 배치
  • 파라미터 레퍼런스는 산문 리스트보다 압축률 높은 테이블 사용
• 사이드바, 브레드크럼, 푸터 링크 같은 내비게이션 잡음 제거
• 각 페이지의 첫 500 토큰에서 "이게 무엇이고, 무엇을 할 수 있으며, 시작하려면 무엇이 필요한지" 답변

Layer 5: 토큰 노출

• llms.txt 인덱스와 페이지 자체(메타데이터 또는 페이지 헤더)에 토큰 수 노출
• 에이전트가 활용하는 판단 예시
  • "이 페이지는 8K 토큰 — 컨텍스트에 전체 포함 가능"
  • "이 페이지는 150K 토큰 — 관련 섹션만 가져와야 함"
  • "컨텍스트 창 초과 — llms.txt 요약 사용"
• 구현은 서버사이드에서 문자 수 카운트 후 약 4로 나눠 추정, 메타 태그나 HTTP 응답 헤더로 노출

Layer 6: "Copy for AI"

• 개발자가 IDE 내 AI 어시스턴트에 문서를 컨텍스트로 포함하려 할 때, 렌더된 HTML 복사는 내비게이션·푸터 잡음까지 포함됨
• 깨끗한 Markdown을 클립보드로 복사하는 "Copy for AI" 버튼은 에이전트가 받는 컨텍스트 품질을 의미 있게 개선
• Anthropic, Cloudflare 등이 이미 변형 버전 출시, 저비용·고시그널

AGENTS.md: 부상하는 기본 표준

• README.md가 인간 개발자의 리포지터리 진입점이었던 것처럼, AGENTS.md는 AI 에이전트의 진입점으로 부상
• 코딩 에이전트는 프로젝트 오픈 시 루트 디렉터리의 AGENTS.md를 찾아 이후 모든 작업에 지침으로 활용
• 좋은 AGENTS.md에 포함할 항목
  • 프로젝트 구조 및 주요 파일 위치
  • 관련 API/서비스 문서의 직접 링크
  • 사용 가능한 개발 샌드박스와 테스트 환경
  • 에이전트가 알아야 할 rate limit과 제약
  • 코드베이스의 선호 패턴과 컨벤션
  • 사용 가능한 경우 MCP 서버 링크
• Cisco DevNet은 이를 오픈소스 프로젝트 GitHub 템플릿의 기본 파일로 채택, 신규 프로젝트 생성 시 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
• 레퍼러 없이 도착하는 직접 에이전트 트래픽은 앞서 언급한 HTTP 지문(axios/1.8.4, curl/8.4.0, got (sindresorhus/got), colly)으로 포착
• 적절한 AI 트래픽 세그먼트 구축은 AEO 작업의 효과를 판단할 선행 지표 제공

개발자 경험에 대한 더 넓은 함의

• 지금까지 개발자 포털은 점진적 공개(progressive disclosure), 시각적 계층, 인터랙티브 예제, 가이드 튜토리얼 등 인간 인지 패턴 중심으로 설계됨
• 에이전트 중심 세계에서 깨지는 전제들
  • 시각적 계층 무의미 — 에이전트는 레이아웃이 아닌 텍스트를 읽음
  • 점진적 공개는 장애물 — 에이전트는 모든 것을 한 번에 원함
  • 인터랙티브 예제는 가치 상실 — 정적/API 등가물이 없으면 무용
  • 유저 저니 붕괴 — 다장 튜토리얼이 단일 컨텍스트 로드가 됨
• 인간 중심 설계가 사라지는 것은 아니지만, 인간도 점점 AI 어시스턴트의 컨텍스트 안에서 문서를 읽게 됨
• 앞으로의 최고 문서는 인간에게는 스캔 가능·잘 구조화, 에이전트에게는 머신 판독·토큰 효율적이어야 함

AEO 감사 체크리스트

Discovery

• 루트에 구조화된 문서 인덱스를 담은 llms.txt 존재
• robots.txt가 알려진 AI 에이전트 user-agent를 의도치 않게 차단하지 않음
• agent-permissions.json으로 자동 클라이언트의 접근 규칙 정의
• 코드 리포지터리에 관련 문서를 연결하는 AGENTS.md 존재

Content structure

• 렌더된 HTML이 아닌 깨끗한 Markdown으로 문서 페이지 제공
• 각 페이지는 첫 200단어 안에 명확한 결과 진술 선두 배치
• 제목은 일관되고 계층적으로 올바름
• 코드 예제는 산문 설명 바로 뒤에 위치
• 파라미터 레퍼런스는 중첩 산문이 아닌 테이블 사용

Token economics

• 문서 페이지별 토큰 수 추적
• 청킹 전략 없이 30,000 토큰을 초과하는 단일 페이지 없음
• 주요 페이지의 토큰 수를 llms.txt에 노출
• 페이지 메타데이터(메타 태그 또는 HTTP 헤더)로 토큰 수 제공

Capability signaling

• skill.md 파일이 각 서비스/API의 호출 방식이 아닌 기능 기술
• 각 skill에 capabilities, required inputs, constraints, key doc links 포함
• 해당되는 경우 직접 에이전트 연동을 위한 MCP 서버 제공

Analytics

• 웹 분석에서 AI 레퍼럴 소스 세그먼트화
• 알려진 AI 에이전트 HTTP 지문에 대한 서버 로그 모니터링
• AI 대 인간 트래픽 비율의 기준선 설정

UX bridge

• 문서 페이지에 "Copy for AI" 버튼 제공
• URL 규약(예: .md 추가)으로 Markdown 원본 접근 가능

Tooling

• 저자는 agentic-seo라는 경량 감사 도구 배포, llms.txt, robots.txt 에이전트 차단, 토큰 수, Markdown 가용성 등을 스캔 — 에이전트 준비도를 위한 Lighthouse 개념

어디서부터 시작할지

• 권장 순서
  1. robots.txt 감사 — 10분 작업, 조용한 에이전트 잠금 예방
  2. llms.txt 추가 — 수 시간 작업, 즉각적 발견 가능성 향상
  3. 토큰 수 측정·노출 — 주말 프로젝트, 높은 레버리지
  4. 상위 3개 API에 대한 skill.md 작성 — 에이전트가 가장 많이 접근할 대상부터
  5. "Copy for AI" 버튼 추가 — 저비용·고시그널
  6. AI 트래픽 모니터링 설정 — 나머지 작업을 정당화할 데이터 확보

마무리

• SEO가 "훌륭한 콘텐츠만으로는 부족하며 해당 시대의 실제 트래픽 패턴에 맞게 발견 가능하게 만들어야 함"을 가르쳤듯, AEO는 새로운 소비자에 대한 같은 교훈
• AI 코딩 에이전트는 이미 문서 트래픽에서 상당하고 증가하는 비중을 차지하며, 인간 독자와 근본적으로 다르게 동작
• 초기 대응 팀은 자사 API가 에이전트에 의해 추천·성공적으로 통합·재사용되는 우위 확보
• 대응하지 않는 팀은 문서 품질과 실제 에이전트 작업 성공률 사이의 격차가 커지는 디버그 어려운 조용한 실패 모드에 직면
• 에이전트를 위한 구축이 결과적으로 인간에게도 더 나은 문서를 만들며, 두 분야는 분기보다 중첩이 큼