Managed Deep Agents v0.10: Browser Use and Async Subagents

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Managed Deep Agents v0.10은 API가 없는 웹사이트를 조작하는 브라우저 기능과 대화를 차단하지 않는 비동기 서브에이전트를 추가하고, 사용자 로그인 인계와 Slack 스레드 연계를 지원한다.

📌 핵심 요약

• 2026년 10월 29일 발표된 Managed Deep Agents v0.10 공개 베타는 브라우저 사용과 async subagents를 추가해, API가 없는 웹사이트에서 작업하고 장기 작업을 백그라운드로 실행할 수 있게 했다.
• 브라우저는 LangSmith sandbox에서 실행되며, 기본적으로 대화마다 분리된다. scope="user"를 선택하면 같은 사용자의 여러 대화에서 로그인 상태를 유지할 수 있고, 로그인이나 2단계 인증은 browser_handoff로 사용자에게 맡겨 비밀번호가 모델 메시지와 추적 기록에 들어가지 않도록 한다.
• async subagents는 별도 스레드에서 실행되어 오케스트레이터가 사용자와 대화를 계속할 수 있게 한다. 작업 시작·상태 확인·수정·취소를 지원하며, 완료 시 직접 알림을 보내고 오케스트레이터의 실행·유휴·승인 대기 상태에 따라 결과 전달 시점이 달라진다.
• runtime.thread는 요청이 시작된 위치와 참여자를 기록해 예약 실행과 서브에이전트의 후속 응답을 원래 Slack 스레드로 연결한다. Slack에는 실행을 취소하는 Stop 버튼이 추가됐고, 실험적 채널 핸들러와 Slack 앱 선택, 발신자를 자체 시스템의 사용자에 연결하는 resolveUser도 지원한다.
• 호환성이 깨지는 변경으로 connectors.mcp()와 connectors/ 구조, sandbox의 scope 옵션이 제거됐다. MCP 서버는 tools/mcp.ts 또는 tools/mcp.py에 선언해야 하며, LANGSMITH_* 변수는 프로젝트 .env보다 셸 환경변수 값이 우선한다.

🧩 주요 포인트

1. 브라우저 조작과 browser_handoff의 결합 → API가 없는 서비스에서 작업을 수행하면서 인증 단계는 사용자가 직접 처리할 수 있다.
2. 비동기 위임과 완료 알림의 결합 → 장기 작업 중에도 대화를 이어가고, 반복 조회 없이 실행 상태에 맞춰 결과를 전달할 수 있다.
3. 원래 Slack 스레드로의 응답 연결과 실행 취소 지원 → 백그라운드 작업의 대화 맥락과 제어가 강화되며, 기존 프로젝트에는 MCP 선언 및 환경설정 변경 대응이 필요하다.

🧠 상세 정리

1. 브라우저가 필요한 이유와 v0.10의 범위

Nathan Drezner와 Sydney Runkle이 2026년 10월 29일 발표한 Managed Deep Agents v0.10은 브라우저 사용과 비동기 서브에이전트를 핵심 기능으로 제시한다. 여행 예약, 구독 취소, 보험금 청구처럼 사람이 페이지를 클릭하는 방식으로 설계된 서비스에는 에이전트가 호출할 API가 없는 경우가 많아, 작업 방법을 추론하더라도 실제 실행에는 한계가 있었다. 원문은 curl로 페이지를 가져와도 JavaScript 실행 전의 HTML만 얻고 클릭할 수 없다는 점을 설명한다. 개인용 에이전트 Instinct와 Meta의 Muse를 브라우저 활용 사례로 들고, DataDome이 관측한 에이전트 브라우저 요청이 9월 한 달 동안 4.7배로 증가했다고 소개한다. 코딩 에이전트에도 앱 변경 사항이 실제로 렌더링되고 작동하는지 확인할 브라우저가 필요하다는 것이 기능 도입의 또 다른 근거다.

2. 브라우저 선언과 도구, 대화별 상태 관리

브라우저를 활성화하려면 프로젝트 루트의 browser.py에서 managed_deepagents의 define_browser를 사용해 브라우저를 선언한다. 예시 설정은 scope="thread"와 idle_ttl_seconds=600이며, Managed Deep Agents는 브라우저를 별도의 LangSmith sandbox에서 실행하고 관련 도구를 에이전트에 자동으로 추가한다. browser_snapshot은 페이지의 접근성 트리를 읽고 요소 ID를 부여하며, browser_run은 JavaScript 또는 스냅샷 ID를 대상으로 한 일괄 동작으로 이동과 상호작용을 수행한다. browser_screenshot은 페이지를 촬영하고 선택적으로 sandbox에 이미지를 저장하며, browser_handoff는 사용자에게 창의 제어권을 넘긴다. 기본 설정에서는 대화마다 브라우저가 하나씩 생성되어 여러 턴에 걸쳐 재사용되지만, 다른 스레드의 쿠키나 로그인 상태 없이 시작한다. scope="user"를 선택하면 로그인한 사용자마다 하나의 브라우저를 사용하고 여러 대화에 걸쳐 로그인 상태를 유지하므로, 같은 사이트에 매번 다시 로그인하도록 요청할 필요가 줄어든다.

