Playwright를 MCP에 연결하며 배운 것: 긍정적인 점, 불안정한 점, 그리고 놀라운 점

처음 작동했을 때, 저는 그저 멍하니 앉아 있었습니다.

저는 채팅창에 한 문장을 입력했습니다. "스테이징 사이트로 이동해서 테스트 계정으로 로그인하고, 장바구니에 아이템 두 개를 담아줘."와 같은 문장이었습니다. 브라우저가 스스로 열렸습니다. 커서가 움직였습니다. 필드들이 채워졌습니다. 제품 하나가 장바구니에 담겼습니다. 저는 단 하나의 로케이터 (locator), 클릭, 또는 스펙 파일 (spec file) 한 줄도 작성하지 않았습니다.

저의 첫 반응은 "이것이 미래다"가 아니었습니다. 그것은 "도대체 방금 무슨 일이 일어난 거지? 그리고 이 모든 것을 신뢰할 수 있을까?"였습니다.

그 질문이 바로 이 포스트 전체의 주제입니다. 저는 지난 몇 년 동안 일반적인 방식으로 Playwright 테스트 스위트 (suites)를 작성하며 시간을 보냈습니다. 셀렉터 (Selectors), 픽스처 (fixtures), 페이지 오브젝트 (page objects) 등 모든 것을 말이죠. Playwright를 MCP에 연결하는 것은 제가 잘 알고 있는 도구가 다른 언어를 말하기 시작하는 것을 지켜보는 것과 같았습니다. 어떤 부분은 진정으로 훌륭했습니다. 어떤 부분은 저를 미치게 만들었습니다. 그리고 몇 가지는 저를 완전히 당황하게 만들었습니다.

이것이 실제로 무엇인지, 쉽게 설명하자면
아직 접해보지 않으셨다면, 짧은 요약은 다음과 같습니다.

MCP, 즉 모델 컨텍스트 프로토콜 (Model Context Protocol)은 AI 모델이 하나의 공유된 인터페이스를 통해 외부 도구를 호출할 수 있는 방법입니다. Playwright MCP 서버는 그러한 도구 중 하나입니다. 사용자가 브라우저 자동화를 작성하는 대신, 이 서버는 모델에게 일련의 브라우저 동작을 전달합니다. 탐색 (Navigate), 클릭 (click), 타이핑 (type), 페이지 읽기 (read the page), 스냅샷 찍기 (take a snapshot). 모델이 무엇을 할지 결정하면 Playwright가 이를 수행합니다.

가장 먼저 저를 놀라게 했던 점은 모델이 페이지를 어떻게 인식하느냐는 것이었습니다. 저는 비전 모델 (vision model)이 픽셀을 뚫어지게 쳐다보는 스크린샷 방식이라고 가정했습니다. 하지만 기본적으로는 그렇지 않습니다. 그것은 스크린 리더 (screen readers)가 의존하는 구조화되고 라벨이 붙은 페이지 버전인 접근성 트리 (accessibility tree)를 기반으로 작동합니다. 그 하나의 결정이 이후에 이어지는 긍정적인 면과 부정적인 면 모두에 대해 많은 것을 설명해 줍니다.

이제 당신은 더 이상 테스트를 실제로 기록하는 것이 아닙니다. 당신은 원하는 바를 설명하고, 다른 무언가가 그것을 동작으로 변환하도록 맡기는 것입니다. 모든 셀렉터 (selector)를 신중하게 결정하며 수년간 작업해 온 사람에게 이것은 묘한 기분이 드는 경험입니다.

긍정적인 점 (The good)

저를 진심으로 감명 깊게 했던 부분부터 시작하겠습니다. 왜냐하면 그런 점이 아주 많았기 때문입니다.

앱을 탐색하는 것이 빨라졌습니다. 보통 익숙하지 않은 것에 접속하면 직접 이것저것 눌러보고, 흐름을 파악한 뒤에 스크립트를 작성하기 시작합니다. 하지만 MCP (Model Context Protocol)가 루프에 포함되어 있으면, 제가 지켜보는 동안 특정 기능을 훑어보라고 요청하기만 하면 됩니다. MCP는 제가 결국에는 도달했을 단계들과 엣지 케이스 (edge cases)들을 찾아냈고, 단지 그 과정이 더 빨랐을 뿐입니다. 실제 테스트를 단 하나도 작성하기 전에 새로운 시스템을 이해하는 방법으로서, 이 방식은 즉각적인 가치를 증명했습니다.

