구글이 지난 6월 22일, Chrome 팀을 통해 'Agent-Ready Toolkit'을 공식 출시했다. Lighthouse의 새로운 Agentic Browsing 카테고리, Chrome DevTools for Agents, Modern Web Guidance, 그리고 WebMCP—이 네 가지를 묶은 이 툴킷은 단순한 개발자 도구 이상의 의미를 갖는다. '내 사이트가 에이전트에 준비됐는가'라는 질문이 감으로 답하던 시대를 끝내고, 브라우저 벤더가 직접 측정 기준을 만들었다는 선언이기 때문이다.
이 변화가 프론트엔드 개발자에게 진짜 중요한 이유를 한 문장으로 정리하면 이렇다. 플랫폼 벤더가 자를 만드는 순간, 측정 대상은 실제 엔지니어링 과제가 된다. SEO가 Google Search Console이라는 공식 도구와 함께 진지해졌듯, 에이전트 준비도도 이제 Lighthouse 점수처럼 측정되고 추적되는 항목이 됐다.
툴킷의 핵심인 WebMCP 감사는 세 가지를 확인한다. navigator.modelContext를 통해 도구를 등록했는가, 도구로 노출됐어야 할 폼이 누락되지 않았는가, 입출력 스키마가 유효한가. 이 체크를 통과하면 AI 에이전트가 사이트에 접근했을 때 검색, 장바구니, 예약 폼을 구조화된 방식으로 호출할 수 있다—스크린샷을 찍고 어디를 클릭해야 할지 추측하는 대신. 명확한 인터페이스를 에이전트에게 제공하는 것, 이것이 '에이전트가 읽는 UI'의 첫 번째 조건이다.
그런데 dev.to의 해당 기사가 정확히 짚어낸 것처럼, 이 툴킷이 측정하는 것은 노출(Exposure)이지 호출(Invocation)이 아니다. 노출은 코드의 속성이다. 정적이고, 감사 가능하고, 합/불합으로 판단된다. 반면 호출은 세계의 속성이다. '화요일 오후 2시 3분, Gemini-in-Chrome이 searchProducts({query:'waterproof'})를 호출해 결과 8개를 받았다'는 사실은 정적 감사가 절대 알 수 없다. 아직 일어나지 않은 일이기 때문이다. 도구를 등록했다고 해서 누군가 실제로 그것을 쓴다는 보장은 없다.
이 공백이 지금 당장 실질적인 위험이 된 이유가 있다. Google이 첫 번째 소비자를 명시했다. 'Gemini in Chrome이 곧 WebMCP API를 지원할 것'이라고. 에이전트가 실제로 사이트를 호출하기 시작하면, 스키마가 맞지 않아 모든 호출이 실패해도 그 사실을 몇 달 뒤 애널리틱스 이상 징후로 뒤늦게 발견하게 된다. 첫 번째 에이전트 호출은 신호다—어떤 의도로 접근했는지, 스키마가 기대와 맞았는지, 호출이 성공했는지를 알 수 있는 기회다. 이것을 놓치는 것은 프로덕트 관점에서 심각한 손실이다.
해법은 복잡하지 않다. 도구를 등록하는 날, 호출 계측도 함께 심는 것이다. navigator.modelContext?.registerTool()에 핸들러를 등록할 때, 그 핸들러를 래퍼로 감싸 호출 성공 여부, 소요 시간, 오류 내용을 자체 엔드포인트로 리포트한다. Lighthouse 감사는 노출을 증명하고, 호출 로깅은 실제 사용을 관찰한다. 이 두 레이어가 함께 있어야 에이전트 준비도가 완성된다.
이 구조적 문제는 AI 에이전트와의 협업 방식 전체에 걸쳐 반복된다. TokenCap v1.3.0이 도입한 'Task Intelligence Layer' 개념도 같은 맥락을 건드린다. 기존의 프롬프팅이 매 세션을 제로에서 시작하는 '일회성 행위'라면, 루핑(Looping)은 프로젝트의 현재 상태—지금 뭘 만들고 있는지, 어떤 결정을 내렸는지, 무엇이 진행 중인지—를 컨텍스트로 유지하며 에이전트가 항상 '알고 있는 상태'에서 시작하게 한다. 에이전트에게 UI를 노출하는 것과, 에이전트가 그 UI의 맥락을 이해하며 호출하는 것은 다른 차원의 문제다.
Trellis가 제안하는 로컬 퍼스트 그래프 접근도 같은 방향을 가리킨다. 에이전트의 추론, 코드 변경, 의사결정이 동일한 그래프 위에 구조화된 데이터로 남을 때—세션이 끝나도 컨텍스트가 사라지지 않을 때—에이전트는 단순한 실행 도구가 아닌 진짜 협업자가 된다. RAG로 채팅 로그를 검색하는 것과 인과 관계를 그래프로 쿼리하는 것의 차이가 여기서 갈린다.
세 가지 흐름이 같은 지점을 향하고 있다. 첫째, 에이전트가 사이트를 조작하는 시대에 UI는 사람만이 아니라 에이전트가 소비하는 인터페이스가 됐다. 둘째, 노출만으로는 부족하다—호출 관찰, 컨텍스트 유지, 의사결정 추적이 없으면 에이전트는 여전히 반쪽짜리 협력자다. 셋째, 이 모든 구조는 프론트엔드가 먼저 설계해야 한다. Lighthouse가 점수를 매기기 시작했다는 것은, 측정되지 않던 것이 이제 팀의 엔지니어링 과제가 됐다는 뜻이기도 하다.
앞으로 UI 설계의 첫 번째 질문이 달라질 것이다. '사용자가 이 버튼을 찾을 수 있는가'와 함께, '에이전트가 이 기능을 호출할 수 있는가'를 동시에 물어야 한다. WebMCP 스키마 설계, 폼의 선언적 노출, 호출 계측—이것들은 UX 레이어 아래의 새로운 인프라 레이어다. 에이전트가 읽는 UI를 설계한다는 것은, 인간과 에이전트 두 페르소나를 모두 위한 경험을 동시에 구조화하는 일이다.