agent-browser 설치 후 클릭 결과는 전체 snapshot으로 확인한다

agent-browser는 접근성 트리 snapshot과 @e 참조로 브라우저를 조작하는 CLI다. macOS arm64와 Node v26.10.0에서 agent-browser@0.41.2를 격리 폴더에 설치하고, 외부 자원이 없는 로컬 HTML 한 페이지에서 클릭 뒤 snapshot 재확인까지 검증했다. 문서 확인과 실험은 2026-11-09 KST에 했다.

이 테스트 페이지에서 전체 snapshot은 원시 HTML보다 74.19% 작으면서 -i에 빠진 상태 문구를 담아 행동 뒤 검증에 썼다.

agent-browser 설치와 snapshot으로 확인할 것

원시 HTML을 통째로 넘기면 조작과 무관한 마크업까지 함께 읽힌다. 반대로 조작 대상만 추리면 클릭 뒤 상태가 바뀌었는지 놓칠 수 있다.

그렇다면 시스템 설정을 건드리지 않고 설치해 열기부터 종료까지 돌릴 수 있을까. 출력 바이트는 원시 HTML과 얼마나 다를까.

공식 문서가 설명하는 작동 방식

vercel-labs agent-browser 저장소의 README와 문서(릴리스 태그 v0.41.2, 2026-11-09 KST 확인)를 기준으로 했다. 문서에 따르면 Rust CLI는 첫 명령에서 백그라운드 데몬을 띄운다. 데몬은 Chrome DevTools Protocol로 브라우저를 제어하고, 명령 사이에도 브라우저를 열어 둔다.

Snapshots 문서는 snapshot이 접근성 트리를 짧은 텍스트와 참조로 돌려주고, 이후 click @e2처럼 조작한다고 설명한다. 요소가 교체되거나 페이지를 이동하면 ref가 무효화될 수 있다고도 적었다. 이번 실험 출력에서 참조는 [ref=e2] 형태로 나왔다.

브라우저 설치 위치는 cli/src/install.rs의 get_browsers_dir()가 정한다. 이 함수는 std::env::home_dir() 아래 .agent-browser/browsers를 쓴다.

Rust 공식 문서에 따르면 home_dir()는 Unix에서 HOME을 먼저 본다. 그래서 자식 프로세스의 HOME만 바꿔 설치 위치를 분리했다.

Configuration 문서의 AGENT_BROWSER_DOWNLOAD_PATH는 페이지에서 받는 파일을 저장하는 폴더다. Chrome 설치 캐시를 옮기는 옵션이 아니다.

로컬 페이지에서 잰 출력 크기

테스트 페이지 index.html은 127.0.0.1:18765에만 띄운 833바이트 문서다. Confirm 버튼과 상태 문구가 하나씩 있다. 같은 초기 페이지의 HTTP 본문과 표준 출력을 UTF-8 바이트로 비교했다.

비교 항목크기(UTF-8 바이트)원시 HTML 대비Pending 포함
초기 HTTP HTML 본문833100.00%포함
초기 전체 snapshot21525.81% (74.19% 감소)포함
초기 snapshot -i779.24% (90.76% 감소)제외

클릭 뒤 다시 받은 전체 snapshot은 227바이트였다. 상태가 바뀐 출력이라 초기 비교에는 넣지 않았다.

왜 출력 크기와 검증 범위가 달라지는가

전체 snapshot이 짧은 이유는 HTML 안의 CSS와 스크립트가 출력되지 않기 때문으로 본다. 태그 대신 역할, 이름, 참조 같은 속성만 남는 점도 길이를 줄인다.

-i가 짧은 이유는 다르다. -i는 상호작용 중심 필터라서 문단 본문과 status 아래 Pending을 뺐다. 같은 정보를 그대로 담은 채 줄인 압축이 아니다.

이번 -i 출력에는 버튼 말고 heading도 남았다. 출력 범위는 문서 설명보다 실제 출력으로 확인하는 편이 낫다.

클릭 뒤에는 -i를 다시 실행하지 않았다. 초기 -i 출력에 상태 문구가 없어서 결과 판정에는 전체 snapshot을 썼다.

격리 설치부터 상태 재확인까지

설치·열기, 트리 확인, 참조 클릭, 상태 재확인의 네 단계를 화살표로 이은 순서도. 이 테스트 페이지에서 전체 snapshot은 215바이트, 원시 HTML은 833바이트라고 적었다.

