Browser Use in Managed Deep Agents

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Managed Deep Agents는 LangSmith에서 브라우저와 실행 인프라를 관리하고, 세션 공유·사용자 핸드오프·컨텍스트 효율적인 도구를 제공해 API가 지원하지 않는 웹 작업과 엔드투엔드 테스트를 수행하도록 한다.

📌 핵심 요약

• Managed Deep Agents는 개발자가 지침과 도구를 작성하면 LangSmith가 하네스와 런타임, 브라우저를 운영하는 서비스다. 브라우저는 클릭·스크롤·양식 입력이 필요한 웹 작업과 엔드투엔드 테스트에 활용되며, 작업을 지원하는 API가 있다면 API 사용이 권장된다.
• 프로젝트 루트의 browser.py에서 define_browser로 browser를 내보내 브라우저를 추가한다. 기본값인 scope="thread"는 대화마다 독립된 브라우저를 제공하고, scope="user"는 로그인한 사용자의 스레드별 창을 분리하면서 쿠키와 브라우저 상태를 공유한다. idle_ttl_seconds의 기본값은 600초로, 해당 시간 동안 활동이 없으면 브라우저가 중지된다.
• browser_handoff는 로그인처럼 사람이 필요한 단계를 사용자에게 넘긴다. 사용자는 LangSmith Studio의 동일한 브라우저에서 직접 로그인하고 Hand back으로 제어권을 돌려주며, Slack 같은 Managed Deep Agents 채널에서도 지원된다. scope="user"에서는 로그인 상태가 이후 스레드에도 이어진다.
• 브라우저는 에이전트와 분리된 LangSmith sandbox에서 실행된다. Stagehand 기반 도구는 접근성 트리 조회, 동작 실행, 스크린샷, 사용자 핸드오프를 제공하며, browser_run은 여러 단계를 한 번에 실행하고 필요한 결과만 반환한다. 저자 측 평가에서 WebVoyager 100개 작업의 성공률은 90%, 총비용은 $1.98로, 비교한 7개 도구 세트 중 성공률이 가장 높았다. 가장 근접한 Browserbase MCP 서버는 성공률 89%에 비용은 9배였다.
• 엔드투엔드 테스트에서는 비공개 localhost 브리지가 브라우저와 에이전트 sandbox의 앱을 연결하므로 공개 URL이 필요 없다. 에이전트는 execute로 앱을 시작하고 실제 사용자 흐름을 검증하며, 통과한 browser_run 단계를 Playwright 테스트 파일로 저장하면 페이지가 바뀌기 전까지 모델 호출 없이 재실행할 수 있다.

🧩 주요 포인트

1. API 지원 여부가 작업 경로를 결정한다 → 브라우저는 API가 다루지 못하는 웹 작업을 보완하고, 비공개 localhost 연결은 같은 브라우저 기능을 앱 테스트로 확장한다.
2. scope="thread"와 scope="user"는 세션 격리와 로그인 재사용의 범위를 결정한다 → browser_handoff와 결합하면 사용자가 직접 로그인한 뒤 에이전트가 작업을 이어갈 수 있다.
3. browser_run의 일괄 실행과 필요한 결과만 반환하는 방식은 속도와 컨텍스트 효율을 겨냥한다 → WebVoyager 100개 작업의 90% 성공률·총 $1.98는 해당 평가에서의 성능 근거이며, Playwright 파일 저장은 반복 실행 시 모델 호출을 줄이는 경로다.

🧠 상세 정리

1. 브라우저가 필요한 작업과 적용 범위

