코드 한 줄 없이 "장바구니에 담아줘"라고 말하면 끝나는 시대, LLM과 Playwright 결합 자동화 들여다보기

Locator를 찾고 XPath를 다듬던 작업을, 이제는 자연어 명령으로 대신할 수 있습니다.

 

Playwright MCP와 Browser Use를 중심으로 최신 자동화 흐름을 정리했습니다.

 

https://testmanager.tistory.com/653

회원가입 화면 하나만 열어도 보이는 것들, QA가 DevTools(개발자도구)로 증거 기반 리포트를 쓰는

https://testmanager.tistory.com/654

Python 한 줄도 몰라도 시작하는 웹 테스트 자동화, Playwright로 로그인부터 자동화해보기

https://testmanager.tistory.com/655

테스트 케이스만 따라가다 보면 놓치는 결함들, 탐색적 테스트가 필요한 이유

 

---

Locator를 찾는 데 들어가는 시간, 그 자체가 비용이었습니다

 

지금까지 다뤄온 Playwright 자동화는 결국 "이 버튼이 어디에 있는지"를 코드로 짚어내는 작업의 연속이었습니다.

 

id가 있으면 간단하지만, id가 없거나 화면 구조가 자주 바뀌는 서비스라면 Locator 하나를 안정적으로 잡는 데도 꽤 많은 시간이 들어갑니다.

 

게다가 화면이 리뉴얼되면 그동안 작성한 Locator들이 한꺼번에 깨지는 경우도 흔합니다.

 

최근 주목받고 있는 흐름은, 이 "위치를 찾는 작업" 자체를 LLM에게 맡기는 방식입니다.

 

사람이 "장바구니에 담아줘"라고 말하면, LLM이 현재 화면 구조를 보고 적절한 요소를 스스로 찾아 클릭까지 수행하는 구조입니다.

 

이번 글에서는 이 흐름의 대표적인 두 가지 접근, Playwright MCP와 Browser Use를 중심으로 살펴보겠습니다.

 

Playwright MCP, Claude 같은 LLM에게 브라우저 조작 권한을 넘기는 방식

 

MCP(Model Context Protocol)는 LLM이 외부 도구나 서비스를 호출할 수 있게 해주는 표준화된 연결 방식입니다.

 

Playwright MCP는 이 구조를 활용해, LLM이 직접 브라우저를 열고 클릭·입력·스크린샷 같은 동작을 수행할 수 있도록 만든 서버입니다.

 

기존 Playwright 코드와의 가장 큰 차이는, 우리가 작성하는 것이 "코드"가 아니라 "지시문"이 된다는 점입니다.

 

예를 들어 기존 방식에서는 아래처럼 작성했습니다.

page.goto("https://www.saucedemo.com")
page.fill("#user-name", "standard_user")
page.fill("#password", "secret_sauce")
page.click("#login-button")
page.click("#add-to-cart-sauce-labs-backpack")

 

Playwright MCP를 연결한 LLM 환경에서는, 이 모든 과정을 다음과 같은 자연어로 대체할 수 있습니다.

"saucedemo.com에 접속해서 standard_user / secret_sauce로 로그인하고, Sauce Labs Backpack을 장바구니에 담아줘"

 

LLM은 이 문장을 받아서, 현재 페이지의 DOM 구조를 직접 들여다보고 "user-name이라는 id를 가진 input이 있으니 여기에 입력하면 되겠다"는 식으로 스스로 판단해 동작을 수행합니다.

 

즉 Locator를 사람이 미리 정의해두지 않아도, LLM이 그때그때 화면을 보고 적절한 요소를 찾아낸다는 점이 핵심입니다.

 

이 방식이 QA 업무에서 의미 있는 이유

 

탐색적 테스트 글에서 다뤘던 내용과 연결되는 지점이 있습니다.

 

탐색적 테스트는 "사람이 화면을 보고 즉흥적으로 다양한 시도를 해보는" 활동이었는데, LLM 기반 자동화는 이 즉흥성을 어느 정도 코드 없이도 흉내 낼 수 있게 해줍니다.

 

