Playwright MCP: 브라우저를 열어 직접 확인하기

Playwright MCP가 연결하는 것#

Playwright MCP는 브라우저를 조작해 화면과 사용자 흐름을 확인하는 데 쓸 수 있습니다. 접근성 스냅샷은 스크린샷과 다르며, 실제 폼 제출은 데이터 변경을 일으킬 수 있습니다.

공식 문서 확인: 2026-11-01. 이 표는 Mirr Code에서의 연결 성공을 뜻하지 않습니다.

1. 테스트 계정과 변경해도 되는 별도 환경을 준비합니다.
2. 공식 서버의 요구사항을 확인하고 Mirr Code MCP 연결 안내를 참고합니다. 로컬 서버의 Mirr 설정은 별도 확인이 필요합니다.
3. 화면 조회와 제출을 구분하고, 실제로 실행한 경우에만 결과와 민감정보를 가린 증거를 기록합니다.

추가 검증 필요: Playwright MCP 서버 설치 명령·버전과 설치 기록, Mirr 연결, 실제 브라우저 세션과 계정·프로필 권한, 민감정보를 가린 브라우저 세션 화면, 실행 기록과 테스트 출력, 셀렉터 실패 및 수정 로그는 아직 확보하거나 확인하지 못했습니다.

준비물과 권한#

브라우저 프로필과 테스트 계정의 접근 범위를 먼저 확인하세요. 스크린샷과 세션 기록에도 개인정보나 인증 정보가 담길 수 있습니다.

설치와 연결#

Mirr Code 설치 문서와 외부 도구 연결 안내를 참고하세요. 서버 설치 및 Mirr 연결 절차는 이 페이지에서 아직 실측하지 않았습니다.

공식 README의 표준 설정은 실행 명령 npx, 인자 @playwright/mcp@latest를 사용합니다. 이는 서버 실행 방식이지 Mirr 설정 파일의 형식을 뜻하지 않습니다. latest는 바뀔 수 있으므로 실제 검증 시에는 사용한 패키지 버전, Node.js 버전과 브라우저 버전을 함께 기록하세요. 설치 과정의 출력과 이후 연결·실행 출력은 별개로 보관해야 합니다.

Playwright MCP 설정을 검토할 때는 Microsoft의 @playwright/mcp 서버와 Mirr 클라이언트의 설정을 분리하세요. 다음은 문서상 HTTP 등록 경로를 검토하는 미실행 절차입니다. 두 문서에 명령이 있다는 사실은 이 조합의 프로토콜·브라우저 동작이 검증됐다는 뜻이 아닙니다.

1. 공식 패키지 출처와 사용할 릴리스를 정하고 설치 과정·버전을 기록할 계획을 세웁니다. 설치 명령의 @latest는 공식 문서의 예시 표기이며 고정 버전이 아닙니다. 개인 브라우저 대신 별도 테스트 프로필과 계정, 로컬 접근 범위를 준비합니다.
2. 서버의 Standalone MCP server 안내에는 npx @playwright/mcp@latest --port 8931로 HTTP 서버를 실행하고 http://localhost:8931/mcp에 연결하는 예가 있습니다. 실행 전 포트 사용 여부·접근 범위와 필요한 브라우저 표시 환경을 확인합니다. 이 글에서는 실행하지 않았습니다.
3. Mirr의 주소 연결 형식에 이 로컬 HTTP 주소를 적용할 수 있는지 해당 버전에서 검토합니다. 예를 들어 /mcp add browser-check --http http://localhost:8931/mcp는 두 문서의 형식을 조합한 미실행 예시이며 작동이 확인된 Mirr 설치 명령이 아닙니다. 로컬 stdio용 JSON을 Mirr 설정이라고 복사하지 마세요.
4. 승인된 테스트 환경에서만 연결 상태와 /mcp tools browser-check의 실제 결과, 빈 테스트 페이지 조회를 단계별로 확인합니다. 등록 성공·도구 노출·브라우저 조작 성공은 각각 별도 결과입니다. 모르는 오류를 포트 공개나 권한 확대로 우회하지 마세요.

