Chrome DevTools 새 API, AI가 React 상태를 읽는 디버깅

AI 요약

• 무슨 일: Chrome DevTools for agents가 devtoolstooldiscovery 기반 서드파티 개발자 도구를 도입했습니다.
  • 프레임워크와 앱은 ToolGroup을 등록하고, 에이전트는 MCP로 내부 상태를 조회합니다.
• 의미: 코딩 에이전트의 디버깅 입력이 DOM 스냅샷에서 컴포넌트 계층, 신호 그래프, 의존성 주입 그래프로 확장됩니다.
• 실무 영향: React, Angular 같은 프레임워크 도구는 사람용 패널을 넘어 에이전트가 호출하는 런타임 API가 됩니다.
• 주의점: 기능은 실험 상태이며 --categoryExperimentalThirdParty=true 플래그가 필요하고, API 안정성은 아직 보장되지 않습니다.

Chrome 팀이 AI 코딩 에이전트의 디버깅 경계를 한 단계 더 낮췄습니다. 2026년 6월 18일 공식 발표에서 Chrome DevTools for agents는 서드파티 개발자 도구를 도입했습니다. 이름은 평범하지만, 변화의 위치는 분명합니다. 이제 에이전트는 브라우저 화면과 DOM 스냅샷만 보는 것이 아니라, 프레임워크와 애플리케이션이 직접 공개한 런타임 상태를 MCP 도구로 호출할 수 있습니다.

이 발표는 단순한 DevTools 확장 포인트가 아닙니다. Chrome DevTools for agents는 이미 AI 코딩 에이전트가 Chrome 브라우저를 열고, 페이지를 조작하고, 성능과 접근성 문제를 검사하게 하는 MCP 서버입니다. 이번 API는 그 서버가 페이지 안의 라이브러리와 대화하는 통로를 엽니다. React 컴포넌트 트리, Angular 신호 그래프, 의존성 주입 위치, 서버 상태, 데이터베이스 조회 결과 같은 정보가 도구 호출의 대상이 됩니다.

최근 devlery에서 다룬 WebMCP 브라우저 에이전트 글은 웹페이지가 에이전트에게 명시적 도구를 제공하는 방향을 다뤘습니다. 이번 Chrome 발표는 그보다 더 개발자 도구 쪽에 붙어 있습니다. 사용자가 보는 웹 기능이 아니라, 개발자가 디버깅할 때 필요한 내부 상태를 에이전트에게 주는 방식입니다. 브라우저가 행동 표면이라면, 이번 API는 관찰 표면입니다.

DOM 스냅샷만으로는 부족한 버그

Chrome 공식 글의 출발점은 현대 웹 애플리케이션의 추상화입니다. React, Angular, Vue 같은 프레임워크는 실제 DOM보다 더 많은 상태를 안쪽에 둡니다. 컴포넌트 계층, 훅 상태, 신호 의존성, 서버 캐시, 폼 상태, 라우터 상태, 의존성 주입 컨테이너는 화면에 그대로 드러나지 않습니다. DevTools는 최종 DOM을 볼 수 있지만, 버그의 원인은 종종 그 위에 있는 프레임워크 런타임에 있습니다.

AI 코딩 에이전트도 같은 한계를 만납니다. 에이전트가 스크린샷과 접근성 트리만 본다면 버튼이 비활성화됐다는 사실은 알 수 있습니다. 그러나 왜 비활성화됐는지는 다른 문제입니다. props가 잘못 내려왔는지, 서버 액션이 실패했는지, React 상태가 갱신되지 않았는지, Angular signal이 순환 의존성을 만들었는지, 의존성 주입 provider가 엉뚱한 위치에 있는지는 DOM만으로 판단하기 어렵습니다.

이 차이는 코딩 에이전트 제품에서 실제 품질 차이로 이어집니다. 정적 분석은 파일을 읽고 가능한 원인을 추론합니다. 브라우저 에이전트는 화면에서 증상을 확인합니다. 하지만 런타임 내부 상태를 읽지 못하면 둘 사이에 빈칸이 남습니다. 이번 Chrome API는 그 빈칸을 프레임워크와 앱이 직접 채우게 합니다.

devtoolstooldiscovery가 여는 통로

