We made Playwright 2x faster and 80% more token efficient
Stagehand는 Playwright의 브라우저 자동화 API를 바탕으로 AI 에이전트에 맞춘 SDK입니다. 브라우저 내부 확장 프로그램, 접근성 트리 기반 컨텍스트 축소, 배치 명령과 캐싱을 활용해 Playwright 대비 2배 빠른 실행과 80% 높은 토큰 효율을 목표로 하며 TypeScript·Python·Go를 지원합니다.
AI 요약
Stagehand는 웹사이트에서 데이터를 추출하고 자연어로 브라우저 동작을 수행하기 위한 SDK입니다. 원래 테스트를 위해 설계된 Playwright와 달리, Stagehand는 AI 에이전트가 웹을 조작하는 상황을 주요 대상으로 삼습니다. TypeScript, Python, Go용 SDK를 제공하며, 기존 Playwright 사용자에게 익숙한 `goto`, `locator`, `screenshot` 같은 브라우저 API를 계속 사용할 수 있도록 구성했습니다.
■ 로그인 상태를 유지하면서 자연어로 브라우저 조작
로컬 실행에서는 `localBrowser.launch()`에 `userDataDir`을 지정해 쿠키와 브라우저 데이터를 보존할 수 있습니다. 예제에서는 사용자가 한 번 로그인한 뒤 다음 실행부터 같은 세션을 재사용하는 흐름을 보여줍니다. 먼저 `observe()`에 “이메일 입력란을 찾아라”, “비밀번호 입력란을 찾아라”와 같은 지시를 전달하면, Stagehand가 실제 DOM selector를 반환합니다. 반환된 selector는 일반적인 Playwright locator로 넘겨지므로 이메일과 비밀번호 값 자체가 모델에 전달되지 않은 상태에서 애플리케이션 코드가 직접 입력할 수 있습니다.
로그인 버튼을 누르거나 청구 페이지를 여는 작업은 `act()`에 자연어 명령을 전달해 수행합니다. 문서에서는 사이트가 폼 구조를 변경하더라도 `act()`가 동작 방식을 새로 확인해 스스로 복구하는 self-healing 동작을 제공한다고 설명합니다. 데이터 추출에는 `extract()`를 사용합니다. TypeScript에서는 Zod 스키마로 송장 번호, 금액, 결제 여부를 정의하고, Python에서는 Pydantic 모델을 사용하며, Go에서는 구조체 타입으로 결과를 받습니다. 따라서 단순한 텍스트 응답이 아니라 애플리케이션에서 바로 사용할 수 있는 스키마 검증 데이터를 반환하는 구조입니다.
■ 성능 개선의 핵심은 브라우저와 실행 코드 사이의 왕복 감소
프로젝트가 해결하려는 가장 큰 문제는 브라우저 자동화에서 발생하는 round-trip latency입니다. 기존 구조에서는 각각의 동작이 스크립트와 브라우저 사이를 왕복해야 하며, 로컬에서는 지연이 짧더라도 브라우저가 클라우드에 있고 스크립트가 다른 지역이나 별도 런타임에서 실행되면 지연이 커질 수 있습니다. Stagehand v4는 브라우저가 시작될 때 자동으로 로드되는 확장 프로그램을 통해 브라우저를 제어하는 구조로 다시 만들었다고 설명합니다. 커뮤니티 답변에서는 이 구조도 Chrome DevTools Protocol(CDP)을 사용하지만, 별도 런타임이나 별도 리전에서 실행되는 스크립트가 아니라 브라우저 내부의 확장 프로그램이 CDP와 통신한다고 밝혔습니다.
문서가 제시하는 성능 결과는 Browserbase의 클라우드 브라우저에서 Playwright의 클라우드 동등 환경보다 2배 빠른 실행입니다. 또한 에이전트가 매번 전체 페이지 정보를 처리하지 않도록 hybrid accessibility-tree trimming을 사용해 필요한 페이지 컨텍스트만 모델에 전달한다고 설명합니다. `act()`와 `extract()`는 에이전트용으로 설계된 토큰 효율 중심의 메서드이며, 서버 측 캐시를 켜면 동일한 요청을 Browserbase에서 재사용해 반복 동작에 토큰을 사용하지 않도록 할 수 있습니다. 프로젝트 측은 이 구조를 바탕으로 Playwright보다 80% 더 높은 토큰 효율을 달성했다고 주장합니다.
이 수치는 Stagehand가 제공하는 자체 평가 결과로 제시됩니다. 커뮤니티의 프로젝트 담당자는 frontier 모델과 오픈 웨이트 모델을 포함해 12개 모델 및 Codex, Claude Code 등 여러 도구에서 성능을 비교한 벤치마크를 공개했다고 안내합니다. 다만 공개된 소개 내용에서 각 모델별 측정 조건이나 비용 산정 방식까지 설명하지는 않습니다.
■ 로컬·클라우드·MCP를 아우르는 실행 방식
로컬에서 사용하려면 Chrome이 설치되어 있어야 하며, TypeScript에서는 `@browserbasehq/stagehand`와 Zod를 설치하고, Python에서는 `stagehand`, Go에서는 `github.com/browserbase/stagehand/packages/sdk-go/v4`를 설치합니다. 프로젝트 저장소를 직접 빌드할 때는 `just install`, `just generate`, `just build`를 실행한 뒤 예제 명령을 수행하는 방식입니다.
클라우드 실행에서는 Browserbase 브라우저를 생성한 뒤 Stagehand를 연결합니다. Model Gateway를 사용하면 각 동작에 적합한 저비용 모델을 자동으로 선택하도록 구성할 수 있어 모델 공급자별 설정을 직접 연결하지 않아도 됩니다. `cache: true` 또는 Go SDK의 캐시 옵션을 사용하면 동일한 호출을 서버 측에서 재사용할 수 있습니다. Browserbase 환경에는 verified mode, residential proxy, persistent context, 세션 녹화 기능도 제공됩니다.
또 다른 사용 방식은 Browserbase의 호스팅 MCP 서버입니다. Claude, Cursor, Codex 등 MCP 클라이언트에 서버 URL과 인증 헤더를 등록하면 별도 설치 없이 `navigate`, `act`, `observe`, `extract` 기능을 사용할 수 있습니다. 브라우저 세션이 필요하지 않은 작업을 위해 URL을 Markdown으로 가져오는 `fetch`와 웹 검색 결과를 반환하는 `search`도 제공하며, 문서에서는 이를 브라우저 세션을 보완하는 가벼운 수단으로 소개합니다. WebMCP, 클립보드, 중첩 iframe 및 닫힌 Shadow DOM을 위한 deep locator, OpenTelemetry(OTel) trace도 에이전트용 기능으로 열거합니다.
■ Hacker News 반응
• @wittydeveloper — 저희는 2년 전에 Stagehand를 만들었고, 2만 4천 개의 별과 월간 npm 다운로드 400만 회를 기록했습니다. 최근에는 가장 큰 결함인 round-trip latency를 해결했습니다. 수행되는 모든 동작은 스크립트와 브라우저 사이의 왕복을 필요로 합니다. 로컬에서 실행할 때는 짧지만 클라우드에서 실행하면 증가합니다. 또한 Playwright MCP의 지나치게 큰 토큰 사용량에 대해 불평하는 글도 여러 개 보았습니다. 그래서 Stagehand를 처음부터 다시 만들었고, 브라우저가 시작될 때 자동으로 로드되는 확장 프로그램을 통해 브라우저를 제어하는 v4를 출시했습니다. Stagehand v4에는 배치 명령 지원, 토큰 효율적인 전용 메서드인 `act()`와 `extract()`, 그리고 Playwright보다 2배 빠르고 토큰 효율이 80% 더 높은 새로운 아키텍처가 포함되어 있습니다. 직접 확인할 수 있도록 여러 frontier 모델과 오픈 웨이트 모델, Codex와 Claude Code 등을 비교한 벤치마크도 공개했습니다. 무엇이든 물어보세요!
• @cl685 — CDP와 비교했을 때 무엇을 잃었나요? 예를 들면 cross-origin iframe이나 확장 프로그램을 로드할 수 없는 환경에서 실행되는 다운로드 같은 것들입니다.
• @wittydeveloper — 여전히 CDP를 사용하지만, 별도 런타임이나 더 나쁘게는 별도 리전에서 실행되는 스크립트가 아니라 브라우저 내부의 확장 프로그램을 통해 통신합니다.
• @youngtaff — CDP를 WebSocket으로 사용하나요, 아니면 pipe를 사용하나요?
• @smpandya — 직접 사용해 보았고, 제 결론은 스크린샷을 파싱하고, 동작을 생성하며, headful 모드로 제한되는 방식의 오버헤드가 접근성 트리를 읽고 CDP 명령을 생성하는 것보다 훨씬 비효율적이라는 것입니다. 기본적으로 브라우저 자동화는 computer use보다 하드웨어에 가까운 추상화이고, 더 많은 유연성을 제공하며, 대규모로 실행하면 결국 훨씬 저렴합니다.
원문: Hacker News / 번역·요약: Trawling