접근성 트리 (accessibility tree) 방식은 기대했던 것보다 더 잘 버텨주었습니다. 픽셀 (pixels) 대신 구조화된 페이지 데이터를 읽기 때문에, 레이아웃이 몇 포인트 이동하거나 색상이 바뀌어도 오류가 발생하지 않습니다. 페이지가 스스로를 설명하는 방식 그대로 페이지를 읽는 것입니다. 요소를 찾을 때도 역할 (role)과 레이블 (label)을 통해 대개 올바른 요소를 찾아냈는데, 솔직히 말해서 이것이 바로 우리 모두가 로케이터 (locators)를 작성해야 한다고 교육받는 방식이기도 합니다.

코딩을 하지 않는 사람들에게 문을 열어주었습니다. 자동화 코드를 작성하는 데 익숙하지 않은 저희 팀의 수동 테스터 (manual tester)에게 이것을 보여주었습니다. 한 시간도 채 되지 않아 그들은 평이한 영어로 실제 흐름을 제어하고 있었습니다. 이것은 결코 작은 일이 아닙니다. 정말 많은 테스트 지식이 프레임워크로 변환하지 못하는 사람들에게 머물러 있는데, 이 기술이 그 격차의 일부를 메워줍니다.

지루한 스캐폴딩 (scaffolding) 초안 작성이 빨라졌습니다. 제대로 된 Playwright 코드를 작성하러 돌아갔을 때조차, 모델이 먼저 흐름을 매핑하게 하면 제가 수동으로 다듬을 수 있는 괜찮은 구조를 얻을 수 있었습니다. 빈 파일을 멍하니 바라보는 시간이 줄어들었습니다.

며칠 동안 저는 완전히 매료되었습니다. 그러다 이것을 실제 업무에 적용하자 균열이 보이기 시작했습니다.

불안정한 점 (The flaky)

이제 솔직해져야 할 부분입니다. 제목에서 '불안정한 점'을 약속했고, 제목은 허풍을 떨지 않았기 때문입니다.

그것은 결정론적 (Deterministic)이지 않으며, 테스트는 본래 결정론적이어야 합니다. 동일한 지시를 두 번 실행하더라도 항상 같은 경로를 거치는 것은 아닙니다. 한 번은 메인 양식을 통해 로그인했습니다. 또 다른 때는 제가 존재조차 잊고 있었던 "이메일로 계속하기" 경로를 발견하고 대신 그 길로 갔습니다. 둘 다 목표에는 도달했습니다. 하지만 실행할 때마다 다른 길을 택하는 테스트는 완전히 신뢰할 수 없는 테스트입니다. 무엇을 정확히 확인했는지 더 이상 알 수 없기 때문입니다. 자동화에서 "어떻게든 도달했다"는 것은 "내가 의도한 동작을 수행했다"와 같지 않습니다.

그것은 모호함을 자신 있게 해결하지만, 때로는 틀리기도 합니다. 제 지시가 모호할 때, 그것은 멈춰서 질문하지 않았습니다. 스스로 해석을 내리고 완전히 확신에 찬 채 실행했습니다. 한 번은 "양식 제출 (Submit the form)"이라는 지시가 실제 제출이 아닌 "임시 저장 (Save Draft)" 버튼을 의미했는데, 잘못된 것을 테스트하면서도 실행 결과는 완벽하게 정상처럼 보였습니다. 잘못된 경로를 조용히 확인하고 내놓는 초록색(성공) 결과는 세상에서 가장 위험한 초록색입니다.

진정으로 특이한 부분에서는 동작이 멈춥니다. 커스텀 날짜 선택기 (Date picker), 드래그 앤 드롭 (Drag and drop), 캔버스 (Canvas) 요소 등 깔끔하고 명확하게 라벨이 붙은 컨트롤이 아닌 모든 것들이 해당됩니다. 이러한 요소들은 제가 해당 위젯을 위해 수동으로 조정해 둔 로케이터 (Locator)보다 훨씬 더 자주 문제를 일으켰습니다. 접근성 트리 (Accessibility tree)의 강점은 인터페이스가 스스로를 제대로 설명하지 못하는 순간 약점으로 변합니다. 그리고 수많은 실제 앱들이 스스로를 제대로 설명하지 못합니다.

비용과 속도 문제도 쌓입니다. 모든 단계는 모델이 다음에 무엇을 할지 결정하는 것을 의미합니다. 간단한 탐색 작업에는 괜찮습니다. 하지만 전체 회귀 테스트 (Regression run)의 경우, 지연 시간 (Latency)과 토큰 비용이 실질적인 문제가 되며, 일반적인 Playwright 스위트가 두 측면 모두에서 여전히 압도적으로 우세합니다.

이 모든 것이 이 방식이 망가졌다는 뜻은 아닙니다. 그것은 이 방식이 결정론적인 테스트 러너 (Test runner)가 아니라, 즉흥적으로 대처하는 영리한 조수처럼 행동한다는 것을 의미합니다. 도구가 다르면 용도도 다릅니다.

놀라운 점 (The surprising)

전혀 예상하지 못했던 몇 가지 사항들입니다.

