기업이 AI 검색을 준비할 때 지금까지의 질문은 대체로 하나였다. “ChatGPT나 Google AI가 우리 회사를 제대로 찾고 인용하는가?” 그래서 SEO와 GEO는 공개 웹에 정확한 제품·브랜드 원문을 쌓고, 크롤러와 검색 시스템이 이를 안정적으로 읽게 만드는 문제로 발전해 왔다.
그런데 에이전트가 검색을 넘어 예약하고, 주문하고, 사내 시스템을 수정하기 시작하면 질문이 달라진다. 웹사이트가 AI에게 읽히는 것만으로는 부족하다. AI가 어떤 행동을 어떤 입력과 권한으로 실행할 수 있는지까지 기계가 이해해야 한다.
Chrome의 WebMCP, Model Context Protocol의 MCP Apps, Shopify의 Agentic Storefronts가 같은 방향을 가리키는 이유가 여기에 있다. 다음 웹 경쟁은 사람이 보는 페이지를 없애는 것이 아니라, 기존 웹 위에 machine-callable action layer를 추가하는 쪽으로 움직이고 있다.[^1][^2][^3]
GEO는 ‘무엇을 아는가’를 해결하지만 ‘무엇을 할 수 있는가’까지 정의하지 않는다
생성형 검색에서 좋은 웹페이지는 기업의 공식 정보와 제품을 설명하는 원출처다. Google도 2026년 생성형 AI 검색 가이드에서 AI Mode와 AI Overviews를 위한 별도의 마법 같은 최적화보다 기존 SEO 원칙, 공개 가능성, 독자적인 콘텐츠와 정상적인 웹 구조를 우선하라고 안내했다.[^4]
이 단계에서 웹의 역할은 주로 retrieval이다. 사용자가 “서울에서 쓸 수 있는 이런 기능이 있는 제품이 무엇인가”라고 묻고, AI가 여러 출처를 찾아 답을 구성한다. 기업이 해야 할 일은 AI가 회사와 제품의 존재, 사양, 가격정책과 공식 설명을 잘 찾도록 만드는 것이다.
하지만 사용자가 이어서 “그럼 이걸 예약해 줘”, “재고를 확인하고 주문해 줘”, “우리 CRM에 이 고객을 등록해 줘”라고 요청하면 검색만으로는 끝나지 않는다. 이제 시스템은 어떤 함수가 존재하는지, 어떤 인자가 필요한지, 인증이 필요한지, 실행 결과가 무엇인지 알아야 한다.
콘텐츠의 원출처와 행동의 인터페이스는 연결돼 있지만 같은 자산은 아니다.
| 계층 | AI가 묻는 질문 | 기업이 제공해야 하는 것 |
|---|---|---|
| Source layer | 무엇이 사실인가? 무엇을 추천할 수 있나? | 공개 콘텐츠, 제품 데이터, 정책, 문서 |
| Action layer | 무엇을 실행할 수 있나? 어떤 입력이 필요한가? | 구조화된 tool/API, 권한, 상태와 결과 |
| Interaction layer | 사용자가 무엇을 확인하거나 선택해야 하나? | 승인 UI, 옵션 선택, 오류·fallback 화면 |
SEO와 GEO가 첫 번째 계층을 튼튼하게 만드는 작업이라면 agentic web은 두 번째와 세 번째까지 웹 설계 범위를 넓힌다.
AEO의 실제 기술 스택은 생각보다 전통적인 웹에 가깝다
AEO(Answer Engine Optimization)를 별도의 AI 검색 기법으로 보면 과장이 생기기 쉽다. 실제 구현은 기존 SEO 위에서 AI가 신뢰할 원출처를 찾고, 필요한 사실을 추출·인용할 수 있도록 source infrastructure를 정리하는 일에 가깝다.
기술 흐름을 압축하면 이렇다.
Crawl / Index → Canonical / Entity → Retrieval / Citation → Freshness / Measurement
Google은 AI Overviews와 AI Mode가 기존 Search index와 ranking·quality system 위에서 동작한다고 설명한다. 별도의 AEO schema나 llms.txt가 필요하다고 보지 않는다.[^9][^10] 따라서 출발점은 여전히 crawler 접근, 정상적인 indexability, canonical URL, 중복 제거, 안정적인 내부 링크다.
Structured data도 “AI citation booster”라기보다 entity ambiguity를 줄이는 contract로 보는 편이 맞다. Organization, Product, Offer, LocalBusiness처럼 회사·제품·가격·재고·장소 정보를 기계가 일관되게 이해하도록 돕는 역할이다.[^11]
OpenAI도 검색 노출과 모델 학습을 분리한다. OAI-SearchBot은 ChatGPT Search의 discoverability와 연결되고, GPTBot은 모델 학습용 crawler다. 검색에는 노출되면서 학습 crawler는 별도로 제한하는 정책도 가능하다.[^12]
결국 AEO의 핵심은 “AI를 위한 별도 페이지를 만들 것인가”보다 공식 원본이 무엇인지, 어느 URL이 canonical인지, 어떤 사실을 지금 시점의 truth로 볼 수 있는지를 명확하게 만드는 데 있다.
AI가 인용하기 쉬운 문서는 ‘답을 추출하기 쉬운 문서’다
검색 시스템이 페이지를 찾았다고 해서 그 문장이 실제 AI 답변의 근거로 쓰이는 것은 아니다. Retrieval과 citation은 같은 단계가 아니다.
실무적으로 유리한 것은 길게 쓰는 것보다 명확한 citation unit을 만드는 것이다.
예를 들어 다음 문장은 정보가 거의 없다.
WebMCP는 앞으로 웹을 크게 바꿀 수 있는 중요한 기술이다.
반면 다음 문장은 답변 근거로 쓰기 쉽다.
WebMCP는 웹페이지가 AI agent에게 구조화된 tool을 노출하도록 제안하는 proposed standard다. JavaScript API와 HTML form metadata를 사용하며, 아직 모든 브라우저가 보편적으로 지원하는 안정 표준은 아니다.[^1]
이 문장에는 Entity + Function + Mechanism + Status + Caveat가 함께 있다.
좋은 AEO 문체는 AI용 문체라기보다 핵심 답을 먼저 주고, 정의·수치·범위·날짜·예외를 명시하는 문체에 가깝다. 사람이 읽기에도 좋고, 기계가 grounding하기에도 좋다.
이 때문에 “AI를 위해 문장을 무조건 짧게 쪼개라”는 식의 규칙보다, 페이지 초반에 핵심 답이 있고 각 섹션이 하나의 구체적인 질문을 해결하도록 쓰는 편이 더 현실적이다.
화면을 ‘보면서 클릭하는’ 방식에는 한계가 있다
오늘의 브라우저 에이전트는 사람처럼 화면을 해석하고 버튼을 찾아 클릭할 수 있다. 이 방식의 장점은 기존 사이트를 거의 수정하지 않아도 동작할 수 있다는 점이다. 동시에 버튼 위치나 문구가 바뀌고 팝업이 나타나거나 로그인 상태가 달라지면 실패 가능성이 높아진다.
Google이 제안한 WebMCP는 이 문제를 웹페이지 쪽에서 줄이려는 접근이다. 사이트가 JavaScript와 HTML form metadata를 통해 자신이 제공하는 기능을 구조화된 tool로 노출하면, 에이전트가 스크린샷에서 좌표를 추측하는 대신 정의된 동작을 호출할 수 있다. Chrome 문서가 드는 예도 링크 클릭부터 폼 입력, 구매 완료까지 실제 행동이다.[^1]
여기서 중요한 점은 WebMCP가 현재 proposed standard라는 사실이다. Chrome은 이를 점진적으로 추가할 수 있는 기능으로 설명하고 있으며, 모든 브라우저와 사이트가 이미 보편적으로 지원하는 안정된 웹 표준은 아니다. 지금 단계에서 모든 기업이 사이트를 WebMCP 중심으로 다시 짜야 한다는 결론은 이르다.[^1]
그럼에도 설계 방향은 읽을 만하다. HTML이 사람에게 페이지 구조를 알려주듯, 향후 웹은 에이전트에게 “이 사이트에서 허용된 행동과 입력은 무엇인가”를 더 명시적으로 알려줄 가능성이 높다.
Citation에서 Action으로 넘어가는 경계에는 semantic interface가 있다
AI가 웹을 읽는 단계와 실제로 조작하는 단계 사이에는 하나의 중간 계층이 있다. 페이지의 의미와 상태를 기계가 안정적으로 해석할 수 있어야 한다는 것이다.
이 지점에서는 semantic HTML과 ARIA 같은 오래된 웹 표준이 다시 중요해진다. 사람에게는 단순한 “확인” 버튼처럼 보여도, browser agent에게는 역할과 상태가 명시된 인터페이스가 더 안정적이다.
<button
type="submit"
aria-label="주문 확인"
>
주문 확인
</button>
복합 UI에서는 상태까지 드러낼 수 있다.
<button
aria-expanded="false"
aria-controls="shipping-options"
>
배송 옵션
</button>
OpenAI도 browser agent가 웹 인터페이스를 해석할 때 ARIA role·label·state 같은 semantic metadata를 활용한다고 설명한다.[^13]
이 흐름을 보면 AEO와 Agentic Web 사이의 경계가 조금 더 선명해진다.
- AEO는 무엇이 사실인지를 기계가 찾고 인용하기 쉽게 만든다.
- Semantic interface는 어떤 UI 요소가 어떤 의미를 갖는지를 기계가 이해하게 한다.
- Agentic Web은 그 다음으로 어떤 행동을 어떤 조건에서 실행할 수 있는지를 contract로 만든다.
즉 웹은 readable → interpretable → callable의 순서로 기계 친화적인 계층을 넓혀가고 있다.
MCP Apps는 행동과 UI를 다시 묶는다
에이전트가 모든 선택을 대신할 수 있는 것도 아니다. 호텔 객실을 고르고, 좌석을 선택하고, 여러 요금제를 비교하거나, 최종 결제를 승인하는 단계에서는 사용자가 화면을 직접 보는 편이 빠르고 안전할 수 있다.
MCP Apps는 이 지점을 다룬다. Model Context Protocol의 공식 extension은 MCP server가 ui:// resource를 함께 제공해 host가 sandboxed iframe 안에서 interactive UI를 보여줄 수 있도록 한다. Tool이 어떤 UI resource를 쓰는지 미리 선언하고, UI가 일으키는 동작도 MCP의 통신·감사 경로를 통해 처리한다.[^2]
OpenAI의 Apps SDK도 MCP를 기반으로 앱의 logic과 interface를 함께 정의하는 구조를 채택하고 있다. 현재 Apps SDK는 preview이고, custom MCP app의 write/modify action 지원 범위도 제품과 플랜에 따라 다르다. OpenAI 문서에서도 중요한 write action은 권한과 맥락에 따라 사용자 확인을 요구할 수 있다고 설명한다.[^5][^6]
즉 agentic web의 목적은 UI를 없애는 데 있지 않다. 사람이 매번 처음부터 사이트를 탐색할 필요는 줄이되, 중요한 결정을 내려야 할 순간에는 브랜드와 서비스가 가진 UI를 에이전트 안으로 다시 가져오는 방식에 가깝다.
상거래에서는 이미 ‘발견’과 ‘거래’가 분리되고 있다
Shopify의 Agentic Storefronts는 이 구분을 가장 구체적으로 보여준다. Shopify는 상품을 ChatGPT, Google AI Mode와 Gemini, Microsoft Copilot, Meta 같은 AI 채널에서 발견할 수 있도록 구조화된 catalog를 제공한다.[^3]
하지만 실제 구매 흐름은 채널마다 다르다. 9월 17일 현재 Shopify 안내에 따르면 Google AI Mode와 Gemini의 일부 eligible store에서는 대화 화면을 벗어나지 않는 Shopify-powered direct checkout이 순차적으로 제공되고 있다. 반면 ChatGPT에서는 사용자가 상품을 발견한 뒤 기존 온라인 스토어의 checkout으로 이동해 구매를 완료한다.[^7][^8]
이 차이는 중요하다. “AI 쇼핑”이라는 같은 이름 아래에서도 어떤 플랫폼은 discovery까지만 맡고, 어떤 플랫폼은 transaction까지 가져간다. 기업 입장에서는 하나의 AI 채널에 맞춰 사이트 전체를 대체하는 것보다 제품 원본 데이터와 거래 backend를 안정적으로 유지하고, 각 플랫폼이 허용하는 action surface를 연결하는 편이 유연하다.
그래서 agentic commerce가 커져도 기업의 웹사이트와 backend가 사라진다고 단정하기 어렵다. 오히려 사람이 직접 접속하는 storefront, AI가 읽는 catalog, 에이전트가 호출하는 tool, 실제 주문과 결제를 기록하는 backend가 서로 다른 접점으로 나뉠 수 있다.
실제 Action Stack은 ‘tool 호출’보다 훨씬 길다
Agentic commerce를 가장 구체적으로 보면, “AI가 상품을 찾는다”와 “AI가 구매를 끝낸다” 사이에는 여러 시스템이 있다.
Google의 Universal Commerce Protocol(UCP)이 보여주는 흐름은 대략 다음과 같다.[^14]
Product discovery → capability 확인 → checkout session → payment → order state → webhook / readback
즉 action layer는 단순히 buy() 같은 함수를 하나 노출하는 것으로 끝나지 않는다.
실제 구현에서는 다음이 함께 필요하다.
- 어떤 행동이 가능한지 capability를 알려야 한다.
- 어떤 입력과 권한이 필요한지 정의해야 한다.
- 사용자의 결제·변경 의사를 확인해야 한다.
- 같은 요청이 중복 실행되지 않도록 idempotency를 보장해야 한다.
- 실행 뒤 실제 주문 상태를 다시 읽어 성공 여부를 확인해야 한다.
- fraud·risk signal과 예외 상태를 처리해야 한다.
이 구조는 commerce에만 국한되지 않는다.
예약, 견적, CRM 변경, 환불, 계정설정 변경 같은 업무도 결국 비슷하다.
Discover → Authorize → Execute → Confirm → Readback
Agentic Web에서 중요한 것은 “에이전트가 클릭할 수 있는가”보다 에이전트가 시스템의 실제 상태를 안전하게 바꾼 뒤 그 결과를 검증할 수 있는가다.
행동을 열면 권한과 실패 처리가 제품의 일부가 된다
페이지를 읽게 하는 것과 주문을 실행하게 하는 것 사이에는 큰 차이가 있다. 잘못 읽은 문장은 수정할 수 있지만, 잘못 전송한 송금이나 중복 주문은 실제 비용을 만든다.
따라서 기업이 action layer를 열 때는 API를 하나 더 만드는 것으로 끝나지 않는다. 앞에서 정리한 항목은 기능 명세라기보다 실패 비용을 관리하는 장치에 가깝다. 인증은 권한 없는 실행을, 확인 단계는 의도하지 않은 결제를, idempotency는 네트워크 재시도가 만드는 중복 거래를, readback은 “성공했다고 믿었지만 반영되지 않은 상태”를 막는다.
이 원칙은 MCP나 WebMCP만의 특수 규칙이라기보다 거래 시스템의 기본 설계에 가깝다. 에이전트가 사용자를 대신해 행동할수록 이 오래된 기본기가 앞단의 대화 인터페이스만큼 중요해진다.
OpenAI가 full MCP write action에서 관리자 검토, 권한, 위험 경고와 confirmation을 강조하고, MCP Apps가 UI를 sandbox 안에 두며 auditable communication을 요구하는 것도 같은 이유다.[^2][^6]
기업 웹 전략도 두 갈래로 나눠 관리해야 한다
앞으로 기업이 “AI 대응 웹사이트”를 만든다고 할 때 최소 두 종류의 품질을 따로 봐야 한다.
첫 번째는 source quality다. 제품과 회사의 사실이 정확하고, 크롤링 가능하며, 다른 곳에 없는 원자료와 설명을 제공하는가. 이 축은 기존 SEO와 GEO의 연장선이다.
두 번째는 action quality다. 에이전트가 재고 조회, 예약, 견적, 주문, 업무 업데이트 같은 행동을 명확한 contract로 호출할 수 있는가. 실패하면 안전하게 멈추고, 중요한 변경은 확인받고, 결과를 다시 읽어 검증할 수 있는가.
둘 중 하나만 좋아서는 경험이 완성되지 않는다. 잘 알려진 브랜드인데 에이전트가 아무 행동도 할 수 없다면 사용자는 결국 수동 작업으로 돌아간다. 반대로 뛰어난 tool API가 있어도 AI가 그 회사와 상품을 발견하지 못하거나 공식 정보를 신뢰하지 못하면 호출 기회 자체가 생기지 않는다.
그래서 실무 순서는 GEO를 버리고 MCP로 갈아타는 것이 아니다. 먼저 canonical web content와 제품 데이터를 제대로 관리하고, 그 위에 반복적으로 가치가 큰 행동부터 구조화된 tool로 노출한다. 그 다음 인증·승인·관측·fallback을 붙이고, 플랫폼별 지원 수준에 맞춰 UI와 거래 경로를 연결하는 편이 현실적이다.
이 판단이 틀릴 수도 있다. AI 서비스가 앞으로도 대부분 검색과 추천에 머물고 실제 거래나 업무 변경은 계속 기존 앱과 웹으로 넘긴다면 action layer의 중요성은 제한적일 것이다. 또는 WebMCP·MCP 같은 개방형 규격보다 각 대형 플랫폼의 전용 인터페이스가 시장을 지배한다면 기업은 공통 표준보다 채널별 통합에 더 많은 비용을 써야 할 수 있다.
하지만 2026년 현재의 방향은 이미 읽기에서 행동으로 이동하고 있다. WebMCP는 사이트가 구조화된 행동을 노출하는 방법을 제안하고, MCP Apps는 도구와 UI를 같은 에이전트 경험 안에 묶고, Shopify와 Google은 일부 commerce 흐름에서 실제 checkout과 transaction까지 연결하고 있다.[^7][^8][^14]
GEO가 “AI가 우리를 어떻게 이해할 것인가”의 문제라면 다음 질문은 더 운영적이다. AI가 우리 서비스를 이해한 다음, 정확히 무엇까지 대신 실행할 수 있게 할 것인가.
AEO와 Agentic Web은 경쟁하는 개념이 아니다. AEO는 AI에게 ‘무엇이 사실인가’를 제공하는 source infrastructure이고, Agentic Web은 그 사실 위에서 ‘무엇을 실행할 수 있는가’를 정의하는 execution infrastructure다.
앞으로 웹 경쟁은 사람이 보는 페이지를 없애는 방향보다는, 같은 웹 자산을 사람이 읽을 수 있고, AI가 인용할 수 있으며, agent가 안전하게 호출할 수 있는 구조로 확장하는 방향에 더 가깝다.
[^1]: Chrome for Developers, “WebMCP,” published May 18, 2026, updated August 7, 2026. https://developer.chrome.com/docs/ai/webmcp [^2]: Model Context Protocol, “SEP-1865: MCP Apps - Interactive User Interfaces for MCP.” https://modelcontextprotocol.io/seps/1865-mcp-apps-interactive-user-interfaces-for-mcp [^3]: Shopify Help Center, “Shopify agentic storefronts.” https://help.shopify.com/en/manual/online-sales-channels/agentic-storefronts [^4]: Google Search Central, “Latest Google Search Documentation Updates,” May 15, 2026 update on optimizing for generative AI features. https://developers.google.com/search/updates [^5]: OpenAI Help Center, “Build with the Apps SDK,” updated August 2026. https://help.openai.com/en/articles/12515353-build-with-the-apps-sdk [^6]: OpenAI Help Center, “Developer mode and MCP apps in ChatGPT,” updated August 2026. https://help.openai.com/en/articles/12584461-developer-mode-and-mcp-apps-in-chatgpt [^7]: Shopify Help Center, “Selling on Google AI Mode and Gemini.” https://help.shopify.com/en/manual/online-sales-channels/agentic-storefronts/google [^8]: Shopify Help Center, “Setting up agentic storefronts for stores on the Agentic plan.” https://help.shopify.com/en/manual/online-sales-channels/agentic-storefronts/agentic-plan-setup [^9]: Google Search Central, “AI Features and Your Website.” https://developers.google.com/search/docs/appearance/ai-features [^10]: Google Search Central, “Optimizing your website for generative AI features on Google Search.” https://developers.google.com/search/docs/fundamentals/ai-optimization-guide [^11]: Google Search Central, “Organization structured data”; “Product structured data”; “LocalBusiness structured data.” https://developers.google.com/search/docs/appearance/structured-data/organization [^12]: OpenAI Help Center, “Publishers and Developers - FAQ.” https://help.openai.com/en/articles/12627856 [^13]: OpenAI Help Center, publisher/developer guidance for browser agents and semantic web interfaces. https://help.openai.com/en/articles/12627856 [^14]: Google for Developers, “Universal Commerce Protocol — Overview.” https://developers.google.com/merchant/ucp/guides/overview