브라우저 자동화는 늘 현실 웹과 부딪힙니다. 로그인, 2FA, 캡차, 쿠키 동의, 지역별 배너, 결제 확인, 관리자 권한 프롬프트, 예상 못 한 modal 하나가 전체 run을 멈춥니다. 예전 방식은 대체로 셋 중 하나였습니다. 실패 처리하고 사람이 처음부터 다시 한다. Live View URL을 따로 공유하고 script가 완료 여부를 polling한다. 또는 더 위험하게, 자동화가 사람 판단이 필요한 화면을 우회하려고 한다. structured handoff는 이 지점을 “예외"가 아니라 workflow state로 승격합니다.

이 글은 Managed Browser Worker, Agent Handoff Packet, Agent Sandbox Handoff Attack Surface, Review Ops Unified Human Gate와 이어집니다. 이전 글들이 브라우저 worker, handoff, host 신뢰 경계, 사람 승인 체계를 각각 봤다면, 오늘 신호는 그중 브라우저 실행 표면에서 사람 개입을 어떻게 구조화할지를 보여 줍니다.

참고한 공식 신호:

• Cloudflare Changelog, Browser Run adds structured handoff for Human in the Loop: https://developers.cloudflare.com/changelog/
• Cloudflare Changelog, Cloudflare MCP servers support the new MCP 2026-07-28 Specification: https://developers.cloudflare.com/changelog/
• GitHub Changelog, GitHub MCP Server supports the next MCP specification: https://github.blog/changelog/2026-07-23-github-mcp-server-supports-the-next-mcp-specification/

이 글에서 얻는 것

• 브라우저 에이전트에서 사람 개입이 왜 단순 fallback이 아니라 pause/resume 계약인지 이해합니다.
• 로그인, 2FA, 권한 동의, 결제 확인을 같은 handoff로 보면 안 되는 이유를 정리합니다.
• structured handoff에 필요한 instruction, timeout, completion event, audit evidence, next action 제한 기준을 가져갑니다.
• 브라우저 자동화 도입 시 handoff 성공률과 재개 후 실패율을 운영 지표로 보는 체크리스트를 만들 수 있습니다.

핵심 개념/이슈

1) 브라우저 자동화의 실패 지점은 대부분 “사람 판단” 근처에 있다

브라우저 agent가 단순 scraping이나 테스트 탐색만 한다면 실패는 selector 변경, 느린 렌더링, 네트워크 오류 정도일 수 있습니다. 하지만 실제 업무 자동화로 들어가면 달라집니다. 사내 SaaS 로그인, 고객 포털 2FA, 권한 동의, 결제 확인, 파일 다운로드 경고, 개인정보 열람 안내처럼 사람이 판단하거나 직접 인증해야 하는 단계가 계속 나옵니다.

이 단계들은 자동화 품질이 낮아서 생기는 버그가 아닙니다. 의도적으로 사람에게 맡겨야 하는 통제 지점입니다. 그래서 좋은 브라우저 agent는 모든 화면을 자동 통과하려는 agent가 아니라, 어디서 멈추고 누구에게 무엇을 요청해야 하는지 아는 agent에 가깝습니다.

2) URL 공유와 polling은 handoff 계약이 아니다

기존에도 사람 개입은 가능했습니다. 원격 브라우저 URL을 보여주고, 사람이 로그인한 뒤 “끝났어요"를 누르거나, script가 cookie 변화를 polling하는 식입니다. 문제는 이 방식이 운영 계약으로 약하다는 점입니다.

빠지는 정보가 많습니다.

• agent가 왜 멈췄는가
• 사람은 어떤 화면에서 무엇만 해야 하는가
• timeout이 지나면 중단할지 재요청할지
• 사람이 한 action의 증거는 어디에 남는가
• 완료 후 agent가 바로 이어서 할 수 있는 action은 어디까지인가
• 실패했을 때 retry인지 escalation인지 누가 판단하는가

structured handoff는 이 정보를 protocol event와 runtime state로 올립니다. Cloudflare 예시는 CDP command로 Live View URL을 얻고, handoff를 요청하며, handoffComplete 이벤트를 기다리는 구조를 보여 줍니다. 핵심은 코드 모양이 아니라 agent가 멈춘 상태와 재개 조건을 런타임이 이해한다는 점입니다.

