왜 이 Show HN이 눈에 띄었나

작성자는 agent-browser-protocol, 즉 ABP를 "browser automation을 agent가 다루기 쉬운 discrete tool loop로 다시 포맷하는 layer"로 설명한다. 핵심 아이디어는 단순하다. click이나 type 뒤에 page를 계속 흘려보내지 않고, JavaScript execution과 rendering을 잠깐 freeze한 뒤 새로운 state를 캡처하고 navigation, download, permission prompt, alert, file picker 같은 event를 정리해서 다음 planning step으로 넘긴다. stale screenshot 위에서 reasoning하다가 실패하는 전형적인 browser-agent error를 정면으로 겨냥한 설계다.

repo description도 같은 진단을 내린다. web은 continuous하고 asynchronous하지만 agent는 step 단위로 생각한다는 것이다. 그래서 HN discussion은 benchmark number 자체보다 failure mode 분석에 더 공감했다. 여러 commenters가 modal, spinner, autocomplete dropdown, page reflow처럼 마지막 capture 뒤에 나타나는 변화 때문에 agent가 엉뚱한 state를 기준으로 행동한다고 지적했다. model reasoning failure처럼 보이는 문제의 상당수가 사실은 harness timing bug라는 주장이다.

HN이 물은 핵심 질문

Show HN 본문은 Opus 4.6 driver 기준 Online Mind2Web 90.5% score도 언급했다. 다만 HN이 바로 물은 것은 "얼마나 model 덕분이고, 얼마나 browser design 덕분인가"와 "Chromium fork를 agent-specific feature 때문에 얼마나 오래 유지할 수 있는가"였다. 이 질문이 정확하다. browser agent의 다음 도약이 더 큰 model이 아니라 더 나은 state contract와 interface layer에서 나올 수도 있기 때문이다.

이 프로젝트의 의미도 여기에 있다. browser agent를 만들 때 필요한 것은 screenshot loop를 하나 더 도는 일이 아니라, action 이후 state가 언제 확정되는지에 대한 강한 계약이다. ABP가 널리 통한다면, agent tooling의 경쟁축은 model size 못지않게 runtime design으로 이동할 가능성이 크다.

Project repo | Hacker News discussion

#browser-agents

Hacker News가 본 AI agent용 browser fork의 설계 포인트