서버 설치 명령·정확한 버전과 transcript, Mirr의 해당 HTTP 전송 지원, 실제 도구 출력·브라우저 세션 화면·권한·테스트는 아직 검증되지 않았습니다. 이 미실행 설정 검토가 실행 증거를 채우지는 않습니다(위 두 문서 2026-11-02 확인).

실제 작업 예제#

예를 들어 테스트 환경에서 로그인 화면을 열고 입력 요소를 확인한 뒤, 승인된 계정으로만 제출 결과를 살펴볼 수 있습니다. 실행 기록과 테스트 출력은 아직 확보하지 못했습니다.

보안과 제한#

공식 보안 안내는 Playwright MCP를 보안 경계로 간주하지 않습니다. 조회와 달리 클릭·제출은 외부 상태를 변경할 수 있으므로, 실제 서비스에서는 실행 전 별도 승인을 받으세요.

문제 해결과 자주 묻는 질문#

이 절의 진단 표는 공식 프로필·옵션·도구 설명을 바탕으로 한 진단 순서입니다(2026-11-02 확인). 실제 실패를 재현하거나 수정한 로그는 아닙니다.

스크린샷, 콘솔과 네트워크 기록에는 개인정보·인증 값이 포함될 수 있습니다. 공유 전에 직접 가리고, --isolated나 URL 제한 옵션만으로 외부 유출이 막힌다고 가정하지 마세요. 필요한 통제는 클라이언트·운영체제·네트워크에서도 적용해야 합니다.

브라우저 검증의 목표를 먼저 정하기#

Playwright MCP를 붙이는 목적이 코드 생성인지 실제 화면 확인인지 먼저 정하세요. 이 글은 후자에 초점을 둡니다. 가상의 문의 폼이라면 빈 입력의 오류, 올바른 입력의 제출 전 확인과 완료 상태를 검증할 수 있습니다. 실제 제출은 서버 상태를 바꿀 수 있으므로 어느 단계까지 허용하는지 따로 정해야 합니다. 테스트 계정과 대상 URL, 입력 데이터와 기대 결과를 먼저 승인받고 개인 계정의 기존 세션을 사용하지 않는 편이 안전합니다.

검증할 결과는 “페이지가 열린다”보다 구체적이어야 합니다. 제목과 입력 요소가 있는지, 오류가 어느 필드에 연결되는지, 제출 뒤 어떤 상태를 보여야 하는지 적으세요. 브라우저가 열렸다는 사실은 로그인과 폼, 회귀 확인이 모두 성공했다는 뜻이 아닙니다. 어떤 상태를 실제로 보고 어떤 행동을 하지 않았는지 기록합니다. 코드의 예상 결과와 브라우저에서 관찰한 결과도 구분해야 합니다.

표는 자료를 고르는 기준입니다. 스크린샷과 접근성 스냅샷은 서로 보완하지만 어느 쪽도 완전한 검증이 아닙니다. 자동화된 구조 확인을 실제 보조기술 사용자의 검토로 부르지 마세요. 브라우저 한 종류의 성공을 모든 환경의 호환성으로 확대하지 않습니다. 화면 크기, 브라우저와 버전, 대상 커밋을 함께 기록하면 전후 비교의 조건을 설명하기 쉽습니다.

설치 기록과 연결 기록을 따로 보관하기#

공식 README의 패키지 실행 명령은 서버를 준비하는 방법입니다. 실제 사용한 패키지와 버전, Node.js와 브라우저 버전을 남겨야 다른 사람이 같은 조건을 검토할 수 있습니다. @latest는 고정 버전이 아니므로 문서의 예시를 복사한 사실만으로 설치 버전이 기록되지 않습니다. 이 글은 패키지를 설치하지 않았습니다.

