32분이 13분이 됐다면, 무엇이 바뀐 걸까요?
보험 포털에서 환자 정보를 찾고 여러 칸을 채운 뒤, 다음 화면의 결과까지 확인하는 업무를 떠올려보세요. 에이전트가 클릭이나 입력을 하나 끝낼 때마다 화면을 다시 보고 모델을 호출한다면 짧은 지연도 계속 쌓입니다. 좌표만 기억해 클릭하면 배너나 메뉴 위치가 달라졌을 때 엉뚱한 곳을 누를 수도 있고요.
Asteroid가 공개한 사례에서는 가장 긴 청구 워크플로가 같은 프롬프트를 유지한 채 32분에서 13분으로 줄었습니다. 다만 이를 ‘페이지 구조를 읽어서 빨라졌다’거나 ‘배칭만으로 빨라졌다’고 단정하면 공개된 비교 범위를 넘어섭니다. Asteroid는 이 결과를 여러 동작을 한 턴에 처리하는 새 interaction loop의 배칭 개선 항목에서 보고했지만, 이때 Claude 4.6으로의 모델 이전도 함께 진행했습니다.
핵심은 세 가지를 구분하는 것입니다. 멀티액션 배칭은 모델과 실행기 사이의 왕복을 줄이고, browser use의 구조 참조는 화면 속 대상을 더 안정적으로 지정하며, 공개된 32분→13분은 이 가운데 배칭만의 독립 효과를 분리한 실험이 아닙니다. 따라서 사례 수치는 새 루프 전체의 관측 결과로 읽고, 각 기능의 기여도는 자사 환경에서 따로 측정해야 합니다.
새 루프에서 호출은 32~52% 줄었습니다
Asteroid는 새 interaction loop를 네 개의 production-style 워크플로에 적용한 결과를 공개했습니다. 이전 루프와 비교해 모델 호출은 32~52%, 작업당 비용은 25~32% 감소했고, 네 업무의 완료율은 모두 100%가 됐다고 보고했습니다.
| 업무 | 모델 호출 | 벽시계 시간 | 완료율 | 작업당 비용 |
|---|---|---|---|---|
| EHR 보고서 추출 | 32% 감소 | 20% 감소 | 90%→100% | 31% 감소 |
| 청구 접수 | 48% 감소 | 59% 감소 | 77%→100% | 32% 감소 |
| EHR 작업 생성 | 46% 감소 | 7% 감소 | 100% 유지 | 29% 감소 |
| 환자 결제 | 52% 감소 | 31% 감소 | 100% 유지 | 25% 감소 |
호출 감소율과 시간 감소율은 같지 않았습니다. EHR 작업 생성은 호출이 46% 줄었지만 시간은 7%만 줄었습니다. 페이지 로딩이나 외부 시스템 응답이 오래 걸리는 업무라면 모델 왕복을 줄여도 전체 시간이 같은 폭으로 줄지 않을 수 있다는 뜻입니다.
이 수치는 Asteroid의 자체 테스트 결과입니다. 실행 횟수와 분산, 이전·신규 모델의 전체 조건, 가격 산식, 재시도와 사람 개입을 집계한 방식은 공개되지 않았습니다. 네 업무에서 나온 완료율 100%를 다른 포털의 예상 성공률로 사용하면 안 됩니다.
배칭과 구조 참조는 서로 다른 문제를 풉니다
멀티액션은 모델 호출 사이의 대기 시간을 줄이는 실행 방식입니다. 이전에는 ‘페이지 읽기→모델 호출→클릭→다시 관찰→모델 호출→입력’처럼 한 번에 한 동작을 처리했다면, 새 computer use는 한 턴에 여러 동작을 순서대로 반환할 수 있습니다. Anthropic과 Asteroid는 새 루프의 개선점으로 이 배칭을 설명합니다.
browser use의 구조 참조는 클릭 대상을 좌표 외의 방식으로 지정합니다. read_page와 find가 접근성 트리의 요소·폼·탭과 함께 ref를 반환하면, Claude는 후속 클릭이나 입력에서 그 참조를 사용할 수 있습니다. 캔버스, 교차 출처 iframe, 가상화 목록처럼 안정적인 참조가 없는 화면에서는 스크린샷과 뷰포트 좌표로 폴백합니다.
다만 browser use는 멀티액션과 구조 참조를 함께 제공하므로, 한 번의 browser use 시험만으로 둘의 효과를 분리할 수는 없습니다. 구조 참조를 평가하려면 같은 업무에서 좌표 오작동과 stale ref 발생을 기록하고, 배칭을 평가하려면 가능한 한 같은 모델과 실행 환경을 유지한 채 단일동작 루프와 멀티액션 루프의 호출 수·시간·비용을 비교해야 합니다.
도구 선택도 화면이 있다는 이유만으로 에이전트부터 붙일 필요는 없습니다. 안정적인 API가 있으면 API를 쓰고, 셀렉터와 절차가 고정된 웹 업무라면 결정론적 브라우저 자동화를 먼저 검토하세요. API가 없고 화면 변화와 예외가 잦을 때 browser use를, 웹 구조를 읽을 수 없는 데스크톱이나 Citrix 화면까지 다뤄야 할 때 computer use를 검토하는 편이 맞습니다.
실행기부터 만들기 전, API 계약을 먼저 확인하세요
공식 Quick start는 완성된 브라우저 프로그램이 아니라 도구 호출과 결과 반환 방식을 보여주는 예제입니다. 예제의 브라우저 처리기는 실제 자동화에 연결되지 않은 stub이므로, 그대로 복사해 페이지가 열리거나 ref 클릭이 실행될 것으로 기대하면 안 됩니다. Claude가 반환한 navigate, read_page, left_click 같은 member tool call을 실제 브라우저에 연결하는 실행기와 반복 호출 루프는 사용자가 구현해야 합니다.
아직 실행기가 없다면 첫 행동의 목표를 ‘브라우저 자동화 성공’이 아니라 ‘구현할 계약과 중단 조건 확인’으로 낮추는 편이 정확합니다.
- 공식 browser use 문서의 Quick start를 엽니다. 요청의
tools배열에 이름 없이{"type":"browser_toolset_20260801"}을 선언하는 부분과, 응답의stop_reason이tool_use일 때 처리하는 루프를 찾으세요. - 현재 코드베이스에 실제 member-tool 처리기가 있는지 확인합니다. 최소한
navigate,read_page,left_click을 실제 브라우저 자동화에 연결하고, 각 결과를toolset_name과 함께 반환할 수 있어야 합니다. stub만 있다면 아직 브라우저 시험 단계가 아닙니다. - 배치 실패 계약을 구현 목록에 넣습니다. 한 턴에 받은 호출은 표시된 순서대로 실행하고 첫 실패에서 멈춰야 합니다. 실행하지 않은 나머지 호출에도 미실행 오류를 반환하고, 모든
tool_use에 대응하는tool_result를 보내야 합니다. - 구조 참조의 수명도 처리합니다.
read_page가 반환한ref만 후속 클릭에 사용하고, 페이지 이동이나 큰 DOM 변경으로 참조가 stale해지면 클릭하지 말고 오류를 반환한 뒤 페이지를 다시 읽도록 설계하세요. - 실제 시험 대상은 팀이 통제하는 스테이징 페이지로 정합니다. 입력값과 예상 요소를 고정하고, 제출 직전에서 멈추게 하세요.
example.com계열은 문서 예시용 도메인이며 콘텐츠·동작·가용성을 테스트 서비스처럼 가정해서는 안 됩니다.
실제 실행기로 넘어갈 때는 Claude API 인증값, browser_toolset_20260801을 지원하는 모델, 최소 권한의 격리 브라우저와 시험 도메인만 여는 네트워크 허용목록이 필요합니다. 기본 toolset 선언은 약 6,600개의 입력 토큰을 추가하고, 스크린샷과 페이지 텍스트도 별도로 입력에 포함됩니다.
성공 기준보다 먼저 중단 조건을 고정하세요
여러 동작을 한꺼번에 받는다고 모두 실행해야 하는 것은 아닙니다. 첫 동작 뒤 화면 상태가 예상과 달라졌거나 참조가 유효하지 않다면, 뒤따르는 입력과 클릭을 중단해야 합니다. 배칭의 가치는 무작정 많은 동작을 실행하는 데 있지 않고, 왕복을 줄이면서도 잘못된 상태에서 멈출 수 있는 데 있습니다.
운영 전 실행기에 넣을 경계는 다음과 같습니다.
ref가 stale이면 클릭하지 않고 페이지를 다시 읽습니다.- 배치의 첫 실패 뒤에는 남은 입력과 클릭을 실행하지 않습니다.
- 제출·구매·메시지 전송·계정 변경은 사람의 확인 전 중단합니다.
- 브라우저는 전용 컨테이너나 VM에 두고 필요한 도메인과 자격증명만 허용합니다.
비교 시험에서는 같은 스테이징 업무와 입력을 사용해 완료율, 모델 호출 수, 벽시계 시간, 총비용, 재시도, 사람 개입 횟수를 함께 기록하세요. 가능하면 모델과 실행 환경을 고정해야 배칭의 기여도를 더 분명하게 볼 수 있습니다. 호출은 크게 줄었는데 전체 시간이 거의 그대로라면 다음 병목은 모델이 아니라 페이지 로딩이나 외부 시스템일 가능성이 큽니다.