🧩 Runtime Snapshots #18 - 구조화된 런타임 인지 (Runtime Perception): 에이전트에게 부족한 계층

지난 세 번의 Runtime Snapshots 포스트는 하나의 스택을 쌓아왔습니다. #15에서는 당신의 에이전트가 눈이 멀어 있으며 눈과 손이 필요하다고 말했습니다. #16에서는 에이전트가 볼 수 있는 세 가지 방법인 시각 (vision), 접근성 트리 (accessibility tree), 그리고 런타임 인지 (runtime perception)를 명시했습니다. #17에서는 둘 이상의 에이전트가 동일한 라이브 브라우저 공간을 공유할 때 어떤 일이 발생하는지 물었습니다. 이번 포스트는 이 모든 것의 밑바닥에 있는, 이전 포스트들이 답이 정해져 있다고 가정했던 질문으로 들어갑니다: 에이전트가 행동하기 직전 0.5초 동안 실제로 무엇을 인지하는가?

아무도 언급하지 않는 비대칭성

대부분의 브라우저 에이전트 실패는 모델의 실패로 분류됩니다. 모델이 잘못된 버튼을 클릭했거나, 메뉴를 놓쳤거나, 잘못된 필드를 채웠거나, 페이지가 로드되지 않았는데 로드되었다고 생각했거나, UI가 변경되었을 때 복구하지 못한 경우입니다. 때로는 그 진단이 맞을 수도 있습니다. 하지만 종종 모델은 잘못된 표면 (surface)을 전달받고 그로부터 추론하도록 요구받은 것입니다.

여기서 생략되는 부분이 있습니다: 에이전트는 사람이 실패하는 방식과는 다르게 실패합니다. 당신은 탭을 열고 페이지가 명시적으로 말하지 않는 모든 것들을 조용히 보완합니다. 클릭하지 않을 회색 처리된 버튼, 기다려야 함을 알려주는 여전히 돌아가고 있는 스피너 (spinner), 아래에 있는 요소가 아직 활성화되지 않았음을 알 수 있게 해주는 페이지 위의 모달 (modal) 같은 것들 말이죠. 당신은 렌더링된 페이지를 바라보는 인간으로서 이러한 연속성을 공짜로 얻습니다. LLM은 그 중 어느 것도 공짜로 얻지 못합니다. LLM은 우리가 전달해 주는 표현 (representation)만을 정확히 전달받으며, 그 외에는 아무것도 얻지 못합니다. 따라서 표현 (representation)이 게임의 전부입니다.

세 가지 표면, 그 중 어느 것도 애플리케이션이 아니다

브라우저는 스크린샷도 아니고, 접근성 트리 (accessibility tree)도 아니며, 가공되지 않은 DOM (raw DOM)도 아닙니다. 그것들은 애플리케이션의 '뷰 (views)'일 뿐입니다. 유용하긴 하지만, 여전히 뷰에 불과합니다. 모델에게 픽셀을 주면 외형으로부터 상태를 추론합니다. 저 버튼이 비활성화된 것인지, 아니면 그냥 회색인 것인지 말이죠. 모델에게 접근성 트리를 주면 보조 기술 (assistive technology)을 위해 구축된 구조를 읽게 되는데, 현대의 웹 앱들은 이를 불완전하거나 일관성 없게 채우는 경우가 많습니다. 모델에게 가공되지 않은 DOM을 주면 모델은 정보의 홍수에 빠져버립니다. 프레임워크의 잔재 (framework residue), 오래된 노드 (stale nodes), 숨겨진 브랜치 (hidden branches), 생성된 식별자 (generated identifiers), 중복된 텍스트, 마크업에는 존재하지만 사용자의 현재 경험에는 존재하지 않는 요소들까지 말입니다.

문제는 이러한 표면들이 쓸모없다는 것이 아닙니다. 그것들은 유용합니다. 문제는 그중 어느 것도 애플리케이션 그 자체는 아니라는 점입니다. 부족한 것은 에이전트가 행동해야 하는 바로 그 순간, 라이브 페이지로부터 구축된 표현 (representation)입니다.

누락된 계층에는 이름이 있습니다