격리 폴더에 설치해 로컬 페이지를 연 뒤 트리를 읽고, 참조로 클릭하고, 상태를 다시 확인하는 순서다. <폴더>는 실험용으로 만든 격리 폴더다.

  1. <폴더>/package에 agent-browser@0.41.2를 로컬 설치하고 버전을 확인한다.
  2. 격리한 HOME 아래에 Chrome for Testing을 내려받는다.
  3. --executable-path로 그 Chrome을 지정해 로컬 페이지를 연다.
  4. 전체 snapshot과 snapshot -i로 @e2와 초기 상태 Pending을 확인한다.
  5. click @e2 뒤 전체 snapshot을 다시 받아 결과를 대조한다.
  6. close로 브라우저와 데몬을 끝낸다.

모든 명령에는 아래 환경변수를 넘겼다.

HOME=<폴더>/home
TMPDIR=<폴더>/tmp
XDG_CACHE_HOME=<폴더>/cache
NPM_CONFIG_CACHE=<폴더>/npm-cache
NPM_CONFIG_USERCONFIG=/dev/null
NPM_CONFIG_REGISTRY=https://registry.npmjs.org
AGENT_BROWSER_SOCKET_DIR=<폴더>/sockets
AGENT_BROWSER_SESSION=radar-local
AGENT_BROWSER_NO_VERSION_CHECK=1
AGENT_BROWSER_ALLOWED_DOMAINS=127.0.0.1
NO_COLOR=1
CI=1

설치에 쓴 명령은 다음과 같다.

npm install --prefix <폴더>/package --no-audit --no-fund agent-browser@0.41.2
<폴더>/package/node_modules/.bin/agent-browser --version
<폴더>/package/node_modules/.bin/agent-browser install

npm은 postinstall 스크립트 승인을 보류했다는 경고를 냈다. 스크립트는 승인하지 않았다. 그래도 패키지에 든 darwin-arm64 바이너리로 --version이 agent-browser 0.41.2를 출력했다.

install은 Chrome 157.0.8103.38(mac-arm64)을 <폴더>/home/.agent-browser/browsers/ 아래에 설치했다.

열기부터 종료까지는 아래 명령을 차례로 실행했다.

<폴더>/package/node_modules/.bin/agent-browser --executable-path "<폴더>/home/.agent-browser/browsers/chrome-157.0.8103.38/Google Chrome for Testing.app/Contents/MacOS/Google Chrome for Testing" open http://127.0.0.1:18765/index.html
<폴더>/package/node_modules/.bin/agent-browser snapshot
<폴더>/package/node_modules/.bin/agent-browser snapshot -i
<폴더>/package/node_modules/.bin/agent-browser click @e2
<폴더>/package/node_modules/.bin/agent-browser snapshot
<폴더>/package/node_modules/.bin/agent-browser close

여섯 명령 모두 종료코드 0이었고 표준 에러는 비어 있었다. open은 ✓ Local agent-browser test, click은 ✓ Done, close는 ✓ Browser closed를 출력했다. 클릭 전 두 snapshot은 다음과 같다.

- main
  - heading "Local browser loop" [level=1, ref=e1]
  - paragraph
    - StaticText "This page has no external resources or network actions."
  - button "Confirm" [ref=e2]
  - status
    - StaticText "Pending"
- heading "Local browser loop" [level=1, ref=e1]
- button "Confirm" [ref=e2]

클릭 뒤 전체 snapshot에서는 두 줄이 바뀌었다. 버튼은 button "Confirm" [disabled, ref=e2]가 됐고, 상태 문구는 StaticText "Confirmed"가 됐다.

✓ Done만 보고 끝내지 않고 이 두 줄로 결과를 확인했다. 클릭할 ref도 짐작하지 않고 직전 snapshot에 나온 값을 썼다.

close 뒤 데몬 PID가 종료되고 pid 파일과 소켓 파일이 지워졌다. 소켓 폴더에는 radar-local.target 파일 하나가 남았다.

이번 실험의 한계

바이트 수치는 직접 만든 로컬 페이지 한 장에서 나온 값이다. 일반 사이트나 대규모 SPA의 대표값이 아니다. 모델을 실행하지 않았으므로 토큰, 요금, 속도로 환산할 수 없다.

입력 fill, 페이지 이동, iframe, 로그인은 실험하지 않았다. 다중 세션 격리, --restore 영속성, 기본 1시간 유휴 종료는 문서로만 확인했다.