병목 현상은 제가 사물을 얼마나 잘 설명하느냐로 옮겨갔습니다. 저는 설정(setup) 과정이 가장 어려울 것이라고 생각했습니다. 하지만 그렇지 않았습니다. 진짜 어려운 부분은 동일한 동작을 두 번 반복해서 얻어낼 수 있을 만큼 정밀한 지침(instructions)을 작성하는 것이었습니다. 제 표현이 더 명확하고 엄격할수록 결과는 더 좋아졌습니다. 이는 차분히 생각해보니, 이미 좋은 테스트 설계(test design)에서 요구하는 규율(discipline)의 더 모호한 버전일 뿐이었습니다. 기술이 사라진 것이 아니라, 그 형태가 변한 것이었습니다.

작동하는 모습을 지켜보는 것 자체가 하나의 디버깅(debugging) 도구가 되었습니다. 모델이 "로그인 링크가 보이지 않아서 먼저 메뉴를 열었습니다"와 같이 자신의 선택 과정을 설명하는 것을 보면서, 제가 오랫동안 인지하지 못했던 제 앱에 대한 가설들을 드러낼 수 있었습니다. 몇 번은 테스트의 문제가 아니라 UX의 실제 투박함을 드러내기도 했습니다. 테스트 도구를 평가하러 들어갔다가 제품 팀에 전달할 피드백을 들고 나오게 된 셈입니다.

이 경험은 제가 가진 지루하고 오래된 테스트 스위트(suite)를 덜 소중하게 만드는 것이 아니라, 오히려 더 가치 있게 만들었습니다. 저는 제가 대체될 수 있다는 느낌을 받으며 물러나게 될 줄 알았습니다. 하지만 오히려 수동으로 작성된 결정론적 테스트(deterministic tests)가 실제로 무엇을 위한 것인지 더 명확하게 깨닫게 되었습니다. 제가 당연하게 여겼던 예측 가능성(predictability)이, 중요한 지점에서는 바로 그 핵심이라는 사실이 밝혀졌습니다.

그렇다면 실제로 어디에 사용할 것인가

저는 계속해서 단순한 이분법적인 결론에 도달하고 있습니다.

탐색, 프로토타이핑(prototyping), 새로운 앱 파악, 그리고 코드를 작성하지 않는 팀원들이 기여할 수 있도록 돕는 용도로는, MCP를 통한 Playwright는 도구 상자에 진정한 추가 요소가 됩니다. 저는 그 용도로 계속 사용할 것입니다. 빠르고, 접근하기 쉬우며, 수년간 완고하게 높았던 장벽을 낮춰줍니다.

하지만 릴리스(release)를 통제하는 회귀 테스트 스위트(regression suite), 특히 릴리스를 중단시킬 수 있는 누군가에게 제가 방어해야 하는 작업에 대해서는, 여전히 제가 직접 작성하고 설명할 수 있는 결정론적 테스트를 원합니다. 이는 테스트 분야의 AI 전반에 대해 제가 계속해서 도달하는 결론과 같습니다. 틀렸을 때의 비용이 적은 곳에서는 AI에 의존하고, 비용이 큰 곳에서는 확고한 통제권을 유지하십시오.

이는 도구에 대한 비판이 아닙니다. 단지 자신이 어떤 일을 하고 있는지 아는 것뿐입니다.

현재 제가 내린 결론

Playwright를 MCP에 연결하는 작업은 최근 제가 했던 일 중 꽤 흥미로운 작업 중 하나였습니다. 주로 이 작업이 "훌륭하다" 혹은 "쓸모없다"라는 식으로 깔끔하게 결론지어지지 않았기 때문입니다. 무엇을 요구하느냐에 따라 두 가지 면을 모두 가지고 있습니다.

좋은 점은 진심으로 좋습니다. 불안정한 점은 진심으로 불안정합니다. 그리고 가장 놀라웠던 부분은, 이 도구가 테스트에 대한 판단력의 필요성을 줄여주지 않는다는 사실을 깨달은 것이었습니다. 단지 그 판단의 영역이 단계를 작성하는 것에서 어떤 단계를 신뢰할지 결정하는 것으로 옮겨갔을 뿐입니다.

저는 이것이 제 업무 주간 일정 중 정확히 어느 위치에 들어맞을지 여전히 파악 중입니다. 이것은 초기 단계의 노트일 뿐, 최종 판결은 아닙니다.

만약 여러분이 Playwright를 MCP에 연결했거나, 어떤 모델이든 실제 브라우저에 연결해 보았다면, 어떤 부분에서 잘 작동했고 어떤 부분에서 무너졌는지 꼭 듣고 싶습니다. 우리 모두가 여전히 이 기술의 경계를 탐색하고 있는 단계라는 느낌이 듭니다.