배경 및 맥락

브라우저 자동화는 오랫동안 테스트 도구의 영역이었고, 최근 들어서야 coding agent와 browsing agent의 핵심 실행 환경으로 부상했다. 하지만 기존 DevTools와 브라우저 디버깅 체계는 사람이 보는 웹앱 문제를 중심으로 설계돼 있었고, tool-calling agent가 어떤 surface에서 실패하는지까지는 충분히 다루지 못했다.

Chrome DevTools 148은 이 균형이 바뀌고 있음을 보여준다. 브라우저 팀이 accessibility, preload, crash context 같은 전통적 디버깅 기능을 강화하는 동시에, agent가 웹을 읽고 도구를 호출하는 흐름 자체를 디버깅 대상 1급 시민으로 올리기 시작했다.

---

핵심 내용

공식 블로그에 따르면 Chrome DevTools MCP server와 CLI는 0.25.0으로 업데이트됐고, 세 가지가 핵심이다. 첫째, Chrome extension debugging으로 agent가 extension page와 background script까지 대상으로 삼을 수 있다. 둘째, experimental WebMCP tool calling으로 페이지가 노출하는 WebMCP 도구를 나열하고 실행할 수 있다. 셋째, Lighthouse에 Agentic Browsing audit category가 들어가 사이트가 agentic web에 얼마나 준비됐는지, 예를 들어 WebMCP tool registration이 유효한지를 평가할 수 있다.

여기에 browser dialog 자동 처리 신뢰성 개선, full accessibility tree 기본화, crash report context 노출, Speculation Rules 필터링 강화까지 붙으면서 agent 디버깅과 전통적 웹 디버깅이 한 surface로 합쳐지고 있다.

---

경쟁 구도 / 비교

최근 agent browser 런타임은 DOM 제어에서 OS 제어까지 확장되고 있다. AWS AgentCore Browser가 OS level action으로 실행 범위를 넓혔다면, Chrome은 표준 브라우저와 개발자 도구 레이어에서 agent-aware 디버깅을 제도화하는 방향에 가깝다. 전자는 런타임 capability, 후자는 ecosystem tooling과 표준화를 밀어주는 축이다.

이는 앞으로 agentic web 경쟁이 모델만의 문제가 아니라 브라우저와 개발자 도구 생태계 경쟁이 될 가능성을 보여준다. WebMCP 같은 인터페이스가 자리 잡으면 웹사이트는 human-first UI만이 아니라 agent-first callable surface를 따로 설계해야 한다.

---

의미

기술적으로는 브라우저가 agent 실행기이자 검사기로 동시에 진화하고 있다. Lighthouse까지 agent-ready 검사를 넣기 시작한 것은 브라우저가 웹 성능과 접근성처럼 agent compatibility도 측정 가능한 품질 항목으로 보겠다는 신호다.

실무적으로는 frontend 팀과 platform 팀 모두 준비가 필요하다. extension 기반 workflow, browser dialog, accessibility tree, tool registration, observability를 함께 봐야 하며, 웹앱의 품질 기준은 점점 "사람이 쓰기 편한가"에서 "사람과 agent가 모두 안정적으로 실행할 수 있는가"로 넓어지고 있다.