포스트

채팅창에서 말로 브라우저를 조종한다 - Playwright MCP 도입기

채팅창에서 말로 브라우저를 조종한다 - Playwright MCP 도입기

“화면 테스트할 때마다 브라우저 켜고 클릭하는 거, 좀 줄일 수 없을까?” 하는 생각에서 시작한 실전 기록입니다. 사내 웹 화면 프로젝트에 Playwright MCP를 붙여, 채팅창에서 자연어로 브라우저를 조작하게 만든 과정을 정리했습니다.

TL;DR

  • Playwright MCP를 Kiro에 붙이면, 채팅창에 말로 지시해서 실제 브라우저를 조작할 수 있습니다.
  • “로그인 페이지 열어서 아이디/비번 넣고 로그인해줘” 같은 자연어가 그대로 동작합니다.
  • 핵심은 스크린샷이 아니라 접근성 트리(Accessibility Tree) 기반이라, Vision 모델 없이도 요소를 정확히 찾습니다.
  • 설정은 mcp.json에 몇 줄이면 끝. Node.js만 있으면 됩니다.
  • 수동 테스트를 완전히 대체하진 않지만, 반복적인 화면 확인/입력 검증/시나리오 재현 시간을 크게 줄여줍니다.
  • 정식 E2E 스위트나 CI 자동화 대체용은 아닙니다. 대화형 탐색 테스트에 강합니다.

목차

  1. 왜 도입했나
  2. Playwright MCP란?
  3. Kiro에서 설정하기
  4. 실제 사용 예시
  5. 실전 활용 사례
  6. 장점과 한계
  7. 팁과 주의사항
  8. 마치며

⚠️ 이 글의 화면 이름, URL, 입력값은 전부 가상의 예시입니다. 실제 사내 화면이나 데이터는 포함하지 않았습니다.

1. 왜 도입했나

개발 중에 화면을 테스트하려면 보통 이렇습니다. 브라우저를 직접 열고, 클릭하고, 값 넣고, 결과를 눈으로 확인합니다. 한두 번이면 괜찮은데 같은 시나리오를 수십 번 반복하다 보면 지치고, 놓치는 부분도 생깁니다.

그러다 Playwright MCP를 알게 됐습니다. Kiro에 연결하면 채팅창에서 자연어로 브라우저를 조작할 수 있다길래, 제가 맡고 있는 웹 화면 프로젝트에 한번 붙여봤습니다. “로그인 페이지 열어서 아이디랑 비번 넣고 로그인해줘” 같은 말로 실제 브라우저가 움직이는 걸 보니, 반복 확인 작업의 상당 부분을 넘길 수 있겠다 싶었습니다.

수동 테스트를 완전히 대체하는 물건은 아닙니다. 다만 반복적인 화면 확인, 입력 검증, 시나리오 재현에 드는 시간을 확 줄여줬습니다. 이 글은 그 도입 과정과, 실제로 써보며 느낀 장단점을 정리한 기록입니다.

2. Playwright MCP란?

핵심 개념

세 가지만 알면 됩니다.

구성 요소설명
PlaywrightMicrosoft가 만든 브라우저 자동화 라이브러리 (Chrome, Firefox, WebKit 지원)
MCP (Model Context Protocol)AI 에이전트가 외부 도구와 소통하는 표준 프로토콜
Playwright MCP ServerPlaywright를 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.jsonargs에 옵션을 추가할 수 있습니다.

옵션설명예시
--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 몇 줄로 가볍게 시작해볼 만합니다.

(이 글은 개인 도입 경험을 정리한 것으로, 사용한 도구의 구성 방식이나 옵션은 버전에 따라 바뀔 수 있습니다. 실제 적용 시 각 도구의 공식 문서를 확인하세요.)

참고 링크