Google I/O 2026에서 놓친 핵심 요소: 에이전트 준비가 된 (Agent-Ready) 웹사이트

이 글은 Google I/O Writing Challenge를 위한 제출물입니다.

모두가 Gemini, Antigravity, AI Mode, 그리고 코딩 에이전트(coding agents)에 대해 이야기하고 있습니다. 저는 웹사이트에 대해 이야기하고 싶습니다. 왜냐하면 저에게 가장 큰 울림을 주었던 Google I/O 2026의 발표는 단순히 모델 발표나 IDE 업데이트, 혹은 또 다른 생산성 기능에 관한 것이 아니었기 때문입니다. 그것은 여러 발표 뒤에 숨겨진 더 큰 패턴, 즉 웹이 에이전트화(agentic)되고 있다는 사실이었습니다.

이는 웹 개발자의 직무를 변화시킵니다. 수년 동안 우리는 주로 세 가지 대상, 즉 브라우저를 사용하는 인간, 페이지를 인덱싱하는 크롤러(crawlers), 그리고 문서를 순위 매기는 검색 엔진(search engines)을 위해 웹사이트를 구축해 왔습니다. Google I/O 2026 이후, 저는 네 번째 대상을 추가해야 한다고 생각합니다. 바로 사용자를 대신하여 읽고, 추론하고, 비교하고, 검사하고, 클릭하고, 도구를 호출하며, 행동하는 AI 에이전트(AI agents)입니다.

그렇다고 해서 인간을 신경 쓰는 일을 멈춰야 한다는 뜻은 아닙니다. 오히려 그 반대입니다. 에이전트 준비가 된(agent-ready) 최고의 웹사이트는 대개 인간에게도 더 나은 웹사이트입니다. 즉, 더 명확하고, 더 의미론적(semantic)이며, 더 접근성(accessible)이 높고, 더 안정적이며, 모호함이 적습니다. 하지만 이는 더 이상 "브라우저에서 보기 좋게 보이는 것"만으로는 충분하지 않다는 것을 의미합니다. 이제 웹사이트는 더 깊은 질문에 답할 수 있어야 합니다: "AI 시스템이 이 페이지의 의미를 이해하고, 주장하는 바를 검증하며, 노출된 정보에 따라 안전하게 행동할 수 있는가?"

저에게 그것은 Google I/O 2026에서 누락된 계층, 즉 에이전트 준비가 된(agent-ready) 웹사이트입니다.

제가 집중하고 있는 발표: WebMCP와 에이전트 웹(agentic web)

Google I/O 2026에는 많은 AI 관련 발표가 있었습니다. Google 자체의 I/O 2026 요약본은 더 유능한 모델, 에이전트 경험(agentic experiences), Antigravity, 검색에서의 정보 에이전트(Information agents in Search), Gemini Spark, Universal Cart, 그리고 제품 전반에 걸친 광범위한 Gemini 통합을 중심으로 행사를 구성합니다. 하지만 웹 개발자들에게 가장 과소평가되었다고 느껴지는 발표는 Chrome 팀의 에이전트 웹(agentic web) 관련 작업, 특히 WebMCP와 "Google I/O 2026의 15가지 업데이트: 에이전트 웹에 동력을 공급하다"에서 발표된 광범위한 Chrome 업데이트 세트입니다.

WebMCP의 핵심 아이디어는 단순하지만 강력합니다. 웹사이트는 브라우저 기반 에이전트(browser-based agents)가 더 높은 신뢰성, 정밀도 및 문맥(context)을 가지고 사용할 수 있도록 구조화된 도구(structured tools)를 노출할 수 있어야 한다는 것입니다. 에이전트가 복잡한 인터페이스를 시각적으로 추측하며 헤매게 만드는 대신, WebMCP는 웹사이트가 동작을 더 기계 친화적인(machine-friendly) 방식으로 설명할 수 있도록 하는 것을 목표로 합니다. Chrome 팀은 이를 JavaScript 함수 및 HTML 폼(forms)과 같은 구조화된 도구를 브라우저 기반 에이전트에게 노출하기 위해 제안된 개방형 웹 표준(open web standard)이라고 설명합니다. 이것이 중요한 이유는 웹사이트의 역할이 바뀌기 때문입니다. 웹사이트는 더 이상 단순한 페이지들의 집합이 아닙니다. 웹사이트는 이해 가능한 기능(capabilities)의 집합이 될 수 있습니다. 예를 들어, 에이전트가 여행 예약 흐름을 단계별로 클릭하며 시도하는 대신, 사이트는 가용성 확인, 옵션 비교 또는 일정 생성(itinerary building)을 위한 구조화된 도구를 노출할 수 있습니다. 사용자는 적절한 경우 여전히 제어권과 승인이 필요하겠지만, 상호작용은 더 명시적이고 덜 취약해집니다. 이것은 단순한 자동화가 아닙니다. 이것은 웹사이트와 에이전트 사이의 새로운 계약입니다.

