에이전트 브라우저 제어 프리뷰: 무엇이고 왜 쓰나
요약: 에이전트 브라우저 제어는 AI가 사람처럼 웹페이지를 직접 보고 클릭·입력해 작업을 끝내는 기술이다. 우리 게이트웨이는 Grok·Gemini·ChatGPT·Genspark의 브라우저 제어 에이전트를 한 번의 호출로 부르고, 답변 텍스트와 산출물(이미지·파일) URL을 함께 돌려준다. 실제로 gemini:fast에 호출해 보니 한 문장 정의가 즉시 반환됐고, 응답엔 텍스트·이미지URL·대화ID·종료사유 필드가 구조화돼 있었다. 쉽게 말하면: 브라우저 제어 에이전트는 마우스·키보드를 쥔 인턴이다. API가 없는 사이트도 화면을 보고 직접 누르고 입력해 일을 처리한다.
에이전트 브라우저 제어는 AI가 사람처럼 웹페이지를 직접 보고 클릭·입력해 작업을 끝내는 기술이다. 우리 게이트웨이는 Grok·Gemini·ChatGPT·Genspark의 브라우저 제어 에이전트를 한 번의 호출로 부르고, 답변 텍스트와 산출물(이미지·파일) URL을 함께 돌려준다. 실제로 gemini:fast에 호출해 보니 한 문장 정의가 즉시 반환됐고, 응답엔 텍스트·이미지URL·대화ID·종료사유 필드가 구조화돼 있었다.
쉽게 말하면: 브라우저 제어 에이전트는 마우스·키보드를 쥔 인턴이다. API가 없는 사이트도 화면을 보고 직접 누르고 입력해 일을 처리한다.
용어부터 정리하자. 에이전트(agent)는 목표를 받으면 스스로 여러 단계를 밟아 끝내는 AI다. 여기에 브라우저 제어가 붙으면, 그 에이전트가 실제 크롬 같은 브라우저를 열어 화면을 보고 마우스를 움직여 일한다. 게이트웨이(gateway)는 여러 제공사의 에이전트를 하나의 공통 인터페이스로 묶어, 코드 한 줄만 바꿔 모델을 갈아끼우게 해주는 중계 계층이다.
무엇을 제어하고 어떻게 동작하나?#
핵심은 픽셀과 DOM을 함께 보는 멀티모달이다. 예전 자동화 봇은 사이트별 API나 셀렉터에 의존했지만, 요즘 브라우저 에이전트는 스크린샷(픽셀)과 요소 레이아웃(DOM)을 같이 인식해 어떤 페이지에서도 클릭·타이핑한다. 연구들이 일관되게 말하는 결론도 같다 — 텍스트/DOM만 보는 모델보다 화면을 보는 비전 기반 에이전트가 훨씬 잘한다. 그래서 로그인·폼 작성·검색·예약처럼 사람 손이 필요한 흐름을 자동화할 수 있다.
DOM은 웹페이지의 구조를 나무처럼 표현한 데이터(버튼·입력칸·링크가 어디 붙어 있는지)이고, 픽셀은 그 페이지가 실제 화면에 그려진 그림이다. 사람은 둘 다 쓴다 — 눈으로 보고(픽셀) 어디를 누를지 판단하며, 화면이 이상하면 구조(DOM)를 짐작한다. 에이전트도 아래처럼 둘을 함께 넣어야 오판이 준다.
공개 벤치마크로 보면 성능은 이렇게 측정된다.
| 에이전트 | 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개 시나리오로 실측해 신뢰 구간을 잡는다.
참고 링크
참고: 벤치 수치는 2024~2025년 공개 측정치이며 평가 방법론·과제 세트에 따라 달라진다(직접 비교 주의). 게이트웨이 제공사·변형은 수시로 바뀌니, 정확한 동작·성능은 본문 방법으로 직접 호출해 확인하라. 분기별 갱신.
Responses
No responses yet. Be the first to respond.