r/AI_Agents•약 2개월 전•5•22

브라우저 에이전트가 UI 탐색에 토큰을 너무 많이 낭비한다고 느끼는 사람 또 있음?

Anyone else feel like browser agents waste too many tokens on UI navigation?

핵심 요약

브라우저 에이전트가 UI 탐색 과정에서 토큰을 과도하게 소모하는 문제에 대해 해결책을 논의함.

토큰 낭비 문제 — 에이전트가 UI 탐색에 너무 많은 토큰을 소모함.
결정론적 접근 — Playwright 등을 활용해 탐색 과정을 자동화하고 예측 가능하게 만듦.
접근성 트리 활용 — 스크린샷 대신 접근성 트리를 사용하여 토큰 사용량을 획기적으로 줄임.
워크플로우 캐싱 — 반복적인 클릭 대신 워크플로우를 저장하여 효율성을 높임.

최근 브라우저 에이전트 몇 개를 테스트해봤는데, 계속 같은 패턴이 보이네.

버튼 위치 찾고, 메뉴 탐색하고, 똑같은 워크플로우를 다시 발견하는 데 시간을 너무 많이 써. 정작 작업을 해결하는 것보다 말이야.

모델은 추론에 집중하고 브라우저 상호작용은 좀 더 결정론적으로 처리하는 깔끔한 추상화 계층이 있어야 할 것 같아.

다들 어떻게 처리하고 있는지 궁금함. 워크플로우를 캐싱하거나, 브라우저 API를 쓰거나, 아니면 다른 방법 쓰고 있음?

원문

커뮤니티 목록

r/AI_Agents•약 2개월 전•5•22

브라우저 에이전트가 UI 탐색에 토큰을 너무 많이 낭비한다고 느끼는 사람 또 있음?

Anyone else feel like browser agents waste too many tokens on UI navigation?

핵심 요약

브라우저 에이전트가 UI 탐색 과정에서 토큰을 과도하게 소모하는 문제에 대해 해결책을 논의함.

토큰 낭비 문제 — 에이전트가 UI 탐색에 너무 많은 토큰을 소모함.
결정론적 접근 — Playwright 등을 활용해 탐색 과정을 자동화하고 예측 가능하게 만듦.
접근성 트리 활용 — 스크린샷 대신 접근성 트리를 사용하여 토큰 사용량을 획기적으로 줄임.
워크플로우 캐싱 — 반복적인 클릭 대신 워크플로우를 저장하여 효율성을 높임.

최근 브라우저 에이전트 몇 개를 테스트해봤는데, 계속 같은 패턴이 보이네.

버튼 위치 찾고, 메뉴 탐색하고, 똑같은 워크플로우를 다시 발견하는 데 시간을 너무 많이 써. 정작 작업을 해결하는 것보다 말이야.

모델은 추론에 집중하고 브라우저 상호작용은 좀 더 결정론적으로 처리하는 깔끔한 추상화 계층이 있어야 할 것 같아.

다들 어떻게 처리하고 있는지 궁금함. 워크플로우를 캐싱하거나, 브라우저 API를 쓰거나, 아니면 다른 방법 쓰고 있음?

주요 댓글

r/ai_agents

대부분의 사용자가 브라우저 에이전트의 반복적인 UI 탐색으로 인한 토큰 낭비에 공감하며, 결정론적 자동화나 구조화된 데이터 접근 방식을 해결책으로 제시하고 있습니다.

이런 건 Playwright가 답이지. 반복적인 요소 찾기 다 쳐내고 모델이 진짜로 생각하게 만들어줌.

맞음, Playwright 진짜 좋음. 난 이걸로 UI 빈 곳 탐색하고, 시나리오 전체 확인하고, AI한테 시나리오 던져서 완료에 필요한 작업 리스트 뽑게 하고, 페이지별 매뉴얼 생성하는 데 씀... 전부 미친 듯이 잘 돌아감.

공감함. 요즘 솔루션들은 같은 패턴을 반복하는 데 문제가 있음. 친구랑 이 문제 해결하려고 작업 중인데, 웹사이트 레이아웃을 먼저 매핑하고 결정론적인 맵을 만드는 방식임. Playwright나 Stagehand보다 a) 빠르고 b) 저렴하고 c) 실행 안정성이 높음. 경험에 대해 더 자세히 얘기 나눌 수 있으면 좋겠음 :)

