브라우저 에이전트 비용을 줄인 핵심: 캐시를 깨뜨리지 않는 기록 관리

배경과 문제

Asana는 인수한 StackAI를 통해 고객이 코드 없이 웹사이트를 탐색하고 양식을 채우는 브라우저 에이전트 워크플로를 만들 수 있게 했다. Asana의 규모에서는 이런 에이전트의 작은 비효율이 큰 비용으로 누적된다. 브라우저 에이전트는 매 호출마다 도구 정의, 시스템 프롬프트, 그리고 페이지 텍스트와 스크린샷으로 이루어진 점점 커지는 히스토리를 다시 보낸다. 프롬프트 캐싱은 반복되는 입력 비용을 낮추지만, 요청의 가장 긴 변경되지 않은 접두사만 재사용할 수 있다.

기존 에이전트는 도구와 시스템 프롬프트만 캐시했고, 히스토리는 캐시하지 않았다. 게다가 에이전트는 거의 매 단계마다 이전 스크린샷을 삭제하고 오래된 텍스트를 잘라내 히스토리 예산에 맞췄다. 이런 편집이 요청의 앞부분을 바꾸기 때문에 캐시 재사용이 거의 매 호출에서 깨졌다. 따라서 단순히 히스토리를 캐시에 추가하는 것만으로는 충분하지 않았고, 히스토리가 얼마나 자주 바뀌는지 자체를 바꿔야 했다.

기존 접근의 한계

개발 기준 설정에서는 Model B의 실행당 평균 추정 모델 비용이 최소 $36.21이었고, 일부 실행은 단계 제한에 도달해 완료되지 못했다. 이는 기준 평균이 하한값임을 의미한다. 실행 시간도 최소 22.5분이 걸렸다. 비용이 높았던 이유는 캐시 읽기 비율이 낮았기 때문이다. 예를 들어 Model B 기준 실행에서는 입력의 약 11%만 캐시에서 읽혔고, 대부분은 할인된 캐시 읽기를 활용하지 못했다.

히스토리 캐싱만 켜는 조건은 오히려 비용을 늘리기도 했다. 480,000자 예산에서 히스토리 캐싱만 적용했을 때 Model A, Model C, Sol 6.1에서는 캐시를 쓰지 않을 때보다 비용이 더 높았다. 캐시 쓰기가 비용의 90% 이상을 차지했지만 캐시 읽기는 입력의 3분의 1 미만이었기 때문이다. 즉, 캐시를 자주 다시 쓰고 거의 읽지 않으면 캐시 쓰기 비용만 추가로 발생한다.

연구방법을 단계별로

Asana의 StackAI CTO인 Frank Hidalgo는 GPT-6 Astra를 Codex에서 사용해 코드베이스를 감사하고 에이전트가 모델 요청을 어떻게 구성하는지 설명하도록 했다. Astra는 에이전트가 고정된 지침과 도구 정의는 캐시하지만, 페이지 텍스트와 스크린샷의 증가하는 히스토리는 캐시하지 않는다는 것을 발견했다. 또한 에이전트가 거의 매 단계에서 오래된 스크린샷을 삭제하고 텍스트를 잘라내 히스토리를 변경한다는 것도 확인했다.

Hidalgo는 Astra가 제안한 수정 사항 중 세 가지를 선택해 테스트했다. 첫째, 캐시를 에이전트의 탐색 히스토리까지 확장한다. 둘째, 유지할 수 있는 텍스트 양을 늘린다. 셋째, 스크린샷을 매 단계가 아니라 배치로 제거한다. Astra는 먼저 빠른 테스트로 어떤 변수가 중요한지 확인한 뒤, 통제된 실험을 위해 코드를 리팩터링해 하나의 프런트엔드와 백엔드가 여러 워크플로를 병렬로 지원하도록 했다.