WebMCP를 넘어 이것이 중요한 이유
중요한 부분은 WebMCP 자체만이 아닙니다. 중요한 것은 방향성입니다. Google I/O 2026은 단순히 질문에 답하는 것이 아니라 사용자가 작업을 완료하도록 돕는 AI 시스템을 반복적으로 가리켰습니다. Google은 Gemini 3.5를 "최첨단 지능과 실행(action)을 결합한" 모델 제품군으로 설명했으며, Gemini 3.5 Flash는 에이전트 중심(agentic) 및 코딩 워크플로(workflows)를 위해 배치되었습니다. Google의 I/O 2026 컬렉션은 또한 검색(Search)에서의 정보 에이전트(Information agents), Gemini Spark, Universal Cart, 그리고 Antigravity에서의 에이전트 우선(agent-first) 개발 플랫폼을 강조합니다. 이와 병행하여, Google Search Central은 검색의 생성형 AI 기능을 위해 웹사이트를 최적화하는 가이드를 게시했습니다.

해당 가이드는 SEO (검색 엔진 최적화)를 여전히 고려 대상에 두되, 환경을 재정의합니다. 생성형 AI 기능은 검색 증강 생성 (Retrieval-Augmented Generation, RAG) 및 쿼리 팬아웃 (Query Fan-out)과 같은 기술을 사용하며, Google은 명확한 기술적 구조, 크롤링 가능성 (Crawlability), 독창적인 비범용 콘텐츠 (Unique non-commodity content), 그리고 에이전트 경험 인식 (Agentic-experience awareness)을 명시적으로 권장합니다. 이어 web.dev는 에이전트 친화적인 웹사이트를 구축하기 위한 지침을 발표하며 더욱 구체적인 지점을 짚어주었습니다. 즉, 에이전트는 스크린샷, DOM 구조, 접근성 트리 (Accessibility tree)를 포함한 다양한 신호를 통해 웹사이트를 해석할 수 있다는 것입니다. 저에게 이러한 발표들은 서로 연결되어 있습니다. 검색은 더욱 생성형으로 변하고 있습니다. 브라우저는 더욱 에이전트화 (Agentic)되고 있습니다. 개발자 도구는 더욱 자율화 (Autonomous)되고 있습니다. 그리고 웹사이트는 전통적인 사용자처럼 행동하지 않는 시스템의 입력값 (Inputs)이 되어가고 있습니다. 이는 매우 중대한 변화입니다.

기존의 웹 계약이 변하고 있습니다. 기존의 웹 계약은 다음과 같은 모습이었습니다: 페이지를 발견 가능하게 만들 것, 콘텐츠를 인덱싱 (Indexable) 가능하게 만들 것, 인터페이스를 인간이 사용할 수 있게 만들 것, 페이지를 충분히 빠르게 만들 것, 콘텐츠의 순위를 높일 것. 그 계약은 여전히 중요합니다. 하지만 더 이상 완전하지 않습니다. 새로운 계약에는 다음과 같은 질문들이 추가됩니다: AI 시스템이 이 페이지에서 정확한 정보를 검색할 수 있는가? AI가 주요 콘텐츠와 장식적인 노이즈를 구분할 수 있는가? 버튼, 양식(Form) 또는 컨트롤의 목적을 식별할 수 있는가? 가격, 가용성, 날짜, 정책, 제약 조건 및 예외 사항을 이해할 수 있는가? 접근성 트리 (Accessibility tree)를 신뢰할 수 있는 기능적 지도로 사용할 수 있는가? 추측 없이 동작을 수행할 수 있는가? 사용자 확인 없이 위험하거나 되돌릴 수 없는 단계를 피할 수 있는가? 이것이 바로 에이전트 준비 (Agent readiness)가 시작되는 지점입니다. 이것은 "이름만 바꾼 SEO"가 아닙니다. "마법 같은 파일 하나를 추가하고 AI 시스템이 자신을 인용하기를 바라는 것"도 아닙니다. 이것은 콘텐츠, 마크업 (Markup), 인터페이스 동작 및 액션 전반에 걸쳐 모호함을 줄여나가는 규율 (Discipline)입니다.

