Playwright MCP로 브라우저 테스트하기: 설치와 실전 활용

Microsoft의 Playwright MCP 서버는 Claude Code, Codex, Cursor, VS Code의 Copilot 에이전트 등을 브라우저 자동화 프레임워크인 Playwright에 연결합니다. 저는 탐색적으로 동작을 점검하고 실패 원인을 조사하는 데 먼저 활용하기를 권합니다. 중요한 문제를 발견했다면 검토를 거쳐 반복 실행할 수 있는 테스트로 남깁니다.

Playwright MCP는 어떤 일을 하나요?

에이전트는 브라우저를 조작하는 툴과 페이지 구조를 설명하는 정보를 받습니다. MCP는 Model Context Protocol의 약자로, 에이전트가 이 툴을 호출할 수 있도록 연결해 줍니다. 브라우저 동작을 실행하는 쪽은 서버이고, 다음에 어떤 동작을 요청할지 결정하는 쪽은 에이전트입니다.

접근성 스냅샷은 건물 안내도와 비슷합니다. 안내도가 각 방과 출입문의 이름, 용도를 알려주듯 페이지 스냅샷은 버튼, 링크, 입력란과 그 접근성 이름을 설명합니다. 에이전트는 이미지에서 클릭할 위치를 추측하는 대신 이 구조에서 대상을 선택할 수 있습니다. 기본 워크플로에는 비전 모델이 필요하지 않습니다. Microsoft 개요

설치 전에 먼저 선택할 것이 있습니다. Microsoft는 코딩 에이전트 사용자를 위한 다른 방식으로 스킬을 활용하는 Playwright CLI도 안내합니다. 한편 MCP는 브라우저 상태를 유지하면서 페이지 구조를 반복해서 살펴보는 작업에 유용하다고 설명합니다. 이렇게 상호작용을 이어가는 방식이 작업에 맞는다면 MCP를 선택합니다. 에이전트가 이미 셸 명령으로 원활하게 작업하고 있다면 CLI 방식도 비교해 봅니다. 어느 쪽을 선택하든 그 선택 자체가 고객 이용 경로의 테스트 통과를 입증하지는 않습니다. Microsoft의 MCP와 CLI 비교

함께 사용할 툴을 더 폭넓게 살펴보려면 2026년 추천 MCP 서버를 참고합니다.

Playwright MCP 설치: Claude Code, Codex, Cursor, VS Code

Node.js 18 이상과 MCP를 지원하는 클라이언트가 필요합니다. 아래 명령과 설정은 Microsoft README의 예시를 그대로 옮긴 것입니다. 사용하는 클라이언트에 해당하는 방법을 선택하면 됩니다. 모든 에디터에서 차례대로 실행하는 절차가 아닙니다. 요구 사항과 설치 방법

Claude Code

다음 명령을 그대로 실행합니다.

claude mcp add playwright npx @playwright/mcp@latest

Codex

다음 명령을 그대로 실행합니다.

codex mcp add playwright npx "@playwright/mcp@latest"

또는 ~/.codex/config.toml에 다음 내용을 추가합니다.

[mcp_servers.playwright]
command = "npx"
args = ["@playwright/mcp@latest"]

Cursor

README의 수동 설정 경로인 Cursor Settings -> MCP -> Add new MCP Server로 이동합니다. 이름을 정하고 유형을 command로 선택한 뒤 다음을 입력합니다.

npx @playwright/mcp@latest

Edit에서 설정을 확인하거나 인수를 추가할 수 있습니다. README에는 Cursor에 설치하는 버튼도 있습니다.

VS Code

다음 VS Code CLI 명령을 그대로 사용합니다.

code --add-mcp '{"name":"playwright","command":"npx","args":["@playwright/mcp@latest"]}'

설정하면 VS Code의 GitHub Copilot 에이전트에서 서버를 사용할 수 있습니다. Microsoft README에는 설치 버튼과 VS Code MCP 설정 가이드 링크도 있습니다.

공통 JSON 설정

README의 표준 JSON 설정을 사용하는 클라이언트라면 다음 예시를 그대로 사용합니다.

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "@playwright/mcp@latest"
      ]
    }
  }
}

설정을 넣을 위치는 위의 클라이언트별 안내를 따릅니다. Codex의 파일 설정 방식은 이 JSON이 아니라 TOML을 사용합니다. 함께 사용할 에이전트를 고르려면 브라우저 테스트를 지원하는 AI 코딩 에이전트를 참고합니다.

브라우저와 에이전트의 페이지 인식 방식 설정하기

