Playwright MCP vs Chrome DevTools MCP: 같은 폼으로 직접 테스트

핵심 요약

• 도구가 직접 Chrome을 실행했을 때 두 서버 모두 모든 입력란을 채우고, 파일을 업로드하고, 동일 출처 iframe과 크로스 사이트 iframe 안에서도 작업했습니다. 각각 5회 중 5회입니다.
• 사람이 이미 열어 둔 Chrome에 연결했을 때 Playwright MCP는 열려 있는 폼을 바로 채웠습니다. Chrome DevTools MCP 1.10.1은 그 페이지에서 클릭은 할 수 있었지만, 입력란은 페이지를 한 번 새로고침한 뒤에만 채울 수 있었고 모든 실행에서 그랬습니다.
• Chrome DevTools MCP가 실행한 Chrome은 navigator.webdriver = true를 보고했고, Playwright MCP가 실행한 Chrome은 false를 보고했습니다. 직접 실행한 Chrome에서는 둘 다 false였습니다.
• 깔끔하고 반복 가능한 실행과 더 짧은 도구 목록이 필요하다면 Playwright MCP를 선택하세요. 자신의 웹 앱을 디버깅하거나(트레이스, Lighthouse, 네트워크) 평소 쓰는 Chrome을 에이전트와 함께 쓰려면 Chrome DevTools MCP를 선택하세요.

테스트 결과

각 칸은 5회 중 통과한 횟수입니다. 테스트 날짜 2026년 9월 30일, Google Chrome 154.0.8037.92, @playwright/mcp 0.0.83, chrome-devtools-mcp 1.10.1, 세 번째 열로 agent-browser 0.38.1.

모드 1: 도구가 직접 Chrome을 실행

각 도구는 새 프로필 폴더로 헤드리스 Chrome을 실행하고, 테스트 페이지를 열어 페이지에 로그인한 뒤 폼을 채우고, 사람 단계는 체크하지 않은 채 제출 버튼을 눌렀습니다.

모드 2: 사람이 이미 쓰고 있는 Chrome에 도구가 연결

Chrome은 저희가 전용 프로필과 로컬 디버깅 포트로 직접 실행했습니다. 사람 역할의 대역이 페이지를 열고, 로그인하고, 제품 이름을 입력했습니다. 그다음 도구가 연결해 나머지를 채우고 멈췄고, 대역이 사람 단계를 체크해 제출했으며, 도구가 결과를 읽었습니다.

실행 스크린샷

테스트 방법

• 2026년 9월 30일, macOS의 Google Chrome 154.0.8037.92에서 진행했습니다. 버전은 고정했습니다: @playwright/mcp 0.0.83, chrome-devtools-mcp 1.10.1, agent-browser 0.38.1.
• 폼은 127.0.0.1의 로컬 테스트 페이지이며, 크로스 사이트 iframe은 다른 포트의 localhost에서 불러옵니다. 실제 웹사이트, 계정, 개인 브라우저 프로필, 결제는 전혀 사용하지 않았습니다.
• 작은 스크립트가 에이전트의 클라이언트와 똑같이 MCP로 각 서버와 통신했습니다. 스냅샷, 폼 채우기, 업로드, 클릭, 콘솔과 네트워크 읽기입니다. 요소 참조는 각 도구 자체의 스냅샷에서 가져왔습니다. 결정을 내리는 언어 모델이 없었으므로 모든 실행이 같은 단계를 따랐습니다.
• 모든 시나리오는 도구마다 5회 실행했습니다. 표는 통과한 실행 횟수를 셉니다.
• 모드 2의 사람은 탭에 일반 DevTools Protocol 명령을 보내는 스크립트입니다. 대역일 뿐 실제 사람이 아닙니다. 이 스크립트가 Chrome DevTools MCP 입력 실패의 원인이 아님을 확인하려고, 스크립트 없이 테스트 URL로 Chrome을 직접 실행해 보기도 했으며 결과는 같았습니다.
• agent-browser는 MCP 모드가 아니라 주 인터페이스인 명령줄로 구동했습니다.

이 테스트가 다루지 않는 것

• 실제 CAPTCHA, 봇 검사, 서드파티 사이트의 실제 로그인.
• Firefox와 WebKit, 두 프로젝트의 브라우저 확장 프로그램, Chrome의 자동 연결 대화상자.
• 성능 트레이스, Lighthouse, 메모리 도구.
• 언어 모델이 단계를 고르는 경우: 실제 에이전트에 필요한 토큰 수와 턴 수는 모델에 따라 다릅니다.
• Windows와 Linux.

눈에 띈 점

문서 기준, 미테스트

아래 차이는 확인일 기준 각 프로젝트의 README와 문서에서 가져온 것입니다. 저희가 측정하지는 않았습니다.

도구 목록의 무게

페이지를 열기 전에 Playwright MCP는 도구 25개와 20.3 KB의 도구 설명을, Chrome DevTools MCP는 도구 30개와 25.7 KB를 알렸습니다(기본 설정, tools/list로 측정). 에이전트는 세션 내내 이 텍스트를 컨텍스트에 싣고 다닙니다. Chrome DevTools MCP는 도구를 세 개로 줄이는 --slim을 제공하고, Playwright MCP는 --caps로 도구 그룹을 추가합니다.

무엇을 고를까

agent-browser는?

agent-browser는 선택적 MCP 모드가 있는 에이전트용 명령줄 브라우저 도구입니다. 직접 브라우저를 실행했을 때는 같은 폼을 채웠지만, 실행 중인 Chrome에 연결했을 때는 크로스 사이트 iframe을 놓쳤습니다. 에이전트가 MCP 도구보다 짧은 셸 명령을 더 잘 다룬다면 살펴볼 만합니다.

