브라우저 세션은 권한의 표면이다

에이전트 데모는 브라우저 사용을 마치 제어(control) 문제처럼 보이게 만듭니다. 에이전트가 페이지를 열 수 있는가? 화면을 이해할 수 있는가? 올바른 버튼을 클릭할 수 있는가? 셀렉터(selector)가 변경되었을 때 복구할 수 있는가? 이것들은 실제적인 문제들입니다. 하지만 이것들이 프로덕션(production) 환경의 문제 전체는 아닙니다. 일단 에이전트가 실제 로그인된 브라우저 세션(browser session)을 사용할 수 있게 되면, 브라우저는 더 이상 단순한 인터페이스가 아닙니다. 그것은 권한의 표면(authority surface)입니다. 이 차이는 매우 중요한데, 브라우저 세션은 중립적인 배관(plumbing)이 아니기 때문입니다. 그 안에는 활성화된 계정, 쿠키(cookies), 관리자 패널(admin panels), 받은 편지함(inboxes), CRM, CMS 대시보드(dashboards), 고객 기록, 결제 페이지, 소셜 계정, 그리고 내부 도구들이 포함되어 있습니다. 해당 환경 내부에서의 클릭은 무해한 탐색일 수도 있습니다. 하지만 그것은 고객에게 전달되는 메시지, 프로덕션의 변이(mutation), 구매, 삭제, 또는 게시가 될 수도 있습니다. 데모에서 브라우저 클릭은 그저 클릭일 뿐입니다. 프로덕션에서 브라우저 클릭은 위임된 권한(delegated authority)이 될 수 있습니다.

데모에서 배포로 넘어가는 간극은 부분적으로 권한의 간극(authority gap)입니다. 많은 에이전트 배포 논의는 오케스트레이션(orchestration), 메모리(memory), 계획(planning), 평가(evaluation), 그리고 모델 품질(model quality)에 집중합니다. 이 모든 것들은 중요합니다. 하지만 인상적인 데모와 안전한 배포 사이의 간극은 종종 더 근본적입니다: 에이전트는 누구로서 행동하는가? 무엇을 보는 것이 허용되는가? 무엇을 변경하는 것이 허용되는가? 어떤 작업에 승인이 필요한가? 작업 후에 어떤 증거가 남는가? 사용자는 어떻게 액세스 권한을 취소하는가? 데모가 샌드박스(sandbox)나 새로운 클라우드 브라우저에서 이루어질 때는 이러한 질문들을 무시하기 쉽습니다. 하지만 워크플로우가 사용자의 실제 로그인된 환경에 의존하게 되면 이러한 질문들은 피할 수 없게 됩니다. 바로 그 지점에 많은 유용한 브라우저-에이전트 워크플로우가 존재합니다: 고객 지원 받은 편지함, 영업 조사, CRM 업데이트, CMS 게시, 파트너 포털, 관리자 대시보드, 금융 도구, 그리고 소셜 계정 등입니다. 이것들은 단순한 웹사이트가 아닙니다. 그것들은 계정의 표면(account surfaces)입니다. 에이전트가 여기에 손을 대는 순간, 제품은 단순한 클릭 루프(click loop)가 아닙니다. 제품은 권한 모델(authority model)이 됩니다. 브라우저 액세스는 단 하나의 권한이 아닙니다. "에이전트에게 브라우저 액세스 권한을 부여하라"는 말은 너무 광범위합니다.

실제 브라우저 워크플로우(workflow)는 여러 가지 서로 다른 권한 계층(authority tiers)을 가집니다: 관찰(Observe) — 페이지 상태, 현재 URL, 가시적 텍스트, 선택된 탭 또는 브라우저 컨텍스트(context)를 읽음. 탐색(Navigate) — 페이지를 열거나, 탭을 전환하거나, URL을 방문하거나, 앱 내에서 이동함. 준비(Prepare) — 초안을 작성하거나, 메시지를 구성하거나, CRM 업데이트를 준비하거나, 변경 사항을 대기열에 추가함. 실행(Execute) — 전송 클릭, 제출, 삭제, 지출, 게시, 승인 또는 업데이트. 위임(Delegate) — 에이전트가 범위가 지정된 정책(scoped policy)에 따라 시간이 지남에 따라 실행을 반복하도록 허용함. 위험은 각 계층마다 달라집니다. 현재 페이지를 읽는 것은 고객 기록을 여는 것과 같지 않습니다. 고객 기록을 여는 것은 그것을 편집하는 것과 같지 않습니다. 초안을 편집하는 것은 전송 버튼을 누르는 것과 같지 않습니다. 만약 권한 모델이 이 모든 것을

