채팅창에서 말로 브라우저를 조종한다 - Playwright MCP 도입기
“화면 테스트할 때마다 브라우저 켜고 클릭하는 거, 좀 줄일 수 없을까?” 하는 생각에서 시작한 실전 기록입니다. 사내 웹 화면 프로젝트에 Playwright MCP를 붙여, 채팅창에서 자연어로 브라우저를 조작하게 만든 과정을 정리했습니다.
TL;DR
- Playwright MCP를 Kiro에 붙이면, 채팅창에 말로 지시해서 실제 브라우저를 조작할 수 있습니다.
- “로그인 페이지 열어서 아이디/비번 넣고 로그인해줘” 같은 자연어가 그대로 동작합니다.
- 핵심은 스크린샷이 아니라 접근성 트리(Accessibility Tree) 기반이라, Vision 모델 없이도 요소를 정확히 찾습니다.
- 설정은
mcp.json에 몇 줄이면 끝. Node.js만 있으면 됩니다. - 수동 테스트를 완전히 대체하진 않지만, 반복적인 화면 확인/입력 검증/시나리오 재현 시간을 크게 줄여줍니다.
- 정식 E2E 스위트나 CI 자동화 대체용은 아닙니다. 대화형 탐색 테스트에 강합니다.
목차
- 왜 도입했나
- Playwright MCP란?
- Kiro에서 설정하기
- 실제 사용 예시
- 실전 활용 사례
- 장점과 한계
- 팁과 주의사항
- 마치며
⚠️ 이 글의 화면 이름, URL, 입력값은 전부 가상의 예시입니다. 실제 사내 화면이나 데이터는 포함하지 않았습니다.
1. 왜 도입했나
개발 중에 화면을 테스트하려면 보통 이렇습니다. 브라우저를 직접 열고, 클릭하고, 값 넣고, 결과를 눈으로 확인합니다. 한두 번이면 괜찮은데 같은 시나리오를 수십 번 반복하다 보면 지치고, 놓치는 부분도 생깁니다.
그러다 Playwright MCP를 알게 됐습니다. Kiro에 연결하면 채팅창에서 자연어로 브라우저를 조작할 수 있다길래, 제가 맡고 있는 웹 화면 프로젝트에 한번 붙여봤습니다. “로그인 페이지 열어서 아이디랑 비번 넣고 로그인해줘” 같은 말로 실제 브라우저가 움직이는 걸 보니, 반복 확인 작업의 상당 부분을 넘길 수 있겠다 싶었습니다.
수동 테스트를 완전히 대체하는 물건은 아닙니다. 다만 반복적인 화면 확인, 입력 검증, 시나리오 재현에 드는 시간을 확 줄여줬습니다. 이 글은 그 도입 과정과, 실제로 써보며 느낀 장단점을 정리한 기록입니다.
2. Playwright MCP란?
핵심 개념
세 가지만 알면 됩니다.
| 구성 요소 | 설명 |
|---|---|
| Playwright | Microsoft가 만든 브라우저 자동화 라이브러리 (Chrome, Firefox, WebKit 지원) |
| MCP (Model Context Protocol) | AI 에이전트가 외부 도구와 소통하는 표준 프로토콜 |
| Playwright MCP Server | Playwright를 MCP로 감싸, AI가 브라우저를 조작할 수 있게 해주는 서버 |
동작 방식
1
2
3
4
5
6
7
사용자 (자연어 지시)
↓
Kiro AI (지시 해석 → MCP 도구 호출)
↓
Playwright MCP Server (브라우저 명령 실행)
↓
실제 브라우저 (Chrome 등)
여기서 가장 중요한 특징. 이 서버는 스크린샷이 아니라 접근성 트리(Accessibility Tree) 를 기반으로 동작합니다. DOM 구조를 구조화된 데이터로 파싱하기 때문에, Vision 모델 없이도 버튼/입력칸/그리드 같은 요소를 정확히 찾아 조작합니다. “이미지를 눈으로 보고 클릭”하는 게 아니라 “구조를 읽고 정확히 짚는” 방식이라 빠르고 안정적입니다.
3. Kiro에서 설정하기
사전 요구사항
- Node.js 18 이상 (npx를 쓸 수 있어야 합니다)
- Kiro IDE
설정 방법: 프롬프트로 바로 추가
설정 파일을 직접 편집할 필요도 없습니다. Kiro 채팅창에 아래를 그대로 던지면 됩니다.
1
2
3
4
5
6
7
8
9
10
Playwright MCP 서버를 설정해줘.
.kiro/settings/mcp.json에 아래 설정을 추가해줘:
{
"playwright": {
"command": "npx",
"args": ["@playwright/mcp@latest"],
"disabled": false
}
}
Kiro가 mcp.json을 직접 수정해줍니다. 기존 설정이 있으면 병합됩니다.
설정 완료 후 확인
설정이 적용되면 Kiro 하단 MCP 상태 표시줄에 playwright 서버가 연결된 것이 보입니다. 채팅에서 아래를 입력해 동작을 확인해보세요.
1
https://www.google.com 으로 이동해줘
브라우저가 열리면서 Google 페이지가 뜨면 성공입니다.
자주 쓰는 옵션
mcp.json의 args에 옵션을 추가할 수 있습니다.
| 옵션 | 설명 | 예시 |
|---|---|---|
--headless | 브라우저를 숨기고 실행 (CI 등) | "args": ["@playwright/mcp@latest", "--headless"] |
--browser | 사용할 브라우저 지정 | "--browser", "firefox" |
--device | 모바일 디바이스 에뮬레이션 | "--device", "iPhone 15" |
--caps | 추가 기능 활성화 | "--caps", "vision,pdf" |
autoApprove 설정 (권장)
매번 도구 실행 허가를 묻지 않게 하려면 autoApprove를 설정합니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
{
"playwright": {
"command": "npx",
"args": ["@playwright/mcp@latest"],
"disabled": false,
"autoApprove": [
"browser_navigate",
"browser_snapshot",
"browser_take_screenshot",
"browser_console_messages",
"browser_network_requests"
]
}
}
💡 읽기 전용 도구만
autoApprove하고, 클릭/입력 같은 조작 도구는 매번 허가를 받는 편이 안전합니다. 자동화가 실수로 데이터를 바꾸는 상황을 막을 수 있습니다.
4. 실제 사용 예시
아래는 제가 실제로 써본 패턴을, 화면 이름과 값만 가상으로 바꿔 정리한 것입니다.
4.1 페이지 열고 스냅샷 확인
1
http://localhost:8080/orders 페이지 열어서 현재 화면 상태 알려줘
Kiro가 페이지를 열고, 접근성 스냅샷으로 화면에 어떤 요소(버튼, 입력칸, 그리드 등)가 있는지 구조적으로 보여줍니다.
4.2 로그인 시나리오
1
2
3
http://localhost:8080/login 으로 가서
아이디에 "testuser", 비밀번호에 "test1234" 입력하고 로그인 버튼 클릭해줘.
로그인 후 화면 상태를 알려줘.
4.3 그리드 데이터 확인
1
주문 목록 화면에서 그리드에 데이터가 몇 건 있는지 확인해줘
4.4 입력 검증 테스트
1
2
주문 등록 화면에서 주문번호를 빈칸으로 두고 저장 버튼을 눌러봐.
필수값 에러 메시지가 뜨는지 확인해줘.
4.5 네트워크 요청 확인
1
저장 버튼을 누를 때 어떤 API가 호출되는지 네트워크 요청 목록을 보여줘
4.6 콘솔 에러 확인
1
현재 페이지의 콘솔 에러 메시지가 있으면 보여줘
5. 실전 활용 사례
제가 맡은 프로젝트는 복잡한 커스텀 UI 프레임워크(WebSquare 같은 엔터프라이즈 웹 프레임워크)로 만든 화면이 많습니다. 이런 환경에서 Playwright MCP가 특히 쓸모 있었던 지점을 정리하면 이렇습니다.
- 화면 로드 후 그리드/폼 상태 확인: 접근성 트리를 통해 그리드 행 수, 셀 값, 버튼 활성화 상태를 텍스트로 받아볼 수 있습니다.
- 입력 검증 로직 테스트: 필수값 미입력 → 저장 시도 → 에러 메시지 확인을 채팅 한 번으로 수행합니다.
- 다국어 전환 확인: 언어를 바꾼 뒤 라벨이 정상적으로 바뀌었는지 확인합니다.
- API 응답 검증: 네트워크 요청을 캡처해 실제 호출된 URL과 파라미터를 확인합니다.
시나리오 하나로 여러 단계 실행
여러 단계를 하나의 프롬프트로 묶어 실행할 수 있다는 게 특히 편했습니다.
1
2
3
4
5
1. http://localhost:8080/orders 열어줘
2. 조회 버튼 클릭
3. 그리드에 데이터 나오면 첫 번째 행 클릭
4. 상세 팝업이 열리는지 확인
5. 팝업 안의 주문번호 값을 알려줘
이 전체 흐름을 한 번에 시키면 Kiro가 순서대로 조작하며 각 단계 결과를 보고합니다. “이 시나리오 다시 해봐”라고 하면 동일 테스트를 그대로 재실행할 수도 있습니다.
6. 장점과 한계
👍 장점
| 항목 | 설명 |
|---|---|
| 자연어로 조작 | 코드 작성 없이 말로 브라우저를 제어 |
| 반복 작업 경감 | “이 시나리오 다시 해봐”로 동일 테스트 재실행 |
| 접근성 기반 | Vision 모델 불필요, 구조적으로 요소를 파악 |
| 네트워크/콘솔 확인 | API 호출이나 JS 에러를 바로 확인 |
| 스크린샷 캡처 | 필요 시 스크린샷을 파일로 저장 |
| 설정이 간단 | mcp.json 몇 줄이면 끝 (Node.js만 있으면 됨) |
👎 한계와 주의점
| 항목 | 설명 |
|---|---|
| CI/CD 자동화용 아님 | 대화형 탐색 테스트에 적합. 정식 E2E 스위트 대체는 아님 |
| 복잡한 DOM | 복잡한 커스텀 컴포넌트는 접근성 트리에서 식별이 어려울 수 있음 |
| 상태 유지 제한 | 긴 시나리오에서 브라우저 세션이 끊기면 처음부터 다시 |
| 보안 | 로컬 동작이라 유출 위험은 적지만, 자격증명 입력 시 주의 |
7. 팁과 주의사항
써보며 정리한 실전 팁입니다.
- 읽기 도구만 자동 승인: 조회성 도구만
autoApprove하고, 클릭/입력/저장 같은 변경성 도구는 매번 확인을 받으세요. 자동화가 실수로 데이터를 바꾸는 사고를 막습니다. - 자격증명은 테스트 계정으로: 실제 운영 계정 대신 테스트 계정을 쓰고, 채팅창에 비밀번호를 평문으로 남기지 않도록 주의하세요.
- 긴 시나리오는 쪼개기: 세션이 끊기면 처음부터 다시 해야 하므로, 아주 긴 흐름은 몇 단계로 나눠 진행하는 편이 안정적입니다.
- 복잡한 컴포넌트는 스냅샷 먼저: 요소를 못 찾을 때는 먼저 “현재 화면 스냅샷을 보여줘”로 접근성 트리를 확인하면, 어떤 이름으로 요소를 지칭해야 하는지 알 수 있습니다.
⚠️ 이런 도구로 얻은 화면 구조나 API 응답을 외부(블로그 포함)로 공유할 때는, 실제 화면 이름, URL, 데이터가 새어나가지 않는지 반드시 확인하세요. 그래서 이 글의 예시도 전부 가상으로 바꿔 썼습니다.
8. 마치며
“화면 테스트 반복이 지겹다”에서 시작해 붙여봤는데, 막상 써보니 단순 클릭 대행을 넘어 입력 검증, 네트워크 확인, 시나리오 재현까지 채팅 한 번으로 넘길 수 있는 게 컸습니다. 정식 E2E 스위트를 대체하진 못해도, 개발 중 “이거 한번 확인해볼까?” 싶은 순간의 마찰을 확 줄여줍니다.
비슷하게 반복 확인 작업에 지치신 분이라면, mcp.json 몇 줄로 가볍게 시작해볼 만합니다.
(이 글은 개인 도입 경험을 정리한 것으로, 사용한 도구의 구성 방식이나 옵션은 버전에 따라 바뀔 수 있습니다. 실제 적용 시 각 도구의 공식 문서를 확인하세요.)