Why 99% Accurate Browser Agents Still Fail — Derek Meegan, Browserbase

한 줄 핵심

브라우저 에이전트는 데모는 쉬워도 생산 환경에서는 성능·비용·유지보수성과 실패 누적을 함께 해결해야 하며, 이를 위해 모델의 책임을 줄이고 결정론적 도구와 검증을 결합한 시스템 설계가 필요하다.

시간별 요약

1. 0:00
   소개 배경 음악으로 시작하며 발표의 도입부를 연다.
2. 0:12
   데모와 프로덕션의 차이 한 번 성공하는 브라우저 에이전트 데모와, 사이트 변화와 모델의 변동성 속에서 수천 번 무인으로 돌아가야 하는 운영 환경은 전혀 다른 문제다.
3. 0:47
   발표 개요 브라우저와 에이전트의 상호작용을 정리하고, 대규모 운영이 어려운 이유를 설명한 뒤, 가치와 수익 관점에서 실전 시스템을 설계하는 흐름으로 이야기를 전개한다.
4. 1:27
   에이전트가 웹과 상호작용하는 방식 모델 출력은 가능한 행동들의 확률 분포로 보고, 입력 토큰을 바탕으로 행동을 고른 뒤 구조화된 도구 호출로 브라우저를 조작하는 구조를 설명한다. 브라우저는 DOM, 스크린샷, 접근성 트리, 쿠키·탭·URL 같은 상태, 그리고 JavaScript나 CDP를 실행하는 런타임까지 여러 층으로 이루어진다.
5. 2:32
   텍스트, 스크린샷, 코드 산업 현장에서는 HTML과 접근성 트리를 섞은 텍스트 표현, 화면 스크린샷 중심의 computer use, 그리고 브라우저에 직접 코드를 실행하는 동적 실행 환경이라는 세 가지 방식이 주로 쓰인다. 실제 운영 시스템은 대개 첫 번째나 두 번째, 또는 둘의 조합에 의존한다.
6. 3:17
   브라우저 궤적의 종류 브라우저 작업은 단일 목적의 고정 궤적부터, 사용자가 임의의 일을 시키는 즉시 자동화까지 자율성 수준이 다양하다. 규모가 커질수록 여러 단계로 끝나는 거래형 업무가 핵심이 되며, 브라우저 에이전트는 모호한 상황을 처리하는 유연한 실행 환경으로 쓰인다.
7. 4:32
   부분 성공은 인정되지 않음 각 단계마다 비용과 실패 위험은 누적되지만, 가치는 모든 단계를 끝냈을 때만 발생한다. 브라우저 에이전트에서는 중간 성과가 의미 없기 때문에 단계별 누적 실패를 끝까지 견뎌야 한다.
8. 5:22
   99%가 36%로 무너지는 문제 각 단계 성공률이 99%여도 100단계 작업의 전체 성공률은 약 36%까지 떨어질 수 있다. 단계 수가 늘어날수록 신뢰성이 급격히 악화되므로, 단순히 정확도 높은 모델을 쓰는 것만으로는 운영 문제가 해결되지 않는다.
9. 6:12
   수익은 매출에서 비용을 뺀 값 에이전트는 그 자체가 또 하나의 비용 항목이며, 비용보다 더 큰 가치를 만들어야 한다. 고객 맥락에서 브라우저 에이전트의 가치는 반복적으로 작업을 끝내 주는 데 있고, 모호함을 처리하면서도 같은 결과를 안정적으로 내는 시스템이 필요하다.
10. 7:37
    성능, 비용, 유지보수성 가장 먼저 봐야 할 것은 성능이고, 그다음이 비용, 마지막이 유지보수성이다. 성능이 확보되면 비용과 유지보수성은 엔지니어링으로 최적화할 수 있는 문제로 바뀐다.
11. 8:12
    성공의 정의 성공은 실행 결과로 남는 구체적 산출물로 판단해야 한다. 청구서 납부의 확인 이메일, 주문의 주문 ID나 영수증, 폼 제출 후 시스템에 생성된 새 레코드처럼 검증 가능한 흔적이 있어야 한다.