전체 연구는 120,000자와 480,000자의 두 히스토리 예산과 여섯 가지 캐싱·스크린샷 정책을 네 모델(GPT-6.1 Sol, Model A, B, C)에 각각 세 번씩 테스트했다. 즉 6정책 × 2예산 × 4모델 × 3회 = 144회 실행이 계획·실행되었고, Model A의 기술 실패 한 건을 도표 평균에서 제외해 분석은 143회였다. 각 구성은 동일한 작업을 수행했다: 공개 데모 카탈로그에서 32권의 책에 대해 여섯 필드를 수집하는 것이다.

Sol에서 최적 조건은 더 큰 기록 예산과 20:1 정책의 결합이었다. 기존 스크린샷이 20개를 넘으면 최근 1개를 남기되, 새 이미지를 보호해 잠시 목표 수를 넘을 수 있다. 이렇게 하면 가지치기 사이에 약 19번의 연속 호출이 캐시된 히스토리를 재사용할 수 있다. Model B만 20:10 정책이 최저 평균 비용을 보였고, Sol·A·C는 20:1이었다.

결과와 숫자의 의미

Model B에서 최적화는 추정 모델 비용을 실행당 최소 $36.21에서 $1.24로 줄여 29배 절감했다. GPT-6.1 Sol의 최적화된 워크플로는 $0.47로, Model B 최적화보다 2.6배 더 저렴했다. 따라서 기존 Model B 기준 설정과 비교하면 76배 저렴하다. 실행 시간은 기존 Model B의 최소 22.5분에서 Sol 최적화 워크플로의 약 4분으로 5배 빨라졌다.

Sol 자체만 보면, 더 큰 히스토리 예산에서 새로운 캐싱과 스크린샷 정책이 비용을 $1.97에서 $0.47로 약 4배 줄였다. 각 호출은 약 3배 저렴해졌는데, 입력의 89%가 캐시에서 읽혔고 캐시 읽기 가격이 비캐시 입력 가격의 5%였기 때문이다. 캐시만 켜는 조건은 $2.23으로 오히려 기준보다 비쌌다.

히스토리 예산이 모델에 맞아야 한다는 점도 드러났다. 120,000자 예산에서 Model C는 18회 실행 중 0회, Sol은 3회만 답을 냈고 대부분 단계 제한에 걸렸다. 480,000자 예산에서는 두 모델 모두 18회 전부 답을 냈고 정답 합계를 제시했다. 원문은 작은 예산에서 잦은 기록 삭제와 재방문이 관찰됐다고 설명한다. 이는 이 과제의 실패 양상을 이해하는 근거이며, 모든 최신 모델이 같은 이유로 실패한다는 보편적 결론은 아니다.

정답 품질은 정보 노출, 기록 유지, 답변 생성, 가격 합계 정답을 따로 평가했다. 모든 최적 조건 실행이 192개 사실을 모두 확인했고, Sol은 정답 합계 £1,164.91을 제시했다. 다만 Sol은 요청된 전체 표 대신 총액과 가장 싼 책·비싼 책에 대한 짧은 요약을 반환했다. 모든 모델이 완전한 최종 답을 냈다는 뜻은 아니다.

구체적인 예시

작업은 CAT32로 명명되었으며, 에이전트가 books.toscrape.com이라는 공개 데모 카탈로그를 열고 32권의 책 페이지를 방문해 각 책당 제목, URL, UPC, 가격, 재고 여부, 재고 수량의 여섯 필드를 수집한 뒤 가격 합계와 가장 싼 책·비싼 책을 포함한 표를 반환하는 것이다. 참조 답은 제품 페이지에서 독립적으로 만들어졌고 총액은 £1,164.91이었다.