만약 에이전트 (Agent)가 실제 브라우저 세션 (Browser session)을 사용할 수 있다면, 만료된 액세스 (Stale access), 광범위한 권한 (Broad permissions), 기록되지 않은 작업 (Unlogged actions), 그리고 빌려온 쿠키 (Borrowed cookies)는 더 빠른 클릭 속도를 가진 오래된 문제들이 되어버립니다. 브라우저 세션은 API 키 (API key)와는 다릅니다. 개발자들은 이미 API 키에 범위 (Scope), 로테이션 (Rotation), 귀속 (Attribution), 그리고 감사 추적 (Audit trails)이 필요하다는 점을 이해하고 있습니다. 브라우저 세션도 동일한 수준의 엄격함이 필요하지만, 훨씬 더 복잡합니다. API 키는 보통 알려진 서비스 경계 (Service boundary)에 매핑됩니다. 반면 브라우저 세션은 수많은 서비스를 가로지릅니다. Gmail, Stripe, Salesforce, Linear, GitHub, WordPress, X, LinkedIn, Notion, 내부 관리 도구, 그리고 그 외에 열려 있거나 로그인되어 있는 무엇이든에 대한 활성 세션을 보유할 수 있습니다. 이는 "그냥 에이전트에게 브라우저를 주라"는 말이 매우 거대한 권한 부여가 되게 만듭니다. 또한 자격 증명 공유 (Credential sharing)가 잘못된 사고 모델임을 의미하기도 합니다. 에이전트에게 비밀번호, 쿠키 저장소 (Cookie jar), 또는 전체 브라우저 프로필을 주는 것은 빌려온 비밀 권한 (Borrowed secret authority)입니다. 그것이 작동할 수는 있지만, 소유권과 정리 (Cleanup)의 경계를 흐립니다. 더 나은 모델은 위임된 권한 (Delegated authority)입니다. 사용자는 자격 증명과 쿠키를 로컬에 유지하고, 에이전트는 브라우저로 향하는 제어된 채널을 얻으며, 작업은 범위가 지정되고 귀속되며, 위험한 단계는 게이트 (Gated)로 차단되고, 작업이 완료되면 액세스를 취소할 수 있습니다. 이것이 BrowserMan의 핵심 관점입니다: 에이전트에게 자격 증명이 아닌 브라우저 세션을 부여하십시오. 실제 Chrome은 판돈을 높입니다. 클라우드 브라우저 (Cloud browsers)는 유용합니다. 샌드박스 (Sandboxes)도 유용합니다. 브라우저 인프라 (Browser infrastructure)도 유용합니다. 하지만 실제 Chrome 프로필은 다른 종류의 객체입니다. 그것은 사용자가 이미 작업하고 있는 웹 환경을 포함합니다: 실제 로그인 상태, 기존 탭, 쿠키, 디바이스 컨텍스트 (Device context), 확장 프로그램 (Extensions), 관리 페이지, 초안, 대시보드, 그리고 절반쯤 완료된 워크플로 (Workflows) 등이 그것입니다. 그것이 바로 실제 브라우저 액세스 (Real-browser access)가 강력한 이유입니다. 이는 API가 잘 다루지 못하고 샌드박스 브라우저가 깔끔하게 재현할 수 없는 작업을 에이전트가 도울 수 있게 해줍니다. 또한 이것이 권한 경계 (Permission boundary)가 중요한 이유이기도 합니다. 로그인된 앱의 스크린샷은 변경 사항을 제출할 수 있는 세션과 같지 않습니다. 페이지 읽기는 버튼 클릭과 같지 않습니다.

일회성 승인된 동작은 장기적인 위임 (delegation)과 같지 않습니다. 브라우저가 실제에 가까워질수록 권한 모델 (authority model)은 더 명시적이어야 합니다.

좋은 브라우저 위임이 답해야 할 것들

실제 운영되는 브라우저 에이전트 (browser-agent) 워크플로우는 몇 가지 지루한 질문에 답할 수 있어야 합니다: 에이전트가 어떤 브라우저, 계정, 또는 세션을 사용하고 있는가? 무엇을 읽을 수 있는가? 무엇을 변경할 수 있는가? 어떤 동작이 승인을 필요로 하는가? 승인 후에 어떤 일이 일어났는가? 동작 후에 어떤 영수증 (receipt)이 존재하는가? 사용자가 향후 액세스를 어떻게 취소 (revoke)할 수 있는가? 이러한 질문들은 단순한 보안 쇼 (security theater)가 아닙니다. 이것들이 바로 브라우저 에이전트가 운영상 사용 가능해지는 방식입니다.