3. 로그인과 2단계 인증을 사용자에게 인계

원문은 많은 브라우저 에이전트가 로그인 화면이나 2단계 인증 요청에서 멈춘다는 문제를 제시하고, browser_handoff로 사용자가 직접 인증할 수 있도록 한다. 에이전트는 browser_handoff(reason)를 호출해 도움이 필요한 이유를 설명하며, Slack이나 Studio 같은 채널에는 원격 브라우저를 조작할 수 있는 링크와 Hand back 버튼이 제공된다. 사용자가 로그인한 뒤 제어권을 돌려주면 에이전트는 페이지를 확인해 로그인 성공 여부를 판단하고 작업을 이어간다. 이 방식은 사용자의 비밀번호가 모델 메시지나 추적 기록에 들어가지 않도록 하면서 웹페이지 작업을 계속할 수 있게 한다. 인계 호출은 즉시 반환되므로 에이전트는 사용자를 기다리는 동안 다른 작업을 수행할 수 있고, 인계 링크는 15분 뒤 만료된다. 자체 클라이언트는 인계 아티팩트를 직접 표시할 수 있으며, 브라우저 범위와 실행별 설정, 전체 인계 절차는 관련 문서에서 다룬다.

4. 인라인 서브에이전트에서 비동기 위임으로

서브에이전트는 자체 컨텍스트 창을 가진 보조 에이전트에 집중된 작업을 맡기는 방식이며, 기존 Managed Deep Agents에서는 호출한 에이전트가 답을 기다리는 인라인 실행을 사용했다. 이 방식은 빠른 조회에 적합하고 계속 지원되지만, 오래 걸리는 작업이나 여러 에이전트로 작업을 분산하는 경우에는 사용자가 기다려야 하고 오케스트레이터와의 추가 상호작용도 차단됐다. v0.10에서는 서브에이전트 정의에 async를 True로 지정하면 별도 스레드에서 실행되어 오케스트레이터가 사용자와 대화를 계속할 수 있다. 코드 예시는 define_deep_agent로 research-assistant를 만들고 openai:gpt-5.5 모델과 researcher 서브에이전트를 지정한다. 오케스트레이터는 비동기 작업 도구로 작업을 시작하고 상태를 확인하며, 진행 방향을 수정하거나 취소할 수 있다. 서비스되는 모든 에이전트에는 범용 서브에이전트의 백그라운드 사본도 제공되므로, 위임 작업을 전경과 배경 중 어디에서 실행할지 런타임에 선택할 수 있다.

5. 완료 알림과 실행 상태별 결과 전달

비동기 서브에이전트는 완료 시 스스로 에이전트에 알림을 보내므로, 오케스트레이터가 상태를 반복 조회하는 루프에 머물 필요가 없다. 오케스트레이터가 실행 중이면 각 모델 호출 전에 미완료 작업을 확인해 실행 도중 결과를 전달받고, 유휴 상태이면 서브에이전트가 새 실행을 시작해 오케스트레이터를 깨운다. 사용자 승인을 기다리며 일시 정지한 경우에는 기존 승인 절차를 그대로 유지하고 사용자가 응답한 뒤 결과를 전달한다. 비동기 서브에이전트는 에이전트의 sandbox를 공유하므로 에이전트가 이미 작성한 파일을 이어서 사용할 수 있으며, 해당 실행은 LangSmith에서 상위 에이전트 실행 아래에 표시된다. Slack에서는 서브에이전트의 승인 요청도 원래 스레드에 게시되고, 사용자가 그곳에서 답하면 서브에이전트가 재개된다. 따라서 비동기 실행은 작업을 분리하면서도 파일, 추적 기록, 승인 응답을 기존 작업 맥락에 연결하는 구조로 설명된다.

6. 스레드 출처 유지와 실행 중단

v0.10의 runtime.thread는 각 스레드가 어디에서 시작됐는지와 누가 참여하는지를 기록하며, 도구는 어느 실행에서든 이 정보를 읽을 수 있다. 원문은 Slack 스레드를 출처의 예로 들고, Studio에서 재개한 실행과 예약 실행, 비동기 서브에이전트가 오케스트레이터를 깨워 시작한 실행도 이 정보를 통해 원래 Slack 스레드에 답한다고 설명한다. 이는 최초 요청과 나중에 생성되는 응답을 같은 대화 위치에 연결하는 기능이다. 실행 제어 측면에서는 Slack 스레드에 기본 Stop 버튼이 추가되어 해당 스레드의 실행들을 취소할 수 있다. Studio에서도 Slack 스레드의 실행을 취소할 수 있어, 원문은 대화 출처 유지와 함께 채널을 넘나드는 중단 기능을 소개한다. 도구가 읽을 수 있는 관리 필드의 세부 사항은 runtime 문서에서 확인하도록 안내한다.

