Playwright MCP를 붙이기 전, AI에게 브라우저를 어디까지 맡길지 먼저 정해야 합니다

Playwright MCP는 AI가 웹앱을 직접 탐색하고 조작하게 해주는 강력한 도구입니다. 다만 사내 업무시스템에 붙이기 전에는 설치보다 먼저 “접근 범위·인증 세션·파일 권한·검증 로그”를 정해야 합니다.

들어가며 — 독자가 지금 이 문제를 검색하는 이유

웹앱 QA나 사내 업무시스템 점검을 하다 보면 이런 생각이 듭니다.

“반복해서 로그인하고, 메뉴를 클릭하고, 화면 상태를 확인하는 일을 AI 에이전트에게 맡길 수 없을까?”

이 질문에 가장 직접적으로 닿아 있는 도구 중 하나가 Microsoft의 Playwright MCP입니다.

Playwright MCP는 Model Context Protocol, 즉 MCP를 통해 AI 에이전트가 브라우저 자동화를 수행할 수 있게 해주는 서버입니다. GitHub 저장소 설명에 따르면 이 MCP 서버는 브라우저 접근성 트리 기반으로 동작하며, AI가 웹페이지를 탐색하고 조작할 수 있도록 돕습니다.

출처: microsoft/playwright-mcp GitHub

하지만 여기서 봐야 할 것은 “가능하다”가 아니라 “어디까지 허용할 것인가”입니다.

브라우저 자동화 MCP는 코드 저장소를 읽는 도구와 다릅니다.

실제 로그인 세션, 쿠키, 사내 데이터, 다운로드 파일, 업로드 동작, 버튼 클릭이 모두 연결될 수 있습니다. 그래서 데모처럼 “AI가 클릭한다”에만 집중하면 운영 리스크를 놓치기 쉽습니다.

이번 글에서는 Playwright MCP를 사내 웹앱 QA나 업무시스템 점검에 붙이기 전, 반드시 확인해야 할 설치 전제·권한·검증 기준을 정리합니다.

Playwright MCP는 무엇을 해주는가

Playwright MCP는 Microsoft가 공개한 MCP 서버입니다. AI 에이전트가 Playwright 기반 브라우저 자동화를 사용할 수 있게 해줍니다. npm 패키지로는 @playwright/mcp가 제공됩니다.

출처: @playwright/mcp npm

리서치 기준으로 GitHub 저장소는 36,250 stars를 기록했고, 최신 릴리스 v0.0.79는 2026년 8월 6일 공개되었습니다. 다만 GitHub stars는 확인 시점에 따라 달라질 수 있으므로 발행 전 재확인이 필요합니다.

출처: Playwright MCP v0.0.79 release

Playwright MCP의 핵심은 “브라우저를 대신 열고 조작한다”는 점입니다.

일반적인 MCP 서버가 문서 검색, 코드 저장소 접근, API 호출을 돕는다면 Playwright MCP는 실제 웹 화면과 상호작용합니다.

예를 들면 다음과 같은 업무에 활용할 수 있습니다.

• 사내 웹앱 로그인 후 주요 메뉴 접근 확인
• 배포 후 핵심 화면이 정상 표시되는지 점검
• 폼 입력, 버튼 클릭, 결과 화면 확인
• QA 시나리오 반복 실행
• 접근성 트리 기반 화면 상태 확인

여기서 중요한 차이가 있습니다.

Playwright MCP는 “브라우저 조작을 위한 MCP”입니다.

따라서 연결하는 순간 AI 에이전트는 단순히 정보를 읽는 것이 아니라, 웹 화면에서 실제 행동을 할 수 있습니다.

그래서 사내 업무에 적용할 때는 설치 명령어보다 다음 질문이 먼저입니다.

“이 에이전트가 어느 사이트에 접속할 수 있고, 어떤 버튼까지 누를 수 있으며, 그 결과를 어떻게 검증할 것인가?”

설치보다 먼저 정해야 할 4가지 권한 기준

Playwright MCP를 붙이기 전에는 최소한 네 가지를 먼저 정해야 합니다.

1. 허용 도메인: 어디까지 접속할 수 있는가

브라우저 자동화 MCP는 웹을 탐색할 수 있습니다.

따라서 사내 웹앱 QA에 쓰려면 “접속 가능한 범위”를 명확히 해야 합니다.

예를 들어 다음을 구분해야 합니다.