처음에는 브라우저 창을 표시하고, 격리된 프로필과 스냅샷을 사용하는 구성이 좋습니다. 서버 인수 목록에서 @playwright/mcp@latest 뒤에 옵션을 추가합니다. 아래 옵션은 Microsoft 설정 레퍼런스에 나온 내용입니다.

스냅샷과 비전의 차이는 조작 방식에 있습니다. 기본 흐름에서는 browser_snapshot으로 대상을 식별합니다. browser_take_screenshot은 시각적 근거를 남기지만, 스크린샷을 찍는 것만으로 좌표 클릭이 활성화되지는 않습니다. README는 --caps=vision에서 사용할 수 있는 툴로 browser_mouse_click_xy, browser_mouse_down, browser_mouse_drag_xy, browser_mouse_move_xy, browser_mouse_up, browser_mouse_wheel을 나열합니다. 클라이언트와 모델도 반환된 이미지를 시각적 추론에 활용할 수 있어야 합니다. 툴 레퍼런스

일반적인 폼과 페이지 이동을 점검할 때는 스냅샷부터 사용하는 것을 권합니다. 화면의 모양이 중요하거나 페이지 구조만으로 조작 요소를 충분히 설명할 수 없을 때는 시각적으로 확인합니다. 접근성 스냅샷은 구조를 파악하는 데 유용한 근거이지만, 화면이 올바르게 보인다는 사실까지 입증하지는 못합니다.

브라우저 점검에 필요한 주요 툴

핵심 툴은 페이지 이동, 조작, 근거 수집을 담당합니다. 아래 표는 README의 핵심 자동화 툴과 탭 툴을 에이전트에게 맡길 작업별로 정리한 것입니다. Microsoft 툴 목록

스냅샷 기반 동작은 페이지 스냅샷에 있는 대상 참조나 대상을 고유하게 식별하는 선택자를 사용합니다. 선택자는 페이지 요소를 식별하는 방법입니다. 페이지가 의미 있게 바뀌었다면 이전 대상 참조가 여전히 유효하다고 가정하지 말고 스냅샷을 새로 가져옵니다.

추가 기능은 명시적으로 활성화해야 합니다. 옵션 표에는 vision, pdf, devtools가 나와 있으며, 툴 설명에는 config, network, storage, testing도 명시되어 있습니다.

• PDF: --caps=pdf는 browser_pdf_save를 추가합니다.
• 디버깅 근거: --caps=devtools에는 트레이싱, 동영상, 동작 기록, 주석, 강조 표시, 일시 중지된 실행 재개 기능이 포함됩니다. 예를 들어 browser_start_tracing과 browser_stop_tracing으로 추적 기록의 시작과 끝을 정합니다.
• 검증 조건: --caps=testing은 browser_generate_locator, browser_verify_element_visible, browser_verify_list_visible, browser_verify_text_visible, browser_verify_value를 추가합니다. 검증 조건인 어서션은 반드시 참이어야 하는 상태를 명시합니다.
• 네트워크 시뮬레이션: --caps=network는 오프라인 동작과 모의 요청을 위한 browser_network_state_set, browser_route, browser_route_list, browser_unroute를 추가합니다.
• 스토리지: --caps=storage는 쿠키, 로컬 스토리지, 세션 스토리지의 조회와 편집 기능에 더해 browser_storage_state와 browser_set_storage_state를 추가합니다.
• 적용된 설정 확인: --caps=config는 browser_get_config를 추가합니다.

이는 README에 문서화된 기능 그룹입니다. 모든 클라이언트에서 모든 툴을 곧바로 사용할 수 있다는 뜻은 아닙니다. 툴이 보이지 않으면 설치된 패키지의 툴 목록과 활성화된 기능을 README와 비교합니다. 전체 툴 설명

비즈니스에 바로 활용할 수 있는 세 가지 점검

실패하면 매출이 막히거나 고객이 연락할 수 없게 되는 이용 경로부터 점검합니다. 아래는 활용할 수 있는 작업 방식이며, 절감 효과를 측정한 결과는 아닙니다.

구매가 결제 단계까지 이어지는지 확인하기

쇼핑몰 개발자는 에이전트에게 스테이징 환경에서 비회원 구매 흐름을 따라가도록 요청할 수 있습니다. 선택한 상품이 장바구니에 그대로 담겨 있는지 확인하고, 가상의 배송 정보를 입력한 뒤 실제 결제 직전에 멈추게 합니다. 고객보다 먼저 구매를 막는 오류를 찾는 것이 목적입니다.