7. Slack 이벤트 처리, 앱 선택과 사용자 식별

실험적 Slack 채널 핸들러에서는 onEvent가 멘션, 다이렉트 메시지, 그 밖의 메시지와 버튼 클릭 등 각 이벤트가 무엇을 시작할지 결정한다. status는 실행이 진행되는 동안 Slack에 표시할 상태를 설정하고, reply: "none"은 응답 처리를 에이전트에 맡긴다. 새 Slack 채널을 배포할 때 mda deploy는 어떤 앱을 사용할지 묻고, LangSmith가 생성·관리하는 앱, 매니페스트로 새로 만드는 앱, 이미 보유한 앱 중에서 선택할 수 있다. 사용자 식별 기능인 resolveUser는 Managed Deep Agents가 확인한 채널 발신자를 자체 시스템의 해당 사용자에 연결한다. 이를 통해 도구가 그 사람의 계정과 권한을 조회할 수 있으며, 구현은 함수 또는 호출 가능한 엔드포인트로 제공할 수 있다. resolveUser를 identity 선언에 설정하면 모든 채널에 적용하고, 개별 채널에만 설정하는 방식도 지원한다.

8. 호환성 변경과 공개 베타 시작 방법

v0.10에서는 connectors.mcp()와 connectors/ 디렉터리 구조가 제거되므로 MCP 서버를 tools/mcp.ts 또는 tools/mcp.py에 선언해야 한다. sandbox의 scope 옵션도 제거됐으며, 이는 브라우저 선언에서 사용하는 scope 설정과 구분해야 하는 변경이다. LANGSMITH_* 변수는 프로젝트 .env보다 셸 환경변수 값이 우선하도록 바뀌어, 기존 프로젝트를 이전할 때 선언 위치와 설정 우선순위를 함께 확인할 필요가 있다. Managed Deep Agents v0.10은 발표일 기준 공개 베타로 제공되며, 문서에서 시작하거나 uvx --from managed-deepagents mda init my-agent 명령으로 새 프로젝트를 생성할 수 있다. 이후 cd my-agent로 이동하고 uv run mda deploy로 배포하는 절차를 제시한다. 글의 마지막에는 이전 v0.9에서 에이전트가 생성하는 예약 작업, 실행별 설정, Slack 반응 기능이 추가됐다는 안내도 덧붙인다.

🧾 핵심 주장 / 시사점

• 브라우저 기능은 API가 없는 서비스까지 실행 범위를 넓히고, browser_handoff는 인증이 필요한 순간에 사용자가 직접 개입할 수 있는 연결점을 제공한다.
• async subagents의 효과는 병렬 실행뿐 아니라 대화 지속에도 있다. 완료 알림과 승인 대기 상태별 처리 방식이 장기 작업과 사용자 상호작용을 함께 유지하도록 뒷받침한다.
• runtime.thread와 Stop 버튼은 뒤늦게 도착하는 작업 결과의 위치와 실행 제어를 보완한다. 동시에 MCP 선언 구조와 환경변수 우선순위 변경은 기존 프로젝트의 이전에 영향을 준다.

✅ 액션 아이템

• API가 없는 웹사이트 작업에 브라우저 사용과 browser_handoff를 적용할지 검토하고, 대화별 분리와 scope="user"의 로그인 상태 유지 중 적합한 범위를 선택한다.
• 장기 작업의 async subagents 적용 가능성을 검토하고, 오케스트레이터의 실행·유휴·승인 대기 상태에 따른 결과 전달 동작을 확인한다.
• 기존 connectors.mcp()와 connectors/ 사용을 tools/mcp.ts 또는 tools/mcp.py 선언으로 이전하고, sandbox의 scope 제거와 LANGSMITH_* 환경변수 우선순위 변경을 반영한다.

❓ 열린 질문

• 브라우저를 대화마다 분리하는 기본 설정과 scope="user"로 로그인 상태를 유지하는 설정 중 어떤 범위가 적합한가?
• 어떤 장기 작업에 async subagents를 적용하고, 실행·유휴·승인 대기 상태별 결과 전달을 어떻게 활용할 것인가?
• 기존 프로젝트에서 connectors.mcp(), sandbox의 scope, LANGSMITH_* 환경변수 우선순위 변경의 영향을 받는 부분은 어디인가?