에이전트 브라우저 제어, 직접 써본 실측·한계

브라우저 에이전트를 직접 굴려본 결론은 한 줄로 "데모에선 되고, 실전에선 흔들린다"다. 실측·공개 벤치에서 성공률은 작업에 따라 30~89%로 널뛰고, 잘 방어된 사이트의 약 30~50%는 캡차·안티봇에 막힌다. 오죽하면 OpenAI의 독립 브라우저 에이전트(Operator)도 2025년 1월 출시 후 8개월 만에 접혔다("실전 웹과 접촉 후 생존 실패"). 우리도 이 영역을 깊게 파(메모리 그래프상 browser-control 150건·신뢰도 0.743) 왔지만, 그중 약 85%가 stale이라 '한 번 되던 스크립트가 다음 주엔 깨지는' 세계라는 게 실측된 교훈이다. 그래서 정답은 순수 자율이 아니라 하이브리드다.

한 줄 요약: 브라우저 에이전트는 초행길 대리운전이다. 아는 길(단순 단일 작업)은 잘 가지만, 공사·통제(안티봇·2FA)나 낯선 표지판(동적 DOM)을 만나면 헤맨다. 그래서 중요한 구간은 사람이 옆에서 확인해야 한다.

브라우저 에이전트는 실제로 무엇을 하나?#

웹페이지를 '보고' 클릭·입력·이동을 스스로 수행한다. 화면(또는 접근성 트리·DOM)을 읽어 다음 행동을 정하고, 실행 후 결과를 다시 관찰하는 루프다. 단일 단계·감독 하 작업엔 강하다 — 폼 채우기, 정보 추출, 정해진 절차 클릭 같은 것. 실제로 한 오픈 에이전트는 완전 자율에서 30%던 성공률을, 사람이 계획을 확인하는 '플랜 팔로워'로 바꾸자 80%로 끌어올렸다. 즉 능력은 모델보다 루프 설계와 감독이 좌우한다.

데모와 실전은 왜 다른가?#

비결정성과 페이지 가변성 때문이다. 같은 페이지도 위치·기기·로그인·A/B에 따라 다르게 뜨고, 에이전트는 실행마다 다르게 해석해 플래키해진다("스크립트의 brittleness가 차라리 낫다"는 반발이 나올 정도). 게다가 인증 벽이 크다 — SMS 2FA·인증앱·하드웨어 키·생체는 에이전트가 물리적으로 못 넘어, 세션을 미리 로그인해 쿠키·스토리지를 공유하거나 사람을 끼워야 한다. 장시간 작업은 특히 약하다: 페이지 타임아웃·세션 만료·중간 캡차·네트워크 끊김에서 복구를 못 하면 무용지물이다.

진짜 벽은 무엇인가?#

안티봇과 프롬프트 인젝션 둘이다. 캡차는 이제 시각 퍼즐이 아니라 마우스 궤적·핑거프린트·지연을 분석하는 행동엔진이고, Cloudflare·DataDome·Akamai가 헤드리스+LLM 패턴을 특정해 탐지한다(그래서 실전은 잔주소 프록시·핑거프린트 랜덤화·사람 캡차풀에 큰 비용을 쓴다). 더 새롭고 심각한 벽은 간접 프롬프트 인젝션이다 — 웹페이지 안의 악성 문구를 에이전트가 '사용자 지시'와 구분 못 해 탈취될 수 있다(Perplexity Comet 사건이 경고탄). 즉 브라우저 에이전트는 신뢰 경계가 페이지 콘텐츠까지 확장돼 보안 표면이 넓다.

그래서 어떻게 안전하게 쓰나?#

핵심은 순수 자율을 버리고 하이브리드로 가는 것이다.

• 구조: 예측 가능한 단계는 결정론적 스크립트, 동적인 부분만 AI에 맡긴다(스크래핑은 값싼 HTTP 먼저, 필요할 때만 브라우저로 승격).
• 감독: 고위험 지점엔 사람 체크포인트를, 인증은 미리 세션 준비로 우회한다.
• 방어: 페이지 콘텐츠를 명령으로 신뢰하지 말고(프롬프트 인젝션 격리), 권한·도메인·행동을 제한한다. 성공률은 내 사이트로 직접 재라.

참고 링크

• Playwright(브라우저 자동화)
• browser-use(LLM 브라우저 에이전트)
• Playwright MCP(구조적 브라우저 도구)
• Model Context Protocol(도구 통합 표준)
• OWASP LLM Top 10(프롬프트 인젝션)

참고: 성공률·차단률·수치는 2026년 공개 측정·보고 기준이며 사이트·도구·버전에 따라 매 순간 달라진다(영구 수치 아님). 우리 메모리의 150건·85% stale은 그 시점 스냅샷으로, 안티봇·캡차·인젝션 지형은 빠르게 바뀌니 내 대상 사이트로 직접 재라(여기 수치는 출발점). 브라우저 에이전트 생태계는 빠르게 바뀌니 분기별로 다시 본다.