Asana 브라우저 에이전트 테스트, GPT-6.1 Sol로 모델 비용 76배 절감

Asana는 엔지니어들이 브라우징 기록을 유지하고 캐싱하는 방식을 바꾼 뒤 자사의 브라우저 에이전트가 비용은 76분의 1로, 속도는 5배로 개선됐다고 밝혔다. Asana 브라우저 에이전트 테스트에서는 Codex의 GPT-6 Astra를 활용해 시스템을 조사하고, 실험을 실행하며, 트레이스를 분석했다. 이후 최적화된 워크플로에서는 GPT-6.1 Sol이 가장 낮은 추정 모델 비용을 기록했다.

표면적으로 이 결과는 모델의 승리처럼 보인다. 그러나 더 중요한 발견은 에이전트 아키텍처에 관한 것이다. Asana는 에이전트가 스크린샷을 제거하는 시점, 기록 보존 한도를 늘리는 방식, 이전 단계 기록이 누적되는 과정을 캐싱하는 방식을 변경했다. 이러한 변화는 에이전트가 작업을 완료하는 데 필요한 정보를 유지하면서 반복 처리량을 줄였다.

이 차이는 브라우저 에이전트를 평가하는 모든 기업에 중요하다. 팀은 더 저렴한 모델로 전환해도 부실한 컨텍스트 관리로 토큰을 낭비할 수 있다. 반대로 더 성능이 뛰어난 모델을 선택하고 적절한 기록을 보존하면 총 운영 비용을 낮출 수 있다. Asana의 실험은 이 두 전략을 직접 경쟁시키고 있다.

Asana 브라우저 에이전트 연구는 모델 이상의 것을 바꿨다

Asana의 가장 큰 개선은 단순히 한 모델을 다른 모델로 교체한 것이 아니라, 모델을 중심으로 워크플로를 재설계한 데서 나왔다.

회사는 2026년 10월 8일 결과를 공개했으며, 이어 10월 9일 OpenAI 사례 연구가 발표됐다. 이 작업은 Asana가 2026년 초 인수한 노코드 자동화 플랫폼 StackAI 내부의 브라우저 에이전트에 초점을 맞췄다.

StackAI는 고객이 웹사이트를 탐색하고, 정보를 수집하며, 비즈니스 애플리케이션 전반에서 양식을 작성하는 에이전트를 만들 수 있게 한다. 이러한 워크플로는 사람이 웹을 탐색하는 방식과 유사하지만, 내부의 에이전트는 지침, 도구, 페이지 텍스트, 스크린샷, 이전 행동을 모델에 반복해서 전송한다.

이처럼 반복되는 컨텍스트는 비용이 많이 드는 패턴을 만든다. 새 단계마다 이전 단계보다 더 많은 기록이 포함된다. 이전 콘텐츠가 계속 바뀌면 제공업체는 캐시된 표현을 안정적으로 재사용할 수 없다.

Asana의 기존 에이전트는 고정 지침과 도구 정의를 캐싱했다. 하지만 누적되는 브라우징 기록은 효과적으로 캐싱하지 못했다. 에이전트는 오래된 스크린샷을 제거하고 텍스트를 자주 잘라내면서 요청의 앞부분을 변경하기도 했다.

이러한 편집은 연속된 모델 요청이 공유하는 변경되지 않은 시작 부분인 안정적 프리픽스를 깨뜨렸다. 그 프리픽스가 바뀌면 브라우징 기록의 상당 부분을 다시 처리해야 했다.

Asana의 최고기술책임자(CTO)인 StackAI의 Frank Hidalgo는 Codex의 GPT-6 Astra에 이 동작을 점검하도록 지시했다. 모델은 코드베이스를 매핑하고, 요청이 조립되는 방식을 검토하며, 테스트할 가치가 있는 변수를 식별했다.

Asana에 따르면, 이번 연구는 4개 프런티어 모델을 대상으로 144회의 주요 실행을 포함했다. 캐싱 및 스크린샷 정책 6종, 기록 보존 한도 2종, 각 조건당 3회 실행을 테스트했다. 회사는 이후 더 작은 규모의 후속 실험도 진행했다.

각 구성에는 동일한 과제가 주어졌다. 브라우저 에이전트는 공개 데모 카탈로그에 있는 32권의 책 각각에 대해 6개 필드를 수집해야 했다. 즉, 올바른 최종 답변을 반환할 만큼 충분한 컨텍스트를 유지하면서 192개의 사실을 찾아야 했다.

