왜 나는 브라우저용 파일시스템을 만들었는가

I’m happy to translate the article for you, but I don’t have the full text of the post available. Could you please paste the content you’d like translated (excluding any code blocks or URLs you want to keep unchanged)? Once I have the text, I’ll provide the Korean translation while preserving the original formatting and source link.

오늘날의 세 가지 주요 접근 방식 (그리고 왜 맞지 않는가)

공통 문제: 세 가지 모두 에이전트가 프로그래밍 방식 탐색을 위해 설계되지 않은 표현을 사용하도록 강요합니다.

The Accessibility (AX) Tree – a ready‑made solution

Browsers already solved “navigate this page without looking at it.” 브라우저는 이미 “페이지를 눈으로 보지 않고 탐색한다” 문제를 해결했습니다.

The Accessibility Tree, which screen readers consume, is:

• Deterministic
• Semantic
• Compact

Every button knows it’s a button, every link carries its href, every input has a label and type. 각 버튼은 자신이 버튼임을 알고, 각 링크는 href를 가지고, 각 입력 요소는 레이블과 타입을 가지고 있습니다.

No invisible wrapper <div>s, no CSS noise, no layout‑dependent coordinates. 보이지 않는 <div> 래퍼가 없고, CSS 잡음도 없으며, 레이아웃에 의존하는 좌표도 없습니다.

The AX tree is the low‑entropy, structured signal agents need. The question was how to expose it. AX 트리는 에이전트가 필요로 하는 저엔트로피, 구조화된 신호입니다. 문제는 이를 어떻게 노출할 것인가였습니다.

AX 트리를 파일 시스템에 매핑하기

AX 트리는 자연스러운 계층 구조를 가지고 있습니다:

• 컨테이너 (네비게이션, 메인 콘텐츠, 사이드바, 폼) → 디렉터리
• 인터랙티브 요소 (버튼, 링크, 입력) → 파일

이는 파일 시스템에 깔끔하게 매핑되며, 모든 LLM은 이미 파일 시스템을 다루는 방법을 알고 있습니다.

이 명령들은 모든 모델의 학습 데이터에 등장하므로 → 제로샷 사용성.

예시 세션

dom@shell:$ cd %here%
✓ Entered tab 386872589
  Title: Wikipedia
  URL:   https://www.wikipedia.org/

dom@shell:$ ls
[d] main/
[d] contentinfo/

dom@shell:$ cd main
dom@shell:$ tree 2
main/
├── [d] top_languages/
│   ├── [x] english_7141000_articles_link
│   ├── [x] deutsch_3099000_artikel_link
│   ├── [x] français_2740000_articles_link
│   └── …
├── [d] search/
│   └── [x] search_input
└── [x] read_wikipedia_in_your_language_btn

페이지가 이제 디렉터리 트리가 되었습니다.

submit search_input "Artificial intelligence"

탐색이 진행되고 트리가 자동으로 새로 고쳐지며, 이제 기사 파일 시스템을 보고 있습니다.

스크린샷 없음. 좌표 없음. 선택자 없음.

원시 AX 트리 정리하기

원시 AX 트리는 잡음이 많습니다: CSS 레이아웃을 위한 수백 개의 래퍼 노드(role=generic, role=none, 이름 없는 <div> 등)가 존재하지만 의미론적 역할은 없습니다. 필터링을 하지 않으면 generic_1, generic_2, … 와 같이 유용한 의미가 없는 노드들을 보게 됩니다.

DOMShell’s VFS mapper (vfs_mapper.ts) 은 비의미 노드를 재귀적으로 평탄화하고, 그 자식들을 위로 승격합니다:

• role=generic 노드에 자식이 하나만 있으면, 그 자식이 해당 노드를 대신합니다.
• 보이는 요소는 접근 가능한 이름과 역할에서 파생된 이름을 부여받습니다 (submit_btn, contact_us_link, email_input).
• 중복된 이름은 _2, _3 등으로 구분합니다.

Design decision: 노드 부피를 최소화하면 에이전트의 신호‑대‑잡음 비율이 최대화됩니다. 평탄화된 각 래퍼 노드는 모델이 추론에 낭비하지 않는 토큰이 됩니다.

아키텍처 – 세 개의 명확히 분리된 구성 요소

1. Chrome Extension (the kernel)

   • 백그라운드 서비스 워커가 셸을 실행합니다: 명령 파싱, CDP를 통한 AX 트리 순회, 파일시스템 매핑, DOM‑변경 감지.
   • 사이드‑패널은 얇은 터미널(React + Xterm.js) – I/O만 담당하고 로직은 없습니다.
   • chrome.debugger(Chrome DevTools Protocol 1.3)를 통해 AX 트리를 읽으며, Page.getFrameTree를 이용한 크로스‑iframe 탐색도 포함합니다.

