모든 글
뉴스 해석2026-09-209 min read

브라우저 자동화 SDK의 README에는 숫자가 하나뿐이었다

"2배 빠르고 토큰 80% 절감"의 출처를 찾아봤다. 2배는 자사 호스팅 비교였고 80%는 원문에 없다. 정작 중요한 줄은 예제 코드 주석에 있었다.

"Playwright보다 2배 빠르고 토큰 효율 80% 높다"는 문장을 보고 저장소를 열었다. README 전체에 숫자로 된 성능 주장은 하나뿐이다.

그 하나는 2x인데, 문장을 읽어보면 비교 대상이 다르다.

Point the same script at Browserbase and get 2x faster execution than Playwright cloud equivalent browsers.

SDK 대 Playwright가 아니라 자사 호스팅 대 Playwright 클라우드 동급 브라우저다. 그리고 80%는 README 어디에도 없다.

출처: github.com/browserbase/stagehand (MIT)

확인된 것

저장소와 npm 레지스트리에서 직접 확인한 것만 적는다.

  • 2024-03-24 생성, 마지막 푸시 2026-09-20. 별 24,561, 포크 1,698, 열린 이슈 396. MIT. npm 최신 4.1.0, v3 계열은 3.7.3로 따로 유지. 누적 게시 버전 1,004개.

  • TypeScript·Python·Go 세 언어로 같은 API를 제공한다. 핵심은 세 함수 — act(), observe(), extract(). 나머지는 Playwright 스타일(goto, locator, screenshot)을 그대로 쓴다.

  • README가 내세우는 근거는 정성 서술이다. "Token efficiency" 항목은 하이브리드 접근성 트리 트리밍, "Faster in production" 항목은 확장으로 브라우저 옆에 붙어 왕복 지연을 줄인다는 설명이고, 둘 다 수치가 붙어 있지 않다.

  • 예제 코드의 주석이 설계 의도를 직접 밝힌다.

    observe() returns real selectors, so credentials never reach the model

    로그인 입력칸을 찾는 일은 모델이 하고, 값을 채우는 일은 반환된 선택자로 Playwright가 한다.

  • 그 밖에 확인된 기능: 쿠키 영속(userDataDir)으로 세션 유지, 사이트가 바뀌면 act/observe/extract가 동작 방식을 갱신하는 자가 치유, 중첩 iframe과 닫힌 Shadow DOM까지 가는 deep locator, WebMCP, OTel 트레이스, 호스팅 MCP 서버.

  • 토론에서 나온 보고 하나: act()에 Jev를 붙이면 4.3배 빠르고 LLM 호출이 97% 줄어든다는 언급. 저장소에서 확인되지 않는 수치다.

판단

1. 정성 서술이 유통 과정에서 수치로 굳는다

이건 저장소가 과장했다는 얘기가 아니다. 저장소는 "접근성 트리를 다듬어 필요한 만큼만 준다"고 썼을 뿐이고, 그 문장에는 숫자가 없다. 숫자는 중간에 붙었다.

그리고 붙은 숫자 중 살아남은 2x조차 조건절이 떨어져 나갔다. 원문은 Browserbase에 스크립트를 겨눴을 때 Playwright 클라우드 동급 브라우저 대비라고 명시한다. 로컬에서 Playwright 대신 이걸 쓰면 2배 빨라진다는 뜻이 아니다.

→ 도입 검토를 유통본에서 시작하면 없는 숫자를 근거로 결정하게 된다. 저장소를 먼저 열고, README에 실제로 박혀 있는 숫자만 세어봐라. 여기서는 하나였다. 하나뿐이라는 사실 자체가 정보다 — 벤더가 아직 측정해서 내놓을 준비가 안 됐다는 뜻이니까.

2. 이 SDK에서 가장 중요한 줄은 성능이 아니라 주석 한 줄이다

