Playwright 는 왜 LLM 과 안 맞았나 — 같은 브라우저인데 결과가 뒤집힌 이유

한 공개 벤치마크를 봤습니다. 한국 개발자가 국내 사이트 다섯 곳에서 세 구성을 비교한 것입니다. 에이전트 브라우저 Aside 가 자체 에이전트로 돌 때는 다섯 작업을 전부 끝냈고 전 항목에서 가장 빨랐습니다. 그런데 같은 브라우저를 코딩 에이전트에 CLI 로 물려주니 Playwright 에 졌습니다.

같은 브라우저인데 운전 방식에 따라 결과가 뒤집힌 것입니다. 이 수치는 그 저장소의 측정이고 독립 검증은 아닙니다. Aside 가 내세우는 「벤치마크 셋 1위」도 자체 채점 수치라 벤더 주장으로 갈라 둡니다. 그래서 숫자를 더 보태지 않고 해석만 우리 실측으로 받쳐 봅니다.

「Playwright 로는 안 되던 게 에이전트 브라우저로는 되더라」가 왜 도구 교체가 아니라 층 교체인지가 이 글의 주제입니다.

Playwright 가 전제하는 것

Playwright 는 결정론적 스크립트를 전제합니다. `page.click('#login-btn')` 처럼 셀렉터를 개발자가 미리 정하고, 그러려면 DOM 을 이미 알고 있어야 합니다. CI 에서 같은 테스트를 매번 똑같이 돌리는 용도로는 이 전제가 완벽합니다. 다만 LLM 이 브라우저를 운전할 때는 세 곳에서 어긋납니다.

페이지 상태를 어떻게 줄 것인가 — HTML 전체는 수만 토큰입니다. 접근성 트리로 줄여도 큰 페이지는 부담이고, 요약 방법의 답이 프레임워크 안에 없습니다

왕복 비용 — 한 동작씩 주고받으면 10단계에 왕복 10번입니다. 매번 페이지 상태를 다시 읽습니다

실패 복구 — 셀렉터가 안 맞으면 에러를 던지고 끝납니다. LLM 은 그 자리에서 다른 방법을 찾아야 하는데 그 로직이 없습니다

셋 다 Playwright 의 결함이 아닙니다. 사람이 미리 아는 페이지를 반복해서 도는 도구에는 처음부터 필요 없던 층입니다.

에이전트 브라우저가 실제로 바꾼 것

그 층을 채우려고 나온 물건이 두 갈래입니다. Playwright 위에 자연어를 셀렉터로 바꾸는 어댑터를 얹은 것과, 브라우저 자체를 다시 설계한 것입니다.

에이전트 브라우저가 바꾼 것은 셋입니다. 브라우저를 JS 함수로 노출해 10단계를 한 덩어리로 보내는 왕복 제거, 쓰던 프로필의 쿠키와 로그인을 그대로 받는 세션 상속, 페이지 상태를 모델이 읽기 좋게 가공하는 LLM 용 스냅샷입니다.

벤치마크의 뒤집힘은 여기서 설명됩니다. 같은 Aside 를 CLI 로 코딩 에이전트에 물리면 호출마다 왕복이 도로 생기고, 스냅샷 가공도 바깥 에이전트의 몫이 됩니다. 이긴 것은 브라우저가 아니라 그 브라우저에 맞춰 튜닝된 에이전트 루프였습니다.

우리 실측 — 속도는 안 갈렸다

우리 쪽에도 같은 결의 실측이 있습니다. 8월에 raw CDP·Playwright·Claude in Chrome 을 같은 크롬에 붙여 150분을 쟀습니다. 명령 왕복이 CDP 0.2ms, Playwright 0.3ms 였고 기동은 1,100ms 와 1,057ms 였습니다.

3표본으로는 반대 결론이 나왔는데 6회로 늘리니 뒤집혔습니다. Playwright 는 CDP 를 대체하는 것이 아니라 그 위의 편의층이라, 같은 프로토콜 위의 래퍼끼리 밀리초를 재는 것은 헛일이었습니다.

갈린 것은 받는 데이터의 크기였습니다. 같은 페이지에서 전체 HTML 이 130,759자, Playwright MCP 형태의 접근성 스냅샷이 11,609자, CDP 로 필요한 것만 질의하면 304자였습니다. 접근성 스냅샷과 견주면 38배, 전체 HTML 과 견주면 400배가 넘습니다. LLM 에게 이 크기는 곧 토큰입니다.

반대 방향도 있습니다. raw CDP 로 클릭 한 번을 하려면 4메서드·6호출이 필요합니다. 조사와 읽기는 CDP 가 싸고 다단계 조작은 래퍼가 쌉니다. 앞의 「왕복 비용」 지점을 숫자로 본 셈입니다.