• 로컬 개발 서버만 허용할 것인가
• 스테이징 환경까지 허용할 것인가
• 운영 환경 접근을 금지할 것인가
• 외부 웹사이트 접근을 차단할 것인가
• 사내 SSO 로그인 페이지 접근을 허용할 것인가

특히 운영 환경에 접근하는 경우, AI의 버튼 클릭은 단순 조회를 넘어 실제 변경으로 이어질 수 있습니다.

따라서 운영 환경에서는 읽기 전용 계정, 제한된 테스트 계정, 별도 테스트 데이터를 써야 합니다.

정리하면, Playwright MCP의 첫 번째 운영 기준은 “브라우저를 열 수 있느냐”가 아니라 “어느 URL까지 열 수 있느냐”입니다.

2. 인증 세션과 쿠키: 누구의 권한으로 실행되는가

브라우저 자동화는 로그인 세션과 함께 동작할 수 있습니다.

이때 가장 조심해야 할 부분은 “AI가 누구의 권한을 빌려 쓰는가”입니다.

개인 계정으로 로그인한 브라우저 세션을 그대로 사용하면 문제가 생길 수 있습니다.

• 개인 권한으로 사내 데이터에 접근할 수 있음
• 쿠키와 세션이 자동화 과정에 노출될 수 있음
• 사용자별 권한 차이 때문에 테스트 결과가 재현되지 않을 수 있음
• 누가 어떤 조작을 했는지 감사 추적이 어려워질 수 있음

따라서 Playwright MCP를 업무에 붙일 때는 가능한 한 자동화 전용 계정을 분리하는 편이 안전합니다.

권장 기준은 다음과 같습니다.

• 개인 계정 대신 테스트 전용 계정 사용
• 운영 데이터 접근이 필요한 경우 최소 권한 적용
• 세션 재사용 범위와 만료 기준 정의
• 로그인 정보와 토큰을 프롬프트에 직접 입력하지 않기
• 자동화 실행 로그와 계정 활동 로그를 함께 확인

브라우저 자동화 MCP의 권한은 곧 로그인 계정의 권한입니다.

따라서 “MCP 권한”만 볼 것이 아니라 “브라우저 세션 권한”까지 함께 봐야 합니다.

3. 다운로드·업로드: 파일이 오가는 순간 위험이 커진다

웹앱 QA에서 자주 놓치는 부분이 파일 다운로드와 업로드입니다.

AI가 브라우저를 조작할 수 있다면 다음과 같은 행동도 시나리오에 포함될 수 있습니다.

• 리포트 파일 다운로드
• 첨부파일 업로드
• 엑셀·PDF·이미지 파일 선택
• 다운로드된 파일 내용 확인
• 양식 제출

이 작업은 단순 화면 확인보다 리스크가 큽니다.

다운로드는 민감 정보 유출과 연결될 수 있고, 업로드는 잘못된 파일 제출이나 데이터 변경으로 이어질 수 있습니다. 특히 사내 업무시스템에서는 첨부파일 하나가 결재, 고객 응대, 발주, 계약, 품질 관리 프로세스와 연결될 수 있습니다.

따라서 Playwright MCP를 적용할 때는 파일 처리 기준을 따로 정해야 합니다.

• 다운로드 허용 여부
• 다운로드 파일 저장 위치
• 다운로드 파일 보존 기간
• 업로드 허용 여부
• 업로드 가능한 테스트 파일 범위
• 실제 업무 파일 사용 금지 여부
• 자동화가 제출 버튼까지 누를 수 있는지 여부

처음 도입할 때는 다운로드·업로드를 막고, 화면 탐색과 상태 확인부터 시작하는 편이 안전합니다.

4. 검증 로그: AI가 “봤다”고 말하는 것을 어떻게 확인할 것인가

AI 에이전트가 브라우저를 조작하면 결과를 자연어로 설명할 수 있습니다.

하지만 운영에서는 “AI가 그렇게 말했다”만으로 충분하지 않습니다.

무엇을 열었고, 어떤 요소를 봤고, 어떤 버튼을 눌렀고, 어떤 결과가 나왔는지 확인할 수 있어야 합니다.

Playwright MCP README는 접근성 트리 기반 자동화를 제공한다고 설명합니다.

출처: microsoft/playwright-mcp GitHub

이 관점은 중요합니다.

브라우저 자동화 결과를 검증할 때 단순 스크린샷만 남기기보다, 접근성 스냅샷이나 단계별 실행 기록을 함께 남기면 재현성과 감사 가능성이 높아집니다.

검증 로그에는 최소한 다음 항목이 필요합니다.