공식 발표와 GitHub 기술 문서가 설명하는 흐름은 이벤트 기반입니다. Chrome DevTools MCP 서버는 페이지의 window 객체에 devtoolstooldiscovery 이벤트를 보냅니다. 페이지나 라이브러리는 이 이벤트를 듣고 event.respondWith()로 ToolGroup을 반환합니다.

ToolGroup은 도구 묶음입니다. 각 도구는 name, description, inputSchema, execute를 가집니다. 입력 스키마는 JSON Schema로 정의됩니다. 실행 함수는 페이지 문맥에서 동작하고 직렬화 가능한 값을 돌려줍니다. DOM 요소는 예외적으로 DevTools의 스냅샷 UID와 연결될 수 있어, 에이전트가 프레임워크가 가리킨 요소를 같은 도구 체계 안에서 다시 조작할 수 있습니다.

에이전트 쪽 호출도 명확합니다. 사용 가능한 도구 목록은 list_3p_developer_tools로 확인합니다. 실제 호출은 execute_3p_developer_tool로 합니다. 더 복잡한 작업은 evaluate_script로 페이지 문맥에서 여러 연산을 조합할 수 있습니다. 이 설계는 일반 사용자용 DevTools 패널을 만드는 것이 아니라, 에이전트가 읽고 호출할 수 있는 도구 인터페이스를 만드는 쪽에 가깝습니다.

Angular가 먼저 보여준 두 가지 도구

Chrome 공식 글은 Angular 팀과의 협업을 첫 성공 사례로 제시합니다. 하나는 Signal Graph 도구입니다. 에이전트가 상태와 뷰 사이의 관계를 시각화해, 무한 루프나 갱신 실패를 일으키는 의존성을 찾도록 돕는 도구입니다. 다른 하나는 Dependency Injection Graph 도구입니다. Angular의 의존성 주입 그래프는 정적 분석만으로 잡기 어려운 런타임 구조입니다. 어떤 서비스가 어디서 제공되는지, 누락된 provider가 어느 위치에 있는지 확인하려면 실행 중인 앱의 컨테이너 상태가 필요합니다.

이 예시는 이번 API의 성격을 잘 보여줍니다. 일반적인 코드 생성 에이전트는 파일을 읽고 grep을 하고 테스트를 돌립니다. 그러나 Angular 의존성 주입 문제는 파일 검색만으로 끝나지 않을 수 있습니다. 모듈 구성, provider 범위, lazy route, 런타임 인젝터가 실제 페이지에서 어떻게 결합됐는지를 봐야 합니다. 프레임워크가 그 정보를 도구로 노출하면, 에이전트는 추측을 줄이고 관측값을 근거로 수정안을 만들 수 있습니다.

React 쪽도 움직임이 있습니다. Chrome 공식 글은 React 팀이 서드파티 개발자 도구를 실험하기 시작했다고 언급합니다. React 저장소의 공개 PR은 react-devtools-cdt-mcp 통합을 제안합니다. 도구 목록에는 컴포넌트 트리 조회, 특정 컴포넌트 조회, 컴포넌트 검색, 소스 조회, owners stack, profiling, trace overview, commit report가 들어갑니다. PR은 아직 열려 있으므로 이를 완료된 React 기능으로 말할 수는 없습니다. 다만 사람이 쓰던 React DevTools의 지식이 에이전트용 MCP 도구 형식으로 재포장되는 방향은 분명히 드러납니다.

사람용 패널에서 에이전트용 API로

DevTools 확장은 원래 사람을 위한 UI였습니다. 개발자는 패널을 열고, 트리를 펼치고, 값을 읽고, 원인을 추론했습니다. Chrome DevTools for agents의 서드파티 도구는 이 패턴을 바꿉니다. 프레임워크가 사람에게 보여주던 상태를 에이전트가 호출 가능한 함수로 바꾸는 것입니다.

이 변화는 작지 않습니다. 에이전트에게 도구를 준다는 것은 그 도구가 설명 가능하고, 입력 스키마를 갖고, 실패 응답을 반환하고, 페이지 이동과 origin 경계를 견뎌야 한다는 뜻입니다. React DevTools나 Angular DevTools처럼 사람에게 친숙한 패널이 곧바로 좋은 에이전트 도구가 되지는 않습니다. 에이전트는 화면을 보며 "이 컴포넌트가 이상하다"고 느끼지 않습니다. 대신 react_find_components 같은 도구를 부르고, 결과를 바탕으로 다음 파일을 열거나 테스트를 실행합니다.