3) Handoff는 승인과 다르다

로그인을 사람이 해 줬다고 해서 agent가 이후 모든 버튼을 눌러도 된다는 뜻은 아닙니다. 이 구분이 중요합니다. handoff는 사람이 어떤 막힌 단계를 처리해 agent가 계속 진행할 수 있게 하는 절차입니다. 승인은 되돌리기 어려운 action을 해도 된다는 별도 판단입니다.

예를 들어 내부 관리자 포털에서 주문 상태를 확인하는 workflow를 생각해 보겠습니다.

이 차이를 놓치면 “사람이 한 번 봤으니 괜찮다"는 위험한 자동화가 됩니다. 특히 브라우저 화면은 버튼의 의미가 UI 문구와 계정 권한에 따라 바뀌기 때문에, 로그인 handoff와 final action approval을 분리해야 합니다.

4) Handoff packet은 짧고 실행 가능해야 한다

사람에게 넘길 instructions는 길수록 안전한 것이 아닙니다. 오히려 길면 operator가 핵심을 놓칩니다. 좋은 handoff instruction은 세 가지를 담습니다.

handoff_request:
  reason: "SSO login required"
  operator_instruction: "회사 SSO로 로그인만 완료하고, 이후 화면에서는 아무 버튼도 누르지 마세요."
  allowed_actions: ["enter_credentials", "complete_2fa"]
  blocked_actions: ["change_settings", "submit_payment", "download_customer_data"]
  timeout_seconds: 600
  resume_condition: "dashboard URL visible"
  evidence: ["screenshot_before", "handoff_started_at", "operator_id"]

이 구조는 Agent Handoff Packet의 브라우저 버전입니다. 긴 대화 로그를 넘기는 것이 아니라, 지금 사람이 판단해야 할 최소 상태와 금지 범위를 넘깁니다.

5) MCP stateless 흐름과도 같은 운영 방향이다

Cloudflare의 같은 changelog에는 MCP 2026-07-28 사양 지원도 함께 올라왔습니다. product-specific MCP servers가 protocol session 없이 fresh stateless server에서 요청을 처리하고, /mcp endpoint 중심으로 연결하는 흐름입니다. GitHub MCP Server도 7월 23일에 다음 MCP specification 지원을 알리며 stateless core, session/init 제거, conformance test를 언급했습니다.

브라우저 handoff와 MCP stateless는 표면은 다르지만 운영 방향은 닮았습니다. 긴 암묵 세션에 기대기보다 요청, 상태, 재개 조건, 검증 가능성을 더 명시적으로 만드는 흐름입니다. 에이전트 시스템이 커질수록 “어딘가에 세션이 살아 있겠지"는 약한 가정이 됩니다. pause/resume, stateless request, conformance test, completion event 같은 장치가 필요한 이유입니다.

실무 적용

1) Handoff taxonomy를 먼저 만든다

브라우저 automation을 도입할 때 모든 사람 개입을 같은 버튼으로 처리하면 안 됩니다. 아래처럼 최소 네 단계로 나눕니다.

도입 초기에는 H2와 H3을 확실히 나누는 것만으로도 사고 위험이 크게 줄어듭니다. 로그인은 사람이 도와줄 수 있지만, 로그인 뒤의 고위험 버튼은 별도 승인입니다.

2) Timeout과 재개 조건을 숫자로 둔다

handoff는 무한 대기하면 안 됩니다. 세션이 오래 열려 있으면 credential 노출, stale page, lock 점유 문제가 생깁니다. 초기값은 이렇게 둘 수 있습니다.

• 쿠키 동의, 단순 modal: 2분
• 일반 로그인/2FA: 5~10분
• 관리자 권한 확인: 3~5분
• 결제/삭제/외부 전송 승인: 자동 재개 금지, 별도 승인 ticket 필요
• handoff 실패 후 자동 재시도: 1회 이하
• 같은 계정의 handoff 동시 실행: 기본 1개

재개 조건도 구체적이어야 합니다. “사람이 끝났다고 함"보다 “dashboard URL이 보임”, “account menu가 렌더링됨”, “download button이 보이지만 클릭하지 않음"처럼 agent가 확인 가능한 조건이 낫습니다.

3) Handoff 이후 action boundary를 줄인다