도구 연결 방식 자체를 고르는 기준은 MCP vs CLI — AI 코딩 에이전트 도구 연결, 둘 다 써보고 정리한 선택 기준에서 비교했다. 반환값보다 화면 상태를 다시 확인하는 이유는 브라우저 자동화 대기: 90초 타임아웃이 나도 화면부터 확인하는 이유와 이어진다.

결론

이번 로컬 페이지에서 agent-browser는 snapshot과 @e 참조만으로 클릭과 결과 확인까지 마쳤다. 결국 기준은 조작 대상을 고를 때는 -i를, 결과를 판정할 때는 상태 문구가 남는 전체 snapshot을 쓰는 것이다. 에이전트용 브라우저 도구를 검토한다면 별도 폴더와 HOME으로 격리한 뒤 open부터 close까지 여섯 명령을 먼저 실행해 보자.

댓글

댓글 쓰기

이 블로그의 인기 게시물

AI 코딩 스킬, 많을수록 좋을까 — 자산이 부채로 바뀌는 손익분기

이미지
AI 코딩 스킬은 자산이다. 처음 몇 개는 그렇다. 그런데 수가 늘면 세금이 붙는다. 어느 스킬이 뜰지 예측이 안 되고, 도구 출력이 컨텍스트를 먹고, 모델이 바뀌면 쌓은 걸 전부 다시 만진다. 스킬을 관리하는 앱이 시장에 나온 게 그 신호다. 만들지 말라는 게 아니다. 만든 만큼 쳐내야 자산으로 남는다. 스킬은 자산으로 시작한다, 그런데 요즘 개발자들이 자기 .claude 디렉터리를 통째로 공개한다. TypeScript 교육자 Matt Pocock도 스킬 묶음을 GitHub에 올렸다. 제목이 “Skills for Real Engineers”이고, 소개가 “내 .claude 디렉터리에서 바로”다. skills.sh 같은 스킬 레지스트리도 생겼다. 스킬이 자산인 건 맞다. 손으로 반복하던 작업을 트리거 한 줄로 줄인다. 결과도 매번 일정해진다. 그래서 다들 쌓는다. 그런데 같은 GitHub에 묘한 게 같이 뜬다. 스킬을 “관리하고 동기화하고 정리”하는 데스크톱 앱이다. skills-manager는 Cursor·Claude Code·Codex 등 15개 넘는 도구의 스킬을 한곳에서 관리한다고 소개한다. 자산을 관리하는 전용 앱이 필요해졌다는 건, 그 자산이 관리 대상이 됐다는 뜻이다. 관리 대상은 곧 부담이다. 여기서 질문이 갈린다. AI 코딩 스킬은 많을수록 좋은가. 다음 중 하나라도 있나 비슷한 일을 하는 스킬이 둘 이상이라, 어느 게 뜰지 헷갈린 적이 있다. 스킬 하나를 고쳤더니 엉뚱한 데서 다른 게 어긋난 적이 있다. 내가 무슨 스킬을 만들어뒀는지, 목록을 열어봐야 기억나는 적이 있다. 셋 중 하나라도 해당되면 이미 부채 구간에 발을 걸친 것이다. 세 신호를 하나씩 본다. 신호 1 — 어느 스킬이 뜰지 예측이 안 된다 스킬이 늘면 비슷한 트리거를 여럿이 주장한다. “리뷰”라는 말에 코드 리뷰 스킬도 반응하고, 글 리뷰 스킬도 반응한다. 그러면 매 요청마다 “어느 스킬을 부를지” 판별하는 비용이 붙는다. 자동 라우팅 점...
자세한 내용 보기

M4 Max 128GB 로컬 LLM 4종 속도 비교 — 실측 기록과 한계