모델에는 GPT-6.1 Sol과 익명 처리된 대안 3종이 포함됐다. Asana는 이 시스템들을 모델 A, B, C로 불렀다. 모델 B는 기존 프로덕션 구성을 구동했고, 모델 C는 같은 제공업체의 더 새로운 모델을 나타냈다.

Asana는 해당 제공업체를 공개하지 않아 직접적인 경쟁 비교에는 한계가 있다. 다만 최적화된 GPT-6.1 Sol 워크플로의 비용은 기존 모델 B 설정보다 76배 낮았다고 밝혔다. 완료 속도도 약 5배 빨랐다.

회사는 이후 StackAI에 브라우저 탐색 변경 사항을 출시했다. Asana가 광범위한 고객 수준 성능 데이터는 공개하지 않았지만, 이는 이번 작업을 실험실 비교에서 프로덕션 변경으로 전환한다.

프롬프트 캐싱이 결정적 메커니즘이 된 이유

결정적 변수는 에이전트가 호출 사이에 누적된 기록 대부분을 변경하지 않은 상태로 유지할 수 있었는지였다.

프롬프트 캐싱은 변경되지 않은 프롬프트 프리픽스와 연결된 재사용 가능한 계산 상태를 저장한다. 이후 요청은 동일한 자료를 처음부터 다시 처리하는 대신 이 상태를 재사용할 수 있다.

캐시는 재생을 위한 완성된 답변을 저장하지 않는다. 모델은 여전히 새로운 자료를 처리하고 새 응답을 생성한다. 다만 동일하게 유지되는 적격 컨텍스트에 대해 반복 작업을 피한다.

OpenAI의 프롬프트 캐싱 가이드는 안정적인 지침과 참조 자료를 변경되는 콘텐츠보다 앞에 배치할 것을 권장한다. 또한 애플리케이션이 이전 대화를 반복해서 다시 작성하는 대신 대화 기록을 추가해 나가도록 조언한다.

Asana의 기존 설계는 브라우저 실행 중 이 두 번째 원칙을 위반했다. 거의 모든 단계에서 이전 스크린샷을 제거했고, 때로는 오래된 텍스트도 잘라냈다. 따라서 다음 요청은 기록의 중간 부분이 달라졌다.

고정 시스템 프롬프트만 캐싱해서는 가장 큰 반복 입력 원인을 포착할 수 없었다. 브라우저 에이전트는 작업을 진행하면서 페이지 텍스트, 스크린샷, 관찰 결과, 도구 결과를 축적했다.

Asana는 배치 프루닝이라고 부르는 다른 정책을 테스트했다. 프루닝은 누적된 기록이 너무 커지기 전에 오래된 컨텍스트를 삭제하는 것을 뜻한다. 선택된 정책에서 에이전트는 가능한 한 20개의 스크린샷을 보존한 뒤 세트를 최신 스크린샷 하나로 줄였다.

이 접근법은 추가만 이뤄지는 기록의 구간을 더 길게 만들었다. 에이전트는 매 단계마다 이전 콘텐츠를 바꾸지 않고 끝부분에 새로운 관찰 결과를 추가할 수 있었다. 그 결과 각 요청의 더 많은 부분이 재사용 대상이 됐다.

최적화된 워크플로는 텍스트 기록 보존 한도도 12만 자에서 48만 자로 늘렸다. 이에 따라 에이전트는 이전에 수집한 사실을 버리지 않고 보존할 여유를 더 확보했다.

더 큰 한도는 작업 완료에 중요한 영향을 미쳤다. 작은 기록 설정에서 GPT-6.1 Sol은 18회 실행 중 단 3회에서만 답변을 생성했다. Asana에 따르면 더 큰 설정에서는 18회 모두 답변을 생성했다.

Asana는 이처럼 더 큰 기록을 사용한 모든 실행이 정답을 반환했다고 밝혔다. 이 결과는 컨텍스트를 공격적으로 축소하는 것이 항상 에이전트 효율성을 높인다는 가정에 이의를 제기한다.