예를 들어 새로운 기능이 배포된 직후, 정식 자동화 스크립트를 작성하기 전이라도 "이 화면에서 입력창에 빈 값을 넣고 제출 버튼을 눌러봐", "로그아웃 후 다시 같은 페이지로 접근해봐" 같은 지시를 자연어로 내려 빠르게 결과를 확인해볼 수 있습니다.

 

정식 자동화로 굳히기 전 단계의 "가벼운 탐색"을 LLM에게 맡기는 흐름입니다.

 

다만 여기서 중요한 건, 이게 "기존 자동화를 대체한다"는 의미는 아니라는 점입니다.

 

매번 LLM이 화면을 해석하고 판단하는 과정은 고정된 Locator를 사용하는 기존 방식보다 느리고, 실행 결과가 항상 동일하게 보장되지 않을 수 있습니다.

 

안정적으로 반복 실행해야 하는 회귀 테스트는 여전히 기존 Playwright 코드 기반이 적합하고, LLM 기반 방식은 "아직 코드화되지 않은 영역을 빠르게 탐색하거나, 비개발자가 자동화에 접근하는 진입점"으로 이해하는 게 현재로서는 더 현실적입니다.

 

Browser Use, 오픈소스로 직접 체험해볼 수 있는 또 다른 접근

 

Playwright MCP와 비슷한 맥락에서 자주 언급되는 또 다른 프로젝트가 Browser Use입니다.

 

Browser Use는 Python 라이브러리 형태로, LLM(예: GPT, Claude 등의 API)과 Playwright를 연결해 "자연어 지시 → 브라우저 동작"을 수행하는 에이전트를 직접 구성할 수 있게 해줍니다.

 

개념적인 흐름은 다음과 같습니다.

from browser_use import Agent
from langchain_openai import ChatOpenAI

agent = Agent(
    task="saucedemo.com에서 standard_user/secret_sauce로 로그인하고 백팩을 장바구니에 담아줘",
    llm=ChatOpenAI(model="gpt-4o"),
)

await agent.run()

 

task에 자연어로 목표를 적어두면, 에이전트가 내부적으로 현재 화면의 DOM을 분석하고, "이 작업을 수행하려면 어떤 요소를 클릭해야 하는가"를 LLM에게 물어가며 단계별로 실행합니다.

 

실행 과정에서 스크린샷을 함께 LLM에게 전달해, 텍스트 정보만으로 판단하기 어려운 화면(예: 이미지 기반 버튼)도 처리할 수 있다는 점이 특징입니다.

 

이 방식의 장점은 오픈소스이기 때문에 직접 코드를 들여다보고 원하는 대로 확장할 수 있다는 점이고, 단점은 LLM API 호출이 매 단계마다 발생하기 때문에 비용과 속도 측면에서 대규모 회귀 테스트에 그대로 적용하기에는 아직 부담이 있다는 점입니다.

 

그래서 지금 시점에 QA가 가져가야 할 시각

 

LLM과 Playwright를 결합한 자동화는 "자동화 코드를 짤 필요가 없어진다"보다는, "자동화의 진입 장벽이 낮아진다"는 쪽으로 이해하는 것이 더 정확합니다.

 

비개발자도 자연어로 간단한 흐름을 테스트해볼 수 있고, 개발자/QA 입장에서도 새로운 화면을 빠르게 탐색하거나 Locator 초안을 잡는 데 보조 도구로 활용할 수 있습니다.

 

다만 매 스프린트마다 반복 실행되는 핵심 회귀 테스트는 여전히 POM 패턴으로 구조화된, 결과가 항상 동일하게 보장되는 기존 Playwright 코드가 담당하는 게 합리적입니다.

 

즉 "안정적으로 반복해야 하는 영역은 코드로, 아직 코드화되지 않은 영역은 LLM 에이전트로"라는 역할 분담이, 현재로서는 가장 현실적인 활용 방식이라고 볼 수 있습니다.

 

이런 흐름을 미리 알아두면, 앞으로 팀에 자동화 도구를 도입하거나 새로운 도구를 평가할 때 "이게 어떤 문제를 해결해주는 도구인지"를 더 명확하게 판단할 수 있을 거라 생각합니다.