Claude in Chrome vs Chrome DevTools MCP: 차이와 선택 기준 →

직접 테스트하기

테스트 페이지는 의존성 없는 Node.js 파일 하나입니다. 내 컴퓨터에서만 요청을 받습니다.

1. 파일을 다운로드해 Node.js 18 이상으로 실행합니다.
2. http://127.0.0.1:4461/을 한 번 열어 페이지를 확인합니다. 크로스 사이트 iframe은 다음 주소에서 불러옵니다: http://localhost:4462/.
3. 아래 MCP 항목 중 하나를 에이전트에 추가하고, 폼을 채우고 작은 PNG 파일 하나를 업로드하고 두 iframe을 채운 뒤 사람 단계 앞에서 멈추라고 요청합니다.
4. 사람 단계를 직접 체크하고 제출한 다음, 이제 페이지에 무엇이 표시되는지 에이전트에게 묻습니다.

다운로드 browser-mcp-test.mjs

이 파일은 폼, iframe, 로컬 에코 엔드포인트를 제공합니다. 다른 곳으로는 아무것도 전송하지 않습니다.

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "-y",
        "@playwright/mcp@0.0.83"
      ]
    }
  }
}

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp@1.10.1",
        "--no-usage-statistics"
      ]
    }
  }
}

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "-y",
        "@playwright/mcp@0.0.83",
        "--cdp-endpoint",
        "http://127.0.0.1:9222"
      ]
    }
  }
}

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp@1.10.1",
        "--browser-url=http://127.0.0.1:9222",
        "--no-usage-statistics"
      ]
    }
  }
}

LaunchRepo의 선택

• LaunchRepo의 플레이북은 사용자 본인의 Chrome에 연결된 Chrome DevTools MCP 기준으로 작성되고 테스트되었습니다. 디렉터리 등록에는 실제 로그인이 필요하고, 모든 단계를 직접 볼 수 있어야 하기 때문입니다.
• 직접 실행한 Chrome에서는 이 테스트의 모든 도구에서 navigator.webdriver가 false로 유지되었고, 인계도 잘 작동했습니다. 같은 탭에서 사용자가 단계를 마치면 에이전트가 결과를 읽습니다.
• 에이전트가 연결할 때 디렉터리 폼이 이미 열려 있다면, 무엇이든 입력하기 전에 에이전트가 페이지를 새로고침하게 하세요. 그래야 입력한 내용을 잃지 않습니다.

• 코딩 에이전트를 내 Chrome에 연결하기 →
• Claude Code로 디렉터리에 SaaS 출시하기 →
• Chrome DevTools Protocol →
• MCP 서버 →

출처

공식 페이지와 저장소는 2026년 9월 30일에 확인했습니다. 인용문은 원문 그대로 옮겼으며, 테스트 결과는 저희가 직접 측정한 것입니다.

자주 묻는 질문

코딩 에이전트에는 Playwright MCP와 Chrome DevTools MCP 중 무엇이 더 나은가요?

모든 면에서 앞서는 쪽은 없습니다. 저희 테스트에서 두 도구 모두 직접 Chrome을 실행했을 때 모든 폼 검사를 통과했습니다. Playwright MCP는 사람이 이미 열어 둔 페이지도 채웠고 도구 목록도 더 짧았습니다. Chrome DevTools MCP는 자신의 앱을 디버깅하기 위한 성능 트레이스, Lighthouse, 더 깊은 네트워크와 콘솔 도구를 제공합니다.

Chrome DevTools MCP가 로그인된 제 Chrome을 사용할 수 있나요?

네. --autoConnect를 쓰면 원격 디버깅을 허용하고 대화상자를 확인한 뒤 실행 중인 Chrome 144 이상에 연결합니다. 또는 원격 디버깅 포트와 별도 프로필 폴더로 Chrome을 실행하고 --browser-url로 그곳을 지정하면 됩니다. Chrome 136부터 기본 프로필에서는 이 포트가 무시됩니다.

둘 다 iframe을 처리하나요?

네. 저희 실행에서 둘 다 두 모드 모두에서 동일 출처 iframe과 크로스 사이트 iframe에 5회 중 5회 접근했고, 그 안에서 입력하고 클릭할 수 있었습니다.

파일 업로드는 왜 실패했나요?

두 서버 모두 기본값으로 허용된 폴더의 파일만 읽습니다. Playwright MCP는 워크스페이스 루트나 작업 디렉터리에서, Chrome DevTools MCP는 클라이언트가 루트를 지정하지 않으면 시스템 임시 폴더에서 읽습니다. 파일을 그곳으로 옮기거나 문서화된 플래그로 제한을 넓히세요.

이 도구들로 CAPTCHA를 풀 수 있나요?

둘 다 CAPTCHA 기능을 문서화하지 않았고, 저희도 실제 CAPTCHA는 테스트하지 않았습니다. 대신 인계를 설계하세요. 에이전트가 멈추고, 사용자가 같은 화면의 창에서 그 단계를 해결하면, 에이전트가 이어서 진행합니다. 저희 연결 테스트에서는 두 서버 모두 이 인계가 작동했습니다.

navigator.webdriver 때문에 에이전트라는 것이 드러나나요?

저희 테스트에서는 Chrome DevTools MCP가 직접 Chrome을 실행했을 때만 true였습니다. Playwright MCP가 실행한 Chrome과 저희가 직접 실행한 모든 Chrome은 false를 보고했습니다. 사이트가 이 값에 반응하는지는 해당 사이트에 달려 있으며, 실제 봇 검사는 테스트하지 않았습니다.