컨텍스트를 삭제하면 요청의 즉각적인 크기는 줄어든다. 그러나 에이전트가 페이지를 다시 방문하거나, 도구 호출을 반복하거나, 이전에 수집한 증거 없이 작업을 계속하도록 만들 수 있다. 삭제로 요청 프리픽스가 변경되면 캐시 재사용도 깨질 수 있다.

따라서 최선의 정책은 전체 작업 경제성에 달려 있다. 팀은 입력 처리, 반복 탐색, 완료율, 응답 품질, 실패 실행의 복구를 고려해야 한다.

Asana는 최적화된 설정에서 GPT-6.1 Sol의 입력 중 89%가 캐시에서 왔다고 보고했다. 이 비율은 더 성능이 뛰어난 모델이 전체 작업 기준으로는 테스트된 선택지 중 가장 저렴해질 수 있었던 이유를 설명한다.

이것이 Asana 브라우저 에이전트 결과의 핵심 메커니즘이다. 회사는 단순히 모델에 더 적은 토큰을 사용하라고 요청한 것이 아니다. 반복 토큰의 처리 비용이 낮아지도록 워크플로를 재구성했다.

더 많은 컨텍스트가 에이전트의 안정적 완료를 도왔다

가장 저렴한 요청이 항상 가장 저렴한 완료 워크플로의 일부인 것은 아니라는 점을 실험은 시사한다.

에이전트 개발자는 종종 컨텍스트를 최소화해야 하는 자원으로 취급한다. 긴 프롬프트는 입력 처리량을 늘리고 모델의 컨텍스트 한도에 가까워질 수 있으므로 이는 타당한 관점이다.

브라우저 에이전트는 계산을 복잡하게 만든다. 이전 관찰 결과가 작업 메모리 역할을 하기 때문이다. 주소, 제품 속성, 경고 또는 탐색 결과를 제거하면 에이전트가 최종 답변을 완성하지 못할 수 있다.

더 작은 기록 보존 한도는 일부 모델에서 특히 약한 결과를 낳았다. Asana는 해당 조건에서 모델 C가 18회 실행 전체에서 답변을 전혀 반환하지 못했다고 보고했다. GPT-6.1 Sol은 단 3개의 답변만 반환했다.

이러한 실패가 모델에 일반적인 브라우징 능력이 부족하다는 증거는 아니었다. 더 큰 기록 보존 한도가 결과를 바꿨다. 두 모델 모두 필요한 기록을 유지할 충분한 공간을 받은 뒤에는 모든 실행에 답변했다.

이 결과는 더 넓은 엔지니어링 원칙을 뒷받침한다. 컨텍스트 정책은 모델과 작업에 맞아야 한다. 단 하나의 보편적 토큰 한도로는 서로 다른 시스템에서 동등한 동작을 만들 수 없다.

모델은 서로 다른 설명, 도구 호출, 추론 트레이스를 생성하므로 각기 다른 속도로 컨텍스트를 소비할 수 있다. 한 에이전트는 적은 수의 행동 뒤 프루닝 임계값에 도달할 수 있는 반면, 다른 에이전트는 훨씬 더 오래 계속할 수 있다.

Asana는 더 새롭거나 더 성능이 뛰어난 모델이 작은 한도를 자동으로 더 효율적으로 사용하지는 않는다는 사실을 발견했다. 테스트된 워크플로에서 모델 C는 모델 A보다 훨씬 이른 시점에 기록을 자르기 시작했다.

실험은 캐싱만으로는 충분하지 않다는 점도 확인했다. 더 큰 기록 보존 한도에서 배치 프루닝 없는 캐싱은 4개 모델 중 3개에서 캐싱하지 않는 것보다 비용이 더 많이 들었다.

요청 구조를 고려하면 이 결과는 모순적이지 않다. 애플리케이션이 재사용하려는 자료를 계속 다시 작성하면 캐시는 제한적인 가치만 제공한다. 시스템은 변화하는 기록을 처리하는 비용을 지불하면서도 충분한 미래 캐시 적중을 얻지 못한다.

Asana가 선택한 정책은 세 가지 결정을 조정했다. 기록을 캐싱하고, 더 오랫동안 추가 전용 시퀀스를 유지하며, 트리밍이 필요해지기 전 더 큰 보존 한도를 제공했다.

후속 실험은 또 다른 질문을 제기했다. Asana는 프루닝 대신 모든 스크린샷을 유지하는 구성을 테스트했다. 일부는 이 특정 작업에서 선택된 정책보다 더 낮은 호출당 비용을 제공했다.

