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

> Clean Markdown view of GeekNews topic #28588. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=28588](https://news.hada.io/topic?id=28588)
- GeekNews Markdown: [https://news.hada.io/topic/28588.md](https://news.hada.io/topic/28588.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-04-16T11:50:02+09:00
- Updated: 2026-04-16T11:50:02+09:00
- Original source: [addyosmani.com](https://addyosmani.com/blog/agentic-engine-optimization/)
- Points: 3
- Comments: 0

## Topic Body

- 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가 에이전트에 의해 추천·성공적으로 통합·재사용되는 우위** 확보  
- 대응하지 않는 팀은 문서 품질과 실제 에이전트 작업 성공률 사이의 격차가 커지는 **디버그 어려운 조용한 실패 모드**에 직면  
- 에이전트를 위한 구축이 결과적으로 인간에게도 더 나은 문서를 만들며, 두 분야는 분기보다 중첩이 큼

## Comments



_No public comments on this page._