예를 들어, 영업 에이전트는 아마도 낮은 마찰 (low friction)로 잠재 고객을 조사하고 연락 초안을 작성할 수 있어야 할 것입니다. 명확한 전송 게이트 (send gate) 없이 실제 계정에서 조용히 메일을 보내서는 안 됩니다. 전송 버튼은 권한 경계 (permission boundary)입니다. 고객 지원 에이전트는 티켓을 읽고 답장을 준비할 수 있습니다. 환불을 처리하거나, 데이터를 삭제하거나, 계정 설정을 변경하는 것은 다른 단계 (tier)여야 합니다. CMS 어시스턴트는 기사 초안을 작성하고 메타데이터를 채울 수 있습니다. 공개적으로 게시하는 것은 영수증을 남겨야 합니다. CRM 어시스턴트는 회사 기록을 보강할 수 있습니다. 대량 업데이트는 미리보기와 롤백 (rollback) 시나리오가 있어야 합니다. 이것은 모든 워크플로우를 느리게 만드는 것에 관한 것이 아닙니다. 권한이 바뀌는 지점에 마찰을 두는 것에 관한 것입니다.

권한 경계가 곧 제품이다

클릭 루프 (click loop)는 눈에 보이기 때문에 감탄하기 쉽습니다. 에이전트가 탐색하고, 읽고, 클릭하고, 작업을 완료합니다. 권한 경계는 덜 화려하지만, 실제 운영 환경에서 중요한 제품의 표면 (product surface)입니다. 좋은 브라우저 에이전트 시스템은 다음을 분리해야 합니다: 관찰 가능한 상태 (observable state), 탐색 명령 (navigation commands), 단계별 변경 사항 (staged changes), 부수 효과 실행 (side-effect execution), 승인 게이트 (approval gates), 영수증 (receipts), 취소 (revoke). 이러한 분리는 사용자가 집 전체를 넘겨주지 않고도 실제 업무를 위임할 수 있게 해줍니다. 또한 브라우저 자동화를 더 신뢰하기 쉽게 만듭니다. 무언가 잘못되었을 때, 사용자가 느낌 (vibes)만으로 세션을 재구성해야 하는 상황이 발생해서는 안 됩니다.

사용자는 에이전트가 무엇에 접근할 수 있는지, 무엇을 수행했는지, 그리고 어떤 지점에서 작업이 준비 (preparation) 단계에서 실행 (execution) 단계로 넘어갔는지 알아야 합니다. BrowserMan의 경로 BrowserMan은 AI 에이전트를 위한 위임된 실제 브라우저 접근 (delegated real-browser access)을 중심으로 구축되었습니다. 핵심은 모든 에이전트가 항상 사용자의 실제 Chrome을 사용해야 한다는 것이 아닙니다. 많은 작업은 샌드박스 (sandbox), 원격 브라우저 (remote browser), 또는 일반적인 API에서 수행하는 것이 더 낫습니다. 핵심은 일부 가치 있는 워크플로우 (workflows)가 사용자의 실제 로그인된 브라우저 상태 (browser state)에 의존한다는 점입니다. 그러한 경우, 브라우저 세션은 권한 (authority)이며, 이는 의도적으로 위임되어야 합니다. BrowserMan의 카테고리는 "탐지 불가능한 브라우저 자동화 (undetectable browser automation)"가 아닙니다. 그것은 제어된 브라우저 권한 (controlled browser authority)입니다. 즉, 에이전트는 사용자의 실제 Chrome을 사용할 수 있고, 쿠키는 로컬에 유지되며, 에이전트는 명령을 전달하는 호스팅된 릴레이 (hosted relay)를 통해 어디서든 실행될 수 있고, 접근 권한은 범위 지정 (scoped), 속성 부여 (attributed), 취소 (revoked)가 가능하며, 위험한 작업에는 가시적인 게이트 (gates)와 영수증 (receipts)이 있어야 합니다. 이것이 데모로서의 브라우저 제어와 운영 계층 (operational layer)으로서의 브라우저 위임 사이의 차이점입니다. 실질적인 규칙: 에이전트가 읽기만 한다면 속도에 최적화하십시오. 에이전트가 준비 중이라면 검토 (review)에 최적화하십시오. 에이전트가 실제 계정으로부터 제출, 게시, 삭제, 지출 또는 메시징을 수행한다면 권한 (authority)에 최적화하십시오: 범위 지정 (scope), 승인 (approval), 영수증 (receipt), 취소 (revoke). 브라우저 세션은 단순한 인터페이스가 아닙니다. 그것은 위임된 권한입니다. 그렇게 다루십시오.