회사는 이를 프루닝이 사라져야 한다는 증거로 보지 않았다. 더 긴 워크플로는 컨텍스트 한도를 초과할 수 있고, 일부 제공업체는 캐시 작업에 더 높은 비용을 부과한다. 불필요한 브라우징으로 벗어나는 에이전트에게도 확고한 경계가 필요하다.

Asana는 단계 수, 토큰, 총 실행 비용에 상한을 둘 것을 권장한다. 이러한 제한은 잘못 동작하거나 혼란에 빠진 에이전트가 기록을 무한정 확장하는 것을 막는다. 오래된 기록을 더 짧은 요약으로 대체하는 컴팩션도 또 다른 선택지다.

컴팩션에는 자체적인 절충점이 있다. 컨텍스트 크기를 줄이지만 이전 프롬프트를 바꿔 캐시 재사용을 방해할 수 있다. 또한 요약은 나중에 중요해지는 세부 사항을 누락할 수 있다.

이 때문에 팀에는 활성 프롬프트 밖의 기록이 필요하다. Asana는 소프트웨어 제공 플랫폼인 Command에 요청, 트레이스, 결과를 기록했다. 그러면 엔지니어와 추가 에이전트가 전체 실험을 검토할 수 있다.

지속 가능한 기록은 검색 가능한 지식 기반도 지원한다. 활성 에이전트는 현재 단계에 필요한 컨텍스트만 받는 반면, 검토자는 완전한 증거 추적에 계속 접근할 수 있다.

이 분리는 팀이 모델 메모리와 조직 메모리를 구분하도록 돕는다. 에이전트의 작업 컨텍스트는 제한된 상태로 유지해야 한다. 실험 기록은 결정을 재현하고 실패를 조사할 수 있을 만큼 상세하게 남아야 한다.

GPT-6 Astra는 평가 작업을 에이전트 작업으로 전환했다

Asana는 한 모델로 시스템을 개선하고, 다른 모델로 최적화된 프로덕션 워크플로를 실행했다.

GPT-6 Astra는 Codex 내부에서 연구 및 엔지니어링 에이전트로 작동했다. GPT-6.1 Sol은 브라우저 에이전트의 런타임 모델 중 하나로 사용됐다. 이들을 별개의 역할로 다루면 결과를 오해하는 것을 방지할 수 있다.

Hidalgo는 연구 방향을 설정하고 시험할 가치가 있는 제안된 변경 사항을 골랐다. GPT-6 Astra는 코드를 점검하고 요청을 계측했으며, 예비 실험을 수행해 영향력이 큰 변수를 파악했다.

기존 코드는 통제된 비교를 위해 설계된 것이 아니었다. Asana는 Codex 에이전트가 시스템을 리팩터링해 하나의 공통 프런트엔드와 백엔드가 여러 실험 워크플로를 병렬로 지원할 수 있게 했다고 밝혔다.

이후 GPT-6 Astra는 연구를 시작하고 사용 기록을 분석했으며 결과물을 비교했다. 별도의 모델 세션들이 작업의 일부를 검토했고, 사람들은 결론을 평가하고 프로덕션 변경 사항을 승인했다.

Asana는 이 프로젝트에 수작업으로 한두 달이 필요했을 것으로 추산한다. Codex 워크플로를 활용하자 조사는 약 일주일 만에 끝났다.

이 주장은 독립적인 평가가 아니라 회사 측의 설명이다. 또한 시스템에 익숙한 기술 임원이 주도한 하나의 엔지니어링 프로젝트를 설명한다. 다른 팀이 같은 수준의 일정 단축을 기대해서는 안 된다.

그럼에도 이 워크플로는 코딩 에이전트 활용 방식의 중요한 변화를 보여 준다. 에이전트는 완성된 명세에 따라 기능만 구현한 것이 아니었다. 실증적 조사의 설계와 실행을 도왔다.

조사 과정에서는 추적 기록, 실험 결과, 티켓, 풀 리퀘스트가 만들어졌다. 이러한 산출물은 변경 사항이 StackAI 프로덕션에 도달하기 전에 Command를 거쳤다.