같은 팀에서 해볼 만한 또 다른 작업은 입력 오류를 고친 뒤 진행할 수 있는지 점검하는 것입니다. 배송 정보를 일부 비워 제출하고, 오류 안내가 이해하기 쉬운지 확인한 뒤, 입력을 수정하면 고객이 계속 진행할 수 있는지 검증합니다. 처음부터 올바르게 입력하는 정상 경로만 확인하면 오타를 낸 고객의 상황을 놓칩니다.

배포 후 사이트 동작 확인하기

랜딩 페이지를 수정해 배포한 창업자는 에이전트에게 배포된 페이지를 열고 핵심 행동 유도 버튼이나 링크를 따라가게 할 수 있습니다. 의도한 회원가입 또는 문의 페이지에 도착하는지 확인하고, 페이지의 근거 자료와 관련 콘솔 출력 또는 실패한 요청 내역을 요청합니다.

웹 에이전시 개발자라면 이어서 뷰포트를 좁힌 상태로 같은 이동 경로를 점검할 수 있습니다. 가려진 메뉴나 누를 수 없는 버튼을 발견하는 데 도움이 됩니다. 스크린샷은 사람이 검토할 자료로 활용합니다. 스크린샷이 있다는 것만으로 화면 품질이 보장되지는 않습니다.

테스트 데이터로 폼 검증하기

SaaS 개발자는 로컬 또는 스테이징 환경에서 로그인이 필요 없는 회원가입 폼의 필수 입력란, 검증 메시지, 오류 수정 후 진행 경로를 테스트할 수 있습니다. 실제 계정이 생성되기 전에 멈추거나, 제출을 받아도 되는 테스트 전용 목적지를 사용합니다.

운영 도구 개발자는 가상의 입력값으로 스테이징의 긴 폼을 채워 보고, 모의 엔드포인트에 제출하기 전에 드롭다운, 조건부 필드, 테스트 파일 업로드를 확인할 수 있습니다. 고객 기록을 전송하거나 실제 업무 흐름을 실행하지 않으면서 필드 매핑 오류를 찾는 데 도움이 됩니다.

E2E 테스트 예시: 결제 페이지로 넘어가지 못하는 비회원 주문

에이전트에게 범위가 정해진 작업을 주고, 결론을 뒷받침할 근거를 요구합니다. 다음은 결함이 있다고 의도적으로 가정한 설명용 E2E 예시입니다. 실제 운영 중인 쇼핑몰을 테스트한 보고서가 아닙니다.

예시 앱에는 비회원 장바구니, 배송 정보 폼, 결제 페이지가 있습니다. 배송 정보 폼이 우편번호 필드를 실수로 postal이라는 이름으로 전송하지만, 백엔드는 postalCode를 기대합니다. 가짜 데이터를 사용하고 실제 결제에는 연결하지 않은, 로그인 없이 접근할 수 있는 로컬 또는 스테이징 테스트 환경을 준비합니다.

아래 대괄호 안의 URL을 자신의 테스트 환경 주소로 바꿔 에이전트에게 지시합니다.

격리 설정은 서버 구성에 --isolated로 지정해야 합니다. 프롬프트에 적는 것만으로 서버가 설정되지는 않습니다.

이 예시에서는 요청 본문에 postal이 들어 있고, 응답은 postalCode가 누락되었다고 알려줍니다. 이는 매핑 오류라는 가설을 뒷받침합니다. 그래도 개발자는 근본 원인을 해결했다고 판단하기 전에 폼 직렬화 로직과 백엔드가 요구하는 데이터 규약을 확인해야 합니다.

에이전트 보고서 예시:

다음으로 매핑을 수정하고, 잘못된 입력과 유효한 입력의 경로를 모두 다시 실행합니다. 동작을 확인한 뒤에는 에이전트에게 Playwright 회귀 테스트 초안을 작성하게 하고, 검증 조건을 검토해 기존 테스트 러너에 추가합니다. 이 마지막 단계는 개발팀의 엔지니어링 절차입니다. MCP로 나눈 대화만으로 회귀 테스트 모음이 만들어지는 것은 아닙니다.

테스트의 한계와 브라우저 에이전트의 접근 범위

목표가 모호하거나 환경이 안전하지 않으면 점검의 신뢰도가 떨어집니다. “구매 흐름을 확인해 줘”라고만 하면 에이전트가 성공 기준까지 임의로 정해야 합니다. 반면 “유효한 배송 정보로 결제 페이지에 도달하는지 확인하되, 결제는 제출하지 마”라는 지시는 결과를 검토할 수 있습니다.

실무에서는 다음과 같은 한계를 고려해야 합니다.

