브라우저 에이전트가 실제로 어디서 막히나요? 제 경험상 추론 문제는 거의 없네요
Where do your browser agents actually break? For me it's rarely the reasoning
핵심 요약
브라우저 에이전트 개발 시 추론 능력보다 UI 상태, 비동기 로딩, 백그라운드 탭 처리 등 환경적 요인으로 인한 오류가 더 빈번하다는 경험 공유.
- 상태 불일치 — 페이지가 예상한 상태가 아니거나 비동기 로딩으로 인해 에이전트가 잘못된 정보를 기반으로 동작함.
- 백그라운드 탭 — 브라우저가 백그라운드 탭의 렌더링을 중단하여 스크린샷이나 클릭 이벤트가 실패함.
- 검증 패턴 — 작업 후 페이지를 다시 읽어 결과를 확인하는 'read-after-write' 방식이 필수적임.
- 중복 작업 방지 — 작업 실패 시 재시도 과정에서 발생하는 중복 예약이나 게시물 생성 문제를 해결해야 함.
실제 브라우저에서 작업(양식 작성, 포털 이용, 예약, 게시물 업로드 등)을 수행하는 에이전트를 만들고 있다. 이제 모델이 다음에 뭘 해야 할지 제대로 골라내는 건 거의 문제가 안 된다. 진짜 골치 아픈 건 그 주변에서 터지는 온갖 잡다한 문제들이다.
-
누르려는 버튼 위에 떡하니 떠 있는 모달창이나 쿠키 배너
-
탭이 활성화되어 있을 때만 댓글창을 렌더링해서, 백그라운드 탭에서는 아무것도 안 보이는 페이지
-
작업 도중에 갑자기 튀어나오는 로그인 요구 화면
-
작업은 "성공"했다고 뜨는데 정작 저장된 건 아무것도 없는 상황
마지막 게 제일 최악이다. 그래서 이제는 클릭 한 번 믿지 않고, 작업 끝날 때마다 페이지 다시 읽어서 제대로 됐는지 일일이 확인하고 있다.
다들 어떤 문제 때문에 제일 고생하는지 궁금하다. 인증 문제, 불안정한 선택자(selector), 레이트 리밋(rate limit), 아니면 아예 다른 문제인가?