로그인 벽이 경로를 갈랐다

두 번째로 갈린 것은 로그인이었습니다. 고객 안내용 매뉴얼 스크린샷을 Playwright MCP 로 찍으려 했는데, 자기 브라우저를 새로 띄우기 때문에 사람이 로그인해 둔 세션을 빌리지 못했습니다. 비밀번호 입력은 에이전트 동작 규칙상 금지라 우회도 없었습니다.

그래서 사람의 브라우저를 디버그 포트로 재시작하고 `connect_over_cdp` 로 붙는 경로를 세웠습니다. 스크립트 1개, 2초, stdout 300자로 끝났습니다.

「Playwright 는 로그인을 유지 못 한다」는 오해입니다. `storageState` 로 쿠키와 로컬스토리지를 저장했다 주입하면 됩니다. 다만 우리 건은 그걸로 풀리는 종류가 아니었습니다. 세션이 아니라 사람이 로그인해 둔 그 창이 필요했습니다.

진짜 차이는 로그인 가능 여부가 아니라 평소 쓰는 프로필을 그대로 물려받느냐입니다. 도구를 바꾼 것이 아니라 층을 바꾼 것이고, 외부 API 를 직접 치다 세 번 막힌 것을 공식 CLI 에 위임해 뚫었던 것과 같은 모양입니다.

에이전트 브라우저 쪽에도 함정이 있다

에이전트 브라우저가 답이라는 얘기는 아닙니다. 9월에 Aside 의 CLI 로 매뉴얼 캡처를 하며 처음 30분을 함정에서 썼습니다.

`page.screenshot({path})` 가 조용히 아무것도 안 만들었습니다. ok 만 찍히고 파일이 없어, Buffer 를 base64 로 stdout 에 흘려 받았습니다

`fullPage:true` 가 페이지를 겹쳐 찍어 개인정보가 크롭에 들어왔습니다. 즉시 삭제했습니다

호출마다 세션이 갈려 앞 호출로 연 탭이 다음 호출에 보이지 않았습니다. 벤치마크에서 CLI 구성이 진 것과 같은 자리입니다

고르는 기준은 「스크립트로 적을 수 있나」

그래서 우리 결정표는 도구 하나가 아니라 셋입니다.

조사·측정·DOM 질의 → CDP 스크립트

다단계 조작 → Playwright 래퍼

사람이 로그인한 창이 필요한 스크린샷 → ego lite, Aside CLI, Claude in Chrome 순으로 그 창을 빌린다

한 줄로 줄이면 「이 작업을 스크립트로 적을 수 있나」입니다. 적을 수 있는 일에 LLM 을 붙이면 비결정성과 토큰만 삽니다. 적을 수 없는 일에 스크립트를 고집하면 셀렉터가 깨질 때마다 사람이 고칩니다. 에이전트를 쓰더라도 읽기와 조사는 CDP 로 내려가는 쪽이 수십 배 쌉니다.

마지막으로 계정 권한입니다. 세션 상속은 편의이자 폭발 반경입니다. 로그인된 창을 빌린 에이전트는 그 계정의 권한을 전부 갖고, 페이지를 읽어 판단하므로 흰 글씨·0px·alt 텍스트에 심긴 지시에도 취약합니다.

전용 계정 분리는 위험 제거가 아니라 폭발 반경 축소입니다. 「이 계정이 탈취됐다고 가정했을 때 감당 가능한 피해인가」로 계정을 고릅니다.

도입 전 점검

이 작업을 스크립트로 적을 수 있는가 — 적을 수 있으면 프레임워크로 충분하다

사람이 로그인해 둔 창이 필요한가, 시드 계정의 `storageState` 로 되는가

에이전트가 페이지에서 받는 데이터 크기를 재봤는가 — 토큰은 거기서 나온다

빌려주는 계정이 탈취됐다고 가정하면 감당 가능한가

마무리

Playwright 가 LLM 과 안 맞았던 것은 성능 문제가 아니었습니다. 사람이 미리 아는 페이지를 반복해서 도는 도구에 페이지를 처음 보는 모델을 앉힌 것입니다. 그 사이를 메우는 층이 어댑터와 에이전트 브라우저로 나왔고, 벤치마크의 뒤집힘은 그 층이 붙었다 떨어졌다 한 결과입니다.

매번 똑같은 작업이면 여전히 Playwright 가 가장 싸고 빠릅니다. 매번 판단이 필요하고 사람의 창을 빌려야 하면 에이전트 브라우저입니다. 어느 쪽이든 읽기는 CDP 로 내려가고, 빌려주는 계정은 잃어도 되는 것으로 고릅니다.