서버가 시작된 뒤에는 Mirr의 해당 전송과 인증 조합을 확인해야 합니다. HTTP 주소 등록, 도구 목록과 브라우저 조작은 각각 다른 결과입니다. 로컬 stdio 설정을 다른 호스트가 쓴다고 Mirr가 같은 JSON을 사용한다고 추정하지 마세요. 포트가 열렸다는 사실도 MCP 프로토콜과 브라우저 실행 성공을 보장하지 않습니다. 오류를 해결하려고 포트를 외부에 공개하거나 보안 제한을 무작정 해제하는 대응은 피합니다.

설치 오류와 실행 오류의 로그는 필요한 부분만 보관합니다. 경로에 사용자 이름이나 프로젝트 이름이 들어갈 수 있고 브라우저 시작 인자에 상태 파일 경로가 나타날 수 있습니다. 공유 전 직접 확인하세요. 사용할 설치 명령·정확한 버전·인증과 도구 출력은 해당 환경에서 얻어야 합니다. 일반 공식 사이트 화면과 로컬 웹페이지의 캡처는 이 설치·연결 기록을 대신하지 않습니다.

지속 프로필과 격리 프로필 선택#

지속 프로필은 세션을 이어 가는 데 편리할 수 있지만 쿠키와 로그인 상태가 남을 수 있습니다. 개인 업무 프로필을 연결하면 의도하지 않은 계정과 자료에 접근할 위험이 있습니다. 별도의 테스트 프로필과 계정을 검토하고 허용 URL과 로컬 파일 접근 범위를 정하세요. 다른 세션이 같은 프로필을 쓰고 있다면 충돌을 피할 방법을 확인해야 합니다. 문제를 해결하려고 사용 중인 프로필을 삭제하지 않습니다.

격리 모드는 브라우저가 닫힐 때 해당 세션의 저장 상태를 잃는다고 공식 문서가 설명합니다. 하지만 서버에 제출한 내용은 사라지지 않습니다. 격리된 브라우저 문맥과 네트워크·외부 쓰기를 막는 보안 경계는 다릅니다. 공식 README도 Playwright MCP를 보안 경계로 간주하지 않습니다. 필요한 통제는 클라이언트, 운영체제와 네트워크에서도 별도로 검토해야 합니다. 옵션 하나로 모든 유출과 제출이 차단된다고 설명하지 마세요.

저장 상태 파일을 제공하는 경우에는 세션 자격 증명처럼 취급해야 합니다. 승인된 테스트 계정의 파일만 사용하고 저장소나 공개 로그에 올리지 않습니다. 로그인 동작을 검증할 때와 로그인 이후의 기능을 검증할 때는 준비 상태가 다릅니다. 이미 로그인한 상태에서 폼을 확인한 결과를 로그인 성공 증거로 부르지 마세요. 계정·프로필·초기 상태와 실제 수행한 행동을 함께 기록해야 합니다.

README는 --isolated 옵션이 브라우저 프로필을 메모리에 두고 디스크에 저장하지 않는다고 설명합니다(Playwright MCP README). 로그인 검증이 필요한 과제마다 승인된 계정을 다시 연결하세요.

프로필을 지운 뒤에도 계정 정보가 남지 않는지 실행 결과로 확인하세요.

현재 스냅샷에서 요소를 다시 찾기#

페이지가 바뀌면 이전 요소 참조가 더 이상 맞지 않을 수 있습니다. 클릭 실패가 났을 때 같은 참조를 반복 사용하지 말고 현재 탭과 URL, 새로운 스냅샷을 확인하세요. 같은 이름의 버튼이 여러 개면 어느 영역의 버튼인지 좁혀야 합니다. 입력 폼, 모달과 뒤쪽 페이지가 함께 있는 상태에서는 이름만으로 대상을 고르기 어려울 수 있습니다. 공식 도구의 실제 스키마와 현재 참조를 사용하고 예전 화면의 좌표를 추측하지 않습니다.