• 모호한 페이지 구조: 이름이 없는 조작 요소나 캔버스 중심 인터페이스에서는 구조 정보의 효용이 떨어집니다. 직접 관리하는 앱이라면 접근성 레이블을 수정하고, 구조만으로 부족한 부분은 시각적 근거로 보완하기를 권합니다.
• 바뀌는 상태: 재렌더링, 팝업, 지연된 화면 전환 때문에 에이전트가 다음 동작의 전제로 삼은 상태가 더 이상 유효하지 않을 수 있습니다. 동작 후 상태를 확인하고, 의도한 텍스트나 화면 전환을 기다린 뒤 계속 진행합니다.
• 프로필 충돌: 영구 프로필은 한 번에 하나의 브라우저 인스턴스에서만 사용할 수 있습니다. Microsoft는 같은 워크스페이스를 공유하는 클라이언트를 동시에 실행할 때 격리 세션을 사용하거나 --user-data-dir 값을 서로 다르게 지정할 것을 권합니다.
• 환경 차이: README의 Docker 구현은 headless Chromium만 지원합니다. 일반 CLI 표에 있는 모든 브라우저 선택지가 해당 컨테이너에서도 작동한다고 가정하면 안 됩니다.
• 불완전한 검증 범위: 특정 페이지에 도착했다고 모든 입력 검증, 브라우저, 기기, 백엔드 처리 결과가 정상이라는 뜻은 아닙니다. 스크린샷만으로 주문이 올바르게 저장되었다고 입증할 수도 없습니다. 여기서 제안하는 점검 방식에는 이런 한계가 있습니다.

프로필과 Docker의 제한 사항은 Microsoft README에 설명되어 있습니다.

브라우저 접근 권한은 실제 시스템에 대한 접근 권한으로 다뤄야 합니다. Microsoft는 Playwright MCP가 보안 경계가 아니라고 명시합니다. 기본 프로필은 브라우저 상태를 유지하며, 선택적으로 설치하는 Chrome/Edge 확장 프로그램은 기존 탭과 로그인된 세션에 연결할 수 있습니다. 이 글의 작업에는 쿠키를 가져오거나 평소 쓰는 브라우저에 연결하지 않은 격리 세션을 사용합니다. 프로필과 확장 프로그램의 동작

에이전트는 브라우저가 실행되는 환경에서 접근 가능한 페이지를 요청할 수 있습니다. 네트워크 구성에 따라 공개 웹사이트뿐 아니라 개발 서버나 내부 서비스도 여기에 포함될 수 있습니다. 오리진 규칙이 네트워크 격리를 대신하지는 못합니다. --allowed-origins와 --blocked-origins는 리디렉션을 제한하지 않으며, 보안 경계가 아니라고 명시되어 있습니다. --allowed-hosts는 MCP 서버로 들어오는 요청의 호스트 검사에 관한 설정입니다. 브라우저가 방문해도 되는 웹사이트 목록이 아닙니다. 설정과 보안

파일 접근에도 같은 주의가 필요합니다. 문서에 따르면 기본 설정은 파일 접근을 워크스페이스 루트로 제한하고 file:// 탐색을 차단하며, --allow-unrestricted-file-access를 사용하면 이 규칙이 완화됩니다. Microsoft는 이런 파일 검사를 안전한 격리 수단이 아닌 보조 보호 장치로 설명합니다. 특히 browser_run_code_unsafe는 서버 프로세스 안에서 JavaScript를 실행하며 그 프로세스가 접근할 수 있는 범위에 영향을 미칠 수 있습니다. 클라이언트 권한으로 해당 툴을 제어하고 서버 환경의 접근 범위도 제한합니다. 설정 스키마와 툴

스크린샷, 페이지 텍스트, 콘솔 출력, 요청 본문을 통해 데이터가 에이전트에 노출될 수 있습니다. 가짜 데이터와 테스트 전용 엔드포인트를 사용합니다. 해당 작업이 구체적으로 승인된 경우가 아니라면 실제 결제, 메시지 전송, 계정 생성 등 실질적인 결과를 낳는 제출 전에 멈춥니다.

Playwright MCP, Chrome DevTools MCP, Browserbase 중 무엇을 선택할까요?

수행할 작업과 브라우저를 실행할 위치에 따라 선택합니다. 기능이 겹치는 부분은 있지만 같은 역할을 하는 대체품은 아닙니다.

