Asana 브라우저 에이전트 실행 1회 $36 이상이 $0.47로
비용을 깎은 건 모델이 아니라 캐시 정책이었다
OpenAI가 Asana StackAI의 브라우저 에이전트 최적화 사례를 냈다. 추정 비용이 76분의 1로 줄었고 실행 시간은 5배 빨라졌다. 모델을 바꾼 효과보다 대화 기록을 어떻게 캐시하느냐의 효과가 컸다.
웹사이트를 돌아다니며 폼을 채우는 에이전트 한 번 돌리는 데 $36.21 이상. 보통 이 숫자를 보면 모델이 비싸서라고 생각한다. OpenAI가 10월 9일 공개한 Asana 사례는 반대 방향을 가리킨다. 같은 에이전트가 최적화 후 $0.47, 약 76배 싸졌고 평균 실행 시간은 22.5분 이상에서 약 4분으로 줄었다.
Asana의 StackAI는 코드 없이 웹사이트를 탐색하고 폼을 채우고 정보를 모으는 워크플로를 만드는 플랫폼이다. 이 사례는 그 위에서 돌아가는 브라우저 에이전트를 GPT-6.1 Sol로 다듬은 기록이다.
한 줄 정리
브라우저 에이전트는 모델 단가보다 매 단계 다시 보내는 화면 기록을 캐시에 태우느냐에서 비용이 갈렸고, 그 설정 하나가 모델 교체보다 컸다.
한눈에 보기
| 항목 | 최적화 전 | 최적화 후 |
|---|---|---|
| 다른 연구소 모델 B (기존 운영 모델) | $36.21 이상 | $1.24 (29배 감소) |
| GPT-6.1 Sol | $1.97 | $0.47 (4배 감소) |
| 평균 실행 시간 | 22.5분 이상 | 약 4분 |
| 답을 낸 실행 (큰 기록 한도, Sol) | 3/18 | 18/18 (전부 정답) |
테스트는 144회였다. 32권의 책마다 6개 필드를 수집하는 과제를 모델 4종과 캐시·스크린샷 정책 6종, 기록 한도 2종으로 돌렸다.
비용이 새던 자리
원래 에이전트는 고정된 지시문과 도구 정의만 캐시했다. 단계마다 쌓이는 페이지 텍스트와 스크린샷 기록은 캐시되지 않아 매 요청마다 정가로 다시 보냈다. 거기다 오래된 스크린샷을 지우고 텍스트를 자르는 일을 거의 매 단계 반복해서 기록이 계속 바뀌었고, 바뀐 기록은 캐시가 맞지 않는다.
개선안은 단순했다. 스크린샷을 20장까지 쌓은 뒤 최신 한 장만 남기고 정리한다. 정리 횟수가 줄어 앞부분이 그대로 유지되니 입력의 약 89%가 캐시에서 읽혔다. 캐시 읽기는 정가의 5%다.
공개된 GPT-6.1 Sol 가격표(입력 100만 토큰 $2.00, 캐시 읽기 $0.10)를 보면 20분의 1이라는 게 맞아떨어진다. 기록이 길어지는 에이전트일수록 이 차이가 곱해진다.
정확도도 같이 올랐다
기록 한도를 12만 자에서 48만 자로 늘리자 Sol이 답을 낸 실행이 18회 중 3회에서 18회 전부로 올랐고 정답이었다. 기록을 너무 아끼면 같은 페이지를 다시 방문하고 단계 제한에 걸려 중간에 끝난다. 싸게 만들려고 줄이다가 일을 못 끝내는 쪽이 오히려 더 비쌌다.
위시클레이 관점
에이전트 개발을 외주로 맡겼거나 StackAI 같은 노코드 플랫폼으로 직접 돌리는 팀이라면 청구서에서 확인할 줄이 하나 늘었다. 실행 1회당 비용, 그리고 입력 중 캐시에서 읽힌 비율.
Asana 사례에서 모델 B 하나만 봐도 최적화 전후가 29배 갈렸다. 모델을 더 싼 걸로 바꾸자는 회의를 하기 전에 캐시 적중률을 먼저 묻는 편이 빠르다. 적중률이 낮으면 모델을 바꿔도 청구서의 큰 부분은 그대로 남는다.
작업 시간도 눈여겨볼 만하다. StackAI CTO는 이 튜닝을 손으로 하면 한두 달 걸렸을 거라고 추정했는데 Codex를 쓴 에이전트와 함께 일주일에 끝냈다. 에이전트의 비용 구조를 에이전트에게 분석시키는 순서다. 1인 사업자의 자동화도 마찬가지다. 한 달에 몇 번 돌리는 브라우저 자동화라면 이 차이가 체감되지 않지만 하루 수백 번 돌리는 순간 청구서에서 먼저 드러난다.