Asana, GPT-6.1 Sol로 브라우저 에이전트 비용을 76분의 1로 줄이다

Asana는 범위가 좁은 엔지니어링 문제를 운영 환경에서 에이전트를 돌리는 모든 팀에 도움이 되는 사례로 만들었다. Asana의 StackAI 플랫폼에서는 고객이 코드를 작성하지 않고도 웹사이트를 탐색하고, 양식을 채우고, 정보를 수집하는 워크플로를 만들 수 있다. Asana 규모에서는 브라우저 에이전트의 작은 비효율도 방대한 실행 횟수에 곱해진다. StackAI의 CTO인 Frank Hidalgo 박사는 이 에이전트를 더 빠르고 저렴하게 만들기로 했다. 그는 Codex의 GPT-6 Astra에게 에이전트를 조사하고, 개선안을 시험하고, 결과를 비교하도록 지시했다. 공개된 결과는 분명하다. GPT-6.1 Sol에서 최적화한 워크플로는 추정 모델 비용이 평균 0.47달러, 실행당 약 4분이다. 모델 B에서 돌던 기존 운영 구성보다 76배 저렴하고 5배 빠르다. Hidalgo는 손으로 하면 한두 달이 걸렸을 작업이라고 추정하는데, 실제로는 약 일주일이 걸렸다.

원인은 에이전트가 모델 요청을 조립하는 방식에 있었다. GPT-6 Astra는 먼저 코드베이스를 정리하고 각 요청이 어떻게 만들어지는지 설명했다. 에이전트는 고정된 지침과 도구 정의는 캐시했지만, 수집한 페이지 텍스트와 스크린샷으로 이루어진 계속 커지는 기록은 캐시하지 않았다. 그래서 요청마다 그 기록을 전액으로 다시 보냈다. 게다가 에이전트는 거의 모든 단계에서 오래된 스크린샷을 버리고 텍스트를 잘라냈다. 이런 편집은 그때마다 기록을 바꾼다. 프롬프트 캐시는 안정적인 앞부분에 적용되므로, 기록의 앞쪽이 바뀌면 그 뒤 전체가 무효가 된다. 기록만 캐시했어도 효과가 없었을 것이다. 정보를 잃으면 이미 읽은 페이지를 다시 방문해야 할 수도 있어 숨은 비용이 생긴다. 캐시, 보존량, 정리 시점은 하나의 설계 문제이며, 일부만 고치면 청구액이 그대로일 수 있다는 교훈이다.

Hidalgo는 GPT-6 Astra가 제안한 수정안을 검토해 세 가지를 시험하기로 했다. 캐시를 탐색 기록으로 확장하는 것, 보존할 수 있는 텍스트 양을 늘리는 것, 스크린샷을 매 단계가 아니라 묶음으로 제거하는 것이다. Astra는 먼저 빠른 시험으로 어떤 변수가 중요한지 확인했다. 기존 코드는 통제된 실험을 염두에 두고 만들어지지 않아서, Astra는 하나의 프런트엔드와 백엔드가 각자 설정을 가진 여러 워크플로를 병렬로 실행하도록 코드를 리팩터링했다. 이어 전체 연구를 수행했다. 기록 예산은 12만 자와 48만 자 두 가지, 캐시와 스크린샷 정책은 여섯 가지이며, 각 조건을 네 모델에서 세 번씩 시험했다. 모두 144회다. 가장 좋은 정책은 스크린샷이 20장까지 쌓이도록 둔 뒤 가장 최근 한 장만 남기는 것이었다. 삭제와 삭제 사이에 이전 기록이 오래 변하지 않으므로 캐시가 유효하게 유지된다. 더 큰 기록 예산과 결합한 이 방식이 최적화된 워크플로가 되었다.

실험 설계도 눈여겨볼 만하다. 모든 구성은 같은 과제를 수행했다. 공개 데모 카탈로그의 책 32권 각각에 대해 여섯 개 항목을 수집하는 일로, 일부 Asana 고객이 StackAI에서 실행하는 작업을 대표한다. 비교한 네 모델은 GPT-6.1 Sol과 다른 선두 연구소의 세 모델이다. 모델 A는 2025년 가을에 나온 더 작고 저렴한 모델로 가격이 GPT-6.1 Sol의 절반이다. 모델 B는 기존에 운영에서 쓰던 2026년 여름 모델로 가격이 같다. 모델 C는 모델 B의 업데이트 버전으로 2026년 가을에 나왔고 가격이 같다. 네 모델 중 셋이 GPT-6.1 Sol과 같거나 더 싸므로, 비용 차이는 대부분 워크플로가 캐시를 얼마나 잘 활용했는지에서 나온다고 볼 수 있다. 공개 수치에서 0.47달러에 76을 곱하면 기존 비용은 실행당 약 36달러다. 이는 본 기사의 계산이며 Asana가 공개한 수치가 아니다.

실험을 둘러싼 운영 방식도 결과만큼 중요하다. GPT-6 Astra가 워크플로를 실행하고 요청, 사용량 기록, 출력을 검토했으며, 별도의 모델 세션이 그 작업을 검토했다. 모든 세션의 요청, 데이터 추적, 결과는 Asana의 소프트웨어 전달 플랫폼 Command에 기록되어 팀이 나중에 연구 전체를 확인할 수 있었다. Command에서 발견 사항은 티켓이 되고 풀 리퀘스트가 되었으며, 변경은 운영 환경으로 갔다. Hidalgo는 자기 전에 /goal을 설정하고 아침에 결과를 검토했다고 말한다. Asana의 최고 제품 책임자 Arnab Bose는 엔지니어가 방향을 정하고, GPT-6 Astra가 실험을 수행하고, 결과가 Command를 거쳐 운영에 들어갔다고 요약했다. 사람과 에이전트가 함께하는 팀의 구체적인 모습이며, 모든 단계에 기록이 남는다.

업계에 주는 시사점은 세 가지다. 첫째, 에이전트의 비용은 모델 단가보다 컨텍스트 설계가 좌우한다. 네 모델 중 셋이 같거나 더 싸다면 결정적인 요소는 요청마다 길어지는 앞부분이 캐시에서 처리되었는지다. 토큰 단가만 비교하는 팀은 더 큰 지렛대를 놓칠 수 있다. 둘째, 에이전트로 에이전트를 개선하려면 실험이 재현 가능하고 증거가 추적 가능해야 한다. Asana는 통제된 비교를 위해 코드를 고치고 모든 추적을 한 시스템에 남겼다. 개별 설정보다 이 규율이 따라 할 가치가 크다. 셋째, 숫자는 신중하게 읽어야 한다. 단일 과제, 공개 데모 카탈로그, 청구서가 아닌 추정 비용이라는 조건이다. 방법이 효과적임은 보여 주지만 모든 브라우저 워크플로가 76배 절감을 얻는다는 증거는 아니다. 에이전트를 운영에 올리는 팀은 먼저 요청의 어느 부분이 캐시되고 어느 부분이 매 단계 바뀌는지 점검한 뒤, 작은 대조 실험으로 확인하는 것이 현실적이다. 한두 달의 수작업을 일주일로 줄인 것은 시간을 아낄 뿐 아니라 아이디어를 시험하는 비용도 낮춘다.