observe()가 선택자를 돌려준다는 설계. 이 한 줄이 비밀값이 모델 컨텍스트를 통과하지 않아도 되게 만든다.

모델은 "이메일 입력칸은 여기다"까지만 알고, 거기에 무엇이 들어가는지는 모른다. 스크린샷을 통째로 모델에 넣고 "로그인해줘"라고 시키는 방식으로는 이 분리가 불가능하다. 화면에 이미 값이 찍혀 있기 때문이다.

어제 ZCode 글에서 세운 질문이 "보낸 것을 내가 확인할 수 있나"였는데, 이건 그 질문에 대한 설계 쪽 답이다. 확인하기 어려우면 애초에 안 보내는 구조로 만들면 된다.

→ 규칙: 브라우저 자동화에 에이전트를 붙일 때, 비밀값은 모델을 거치지 말고 선택자만 받아와라. 프레임워크를 안 쓰더라도 이 분리는 직접 구현할 수 있다.

3. 접근성 트리에 기대는 설계는 두 번째다 — 이제 규칙으로 굳힐 만하다

사흘 전 안드로이드 에이전트를 보면서 같은 구조를 적었다. 접근성 정보가 잘 붙은 대상에서는 잘 되고, 비어 있으면 더 무겁고 불안정한 경로로 떨어진다.

브라우저 쪽도 같다. 토큰 효율의 출처가 접근성 트리 트리밍이라면, 그 트리가 빈약한 페이지에서는 효율도 같이 빈약해진다. 시맨틱 없이 div로만 짜인 화면, 레이블 없는 입력칸, 캔버스로 그린 UI가 그렇다.

두 번의 다른 플랫폼에서 같은 결론에 도달했으니 규칙으로 써도 되겠다. 에이전트 자동화 도구를 검토할 때 첫 단계는 벤치마크 확인이 아니라 내 대상의 접근성 트리를 떠보는 것. 브라우저에서는 개발자도구 접근성 패널로 몇 분이면 끝난다.

4. 역할별 모델 분업이 제품 안에서 먼저 일어나고 있다

act()에 Jev를 붙였다는 보고는 내가 확인하지 못한 수치지만, 방향은 짚을 만하다. Jev에 대해 쓰면서 정리한 게 "분류·선택 호출에는 텍스트 생성이 필요 없다"였는데, "이 페이지에서 어느 요소를 누를까"는 정확히 그 형태다. 선택지가 유한하고, 답은 그중 하나이며, 문장을 지어낼 필요가 없다.

그러니 이건 특정 모델 얘기가 아니라 스택 구조 얘기다. 에이전트 스택이 하나의 큰 모델에서 역할별 모델 조합으로 갈라지는 중이고, 그 갈라짐이 논문이나 블로그가 아니라 제품 내부에서 먼저 일어난다. 내가 만드는 것에서도 같은 분해가 가능한지 — 어느 호출이 생성이고 어느 호출이 선택인지 — 세어볼 시점이다.

모르는 것

  • 직접 돌려보지 않았다. 저장소 README와 레지스트리 메타데이터를 읽은 결과다.
  • 어떤 수치도 내가 재현하지 않았다. 2x는 README에 있지만 측정 방법과 대상이 공개돼 있지 않고, 80%는 README에 없으며, 4.3배와 97%는 토론에서 나온 발언이다.
  • v4의 확장 기반 구조가 어떤 실행 환경에서 제약이 있는지 모른다. 토론에 Lambda 관련 질문이 있었지만 답을 확인하지 못했다.
  • 자가 치유가 실제로 얼마나 자주 성공하는지에 대한 수치가 없다. 사이트 개편 시 조용히 틀린 요소를 누를 가능성은 남는다.
  • MIT지만 Browserbase라는 호스팅 사업이 뒤에 있다. 로컬 실행과 호스팅 실행의 기능 차이, 그리고 가격을 확인하지 않았다.

댓글

불러오는 중...

모든 글로 돌아가기