12. 8:42
    실행별 성공과 거래별 성공 한 번의 실행 성공률보다, 재시도를 허용했을 때 하나의 거래를 끝내는 비율이 더 중요하다. 고객은 재시도 횟수가 아니라 실제로 업무가 안정적으로 완료되었는지를 보므로, 성공률은 거래 단위로 측정해야 한다.
13. 9:32
    비용의 분해 비용은 실행당 모델 비용, 인프라와 컴퓨트, 추가 통합과 도구 비용으로 나눌 수 있다. 특히 모델 비용은 오픈소스 생태계와 가격 하락 압력으로 점점 줄어들 가능성이 크다.
14. 10:11
    시간에 따른 유지보수 유지보수에는 에이전트의 판단 과정과 실제 브라우저에서 벌어진 일을 모두 볼 수 있는 관측성이 필요하다. 또한 장애 대응과 재구성에 드는 개발자 시간, 그리고 사이트와 모델 변화에 맞춘 재평가가 계속 들어간다.
15. 10:46
    리스크: 웹은 반격한다 안티봇과 같은 방어 장치 때문에 웹 환경은 에이전트에게 우호적이지 않다. 작업 자체가 변하거나, 더 나은 방법이 생기거나, 모델이 경로를 벗어나는 등 여러 요인으로 시스템의 지속 가능성이 흔들린다.
16. 12:06
    아키텍처: 보험 포털 자동화 실제 사례로 건강보험 포털의 설명서 다운로드 작업을 자동화하는 아키텍처를 단계적으로 확장한다. 요청 처리, 다운로드, 검증, 인증, 업무 절차의 분리 등을 통해 성능·비용·유지보수성을 동시에 개선하는 방향을 보여준다.
17. 13:01
    결정론적 다운로드 도구 다운로드처럼 복잡하지만 반복적인 동작은 모델이 즉흥적으로 판단하게 두지 않고 하나의 도구 호출로 감싼다. 이렇게 하면 브라우저 페이지 조작과 파일 저장소 접근, 런타임으로의 파일 전달을 한 번에 처리할 수 있다.
18. 13:31
    OCR로 검증하기 문서에서 엔터티를 OCR로 결정론적으로 추출하고, 시스템 기록과 비교해 작업이 제대로 끝났는지 확인한다. 에이전트가 스스로 수행 결과를 판별할 수 있게 되면서 실패 여부가 명확해진다.
19. 13:56
    인증 분리하기 인증 흐름은 비즈니스 로직보다 변하지 않는 부분이므로 모델 책임에서 분리해 재사용 가능한 함수로 빼낸다. 이렇게 하면 에이전트가 처리해야 할 단계 수가 줄고, 단가와 유지보수성도 함께 좋아진다.
20. 14:36
    표준 운영 절차로서의 Skills Skills는 에이전트를 위한 표준 운영 절차처럼 작동하며, 모델이 따라야 할 핵심 경로를 명시해 모호성을 줄인다. 단계가 명확할수록 다음에 무엇을 해야 하는지 더 잘 알게 되어 실패 가능성이 낮아진다.
21. 15:26
    최종 시스템 최종 구조에서는 서버리스 인증 함수, 에이전트 런타임, Skill, 결정론적 다운로드 도구, 검증 도구가 연결되어 하나의 거래를 완료한다. 모델이 맡을 필요가 없는 단계를 밖으로 빼서 더 유지보수 가능하고 더 높은 성능의 시스템을 만든다.
22. 16:21
    프로덕션에 오신 것을 환영합니다 이제 시스템은 운영 단계에 들어가며, 곧 온콜 책임까지 따라온다.

실무 인사이트

• 브라우저 에이전트는 모델 정확도보다도 재시도, 검증, 결정론적 도구화를 포함한 전체 거래 성공률로 설계해야 한다.
• 모델이 즉흥적으로 결정할 부분을 줄이고, 인증·다운로드·검증 같은 반복 절차를 도구와 함수로 분리하면 성능과 유지보수성이 함께 개선된다.
• 실무에서는 단계별 성공률보다 고객이 체감하는 완료 결과를 기준으로 지표를 잡아야 운영 판단이 흔들리지 않는다.