본문으로 건너뛰기
중급25

Claude Code와 Playwright MCP로 실전 테스트 자동화

레슨 4에서 배운 MCP 개념을 실제 도구로 구체화한다. Claude Code에 Playwright MCP 서버를 연결해, 자연어 지시로 브라우저 테스트를 실행하고 검증하는 과정을 실습한다.

  • #ClaudeCode
  • #PlaywrightMCP
  • #테스트자동화
  • #실습

개념

레슨 4의 개념을 손에 잡히는 도구로

레슨 4에서 "MCP가 AI와 도구 사이를 연결하는 표준 규격"이라는 걸 개념으로 배웠다. 이 레슨은 그 개념을 실제로 만져본다 — Claude Code(터미널에서 쓰는 Anthropic의 코딩 에이전트)에 Playwright MCP 서버를 연결하면, "로그인 페이지에서 이메일 형식 검증이 제대로 되는지 확인해줘" 같은 자연어 지시만으로 브라우저가 실제로 열리고, 클릭하고, 결과를 판단하는 것까지 이어진다.

연결 구조

Claude Code (AI 에이전트)
   ↕ MCP
Playwright MCP 서버 (브라우저 제어 도구)

실제 브라우저 (Chromium/Firefox/WebKit)

Claude Code 설정 파일에 Playwright MCP 서버를 등록해두면, Claude Code가 "이 작업엔 브라우저 조작이 필요하다"고 판단할 때마다 이 서버를 통해 실제 브라우저를 띄우고 조작한다. 사람은 설정을 한 번 해두는 것 외엔 별도 코드를 짤 필요가 없다 — 이게 모듈 13에서 배운 "Playwright 스크립트를 사람이 직접 짜는" 방식과의 근본적인 차이다.

실제 사용 흐름

1. 사람: "회원가입 폼에서 비밀번호를 8자 미만으로 입력하면
         에러 메시지가 뜨는지 확인해줘"
2. Claude Code: 이 작업엔 브라우저가 필요하다고 판단
3. Playwright MCP를 통해 브라우저를 열고 회원가입 페이지로 이동
4. 비밀번호 필드에 7자짜리 값을 입력하고 제출 버튼 클릭
5. 화면에 에러 메시지가 나타났는지 확인
6. 사람에게 결과 보고: "에러 메시지 '최소 8자 이상 입력하세요'가
   정상적으로 표시됨을 확인했습니다"

이 흐름은 레슨 4에서 배운 5단계(판단 → MCP 요청 → 도구 실행 → 결과 전달 → 다음 판단)가 실제 화면에서 그대로 일어나는 모습이다.

코드 자동화와 무엇이 다른가

기존 Playwright 자동화(모듈 13)Claude Code + Playwright MCP
테스트 케이스사람이 코드로 미리 작성자연어 지시를 그때그때 해석
변경 대응셀렉터가 바뀌면 코드 수정 필요레슨 3의 셀프힐링과 유사하게 상황에 맞춰 재탐색
실행 속도빠름(정해진 스크립트)상대적으로 느림(매 단계 판단)
적합한 대상반복되는 회귀 테스트탐색적 확인, 일회성 검증, 빠른 프로토타이핑

둘은 대체 관계가 아니라 보완 관계다. 매일 도는 회귀 스위트는 여전히 모듈 13의 방식(사람이 짠 스크립트)이 빠르고 안정적이다. Claude Code + Playwright MCP는 "아직 스크립트로 안 짜본 걸 지금 당장 확인해보고 싶을 때" 특히 강하다.

검증 없이 결과를 믿으면 안 되는 이유

레슨 1에서 배운 원칙이 여기서도 똑같이 적용된다 — AI가 "확인 했습니다"라고 보고해도, 그게 정말 맞는 확인이었는지는 사람이 봐야 한다. Claude Code가 실행한 브라우저 조작의 스크린샷이나 로그를 남기게 하고, 그걸 사람이 검토하는 습관이 필요하다. 이건 레슨 6에서 배운 "실행 기록을 남겨야 블랙박스가 안 된다"는 설계 요소와 같은 이유다.

실무에서 왜 필요한가

새로 생긴 화면을 아직 자동화 스크립트로 안 짰는데 빠르게 한 번 훑어보고 싶을 때, Claude Code + Playwright MCP는 스크립트를 짜는 시간 없이 바로 확인할 수 있게 해준다. 예를 들어 "결제 페이지에서 쿠폰 코드 필드에 만료된 쿠폰을 넣으면 어떻게 되는지 확인해줘" 같은 요청을 즉시 실행하고 결과를 받아볼 수 있다. 다만 이게 매일 도는 정식 회귀 스위트를 대체하는 건 아니다 — 반복 실행되는 핵심 시나리오는 여전히 모듈 13의 방식으로 코드화해 CI(모듈 14)에 태우는 것이 안정적이다. QA가 판단해야 할 것은 "이 확인이 일회성인가, 반복될 것인가"이고, 그 판단에 따라 두 방식을 적절히 나눠 쓰는 것이 실무 감각이다.

실습 과제

과제 1 — 지시문 설계하기 (10분)

"장바구니에 상품을 5개 이상 담으면 무료배송 안내 문구가 나타나는지 확인해줘" 같은 자연어 지시를 하나 더 만들어본다. 레슨 6에서 배운 "성공/실패 기준"을 지시문 안에 구체적으로 포함시켜본다.

과제 2 — 언제 스크립트화할지 판단하기 (10분)

과제 1에서 만든 확인 작업을, 앞으로 매 배포마다 반복해서 확인해야 한다고 하자. 이걸 Claude Code로 그때그때 시키는 것과, Playwright 스크립트로 코드화해 CI에 태우는 것 중 어느 쪽이 나을지, 그 이유를 2~3문장으로 적는다.

자가 체크리스트

  • Claude Code와 Playwright MCP가 연결되는 구조를 레슨 4의 MCP 개념으로 설명할 수 있다
  • 자연어 지시가 실제 브라우저 조작으로 이어지는 5단계 흐름을 설명할 수 있다
  • 이 방식과 기존 Playwright 코드 자동화의 차이를 표로 구분할 수 있다
  • 언제 이 방식을 쓰고 언제 코드로 스크립트화해야 하는지 판단할 수 있다
  • AI의 실행 결과를 검증 없이 신뢰하면 안 되는 이유를 설명할 수 있다

흔한 실수

  • 모든 테스트를 Claude Code + Playwright MCP로 대체하려 한다. 매일 반복되는 회귀 스위트는 여전히 코드화된 스크립트가 빠르고 안정적이다. 일회성 확인·탐색적 검증에 강점이 있는 도구다.
  • 지시문을 모호하게 던진다. "결제 페이지 확인해줘"보다 레슨 6에서 배운 것처럼 성공/실패 기준을 구체적으로 포함해야 판단이 정확해진다.
  • 실행 기록 없이 결과 보고만 믿는다. 스크린샷이나 로그가 남지 않으면, 나중에 그 판단이 맞았는지 검증할 방법이 없다.

참고 자료