SEO (검색 엔진 최적화)는 여전히 유효하지만, 그것이 전부가 아닙니다. Google의 새로운 생성형 AI 검색 가이드라인에서 가장 유용한 부분 중 하나는 AI 검색을 완전히 별개의 세계로 취급하기를 거부한다는 점입니다. Google은 Search (검색) 내의 생성형 AI 기능이 핵심적인 Search 랭킹 및 품질 시스템에 뿌리를 두고 있기 때문에, 기초적인 SEO 관행이 여전히 중요하다라고 말합니다. 이는 중요한 지점입니다. 크롤링 가능성 (Crawlability), 인덱싱 가능성 (Indexability), 기술적 명확성 (Technical clarity), 유용한 콘텐츠 (Helpful content), 좋은 페이지 경험 (Good page experience), 그리고 구조화된 정보 (Structured information)는 구식 기술이 아닙니다. 하지만 저는 이것을 "아무것도 변하지 않았다"라고 읽지 않습니다. 저는 다음과 같이 해석합니다. SEO는 여전히 토대(Foundation)로 남지만, AI 에이전트 (AI agents)가 그 토대 위에 새로운 상호작용 계층 (Interaction layer)을 추가한다는 것입니다. 페이지가 인덱싱될 수 있어도 에이전트가 사용하기에는 어려울 수 있습니다. 페이지가 랭킹에 오를 수 있어도 여전히 혼란스러운 양식 (Form)을 노출할 수 있습니다. 페이지가 구조화된 데이터 (Structured data)를 가지고 있어도 모호한 UI 레이블 (UI labels) 뒤에 중요한 맥락 (Context)을 숨길 수 있습니다. 페이지가 아름다울 수 있어도 비인간적 탐색 (Non-human navigation) 관점에서는 기능적으로 망가져 있을 수 있습니다. 이는 작업의 목표가 "문서 찾기"가 아니라 "여정 완료하기 (Complete a journey)"일 때 특히 그러합니다. 호텔 페이지를 찾는 것과, 객실 유형을 이해하고, 날짜를 확인하며, 취소 정책을 비교하고, 접근성 옵션을 선택하며, 예약 요청을 준비하는 것은 별개의 문제입니다. 에이전트 준비성 (Agent readiness)이 중요한 지점은 바로 그 두 번째 경험입니다.

나의 비판: 에이전트 중심의 웹은 명확성에 보상하거나, 취약한 웹사이트를 처벌할 수 있습니다. 나의 가장 큰 우려는 에이전트 기반 브라우징 (Agentic browsing)이 잘 설계된 웹사이트와 취약한 인터페이스 (Fragile interfaces) 사이의 격차를 벌릴 수 있다는 점입니다. 깨끗하고 의미론적이며 (Semantic) 접근 가능한 (Accessible) 웹사이트는 에이전트가 이해하고 작동하기 더 쉬워질 것입니다. 시각적으로는 인상적이지만 구조적으로 혼란스러운 웹사이트는 인간에게는 좋아 보일지라도 실제로는 유용성이 떨어지게 될 것입니다. 이는 많은 현대적 인터페이스가 시각적 세련미에는 최적화되어 있지만 의미론적 명확성 (Semantic clarity)에는 최적화되어 있지 않기 때문에 중요합니다. 우리는 버튼 대신 클릭 가능한 div를 사용합니다. 플레이스홀더 (Placeholder)가 더 깔끔해 보인다는 이유로 레이블 (Labels)을 숨깁니다. 우리는 아름다워 보이지만 약한 역할 (Roles)과 이름 (Names)을 노출하는 커스텀 컨트롤 (Custom controls)을 구축합니다.

우리는 자동화로 전환하기 어려운 호버 상태 (Hover states)에 의존합니다. 우리는 중요한 정보를 모달 (Modals), 아코디언 (Accordions), 캐러셀 (Carousels), 그리고 애니메이션이 많은 레이아웃 (Animation-heavy layouts)에 분산시켜 놓습니다. 우리는 인간은 결국 이해할 수 있지만, 기계는 추론해야만 하는 양식 (Forms)을 만듭니다. 인간에게 이것은 짜증스러운 일입니다. 에이전트 (Agents)에게 이것은 취약한 (Brittle) 일입니다. 그리고 개발자에게 이것은 경고입니다. 에이전트 중심의 웹 (Agentic web)은 더 나은 모델만 필요로 하는 것이 아닙니다. 더 나은 웹사이트가 필요할 것입니다.