이미지
M4 Max 128GB에서 로컬 LLM은 얼마나 빠를까? 이 글의 과거 표에서는 gemma4:latest가 88 tok/s로 가장 높고, gemma4:26b는 85 tok/s다. gpt-oss:120b 47 tok/s, qwen3.6:35b-a3b 25 tok/s가 뒤를 잇는다. 처리량 표이지 정답률이나 코딩 품질 순위가 아니다. 작성자: 닥터조지. 2026년 4월 게시 당시 측정 기록 / 편집 보완: 2026-09-23. 기존 수치는 그대로 보존했고 이번에 모델을 다시 실행하지 않았다. 초판 제목의 llama3.3 표기와 “26B가 가장 빠르다”는 도입은 표와 일치하지 않아 바로잡았다. 원문의 장비·런타임·모델 표기는 당시 기록이다. 표의 qwen3.6:35b-a3b 는 원문에서 사용한 축약 표기이며, Q8과 qwen3.6:35b-a3b-q8_0 표기는 당시 본문 기록에서 가져왔다. 모델 파일이나 digest를 이번에 확인한 것은 아니다. 원 프롬프트 전문, 모델 digest, 반복 횟수와 개별 원시 응답이 이 글에 없어 표의 숫자를 그대로 재현했다고 확인할 수는 없다. 특히 latest 는 고정 버전 식별자가 아니다. 아래는 M4 Max 128GB 한 대에서 기록한 네 모델의 처리량이다. 모델 구조, 양자화, 크기가 동시에 다르므로 어느 한 요인만의 효과를 분리한 실험으로 읽으면 안 된다. 모델 크기만으로 속도를 예측하기 어려운 이유 원문은 gpt-oss:120b 를 총 117B, 활성 약 5.1B의 MoE로 기록했다. 활성 파라미터 수만으로 실제 생성 속도를 계산할 수는 없다. 모델 구조에 따른 메모리 접근 차이는 가능한 설명이지만, 이 표는 메모리 대역폭이나 접근 패턴을 직접 계측한 자료가 아니다. 생성 속도 차이만으로 병목의 원인을 확정하지 않는다. 당시 표의 gemma4:26b 는 gpt-oss:120b 보다 높은 생성 처리량을 보였다. 다만 이 결과를 모든 Dense 모델과 MoE 모델의 우열로 일반화할 수는 없다. 같은 ...
자세한 내용 보기

Opus 5는 더 잘 쓰고, 더 AI답게 쓴다 — 세 모델 첫날 실측

이미지
Claude Opus 5가 나온 다음 날, 세 모델에게 같은 시험지를 줬다. 결과부터 적는다. 글 품질 점수는 신형일수록 올랐다. 그런데 문장 리듬은 신형일수록 고르게, 그러니까 더 AI답게 변했다. 여기서 “AI답게”는 말투가 기계 같다는 뜻이 아니다. 문장 길이와 어미가 균질해진다는 뜻이고, 그 균질함이 통계 탐지기가 AI 글을 잡아낼 때 쓰는 바로 그 지문이다. 발표는 두 가지를 팔았다 새 모델이 나오면 벤치마크 표부터 보게 된다. 그 표는 전부 만든 쪽이 자기 시험지로 채점한 결과다. 내 작업에서 뭐가 달라지는지는 표에 없다. 그래서 표를 덮고 시험지를 직접 만들었다. 7월 24일 발표에서 Anthropic은 크게 두 가지를 내세웠다. 하나, 자기 작업을 검증하며 성공할 때까지 반복하는 능력이 강해졌다. 둘, 응답이 더 명확하고 간결해졌다. 벤치 수치는 여기 옮기지 않는다. 이 글이 확인할 건 저 두 문장이 내 작업물에서 어떻게 나타나느냐다. 같은 시험지 두 장 시험지는 두 장이다. 첫째는 글쓰기다. 주제·허용 사실·문체 규칙을 고정한 한국어 블로그 초안 스펙을 만들어 세 모델에 원샷으로 줬다. 둘째는 코딩 진단이다. 내 수집기에서 한 달 넘게 죽어 있던 실제 버그(reddit 수집 429 연쇄 실패)를 읽기 전용으로 진단하게 했다. 모든 주장에 파일과 행 번호 인용을 의무로 걸었다. 대상은 Opus 4.8, Fable 5, Opus 5. 각 모델의 정체는 시스템 프롬프트 자기보고로 확인했다. 채점은 사람 감이 아니다. 글은 발행 글 29편에서 뽑은 결정론 밴드(파이썬 스크립트)와 10점 감점제 루브릭으로, 진단은 미리 고정해 둔 정답표와 인용 실물 대조로 매겼다. 실측 1 — 더 잘 쓸수록 더 고르다 숫자부터 본다. 지표 Opus 4.8 Fable 5 Opus 5 발행 글 기준 문장 길이 변주(변동계수) 0.316 0.220 0.274 0.417 이상 행 길이 변주 0.266 0.23...
자세한 내용 보기