• 실행한 URL
• 사용한 계정 또는 계정 유형
• 수행한 단계
• 클릭·입력한 주요 요소
• 확인한 화면 상태
• 실패한 단계와 오류 메시지
• 다운로드·업로드 발생 여부
• 최종 판단 근거

특히 QA 업무에서는 “성공”이라는 결론보다 “무엇을 근거로 성공이라 판단했는가”가 더 중요합니다.

최소 적용 단계: 사내 웹앱 QA에 붙이는 순서

Playwright MCP를 처음 적용한다면, 처음부터 운영 환경 전체를 맡기지 않는 것이 좋습니다.

다음 순서처럼 작은 범위에서 시작하는 편이 안전합니다.

1단계: 대상 업무 결과물을 하나로 좁히기

먼저 자동화 결과물을 하나로 정합니다.

예를 들어 다음처럼 구체화합니다.

• “배포 후 로그인 페이지와 대시보드 진입 여부를 확인하는 QA 리포트”
• “스테이징 환경에서 주요 메뉴 5개가 열리는지 확인하는 점검 기록”
• “업무시스템 신청서 화면이 정상 렌더링되는지 확인하는 테스트 결과”

이번 글의 기준 결과물은 다음과 같이 잡을 수 있습니다.

“스테이징 웹앱에 접속해 로그인 후 핵심 화면 3개를 확인하고, 단계별 검증 로그를 남기는 브라우저 자동화 사전 점검표”

이렇게 결과물을 좁히면 에이전트에게 줄 권한도 좁아집니다.

2단계: 실행 환경을 분리하기

브라우저 자동화는 가능하면 개인 업무 환경과 분리해야 합니다.

최소 기준은 다음과 같습니다.

• 테스트 전용 계정 사용
• 스테이징 또는 로컬 환경 우선 적용
• 운영 환경은 초기 적용 대상에서 제외
• 민감 데이터가 없는 테스트 데이터 사용
• 자동화 실행 계정의 권한 최소화

이 단계에서 중요한 것은 “자동화가 실패해도 실제 업무에 영향이 없는가”입니다.

3단계: Playwright MCP 연결 전제를 확인하기

Playwright MCP는 GitHub 저장소와 npm 패키지로 공개되어 있습니다.

출처: microsoft/playwright-mcp GitHub, @playwright/mcp npm

다만 실제 연결 방식은 사용하는 AI 클라이언트나 에이전트 환경에 따라 달라질 수 있습니다.

따라서 설치 전에 다음을 확인해야 합니다.

• 현재 사용하는 AI 에이전트가 MCP 서버 연결을 지원하는가
• 로컬 MCP 서버 실행이 가능한 환경인가
• Node.js/npm 기반 패키지 실행이 가능한가
• 브라우저 실행이 허용되는 서버 또는 로컬 환경인가
• 사내 보안 정책상 브라우저 자동화 도구 실행이 가능한가
• 프록시, 방화벽, 인증 정책에 막히지 않는가

여기서 하나라도 불명확하면 “설치 완료”보다 “운영 가능 조건 확인”이 먼저입니다.

4단계: 첫 시나리오는 읽기 전용으로 제한하기

첫 시나리오는 반드시 읽기 전용에 가깝게 설계하는 것이 좋습니다.

예를 들어 다음 정도로 시작합니다.

1. 지정된 스테이징 URL 접속

2. 테스트 계정으로 로그인

3. 대시보드 진입 여부 확인

4. 메뉴 2~3개 이동

5. 주요 텍스트 또는 화면 상태 확인

6. 로그아웃

7. 단계별 결과 기록

반대로 초기 시나리오에서 피해야 할 작업은 다음과 같습니다.

• 신청서 제출
• 결재 승인
• 데이터 삭제
• 실제 고객 정보 다운로드
• 운영 환경 설정 변경
• 대량 업로드
• 관리자 메뉴 조작

AI 브라우저 자동화는 처음부터 “할 수 있는 일”을 늘리는 방식보다 “하면 안 되는 일”을 먼저 정하는 방식이 안전합니다.

바로 적용하는 체크리스트 또는 비교 기준

아래 체크리스트는 Playwright MCP를 사내 웹앱 QA나 업무시스템 점검에 붙이기 전 사용할 수 있는 사전 점검표입니다.

Playwright MCP 사전 점검표