셀렉터 실패를 기록할 때는 처음 기대한 대상, 실제 실패와 새 관찰에서 발견한 차이를 남깁니다. 예를 들어 버튼의 접근 가능한 이름이 바뀌었는지, 다른 탭으로 이동했는지와 렌더링이 아직 끝나지 않았는지 구분합니다. 이 예시는 진단 질문이며 실제로 그런 실패를 재현했다는 뜻이 아닙니다. 실패→수정 기록은 같은 과제의 실제 관찰로 연결해야 합니다. 성공 화면만으로 실패 원인과 수정이 입증되지는 않습니다.

화면에 보인 오류를 바로 제품 결함으로 단정하지 마세요. 테스트 데이터, 계정 권한과 환경 설정이 다를 수 있습니다. 반대로 테스트를 통과시키려고 잘못된 기대값을 현재 화면에 맞추면 회귀를 숨길 수 있습니다. 승인한 요구사항과 독립적인 기대 결과를 기준으로 비교하세요. 브라우저 자동화가 실패한 것과 실제 사용자 기능이 실패한 것도 구분해야 합니다. 재현 조건이 명확해질 때까지 근거를 모으는 편이 좋습니다.

폼 제출과 재시도의 승인 경계#

입력 필드에 값을 넣는 행동과 제출 버튼을 누르는 행동은 영향이 다를 수 있습니다. 자동 저장이 있는 폼은 입력 자체가 외부 상태를 바꿀 수도 있으므로 해당 화면의 동작을 먼저 확인하세요. 제출 전 수신 대상, 본문과 비용·알림 가능성을 사람이 검토해야 합니다. 결제, 메시지 전송과 실제 계정 생성은 일반적인 화면 확인 승인에 포함되지 않습니다. 이 글의 작업은 그런 외부 실행을 허가하지 않습니다.

제출 뒤 시간 초과가 나면 실제 서버와 현재 화면의 상태를 먼저 조회합니다. 요청이 저장됐는데 응답만 늦었을 수 있어 재전송이 중복을 만들 수 있습니다. 완료 화면, 대상 객체와 승인된 조회 결과를 대조하고 다시 누를지 판단하세요. 브라우저를 닫거나 /rewind를 사용해도 외부 제출은 자동 취소되지 않습니다. 테스트 데이터를 정리하는 작업도 별도 쓰기이므로 허용 범위와 서비스 복구 절차를 확인해야 합니다.

증거를 남길 때 가려야 할 정보#

스크린샷에는 이름, 이메일과 내부 URL이 보일 수 있고 콘솔·네트워크 기록에는 쿠키와 인증 헤더, 요청 본문이 담길 수 있습니다. 필요한 관찰만 수집하고 공유 전에 직접 검토하세요. 자동 비밀 치환 옵션은 편의 기능이지 보안 보증이 아니라는 공식 설명도 있습니다. 화면의 한 부분만 가렸다고 관련 로그 전체가 안전해지는 것은 아닙니다. 기록을 보관할 위치와 접근자, 삭제 기준도 조직 정책에 맞춰 정해야 합니다.

비교 화면은 같은 버전·계정·입력·화면 크기인지 확인합니다. 실패 화면과 수정 화면이 다른 과제라면 하나의 수정 기록처럼 묶지 마세요. 파일 해시와 대상 커밋을 남기면 검토한 자료와 이후 수정본을 구분하기 쉽습니다. 화면은 실제 브라우저 세션의 캡처여야 합니다. 생성 이미지나 웹사이트 소개 화면을 실행 결과처럼 쓰지 않습니다. 접근성 스냅샷을 화면 사진으로 부르는 것도 피해야 합니다.

작은 검증 과제의 완료 기준#

