Chrome DevTools MCP 공식 출시 — AI 에이전트가 드디어 브라우저를 본다

Chrome DevTools MCP 공식 출시 — 36K stars · 29개 도구 · npx 한 줄

“AI 에이전트는 브라우저를 볼 수 없다”는 전제가 깨졌다. Google이 Chrome DevTools MCP를 공식 출시했고, 출시 직후 GitHub 스타 35,975개를 기록했다. 도구는 29개, 설치는 npx 한 줄이다.

지금까지 Claude Code로 프론트엔드 작업을 하면 “코드 짜기 → 빌드 → 브라우저 열기 → 콘솔 확인 → 버그 재현 → 다시 코드”의 핑퐁이 반복됐다. 에이전트는 브라우저를 못 보니 사람이 중간 다리 역할을 해야 했다. 이제 이 전체 루프를 에이전트가 혼자 돈다.

공식 출시 핵심 팩트

  • GitHub: ChromeDevTools/chrome-devtools-mcp, 스타 35,975개 (2026-04 기준)
  • 도구 수: 29개 (6개 카테고리로 분류)
  • 설치: npx chrome-devtools-mcp 한 줄
  • 호환: Claude Code, Gemini CLI, Cursor, VS Code Copilot, Windsurf 등 20개 이상 AI 클라이언트 공식 지원
  • Chrome 144부터: 자동 연결 지원. 헤드리스 가능, 기존 브라우저 세션에도 붙음

29개 도구는 6개 카테고리로 묶인다. 입력 자동화(클릭·폼·파일 업로드), 네비게이션(페이지 열기·탭 전환), 에뮬레이션(모바일 기기·네트워크 쓰로틀링), 콘솔 검사, 네트워크 추적, 성능 프로파일링.

에이전트가 할 수 있게 된 것

구체적으로 무엇이 바뀌었는지 정리한다.

  • 스크린샷 기반 판단: 에이전트가 화면 상태를 직접 눈으로(비전으로) 본다. “이 버튼이 잘렸다”를 사람이 스크린샷 붙여주지 않아도 된다
  • 콘솔 에러 자동 분석: 소스맵까지 따라가서 스택 트레이스 확인. “무슨 에러?” 대신 “이 함수 142줄에서 null 참조”까지 즉시
  • UI 자동 조작: 클릭, 타이핑, 폼 제출을 에이전트가 직접 실행. 테스트 시나리오 자동 수행
  • Lighthouse 감사 자동화: 성능 점수 목표치까지 수정-측정 루프를 자율로 반복
  • 네트워크 요청 추적: 어떤 API가 느린지, 어떤 요청이 중복되는지 직접 측정
  • 성능 프로파일링: 렌더링 병목, 리플로우 원인을 에이전트가 진단

프론트엔드 개발 루프 3가지 변화 — Before vs After

실전 3가지 시나리오

1. “이 버튼 안 눌려요” 재현 자동화

고객이 버그 제보를 보내면 보통 이렇게 흘러간다: 개발자가 환경 구성 → 재현 시도 → 브라우저 콘솔 확인 → 원인 찾기. 짧게 잡아도 30분.

Chrome DevTools MCP를 쓰면 에이전트가 URL을 받아 자동으로 해당 페이지 열고, 버튼 클릭 시도하고, 콘솔 에러를 수집한다. 스택 트레이스까지 따라가 원인 함수를 지목한다. 사람이 확인할 건 “이 분석이 맞는가”뿐이다.

2. Lighthouse 점수 개선 루프

성능 최적화는 본질적으로 “수정 → 측정 → 수정”의 반복이다. 사람이 하면 한 번 사이클에 10~20분. 10번 반복하면 반나절.

에이전트가 Lighthouse를 직접 돌려 점수를 읽고, 개선 가능한 부분을 찾아 코드 수정하고, 다시 측정한다. “Largest Contentful Paint를 1.2초까지 낮춰라”라고 목표만 주면 에이전트가 루프를 자율로 끝낸다.

3. 느린 API 범인 색출

네트워크 탭을 직접 보는 일이 줄어든다. 에이전트가 페이지 로딩 시 발생하는 모든 네트워크 요청을 수집하고, 응답 시간·크기·중복을 분석해 “이 API가 800ms로 가장 느리고, 3번 중복 호출되고 있다”는 보고서를 낸다.