구분	점검 질문	권장 기준
적용 목적	무엇을 자동화할 것인가?	“웹앱 전체 점검”이 아니라 “로그인 후 핵심 화면 3개 확인”처럼 좁게 정의
대상 환경	어디에 접속할 것인가?	로컬 또는 스테이징 우선, 운영 환경은 별도 승인 후 검토
허용 도메인	어떤 URL까지 접근 가능한가?	허용 도메인 목록을 사전에 고정
계정 권한	누구의 권한으로 실행되는가?	개인 계정 금지, 테스트 전용 계정 사용
세션 관리	쿠키와 로그인 세션은 어떻게 관리하는가?	세션 재사용 범위와 만료 기준 정의
데이터 범위	실제 업무 데이터에 접근하는가?	민감 정보 없는 테스트 데이터 우선
클릭 권한	버튼 클릭이 실제 변경을 일으키는가?	제출·승인·삭제 버튼은 초기 자동화에서 제외
다운로드	파일 다운로드를 허용할 것인가?	초기에는 비활성화하거나 저장 위치·보존 기간 지정
업로드	파일 업로드를 허용할 것인가?	테스트 파일만 허용, 실제 업무 파일 금지
검증 방식	결과를 무엇으로 확인할 것인가?	접근성 스냅샷, 단계별 로그, 화면 상태 근거 기록
실패 대응	실패하면 어떻게 중단할 것인가?	오류 발생 시 즉시 중단하고 재시도 조건 분리
감사 추적	누가 언제 무엇을 실행했는가?	실행 계정, 시간, URL, 주요 액션 기록
보안 검토	사내 정책상 허용되는가?	브라우저 자동화·MCP 실행·외부 패키지 사용 정책 확인

도입 판단 기준

Playwright MCP가 적합한 경우는 다음과 같습니다.

• 실제 웹 화면을 탐색해야 한다
• 로그인 후 화면 상태를 확인해야 한다
• QA 시나리오를 반복 실행해야 한다
• 접근성 트리 기반으로 요소를 확인하고 싶다
• 브라우저 조작 결과를 단계별로 검증하고 싶다

반대로 다음 상황에서는 신중해야 합니다.

• 운영 환경에서 관리자 권한으로 실행해야 한다
• 고객 정보나 민감 데이터가 화면에 표시된다
• 클릭 한 번이 결재·발주·삭제로 이어진다
• 자동화 로그를 남길 수 없다
• 테스트 계정이나 스테이징 환경이 없다
• 사내 보안 정책상 브라우저 자동화 도구 실행이 불명확하다

또 하나 주의할 점이 있습니다.

Playwright MCP README는 코딩 에이전트에는 CLI와 skills 조합이 더 토큰 효율적일 수 있다고 구분합니다.

출처: microsoft/playwright-mcp GitHub

즉, 모든 자동화에 Playwright MCP가 최선은 아닙니다.

• 코드 수정과 테스트 실행이 중심이면 CLI와 agent skills가 더 적합할 수 있습니다.
• 웹 화면을 직접 탐색하고 상태를 확인해야 한다면 Playwright MCP가 더 적합할 수 있습니다.
• 외부 시스템 API 호출이 핵심이면 별도 MCP 서버나 기존 자동화 도구가 더 적합할 수 있습니다.

도구 선택 기준은 “최신인가”가 아니라 “어떤 업무 결과물을 안전하게 재현할 수 있는가”입니다.

마무리 + 생각해볼 질문 1개

Playwright MCP는 AI 에이전트에게 브라우저를 맡길 수 있게 해주는 흥미로운 도구입니다.

하지만 사내 웹앱이나 업무시스템에 붙이는 순간, 이것은 단순한 데모가 아니라 운영 권한의 문제가 됩니다.

핵심은 설치 명령어가 아닙니다.

• 어느 도메인까지 접속할 것인가
• 어떤 계정으로 로그인할 것인가
• 어떤 버튼까지 누를 수 있는가
• 다운로드와 업로드를 허용할 것인가
• AI의 판단을 어떤 로그로 검증할 것인가

이 다섯 가지가 정리되어야 브라우저 자동화 MCP를 업무에 안전하게 붙일 수 있습니다.

Playwright MCP를 도입하려는 팀이라면 먼저 큰 자동화 목표를 세우기보다, “스테이징 환경에서 핵심 화면 3개를 확인하고 검증 로그를 남기는 작은 시나리오”부터 시작하는 것이 좋습니다.

생각해볼 질문은 하나입니다.

우리 팀은 AI가 브라우저에서 “무엇을 할 수 있는지”보다, “무엇을 하면 안 되는지”를 먼저 문서로 정해두었는가?