검증 완료는 요청한 상태를 관찰할 근거가 있을 때만 판단합니다. 다음 절의 가상 폼이라면 입력 거부와 값 유지, 올바른 요청과 결과 표시를 각각 확인해야 합니다. 로그인까지 포함한다면 테스트 계정과 인증 절차의 승인도 필요합니다. 제출이 금지된 환경에서는 제출 전 조건만 확인하고 뒤의 행은 미실행으로 남깁니다.

「작은 폼의 검증 행렬」 표는 실행할 수락 조건을 정한 자료이며 성공 화면이 아닙니다.

추가 근거: 공식 Playwright MCP README의 도구·프로필·보안 설명. 구조 관찰과 시각적 관찰, 격리 프로필과 보안 경계를 나누는 근거로 사용했습니다.

작은 폼의 검증 행렬을 작성하는 예#

다음은 실행하지 않은 가상의 문의 폼 계약입니다. 이름과 이메일이 필수이고 이름의 앞뒤 공백은 제거합니다. 검증자와 test@example.invalid를 정상 예시로 정하며 abc는 이 예시의 잘못된 이메일 입력입니다. 자동 저장은 없고 별도 제출 승인 뒤에만 요청을 보낸다고 가정합니다. 이메일 전체 표준을 정의하는 규칙이나 실제 서비스의 구현 설명은 아닙니다.

첫 두 행은 오류 문구가 보이는지만 검사하면 부족합니다. 이름 오류가 이메일 필드에 붙거나 잘못된 입력에서 요청이 전송되면 계약과 다릅니다. 화면의 빨간 글자와 접근성 구조의 필드 연결을 함께 살펴야 합니다. 다만 스냅샷과 화면만으로 서버에 데이터가 저장되지 않았다고 증명할 수는 없습니다. 요청·저장 여부를 판단할 자료가 없으면 그 항목은 미확인입니다. 실제 요청을 관찰할 권한도 먼저 검토해야 합니다.

정상 입력 행에서는 “제출하지 않음” 자체가 검사의 한계입니다. 값을 채웠다는 관찰을 완료 화면 확인으로 바꾸지 마세요. 모달이나 로딩 때문에 화면에 보이는 버튼을 실제로 조작할 수 없는 상태가 있을 수 있으므로 그 상태도 구분해야 합니다. 요청 중 중복 방지 역시 버튼 비활성화만으로 서버의 멱등성이 증명되는 것은 아닙니다. 같은 응답과 요청 식별자의 관계를 확인할 수 있어야 합니다. 이 표가 특정 서버의 멱등성 기능을 가정하지는 않습니다. 시간 초과 행은 앞서 설명한 반영 상태 확인과 별도 복구 원칙을 적용합니다.

회귀 비교에서 고정할 조건#

위 폼을 전후 비교한다면 대상 커밋 외의 입력, 테스트 계정·프로필 초기 상태, 브라우저와 화면 크기를 고정해야 합니다.

내부 식별자 변경을 만났을 때 모든 버튼을 잡는 넓은 선택으로 바꾸면 다른 동작을 수행해도 검사가 통과할 수 있습니다. 필요한 폼·역할·이름으로 대상을 좁히고 그 대상이 유일한지 다시 봅니다. 반면 이름이 사라지는 문제는 참조를 고치는 것으로 해결됐다고 할 수 없습니다. 테스트가 같은 필드와 값을 보았는지 확인한 뒤 기능 코드를 조사해야 합니다.

실패 화면과 수정 후 화면은 이처럼 같은 입력 조건의 차이를 보여 줘야 합니다. 다른 브라우저나 다른 데이터로 성공한 화면을 붙여 원인을 해결했다고 설명하지 않습니다. 실제로 두 상태를 관찰하지 못했다면 검증 계획만 제시한 것입니다.

다음에 연결할 것#

브라우저에서 발견한 오류를 코드와 함께 추적하려면 오류 원인 찾기 안내를 참고하세요.

관련#

• Mirr Code 오류 원인 찾기

편집 메모 (2026-11-02): 공식 실행 방식과 프로필 충돌·요소 실패 진단을 보충했습니다.