이 과정은 AI 에이전트가 기계적인 작업 대부분을 수행했다는 주장보다 더 중요하다. 안정적인 기록이 없다면 검토자는 어떤 구성이 실행됐는지, 왜 실패했는지, 보고된 개선 효과가 코드 변경 이후에도 유지됐는지를 신뢰성 있게 판단할 수 없다.

Asana 연구는 사람이 목표와 평가 기준을 수립했다고 설명한다. 사람들은 결과도 검토했다. 코딩 에이전트는 그 결정들 사이에서 팀이 수행할 수 있는 실험의 양을 늘렸다.

Hidalgo는 잠들기 전 목표를 설정하고 다음 날 아침 결과를 검토하는 일상을 설명했다. 이러한 비동기 패턴은 에이전트 실행 시간을 엔지니어링 자원으로 바꾼다.

동시에 병목 지점도 옮긴다. 실험을 쉽게 생성할 수 있게 되면, 사람은 타당한 질문을 고르고 측정값을 확인하며 오해를 부르는 결론을 걸러내는 데 더 많은 시간을 써야 한다.

위험은 자동화된 실험 노이즈다. 에이전트는 강력한 증거를 만들지 못한 채 많은 실행을 만들어낼 수 있다. 반복 테스트는 여전히 벤치마크 설계, 숨겨진 작업 변동, 채점 오류에 취약하다.

Asana는 고정된 작업과 독립적으로 준비한 기준 답변을 사용해 이 위험의 일부를 줄였다. 또한 텍스트 길이로 토큰 소비량을 추정하지 않고 공급업체가 제공한 사용량 카운터를 기록했다.

회사는 대부분의 구성에 대해 세 번만 반복 실행했다. Asana는 이 연구가 광범위한 패턴을 드러낼 뿐, 몇 퍼센트포인트 차이를 신뢰성 있게 보여 주지는 않는다고 명시했다.

이 단서는 중요하다. 76배와 5배 비교는 주목할 만큼 크지만, 아키텍처와 모델 변경을 함께 포함한다. 이는 GPT-6.1 Sol의 보편적인 우위를 분리해 입증하지는 않는다.

Asana의 내부 결과는 Model B도 최적화된 워크플로를 받은 뒤 크게 개선됐음을 보여 준다. GPT-6.1 Sol이 비용을 추가로 낮추기 전부터 아키텍처가 개선 효과의 상당 부분을 차지했다.

76배 주장이 입증하지 않는 것

공개된 결과는 설득력 있는 엔지니어링 증거이지만, 브라우저 에이전트 시장의 중립적 벤치마크는 아니다.

이 연구는 공개 도서 카탈로그에서 하나의 구조화된 작업을 사용했다. 각 실행은 같은 목표를 따르고 동일한 필드 집합을 수집했다. 실제 엔터프라이즈 브라우징에는 흔히 인증, 변하는 레이아웃, 모호한 지시, 예상치 못한 대화상자로부터의 복구가 포함된다.

반복적인 추출에 탁월한 워크플로는 조달, 지원, 컴플라이언스 또는 내부 운영에서는 다르게 작동할 수 있다. 이러한 작업은 유사한 페이지에서 반복적으로 수집하는 것보다 여러 시스템에 걸친 판단을 요구할 수 있다.

Asana의 브라우저 에이전트 테스트는 GPT-6.1 Sol을 익명화된 세 가지 모델과도 비교했다. 독자는 공급업체별 설정을 검토하거나 각 대안이 독립적인 최적화 후 어떻게 수행될지 판단할 수 없다.

Asana는 연구 기간에 Models B, C, GPT-6.1 Sol의 표준 가격이 비슷했다고 밝혔다. Model A는 더 저렴한 대안으로 설정됐다. 공개 기사에서는 이들의 이름을 밝히지 않았다.

이러한 익명성은 결과가 깔끔한 모델 순위표가 되는 것을 막는다. 동시에 충분한 실험으로 뒷받침되지 않는 공급업체 비교로 연구가 흘러가는 것도 방지한다.

가장 큰 헤드라인은 최적화된 GPT-6.1 Sol 워크플로를 Model B의 기존 프로덕션 구성과 비교한다. 모델과 에이전트 아키텍처라는 두 변수가 동시에 바뀌었다.

더 좁은 비교에서는 새 정책을 GPT-6.1 Sol 내에 적용했을 때 비용이 4분의 1로 줄었다. 나머지 차이는 해당 최적화 시스템을 이전 프로덕션 기준선과 비교하면서 발생했다.

