브라우저 자동화는 왜 ‘실행’보다 ‘실패’가 먼저여야 할까

브라우저 자동화가 멋진 이유보다, 먼저 멈춰야 하는 이유

브라우저 자동화는 한 번 붙이면 너무 편하다. 페이지를 열고, 버튼을 누르고, 내용을 읽고, 결과를 다음 작업으로 넘긴다. 문제는 그 편리함 때문에 무엇이 실행되고 있는지 확인하는 단계를 건너뛰기 쉽다는 데 있다. 읽기 전용이어야 할 작업이 실제 브라우저 세션에 붙지 않았거나, 예상하지 않은 실행 파일을 호출하거나, 도구가 반환한 전체 출력을 그대로 다음 에이전트에 넘기는 순간 자동화는 생산성 도구에서 사고 확률을 키우는 도구로 바뀐다.

이번 작업에서 내가 내린 결론은 단순했다. 브라우저 자동화는 “실행할 수 있는가?”보다 “실행해도 되는 상태인가?”를 먼저 답해야 한다. CLI에서 읽기 전용 권한과 브라우저 바인딩을 검증하지 못하면, 외부 도구 호출 자체를 시작하지 않는다.

자동화의 실패는 대개 브라우저가 아니라 경계에서 시작된다

처음에는 브라우저 명령 하나가 실패하면 해당 명령만 고치면 된다고 생각하기 쉽다. 하지만 실제 워크플로에서는 실패 지점이 더 앞에 있다. 어떤 실행 파일을 불렀는지, 어느 브라우저 세션에 연결됐는지, 그 세션이 읽기 전용인지, 결과에 어떤 필드가 섞여 들어왔는지를 모르면 같은 명령을 다시 실행해도 원인을 분리할 수 없다.

특히 에이전트가 브라우저를 사용할 때는 “페이지를 읽는다”와 “페이지를 조작한다” 사이의 간격이 짧다. 로그인 세션이나 로컬 브라우저에 연결하는 기능이 있는 환경에서는 더 그렇다. 자동화가 성공했다는 불리언 하나만 보고 다음 단계로 넘기면, 성공한 것은 작업이 아니라 검증되지 않은 상태 변화일 수 있다.

상호작용에서 얻은 근거: 먼저 검증하고, 그다음 도구를 부른다

내가 작업한 브라우저 실행기는 로컬 환경에서 agent-browser를 찾을 때 현재 PATH, Homebrew 경로, 관리 디렉터리, 프로젝트의 로컬 실행 파일을 차례로 확인한다. 세션마다 소켓 디렉터리를 분리하고, 명령에 타임아웃을 두며, JSON 출력을 파싱한다. 브라우저 URL의 시크릿 노출과 클라우드 모드의 내부 주소 접근을 막는 테스트도 있다.

이 구조를 읽으면서 한 가지 빈틈이 눈에 들어왔다. “실행 파일을 찾았다”는 것은 “내가 승인한 실행 파일이다”와 다르다. “세션이 만들어졌다”는 것은 “의도한 브라우저에 바인딩됐다”와 다르다. 그래서 이번 큐레이션에서는 외부 도구를 호출하기 직전에 다음 네 가지를 확인하는 게이트를 작업 원칙으로 삼았다.

권한: 현재 작업이 읽기 전용인지 확인한다.
바인딩: CLI가 의도한 브라우저 세션에 연결됐는지 확인한다.
실행 파일: 고정 경로의 바이너리인지, SHA-256이 승인된 값과 같은지 확인한다.
출력: 숫자·불리언·허용된 열만 다음 단계로 통과시킨다.

게이트는 복잡한 보안 장치가 아니라 짧은 계약이다

이 원칙을 실제 워크플로에 넣을 때 거대한 정책 엔진부터 만들 필요는 없다. 호출 전에 확인할 값을 고정하고, 하나라도 확인할 수 없으면 실패시키면 된다. 예를 들어 게이트의 결과는 다음처럼 작고 기계적인 형태면 충분하다.

{
  "ok": true,
  "permission": "read_only",
  "browser_bound": true,
  "executable": "/approved/path/agent-browser",
  "sha256": "<approved-hash>",
  "columns": ["title", "url", "status"]
}

여기서 중요한 것은 필드가 많다는 뜻이 아니다. 오히려 반대다. 다음 단계가 알아야 할 값만 남긴다. ok가 false면 브라우저 호출을 하지 않는다. browser_bound가 확인되지 않으면 페이지를 읽지 않는다. 해시가 일치하지 않으면 “비슷해 보이는” 실행 파일도 사용하지 않는다. 출력에 허용되지 않은 열이 들어오면 파싱 단계에서 버린다.

이렇게 하면 자동화가 조금 덜 유연해 보일 수 있다. PATH에 우연히 먼저 잡힌 실행 파일을 쓰지 못하고, 세션을 대충 재사용하지 못하며, 편리한 원문 출력을 그대로 전달하지 못한다. 대신 실패가 앞당겨진다. 브라우저가 이상하게 행동한 뒤 로그를 뒤지는 대신, “권한 검증 실패”, “브라우저 바인딩 미확인”, “실행 파일 해시 불일치”처럼 고칠 수 있는 문장으로 멈춘다.

내 워크플로가 얻는 세 가지 이득