Sol의 중간 비용 실행을 비교하면 차이가 분명하다. 480,000자 예산의 기준 정책 실행에서는 24번째 호출이 약 40,000 입력 토큰을 싣고 그중 9%만 캐시에서 읽혔으며, 실행은 35회 호출로 끝났다. 최적 조건 실행에서는 24번째 호출이 약 58,000 토큰으로 더 컸지만 93%가 캐시에서 읽혔고, 실행은 24회 호출로 끝났다. Sol은 캐시 읽기를 입력 가격의 0.05배로 하므로 더 크지만 대부분 캐시된 요청이 더 작은 비캐시 요청보다 저렴했다.

한계와 오해하기 쉬운 점

이 연구는 동료 심사된 독립 연구가 아니라 제품 공급자와 사용 기업의 자체 실험이다. 하나의 브라우저 에이전트 설계와 하나의 작업(32권×6필드)만 시험했고, 모델 A/B/C의 실제 이름은 비공개다. 결과는 다른 설계나 작업에서 다를 수 있다.

76배 비교는 기존 Model B+개발 기준 설정(실행당 최소 $36.21)에서 최적화된 Sol($0.47)로 모델과 정책을 함께 바꾼 결과다. Sol 자체의 480,000자 예산 고정 비교는 $1.97→$0.47로 약 4배이며, 캐시만 켜는 조건은 오히려 $2.23이었다. 따라서 76배는 모델 교체와 정책 최적화가 합쳐진 효과다.

미완료·단계 제한 실행이 기준군에 포함되어 기준 비용·시간 및 일부 절감배수는 하한값이다. 예를 들어 Model C와 Sol의 개발 기준 실행은 모두 단계 제한에 걸려 평균이 실제보다 낮게 잡혔다. 또한 모델 간 두 실험 단계는 날짜, 추론 설정, 도구 선택, 캐시 수명이 달라 인과적 모델 우열 실험으로 볼 수 없다.

최저 평균 비용 조건을 사후 선택했고 조건당 주로 3회뿐이다. Model B의 최저 비용 정책은 20:10, Sol·A·C는 20:1이다. 문맥 예산은 문자 수이며 스크린샷을 포함한 전체 토큰 수가 아니다. 비용은 당시 토큰 사용량과 단가로 추정한 모델 API 비용으로, 최신 단가나 인프라·인건비를 포함한 총 운영비가 아니다.

후속 12회에서는 스크린샷을 아예 지우지 않아 호출당 비용이 Model B·Sol에서 약 1.2배 더 낮아졌다. 그러나 실행당 호출 수가 달라 전체 실행 비용의 같은 배수 개선을 뜻하지 않는다. 480,000자 예산을 실제로 채운 실행도 없었으므로 이 과제에서 통했다고 해서 모든 긴 작업의 제한을 없애도 된다는 결론은 아니다.

실제로 어떻게 활용할까

이 실험에서 시험해 볼 수 있는 원칙은 반복 입력의 앞부분을 오래 유지하고, 캐시가 실제로 재사용되는지 공급자의 사용량 기록으로 확인하는 것이다. 기록은 가능하면 뒤에 추가하고, 삭제가 필요하면 묶어서 처리하되 문맥·비용·단계 상한을 둔다. 캐시 마커(표식)나 어댑터는 각 API의 요구에 맞게 구현해야 하므로 하나의 설정을 모든 에이전트에 그대로 적용할 수는 없다. 히스토리 예산, 정답 품질, 호출 수, 캐시 읽기·쓰기 비용을 함께 측정해야 한다.

Asana는 이러한 변경 사항을 StackAI의 브라우저 내비게이션에 출시했고, 유사한 실험을 더 쉽게 반복할 수 있는 도구를 개발 중이다. 장기적으로는 이 테스트를 플랫폼의 평가에 통합해 고객과 내부 팀이 에이전트를 구성할 때 비용, 실행 시간, 답변 품질을 비교할 수 있게 할 계획이다. 또한 Asana는 GPT-6 Astra를 Codex에서 사용해 출시 전 제품 기능을 테스트하고 있으며, Astra가 플랫폼을 탐색하고 다양한 입력을 시도해 인간 QA 검토자를 위해 버그를 보고한다.