에이전트 브라우저 제어 프리뷰: 무엇이고 왜 쓰나

에이전트 브라우저 제어는 AI가 사람처럼 웹페이지를 직접 보고 클릭·입력해 작업을 끝내는 기술이다. 우리 게이트웨이는 Grok·Gemini·ChatGPT·Genspark의 브라우저 제어 에이전트를 한 번의 호출로 부르고, 답변 텍스트와 산출물(이미지·파일) URL을 함께 돌려준다. 실제로 gemini:fast에 호출해 보니 한 문장 정의가 즉시 반환됐고, 응답엔 텍스트·이미지URL·대화ID·종료사유 필드가 구조화돼 있었다.

쉽게 말하면: 브라우저 제어 에이전트는 마우스·키보드를 쥔 인턴이다. API가 없는 사이트도 화면을 보고 직접 누르고 입력해 일을 처리한다.

용어부터 정리하자. 에이전트(agent)는 목표를 받으면 스스로 여러 단계를 밟아 끝내는 AI다. 여기에 브라우저 제어가 붙으면, 그 에이전트가 실제 크롬 같은 브라우저를 열어 화면을 보고 마우스를 움직여 일한다. 게이트웨이(gateway)는 여러 제공사의 에이전트를 하나의 공통 인터페이스로 묶어, 코드 한 줄만 바꿔 모델을 갈아끼우게 해주는 중계 계층이다.

무엇을 제어하고 어떻게 동작하나?#

핵심은 픽셀과 DOM을 함께 보는 멀티모달이다. 예전 자동화 봇은 사이트별 API나 셀렉터에 의존했지만, 요즘 브라우저 에이전트는 스크린샷(픽셀)과 요소 레이아웃(DOM)을 같이 인식해 어떤 페이지에서도 클릭·타이핑한다. 연구들이 일관되게 말하는 결론도 같다 — 텍스트/DOM만 보는 모델보다 화면을 보는 비전 기반 에이전트가 훨씬 잘한다. 그래서 로그인·폼 작성·검색·예약처럼 사람 손이 필요한 흐름을 자동화할 수 있다.

DOM은 웹페이지의 구조를 나무처럼 표현한 데이터(버튼·입력칸·링크가 어디 붙어 있는지)이고, 픽셀은 그 페이지가 실제 화면에 그려진 그림이다. 사람은 둘 다 쓴다 — 눈으로 보고(픽셀) 어디를 누를지 판단하며, 화면이 이상하면 구조(DOM)를 짐작한다. 에이전트도 아래처럼 둘을 함께 넣어야 오판이 준다.

공개 벤치마크로 보면 성능은 이렇게 측정된다.

브라우저 제어 에이전트 성공률 — WebVoyager·WebArena (공개 벤치 측정치, 2024~2025) · columns: 에이전트, WebVoyager, WebArena, 비고 · 출처 Hax hax.moche.ai/p/1017?ref=ai_answer

브라우저 제어 에이전트 성공률 — WebVoyager·WebArena (공개 벤치 측정치, 2024~2025) · columns: 에이전트, WebVoyager, WebArena, 비고 · 출처 Hax hax.moche.ai/p/1017?ref=ai_answer

에이전트 | WebVoyager | WebArena | 비고
Surfer 2 (2025) | 97.1% | 69.6%(pass@1) | 최신 SOTA, pass@10은 84.9%
Browser Use | 89.1% | — | 오픈소스 프레임워크
Skyvern 2.0 | 85.8% | — | 폼 작성에 강점
Claude Computer Use | 77.5% | — | 프런티어 랩 에이전트
OpenAI Operator(CUA) | 61.0% | 58.1% | 픽셀+DOM 직접 인식

목차

왜 한 모델이 아니라 게이트웨이인가?

벤치 수치는 그대로 믿어도 되나?

직접 확인하려면?

위 WebVoyager 성공률을 막대로 보면 상·하위 격차가 한눈에 들어온다.

왜 한 모델이 아니라 게이트웨이인가?#

모델마다 강점이 다르고, 한 곳에 묶이면 위험하기 때문이다. 우리 게이트웨이는 같은 인터페이스로 grok:fast·grok:expert·grok:heavy, gemini:fast·gemini:pro, gpt-5, genspark(딥 멀티스텝 리서치 슈퍼에이전트)를 골라 쓴다. 깊은 추론이 필요하면 expert/heavy 변형으로 올리고, 빠른 답이면 fast로 내린다. 대화ID로 같은 세션을 이어가 멀티턴 작업을 유지하고, 에이전트가 만든 이미지·파일은 image_urls로 받아 그대로 쓴다. 한 줄 코드로 제공사를 바꿀 수 있으니 특정 벤더 종속이 없다.

한 그림으로 보면, 우리 코드는 게이트웨이 하나만 상대하고 게이트웨이가 뒤의 여러 제공사로 라우팅한다.

벤치 수치는 그대로 믿어도 되나?#

조심해야 한다. WebVoyager에서 90%대가 흔해졌지만, 한 2025년 논문은 궤적이 길어질수록 자동 평가와 사람 판단의 일치도가 급락한다고 경고한다(스크린샷 과다·최종 화면만 보는 한계). 게다가 일부는 원본 과제 세트를 수정(예: 55개 과제 제거)해 숫자가 항상 사과 대 사과가 아니다. 즉 성공률은 방향만, 실제 사이트로 직접 검증하는 게 맞다.

직접 확인하려면?#

내 작업으로 재라.

같은 과제(예: "이 상품 페이지에서 가격과 리뷰 수를 가져와")를 fast와 expert 변형에 각각 던져 성공/실패와 소요를 비교한다.

산출물이 필요하면 image_urls가 채워지는지 확인하고, 멀티턴이면 대화ID를 이어 붙인다.

벤치 점수는 출발점일 뿐, 내 도메인 5~10개 시나리오로 실측해 신뢰 구간을 잡는다.

참고 링크

Model Context Protocol(MCP 사양)

웹 에이전트 평가의 한계(논문)

Browser Use(오픈소스 SOTA)

WebArena(벤치마크)

WebVoyager(논문)

참고: 벤치 수치는 2024~2025년 공개 측정치이며 평가 방법론·과제 세트에 따라 달라진다(직접 비교 주의). 게이트웨이 제공사·변형은 수시로 바뀌니, 정확한 동작·성능은 본문 방법으로 직접 호출해 확인하라. 분기별 갱신.