TL;DR
- AI Agent는 검색 봇이 아닙니다 — 사용자 대신 실제로 브라우저를 조작하고 폼을 제출하는 자동 탐색 주체입니다
- 2026년 현재 가능한 것 — OpenAI ChatGPT agent, Anthropic Claude Computer Use, Google Project Mariner, Microsoft Copilot Actions가 이미 출시
- Agent가 보는 것 — 렌더링된 DOM, 접근성 트리(accessibility tree), ARIA 라벨이 핵심 신호
- Agent-Friendly SEO — 시맨틱 HTML, 명확한 네비게이션, 표준 스키마, llms.txt(제안 단계), MCP 지원
- 중요한 구분 — Agent SEO는 AEO(답변 엔진 최적화)와 다릅니다. AEO는 인용, Agent SEO는 탐색·행동이 목표입니다
2025년부터 2026년 사이, AI Agent가 사용자 대신 직접 웹사이트를 탐색하는 시대가 본격적으로 시작됐습니다. 검색 결과를 보여주던 SEO의 시대에서, AI Agent가 실제로 링크를 클릭하고 폼을 채우는 시대로 넘어가고 있습니다. 이 변화는 SEO의 기본 가정 — 사람이 검색 결과를 보고 클릭한다 — 를 근본부터 바꿉니다.
이 글에서는 AI Agent가 웹을 어떻게 읽는지, 검색 봇과 어떻게 다른지, 그리고 Agent-Friendly SEO가 무엇을 의미하는지 정리합니다. 2026년 현재 가능한 것과 앞으로 표준화될 것을 구분해서 살펴봅니다.
AI Agent란 무엇이고 왜 지금 중요한가
AI Agent는 사용자의 목표를 이해하고, 이를 달성하기 위해 컴퓨터나 웹 브라우저를 직접 조작하는 자동화된 시스템입니다. 기존 챗봇이 텍스트로 답변했다면, Agent는 실제로 마우스를 움직이고 버튼을 클릭하며 폼을 제출합니다.
2025-2026년 주요 출시
출처: OpenAI - Introducing Operator
OpenAI Operator는 2025년 1월 23일 출시되어 ChatGPT Pro 사용자에게 제공됐으며, 2025년 7월 17일 ChatGPT agent로 통합됐습니다.
| Agent | 출시 시점 | 제공사 | 동작 방식 |
|---|---|---|---|
| OpenAI Operator → ChatGPT agent | 2025년 1월 → 7월 통합 | OpenAI | 클라우드 브라우저 |
| Claude Computer Use | 2024년 10월 베타 | Anthropic | 스크린샷-분석-실행 루프 |
| Project Mariner | 2025년 5월 일반 공개 | Google DeepMind | 클라우드 VM, 최대 10개 병렬 |
| Copilot Actions | 2025-2026 단계적 출시 | Microsoft | Edge·Copilot Studio 통합 |
출처: TechCrunch - Google rolls out Project Mariner
Google I/O 2025에서 Project Mariner가 클라우드 기반으로 업데이트되어 최대 10개 작업을 동시 수행할 수 있게 됐습니다.
왜 지금 중요한가
Agent의 실제 사용률은 아직 초기 단계입니다. 그러나 기술 표준, 봇 식별, 접근성 구조는 지금 설계되고 있습니다. 2026년 중반 현재 Agent는 주로 쇼핑·예약·데이터 수집 같은 반복 업무에 쓰이고 있고, 한국 사용자 기준으로는 아직 실험 단계입니다.
하지만 사이트 구조·봇 정책·스키마는 Agent를 염두에 두고 미리 준비할 수 있는 항목입니다.
Agent는 검색 엔진 봇과 어떻게 다른가
검색 엔진 크롤러(Googlebot, GPTBot 등)와 AI Agent는 웹을 읽는 방식이 근본적으로 다릅니다.
검색 봇: 수집만, 상호작용 없음
전통적인 크롤러는 HTML을 가져와서 색인합니다. 링크를 따라가지만 버튼을 누르거나 폼을 제출하지 않습니다. JavaScript 실행 여부는 봇마다 다릅니다.
AI Agent: 브라우저 자체를 조작
AI Agent는 실제 사용자처럼 브라우저를 씁니다. 페이지가 로드된 후의 최종 상태를 보고, 버튼을 누르고, 입력 필드에 타이핑합니다.
출처: Anthropic - Computer use, Claude 3.5 Sonnet
Claude 3.5 Sonnet의 Computer Use는 스크린샷을 분석해 UI 요소를 파악하고, 마우스 이동·클릭·타이핑 같은 실제 동작을 수행하는 루프로 작동합니다.
Agent가 페이지를 인식하는 3가지 경로
출처: No Hacks - How AI Agents See Your Website
AI Agent는 비전(스크린샷), DOM 파싱, 접근성 트리(accessibility tree) 세 가지 방식으로 페이지를 인식하며, 업계는 접근성 트리로 수렴하는 중입니다.
| 방식 | 설명 | 비용·성능 |
|---|---|---|
| 비전(스크린샷) | 이미지로 UI 이해 | 가장 비쌈, 약 5만 토큰 수준 |
| DOM 파싱 | HTML 원본 분석 | 구조 복잡, 노이즈 많음 |
| 접근성 트리 | 시맨틱 구조 추출 | 가장 효율적, 약 4천 토큰 수준 |
접근성 트리는 ARIA 라벨·버튼 역할·헤딩 계층 같은 시맨틱 정보를 담은 요약본입니다. OpenAI Atlas, Microsoft Playwright MCP, Perplexity Comet이 모두 이 방식을 기반으로 동작합니다.
Agent-Friendly SEO의 5가지 원칙
Agent에게 읽히는 사이트는 결국 접근성 잘 된 사이트와 거의 일치합니다. 이 점이 Agent SEO가 완전히 새로운 분야가 아닌 이유입니다.
1. 시맨틱 HTML과 ARIA 라벨
<div>로 모든 걸 만들지 말고 <button>, <nav>, <main>, <article> 같은 네이티브 요소를 써야 합니다. 네이티브 요소는 자동으로 접근성 트리에 올바른 역할(role)을 부여합니다.
<!-- Agent가 읽기 어려움 -->
<div onclick="submitForm()">구매</div>
<!-- Agent가 명확히 이해 -->
<button type="submit" aria-label="상품 구매하기">구매</button>
ARIA는 네이티브 HTML이 부족할 때만 보완재로 사용합니다.
2. JS 의존 최소화, 서버 측 콘텐츠
일부 Agent는 JavaScript 실행이 가능하지만 렌더링 대기 시간은 한정적입니다. 핵심 콘텐츠는 SSR·SSG로 초기 HTML에 포함해야 합니다.
단일 페이지 앱(SPA)에서 탐색이 클라이언트 라우팅으로만 작동하면 Agent가 페이지 전환을 놓칠 수 있습니다. 표준 링크(<a href>) 사용을 유지해야 합니다.
3. 명확한 네비게이션과 페이지 식별자
Agent는 현재 페이지가 어디인지, 어디로 이동하는지 판단해야 합니다. 도움이 되는 요소:
<title>태그 — 페이지마다 고유하고 구체적으로<h1>— 페이지당 하나, 페이지의 핵심 의도를 담기- Breadcrumb — 현재 위치를 계층으로 표현
- URL 구조 — 의미 있는 경로(
/products/shoes/running)
4. 표준 스키마 마크업
출처: Backlinko - 6 Agentic AI Protocols
Agent가 사이트를 탐색할 때 Product, Organization, Action 같은 Schema.org 타입이 의사결정 신호로 활용됩니다.
Agent가 의사결정에 활용할 수 있는 핵심 스키마:
| 스키마 타입 | 용도 |
|---|---|
| Organization | 회사 정체성 확인 |
| Product | 가격, 재고, 평점 |
| Action (BuyAction, ReserveAction) | Agent가 수행 가능한 동작 |
| FAQPage | 빠른 질의응답 참조 |
| BreadcrumbList | 사이트 구조 이해 |
JSON-LD 형식으로 HTML에 직접 포함하는 것이 표준입니다.
5. llms.txt — 제안 단계의 Agent용 사이트 요약
출처: Answer.AI - /llms.txt proposal
2024년 9월 Jeremy Howard(Answer.AI 공동창립자)가 제안한 /llms.txt는 LLM이 사이트를 이해하기 쉽도록 마크다운 기반의 요약을 제공하는 표준안입니다.
llms.txt는 사이트 루트에 /llms.txt 파일을 두어 LLM·Agent에게 사이트 구조와 핵심 문서 링크를 제공하자는 제안입니다. robots.txt·sitemap.xml의 LLM 버전에 가깝습니다.
주의: llms.txt는 공식 표준이 아닙니다. 2026년 중반 현재 일부 문서 사이트(Anthropic, Mintlify, Cloudflare 등)가 자발적으로 채택하고 있지만, Google·OpenAI가 이를 공식적으로 크롤링한다는 증거는 없습니다.
# llms.txt 예시
# 회사 이름
> 회사 소개 한 줄 설명
## 핵심 문서
- [제품 가이드](/docs/product.md): 제품 사용법
- [가격 정책](/pricing.md): 요금제 및 정책
## 참고
- [자주 묻는 질문](/faq.md)
Robots.txt와 에이전트 봇 관리
Agent가 사이트를 방문할 때도 User-Agent를 보냅니다. 현재 식별 가능한 주요 에이전트·크롤러:
출처: Scrunch - Guide to AI User Agents
ChatGPT-User는 사용자가 ChatGPT에서 직접 요청한 브라우징을 수행하는 봇이며, 학습용 GPTBot과 구분됩니다.
| User-Agent | 용도 | 차단 시 영향 |
|---|---|---|
| GPTBot | OpenAI 학습 | 학습 데이터 제외 |
| ChatGPT-User | 사용자 실시간 요청 | ChatGPT 내 탐색 차단 |
| ClaudeBot | Anthropic 학습 | Claude 학습 제외 |
| Claude-User | Claude 사용자 요청 | Claude 내 탐색 차단 |
| PerplexityBot | Perplexity 색인 | Perplexity 결과 제외 |
| Perplexity-User | Perplexity 사용자 요청 | 실시간 인용 제외 |
| Google-Extended | Gemini 학습 | 학습 제외 (검색은 별개) |
# 학습용은 선택 차단, 사용자 요청은 허용
User-agent: GPTBot
Disallow: /
User-agent: ChatGPT-User
Allow: /
User-agent: Claude-User
Allow: /
Agent 트래픽이 증가할수록 User-Agent 판단이 곧 비즈니스 판단이 됩니다. 사용자 요청 봇을 차단하면 해당 Agent 안에서 사이트가 보이지 않습니다.
MCP의 의미 — 사이트가 에이전트에게 도구를 제공하는 시대
출처: Anthropic - Introducing the Model Context Protocol
MCP(Model Context Protocol)는 2024년 11월 Anthropic이 공개한 오픈 표준으로, AI 시스템이 외부 도구·데이터와 연결되는 방식을 표준화합니다.
MCP는 "사이트가 Agent에게 기능 그 자체를 제공하는" 구조입니다. HTML을 긁어서 동작을 추론하는 게 아니라, 사이트가 API처럼 도구 목록을 내놓고 Agent가 그걸 호출합니다.
예: 예약 사이트가 MCP 서버를 노출하면, Agent는 브라우저에서 폼을 채우지 않고 reserve(date, people) 같은 도구를 직접 호출합니다.
2025년부터 OpenAI·Google DeepMind가 MCP를 채택했고, 2025년 12월 Anthropic이 MCP를 Linux Foundation 산하 Agentic AI Foundation에 기부하면서 업계 공통 표준으로 자리잡고 있습니다.
Agent SEO와 MCP의 관계
- HTML 기반 탐색 — Agent가 브라우저로 사이트를 사용 (2026년 주력)
- MCP 기반 실행 — Agent가 사이트의 도구를 직접 호출 (확산 중)
둘은 공존합니다. MCP는 특정 비즈니스(전자상거래, 예약, CRM)에 먼저 자리잡고, 일반 정보 사이트는 여전히 HTML 탐색 대상입니다.
실무 체크리스트 10개
Agent-Friendly SEO를 위해 지금 점검할 수 있는 항목입니다.
| 번호 | 항목 | 점검 방법 |
|---|---|---|
| 1 | 시맨틱 HTML 태그 사용 | <button>, <nav>, <main> 등 네이티브 요소 |
| 2 | ARIA 라벨 (필요한 경우) | 커스텀 컴포넌트에만 보완 |
| 3 | 핵심 콘텐츠 SSR | JS 비활성화 시 HTML에 본문 포함 |
| 4 | 페이지 고유 title·h1 | 중복 없는 명확한 제목 |
| 5 | Breadcrumb 마크업 | BreadcrumbList JSON-LD |
| 6 | Organization·Product 스키마 | 핵심 엔티티 명시 |
| 7 | Action 스키마 (구매·예약 등) | 수행 가능한 동작 표현 |
| 8 | robots.txt Agent 봇 정책 | User-Agent별 허용·차단 명확화 |
| 9 | llms.txt 배치 (선택) | 사이트 요약 + 핵심 문서 링크 |
| 10 | 공식 API·MCP 고려 | 핵심 비즈니스 기능 API화 |
1-8번은 2026년 현재 효과가 확인된 기본 항목이고, 9-10번은 미래 대비 성격이 강합니다.
한국 시장의 Agent-Readiness
한국에서 AI Agent의 일반 사용은 아직 초기입니다. ChatGPT agent·Claude·Gemini의 한국어 사용률은 증가 중이지만, 한국 내 결제·예약 같은 실제 거래형 Agent 시나리오는 2026년 중반 기준 드물게 보입니다.
한국어 접근성 체크포인트
lang="ko"속성 — HTML 루트에 명시- 한국어 ARIA 라벨 — 영문 레이블과 혼재 금지
- 한국 이메일·전화 형식 — tel:·mailto: 스킴 활용
네이버와 Agent의 관계
출처: The Egg - How Naver's AI Search Is Reshaping the Korean Digital Landscape
네이버는 자체 AI 모델 HyperCLOVA X를 기반으로 AI Briefing 등 AI 검색 기능을 확대하고 있으며, 구조화된 콘텐츠를 우선시합니다.
네이버는 자체 크롤러(Yeti)와 자체 AI(HyperCLOVA X) 기반이라, 글로벌 Agent가 네이버 내부 콘텐츠(카페·블로그)에 직접 접근하기는 제한적입니다. 따라서 한국 웹사이트는:
- 글로벌 Agent 대비: 표준 HTML, 시맨틱 구조, 스키마
- 네이버 대비: 네이버 서치어드바이저 사이트맵 제출, 구조화 데이터
두 축을 동시에 챙기는 방식이 현실적입니다.
자세한 기술 가이드는 AI 크롤러가 읽을 수 있는 사이트 만들기를 참고하세요.
한계와 불확실성
Agent-Friendly SEO를 이야기할 때 과장하지 말아야 할 것들이 있습니다.
- 표준 미정립 — llms.txt, WebMCP, Agentic Commerce Protocol 등은 제안 단계이거나 초기 단계입니다
- 트래픽 측정 어려움 — Agent 트래픽은 User-Agent가 불명확하거나 위장되는 경우가 있어 정확한 측정이 어렵습니다
- 보안 이슈 — Agent가 사용자 세션을 공유하면 CSRF·무단 결제 같은 리스크가 커집니다
- 광고 모델 영향 — Agent가 광고를 건너뛰면 광고 기반 매출 모델이 흔들립니다
- 실제 채택률 — 2026년 중반 한국 시장에서 일반 사용자가 거래형 Agent를 일상적으로 쓰는 단계는 아닙니다
이 모든 불확실성에도 불구하고, 접근성·시맨틱 HTML·스키마 같은 기본은 Agent가 성공해도 실패해도 도움이 됩니다. 리스크가 낮은 투자입니다.
자주 묻는 질문
Q1. Agent SEO는 AEO와 같은 개념인가요?
다릅니다. AEO(Answer Engine Optimization)는 ChatGPT·Perplexity 같은 답변 엔진에서 인용되는 것이 목표입니다. Agent SEO는 OpenAI Operator·Project Mariner 같은 Agent가 사이트를 탐색하고 동작을 수행하도록 돕는 것이 목표입니다. 기반 원칙(명확한 구조, 스키마)은 겹치지만 목표가 다릅니다.
Q2. llms.txt를 지금 만들어야 하나요?
필수는 아닙니다. 2026년 중반 기준 공식 표준이 아니고, 주요 검색 엔진이 공식적으로 크롤링한다는 증거도 없습니다. 다만 문서 사이트·기술 제품 사이트라면 만들어두는 것이 추가 비용 없이 미래 대비가 됩니다.
Q3. Agent가 우리 사이트에 왔는지 어떻게 확인하나요?
서버 로그에서 User-Agent를 확인합니다. ChatGPT-User, Claude-User, Perplexity-User, Mariner 같은 문자열을 검색하세요. 단, Agent는 일반 브라우저 User-Agent를 사용할 때도 있어 완벽한 식별은 어렵습니다.
Q4. Agent-Friendly 사이트를 만들면 SEO 점수가 오르나요?
직접적인 Google 순위 요소는 아닙니다. 그러나 Agent-Friendly 설계(시맨틱 HTML, 스키마, 명확한 구조)는 Googlebot에게도 유리합니다. 기존 SEO와 충돌하지 않습니다.
Q5. MCP 서버를 지금 구축해야 하나요?
일반 콘텐츠 사이트라면 우선순위가 낮습니다. 반면 예약·주문·데이터 조회 같은 기능형 비즈니스라면 이미 API가 있는 경우가 많으므로, MCP 래퍼를 추가하는 비용이 크지 않고 Agent 생태계 노출 가치가 있습니다.
마무리: Agent-Friendly SEO는 새 종목이 아니라 오래된 원칙의 재발견이다
AI Agent 시대의 SEO를 요약하면 이렇게 됩니다. 접근성을 잘 지키고, HTML을 의미 있게 쓰고, 구조화 데이터를 붙이는 것. 20년 동안 웹 표준 진영이 주장해온 원칙과 거의 같습니다.
Agent는 아직 초기 단계이고 표준도 미정립입니다. 과장해서 "Agent SEO에 올인하라"는 조언은 2026년 현재 시기상조입니다. 그러나 Agent가 자리잡든 아니든 도움이 되는 준비, 그리고 Agent 시대에만 특별히 의미 있는 준비를 구분해서 접근하면 됩니다.
- 지금 하세요 — 시맨틱 HTML, ARIA, SSR, 표준 스키마, User-Agent별 robots.txt 정책
- 준비해두세요 — llms.txt, MCP 서버 (핵심 기능이 있는 경우)
- 기다리세요 — Agentic Commerce Protocol, WebMCP 같은 미완의 표준
기본에 충실한 사이트는 검색 봇에게도, Agent에게도, 그리고 사람에게도 잘 읽힙니다. Agent-Friendly SEO는 그 원칙의 이름만 새로 붙인 것입니다.
관련 글: