WebMCP 3편: Agentic SEO — 에이전트 시대에 웹사이트는 무엇이 달라져야 하나

2010년대 초, 모바일 검색 트래픽이 올라오기 시작할 때 먼저 반응형 웹을 준비한 사이트는 이후 몇 년간 유리한 고지를 점했습니다. WebMCP는 그 분기점과 닮아 있습니다. SEO 전문가 Dan Petrovic은 WebMCP를 "구조화 데이터 이후 기술 SEO의 가장 큰 변화"라고 불렀습니다. 구조화 데이터가 "이 페이지가 무엇인지"를 AI에게 알렸다면, WebMCP는 "이 페이지에서 무엇을 할 수 있는지"를 알립니다. SEO → GEO → AEO로 이어지는 흐름의 끝에서, 웹사이트 전략의 기준이 어떻게 바뀌는지 실무 관점으로 정리했습니다.

---

이 포스트 한 줄 요약 → SEO(검색 노출) → GEO(AI 인용) → AEO(에이전트 실행)로 최적화 패러다임 진화 중 → 구조화 데이터: "이 상품은 10만원이다" → WebMCP: "장바구니에 담는 함수는 이것이다" → 에이전트가 실행 가능한 사이트 = 트랜잭션 의도 검색에서 경쟁 우위 → WebMCP 미구현 사이트는 에이전트가 도구 찾지 못해 경쟁사로 라우팅될 수 있음 → 현재 공식 Google 검색 랭킹 요소 아님 — 과대 적용 금물 → 우선순위: 폼 정리·시맨틱 HTML·속도 기반 다진 후 WebMCP 적용 → CAPTCHA·인증 플로우가 에이전트를 막는 가장 큰 장벽 → Schema.org + WebMCP는 대체 관계가 아닌 보완 관계

---

SEO에서 AEO까지 — 최적화의 진화

웹사이트 최적화의 목표는 시대마다 달라졌습니다.

SEO(Search Engine Optimization) 시대에는 검색 엔진 크롤러가 페이지를 이해하도록 만들었습니다. 키워드, 메타 태그, 백링크가 핵심 지표였습니다. 목표는 "검색 결과 상위 노출"이었습니다.

GEO(Generative Engine Optimization) 시대에 AI 검색이 등장하면서 목표가 바뀌었습니다. ChatGPT, Gemini, Perplexity가 답변을 생성할 때 내 사이트를 인용하게 만드는 것이 새로운 과제가 됐습니다. 구조화 데이터, E-E-A-T, 명확한 팩트 제공이 중요해졌습니다.

AEO(Agentic Engine Optimization) 는 그 다음 단계입니다. AI가 정보를 인용하는 수준을 넘어 사용자를 대신해 실제로 행동을 실행하는 시대에서, 내 사이트가 에이전트가 실행할 수 있는 도구를 갖추고 있느냐가 핵심이 됩니다.

사용자: "로봇청소기 괜찮은 거 하나 사줘"

AEO 미구현 사이트 → 에이전트가 DOM 파싱 시도 → 실패 또는 포기
AEO 구현 사이트   → 에이전트가 searchProducts() 호출
                 → addToCart() 호출 → 결제 시작

트랜잭션 의도 검색에서 에이전트가 실행 가능한 사이트를 선택한다면, 경쟁 우위는 "어떤 사이트가 더 잘 찾히느냐"에서 "어떤 사이트가 더 잘 실행되느냐"로 옮겨갑니다.

---

구조화 데이터 vs WebMCP — 무엇이 다른가

둘은 대체 관계가 아닙니다. 역할이 다릅니다.

항목 Schema.org 구조화 데이터 WebMCP

목적	페이지 내용 이해	페이지에서 실행 가능한 행동 정의
예시	"이 상품은 10만원, 재고 있음"	"장바구니 추가 함수: productId, quantity"
소비 주체	검색 엔진 크롤러	브라우저 내 AI 에이전트
적용 방법	JSON-LD, Microdata	HTML 어노테이션, JS 등록
현재 성숙도	검색 랭킹 직접 영향	실험적 (Origin Trial 단계)

실무에서 두 가지를 함께 쓰는 것이 맞습니다. 구조화 데이터로 "이 페이지가 무엇인지" 알리고, WebMCP로 "이 페이지에서 무엇을 할 수 있는지" 알립니다.

{
  "@context": "<a href=https://schema.org/>https://schema.org/</a>",
  "@type": "Product",
  "name": "로봇청소기 X1",
  "offers": {
    "@type": "Offer",
    "price": "499000",
    "priceCurrency": "KRW",
    "availability": "<a href=https://schema.org/InStock>https://schema.org/InStock</a>"
  }
}

if ('modelContext' in navigator) {
  navigator.modelContext.registerTool({
    name: 'addToCart',
    description: '로봇청소기를 장바구니에 추가합니다.',
    inputSchema: {
      type: 'object',
      properties: {
        productId: { type: 'string' },
        quantity:  { type: 'number', default: 1 },
      },
      required: ['productId'],
    },
    async execute({ productId, quantity = 1 }) {
      const res = await cartAPI.add(productId, quantity);
      return { content: [{ type: 'text', text: `추가 완료: ${res.total}원` }] };
    },
  });
}

---

어떤 사이트가 먼저 움직여야 하나

모든 사이트가 지금 당장 WebMCP를 도입해야 하는 건 아닙니다. 에이전트 트래픽의 영향이 큰 순서대로 우선순위가 달라집니다.

우선순위 높음 — 지금 실험 시작

트랜잭션 의도 방문자가 많고, 에이전트가 대신 실행하면 가치가 큰 사이트들입니다.

✅ 여행·항공·호텔 예약 플랫폼  (검색·예약·결제가 핵심 플로우)
✅ 이커머스 사이트              (상품 검색·필터·장바구니·구매)
✅ SaaS 플랫폼                  (플랜 비교·데모 신청·온보딩)
✅ 금융 서비스                  (계좌 조회·이체·상품 비교)
✅ 음식 배달·예약 서비스        (메뉴 탐색·주문·결제)

우선순위 낮음 — 표준 안정 후 대응

⏳ 콘텐츠·미디어 사이트   (정보 소비 중심, 실행 행동 적음)
⏳ 포트폴리오·브로셔 사이트 (트랜잭션 없음)
⏳ 사내 인트라넷           (브라우저 에이전트 도달 범위 밖)

---

핵심 도구 선정 — 무엇을 에이전트 도구로 노출할까

사이트의 모든 기능을 도구로 노출할 필요는 없습니다. 에이전트가 사용자를 대신해 실행할 때 가장 가치가 큰 행동을 골라야 합니다.

도구 선정 기준

사용자가 "해줘"라고 말할 수 있는 행동인가?
→ "항공권 검색해줘" ✅
→ "내 예약 확인해줘" ✅
→ "결제해줘" ✅
→ "헤더 색상 바꿔줘" ❌ (UI 조작, 에이전트 불필요)

업종별 핵심 도구 예시

이커머스:

searchProducts      — 키워드·카테고리·가격 필터 상품 검색
getProductDetail    — 상품 상세 정보 조회
checkInventory      — 재고 확인
addToCart           — 장바구니 추가
getCartContents     — 장바구니 조회
initiateCheckout    — 결제 시작

여행 예약:

searchFlights       — 출발지·도착지·날짜·인원으로 항공편 검색
searchHotels        — 지역·날짜·인원으로 호텔 검색
checkAvailability   — 선택 상품 재고·가용성 확인
makeReservation     — 예약 진행
getReservationDetail — 예약 내역 조회

SaaS:

comparePlans        — 플랜 기능·가격 비교
requestDemo         — 데모 신청
startTrial          — 무료 체험 시작
getUsageStats       — 사용량 통계 조회

---

에이전트를 막는 장벽 — 지금 당장 점검해야 할 것들

WebMCP 도구를 잘 정의해도, 에이전트가 사이트에 접근하는 과정에서 막히면 의미가 없습니다.

① CAPTCHA

가장 흔한 장벽입니다. reCAPTCHA v2("로봇이 아닙니다")는 에이전트를 원천 차단합니다. 봇 방어가 필요하다면 reCAPTCHA v3(행동 기반, 비가시적)나 hCaptcha의 에이전트 허용 설정을 검토해야 합니다. WebMCP 도구 실행 경로에는 CAPTCHA를 배치하지 않는 것이 기본 원칙입니다.

② 인증 플로우

사용자가 로그인된 세션을 에이전트가 사용하는 구조이므로, 인증 자체가 에이전트 차단 요소가 되면 안 됩니다. 세션 쿠키 기반 인증은 에이전트와 호환됩니다. 별도의 봇 감지 레이어가 정상 에이전트 세션을 차단하고 있진 않은지 확인해야 합니다.

③ 동적 렌더링 의존

WebMCP 도구 등록 코드가 복잡한 JS 번들 로딩 이후에 실행된다면, 에이전트가 페이지를 충분히 로드하기 전에 도구를 탐색할 수 있습니다. 도구 등록 코드는 가능한 한 빠른 시점에 실행되도록 배치해야 합니다.

④ 폼 구조 문제

Declarative API로 기존 폼을 활용할 계획이라면 폼 자체가 에이전트 친화적이어야 합니다.

<!-- ❌ 에이전트가 파라미터를 매핑하기 어려운 폼 -->
<input name="f1" placeholder="입력하세요" />
<input name="f2" placeholder="입력하세요" />

<!-- ✅ 명확한 name·toolparamdescription이 있는 폼 -->
<input
  name="departure_city"
  placeholder="서울"
  toolparamdescription="출발 도시명 (예: 서울, 부산)"
/>
<input
  name="arrival_city"
  placeholder="도쿄"
  toolparamdescription="도착 도시명 (예: 도쿄, 오사카)"
/>

---

지금 당장 할 수 있는 AEO 체크리스트

기반 작업 (WebMCP 무관하게 먼저)
□ 핵심 트랜잭션 플로우 파악 (구매·예약·신청·검색)
□ Schema.org 구조화 데이터 적용 완료
□ 시맨틱 HTML, 명확한 폼 name 속성
□ Core Web Vitals 기준 이상 (LCP·CLS·INP)
□ CAPTCHA → 에이전트 친화적 방식으로 교체 검토

WebMCP 실험 (Chrome 149 Origin Trial)
□ Chrome Developer Console에서 Origin Trial 등록
□ 핵심 플로우 1개 선택 → Declarative API 적용
□ 복잡한 플로우 1개 → Imperative API 등록
□ Chrome DevTools 확장으로 도구 등록 확인
□ 스테이징에서 Gemini in Chrome으로 도구 호출 테스트

모니터링
□ Google Search Console AI 트래픽 채널 추적
□ 에이전트 유입 vs 일반 유입 전환율 비교
□ 도구 호출 로그 수집 (execute 함수 내 analytics)

---

과대 적용 주의 — 아직 아닌 것들

WebMCP를 지금 당장 전사 전략의 핵심에 놓는 건 이릅니다. 현실적인 리스크를 명확히 봐야 합니다.

WebMCP는 공식 구글 검색 랭킹 요소가 아닙니다. 구현한다고 검색 순위가 올라가지 않습니다. Firefox와 Safari가 지원을 약속하지 않은 상태에서 사이트 트래픽의 30%는 WebMCP 도달 범위 밖입니다. 스펙이 Origin Trial 단계이므로 API 형태가 바뀔 수 있습니다. 실제 Gemini in Chrome의 WebMCP 지원은 아직 "곧 지원 예정" 상태입니다.

합리적인 접근은 이렇습니다.

지금 (2026년 상반기)
→ 기반 다지기 (폼 정리, 시맨틱 HTML, Schema.org)
→ Origin Trial로 핵심 도구 1~2개 실험

2026년 하반기
→ Gemini in Chrome WebMCP 정식 지원 시
→ 도구 커버리지 확대, 에이전트 트래픽 데이터 수집

2027년~
→ Firefox·Safari 지원 여부 확인 후 전략적 투자 결정

---

✅ 결론

항목 평가

장기 전략 방향성	✅ SEO→GEO→AEO 흐름은 명확
트랜잭션 사이트 즉시 실험 가치	✅ 얼리 어답터 이점 가능성
지금 당장 검색 순위 영향	❌ 공식 랭킹 요소 아님
전사 전략 핵심에 배치	❌ Origin Trial 단계에서는 이름
Schema.org 병행	✅ 둘은 보완 관계
CAPTCHA·인증 플로우 점검	✅ WebMCP보다 먼저 해야 할 것

WebMCP 3편 시리즈를 마무리하면서 핵심 한 줄로 정리합니다. "내 사이트가 검색되는가"가 SEO의 질문이었다면, "내 사이트에서 에이전트가 행동할 수 있는가"가 AEO의 질문입니다. 지금 당장 WebMCP 전면 도입보다는, 기반을 다지고 Origin Trial로 실험하면서 표준 안착을 지켜보는 것이 실무적으로 가장 올바른 타이밍입니다.

---

관련 포스트

https://cell-devlog.tistory.com/258

브라우저가 에이전트를 위한 API 레이어가 된다 — WebMCP 1편: 표준의 탄생

https://cell-devlog.tistory.com/259

WebMCP 2편: Declarative·Imperative API 직접 구현해보기