1인 개발자한테 가장 큰 변화

QA를 외주 안 줘도 된다. 이게 이번 출시의 진짜 의미다.

지금까지 1인 개발자가 프론트엔드 제품을 만들 때 가장 큰 병목은 “내가 모든 브라우저·화면 크기·상호작용을 직접 테스트해야 한다”였다. QA 인력을 고용할 여력이 없고, 자동화 테스트를 작성할 시간도 없었다.

Chrome DevTools MCP는 이 격차를 지운다. Claude Code나 Cursor에게 “회원가입 플로우를 Safari·Chrome·Firefox에서 각각 테스트해달라”고 요청하면 에이전트가 모바일 뷰포트까지 전환해가며 전 과정을 수행한다. 실패 지점마다 스크린샷 + 콘솔 로그를 리포트로 정리한다.

개발자 1명이 사실상 팀 1개가 되는 지점이다.

설치법

npm/npx가 있으면 별도 설정 없이 바로.

# Claude Code 예시
claude mcp add chrome-devtools -- npx -y chrome-devtools-mcp

# 또는 .claude/mcp.json에 직접
{
  "chrome-devtools": {
    "command": "npx",
    "args": ["-y", "chrome-devtools-mcp"]
  }
}

Chrome 144 이상이면 별도 브라우저 실행 없이 에이전트가 자동으로 인스턴스를 띄운다. 기존에 열려있는 Chrome 세션에 붙고 싶으면 --connect-existing 플래그.

주의할 점

  • 보안: MCP가 브라우저를 조작한다는 건 로그인된 세션에도 접근 가능하다는 의미. 민감한 계정이 떠 있는 브라우저에 에이전트를 붙일 때는 별도 프로필 권장
  • 비용: 복잡한 Lighthouse 루프는 토큰을 상당히 소비한다. 실험 초기엔 단순한 시나리오부터
  • 한계: CAPTCHA, 2FA, iframe 내부 일부 요소는 여전히 에이전트가 완벽히 못 다룬다

결론

Chrome DevTools MCP 출시로 AI 에이전트 시대의 프론트엔드 워크플로우가 한 단계 전환됐다. 요점 셋으로 정리한다.

  1. 사람이 브라우저 중간 다리 역할 하던 루프가 닫힌다
  2. 1인 개발자에게 QA 자동화가 처음으로 실현된다
  3. 성능·네트워크·UI 테스트가 에이전트 자율 과제로 이동한다

npx 한 줄이면 시작된다. 실제로 하루 돌려보면 어떤 루프가 가장 많이 줄어드는지 체감으로 알 수 있다.

출처

댓글

댓글 쓰기

이 블로그의 인기 게시물

[알고리즘] Suffix Tree

이미지
Suffix tree는 문자열의 모든 접미사들을 표현하는 trie 모양의 자료 구조이다. prefix tree라 불리는 trie가 근간이 되는 자료구조인듯 한데 두 자료구조의 차이는 banana라는 단어가 있을 때 trie는 banana라는 단어만 저장을 하지만 suffix tree는 banana, anana, nana, ana, na, a 와 같이 banana라는 단어에서 나올 수 있는 모든 경우의 수를 다 저장한다는 것이다. 쓸데없이 모든 경우를 저장하는 이유는 문자열에 대한 검색을 할 때 필요하기 때문이다. Trie 자료구조 같은 경우에는 ban, ba와 같은 일부분의 단어로 banana라는 완전한 단어를 찾을 수 있지만 nan, ana와 같은 단어로는 banana를 찾을 수 없다. 이러한 문제를 해결하기위해 trie를 개선시킨 것이 suffix tree인듯 하다.  Suffix trie는 trie에 모든 suffix들을 저장한 구조를 의미한다. 아래 그림은 abaaba라는 문자열 T를 suffix tree에 저장하는 예시이다. suffix tree나 suffix trie에 문자열을 저장할 때는 문자열의 끝에 $를 붙이는데 그 이유는 정확히 모르겠다... 아마 문자열의 끝을 알리기 위한 용도인 것 같다. Suffix Trie의 형태  위 그림의 왼쪽과 같은 모양이 suffix trie이다. 여기서 자식 노드가 1개 뿐인 것들을 합치면 오른쪽과 같은 모양이 되는데 저러한 형태의 자료구조를 suffix tree라 한다. Suffix Tree  이 suffix tree는 문자열의 길이만큼의 leaf node를 갖는다  위 그림에서 오른쪽 그림은 tree의 edge label을 (offset, length)의 형태로 T를 나타낸 것이다. Suffix tree의 label  각 노드의 label은 root로부터 node로 연결된 edge의 label과 ...
자세한 내용 보기