Microsoft도 브라우저 엔드포인트에 연결하는 --cdp-endpoint 옵션을 제공합니다. 그래서 에이전트가 사용할 인터페이스와 브라우저를 실행할 위치는 별도로 결정해야 합니다. Browserbase는 Microsoft 서버의 다른 이름이 아닙니다. 더 넓은 관점에서 비교하려면 AI 에이전트용 추천 브라우저를 참고합니다.

비용 계산과 만들어 볼 만한 두 가지 서비스

비용을 비교하려면 현재의 점검 과정과 자동화된 전체 작업 과정을 나란히 놓고 봐야 합니다. Playwright MCP 저장소는 Apache 라이선스를 사용합니다. 서버를 설치한다고 에이전트 모델, 컴퓨팅 자원, 테스트용 환경과 데이터, 사람의 검토까지 제공되는 것은 아닙니다.

자신의 비용을 넣어 계산합니다.

• 도입 전: 수동 점검 시간 × 인건비와 관련 부대비용을 포함한 시간당 비용 + 기존 테스트 서비스 구독료.
• 도입 후: 에이전트 사용료 + 브라우저 인프라 + 사람의 검토 + 테스트 환경·데이터 및 테스트 유지보수.

호스팅 비용의 구체적인 기준으로, Browserbase의 Developer 요금제는 월 $20에 브라우저 사용 100시간을 포함하며 이후 브라우저 사용 시간당 $0.12를 청구합니다. 이는 브라우저 인프라 비용입니다. 에이전트가 구매 흐름을 테스트하는 데 드는 전체 비용은 아닙니다. Browserbase 요금

가장 유망한 기회: 배포 후 인수 검증 서비스

소규모 에이전시라면 고객사가 배포할 때마다 사전에 합의한 고객 이용 경로를 점검하는 서비스를 제공할 수 있습니다. 최소한의 유용한 구성은 스테이징 URL과 인수 체크리스트를 받아, 허용된 비로그인 경로를 실행하고, 근거와 검증하지 못한 범위를 명시한 보고서를 검토해 전달하는 방식입니다. 고객은 배포 점검을 책임져 주는 데 비용을 지불합니다.

수요 신호는 크지 않습니다. 2026년 10월에 조회한 DataForSEO의 미국 영어 키워드 추정치에서 “automated browser testing”의 월간 검색량은 110회, “checkout testing”은 10회였습니다. 이는 검색 횟수이지 구매자 수가 아닙니다. 범용 소프트웨어 제품에 투자하기 전에 기존 고객을 대상으로 범위를 좁힌 서비스를 검증해 볼 근거로 삼을 수 있습니다.

관건은 유지보수입니다. 이용 경로의 변경, 모호한 검증 조건, 잘못된 경고를 처리하다 보면 아끼려던 인력이 다시 투입될 수 있습니다. 차별화의 기반은 누구나 설치할 수 있는 공개 MCP 서버가 아니라, 실용적인 인수 체크리스트와 신뢰할 수 있는 문제 분류·우선순위 판단에 있습니다.

또 다른 기회: 스테이징 폼 점검 도구

웹 에이전시라면 가상의 값으로 폼을 채우고, 필수 입력란 오류를 확인한 뒤, 수정된 내용을 제출하면 모의 목적지에 도착하는지 검증하는 도구를 만들 수 있습니다. 이미 유지보수하는 사이트의 폼부터 시작하고, 개발자가 재현할 수 있는 보고서를 제공합니다.

같은 DataForSEO 미국 영어 데이터셋에서 “website form testing”의 월간 검색량 추정치는 10회입니다. 독립적인 고객 확보 근거로는 약합니다. 저는 이를 웹사이트 유지보수의 추가 서비스로 판매하고, 반복 수요를 확인한 뒤 별도 제품을 만들기를 권합니다.

주의할 부분은 데이터를 받는 시스템입니다. 성공한 것처럼 보이는 페이지가 나타났다고 문의 정보가 목적지에 도착했다는 뜻은 아닙니다. MVP에는 브라우저 근거와 함께, 테스트 엔드포인트나 수신 여부를 확인할 수 있는 다른 허용된 방법이 필요합니다.

설치할 때 자주 묻는 질문

월요일에 바로 해볼 일: 매출과 가장 가까운 비회원 이용 경로를 고르고, 기대 결과와 중단 지점을 적습니다. 그런 다음 현재 사용하는 코딩 에이전트에게 스테이징에서 점검을 맡깁니다. 범위를 넓히기 전에 해당 흐름을 담당하는 개발자와 근거 자료를 함께 검토합니다.

배포 절차에 맞는 브라우저 점검 워크플로가 필요하다면, 비즈니스 업무를 위한 AI 에이전트 개발 서비스를 확인할 수 있습니다.