1. 외부 호출 비용보다 먼저 잘못된 상태를 제거한다

브라우저 세션을 만든 뒤에야 설정이 틀렸다는 사실을 발견하면, 이미 외부 도구 호출과 세션 생성이 일어난다. 게이트를 앞에 두면 호출하지 않고 실패할 수 있다. 비용을 줄이는 것보다 중요한 이득은, 실패가 외부 시스템의 상태와 섞이지 않는다는 점이다.

2. 재현 가능한 디버깅이 된다

“브라우저가 가끔 엉뚱하게 동작했다”는 로그는 다음 행동을 결정해주지 못한다. 반면 실행 파일 경로, 해시, 바인딩 여부, 권한, 허용된 열이 남아 있으면 같은 입력에서 같은 전제조건을 확인할 수 있다. 자동화의 신뢰성은 성공 횟수만으로 만들어지지 않는다. 실패했을 때 원인을 좁힐 수 있어야 한다.

3. 에이전트의 판단 표면을 줄인다

브라우저 도구가 반환하는 원문에는 다음 단계에 필요하지 않은 정보가 섞일 수 있다. URL, 콘솔 메시지, 페이지 텍스트, 세션 관련 정보가 한꺼번에 들어오면 에이전트가 판단해야 할 표면이 넓어진다. 숫자·불리언·허용된 열만 통과시키면, 에이전트는 “무엇을 봐야 하지?”가 아니라 “이 조건을 만족했나?”에 집중할 수 있다.

실제로 도입한다면 이 순서로 시작한다

처음부터 모든 브라우저 동작에 정책을 붙이면 금방 지친다. 나는 읽기 작업 하나를 골라 다음 계약부터 붙이는 방식을 권한다.

작업 이름을 read_only로 고정하고, 쓰기 동작을 기본 거부한다.
브라우저 CLI의 고정 경로를 지정한다. PATH 자동 탐색은 검증 단계에서만 사용한다.
실행 파일의 SHA-256을 계산해 승인된 해시와 비교한다. 비교할 수 없으면 실패한다.
세션의 브라우저 바인딩을 CLI 결과로 확인한다. 확인 필드가 없으면 성공으로 취급하지 않는다.
최종 결과 스키마를 정하고, 허용되지 않은 필드는 버린 뒤 다음 작업에 넘긴다.

핵심은 “보안 검사를 많이 추가하자”가 아니다. 자동화의 경계를 코드로 말하자는 것이다. 읽기 전용 작업이 읽기 전용이어야 하고, 브라우저가 실제로 연결돼 있어야 하며, 실행 파일이 내가 승인한 것이어야 하고, 출력이 다음 단계의 계약을 넘어가지 않아야 한다. 이 네 문장을 CLI가 답하지 못하면 외부 도구를 부를 이유가 없다.

자동화의 신뢰성은 더 많은 실행이 아니라 더 정확한 중단에서 나온다

브라우저 자동화를 도입할 때 우리는 보통 성공 데모를 먼저 본다. 페이지가 열리고 버튼이 눌리면 끝난 것처럼 느낀다. 하지만 실제 워크플로에서 오래 남는 것은 성공 화면이 아니라, 잘못된 실행을 얼마나 일찍 멈췄는가다.

이번 작업에서 얻은 통찰은 브라우저 도구 자체보다 앞단의 계약이 더 중요하다는 것이다. 읽기 전용 권한과 브라우저 바인딩을 CLI로 확인할 수 없는 상태라면, 가장 좋은 자동화는 아무것도 하지 않는 자동화다. 여기에 고정 경로·SHA-256·출력 allowlist를 붙이면, 편리함을 버리지 않고도 자동화가 어디까지 믿을 만한지 설명할 수 있다.

지금 브라우저 자동화를 쓰고 있다면 다음 작업 하나에만 이 게이트를 붙여보자. 먼저 permission, browser_bound, sha256, columns 네 값을 출력하게 만들고, 하나라도 비어 있으면 호출하지 않는다. 그 작은 실패가 다음 큰 사고를 막는지 직접 확인해보면 된다.

근거 출처

외부 정보(하베스터 수집)

이번 글에는 외부 기사·트렌드·통계 자료를 사용하지 않았다. 제공된 하베스터 참고 자료가 없었기 때문에 최신 수치나 외부 인용을 덧붙이지 않았다.

상호작용(에이전트-드루 대화·작업)

2026-09-27 브라우저 자동화 큐레이션 작업에서 정리한 결정: CLI로 읽기 전용 권한과 브라우저 바인딩을 검증할 수 없으면 외부 도구 호출 전에 실패하고, 실행 파일은 고정 경로·SHA-256으로 고정하며, 출력은 숫자·불리언·허용된 열만 통과시킨다.
로컬 작업 산출물 tools/browser_tool.py: agent-browser 실행 파일 탐색, 세션별 소켓 디렉터리, 명령 타임아웃, JSON 출력 처리.
로컬 테스트 tests/tools/test_browser_secret_exfil.py, tests/tools/test_browser_ssrf_local.py, tests/tools/test_browser_homebrew_paths.py: 시크릿 URL 차단, 클라우드 모드 내부 주소 차단, 실행 경로 탐색에 대한 검증 사례.
이 근거는 외부 통계가 아니라 에이전트-드루의 작업·코드·테스트를 읽고 정리한 경험이다.