그래서 프레임워크 팀의 역할도 달라집니다. 예전에는 DevTools 패널이 개발자 경험의 부가 기능에 가까웠습니다. 앞으로는 에이전트가 버그를 고치는 능력을 좌우하는 런타임 API가 될 수 있습니다. 같은 React 앱이라도 컴포넌트 트리와 owner stack을 에이전트가 안정적으로 읽을 수 있으면, 코딩 에이전트는 더 짧은 루프로 원인을 좁힐 수 있습니다.

Chrome DevTools MCP는 이미 넓은 설치 표면을 갖고 있다

Chrome DevTools for agents 문서는 여러 에이전트 호스트를 직접 언급합니다. Antigravity 2.0에는 사전 번들로 들어가고, Gemini CLI는 extension 방식으로 설치할 수 있으며, Claude Code는 플러그인 또는 MCP 설정으로 붙일 수 있습니다. Codex도 codex mcp add chrome-devtools -- npx chrome-devtools-mcp@latest 형식의 설정 예시가 문서에 있습니다.

GitHub 저장소도 이미 작은 실험 수준을 넘어섰습니다. 확인 시점의 GitHub API는 ChromeDevTools/chrome-devtools-mcp가 TypeScript 저장소이고 Apache-2.0 라이선스를 사용한다고 표시했습니다. 같은 응답에서 약 4만 3917개 스타와 2823개 포크도 확인했습니다. 이 숫자는 시간이 지나면 바뀌지만, 최소한 Chrome DevTools MCP가 에이전트 도구 생태계에서 넓은 관심을 받고 있다는 신호로 볼 수 있습니다.

같은 날 나온 최신 릴리스도 주목할 만합니다. chrome-devtools-mcp-v1.3.0은 2026년 6월 18일 배포됐고, 힙 스냅샷 dominator, retaining path, heap snapshot edge 같은 메모리 분석 도구와 스크린샷 크기 제한, 페이지 제목 출력 개선을 포함했습니다. 서드파티 도구 설명 누락을 안전하게 처리하는 수정도 들어갔습니다. 발표와 저장소 릴리스가 같은 날 움직인다는 점은 이번 기능이 블로그 문구에 머물지 않는다는 근거입니다.

보안 경계는 넓어지지 않지만 책임은 생긴다

기술 문서는 보안 범위를 조심스럽게 설명합니다. 서드파티 개발자 도구는 해당 페이지가 정의한 문맥에서 실행되며 origin을 넘어 지속되지 않습니다. 새 권한을 부여하지 않고, 공격자가 해당 페이지에서 이미 실행할 수 있는 코드 수준의 능력만 가진다는 설명도 있습니다. 이는 브라우저 보안 모델을 깨는 기능이 아니라, 페이지 내부에서 이미 접근 가능한 상태를 DevTools MCP 경로로 노출하는 기능이라는 뜻입니다.

그렇다고 아무 부담이 없는 것은 아닙니다. 개발자 도구가 내부 상태를 노출하면, 무엇을 노출할지 결정해야 합니다. 서버 상태, 데이터베이스 내용, 사용자 세션 정보, 실험 플래그, 결제 상태, 관리자 권한 상태가 모두 디버깅에 유용할 수 있습니다. 그러나 에이전트가 그 값을 읽게 하는 순간, 로그와 대화 기록, MCP 서버 출력, 에이전트 프롬프트 문맥에 민감 정보가 들어갈 수 있습니다.

따라서 프레임워크와 애플리케이션 팀은 도구 설계 기준을 만들어야 합니다. 첫째, 도구 이름과 설명은 에이전트가 오해하지 않게 좁아야 합니다. 둘째, inputSchema는 허용 범위를 정확히 제한해야 합니다. 셋째, 반환값은 디버깅에 필요한 최소 구조만 담아야 합니다. 넷째, 실패 응답은 원인을 설명하되 민감 정보를 흘리지 않아야 합니다. 다섯째, 실험 플래그 뒤에 있는 동안에도 어떤 환경에서 켤지 정해야 합니다.