여행 예약, 구독 취소, 청구 접수 같은 작업은 사람이 페이지를 클릭하며 이용하도록 만들어진 웹사이트에서 이루어지고, 에이전트가 호출할 API가 없는 경우도 있다. curl로 페이지를 가져오는 것만으로는 JavaScript가 렌더링한 결과를 읽거나 실제 요소를 클릭할 수 없어 한계가 있다. 원문은 Instinct와 Meta의 Muse를 브라우저 활용 사례로 들고, DataDome이 관측한 에이전트 브라우저 요청이 9월 한 달 동안 4.7배 증가했다고 소개한다. 주요 용도는 API가 지원하지 않는 예약 등의 작업과 프런트엔드 변경을 확인하는 엔드투엔드 테스트이며, 작업에 맞는 API가 있다면 이를 사용해야 한다고 명시한다. Managed Deep Agents는 LangSmith가 하네스와 런타임에 더해 브라우저까지 운영하게 하며, 저자 측 코딩 에이전트 Open SWE에서도 브라우저 테스트를 사용한다고 설명한다.

2. 브라우저 추가와 세션 공유 설정

브라우저를 추가하려면 프로젝트 루트의 browser.py에서 define_browser를 호출하고 browser라는 이름으로 내보낸다. 기본 설정인 scope="thread"는 스레드마다 별도 브라우저를 제공하므로, 새 대화는 다른 스레드의 쿠키나 로그인 상태가 없는 창에서 시작한다. scope="user"는 로그인한 사용자의 여러 스레드가 하나의 브라우저를 공유하되 각 스레드에는 별도 창을 제공해, 동시에 진행되는 대화가 서로의 클릭을 방해하지 않도록 한다. 이 경우 쿠키와 다른 브라우저 상태는 공유되므로 한 스레드에서 로그인한 사이트를 이후 스레드에서도 이어서 이용할 수 있다. idle_ttl_seconds는 활동 없이 브라우저를 유지하는 시간을 정하며, 기본값은 600초인 10분으로 사용하지 않는 브라우저에 비용이 계속 발생하지 않도록 중지한다.

3. 로그인을 위한 사용자 핸드오프

원문은 여전히 사람이 처리해야 하는 단계가 있으며, 가장 흔한 예로 로그인을 든다. 비밀번호를 에이전트에게 전달하면 모델 메시지와 트레이스에 남고 모델 제공자에게도 전달될 수 있으므로, 사용자가 브라우저에서 직접 로그인하는 흐름을 제시한다. 에이전트가 로그인 페이지에 도달하면 browser_handoff를 호출하면서 작업을 넘기는 이유를 설명하고, LangSmith Studio에는 같은 브라우저를 조작할 수 있는 대화형 카드가 표시된다. 사용자가 로그인한 뒤 Hand back을 누르면 에이전트는 로그인된 상태에서 중단했던 작업을 이어간다. 이 기능은 모든 관리형 브라우저에 포함되고 Slack 같은 Managed Deep Agents 채널에서도 별도 설정 없이 작동하며, scope="user"에서는 로그인 상태가 이후 스레드에도 유지되어 반복 로그인의 필요성을 줄인다.

4. 분리된 브라우저와 컨텍스트 효율적인 도구

Managed Deep Agents는 브라우저를 에이전트와 분리된 자체 LangSmith sandbox에서 실행하며, 원격 브라우저이므로 사용자 컴퓨터에서 실행되는 구성 요소는 없다. browser_snapshot은 페이지의 접근성 트리를 읽고 상호작용 가능한 요소에 ID를 붙이며, browser_screenshot은 렌더링된 화면을 캡처한다. browser_run은 click과 fill 같은 동작을 묶어 실행하거나 Playwright 스타일의 page 객체를 사용하는 JavaScript를 받아, Stagehand가 자체 명령으로 변환하게 한다. 에이전트는 페이지 열기, 입력, 클릭, 결과 확인을 하나의 호출에 담고 필요한 결과만 반환받을 수 있어 긴 브라우저 작업의 속도와 컨텍스트 사용 효율을 높일 수 있다. browser_handoff는 사람에게 제어권을 넘기는 역할을 맡으며, 이 도구들은 Browserbase의 오픈 소스 브라우저 에이전트 SDK인 Stagehand를 기반으로 한다.

5. 도구 평가 결과와 해석 범위