Claude Opus 4.7 출시 총정리 — 뭐가 달라졌고 지금 써야 하나

결론: Claude Opus 4.7은 "전부 업그레이드"가 아니다. 에이전트 작업에선 4.6보다 확실히 강해졌지만, 일상 코딩은 Sonnet이 여전히 3~5배 싸다. 2026-04-16 출시 후 Claude Code에서 반나절 써본 결과 3가지 체감 변화와 Qwen 3.6과의 비교까지 정리한다. Opus 4.7 핵심 변화 3가지 4.6과 비교해 체감되는 지점은 세 곳이다. 1. 에이전트 작업 체류 시간이 길어졌다 단일 지시로 파일 여러 개를 연쇄 수정할 때 중간에 “다음 단계 확인해 드릴까요?” 같은 끊김이 줄었다. 4.6은 5~6 step에서 한 번씩 끊겼는데, 4.7은 10 step 이상을 한 번에 간다. 긴 리팩터링 작업에서 체감이 크다. 2. 코딩 벤치마크 점수 상승 Anthropic 공식 블로그의 차트 기준으로 SWE-bench Verified, Terminal-bench 모두 4.6보다 올랐다. 다만 이게 실사용 속도까지 보장하지는 않는다. 3. 반론에 더 단단해졌다 4.6은 “내 말이 맞다”고 밀면 바로 물러서는 경향이 있었다. 4.7은 근거를 다시 제시한다. 디버깅 대화에서 사람이 틀린 가정을 고집할 때 이 특성이 오히려 시간을 아낀다. Qwen 3.6-35B가 Opus 4.7을 이긴다고? 같은 날 Alibaba가 Qwen 3.6-35B-A3B(오픈소스)를 공개했다. Simon Willison이 자기 노트북에서 Qwen 3.6이 Opus 4.7보다 “더 나은 펠리컨 그림을 그렸다”는 글을 올려 HN 상위에 갔다. 이 결과를 어떻게 봐야 할까. 일부 작업에서는 오픈소스가 이긴다 — 이미지 생성, 특정 추론 과제 복잡한 에이전트·장문 코딩은 Opus 4.7이 여전히 우세 비용 관점 에서 오픈소스가 매력적이지만, API 없이 로컬 돌리려면 GPU 비용이 따로 든다 즉 “Opus 4.7 vs Qwen 3.6”은 “어느 게 ...
자세한 내용 보기

[기타IT] php설치

이미지
 이번에는 php 설치하는 법에 대해 알아보겠습니다. 저는 개발할 때 node.js를 사용 하지만 이번에 프로젝트하는데 필요한 xibo가 php기반이라 설치하게 되었습니다. php란?  php(약칭 : Hypertext Preprocessor)는 프로그래밍 언어의 일종으로 동적 웹 페이지를 만들기 위해 설계되었습니다. php는 일반적으로 혼자 설치되지 않고 apache와 MySql과 함께 설치되는 것이 일반적입니다.  php는 apache를 통해 브라우저로 정보를 전송하고 MySql을 이용해 사용자의 정보를 저장하기 때문에 일반적으로 함께 사용되고 설치됩니다. 이를 APM이라 하는데 Window에 설치하는 APM을 WAPM이라 합니다. 이걸 각각 설치 할 수도 있지만 난이도가 있기 때문에 Bitnami를 이용해 한번에 설치해 보도록 하겠습니다. php설치 먼저 https://bitnami.com/stack/wamp 에 접속하여 설치파일을 다운로드 받습니다.  다운로드가 완료되면 설치파일을 실행합니다. 다른 구성요소들은 굳이 필요하지 않으니 체크박스를 해제해줍니다. php에서 쓰는 MySql의 root사용자 비밀번호를 설정해주는 화면입니다. 6자리 이상의 비밀번호를 입력하시면 됩니다. 설치가 되고 있는 화면입니다.  설치가 완료되고 브라우저 주소창에 localhost를 쳤을 때 다음과 같은 화면이 출력되면 제대로 설치가 된것입니다.
자세한 내용 보기