How We Optimized Browser Use for Deep Agents

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Managed Deep Agents 팀은 7개 브라우저 도구 세트를 비교해 Stagehand를 선택하고, LangSmith 추적과 평가를 반복해 컨텍스트 사용·비용·실행 시간을 개선했다.

📌 핵심 요약

• 브라우저 사용은 공개 API로 처리하기 어려운 웹 작업과 코딩 에이전트가 만든 웹 앱의 종단 간 테스트에 유용하며, 긴 작업 흐름과 방대한 페이지 콘텐츠 때문에 효율적인 컨텍스트 관리가 필요하다.
• Claude Sonnet 5.5로 WebVoyager 100개 작업을 비교한 결과, Stagehand는 성공률 90%, 총비용 $1.98, 작업당 중앙값 17.4초를 기록했다. Playwright MCP는 성공률 78%, 총비용 $26.71로 약 13배 비쌌고, 작업당 시간은 약 3배 길었다.
• Stagehand는 여러 동작을 한 번에 실행하는 코드 모드, 상호작용 요소를 압축해 보여주는 snapshot, 브라우저 내부 실행을 통해 모델 호출과 컨텍스트 유입량, 브라우저와의 통신 왕복을 줄인다.
• 팀은 LangSmith 추적에서 비효율을 찾고 WebVoyager·HardBench·WebTailBench 평가로 변경 효과를 확인했다. HardBench에서는 페이지가 500ms 동안 조용하면 대기를 조기 종료하는 개선에 구조화된 응답과 모델 호출 타임아웃을 함께 적용해, 정확도가 측정 잡음 범위에 머무는 가운데 실행 시간 중앙값을 182초에서 124초로 줄였다.
• 같은 도구를 오픈소스 Deep Agents에서 사용하려면 langchain-stagehand의 StagehandMiddleware를 추가할 수 있다. 로컬 브라우저를 사용할 수 있으며, 공개 웹에서 대규모로 실행할 때는 Browserbase의 browserbase.launch()를 사용하는 방식을 안내한다.

🧩 주요 포인트

1. 같은 모델·작업에서도 도구에 따라 비용과 속도가 크게 달라짐 → 브라우저 도구 설계가 에이전트 성능 최적화의 핵심 변수다.
2. 코드 모드·snapshot·브라우저 내부 실행이 서로 다른 낭비를 줄임 → 모델 판단 횟수, 페이지 표현량, 통신 왕복을 함께 살펴볼 필요가 있다.
3. LangSmith 추적에서 찾은 개선을 평가로 검증함 → 성공률뿐 아니라 비용과 시간을 함께 확인해야 최적화의 효과를 판단할 수 있다.

🧠 상세 정리

1. 브라우저 사용의 확산과 컨텍스트 문제

브라우저를 사용하는 에이전트는 공개 API가 없는 사이트에서도 장거리 자동차 여행 계획, 사용하지 않는 구독 해지, 자동차 판매 등록처럼 여러 단계가 필요한 작업을 수행할 수 있으며, 글은 Instinct와 Meta의 Muse를 사례로 든다. DataDome은 9월 한 달 동안 에이전트의 브라우저 요청이 4.7배 증가했다고 보고했으며, 글은 브라우저 사용의 주요 용도를 API로 처리하기 어려운 작업과 코딩 에이전트가 만든 웹 앱의 종단 간 테스트로 설명한다. 이를 위해서는 페이지를 열고 읽고 조작하는 도구와 실제로 제어할 브라우저가 필요하고, 대부분의 도구 세트는 Chrome을 검사하고 제어하는 Chrome DevTools Protocol(CDP)을 사용한다. Managed Deep Agents는 LangSmith에서 별도 인프라 운영 없이 에이전트를 구축·배포하고 브라우저도 실행할 수 있게 하며, Browserbase 같은 호스팅 제공자는 CAPTCHA, 봇 차단, 대규모 브라우저 운영을 처리한다. 도구 측면의 핵심 어려움은 작업이 길고 페이지 정보가 많다는 점으로, Playwright MCP의 WebVoyager 작업은 평균 26번의 모델 턴이 필요했고 Browserbase 호스팅 MCP 서버의 탐색 응답은 중앙값 약 17,000자였다.

2. 추적과 세 가지 벤치마크를 결합한 평가

팀은 벤치마크 실행, LangSmith 추적 검토, 도구 수정, 재평가를 반복하는 방식으로 최적화를 진행했으며, 모든 실행을 LangSmith 실험으로 기록해 설정별 수치와 해당 추적을 연결했다. WebVoyager에서는 Allrecipes, Amazon, Google Flights 같은 인기 사이트의 일상 작업 100개를 Claude Sonnet 5.5로 수행하고 Jev 판정기로 채점했으며, 비교적 포화된 벤치마크라는 특성을 이용해 컨텍스트 사용량·비용·속도를 비교했다. HardBench는 Browserbase가 제공한 더 어려운 작업 102개로 구성되며 자체 검증기로 평가하고 주로 Claude Opus 5.5를 사용했다. WebTailBench는 Microsoft의 실제 환경에서 드물게 나타나는 작업을 짧은 평가 기준에 따라 채점하는 벤치마크로, 팀은 그중 150개를 Stagehand 평가 체계에서 실행했다. 모든 하니스가 구조화된 JSON 답변을 반환하도록 해 표를 요구하는 작업에 한 줄로 답하는 등의 형식 오류가 브라우징 능력의 감점으로 이어지지 않게 했고, 이 옵션을 Browserbase 평가 체계에도 기여했다.

