Code-as-action의 위력🔥 Webwright 도입으로 3일 규모의 E2E 테스트 실행이 30분이 되었다❗️

결론

E2E 테스트를 편하게 하고 싶어서 Webwright를 만져보다가, 테스트의 틀을 넘어선 “깨달음”에 도달했습니다.

• Web 에이전트의 정밀도는 「AI에게 무엇을 시킬 것인가」가 중요한 요소인 것 같습니다.
• Web 에이전트는 화면을 보고 「다음에 어디를 누를지」를 예측하는
  **좌표 예측 (coordinate prediction)**보다, 조작을 코드로 작성하여 실행하고, 그 결과를 AI 스스로 검증하게 하는 것이 압도적으로 강력합니다.

그것을 훌륭하게 체감하게 해준 것이 Webwright라는 터미널 네이티브 Web 에이전트입니다. 공식에서도 "Code-as-action beats coordinate prediction" (코드를 액션으로 만드는 방식이 좌표 예측을 이긴다)라고 말하고 있습니다. - 그 강력함의 정체는 특별한 모델이 아니라
설계에 있었습니다. 효과를 발휘하는 것은 「코드를 작성한다 → 실행한다 → AI 스스로 결과를 검증한다 → 통과할 때까지 수정한다」라는 일련의 루프, Code-as-action입니다. - AI에게 직접 시키는 것이 아니라 「
동작하는 것을 만들게 하고, AI에게 검증하게 하며, 성공할 때까지 수정하게 한다". 이 사고방식은 E2E 테스트를 넘어 광범위하게 활용할 수 있다고 생각합니다.

솔직히, 지금까지 Web 에이전트에는 별로 기대하지 않았다

E2E 테스트의 케이스 작성은 수수하고 시간이 걸리는 작업입니다. 특히 대상 시스템에 대해 잘 모르는 사람에게 맡길 경우에는 아주 상세하게 조작을 지시해야 합니다.

실시하는 것도 힘듭니다. 화면을 조작하고, 폼을 채우고…, 기대한 대로의 상태가 되었는지를 에비던스(evidence)로 남긴다. 이것을 사람이 수행하면 상당히 시간이 걸립니다.

그렇다고 Playwright로 옮겨 적는 것도 또한 힘든 일입니다.

「그럼 AI (Web 에이전트)에게 시켜볼까」 ── 그렇게 생각하여 이전부터 시도해 보았습니다만, 결과는 그저 그랬습니다.

• 목표한 장면에서 에비던스용 스크린샷이 찍히지 않음
• 화면 전환에 대한 이해가 부족하여 「다음에 어느 화면으로 진행해야 하는지」를 잘못 파악함
• 리치한 UI (애니메이션이나 동적 묘사)가 상대일 경우, 갑자기 거동이 수상해짐
• 실행 결과를 Playwright 스크립트로 남겨 재사용하고 싶지만, 정작 중요한 거동이 불안정하여 케이스대로 되지 않음

「아쉬운 부분까지는 갈 수 있다. 하지만 튜닝이나 수정이 너무 힘들다」라는 상태. 이것이 솔직한 체감이었다.

Webwright에 맡겼더니, 테스트가 "그대로" 완성되었다

그런 상황 속에서 Webwright (ClaudeCode의 플러그인으로 이용)를 시도해 보았습니다.

「뭐, 어느 정도 괜찮은 것은 만들어지겠지 (어차피 나중에 수정은 필요하겠지만...)」 정도로 생각하고 있었습니다.

하지만 시험 삼아 실행해 보았을 때, 조금 놀랐습니다.

제가 전달한 테스트 절차는, "알고 있는 사람"이 한다는 전제로 만들어진 한 줄짜리 테스트 케이스였습니다.

「계정이 생성되지 않은 이메일 주소로, 결제 내용 확인 화면까지 전환한다」

이것뿐입니다. 「업종 선택 → 플랜 선택 → 계약자 정보 입력 → 동약 체크 → 카드 정보 입력 → 결제 내용 확인 화면에 도달」이라는 동선을 일절 설명하지 않았습니다.

그런데도 완성된 스크립트는, 「시스템을 이해하고 있는 사람이 수행한 테스트」 그 자체였습니다.

• 각 화면의 필수 항목은 사람과 마찬가지로 화면을 보면서 AI가 채워 나간다
• 단계마다 스크린샷과 도달 URL을 에비던스로 남긴다
• 「결제 완료 화면까지 진행하지 않는다 (확정 버튼은 누르지 않는다)」라는, 지시에 없던 암묵적인 제약도 지킨다

이것은 가능하겠다 싶어 테스트 케이스를 통째로 던져 넣었습니다.

물론 수정은 필요하지만, 거의 완벽한 테스트 코드가 만들어졌습니다.

생성된 Playwright 스크립트를 돌리는 데 필요한 시간은 약 30분간. 지금까지 사람이 3일 동안 수행하던 분량의 테스트입니다.