이는 결과를 약화하지 않는다. 다만 결론을 바꾼다. 연구는 단순히 모델 교체를 전체 해법으로 보는 것이 아니라, 성능 있는 모델과 컨텍스트 인지형 아키텍처를 결합하는 방식을 뒷받침한다.

5배의 실행 시간 개선에도 비슷한 단서가 따른다. 일부 기존 Model B 실행은 완료 전에 단계 한도에 도달했다. 따라서 이들의 측정된 실행 시간은 전체 작업 완료 시간의 하한을 나타낸다.

완료 품질 역시 지속적인 관찰이 필요하다. Asana는 최적 조건의 모든 실행이 필요한 사실을 찾고 정확한 답변을 만들었다고 보고한다. 공개 자료에는 고객 워크로드나 장기 오류율이 포함돼 있지 않다.

전체 연구가 Asana의 구현 및 추적 기록에 의존하기 때문에 독립적인 재현은 여전히 제한적이다. 회사는 방법론과 더 상세한 연구를 공유했지만, 외부 팀은 여전히 자체 작업 모음이 필요하다.

StackAI 인수 역시 결과에 대한 상업적 이해관계를 만든다. Asana는 교차 시스템 에이전트 워크플로를 확장하기 위해 2026년 5월 StackAI 인수를 완료했다.

OpenAI 역시 GPT-6 Astra와 GPT-6.1 Sol이 엔터프라이즈 에이전트를 어떻게 지원하는지 보여 줄 이해관계가 있다. 두 1차 출처는 가치 있는 기술적 세부 정보를 제공하지만, 어느 쪽도 독립적인 산업 감사를 대표하지는 않는다.

운영 조건도 결과를 바꿀 수 있다. 캐시 가용성에는 제한된 유지 기간이 있다. 동시 고객은 서로 다른 기록을 가질 수 있고, 개인화된 컨텍스트는 공유 가능한 자료의 양을 줄일 수 있다.

개인정보 보호 요구사항은 어떤 콘텐츠가 모델 컨텍스트에 들어갈 수 있는지를 제한할 수 있다. 보안팀은 브라우징 중 수집되는 스크린샷, 자격 증명, 고객 기록, 민감한 정보에 대한 통제도 필요하다.

캐싱이 이런 의무를 없애지는 않는다. 이는 데이터 거버넌스의 필요성이 아니라 연산 및 청구 방식을 바꾼다. 팀에는 여전히 보존 정책, 접근 제어, 감사 추적, 장애 처리 절차가 필요하다.

따라서 올바른 결론은 조건부다. Asana는 특정 브라우저 에이전트에서 높은 가치의 최적화를 찾아 프로덕션에 적용했다. 다른 팀은 이 메커니즘을 검증 가능한 가설로 다뤄야 한다.

다음 시험은 실제 고객 워크플로 전반의 성능이다

향후 세 가지 신호는 Asana의 결과가 재사용 가능한 운영 모델이 될지, 강력한 내부 사례 연구에 머물지를 보여 줄 것이다.

첫 번째 신호는 더 폭넓은 평가 범위다. Asana는 고객과 내부 팀이 에이전트를 구성할 때 비용, 실행 시간, 답변 품질을 비교할 수 있는 도구를 개발 중이라고 밝혔다.

이러한 평가에는 구조화된 카탈로그 추출을 넘어선 작업이 필요하다. 유용한 테스트 모음에는 변하는 웹사이트, 인증이 필요한 애플리케이션, 부분 실패, 긴 탐색 경로, 종료 지점이 모호한 지시가 포함돼야 한다.

같은 기록 정책이 이러한 워크플로에서도 개선을 보인다면 아키텍처 주도 최적화의 근거는 더 강해진다. 개선 폭이 줄어든다면 Asana가 선택한 구성은 반복적 추출에 밀접하게 묶여 있을 수 있다.

두 번째 신호는 프로덕션 도입의 증거다. Asana는 이미 브라우저 탐색 변경 사항을 StackAI에 배포했지만, 고객 전체의 집계 결과는 공개하지 않았다.

완료율은 호출당 비용보다 더 중요해야 한다. 고객이 작업을 재실행하거나 불완전한 결과물을 수동으로 보완해야 한다면 저렴한 요청은 큰 가치가 없다.