2. MCP Server (the bridge)

   • localhost:3001에서 실행되는 독립형 Node.js HTTP 서버.
   • MCP‑호환 클라이언트(Claude Desktop, Claude Code, Cursor, Windsurf, Gemini CLI) 어느 것이든 연결됩니다.
   • MCP 도구 호출을 셸 명령으로 변환하고, 이를 WebSocket(localhost:9876)을 통해 확장 프로그램에 전달한 뒤 결과를 스트리밍합니다.
   • 다중 동시 클라이언트를 지원합니다.

3. Security tiers

   • 기본적으로 읽기 전용 – 에이전트는 페이지를 탐색할 수 있지만 행동을 취할 수 없습니다.
   • 쓰기 명령(click, type, scroll, js)은 --allow-write가 필요합니다.
   • 민감한 명령(예: 쿠키를 위한 whoami)은 --allow-sensitive가 필요합니다.
   • 도메인 허용 목록을 통해 에이전트가 작업할 수 있는 사이트를 제한합니다.
   • 모든 명령은 타임스탬프와 함께 감사 로그에 기록됩니다.
   • 인증 토큰이 WebSocket 브리지에 대한 접근을 제어합니다.

이러한 분리는 의도적인 설계입니다: MCP 서버 없이도 DOMShell을 인터랙티브하게 사용할 수 있고, 에이전트가 “Delete Account”와 같은 클릭을 할 수 없도록 하면서 탭을 탐색하도록 할 수 있습니다.

성능 결과

Claude Opus 4.6을 사용해 DOMShell과 Anthropic의 내장 브라우저 자동화(Chrome에서 Claude) 두 가지를 모두 적용하여 4개의 작업에 대해 8회 시도를 수행했습니다.

측정 지표: 툴 호출 횟수 – 지연 시간 및 API 비용과 직접 비례합니다.

결과: 호출 횟수 50 % 감소.

가장 큰 효과를 본 부분은 콘텐츠 추출이었습니다: DOMShell은 2회 호출(네비게이션 + 추출)만으로 완료했지만, Chrome에서 Claude는 5‑6회가 필요했습니다.

TL;DR

• 접근성 트리는 페이지의 결정적이고 의미론적인 저엔트로피 표현입니다.
• 이를 가상 파일 시스템에 매핑하면 에이전트에게 익숙한 제로샷 인터페이스(ls, cd, click, …)를 제공합니다.
• 비의미 노드를 평탄화하면 신호 대 잡음비를 최대화합니다.
• 3부분 아키텍처(Chrome 확장 프로그램, MCP 브리지, 보안 계층)는 시스템을 유연하고 안전하게 유지합니다.
• 실제로 DOMShell은 일반적인 브라우징 작업에 필요한 도구 호출 수를 절반으로 줄입니다.

개요

새로운 접근 방식은 에이전트가 올바른 섹션으로 범위 지정 (cd main/article)하고 일괄 추출 (text)을 한 번의 호출로 수행하게 하며, read_page 결과를 반복적으로 탐색하는 대신에 작동합니다.

왜 DOMShell이 빛나는가

• Raw JavaScript execution – javascript_exec는 여러 DOM 작업을 하나의 호출로 배치할 수 있습니다.
• Compound pipeline – for + script + each 파이프라인은 명령 출력을 반복하고 URL 전반에 걸쳐 저장된 스크립트를 재생함으로써 다중 페이지 워크플로를 1‑2 회 호출로 축소합니다.

Impact

• 50 % reduction in tool calls → cost와 latency에 대한 직접적인 절감.
• For production agents (where every tool call is an API round‑trip), 호출 횟수를 절반으로 줄이는 것은 meaningful operational improvement이다.

Open‑source & Roadmap

• DOMShell은 오픈 소스(MIT)이며 무료입니다.
• Roadmap: headless mode – 에이전트가 직접 실행할 수 있는 자체 포함 Chromium 프로세스로, 눈에 보이는 브라우저가 필요 없는 CI 파이프라인 및 서버‑사이드 자동화에 사용됩니다.

복합 효율성 향상

for + script + each 파이프라인이 실제 이득이 발생하는 곳입니다:

1. 저장 명령 시퀀스를 스크립트로 저장합니다.
2. 재생 단일 호출로 N개의 URL에 걸쳐 실행합니다.

결과: O(2N) 도구 호출이 O(2)가 됩니다.
여러 페이지에 걸쳐 연구, 추출 또는 모니터링을 수행하는 모든 에이전트에게 이는 효율성의 큰 도약입니다.

빠른 참고

# Example: change directory and bulk‑extract text
cd main/article
bulk-extract text

브라우저는 여러분의 파일 시스템입니다.
ls 해라.

GitHub

프로젝트: DOMShell – Pireno