블로그 목록으로Playwright MCP란? 강점 7가지와 상황별 선택 3가지
By 원영2026년 7월 27일9분이 글의 목차
Playwright MCP를 붙여 클로드 코드나 커서에 "테스트 좀 해줘"라고 시켜 보셨다면, 처음엔 놀라셨을 겁니다. 브라우저가 실제로 열리고, 버튼을 누르고, 결과를 말로 설명해 줍니다. 그런데 며칠 쓰다 보면 다른 느낌이 옵니다 — 시킬 때마다 확인하는 범위가 조금씩 다르고, 어제 통과한 것이 오늘도 통과했는지는 알 수 없습니다. 이 글은 Playwright가 무엇이고 무엇을 잘하는지 7가지로 정리하고, Playwright MCP는 무엇이 다른지, 그리고 상황별로 무엇을 쓰면 되는지를 3가지로 나눠 안내합니다.
- Playwright는 마이크로소프트가 만든 브라우저 자동화 도구로, 개발자가 코드로 브라우저를 조종하도록 설계됐습니다. 이 영역에서는 사실상 표준입니다.
- Playwright MCP를 붙이면 AI 도구가 그 브라우저를 직접 조종합니다. 코드를 쓰지 않고 말로 시킬 수 있다는 점이 큰 변화입니다.
- 다만 MCP는 그때그때 시키는 방식입니다. 무엇을 통과로 볼지, 그리고 그것을 배포마다 다시 확인할지는 도구가 아니라 사람이 정해야 합니다.
Playwright란 무엇인가
Playwright(플레이라이트)는 마이크로소프트가 2020년 1월 31일에 공개한 브라우저 자동화 도구입니다. 사람이 브라우저에서 하는 일 — 페이지 열기, 버튼 누르기, 글자 입력하기, 화면 확인하기 — 을 코드로 적어 두면 기계가 대신 실행합니다.
원래 이런 일에는 셀레니움(Selenium)이 오래 쓰였습니다. Playwright는 그 자리에서 여러 가지를 다시 설계했고, 지금은 새로 시작하는 팀이 기본으로 고르는 도구가 됐습니다.
기본 정보를 먼저 정리하면 이렇습니다.
| 항목 | 내용 |
|---|---|
| 만든 곳 | 마이크로소프트 |
| 공개 | 2020년 1월 31일 |
| 라이선스 | Apache 2.0 — 상업적 사용 포함 무료 |
| 지원 언어 | JavaScript·TypeScript(기본), Python, Java, .NET(C#) |
| 지원 브라우저 | 크로미움, 파이어폭스, 웹킷 |
| 비용 | 도구 자체는 무료. 실행에 드는 서버 비용만 별도 |
무료이고, 오픈소스이고, 마이크로소프트가 계속 개발합니다. 이 세 가지만으로도 선택하지 않을 이유를 찾기 어렵습니다.
Playwright가 잘하는 7가지
이 도구가 왜 표준이 됐는지는 구체적으로 볼 필요가 있습니다.
1. 기다림을 알아서 처리합니다. 브라우저 자동화에서 가장 흔한 문제는 "화면이 아직 안 떴는데 버튼을 누르려 해서 실패하는" 상황입니다. 예전 도구들은 "3초 기다려라" 같은 코드를 사람이 직접 넣어야 했고, 그 3초가 어떤 날은 모자라고 어떤 날은 낭비였습니다. Playwright는 요소가 실제로 누를 수 있는 상태가 될 때까지 자동으로 기다립니다. 이 하나로 실패가 크게 줄었습니다.
2. 브라우저 3종을 한 번에 다룹니다. 크로미움(크롬·엣지 계열), 파이어폭스, 웹킷(사파리 계열)을 같은 코드로 실행합니다. "크롬에서는 되는데 사파리에서 안 된다"를 미리 잡을 수 있습니다.
3. 실패했을 때 무엇이 있었는지 남깁니다. 트레이스 뷰어라는 기능이 실행 과정을 통째로 기록해, 나중에 화면을 되감아 보며 어느 단계에서 멈췄는지 확인할 수 있습니다. 로그만 남는 도구들과 확실히 다른 점입니다.
4. 코드를 대신 써 줍니다. 코드젠(codegen)이라는 기능을 켜고 브라우저에서 직접 클릭하면, 그 동작이 코드로 기록됩니다. 처음 시작할 때 진입 장벽을 크게 낮춰 줍니다.
5. 개발 흐름에 자연스럽게 들어갑니다. 깃허브 액션 같은 배포 자동화 도구와 붙여 두면, 코드를 올릴 때마다 자동으로 실행되게 만들 수 있습니다.
6. 여러 개를 동시에 돌립니다. 확인할 항목이 수십 개로 늘어나도 병렬로 나눠 실행해 전체 시간을 줄입니다. 항목이 늘수록 이 차이가 커집니다.
7. 화면 밖도 확인합니다. 브라우저 조작만이 아니라 서버와 주고받는 요청을 직접 확인하거나, 특정 응답을 일부러 흉내 내 오류 상황을 만들어 볼 수도 있습니다.
이 정도면 코드를 읽고 쓸 수 있는 사람에게는 더 나은 선택지를 찾기 어렵습니다. 이 글을 읽는 분이 코드를 다루실 수 있다면, 이 아래는 참고만 하시고 Playwright를 쓰시면 됩니다.
코드를 다룰 수 있다면 더 나은 선택지를 찾기 어렵다
Playwright MCP는 무엇이 다른가
여기서부터가 최근에 달라진 부분입니다.
MCP는 AI 도구가 외부 프로그램을 직접 다루게 해 주는 연결 방식입니다. 클로드 코드나 커서 같은 도구에 MCP로 무언가를 붙여 두면, AI가 그것을 도구처럼 사용합니다.
Playwright MCP는 마이크로소프트가 공식으로 내놓은 연결 장치입니다. 이것을 붙이면 AI가 브라우저를 직접 조종합니다. 사용자는 이렇게 말하면 됩니다.
"회원가입이 되는지 브라우저로 확인해줘."
그러면 AI가 브라우저를 열고, 가입 화면으로 가고, 값을 넣고, 결과를 읽어 설명해 줍니다. 코드를 한 줄도 쓰지 않았는데 실제 브라우저가 움직입니다.
이건 작은 변화가 아닙니다. 원래 Playwright를 쓰려면 코드를 쓸 줄 알아야 했는데, 그 조건이 사라진 것처럼 보입니다.
그래서 며칠 써 보면 생기는 질문
여기까지 오면 자연스럽게 다음 질문이 생깁니다. "그럼 이제 이걸로 다 되는 건가?"
정확히 말하면, 되는 일과 아직 손이 가는 일이 나뉩니다. 그리고 그 경계는 도구가 못 만들어서가 아니라 MCP라는 방식이 겨냥한 자리가 거기까지이기 때문입니다.
MCP는 이름 그대로 AI에게 도구를 쥐여 주는 연결 방식입니다. 사람이 말할 때마다 AI가 그 도구를 집어 씁니다. 좋은 설계이고, 대화하듯 쓰기에 알맞습니다. 다만 그 성격 때문에 따라오는 것들이 있습니다.
첫째, 매번 시켜야 합니다. 오늘 "가입 확인해줘"라고 했다면, 내일 배포한 뒤에도 다시 말해야 합니다. 말하지 않으면 확인은 일어나지 않습니다. 배포가 잦아질수록 이 말을 매번 기억하는 일이 부담이 됩니다.
둘째, 매번 같은 범위로 확인되지는 않습니다. 같은 문장으로 시켜도 AI가 그날 밟는 단계는 조금씩 다를 수 있습니다. 오늘은 이메일 형식 오류까지 확인하고, 내일은 가입 성공만 보고 끝날 수 있습니다. 대화형 도구의 자연스러운 성질이지만, "지난번과 같은 기준으로 봤는가"를 보장하기는 어렵습니다.
셋째, 통과 기준을 AI가 정하게 됩니다. 무엇을 통과로 볼지 사람이 미리 못 박아 두지 않으면, 판정도 AI 몫이 됩니다. 만든 쪽이 판정까지 맡을 때 무슨 일이 생기는지는 앞 글에서 연구 결과와 함께 다뤘습니다.
넷째, 지난 결과가 쌓이지 않습니다. 대화는 흘러갑니다. "3회차까지는 정상이었고 4회차부터 실패"를 나중에 확인하려면 그 기록이 어딘가 남아 있어야 하는데, 그때그때 시키는 방식에서는 남기 어렵습니다.
어느 쪽이 더 좋다가 아니라 풀려던 문제가 다르다
이건 Playwright의 문제가 아닙니다
짚고 넘어갈 것이 있습니다. 위의 것들은 Playwright가 못 만들어서 생긴 일이 아닙니다.
Playwright는 개발자가 코드로 통제하는 자동화 도구로 설계됐습니다. 무엇을 확인할지 코드에 적어 두고, 언제 실행할지도 개발 흐름 안에서 정합니다. 그 방식으로 쓰면 위의 네 가지가 전부 해결됩니다 — 코드에 적혀 있으니 범위가 고정되고, 배포 자동화에 걸어 두면 매번 돌고, 통과 기준도 코드에 있고, 결과도 쌓입니다.
즉 Playwright를 제대로 쓰는 방법은 원래부터 코드를 쓰는 것입니다. MCP는 그 문턱을 낮춘 편리한 통로이지, 코드로 하던 일을 전부 대신하려고 만든 것이 아닙니다.
상황별로 무엇을 쓰면 되는지
지금까지를 정리하면 이렇게 갈립니다.
- 코드를 읽고 쓸 수 있다 → Playwright를 코드로 쓰시면 됩니다. 이 글이 권하는 답입니다.
- 코드는 못 읽지만 가끔 확인만 하면 된다 → Playwright MCP로 충분합니다.
- 코드는 못 읽는데 배포마다 같은 기준으로 확인해야 한다 → 여기가 비어 있는 자리입니다.
비어 있는 자리에서 필요한 것
세 번째 경우에 필요한 것은 더 똑똑한 브라우저 조종이 아닙니다. 브라우저를 움직이는 일은 이미 잘 됩니다. 필요한 것은 그 위에 얹히는 2가지입니다.
1. 통과 기준을 사람이 승인해 두는 것. 무엇을 통과로 볼지 미리 정해 두면, 그 판정이 AI 손에 넘어가지 않습니다. 기준이 고정되어야 "지난번과 같은 기준"이 성립합니다.
2. 그것이 배포마다 저절로 다시 도는 것. 사람이 매번 말하지 않아도 실행되고, 회차마다 통과·실패가 쌓여야 나중에 "언제부터 문제였는지"를 볼 수 있습니다.
Specnote는 이 2가지를 맡습니다. 브라우저를 움직이는 부분은 같은 계열의 기술을 쓰므로 특별할 것이 없습니다. 다른 것은 판정과 반복을 누가 맡느냐입니다 — 통과 조건은 코드를 못 읽는 사람이 읽고 승인하고, 실행은 배포마다 자동으로 반복됩니다.
Specnote도 MCP로 붙습니다. 쓰던 AI 도구를 바꾸지 않으셔도 됩니다.
앞의 두 경우라면 Playwright 를 그대로 쓰면 된다
이 시리즈에서 앞으로 다룰 것
Playwright는 기능이 많고, 각각이 따로 설명할 값어치가 있습니다. 다음 편들에서 하나씩 다루겠습니다.
- 코드젠 — 클릭만 하면 코드가 만들어지는 기능. 어디까지 믿고 쓸 수 있는지
- 로케이터 — 화면의 요소를 어떻게 찾는지. 화면이 조금 바뀌면 왜 멈추는지
- 트레이스 뷰어 — 실패했을 때 무엇이 남는지. 되감아 보는 방법
- 픽스처 — 매번 같은 상태에서 시작하게 만드는 장치
- 배포 자동화 연동 — 코드를 올릴 때마다 자동으로 실행되게 하는 방법
지금 테스트해보기
확인 기준을 한 번 정해 두세요
무엇을 통과로 볼지 직접 승인해 두면, 배포할 때마다 같은 기준으로 다시 확인합니다. 쓰시던 AI 도구는 그대로 두셔도 됩니다.
자주 묻는 질문
Playwright MCP란 무엇입니까?
마이크로소프트가 공식으로 내놓은 연결 장치로, 클로드 코드·커서 같은 AI 도구가 Playwright 브라우저를 직접 조종하게 해 줍니다. 코드를 쓰지 않고 말로 시킬 수 있다는 점이 가장 큰 변화입니다.
Playwright와 Playwright MCP는 무엇이 다릅니까?
Playwright는 브라우저 자동화 도구 자체이고, MCP는 그것을 AI 도구에 연결하는 방식입니다. 코드로 쓰면 확인 범위와 실행 시점을 고정할 수 있고, MCP로 쓰면 그때그때 말로 시키는 대신 그 고정이 없습니다.
Playwright 사용법을 배우려면 어디서 시작합니까?
공식 문서가 가장 정확하고 잘 정리돼 있습니다. 이 시리즈는 사용법 자체보다 각 기능이 무엇을 풀려고 만들어졌는지를 다룹니다.
그럼 Playwright는 쓰지 말라는 뜻입니까?
아닙니다. 코드를 읽고 쓸 수 있다면 Playwright가 더 나은 선택입니다. 무료이고, 통제할 수 있는 범위가 넓고, 생태계도 큽니다. 이 글이 말하는 것은 코드를 다루지 못하는 사람이 배포마다 같은 기준으로 확인해야 할 때 무엇이 더 필요한가입니다.
Specnote는 Playwright와 무엇이 다릅니까?
브라우저를 움직이는 기술 자체는 같은 계열입니다. 다른 것은 통과 기준을 누가 정하고, 실행을 누가 반복하느냐입니다. Specnote에서는 코드를 못 읽는 사람이 통과 조건을 읽고 승인하며, 승인된 것은 배포마다 자동으로 다시 실행됩니다.
이미 Playwright로 테스트를 짜 둔 상태입니다.
그대로 쓰시면 됩니다. 이미 코드로 관리하고 계시다면 그 자산이 더 유연합니다. Specnote가 맞는 경우는 그 코드를 읽고 고칠 사람이 팀에 없거나, 기획자·대표가 직접 확인 기준을 정해야 할 때입니다.