맞음. 모델은 액션 선택만 하게 하고, 결정론적 계층이 셀렉터, 저장된 워크플로우, 재시도, 가능한 경우 직접 API 호출까지 처리하게 했을 때 결과가 더 좋았음. 매번 UI를 다시 찾게 하면 토큰만 날리고 레이아웃 조금만 바뀌어도 바로 깨지거든. 브라우징은 줄이고 실행에 집중해야 함.

맞는 말인데, 진짜 비용은 클릭이 아니라 액션마다 찍는 스크린샷 루프임. 전체 페이지 스크린샷 대신 Playwright의 접근성 트리 스냅샷으로 바꿨더니 세션당 토큰 사용량이 70% 정도 줄었음. 일반적인 웹 UI 트리는 150~300 토큰인데, 1280x720 스크린샷은 700~1000 토큰이나 먹거든. 대부분 브라우저 에이전트가 구현하기 쉬워서 비전(vision)을 기본으로 쓰는데, 진짜 핵심은 하이브리드임. 탐색이랑 상태 확인은 접근성 트리로 하고, 시각적 정보가 꼭 필요할 때만 스크린샷을 쓰는 거지.

어떤 작업들이 반복적으로 시각적 컨텍스트가 꼭 필요하다고 생각함? 지금까지 내 워크플로우 대부분은 시각적 정보 없이도 괜찮았거든, 그냥 궁금해서.

캐시는 클릭 재현이 아니라 압축된 워크플로우 계약(contract) 형태여야 함: 전제 조건, 안정적인 셀렉터나 의미론적 타겟, 성공 조건, 그리고 무효화를 위한 작은 DOM 핑거프린트 같은 거. API가 있으면 바로 API로 보내고, 아니면 결정론적 워크플로우를 돌리면서 모델은 계획이나 복구에만 아껴 써야 함. 핑거프린트가 안 맞으면 그때 다시 흐름을 찾아서 새 버전을 작성하는 거지. 이렇게 하면 일상적인 탐색에 토큰 낭비 안 하면서도 UI 변경 사항을 감지할 수 있음.

WebMCP라고 웹사이트용 MCP가 개발 중임. 에이전트가 일일이 UI를 훑을 필요가 없게 해주는 건데... 채택만 잘 되면 나중에 이 문제 해결될 듯.

이게 표준이 될 가능성이 높음. 솔직히 나중엔 SEO 전문가들이 할 일이 될 거라고 봄.

이건 마치 위성 사진만 보고 도시를 돌아다니면서 문이 어디 있는지 추측하는 거랑 같음. 문제는 '내비게이션'이 아님. DOM을 구조화된 API가 아니라 시각적 퍼즐로 취급하는 게 문제지. 진짜 해결책은 더 깔끔한 추상화가 아님. 모델이 '버튼이 어디 있지?'가 아니라 '의도가 뭐지?'에 집중하게 하고, CSS 선택자 같은 잡일은 결정론적 레이어가 처리하게 해야 함.

그래서 내가 Playwright랑 WebCmd를 같이 보고 있는 거임. 하나는 결정론적인 브라우저 자동화를 제공하고, 다른 하나는 반복적인 브라우저 상호작용을 추상화해서 LLM이 내비게이션보다는 추론에 더 많은 시간을 쓰게 해주거든.

완전 동의함. 브라우저 에이전트들은 종종 'DOM 루핑'에 빠져서 같은 요소를 계속 건드리거나 같은 구조 정보를 반복해서 파싱함. 더 구조화된 '접근성 트리'나 '시맨틱 스냅샷' 방식으로 넘어가서, 에이전트가 페이지의 단순화된 고수준 맵을 기반으로 작동하게 하면 토큰 낭비도 줄이고 내비게이션 속도도 훨씬 빨라질 거임.

혹시 이거 관련해서 링크 걸어줄 만한 문서 있음? 일반적인 스크래핑이 어려운 크롤링 작업 몇 개 있는데 이거 쓰면 딱일 것 같아서.

ㅇㅇ 나도 이게 토큰 제일 많이 잡아먹음. 제일 도움 된 건: 에이전트가 매번 흐름을 다시 찾게 하지 않는 거임. 한 번 작업을 해결하게 한 다음, 작동하는 단계(선택자 + 순서)를 기록하고 그걸 결정론적으로 다시 실행함. 리플레이가 깨지거나 페이지가 기록된 거랑 다를 때만 모델을 다시 투입하는 거지. 즉, LLM은 해피 패스가 아니라 예외 상황만 처리하게 함. 토큰 줄이는 데 도움 된 또 다른 건: 접근성 트리 전체를 컨텍스트에 다 때려 넣지 않는 거임. 상호작용 가능한 요소만 필터링해서...

원문r/AI_Agents