Runtime Snapshots #17 — BaSS: 공유 공간으로서의 브라우저 (Browser-as-Shared-Space)

#16은 단일 에이전트가 페이지를 인식하는 방식 — 시각 (Vision), 접근성 트리 (Accessibility tree), 또는 런타임 구조적 인식 (Runtime structural perception) — 에 관한 것이었으며, 사용자가 사용자일 때 왜 세 번째 방식이 승리하는지에 대해 다루었습니다. 이번 포스트는 그 아래에 있는 축, 즉 아무도 명명하지 않은 부분에 관한 것입니다. 에이전트가 페이지를 어떻게 보느냐가 아니라, 얼마나 많은 것들이 동시에 그것을 보고 있느냐에 대한 이야기입니다.

오늘날 그 답은 '하나'입니다. 브라우저당 하나의 드라이버입니다. 이 가정은 너무나 깊게 박혀 있어서 보이지 않을 정도이며, 바로 다음에 무너질 부분입니다.

하나의 드라이버는 법칙이 아니라 설계 결정입니다

#16에서 다룬 세 가지 인식 아키텍처를 살펴보고 그들이 공유하는 점을 주목해 보세요. 시각 (Vision) 방식은 에이전트가 소유한 헤드리스 브라우저 (Headless browser)를 실행합니다. 접근성 트리 (Accessibility-tree) 에이전트는 DevTools Protocol을 통해 Chromium 인스턴스를 제어하며, 이 역시 에이전트의 것입니다. 두 방식 모두 브라우저는 1인용 차량과 같습니다. 에이전트가 탑승하고, 운전하고, 내립니다. 인간은 차에 타고 있지 않습니다. 다른 어떤 에이전트도 마찬가지입니다.

런타임 구조적 인식 (Runtime structural perception)은 이들과 다른 이질적인 방식이며, 그 차이점이 바로 이 포스트의 핵심입니다. 이 방식은 사용자의 자체 브라우저 — 이미 로그인된 실제 세션 — 의 주변 장치로서 작동합니다. 이는 이 방식이 읽어들이는 표면이 구조적으로 이미 누군가가 사용 중인 표면임을 의미합니다. 인간이 바로 그곳에 있습니다. 에이전트는 브라우저를 조작하는 것이 아니라, 동일한 브라우저를 조작하고 있는 것입니다.

이것이 사실이 되는 순간, "하나의 드라이버"는 제약 사항이 아니라 선택 사항이 됩니다.

BaSS: 공유 공간으로서의 브라우저 (Browser-as-Shared-Space)

이를 BaSS — Browser-as-Shared-Space(공유 공간으로서의 브라우저)라고 부릅시다.

이 주장은 말하기에는 간단하지만 결과는 거대합니다. 브라우저 탭은 한 명의 드라이버를 위한 조종석이 아닙니다. 그것은 여러 참여자가 동시에 점유할 수 있는 표면입니다. 당신, 한 에이전트, 그리고 다른 벤더의 두 번째 에이전트가 각각 단순히 "페이지"를 다루는 것이 아니라, 동일한 라이브 DOM 상에서 동일한 시간에 안정적인 ID를 통해 개별 요소들을 다루는 것입니다.

표면(surface): 결제 (live, 인증된 세션)
el#a17  "주문하기"   [button]
  · 인간         — 호버링 중, 아직 확정하지 않음
...

그것은 "브라우징하는 에이전트"와는 다른 프리미티브 (primitive)입니다. 브라우징하는 에이전트는 혼자입니다. BaSS는 공동 현존 (co-presence)입니다. 즉, 여러 명의 커서가 하나의 파일을 편집하는 공유 문서처럼, 인간과 다수의 에이전트가 하나의 라이브 상태 (live state)를 공유하는 것입니다. 다만 그 문서가 당신이 실제 작업 중인, 실제 인증 정보(credentials)를 가진 라이브 웹 앱이라는 점이 다를 뿐입니다.

왜 세 가지 모델 중 단 하나만이 이를 호스팅할 수 있는가

이 부분이 아키텍처 측면에서 중요한 지점입니다. 세 가지 인지 모델 중 오직 런타임 구조적 인지 (runtime structural perception)만이 BaSS를 호스팅할 수 있습니다. 이는 단순히 기술적 영리함 때문이 아니라, 구조적 설계 (construction) 때문입니다.