팀은 캐시에서 제공되는 입력의 비율, 작업 시간 중앙값, 단계 한도 실패, 사람의 개입 비율도 지켜봐야 한다. 이러한 지표는 최적화된 설계가 변동적인 프로덕션 트래픽에서도 유지되는지를 보여 준다.

세 번째 신호는 경쟁 모델 공급업체와 에이전트 플랫폼이 어떻게 대응하는지다. 프롬프트 캐싱은 제품 기능이 됐지만, 개발자가 이를 활용할 수 있는지는 애플리케이션 아키텍처가 결정한다.

공급업체는 더 긴 캐시 보존 기간, 더 나은 진단 기능, 더 낮은 캐시 입력 요금, 더 명확한 사용량 데이터를 통해 경쟁할 수 있다. 에이전트 프레임워크는 모든 고객이 맞춤형 계측을 구축하도록 강요하지 않고 기록 정책을 노출할 수 있다.

OpenAI는 GPT-6.1 Sol을 GPT-6 Astra보다 낮은 운영 비용으로 유능한 에이전트 작업을 수행하는 모델로 제시한다. Asana의 연구는 이 포지셔닝에 구체적인 애플리케이션 사례를 제공한다.

그러나 가장 강한 경쟁 압력은 에이전트 소프트웨어 팀에 가해진다. 고객은 단순한 모델 선택기만 제공하는 대신 플랫폼이 전체 작업 비용을 자동으로 최적화하기를 점점 더 기대할 것이다.

성숙한 플랫폼은 관찰된 행동을 바탕으로 컨텍스트 한도를 권장해야 한다. 캐시를 깨는 편집을 식별하고, 정책을 비교하며, 가지치기로 인해 에이전트가 이전 페이지를 다시 방문할 때 경고해야 한다.

또한 사람이 결과를 감사할 수 있을 만큼의 외부 증거를 보존해야 한다. 브라우저 에이전트에는 제한된 작업 메모리가 필요하지만, 조직에는 완전한 운영 기록이 필요하다.

Asana는 유사한 테스트를 평가 시스템에 통합할 계획이다. 또한 Codex에서 GPT-6 Astra를 사용해 제품 기능을 탐색하고, 다양한 입력을 시험하며, 사람 검토자를 위한 버그를 보고하고 있다.

이 확장은 이야기를 하나의 브라우저 에이전트 너머로 넓힌다. Asana는 엔지니어링 에이전트가 다른 에이전트와 제품 기능을 지속적으로 평가할 수 있는지 시험하고 있다.

기회는 분명하다. 자동화된 실험은 소규모 엔지니어링 팀이 수동으로 시험할 수 있는 것보다 더 많은 구성을 평가할 수 있다. 또한 추적 분석에서 검토된 코드 변경까지의 경로를 단축할 수 있다.

제약도 마찬가지로 분명하다. 에이전트가 실험, 발견, 패치를 지속적으로 생성할 수 있게 되면 사람의 주의력이 희소한 자원이 된다. 팀은 어떤 결과를 신뢰하고 프로덕션에 노출할지 결정해야 한다.

개발자가 당장 해야 할 일은 개별 호출이 아니라 전체 작업을 측정하는 것이다. 현실적인 조건에서 캐시 적중 비율, 완료 품질, 실행 시간, 재시도, 사람의 보완 작업을 기록해야 한다.

엔터프라이즈 구매자는 공급업체에 에이전트가 늘어나는 기록을 어떻게 관리하는지 물어야 한다. 모델 이름만으로는 주변 시스템이 유용한 컨텍스트를 보존하는지, 아니면 이를 처리하는 데 반복적으로 비용을 지불하는지를 알 수 없다.

지식 근로자에게 이러한 변화는 더 빠르고 더 유능한 브라우저 자동화를 약속한다. 그 가치는 에이전트가 민감한 데이터를 노출하거나 불필요한 단계를 거치지 않고 필요한 사실을 유지할 수 있는지에 달려 있다.

Asana의 브라우저 에이전트 결과는 이제 컨텍스트 설계가 모든 에이전트 평가에서 모델 선택과 나란히 놓여야 한다는 설득력 있는 근거를 제시한다. 다음 질문은 이 교훈이 고객이 실제로 자동화하려는 복잡한 워크플로 전반에서 통하는지다.