3. 7개 도구 세트 비교와 Stagehand 선택

첫 비교에서는 모델과 작업을 고정한 채 도구 세트만 바꿨으며, Playwright MCP·browser-use·Browserbase MCP의 동작별 네이티브 도구, agent-browser·browse의 CLI, Stagehand와 코드에서 호출하는 Browserbase MCP의 코드 모드를 비교했다. WebVoyager 100개 작업에서 모든 도구의 성공률은 78~90%였지만, Stagehand는 가장 높은 90%를 기록하면서 총비용 $1.98와 작업당 중앙값 17.4초를 달성했다. Playwright MCP는 성공률 78%, 총비용 $26.71로 약 13배 비쌌고 작업당 시간도 약 3배 길어, 성공률 차이보다 비용과 속도 차이가 특히 컸다. 더 어려운 HardBench의 핵심 작업 38개에서도 Deep Agents는 Stagehand의 코드 작성형 run 도구로 30개를 통과한 반면 Browserbase의 명령형 browse CLI로는 21개를 통과했으며, CLI의 작업당 비용은 3배였다. 선택된 Stagehand는 상호작용 요소에 ID를 붙인 접근성 트리를 읽는 snapshot, 동작 묶음이나 Playwright 방식 JavaScript를 실행하는 run, 렌더링된 페이지를 캡처하는 screenshot의 세 도구를 제공한다.

4. 코드 모드로 모델 턴과 중간 컨텍스트 축소

코드 모드에서는 에이전트가 브라우저 도구를 하나씩 호출하는 대신 페이지 열기, 입력, 클릭, 확인으로 이어지는 전체 동작을 코드로 작성해 실행하므로 각 단계 사이에 모델의 판단을 기다리지 않아도 된다. 실행 중 다루는 중간 정보는 코드의 변수에 남고 최종적으로 반환한 내용만 모델 컨텍스트에 들어가므로, 긴 순차 작업에서 턴 수와 컨텍스트 유입량을 함께 줄일 수 있다. Stagehand를 선택하기 전에도 Browserbase MCP 도구를 개별 호출하는 대신 인터프리터의 코드에서 호출하자 비용이 $17.87에서 $4.52로 약 4분의 1이 됐다. Stagehand의 run은 작업당 평균 10단계로 Playwright MCP의 26단계보다 적었고, 탐색 응답의 중앙값은 117자로 Browserbase 호스팅 navigate 도구의 약 17,000자보다 작았다. 또한 모델이 학습 과정에서 많이 접한 Playwright 방식 코드를 Stagehand 명령으로 변환하도록 했으며, 정확한 도구 설명을 제공해도 Stagehand 고유 API를 직접 작성하게 한 대안은 성공률이 5.3퍼센트포인트 낮고 성공 작업당 비용이 19% 높았다.

5. snapshot으로 페이지 읽기 비용 절감

페이지 읽기는 브라우저 에이전트의 비용이 많이 드는 작업 중 하나이며, Stagehand의 snapshot은 접근성 트리를 필요한 부분으로 줄이고 각 상호작용 요소에 ID를 붙여 반환한다. 에이전트는 이 ID를 run의 클릭 명령에 바로 사용할 수 있으므로 버튼을 누르기 위해 원시 HTML을 읽거나 선택자를 직접 작성할 필요가 없다. Browserbase는 Stagehand v4가 Playwright보다 토큰 효율이 약 80% 높다고 보고하며, 글은 주로 screenshot 대신 snapshot으로 페이지를 읽는 방식을 컨텍스트 관리의 큰 이점으로 평가한다. snapshot은 동작으로 연결하기 쉬운 압축 텍스트인 반면 screenshot은 모델이 해석해야 하는 이미지이며, WebTailBench 실행에서 스크린샷 크기의 중앙값은 호출당 89KB였다. 다만 정보를 줄이는 방식도 중요해서, 반환된 snapshot을 사후에 8,000자로 잘랐을 때는 에이전트가 페이지를 다시 가져왔고 성공 작업당 비용도 줄지 않아 필요한 정보를 생성 단계에서 적절히 추리는 것이 중요하다는 결과가 나왔다.

6. 브라우저 내부 실행으로 통신 왕복 축소