비전 (Vision) 에이전트와 접근성 트리 (accessibility-tree) 에이전트는 각각 자신만의 브라우저를 인스턴스화 (instantiate) 합니다. 각 참가자가 자신만의 브라우저를 가져오기 때문에 공유된 표면 (shared surface)이 존재하지 않습니다. 두 명의 에이전트와 한 명의 인간을 "같은 장소"에 두려면, 그 장소는 이미 존재해야 하고 이미 점유되어 있어야 합니다. 이것이 바로 세션 내 주변 장치 (in-session peripheral)가 하는 역할이며, 헤드리스 인스턴스 (headless instance)가 할 수 없는 일입니다. 격리된 브라우저들에 조정 (coordination) 기능을 덧붙일 수는 있겠지만, 그렇게 되면 세션 내 모델이 공짜로 얻는 공유 표면을 소프트웨어로 다시 구축해야 하는 셈이 됩니다.

따라서 BaSS는 아무 브라우저 에이전트에나 뿌릴 수 있는 기능이 아닙니다. 이는 이미 사용자의 실제 세션 내부에 자리 잡고 있는 아키텍처에만 가능합니다. #16에서는 런타임 구조적 인지가 비용, 인증, 그리고 실제 앱 커버리지 측면에서 승리한다고 주장했습니다. 이것은 네 번째 이유이자, 가장 긴 여파를 남기는 이유입니다. 그것은 바로 공유될 수 있는 유일한 모델이라는 점입니다.

어려운 점은 권한이 아니라 공존이다

본능적으로 우리는 이것을 접근 제어 (access control), 즉 누가 어떤 순서로 행동할 수 있는지의 문제로 모델링하려 합니다. 그것은 잘못된 프레임입니다. BaSS에는 계층도 없고 게이트도 없습니다. 참가자들은 모두 평등합니다. 실제 어려운 문제는 공존 (coexistence)입니다. 실제 DOM에 존재하는 대부분의 것들 — 당신, 외부 스크립트, 혹은 사이트 자체가 실행하는 어떤 자동화 도구든 — 은 어떤 프로토콜이 존재하는지조차 알지 못합니다. 질문은 "누가 들어올 수 있는가"가 아닙니다. "사전에 조율되지 않은 공간에서 독립적인 행위자들이 서로 방해하지 않고 어떻게 공간을 공유할 것인가"입니다.

그것은 누구의 소유도 아닌 표면 위에서 발생하는 동시성 문제 (concurrency problem)입니다. 바로 이 지점이 흥미로운 부분이며, 엔지니어링의 대부분을 차지합니다.

무엇이 출시되었고, 무엇이 며칠 뒤에 나올 것인가

이 시리즈를 읽는 분들은 실제로 무언가를 만드는 분들이기에, 상태에 대해 솔직하게 말씀드리겠습니다.

기반 구조 (substrate)는 이미 프로덕션 환경에 있습니다. 런타임 구조적 인지 (Runtime structural perception, #16 방식), 이를 MCP를 통해 노출하는 릴레이 (relay), 그리고 사용자의 실제 인증된 브라우저 내부에서 작동하는 단일 에이전트의 인지 및 행동 (perceive-and-act) 기능은 이미 출시되어 실행 중입니다. 우리는 이미 서로 다른 벤더의 두 에이전트가 릴레이를 통해 하나의 공유 장바구니에서 작동하는 것을 확인했으며, 이는 '공유'라는 부분이 단순한 슬라이드(겉치레)가 아니라는 가장 작고 정직한 증거입니다.

전체 BaSS 레이어 — 하나의 표면 위에 다수의 참여자가 존재하고, 이들 모두를 아우르는 요소 수준의 주소 지정 (element-level addressing), 그리고 이들이 서로 방해하지 않도록 유지하는 공존 로직 (coexistence logic) — 는 현재 활발히 개발 중이며 출시까지 며칠 남지 않았습니다. 이 포스트는 실제 제품이 나오기 직전에 개념을 착륙시키는 단계입니다. 다음 스냅샷이 바로 그 제품 자체가 될 것입니다.

e2llm.com

이 글은 Runtime Snapshots 시리즈의 17번째 파트입니다. 구조화된 브라우저 데이터가 우리가 소프트웨어를 구축, 테스트 및 출시하는 방식을 어떻게 변화시키는지 탐구합니다. #16에서는 에이전트가 페이지를 볼 수 있는 세 가지 방식을 매핑했습니다. 이번 편은 둘 이상의 에이전트가 동시에 같은 페이지를 보고 있을 때 어떤 일이 발생하는지에 관한 것입니다.

만약 동일한 라이브 페이지에 대해 두 개의 에이전트를 실행해 보셨다면, 가장 먼저 충돌이 발생한 지점은 어디였나요?