에이전트 준비 스택 (The Agent Readiness Stack)
다음은 Google I/O 2026 이후 제가 사용할 정신적 모델 (Mental model)입니다. 저는 이것을 에이전트 준비 스택 (Agent Readiness Stack)이라고 부릅니다. 여기에는 다섯 가지 계층이 있습니다.

1. 크롤링 가능성 (Crawlability)
   에이전트가 당신의 콘텐츠에 대해 추론하기 전에, 콘텐츠는 발견 가능하고 접근 가능해야 합니다. 이것은 전통적인 SEO (Search Engine Optimization)가 이미 잘 알고 있는 계층입니다: 중요한 페이지를 실수로 차단하지 마십시오; 중요한 콘텐츠는 마땅히 공개적으로 도달할 수 있어야 합니다; 합리적인 내부 링크 (Internal linking)를 사용하십시오; 불필요한 중복을 피하십시오; JavaScript로 렌더링된 콘텐츠를 검색 시스템이 접근할 수 있도록 유지하십시오; 적절한 경우 깨끗한 상태 코드 (Status codes), 표준 URL (Canonical URLs), 그리고 사이트맵 (Sitemaps)을 유지하십시오. 이것은 화려하지 않지만, 기초적입니다. 페이지를 찾을 수 없다면 다른 것은 아무런 의미가 없습니다.

2. 콘텐츠 명확성 (Content clarity)
   생성형 AI (Generative AI) 검색은 품질이 낮은 콘텐츠를 더 쉽게 무시하게 만듭니다. Google의 가이드는 독특하고, 가치 있으며, 범용적이지 않은 (Non-commodity) 콘텐츠를 강조합니다. 이 문구가 중요한 이유는 AI 시스템이 일반적인 지식을 요약하는 데 점점 더 능숙해지고 있기 때문입니다. 만약 당신의 페이지가 다른 모든 사람이 말하는 내용을 반복하기만 한다면, 그것을 검색하거나, 인용하거나, 사용자를 그곳으로 보낼 이유가 거의 없을 것입니다. 개발자와 사이트 소유자에게 이는 콘텐츠가 다음과 같은 질문에 답해야 함을 의미합니다: 우리가 직접적인 경험을 통해 알고 있는 것은 무엇인가? 우리가 일반적인 출처보다 더 잘 설명할 수 있는 것은 무엇인가? 어떤 세부 사항이 사용자의 실제 의사결정을 도울 것인가? 어떤 제약 사항, 트레이드오프 (Trade-offs), 예외 사례 (Edge cases), 또는 리스크가 가시적이어야 하는가? 어떤 주장들이 검증 가능한가? 에이전트 준비가 된 콘텐츠가 반드시 더 길어야 하는 것은 아닙니다. 더 명확해야 합니다. 중요한 사실을 명시적으로 드러내야 합니다.

3. 의미론적 구조 (Semantic structure)
   HTML은 단순한 렌더링 대상이 아닙니다. 그것은 의미 (Meaning)입니다.

인터페이스가 의미론적 요소 (Semantic elements)로 구축되면 브라우저, 보조 기술 (Assistive technologies), 크롤러 (Crawlers), 그리고 에이전트 (Agents)가 현재 어떤 일이 일어나고 있는지 이해할 가능성이 높아집니다. 즉, 구조를 위해 실제 제목 (Headings)을 사용하고, 동작을 위해 실제 버튼 (Buttons)을 사용하며, 탐색을 위해 링크 (Links)를 사용해야 합니다. 레이블 (Labels)을 입력창 (Inputs)에 연결하고, 이름 (Names), 역할 (Roles), 상태 (States)를 정확하게 노출해야 합니다. 강력한 이유가 없는 한 네이티브 컨트롤 (Native controls)을 취약한 커스텀 컴포넌트 (Custom components)로 대체하는 것을 피해야 하며, 중요한 정보는 단순한 시각적 장식이 아닌 문서의 일부가 되도록 해야 합니다. 이것은 단순히 완벽한 HTML을 작성하기 위한 것이 아닙니다. 해석 오류 (Interpretation errors)를 줄이기 위한 것입니다. 사람은 스타일이 적용된 카드가 클릭 가능하다는 것을 때때로 추측할 수 있습니다. 하지만 에이전트가 추측까지 해야 해서는 안 됩니다.