그 계층은 바로 구조화된 런타임 인지 (structured runtime perception)입니다. (#16에서는 이를 런타임 구조적 인지 (runtime structural perception)라고 불렀으나, 이후 이 명칭으로 정착되었습니다.) 구조화된 런타임 스냅샷 (structured runtime snapshot)은 액션 루프 (action loop)가 실제로 던지는 질문들에 답합니다. '지금 당장 무엇을 볼 수 있는가?', '지금 당장 무엇에 대해 행동할 수 있는가?', '무엇이 비활성화되었거나, 숨겨졌거나, 가려졌거나, 로딩 중이거나, 오래되었는가?', '다음 액션 이후에도 유지될 요소의 식별자 (element identities)는 무엇인가?', '어떤 텍스트가 작업(task)이고 어떤 것이 내비게이션(nav), 크롬(chrome), 프레임워크 잔재인가?', '마지막 단계 이후 무엇이 변했는가?'

구체적으로, 이는 HTML이 말하는 것과 페이지의 실제 상태 사이의 간극을 메워줍니다:

form#login (action=/auth)
  input[email]      "user@example.com"
  input[password]   required
...

비활성화된 제출(submit) 버튼과 아직 보이지 않는 에러는 다음 동작이 실제로 효과를 거둘 수 있을지를 결정하는 바로 그러한 종류의 상태입니다. 이러한 상태들은 픽셀 단위로는 모호하고, 얇은 접근성(accessibility) 뷰에서는 불완전하거나 신뢰할 수 없는 경우가 많으며, 가공되지 않은 DOM(Document Object Model)에서는 존재하지만 노이즈가 심합니다. E2LLM에서 사용하는 SiFR(Structured Interface Representation, 구조화된 인터페이스 표현)은 모든 관련 노드에 접근할 수 있도록 해당 상태를 압축하여 전달하므로, 모델이 의도하는 요소를 정확히 지칭할 수 있습니다. 이것이 바로 "모델이 페이지를 보았다"와 "모델이 사용 가능한 상태 표현(state representation)을 전달받았다" 사이의 실질적인 차이입니다.

브라우저 세션이 중요한 이유

구조화된 런타임 인지(Structured runtime perception)는 사용자의 실제 브라우저 세션과 나란히 실행됩니다. 즉, 이미 인증되었고 사용자가 이미 보유한 것과 동일한 권한 및 제약 조건을 가진 실제 세션입니다. 이것이 중요한 이유는 많은 중요한 애플리케이션들이 사용자가 수행하고자 하는 작업에 대해 깔끔한 API를 제공하지 않기 때문입니다. 예를 들어 은행 포털, 정부 포털, 내부 도구, 레거시 관리 패널(admin panels), 로그인 뒤에 워크플로우 상태(workflow state)가 숨겨진 SaaS 대시보드 등이 이에 해당합니다. 이러한 환경에서는 분리된 봇 계정이나 로그아웃된 상태의 새로운 브라우저는 동일한 애플리케이션 상태가 아닙니다. 에이전트가 유용한 다음 단계 제안을 하기 위해서는, 명시적으로 권한이 부여된 세션 내에서 사용자가 실제로 보고 있는 상태를 인지해야 합니다. 이것은 편의 기능의 문제가 아니라, "작업을 시도할 수 있는가"와 "관련 페이지를 전혀 볼 수 없는가"의 차이입니다.

논문에서 증거로

여러 게시물에서 이 내용은 아키텍처에 관한 것이었으므로, 명확하게 현재 위치를 설명합니다. 기반 기술(substrate)은 실시간으로 작동하며, E2LLM은 브라우저 확장 프로그램과 MCP 도구를 통해 구조화된 브라우저 상태를 노출합니다. 관련 문서는 e2llm.com/docs/mcp-tools에서 확인할 수 있습니다. 공개 카테고리와 증거 표면(evidence surface)은 insitu.im/e2llm 및 insitu.im/e2llm/evidence에 있으며, Runtime Snapshots 인덱스는 insitu.im/e2llm/runtime-snapshots에서 확인할 수 있습니다. 다음 스냅샷은 이 시리즈가 구축해 온 부분입니다. API가 없는 사이트에서 실제 작업을 수행하는 구조화된 런타임 인지(structured runtime perception)에 대한 전체 워크스루를 시작부터 끝까지 다룰 것이며, 여기서 어려움을 겪는 지점도 포함합니다.

모델이 아닌 경계 (The boundary, not the model)

다음 브라우저 자동화 물결은 단순히 더 나은 모델만으로 정의되지 않을 것입니다. 에이전트가 행동하기 전에 무엇을 알 수 있도록 허용하는지, 즉 더 나은 인지 경계(perception boundaries)에 의해 정의될 것입니다. 스크린샷은 유용하고, 접근성 트리(accessibility trees)는 유용하며, DOM도 유용합니다. 하지만 실제 브라우저 세션 내에서 작동하는 에이전트는 더 구체적인 것이 필요합니다. 즉, 페이지가 현재 어떤 상태인지, 무엇을 지금 행동할 수 있는지, 그리고 이전 단계 이후로 무엇이 변경되었는지에 대한 구조화된 표현입니다. 이것이 제가 관심을 갖는 범주입니다. '페이지를 보는 AI'가 아닙니다. 구조화된 런타임 인지: 브라우저 에이전트들이 부족한 레이어입니다.

e2llm.com

이것은 Runtime Snapshots 시리즈의 18번째 부분으로, 구조화된 브라우저 데이터가 소프트웨어를 구축하고 테스트하며 배포하는 방식을 어떻게 변화시키는지 탐구합니다. #16에서는 세 가지 아키텍처를 명명했고; #17에서는 이들이 세션을 공유하도록 만들었습니다. 이번 글은 그들 중 어떤 것이 행동하기 전에 무엇을 인지하는지에 관한 것입니다.

브라우저 에이전트를 구축하거나 사용해 본 적이 있다면, 어디서 가장 먼저 실패했습니까: 인지(perception), 계획(planning), 아니면 행동(action)입니까?