실험 플래그가 말하는 현재 위치

이번 기능은 안정 API가 아닙니다. 공식 발표는 Chrome DevTools for agents 0.25.0부터 사용할 수 있고, --categoryExperimentalThirdParty 명령줄 플래그로 활성화한다고 설명합니다. GitHub 기술 문서는 API가 실험 상태이며 변경될 수 있고 안정성을 보장하지 않는다고 적습니다.

이 조건은 개발팀의 채택 방식을 제한합니다. 프로덕션 앱에 바로 넓게 넣기보다, 내부 개발 환경이나 프레임워크 실험에서 먼저 다루는 것이 맞습니다. 예를 들어 디자인 시스템 팀이 컴포넌트 상태 조회 도구를 만들고, 코딩 에이전트가 실패한 스토리북 사례를 디버깅하게 하는 식의 좁은 시작이 가능합니다. 대규모 SaaS 제품의 고객 데이터 화면에 내부 DB 조회 도구를 곧바로 붙이는 접근은 위험합니다.

반대로 실험 상태라는 점이 발표의 중요도를 낮추지는 않습니다. 코딩 에이전트의 품질 병목은 이미 "모델이 코드를 얼마나 잘 쓰는가"만의 문제가 아닙니다. 실행 중인 앱에서 무엇을 관측할 수 있는지, 실패 증상을 어느 정도 구조화해 줄 수 있는지, 도구 호출 결과가 코드 수정과 테스트 재실행으로 이어지는지가 중요해졌습니다. Chrome이 이 영역을 DevTools MCP의 공식 확장점으로 다루기 시작했다는 사실이 뉴스의 중심입니다.

WebMCP와 다른 지점

WebMCP는 웹사이트가 에이전트에게 구조화된 도구를 제공하는 방향입니다. 사용자가 웹을 탐색하거나 작업을 맡길 때, 클릭과 스크래핑 대신 명시적 도구를 제공하자는 문제의식에 가깝습니다. Chrome DevTools for agents의 서드파티 개발자 도구는 목적지가 다릅니다. 사용자가 아니라 개발자와 코딩 에이전트가 대상입니다. 제품 기능 실행이 아니라 버그 원인 분석이 목적입니다.

이 차이는 도구 설계에도 영향을 줍니다. WebMCP 도구는 예약, 검색, 결제, 폼 입력처럼 사용자 과업을 표현할 수 있습니다. DevTools 서드파티 도구는 컴포넌트 트리, signal graph, provider 위치, 내부 상태처럼 진단 데이터를 표현합니다. 둘 다 MCP와 가까운 세계에 있지만, 하나는 제품 행동의 API이고 다른 하나는 런타임 관찰의 API입니다.

두 방향은 결국 만날 수 있습니다. 에이전트가 웹앱에서 사용자의 과업을 수행하다가 실패하면, 같은 브라우저 세션에서 DevTools 도구로 내부 상태를 확인할 수 있습니다. 예를 들어 장바구니 추가가 실패했을 때 WebMCP는 "상품 추가" 도구의 오류를 반환하고, DevTools 도구는 React 상태나 서버 캐시의 불일치를 보여줄 수 있습니다. 에이전트에게 중요한 것은 어느 쪽이 더 멋진 표준이냐가 아니라, 실패를 재현하고 원인을 좁히는 데 필요한 관측값이 충분한가입니다.

AI 디버깅의 경쟁 기준이 바뀐다

코딩 에이전트 경쟁은 오랫동안 코드 작성 능력과 벤치마크 점수로 설명됐습니다. 그러나 실제 개발팀이 매일 겪는 문제는 더 지저분합니다. 테스트는 통과하지만 UI가 깨집니다. 로컬에서는 되지만 브라우저에서는 안 됩니다. 프레임워크 상태는 맞는데 서버 캐시가 오래됐습니다. 타입 오류는 없지만 렌더링 루프가 멈추지 않습니다. 이런 문제는 파일만 읽는 에이전트에게 어렵습니다.