저자 측은 브라우저 벤치마크 실행, LangSmith 트레이스 분석, 평가를 통한 변경 검증을 반복하는 에이전트 개발 수명주기로 도구를 시험하고 조정했다고 설명한다. 실제 웹사이트의 일상적인 작업을 다루는 WebVoyager에서 100개 작업을 평가한 결과, 해당 도구 세트는 90%의 작업에 성공했고 총비용은 $1.98였다. 이는 비교한 7개 도구 세트 가운데 가장 높은 성공률이며, 가장 근접한 Browserbase MCP 서버는 89%의 성공률을 기록했지만 비용은 9배였다. 이 수치는 원문이 제시한 평가 범위에서 성공률과 비용 효율을 뒷받침하는 근거이며, 모든 웹사이트나 작업에서 같은 결과가 나온다는 주장으로 확장되지는 않는다. 원문은 브라우저 도구를 어떻게 시험하고 조정했는지에 관한 더 자세한 내용을 다음 주 심층 글에서 다룰 예정이라고 예고한다.

6. 비공개 앱 테스트와 반복 실행

예약처럼 API가 지원하지 않는 작업은 브라우저 sandbox가 사이트를 조작하면 되지만, 엔드투엔드 테스트에서는 에이전트 sandbox에서 실행 중인 앱에 브라우저가 접근해야 한다. 이를 위해 에이전트는 브라우저 도구로 브라우저를 제어하고, 브라우저는 별도의 비공개 localhost 브리지를 통해 앱에 연결한다. 예를 들어 localhost:5173 요청은 에이전트 sandbox의 5173번 포트로 전달되므로, 여기서 localhost는 에이전트 sandbox를 뜻하고 앱에 공개 URL을 부여할 필요가 없다. 에이전트는 execute로 앱을 시작한 뒤 가입 양식 같은 실제 흐름을 클릭하며 렌더링 결과를 확인하고, 테스트가 통과하면 각 browser_run 호출을 일반적인 Playwright 스크립트의 일부로 저장하도록 요청할 수 있다. 저장한 테스트는 페이지가 바뀌기 전까지 모델 호출 없이 재실행할 수 있으며, 오픈 소스 Deep Agents에서 브라우저를 사용하려면 Browserbase의 호스팅 브라우저 같은 실행 환경을 직접 마련하는 별도 안내를 따른다.

🧾 핵심 주장 / 시사점

• 브라우저 지원은 에이전트의 작업 범위를 사람이 사용하는 웹 인터페이스로 넓히지만, 원문은 작업을 지원하는 API가 있을 때 API를 우선하는 기준을 유지한다.
• scope="user"의 로그인 재사용과 browser_handoff의 직접 로그인을 결합하면, 사용자가 인증을 맡고 에이전트가 이후 작업을 이어가는 역할 분담이 가능하다.
• browser_run은 모델이 브라우저 작업을 수행하는 단계의 컨텍스트 사용을 줄이고, Playwright 테스트 파일은 검증된 흐름을 반복하는 단계에서 모델 호출을 없애는 서로 다른 효율화 경로를 제공한다.

✅ 액션 아이템

• 대상 웹 작업의 API 지원 여부를 확인하고, API가 지원하지 않는 작업과 엔드투엔드 테스트에 Managed Deep Agents 브라우저 적용을 검토.
• 로그인 재사용 필요에 따라 scope="thread" 또는 scope="user"를 선택하고, browser_handoff와 idle_ttl_seconds 기본값 600초의 적합성을 검토.
• WebVoyager 100개 작업의 90% 성공률·총 $1.98를 평가 근거로 참고하고, 통과한 browser_run 단계의 Playwright 테스트 파일 저장과 재실행을 검토.

❓ 열린 질문

• 대상 웹 작업 중 API가 지원하지 않아 Managed Deep Agents 브라우저가 필요한 작업은 무엇인가?
• 로그인 상태를 이후 대화에서도 재사용해야 하는가, 아니면 scope="thread"의 세션 격리가 필요한가?
• 엔드투엔드 테스트에서 검증한 어떤 사용자 흐름을 Playwright 테스트 파일로 저장해 페이지가 바뀌기 전까지 재실행할 것인가?