Playwright를 감싼 또 하나의 도구가 아니라, AI 친화적인 브라우저 자동화 인터페이스
최근 AI 코딩 에이전트가 브라우저를 다루는 방식은 빠르게 바뀌고 있다.
기존에는 Playwright, Selenium 같은 자동화 도구를 사람이 직접 스크립트로 짜는 흐름이 중심이었다면, 이제는 에이전트가 브라우저를 탐색하고, 요소를 찾고, 액션을 수행하는 과정 자체를 더 잘 다룰 수 있는 인터페이스가 중요해지고 있다.
그 흐름에서 눈에 띄는 프로젝트가 바로 Vercel Labs의 agent-browser다.
이 프로젝트는 단순한 브라우저 자동화 CLI가 아니다.
핵심은 “AI 에이전트가 브라우저를 더 안정적으로, 더 적은 컨텍스트 비용으로, 더 명시적으로 다룰 수 있게 해주는 실행 인터페이스”라는 점이다.
1. agent-browser는 무엇인가
agent-browser는 AI 에이전트를 위한 헤드리스 브라우저 자동화 CLI다.
README 설명 그대로 요약하면 다음이다.
- 브라우저를 열고
- 페이지를 스냅샷으로 읽고
- 특정 요소를 클릭/입력/탐색하고
- 스크린샷, PDF, 네트워크, 세션, 상태 저장까지 다룰 수 있다
표면적으로는 Playwright 기반 브라우저 자동화 툴처럼 보인다.
하지만 이 도구가 겨냥하는 핵심 사용자는 사람이 아니라 AI coding assistant / agent다.
즉, 이 도구는 “테스트 자동화 도구”라기보다
에이전트가 웹을 조작하기 위한 운영 인터페이스에 가깝다.
2. 왜 이 도구가 중요한가
AI가 브라우저를 다룰 때 가장 큰 문제는 세 가지다.
2-1. DOM 전체를 계속 읽는 건 비효율적이다
브라우저 자동화에서 AI가 페이지 상태를 이해하려면 보통 DOM, accessibility tree, 텍스트, 스크린샷 같은 정보가 필요하다.
문제는 이걸 매번 길게 전달하면 토큰 비용이 커지고, 컨텍스트가 금방 오염된다는 점이다.
2-2. 셀렉터 기반 자동화는 깨지기 쉽다
전통적인 자동화는 #submit, .button, XPath 같은 셀렉터를 쓴다.
그런데 AI가 동적으로 페이지를 이해하며 작업할 때는, 이 방식이 불안정하다.
- 클래스명이 자주 바뀌고
- 동적 렌더링 구조가 바뀌고
- 텍스트/접근성 정보와 셀렉터가 분리되어 있기 때문이다
2-3. 에이전트에게는 “결정 가능한 단위”가 필요하다
AI는 “현재 뭐가 보이고”, “무엇을 누를 수 있고”, “다음 액션이 무엇인지”를 명확한 단위로 받아야 잘 동작한다.
agent-browser는 이 지점을 snapshot + ref 패턴으로 풀고 있다.
3. 이 도구의 핵심: snapshot과 ref
agent-browser에서 가장 중요한 명령은 사실 click이 아니라 snapshot이다.
예시 흐름은 이렇다.
agent-browser open example.com
agent-browser snapshot그러면 페이지를 accessibility tree 기반으로 읽어 다음처럼 ref를 붙여준다.
- heading "Example Domain" [ref=e1] [level=1]
- button "Submit" [ref=e2]
- textbox "Email" [ref=e3]
- link "Learn more" [ref=e4]그 다음 액션은 셀렉터가 아니라 ref로 수행한다.
agent-browser click @e2
agent-browser fill @e3 "test@example.com"
agent-browser get text @e1이 패턴의 장점은 분명하다.
장점 1. 결정성이 높다
AI가 직전에 본 스냅샷의 요소를 그대로 참조하므로,
“이 버튼이 맞나?” 같은 ambiguity가 줄어든다.
장점 2. 토큰 낭비가 줄어든다
DOM 전체를 계속 싣는 대신, 현재 인터랙션 가능한 요소 목록과 ref만 알면 된다.
장점 3. AI 워크플로우에 맞다
브라우저 상태를 읽고 → 타겟 ref를 고르고 → 액션하고 → 다시 스냅샷하는 구조는
에이전트의 판단 루프와 잘 맞는다.
이건 단순한 UX 차이가 아니라,
AI 브라우저 자동화 인터페이스를 인간 중심 도구와 다르게 설계했다는 신호다.
4. 기본 명령어보다 중요한 것은 “작업 모델”이다
README에는 클릭, 입력, hover, drag, upload, network interception, session 관리 등 명령어가 매우 많다.
하지만 실무적으로 더 중요한 건 명령 목록이 아니라 어떤 작업 모델을 제공하느냐다.
agent-browser의 작업 모델은 대략 아래처럼 요약할 수 있다.
4-1. 탐색
agent-browser open <url>
agent-browser snapshot -i4-2. 선택
AI가 snapshot 결과에서 적절한 @eN을 선택
4-3. 조작
agent-browser click @e2
agent-browser fill @e3 "hello"4-4. 상태 재확인
agent-browser snapshot -i
agent-browser get url
agent-browser get text @e4즉, 이 도구는 단순 커맨드 집합이 아니라
에이전트가 상태 기반으로 웹을 다루는 루프를 명시화한다.
5. 전통적인 Playwright 사용과 무엇이 다른가
겉으로 보면 agent-browser는 Playwright를 CLI 형태로 감싼 도구처럼 보일 수 있다.
실제로 기본 아키텍처도 Node.js daemon + Playwright 조합이다.
하지만 차이는 꽤 크다.
Playwright 중심 사고
- 사람이 테스트 스크립트를 작성
- 셀렉터와 assertion을 코드로 유지
- 재현 가능한 deterministic test가 목적
agent-browser 중심 사고
- AI가 런타임에 페이지 상태를 탐색
- snapshot을 보고 현재 가능한 액션을 선택
- 인터랙션을 반복하며 목표를 달성
- 테스트뿐 아니라 “에이전트 실행 인터페이스” 자체가 목적
즉, Playwright가 스크립트 자동화라면
agent-browser는 에이전트 상호작용 실행기에 가깝다.
6. 실무에서 특히 유용한 기능들
README 전체를 보면 기능이 많지만, AI/개발자 관점에서 특히 중요한 부분만 추리면 이렇다.
6-1. --json 출력
에이전트가 기계적으로 처리하기 좋다.
agent-browser snapshot --json
agent-browser get text @e1 --json이건 단순 편의 기능이 아니다.
AI 도구 체인에 붙일 때는 사람이 읽기 좋은 CLI보다 구조화된 결과가 훨씬 중요하다.
6-2. Annotated Screenshot
agent-browser screenshot --annotate화면 위에 번호를 덧씌우고, 그 번호를 @e1, @e2 같은 ref와 연결해준다.
이 기능은 특히 다음 상황에서 강하다.
- 접근성 트리만으로는 잘 안 보이는 UI
- 아이콘 버튼
- canvas 기반 UI
- 시각적 상태가 중요한 앱
즉, 텍스트 기반 스냅샷만으로 부족할 때 멀티모달 에이전트와 결합하기 좋은 인터페이스다.
6-3. Session / Profile Persistence
브라우저 자동화에서 로그인 상태 유지 문제는 늘 귀찮다.
agent-browser는 다음 두 가지 방식을 제공한다.
세션 기반
agent-browser --session agent1 open site-a.com프로필 기반
agent-browser --profile ~/.myapp-profile open myapp.com이 차이는 중요하다.
session: 격리된 브라우저 인스턴스 중심profile: 쿠키/스토리지/로그인 상태를 파일 시스템에 지속
즉, 테스트뿐 아니라 장기 실행되는 에이전트 워크플로우에도 맞출 수 있다.
6-4. Security 옵션
README에서 의외로 인상적인 부분이 보안 섹션이다.
예를 들면:
--allowed-domains--content-boundaries--action-policy--confirm-actions--max-output
이건 단순 부가 기능이 아니다.
AI 에이전트가 브라우저를 조작할 때 실제로 필요한 안전장치다.
특히 아래 문제를 줄이는 데 유용하다.
- 프롬프트 인젝션 유사 문제
- 신뢰하지 않는 페이지로의 이동
- 의도치 않은 destructive action
- 과도한 출력으로 인한 컨텍스트 오염
브라우저 자동화 툴이 아니라 에이전트 실행 인프라로 보고 설계했다는 흔적이 여기서 더 분명해진다.
7. Native 모드가 의미하는 것
agent-browser는 기본적으로 Node.js daemon + Playwright를 사용하지만,
실험적으로 --native 모드도 제공한다.
agent-browser --native open example.com이 모드는 Rust 기반 daemon이 Chrome DevTools Protocol(CDP)을 직접 다루는 방향이다.
이게 왜 중요하냐면:
- Node.js 의존성을 줄일 수 있고
- 단일 바이너리 중심으로 배포가 쉬워지고
- 파싱/IPC 오버헤드를 낮출 수 있으며
- AI 에이전트 런타임에 더 적합한 경량 구조로 갈 수 있기 때문이다
즉, 단순히 “Rust라서 빠르다” 수준이 아니라
에이전트 런타임에 최적화된 브라우저 제어 계층으로 진화하려는 방향성이 보인다.
8. 이 프로젝트가 특히 강한 지점
내가 보기엔 agent-browser의 강점은 네 가지다.
8-1. AI 워크플로우에 맞게 인터페이스가 설계되어 있다
기존 자동화 도구를 억지로 에이전트에 붙인 느낌이 아니다.
처음부터 AI가 읽고 행동하기 좋은 형식에 가깝다.
8-2. CLI라서 통합이 쉽다
에이전트, 쉘, CI, 로컬 개발 환경 어디든 붙이기 쉽다.
특히 coding agent가 shell command를 실행할 수 있는 환경이면 바로 연결 가능하다.
8-3. 기능 범위가 넓다
단순 클릭 자동화를 넘어서 다음까지 포괄한다.
- 세션 관리
- 인증 상태 저장
- 네트워크 추적
- 콘솔/에러 확인
- diff
- trace/profiler
- cloud browser provider 연동
즉, “브라우저를 조작한다”를 넘어
브라우저 상태를 운영하고 디버깅하는 계층까지 갖췄다.
8-4. AI 코딩 툴과의 연결이 명시적이다
README에서 Claude Code, Cursor, Copilot, Gemini CLI, Goose, Windsurf 등과의 연계를 직접 언급한다.
이건 단순 홍보가 아니라, 이 프로젝트의 포지셔닝이 AI coding ecosystem의 브라우저 레이어라는 뜻이다.
9. 한계도 분명하다
좋은 점만 있는 건 아니다.
9-1. 결국 브라우저 자동화의 본질적 불안정성은 남는다
웹은 동적이고 비동기적이다.
ref 기반으로 안정성이 높아져도 페이지 로딩, hydration, custom UI, shadow DOM, iframe, race condition 문제는 계속 생긴다.
9-2. snapshot 기반 접근은 페이지 의미 구조에 의존한다
접근성 구조가 나쁘거나 커스텀 컴포넌트가 많은 앱에서는 snapshot 품질이 떨어질 수 있다.
이 경우 annotated screenshot이나 cursor-interactive 옵션이 필요해진다.
9-3. Native 모드는 아직 실험적이다
README에서도 명확히 experimental이라고 적고 있다.
즉, production에서 전면 채택하려면 아직 검증이 더 필요하다.
9-4. “스크립트 자동화”와 “에이전트 자동화”는 다르다
이 도구가 좋다고 해서 기존 Playwright 테스트를 대체하는 건 아니다.
회귀 테스트, assertion-heavy E2E 테스트, deterministic CI 테스트는 여전히 전통적인 테스트 코드가 더 적합하다.
10. 어떤 팀에게 특히 맞는가
agent-browser는 모든 팀에 필요한 도구는 아니다.
하지만 아래 경우에는 상당히 유효하다.
잘 맞는 경우
- AI 코딩 에이전트가 실제 브라우저를 다뤄야 하는 팀
- QA 자동화보다 agent-driven exploration이 중요한 팀
- 브라우저 상호작용을 CLI 기반으로 통합하고 싶은 팀
- coding assistant와 브라우저 자동화를 연결하려는 팀
- 웹앱에서 반복적인 사용 흐름을 에이전트가 재현하게 만들고 싶은 팀
덜 맞는 경우
- 순수한 deterministic E2E 테스트만 필요한 팀
- 이미 Playwright 스위트가 매우 잘 정리된 팀
- 에이전트 기반 실행보다 사람이 작성한 테스트 코드가 중심인 팀
11. 개인적으로 중요하게 본 포인트
이 프로젝트를 보면서 가장 중요하다고 느낀 부분은 기능 개수보다도 설계 관점의 변화다.
예전에는 브라우저 자동화 도구를 만들 때 주로 이런 질문을 했다.
- 사람이 테스트를 어떻게 작성할까?
- 셀렉터를 어떻게 안정화할까?
- CI에서 어떻게 돌릴까?
그런데 agent-browser는 질문이 다르다.
- AI가 현재 페이지를 어떻게 이해할까?
- 어떤 형태의 출력이 LLM에게 가장 유리할까?
- 브라우저 상호작용을 어떻게 ref 중심으로 안정화할까?
- 출력과 액션을 어떻게 안전하게 제한할까?
즉, 이 프로젝트는 브라우저 자동화를 “테스트 도구” 관점에서 한 단계 밀어내고,
AI 에이전트 실행 인터페이스라는 새로운 기본값으로 재구성하려고 한다.
이 점이 가장 흥미롭다.
12. 마무리
agent-browser는 단순한 브라우저 CLI가 아니다.
이 도구가 보여주는 핵심은 다음이다.
앞으로의 브라우저 자동화는 사람이 스크립트를 짜는 문제가 아니라,
AI가 웹을 읽고 판단하고 행동하는 인터페이스를 어떻게 설계할 것인가의 문제다.
정리하면:
snapshot + ref모델이 핵심이다- AI 친화적인 브라우저 인터페이스로 잘 설계되어 있다
- 보안/세션/상태/구조화 출력까지 고려되어 있다
- Playwright의 대체재라기보다 에이전트 레이어 위의 실행기에 가깝다
브라우저를 다루는 AI 에이전트가 점점 흔해질수록,
이런 형태의 도구는 더 중요해질 가능성이 높다.
특히 프론트엔드 개발, QA, 에이전트 UX, 브라우저 기반 자동화에 관심 있는 사람이라면 한 번 읽어볼 만한 프로젝트다.