이전의 「아쉬운」 느낌이 거짓말 같았습니다. 똑같은 Playwright가 베이스일 텐데, 왜 이렇게까지 다른 것일까.

핵심은 "Code-as-action"이었다

Webwright의 README를 읽어 내려가다 보니 「아, 이거다」라고 생각한 문장이 있었습니다.

가지고 있던 Web 에이전트가 그저 그랬던 이유가 납득되었습니다.

🧠 Code-as-action이 좌표 예측 (coordinate prediction)을 압도하다: Webwright는 모든 난이도 구분에서 재현된 GPT-5.4의 「스크린샷 + xy 좌표」 베이스라인을 실질적으로 크게 상회하는 성능을 보여주었습니다.

조금 정리해 보겠습니다. 지금까지의 Web 에이전트는 크게 두 가지 타입이 있습니다.

스냅샷형 (Snapshot type): 화면의 접근성 트리 (Accessibility Tree)를 보고, 준비된 조작 (click / type) 중에서 「다음에 만질 요소」를 하나씩 선택함

좌표 예측 (coordinate prediction)형: 스크린샷 (이미지)을 보고, 「다음에 누를 위치 (xy 좌표)」를 예측함

부르는 방식은 달라도, 둘 다 본질은 **「다음 조작을 "예측하는" 것」**입니다. 예측이 틀리거나 화면이 조금만 움직여도 금세 취약해지는 것 같습니다. 이전에 제가 「아쉽다」고 느꼈던 것도 바로 이 "예측에 의존하는" 느낌 때문이었습니다.

그리고 예측에 의존하지 않으려면 조작을 아주 상세하게 지정해야만 합니다...

반면 Webwright는 발상이 반대입니다. 「다음에 어디를 누를지」를 예측하는 대신, 조작을 Playwright 코드로 작성하여 실행합니다. AI에게는 터미널이 주어지고, 코드를 쓰고 실행하고, 출력을 보고 수정하고, 다시 실행하는 과정을 반복합니다.

"조작"을 코드로 표현하고 실행과 수정의 루프를 반복하는 것. 이것이 Webwright가 말하는 Code-as-action입니다. 공식 벤치마크에 따르면, 이 방식은 좌표 예측형 베이스라인을 모든 난이도의 케이스에서 앞질렀다고 합니다.

아시다시피 코딩 에이전트는 원래 「코드를 쓰고, 실행하고, 결과를 보고, 수정하는」 루프에 매우 능숙합니다. Webwright는 브라우저 조작을 AI가 가장 잘하는 영역으로 끌어들인 것입니다.

예측으로 움직이는 대신, 코드를 작성해 실행하고 결과를 검증하며 수정을 반복한다.

듣고 보니 당연한 이야기입니다. 하지만 실제로 구현된 결과물을 보고 나니, 마치 콜럼버스의 달걀을 본 것 같았습니다.

검증: 본질이 "코드를 쓰게 하는 것"이라면, 자체 Skill로도 재현할 수 있지 않을까?

여기서 저의 심술궂은 탐구심이 발동합니다.

「Webwright의 본질이 터미널을 넘겨주어 코드를 쓰게 하고, 결과를 스스로 검증하게 하는 설계에 있다면,

ClaudeCode + Playwright + 자체 Skill 정도만으로도 비슷한 동작을 하도록 지시하면 거의 동일한 결과가 나오지 않을까?」

시험해보고 싶어서 직접 해봤습니다. Webwright 대신 microsoft/playwright-cli를 사용하고, 명령어 하나(=조작 하나)를 실행할 때마다 출력이나 스크린샷을 Claude가 직접 읽어 성패를 확인하고, 실패하면 방법을 바꿔 다음 조작을 결정하는 대화형 루프(dialogue loop)로 브라우저를 구동하도록 했습니다.

그렇게 다듬은 절차는

재사용 가능한 Python 스크립트로 남기고, 이 역시 실행과 검증을 반복하며 문제가 있으면 수정 후 재실행한다. 전부 통과할 때까지 이를 반복한다.
이런 Skill을 직접 제작했습니다.

또한 비교하기 쉽도록 결과물은 Webwright와 동일하게 맞췄습니다.

plan.md: 테스트 실행 계획. **Parameters (파라미터 표)**와 **Critical Points (검증 체크리스트)**를 기재

final_script.py: 최종 결과물. 인수로 값을 교체하여 재실행할 수 있는 파라미터화된 Python 스크립트 (깨지기 쉬운 것을 방지하기 위해 **안정적인 셀렉터 (stable selector)**를 심어둠)

final_runs/run_<id>/: 실행 시마다 격리되는 작업 디렉토리. 하위에 **스크린샷 증적 (screenshots/)**과 **액션 로그 (final_script_log.txt)**를 남김

비교 실험: 두 패턴을 나란히 놓고 비교해 보았다

케이스 1: 심플한 정상계 (프로젝트 E2E의 대부분은 이것)

주제는 자사의 보험 인터넷 모집 사이트입니다. 가입 동선은 이탈을 방지하기 위해 「Simple is best」 원칙에 따라 철저히 설계되어 있으며, 우리가 다루는 E2E 케이스의 대부분이 이 솔직한 정상계입니다.

