요즘 핫한 agent-browser 맛좀 봤습니다

AI 스킬 설치 순위를 훑다가 agent-browser라는 이름이 7위에 올라와 있는 걸 봤습니다. 버셀 랩스에서 만든 물건이더군요.

처음에는 별 생각이 없었습니다. 브라우저 자동화 도구가 하나 더 나왔나 싶었어요. Playwright도 있고 Puppeteer도 있고, 저희도 카페24 관리자 자동화에는 Playwright를 직접 짜서 쓰고 있으니까요.

그런데 설치 수가 72만 건이라고 적혀 있었습니다. 그래서 저장소를 열어봤습니다.

2026년 9월 2일 캡처. 스타 41.7k, 포크 2.8k, 아파치 2.0 라이선스입니다. 맨 위 커밋이 Prepare v0.36.0 release로 어제 자였어요.

이름만 보고는 Playwright를 감싼 줄 알았습니다

설치는 두 줄입니다.

npm install -g agent-browser
agent-browser install

두 번째 줄이 크롬을 받아옵니다. 구글이 자동화용으로 따로 내놓는 판이에요. 저희 쪽에서는 193MB를 받아 152.0.7977.75가 깔렸습니다.

안을 열어보니 예상과 달랐습니다. 노드가 아니라 러스트로 짠 CLI고, 데몬이 크롬과 붙어 있는 구조더군요. 명령을 칠 때마다 브라우저를 새로 켜지 않고 띄워둔 걸 계속 써요. 한 시간 놀면 알아서 꺼진다고 문서에 적혀 있습니다.

여기까지는 "빠른 Playwright CLI"로 읽혔습니다. 제 생각이 바뀐 건 snapshot이라는 명령을 보고 나서입니다.

화면을 통째로 넘기지 않습니다

AI에게 웹페이지를 다루게 하려면 지금 화면이 어떻게 생겼는지를 어떻게든 넘겨야 합니다. HTML을 통째로 주거나, 스크린샷을 찍어 주거나요.

이 도구는 접근성 트리만 뽑아서 넘깁니다. 화면 읽어주는 프로그램이 쓰는 그 구조예요. 클래스명, 인라인 스타일, 스크립트, 트래킹 태그는 전부 버립니다.

얼마나 차이 나는지 궁금해서 공개된 데모 상점 첫 화면으로 세어봤습니다.

세는 데 쓴 화면입니다. 사람 눈에는 이 정도인데 브라우저가 들고 있는 마크업은 211,182자였습니다.

아래 두 막대가 거의 안 보이는 게 요점입니다.

대신 요소마다 [ref=e5] 같은 번호표가 붙어 나옵니다. 다음 명령에서 agent-browser click @e5라고 쓰면 그걸 누릅니다. CSS 선택자를 짜맞출 필요가 없어요.

AI가 HTML 전체를 읽는 것보다 이쪽이 다루기 편해 보입니다. 넘기는 양이 적어서만은 아니고, 버릴 것을 사람이 고르지 않아도 되기 때문입니다. 지금까지는 "본문만 긁어와라" 같은 규칙을 페이지마다 손으로 짜야 했거든요.

버튼이 자기가 왜 안 눌리는지 말해줍니다

제일 재미있었던 건 여기입니다.

티셔츠 상품 페이지를 열고 스냅샷을 떴더니 옵션 부분이 이렇게 나왔습니다.

- term "COLOR"
  - button "Black" [ref=e30]
  - button "White" [ref=e31]
  - button "Blue" [disabled, ref=e32]
- term "SIZE"
  - button "XS" [ref=e33]
  ...
- button "Please select an option" [disabled, ref=e7]
    - StaticText "Add To Cart"

파랑에 disabled가 붙어 있습니다. 못 고르는 색이라는 걸 AI가 짐작이 아니라 표시로 압니다.

그리고 맨 아랫줄. 장바구니 버튼도 disabled인데, 버튼 이름이 "Add To Cart"가 아니라 "Please select an option"입니다. 화면에 보이는 글자와 접근성 이름이 다르고, 그 이름에 왜 못 누르는지가 들어 있습니다.

몇 개 눌러봤습니다. 사이즈 M을 고르니 검정이 disabled로 바뀌더군요. M에 검정 재고가 없다는 뜻입니다. 흰색으로 바꾸니 이번엔 L이 disabled가 됐고요. 그러고 나서 장바구니 버튼이 이렇게 됐습니다.

- button "Add to cart" [ref=e7]
    - StaticText "Add To Cart"

같은 시점에 agent-browser screenshot으로 찍은 화면입니다. 흰색·M을 고른 상태이고 검정·파랑·L이 흐려져 있습니다. 트리에서 disabled로 읽힌 것과 같은 항목입니다.

