agent-browser와 Playwright를 이용한 탐색과 검증의 분리

최근 UI 평가 플로우에 agent-browser를 도입하는 경우가 있습니다.

일반적인 E2E 테스트는 조작 경로가 결정되어 있는 상황에서 유효합니다.

await page.getByRole("button", { name: "Settings" }).click();
await expect(
page.getByRole("dialog", { name: "Settings" })
...

반면, 조작 절차를 지정하지 않고 '설정 화면을 찾아서 열기'라는 목적을 주었을 때, 그곳까지 도달할 수 있는지 확인하고 싶을 때도 있습니다.

저희는 이 탐색에 agent-browser를 사용합니다. 목적 달성 여부는 에이전트의 자체 신고만으로 결정하지 않고, Playwright 등을 이용한 검증을 결합합니다.

아직 정비 중인 부분도 있지만, 시도하는 과정에서 탐색과 판정의 책임을 분리하는 것의 유용성을 발견했습니다. 이 글에서는 현재 구성과 실제 버그를 통해 재검토한 점들을 소개합니다.

agent-browser와 Computer Use의 위치 설정

먼저, 이 글에서 다룰 두 가지 실행 경로를 정리하겠습니다.

저희 구성에서는 agent-browser를 개발 측 평가 하네스에 통합하고 있습니다. Codex나 Claude가 agent-browser를 통해 웹 앱을 조작하고, 그 결과를 에이전트 외부에서 검증합니다.

agent-browser의 스냅샷(snapshot)에서는 요소의 참조 정보를 포함하는 접근성 트리(accessibility tree)를 가져올 수 있습니다. 에이전트는 UI 확인과 조작을 반복하며 목적을 향해 나아갑니다.

반면, 이 글에서 말하는 Computer Use는 Codex가 데스크톱 애플리케이션을 조작하는 기능을 의미합니다. 사용 가능한 환경에서는 네이티브 앱 평가에 이것을 사용합니다.

agent-browser 세션을 Computer Use로 인계하는 구성은 아닙니다. 또한, Computer Use 자체를 Office 문서 편집 API로 취급하고 있는 것도 아닙니다. 엑셀 전용 애드인 같은 편집 수단과 그 환경에 도달하기 위한 화면 조작은 역할을 분리하여 생각하고 있습니다.

공통적인 방침은, 조작하는 메커니즘과 결과를 판정하는 메커니즘을 분리하는 것입니다. 이후는 주로 agent-browser 측면을 다루겠습니다.

절차 대신 목적 부여하기

에이전트에게는 클릭 절차 대신 목적을 전달합니다.

설정 화면을 열어주세요.

좀 더 복잡한 태스크의 경우, 다음과 같은 지시가 됩니다.

대상 고객을 찾고, 최신 문의와 관련된 정보를 열어주세요.

에이전트는 현재 UI를 관찰하고 다음 조작을 판단합니다. 특정 셀렉터 목록을 재현하는 테스트와 별개로, 목적에 이르는 경로를 탐색하게 하는 평가입니다.

다만, 이 결과로부터 직접 알 수 있는 것은 지정한 관찰/조작 조건으로 그 에이전트가 목적에 도달했는지 여부뿐입니다.

접근성 트리를 읽는 에이전트와 화면을 보고 조작하는 인간은 이용 가능한 정보나 탐색 방법이 다릅니다. 사용성 테스트의 대안이라고 보지는 못하지만, 동선의 명확성을 생각할 재료가 될 수는 있습니다.

동선을 평가하려면 시작 화면과 허용할 조작도 정의해야 합니다. 설정 화면 URL로 직접 이동할 수 있다면, 최종 상태는 올바르더라도 화면상의 동선을 찾았다고 할 수는 없기 때문입니다.

목적 도달 조건과, 도중에 지켜야 할 조작 조건은 분리하여 정의합니다.

자체 신고만으로 성공 여부를 결정하지 않기

에이전트가 다음 결과를 반환하더라도 그것만으로는 성공이라고 간주하지 않습니다.

{
"status": "completed"
}

조작 후, Playwright로 사전에 정의한 기대 조건을 검증합니다.

// page는 에이전트가 조작한 대상 탭을 가리킵니다
await expect(
page.getByRole("dialog", { name: "Settings" })
...

이 검증이 성립하려면, page가 에이전트가 조작한 동일한 탭을 가리키고 있어야 합니다.

다른 브라우저를 실행하여 인증 정보만 인계받더라도, 열린 다이얼로그와 같은 일시적인 UI 상태는 인계할 수 없습니다. 조작 후의 상태를 검증하려면, 그 상태를 유지하고 있는 대상 탭에 연결해야 합니다.

Chromium에서는 Playwright에서 기존 브라우저로 CDP(Chrome DevTools Protocol) 연결을 하는 방법이 있습니다. 다만, 일반적인 Playwright 연결과 동등한 기능이 보장되는 것은 아닙니다. 연결 방법은 이용 버전이나 후술할 제한 설정과의 조합으로 확인해야 합니다.

여기서 말하는 '독립적 검증'은 다른 브라우저에서 검증한다는 의미가 아닙니다. 판정 로직(judgment logic)과 기대 조건(expected condition)을 조작하는 에이전트로부터 독립시키는 의미입니다.

완료 보고와 어설션(Assertion)을 분리하여 처리하기

저희의 평가에서는, 에이전트의 완료 보고와 어설션 성공이 갖춰졌을 때 태스크 성공으로 간주합니다.

진단 과정에서는 이 두 가지를 구별해서 다루는 것이 중요합니다.

'최신 문의와 관련된 정보를 열기'라는 태스크라면, 대상 고객, 문의, 표시해야 할 정보를 검증 측에서 특정할 수 있어야 합니다. 기대 조건이 모호한 상태에서는 판정을 외부에 옮겨도 평가가 안정적이지 않습니다.

독립적 검증이 탐색의 자유를 지지하다

당초에는 Playwright를 에이전트 조작에 대한 안전망으로 생각했습니다. 지금은, 판정 기준을 외부에 두어 조작 경로를 유연하게 할 수 있다는 점에서도 가치를 느끼고 있습니다.

에이전트는 목적지에 이르는 경로를 찾고, Playwright는 사전에 정의된 조건을 확인합니다. 경로에 제약이 있는 경우에는 그 조건도 별도로 확인합니다.

이러한 분담을 통해 모든 클릭 절차를 고정하지 않고 평가 기준을 유지할 수 있습니다. 적어도 저희의 용도에서는 agent-browser와 Playwright가 경쟁하기보다는, 서로 다른 책임을 맡는 조합으로 기능하고 있습니다.

기존 에이전트 평가와의 관계

탐색과 검증을 분리하는 생각은 기존의 노력에서도 찾아볼 수 있습니다.

Anthropic은 에이전트 평가를 태스크(task), 결과(result), 채점기(scorer)라는 관점에서 정리하고, 행동 경로를 과도하게 제약하지 않으면서 가능한 부분에서는 코드를 이용한 채점을 사용하도록 권장합니다.

WebArena 역시 자연어로 웹상의 태스크를 주고 기능적으로 달성했는지를 평가하는 구성입니다.

Playwright의 Test Agents에서는 플래너(planner)가 애플리케이션을 탐색하고, 제너레이터(generator)가 계획을 실행 가능한 테스트로 변환하며, 힐러(healer)가 실패한 테스트를 복구합니다.

qa-skills에서는 자연어 목표를 브라우저 에이전트에게 주고, 외부 판정기에서 성패를 결정하고, 안정적인 플로우를 Playwright 테스트로 옮기는 워크플로우가 설명되어 있습니다. SightCI에도 AI에 의한 탐색 결과의 일부를 Playwright spec으로 옮기는 생각이 있습니다.

저희가 검토한 것은 이러한 패턴들을 UI, API, 인증, 네이티브 문서 조작이 혼재하는 애플리케이션에 어떻게 적용할 것인가였습니다.

실제 결함으로부터 리그레션 테스트의 위치를 재검토하다

처음에 생각했던 흐름은 다음과 같았습니다.

• agent-browser를 사용한 탐색으로 결함을 발견한다
• 원인을 조사한다
• Playwright의 리그레션 테스트(regression test)를 추가한다

하지만, 인증된 실환경에서 클라우드 측에 대한 지시가 거부되는 문제에 직면했습니다.

같은 인증 컨텍스트로 API 동작을 비교하자, 원인은 조직을 특정하는 처리의 불일치였습니다. 문제는 제품 조작 중에 표면화되었지만, 고장 난 것은 UI의 동작이 아니었습니다.

이 케이스에서는 브라우저 리그레션 테스트를 늘리는 것보다, 문제 경계에 가까운 곳에서 검증하는 것이 적절하다고 판단했습니다. 구현을 수정하여 AI 모델을 사용하지 않는 Hosted E2E(End-to-End) 검증을 추가하고 있습니다. 대상은 배포된 환경에서의 인증과 조직 해결을 포함한 API 연동입니다.

이 경험으로부터, 리그레션 테스트를 배치하는 기준을 재검토했습니다.

원인이 밝혀진 결함은, 고장 난 계약(broken contract)을 재현할 수 있는 범위에서 가장 비용 효율적인 어설션 기반의 테스트로 옮깁니다.

계약이란, 그 경계에서 지켜져야 할 동작이나 조건을 말합니다. 이번 경우라면, 인증 정보에 대응하는 조직이 올바르게 선택되는 것이 해당됩니다.

다만, 비용을 낮추기 위해 재현에 필요한 조건을 떨어뜨려서는 안 됩니다. 시스템 간의 연동에서만 발생하는 결함이라면, 그 연동까지 포함하여 검증해야 합니다. 작은 단위 테스트(unit test)로 분해하는 것이 항상 적절한 것은 아닙니다.

원인에 맞는 계층에서 검증하기

현재는 대략 다음과 같이 회귀 테스트의 위치를 선택하고 있습니다.

중요하게 생각하는 것은 발견에 사용한 도구가 아니라, 결함을 재현할 수 있는 조건입니다. 그 조건을 유지한 상태에서, 가능한 한 직접적이고 저비용의 검증 대상을 선택합니다.

알려진 결함은 AI 없이도 감지 가능하도록 하기

탐색을 통해 결함을 발견하고 원인을 특정하여 적절한 회귀 테스트를 추가했다면, 다음부터는 일반적인 CI(Continuous Integration)로 탐지할 수 있는 상태를 목표로 합니다.

같은 문제를 탐지하기 위해 매번 에이전트를 구동할 필요는 없습니다.

AI는 아직 무엇이 일어날지 모르는 부분의 탐색에 사용합니다. 원인이 파악되어 지식으로 남은 부분은 어설션 기반 테스트(assertion-based test)로 남깁니다.

회귀 테스트가 AI에 의존하는 것을 늘리기보다는, 탐색을 통해 얻은 지식을 더 저비용이고 안정적인 검증으로 변화시키는 방침입니다.

제한을 프롬프트에만 맡기지 않기

브라우저를 조작하는 에이전트에게는 실행할 수 있는 작업의 제한도 필요합니다.

파일을 업로드하지 마십시오.
파일을 다운로드하지 마십시오.
테스트 환경 밖으로 이동하지 마십시오.
...

마지막 항목은 에이전트에 의한 임의 코드 실행을 금지하는 것입니다. 웹 앱 자체의 JavaScript를 비활성화한다는 의미는 아닙니다.

이러한 지시 외에도, 가능한 부분에서는 실행 환경 측에서도 제한합니다. agent-browser에는 도메인 제한(domain restriction), 콘텐츠 경계를 나타내는 메커니즘, 액션 정책(action policy), 작업 확인(operation confirmation), 출력량 제한 등이 있습니다.

필요한 제한이 자동으로 모두 활성화된다고 생각하지 않으며, 평가 하네스(evaluation harness)의 설정으로 명시합니다.

또한, 제한 설정과 브라우저 연결 방식은 조합하여 확인할 필요가 있습니다. --allowed-domains와 agent-browser에서 기존 브라우저로 연결하는 --cdp 등에는 병용상의 제약이 있습니다. 이용 버전, 연결 방향, 제한의 적용 범위를 확인하지 않고 구성을 결정할 수는 없습니다.

원문 작성 시점에서는 문서상의 액션 분류와 개별 작업에 대한 정책 적용 불일치를 지적하는 Issue도 있었습니다. 설정 이름만으로 판단할 것이 아니라, 실제로 무엇이 허가되고 거부되는지 확인할 필요가 있습니다.

저희는 도구의 정책 외에도 임시 실행 환경(temporary execution environment), 비밀 정보 최소화(minimization of secret information), 실행 시간 상한(upper limit on execution time), 일회용 브라우저 상태(disposable browser state)를 결합하고 있습니다. 하나의 설정만으로 모든 것을 보호할 수 있다고 생각하지 않습니다.

다음 공정에는 확인 가능한 증거를 전달하기

탐색에 실패한 후, 그 결과를 어떻게 진단으로 연결할지도 검토하고 있습니다.

브라우저를 띄워둔 채 같은 세션을 여러 에이전트에게 넘기는 방법도 있습니다. 다만, 변경되 계속되는 세션을 공정 간의 주요 전달 수단으로 삼는 것에는 신중합니다.

작업 직후의 UI 검증에는 같은 탭이 필요하지만, 그 이후의 진단까지 살아있는 세션에 의존할 필요는 없다고 생각합니다.

현재 평가 하네스에서는 다음 정보를 구조화하여 기록하고 있습니다.

• 최종 URL과 실패한 단계
• 접근성 스냅샷(accessibility snapshot)
• 스크린샷
• 콘솔 에러
• 트레이스(trace)

트레이스나 로그는 실패 후에 과거로 거슬러 올라가서 얻을 수 있는 것이 아닙니다. 필요한 기록은 실행 중에 시작하여, 실패 시에 저장하는 설계로 합니다.

이것들을 개발자나 Codex가 확인하고, 원인 진단과 회귀 테스트 후보 작성으로 연결합니다. 스토리지 상태나 네트워크 로그를 포함하여, 무엇이 일어났는지를 저장·비교·리뷰할 수 있는 형태로 만드는 것을 중요하게 생각합니다.

현재 구현과 앞으로의 과제

현 시점에서는 다음 부분까지 구현했습니다.

agent-browser를 이용한 탐색용 평가 경로

• Codex와 Claude를 각각 독립적으로 사용한 평가
• 브라우저에서 사용할 수 있는 기능의 제한
• 에이전트 외부에서 실행하는 Playwright 어설션
• 구조화된 평가 기록

한편, 회귀 테스트로 전환되는 과정을 연결하는 시스템은 아직 정비 중입니다.

• 스크린샷 및 트레이스를 포함한 진단 정보 일체 저장
• 회귀 테스트 후보 자동 생성
• 발견 시의 증거와 회귀 테스트 연계
• 검토를 거쳐 회귀 테스트로 옮긴 이력 관리

현재는 어설션 기반 QA에 탐색 레이어를 병행시키는 구성입니다. 릴리스 판단에는 계속해서 기존 테스트를 사용하고 있습니다.

결론

agent-browser를 시도하면서, 탐색 결과를 자체 보고만으로 판단하지 않는 것과 발견한 불량에 따라 검증 대상을 선택하는 것의 중요성을 배웠습니다.

에이전트에게는 정해진 조건 내에서 목적지로 가는 경로를 찾게 합니다. 결과는 Playwright, API 테스트, 산출물 검증을 통해 확인합니다. 원인을 알게 되면, 그 동작 방식을 지킬 수 있는 계층에 회귀 테스트를 남깁니다.

이 구성이 모든 용도에 맞는 것은 아닐지라도, 저희 환경에서는 탐색의 유연성과 검증의 명확성을 모두 갖추는 데 도움이 되고 있습니다.

미지의 문제 발견에 AI를 사용하고, 얻은 지식은 지속적으로 실행 가능한 테스트로 옮깁니다. 그 축적을 통해 탐색의 가치를 회귀 방지에 연결해 나가고 싶습니다.

논의