예를 들어 「계정 미생성 이메일 주소로 결제 내용 확인 화면까지 이동하는」 케이스를 자체 Skill로도 돌려 비교해 보았습니다. 결과는 ── 거의 동일했습니다.

한 줄에 가까운 지시로부터 「업종 선택 ~ 결제 내용 확인 화면」까지의 동선을 구성하고, 「확정 버튼은 누르지 않고 이탈」이라는 제약도 준수하며, 각 CP(Checkpoint, 체크포인트)를 스크린샷 + 로그로 검증한 상태에서 final_script.py가 완성되었습니다.

케이스 2: 시각적인 판단이 필요한, 약간 리치한 정상계

다음은 「시각」이 필요한 케이스입니다. 정상계이긴 하지만, 동적으로 그려지는 리치한 UI를 가진 사이트에서 합불 판정 조건이 **「조작에 따라 표시되는 이미지의 모습이 바뀌고 있을 것」**이라는, 이미지를 보고 판단할 수밖에 없는 경우입니다.

이를 Webwright와 자체 Skill 양쪽으로 구현하여 결과를 나란히 비교했습니다.

관점	Webwright	자체 Skill (playwright-cli)
테스트 실행 계획 내용	체크포인트를 설정하여 확실히 검증	거의 동일
생성 스크립트의 질	높음	거의 동등. 우열을 가리기 어려움
스크린샷 촬영 방식	깔끔함	약간 거칠지만 실용 범위 내
컨텍스트 소비	──	거의 동일
처리 속도	약간 빠름	약간 느린 정도 (오차 범위 수준)

종합적으로, 만듦새의 거친 부분(튜닝의 여지)은 느껴지지만, 본질적인 결과는 거의 동일했습니다. 시각적 판단이 필요한 케이스에서도 양쪽 모두 「체크포인트를 설정하고, 스크린샷을 직접 보고 검증한다」는 동일한 전략으로 자연스럽게 수렴했습니다.

참고로 나중에 Webwright의 리포지토리(Repository)를 살펴보니, 플러그인의 정체도 이 발상과 유사한 것 같았습니다. 역시 핵심은 코드를 작성하게 하여 스스로 검증하게 만드는 루프(Loop)였던 것입니다.

이것은 Skill의 잔기술이 아니라, 「설계의 전환」이었다

여기서 강조하고 싶은 점은, 자체 Skill로 재현할 수 있었기 때문에 Webwright가 대단하다는 이야기가 결코 아니라는 것입니다. 오히려 반대입니다.

Webwright가 보여준 것은 프롬프트(Prompt)의 미세한 튜닝이 아니라, **에이전트(Agent)에게 문제를 주는 방식 자체를 바꾸는 「설계의 전환」**이라고 생각합니다.

AI에게 좌표를 예측하게 하는 것이 아니라, 잘하는 코드를 작성하게 하고 스스로 결과를 검증하게 한다. 그렇기에 에이전트의 능력을 최대한으로 끌어낼 수 있습니다.

공식에서 공개한 평가 결과 ── 좌표 예측형 베이스라인(Baseline)과 비교하여 Online-Mind2Web 86.7%, Odysseys 60.8%, 상대적으로 35.1% 개선 ── 가 그 정당성을 뒷받침하고 있다고 생각합니다.

"Code-as-action beats coordinate prediction"은 캐치프레이즈가 아니라 실측된 결론이었습니다.

그리고 본질이 설계에 있기 때문에, 같은 발상으로 같은 결과에 접근할 수 있습니다. 저의 검증은 그 「본질은 설계에 있다」는 가설을 우리 손으로도 확인할 수 있었다는 점에 가치가 있었다고 생각합니다.

일반화하면: 「AI를 움직이게 하는 것」이 아니라 「움직이는 것을 만들게 하여 검증하게 하는 것」

이번에는 E2E 테스트에 관한 이야기였지만, 이 발상은 훨씬 더 넓게 적용될 수 있다고 생각합니다. 제가 가장 큰 배움이라고 느낀 점은 바로 이것입니다.

AI에게 직접 태스크(Task)를 "실행"하게 하는 것이 아니라, AI에게 "움직이는 스크립트"를 만들게 하고, 그 결과를 AI 스스로 검증하게 하며, 성공할 때까지 다시 만들게 한다.

브라우저 조작에 국한되지 않고 데이터 처리든, 인프라 조작이든, 어떠한 「정답을 관측할 수 있는」 태스크라면 다음과 같은 루프는 응용이 가능합니다.

• 코드로 작성하게 한다
• 실행하여 결과를 관측한다
• AI 스스로 성패를 검증한다
• 안 되면 수정하여 재실행한다

「AI를 잘 다루는 것」에 고민하고 있는 분들은, 애초에 AI에게 무엇을 시키고 있는지를 한 번 점검해 보면 돌파구를 찾을 수 있을지도 모릅니다.

Discussion