사람이 개입한 직후가 가장 위험할 수 있습니다. agent는 새 권한과 새 화면을 얻었고, context에는 사용자가 처리한 민감 단계가 있습니다. 따라서 handoff 후에는 action boundary를 다시 계산해야 합니다.

post_handoff_policy:
  allowed:
    - read_visible_data
    - navigate_within_same_app
    - export_non_sensitive_summary
  requires_approval:
    - submit_form
    - download_file
    - send_external_message
    - change_permission
  blocked:
    - reveal_password
    - store_2fa_code
    - bypass_security_prompt

이 정책은 Review Ops Unified Human Gate와 연결됩니다. 사람의 개입은 자동화의 빈칸을 채우는 것이지, 이후 모든 action을 승인하는 만능 표가 아닙니다.

4) 관측 지표를 workflow 지표로 둔다

브라우저 handoff는 성공/실패만 보면 부족합니다.

• handoff_requested_count
• handoff_success_rate
• handoff_wait_p95
• handoff_timeout_rate
• resume_after_handoff_failure_rate
• post_handoff_blocked_action_count
• operator_intervention_by_reason
• sensitive_input_exposure_count
• manual_rework_after_agent_resume_rate

특히 resume_after_handoff_failure_rate가 중요합니다. 사람이 로그인까지 했는데 agent가 다음 화면에서 바로 실패한다면 handoff instruction이나 재개 조건이 부정확한 것입니다. post_handoff_blocked_action_count가 자주 발생하면 workflow 설계가 고위험 action을 너무 자연스럽게 이어 붙이고 있다는 신호입니다.

트레이드오프/주의점

첫째, structured handoff는 자동화율을 낮추는 것처럼 보일 수 있습니다. 하지만 로그인 벽을 억지로 우회하거나 실패한 run을 사람이 처음부터 다시 하는 비용을 생각하면, 명시적 handoff가 오히려 전체 처리 시간을 줄일 때가 많습니다. 기준은 자동화율이 아니라 완료율, 재작업률, 사고 위험입니다.

둘째, 사람이 브라우저에 들어오는 순간 privacy와 credential boundary가 생깁니다. operator가 보는 화면, 입력하는 값, agent가 이후 읽을 수 있는 DOM 범위를 제한해야 합니다. 가능하면 테스트 계정, scoped role, short-lived session, read-only 권한부터 시작합니다.

셋째, handoff instructions가 모호하면 사람이 agent보다 더 큰 위험을 만들 수 있습니다. “로그인해 주세요"보다 “SSO 로그인만 완료하고 이후 설정 변경 화면에서는 아무 것도 누르지 마세요"가 낫습니다. blocked action을 명시해야 합니다.

넷째, 고위험 action은 handoff가 아니라 승인입니다. 결제, 삭제, 권한 변경, 외부 전송은 사람이 잠깐 브라우저를 조작했다는 이유로 자동 진행되면 안 됩니다. 이 범위는 agent policy와 UI 권한 양쪽에서 막는 편이 안전합니다.

체크리스트 또는 연습

• 브라우저 agent workflow에서 사람이 필요한 단계를 H0~H3으로 분류했다.
• handoff request에는 reason, instruction, allowed action, blocked action, timeout이 있다.
• handoff 완료 후 agent가 바로 할 수 있는 next action이 제한된다.
• 로그인 handoff와 결제/삭제/권한 변경 승인을 분리한다.
• handoff wait p95, timeout rate, resume failure rate를 측정한다.
• operator id, 시작/완료 시각, before/after screenshot 또는 equivalent evidence가 남는다.
• 민감 입력은 저장하지 않고, session TTL과 계정 권한을 좁게 둔다.

연습은 간단합니다. 현재 팀에서 브라우저로 반복하는 운영 작업 하나를 고르세요. 예를 들어 파트너 포털에서 주문 상태를 확인하거나, 클라우드 콘솔에서 사용량 리포트를 내려받는 작업이면 충분합니다. 그 workflow를 자동 단계, 사람 handoff 단계, 별도 승인 단계 세 칸으로 나누고, handoff timeout과 blocked action을 적어 봅니다. 마지막으로 handoff 후 agent가 외부 전송이나 설정 저장 버튼을 누르지 못하게 하는 규칙을 하나 넣습니다. 이 작업을 하면 브라우저 자동화가 단순 스크립트가 아니라 운영 런타임으로 보이기 시작합니다.