글이 설명한 Playwright의 단일 클릭은 요소를 화면 안으로 스크롤하고 위치를 읽은 뒤 마우스 이동, 누르기, 떼기를 수행하는 다섯 번의 CDP 호출로 구성된다. Playwright는 각 응답을 받은 다음 요청을 보내므로 클릭 하나에도 에이전트와 브라우저 사이를 다섯 번 왕복하며, 브라우저가 노트북에서 샌드박스나 클라우드로 멀어질수록 이 지연이 누적된다. Stagehand v4는 브라우저 확장 프로그램으로 내부에서 실행돼 저수준 호출이 페이지 가까이에서 처리되고, run은 여러 동작을 한 묶음으로 보내 한 번의 왕복으로 실행할 수 있다. Browserbase는 자체 벤치마크에서 v4가 Playwright보다 2배 빠르다고 보고했으며, 이는 앞서 제시한 팀의 WebVoyager 비교 결과와는 별도로 소개된 수치다. 이 설계는 모델 호출 사이의 대기를 줄이는 코드 모드와 함께, 브라우저 제어 과정 자체에서 발생하는 통신 대기도 줄이는 역할을 한다.

7. 고정 대기 최적화와 성능 검증

Stagehand를 선택한 뒤에도 하니스를 조정했으며, 가장 큰 추가 개선은 페이지 로딩을 기다리는 방식에서 나왔다. LangSmith 추적에서는 에이전트가 page.waitForTimeout(8000)처럼 고정된 대기 시간을 작성했지만, 실제 페이지는 대부분 그보다 일찍 준비돼 실행 시간의 상당 부분을 아무 작업 없이 보내는 현상이 관찰됐다. 팀은 페이지가 500ms 동안 조용하면 대기를 종료하되 에이전트가 요청한 시간보다 늦게 끝나지는 않도록 run을 수정했고, 한 측정에서는 8초 대기가 0.6초 만에 반환됐다. HardBench에서는 이 수정에 구조화된 답변과 모델 호출 타임아웃을 함께 적용했을 때 에이전트 실행 시간 중앙값이 182초에서 124초로 줄었고, 정확도 변화는 측정 잡음 범위에 머물렀다. 따라서 이 전체 시간 감소를 대기 수정 하나의 효과로만 볼 수는 없으며, 글은 평가로 확인한 개선을 소개하면서 해당 대기 수정이 이후 Stagehand에도 반영됐다고 설명한다.

8. 도구 설계의 교훈과 Deep Agents 적용

글의 결론은 브라우저 작업이 에이전트의 컨텍스트를 크게 압박하며, 모델에 반환하는 정보량과 필요한 턴 수를 줄이는 도구 설계에서 가장 큰 개선을 얻었다는 것이다. 다른 에이전트에도 같은 접근을 적용할 수 있다고 제안하며, 사용 사례가 만들어내는 컨텍스트를 이해하고 추적으로 단계·토큰 낭비를 찾은 다음 평가로 변경의 효과를 확인하는 반복 과정을 강조한다. 소개된 도구는 Managed Deep Agents의 브라우저 기능에 사용되며, 오픈소스 Deep Agents에서는 langchain-stagehand의 StagehandMiddleware를 에이전트에 추가해 이용할 수 있다. 예제는 local_browser.launch(headless=True)로 로컬 브라우저를 실행하고 Stagehand 인스턴스를 만든 뒤, openai:gpt-5.5를 사용하는 create_deep_agent에 미들웨어를 연결하는 구성이다. 공개 웹을 대규모로 탐색할 때는 로컬 실행 대신 Browserbase의 browserbase.launch()로 브라우저를 시작하도록 안내하며, 브라우저 범위와 샌드박스 내 앱 테스트에 관한 세부 사항은 별도 가이드로 연결한다.

🧾 핵심 주장 / 시사점

• WebVoyager 비교에서 성공률 차이보다 비용 차이가 훨씬 크게 나타났다는 점은, 브라우저 에이전트를 평가할 때 작업 성공 여부와 실행 효율을 함께 봐야 함을 보여준다.
• snapshot을 사후에 잘랐을 때 재조회가 발생한 결과는, 컨텍스트 축소가 단순한 출력 길이 제한이 아니라 에이전트가 행동에 필요한 정보를 유지하는 표현 설계의 문제임을 시사한다.
• Playwright 방식 코드가 Stagehand 고유 API보다 좋은 결과를 낸 점은, 도구 설명의 정확성뿐 아니라 모델이 익숙하게 작성할 수 있는 인터페이스도 성능에 영향을 준다는 근거다.

✅ 액션 아이템

• Stagehand와 Playwright MCP 비교 시 성공률·비용·작업당 시간을 함께 평가.
• LangSmith 추적으로 모델 호출, 페이지 콘텐츠, 대기에서 발생하는 비효율을 확인하고 평가로 개선 효과 검증.
• 오픈소스 Deep Agents 적용 시 StagehandMiddleware를 연결하고 실행 규모에 따라 로컬 브라우저 또는 Browserbase 사용 검토.

❓ 열린 질문

• Stagehand의 WebVoyager 성공률 90%와 비용·속도 이점은 실제 적용하려는 웹 작업에서도 유지되는가?
• 코드 모드·snapshot·브라우저 내부 실행 중 실제 작업의 모델 호출, 컨텍스트 유입량, 통신 왕복을 가장 크게 줄이는 요소는 무엇인가?
• HardBench의 실행 시간 중앙값을 182초에서 124초로 줄인 대기 개선·구조화된 응답·모델 호출 타임아웃은 각각 얼마나 기여했는가?