4. 접근성 트리 (Accessibility tree) 품질
   접근성 트리 (Accessibility tree)는 에이전트 준비가 된 (Agent-ready) 웹사이트를 위한 가장 중요한 디버깅 표면 중 하나가 될 수 있습니다. web.dev는 접근성 트리를 DOM을 대화형 요소의 역할 (Roles), 이름 (Names), 상태 (States)로 추출하여 나타내는 브라우저 네이티브 표현 (Browser-native representation)이라고 설명합니다. 보조 기술 (Assistive technology)에게 이것은 필수적입니다. 에이전트에게 이것은 페이지의 기능적 지도 (Functional map)가 될 수 있습니다. 이는 접근성 (Accessibility)이 더 이상 별개의 체크리스트가 아님을 의미합니다. 그것은 AI 사용성 (AI usability)의 일부입니다. 버튼에 접근 가능한 이름 (Accessible name)이 없다면 스크린 리더 (Screen reader) 사용자가 어려움을 겪습니다. 양식 필드 (Form field)에 레이블 (Label)이 없다면 에이전트는 어떤 값이 거기에 속하는지 이해하지 못할 수 있습니다. 커스텀 컨트롤 (Custom control)이 잘못된 역할 (Role)을 노출하면 자동화 (Automation)는 신뢰할 수 없게 됩니다. 접근성 작업은 항상 포용성 (Inclusion)에 관한 것이었습니다. 이제 그것은 기계 해석 가능성 (Machine interpretability)의 일부가 되고 있습니다. 그렇다고 해서 인간에게 미치는 중요성이 줄어들어서는 안 됩니다. 오히려 우선순위가 높아져야 합니다.

5. 동작 준비성 (Action readiness)
   이것은 새로운 계층입니다. 에이전트가 사이트에서 안전하게 동작 (Act)할 수 있습니까? 모든 웹사이트가 즉시 이것을 필요로 하는 것은 아닙니다. 블로그 포스트는 읽기 가능하고 인용 가능하기만 하면 될 수도 있습니다. 하지만 이커머스 (Ecommerce), 여행 (Travel), SaaS, 지역 서비스 (Local services), 예약 시스템 (Booking systems), 대시보드 (Dashboards), 그리고 지원 포털 (Support portals)은 점점 더 동작 (Actions)에 대해 고민해야 합니다. 동작 (Actions)에는 버튼 그 이상의 것이 필요합니다.

이들에게는 의도 (intent), 제약 조건 (constraints), 파라미터 (parameters), 검증 (validation), 그리고 확인 (confirmation)이 필요합니다. 예를 들어: “제출 (Submit)”보다는 “객실 검색 (Search rooms)”이 더 안전합니다. “계속 (Continue)”보다는 “예약 견적 요청 (Request booking quote)”이 더 명확합니다. “구독 취소 (Cancel subscription)”는 반드시 명시적인 확인을 요구해야 합니다. “지금 결제 (Pay now)”는 모호한 자동화 뒤에 절대 숨겨져서는 안 됩니다. “요금제 비교 (Compare plans)”는 요금제 이름, 가격, 제한 사항, 그리고 청구 기간을 명확하게 노출해야 합니다. WebMCP가 흥미로운 이유는 웹사이트가 에이전트(agent)로 하여금 픽셀(pixels)과 DOM 파편(DOM fragments)으로부터 모든 것을 추론하게 만드는 대신, 이러한 동작(actions)들을 구조화된 도구(structured tools)로서 노출할 수 있는 세상을 가리키고 있기 때문입니다. 이것이 UX(사용자 경험)의 필요성을 없애는 것은 아닙니다. 오히려 UX를 더 명시적으로 만듭니다. 작은 예시를 들어보겠습니다: 취약한 양식에서 에이전트가 읽을 수 있는 양식으로. 하나의 예약 양식을 상상해 보십시오. 취약한 버전은 사람에게는 깔끔해 보일 수 있지만 에이전트에게는 혼란스러울 수 있습니다: <div class= "booking-card" > <div class= "field" > 도착 (Arrival) </div> <input type= "text" placeholder= "날짜 선택 (Select date)" > <div class= "field" > 출발 (Leaving) </div> <input type= "text" placeholder= "날짜 선택 (Select date)" > <div class= "fake-button" onclick= "submitBooking()" > 계속 (Continue) </div> </div> 이것은 시각적으로는 작동할 수 있지만, 모호함을 유발합니다: 입력창(inputs)에는 안정적인 레이블(labels)이 없고, 필드(fields)에는 명확한 이름(names)이 없으며, 동작(action)은...