Chrome DevTools의 새 API는 이 경쟁 기준을 관측 가능성으로 옮깁니다. 어느 에이전트가 더 좋은 모델을 쓰는지도 중요하지만, 어느 프레임워크가 에이전트에게 더 좋은 런타임 도구를 제공하는지가 중요해집니다. Angular가 신호 그래프를 열고 React가 컴포넌트 트리와 profiling 도구를 실험하면, 같은 모델도 더 나은 증거를 갖고 판단할 수 있습니다.

개발 도구 회사에게도 질문이 생깁니다. 기존 DevTools 패널을 에이전트가 호출할 수 있는 도구로 바꿀 것인가. 도구 이름과 스키마를 어떻게 표준화할 것인가. 사용자 프로젝트의 민감한 상태를 어느 수준까지 반환할 것인가. 실패한 도구 호출을 에이전트가 어떻게 복구하게 할 것인가. 이 질문들은 UI 기능보다 API 설계와 운영 정책에 가깝습니다.

개발팀이 지금 확인할 것

프레임워크나 내부 플랫폼을 운영하는 팀이라면, 이번 발표를 바로 제품 기능으로 붙이기보다 세 가지를 먼저 확인하는 편이 좋습니다. 첫째, 사람이 DevTools에서 반복적으로 확인하는 런타임 상태가 무엇인지 목록화해야 합니다. 컴포넌트 경로, props, signal dependency, query cache, feature flag, authorization state 중 어디가 실제 디버깅 시간을 많이 쓰는지 봐야 합니다.

둘째, 그 상태를 에이전트가 읽어도 안전한 형태로 줄일 수 있는지 확인해야 합니다. 원본 객체 전체를 반환하는 도구는 편하지만 위험합니다. 민감 필드를 제거하고, 식별자는 축약하고, 범위를 현재 선택 요소나 현재 route로 제한하는 방식이 필요합니다. GitHub 기술 문서가 말하듯 DOM 요소는 특수 UID로 연결할 수 있으므로, 전체 페이지 상태를 던지지 않고도 선택 지점 중심의 도구를 만들 수 있습니다.

셋째, 이 도구가 수정 루프와 어떻게 연결되는지 검증해야 합니다. 에이전트가 getComponentState를 호출해 상태를 읽었는데, 그 다음 어느 파일을 수정해야 하는지 알 수 없다면 효과는 제한적입니다. React PR의 도구 목록에 component source, owners stack, commit report가 들어간 이유도 여기에 있습니다. 런타임 상태와 소스 위치, 변경 이력, profiling 결과가 이어져야 에이전트가 실제 수정을 할 수 있습니다.

브라우저 에이전트의 다음 입력은 내부 상태

Chrome DevTools for agents의 서드파티 개발자 도구는 아직 실험 기능입니다. 플래그가 필요하고, API는 바뀔 수 있으며, React 통합도 공개 PR 단계입니다. 하지만 방향은 분명합니다. 브라우저 에이전트는 더 이상 화면을 보고 클릭만 하는 자동화가 아닙니다. 코딩 에이전트는 브라우저 안에서 앱을 실행하고, DevTools로 관측하고, 프레임워크 내부 상태를 도구로 읽고, 코드 수정으로 돌아오는 폐쇄 루프를 향하고 있습니다.

이 변화가 자리 잡으면 좋은 프레임워크의 조건도 달라집니다. 문서와 타입, 오류 메시지뿐 아니라 에이전트가 읽을 수 있는 런타임 진단 표면이 필요합니다. 사람이 눈으로 보는 DevTools 패널은 계속 중요합니다. 그러나 AI 코딩 에이전트가 팀의 실제 디버깅 루프에 들어온다면, 같은 정보는 함수와 스키마와 MCP 도구로도 제공돼야 합니다.

이번 발표의 실무적 결론은 단순합니다. AI 디버깅의 정확도는 모델만으로 결정되지 않습니다. 에이전트가 실행 중인 앱에서 어떤 증거를 받을 수 있는지가 점점 더 중요해집니다. Chrome이 devtoolstooldiscovery라는 작은 이벤트를 만든 이유도 여기에 있습니다. DOM 밖에 있던 프레임워크의 진실을, 이제 에이전트가 물어볼 수 있게 하려는 것입니다.