Playwright MCP와 Chrome DevTools MCP, 어떤 작업에 맞을까?

MCP 연결·활용 / 브라우저 실습

브라우저 MCP를 찾다 보면 Chrome DevTools MCP와 Playwright MCP가 함께 추천됩니다. 둘 다 AI가 웹페이지를 다루게 하지만, 잘하는 일이 다릅니다. 공개 페이지 이동에 더해 같은 로컬 버튼 클릭, 404 응답, 콘솔·네트워크 기록을 두 서버에서 직접 시험하고 작업에 따라 고르는 기준을 정리했습니다.

같은 버튼과 실패 요청을 두 서버에서 시험

외부 계정 없이 비교하려고 로컬 HTTP 서버에 버튼 하나가 있는 시험 페이지를 띄웠습니다. 버튼은 /missing-status.json을 요청하고, 존재하지 않는 파일이라 화면에 Response 404를 표시합니다. 요청 직전에 Test request started 경고도 콘솔에 남깁니다. 두 MCP는 각각 새 격리 브라우저를 사용했습니다.

확인 항목	Playwright MCP	Chrome DevTools MCP
버튼 찾기·클릭	스냅샷의 버튼 참조로 클릭	페이지 스냅샷의 요소 UID로 클릭
화면 결과	Response 404 확인	Response 404 확인
콘솔·네트워크	경고와 404 요청 확인	경고와 404 요청 확인

이번 작은 시험에서는 두 도구 모두 화면 상호작용과 오류 기록을 읽을 수 있었습니다. Playwright MCP의 클릭 응답은 스냅샷 파일 경로를 돌려줘 별도로 browser_snapshot을 다시 호출해 화면 결과를 확인했습니다. Chrome DevTools MCP는 클릭 응답에 최신 스냅샷을 포함하도록 요청했습니다. 차이는 이 실행의 확인 절차이지 어느 서버가 항상 더 빠르거나 정확하다는 증거가 아닙니다.

재현할 때는 빈 로컬 페이지에 버튼, 클릭 시 실패하는 요청, 화면의 상태 문구를 준비한 뒤 두 서버에서 이동 → 스냅샷 → 버튼 클릭 → 다시 스냅샷 → 콘솔·네트워크 확인 순서로 실행하면 됩니다. 실제 사이트에서는 로그인·개인정보 접근 범위와 기대 결과를 별도로 정해야 합니다.

어떤 차이가 있나?

선택지	먼저 살펴볼 작업	확인할 점
Playwright MCP	페이지 구조 읽기, 요소 찾기, 클릭·입력 등 흐름 시험	접근성 스냅샷이 작업에 충분한지, 브라우저 환경이 준비됐는지
Chrome DevTools MCP	콘솔 오류, 네트워크 요청, 성능 추적을 통한 디버깅	Chrome 사용 여부, 브라우저 데이터 노출 범위, 성능 자료 수집 옵션

Playwright MCP 공식 README는 접근성 트리를 활용한 상호작용을 설명합니다. Chrome DevTools MCP 공식 README는 콘솔·네트워크·성능 분석을 주요 기능으로 소개합니다. 어느 쪽이 항상 더 낫다는 결론보다 지금 해결할 문제가 무엇인지가 중요합니다.

처음 연결할 때

두 서버 모두 Node.js와 npm을 사용하는 예제가 제공됩니다. Codex CLI에서 MCP 서버를 추가하는 기본 형식은 아래와 같습니다. Claude Code 사용자는 각 프로젝트의 공식 클라이언트 설정 예제를 확인하세요. 처음 연결 시험에서는 개인 브라우저 세션을 연결하지 않고, 분리된 브라우저에서 example.com을 열었습니다. 이후 로컬 시험 페이지에서 버튼 클릭과 오류 응답을 추가로 확인했습니다.

codex mcp add playwright -- npx -y @playwright/mcp@latest
codex mcp add chrome-devtools -- npx -y chrome-devtools-mcp@latest
codex mcp list

연결 후 바로 로그인 페이지를 맡기기보다 다음처럼 공개 페이지에서 시작하세요. 도구 목록에 Playwright의 browser_navigate 또는 Chrome DevTools의 navigate_page가 보이고, 실제 페이지 제목이 돌아오면 최소한의 이동 시험이 된 것입니다.

example.com을 열고 페이지 제목만 알려줘.
그다음 어떤 브라우저 MCP 도구를 사용했는지 표시해줘.

성능 분석과 개인정보에서의 차이

Chrome DevTools MCP는 성능 추적과 콘솔·네트워크 분석에 강점이 있습니다. 공식 문서에 따르면 성능 도구가 CrUX 자료를 조회하도록 trace URL을 보낼 수 있고, 사용 통계 수집이 기본 켜짐입니다. 원하지 않으면 --no-performance-crux와 --no-usage-statistics 옵션을 확인하세요. 이번 서버 시험에서는 두 옵션을 사용했습니다. 브라우저에 로그인 정보나 개인 자료가 있으면 MCP 클라이언트가 그 내용을 볼 수 있으므로 실습에는 격리된 브라우저를 권합니다.

Playwright MCP의 공식 README는 코딩 에이전트에서 CLI와 Skill 방식이 더 간결할 수 있다고도 설명합니다. 이미 프로젝트에 Playwright 테스트가 있다면 새 MCP가 필요한지 먼저 비교해 보세요. 실제 E2E 테스트의 성공은 페이지 이동 한 번으로 판단할 수 없고, 재현 가능한 테스트 시나리오와 기대 결과가 필요합니다.

무엇부터 연결할까?

“버튼을 눌렀더니 화면이 바뀌는가”를 반복 확인하려면 Playwright MCP부터, “왜 요청이 실패했는가”를 콘솔·네트워크 기록으로 추적하려면 Chrome DevTools MCP부터 시험해 보세요. 이번 확인처럼 공개 페이지에서 최소 동작을 재현한 뒤 자신의 프로젝트로 범위를 넓히면 연결 문제와 사이트 자체 문제를 구분하기 쉽습니다.

근거: Playwright MCP, Chrome DevTools MCP 공식 README 및 공개 예제 페이지 직접 이동 결과.