스크린샷만 넘겼다면 AI는 회색 버튼을 보고 이유를 지어내야 합니다. 품절인지, 위 옵션을 아직 안 골라서인지, 그냥 디자인이 그런 건지 구분할 방법이 없어요. 트리에는 그게 문자열로 있습니다.

물론 이건 저 상점이 마크업을 제대로 해놨기 때문입니다. 도구가 없는 정보를 만들어내지는 않습니다. 이걸 보면서 접근성이 사람만의 문제가 아닐 수 있겠다는 생각이 들었어요. 다만 이건 제 해석이고, 문서에 그렇게 적혀 있는 건 아닙니다.

한 가지 걸린 것도 있었습니다. 번호표는 화면이 다시 그려지면 가리키는 게 달라집니다. 처음 스냅샷에서 @e30이 검정이었는데 사이즈를 누른 뒤에는 아니었어요. 저도 여기서 한 번 헛클릭했습니다. 누른 다음에는 다시 스냅샷을 떠야 합니다.

테스트 코드 자리를 뺏는 물건은 아닌 것 같습니다

그럼 Playwright를 걷어내야 하나 싶었는데, 읽어보니 겨냥하는 자리가 달라 보입니다.

로그인해서 장바구니에 담고 결제까지 가는 순서가 정해진 흐름은 여전히 Playwright 쪽이 자연스럽습니다. 같은 순서를 매번 똑같이 돌리는 게 목적이고, 그건 코드로 박아두는 게 맞으니까요.

제가 재미있다고 느낀 쪽은 순서를 미리 못 정하는 경우입니다. 화면을 보고 다음에 뭘 누를지 그때 정해야 하는 상황이요. 사람이 짠 순서가 없으니 AI가 현재 상태를 읽어야 하는데, 그 읽는 비용이 5,365자면 매 단계 다시 읽어도 부담이 적습니다.

둘 중 하나를 고르는 문제는 아닌 것 같고, 쓰는 자리가 다른 것에 가까워 보입니다.

우리 사이트는 어떻게 읽히나 궁금했습니다

같은 도구에 접근성 감사 명령이 붙어 있길래 저희 사이트에 걸어봤습니다.

agent-browser open https://simpler24.com
agent-browser a11y

검사기는 도구에 들어 있는 axe-core 4.12.1입니다. 대비로 걸린 곳은 푸터 링크 쪽이었고, 제목 단계는 h4 하나가 순서를 건너뛴 자리였어요. 기분 좋은 결과는 아니에요.

스냅샷 크기도 재봤는데 저희 첫 화면은 DOM 143,137자에 스냅샷 21,470자, 15%였습니다. 데모 상점의 2.5%와 차이가 큽니다. 줄어드는 건 마크업이지 글이 아니니까, 글자가 많은 페이지는 덜 줄어드는 것 같습니다.

코드를 짜게 한 다음 눌러보게 하고 싶습니다

써보고 싶은 자리가 하나 떠올랐습니다.

Claude Code한테 화면 작업을 시키면 코드까지는 만들어 주는데, 그게 실제로 눌리는지는 결국 사람이 열어서 확인합니다. 여기를 붙여보고 싶어요. 만든 다음에 직접 열어서 버튼 한 번 눌러보고, 안 눌리면 왜 안 눌리는지 읽어오게요.

위에서 본 것처럼 버튼이 자기 상태를 이름으로 말해주니, 최소한 "왜 실패했는지 모르겠다"로 끝나지는 않을 것 같습니다.

직접 써봐야 알 것 같은 것

여기까지가 문서 읽고 몇 개 눌러본 범위입니다. 결제까지 태워보지도, 실제 업무에 붙여보지도 않았습니다.

그래서 이런 건 아직 모르겠습니다.

로그인이 걸린 페이지나 화면이 계속 바뀌는 곳에서 얼마나 버티는지. 번호표가 다시 그려질 때마다 갱신돼야 한다면 긴 흐름에서는 스냅샷을 몇 번이나 떠야 하는지. 한글 페이지에서 접근성 이름이 제대로 안 붙어 있는 경우가 얼마나 흔한지도요.

설치할 때 하나 더 걸린 게 있었습니다. --headless 없이 open을 쳤더니 창을 못 띄우는 셸이라 3분을 기다려도 응답이 없었어요. 사람이 쓰는 터미널이면 크롬 창이 뜨니 문제가 안 되겠지만, 자동화 안에 넣을 거라면 --headless를 기본으로 두는 게 낫겠습니다.

정리하면, 브라우저를 AI에게 붙일 일이 생기면 먼저 꺼내볼 후보가 하나 생겼습니다. 그게 지금까지의 생각입니다.