Asana, GPT‑6.1 Sol로 브라우저 테스트 모델 비용을 76분의 1로 절감
Asana는 고객에게 더 뛰어난 모델을 제공하기 위해 Codex의 GPT‑6 Astra를 활용했습니다. 테스트에서 브라우저 에이전트의 비용은 76분의 1로 줄고 속도는 5배 빨라졌습니다.
76배
최적화된 GPT-6.1 Sol 워크플로의 추정 모델 비용 절감
5배
최적화된 GPT-6.1 Sol 워크플로의 브라우저 실행 속도 향상
$0.47
최적화된 GPT-6.1 Sol 워크플로의 평균 추정 모델 비용
Asana는 Codex에서 GPT‑6 Astra로 실험을 수행하고 GPT‑6.1 Sol 기반 브라우저 에이전트의 워크플로를 최적화해, 실행 비용을 76분의 1로 줄이고 속도를 5배 높였습니다.
Asana는 자사가 인수한(새 창에서 열기) 플랫폼 StackAI(새 창에서 열기)를 통해 고객이 여러 비즈니스 애플리케이션에 걸친 업무를 자동화하도록 돕습니다. 고객은 StackAI를 사용해 코드를 작성하지 않고도 웹사이트를 탐색하고, 양식을 작성하고, 정보를 수집하는 워크플로를 구축할 수 있습니다. Asana처럼 서비스 규모가 크면 이런 워크플로의 작은 비효율도 누적되어 큰 영향을 미칩니다.
Asana의 StackAI CTO인 프랭크 이달고(Frank Hidalgo) 박사는 브라우저 에이전트의 실행 속도를 높이고 비용을 줄이기 위한 작업에 나섰습니다. 그는 Codex에서 GPT‑6 Astra에 에이전트를 분석하고, 개선안을 테스트하고, 결과를 비교하도록 지시했습니다. 직접 했다면 한두 달은 걸렸을 것으로 추산한 작업이 약 일주일 만에 끝났습니다.
Asana의 144회 실행 연구(새 창에서 열기)에서는 GPT‑6.1 Sol과 다른 프런티어 모델 3종을 테스트했습니다. 여기서는 이들을 모델 A, B, C로 부릅니다. 이 과정에서 완성된 GPT‑6.1 Sol의 최적화 워크플로는 실행당 평균 추정 모델 비용이 0.47달러, 실행 시간이 약 4분이었습니다. 모델 B를 사용한 기존 프로덕션 설정보다 비용은 76분의 1로 줄고 속도는 5배 빨라졌습니다.
“사람과 에이전트로 이루어진 팀이 실제로 일하는 모습이 바로 이렇습니다. 엔지니어가 방향을 정하고, GPT-6 Astra가 실험을 수행했으며, 그 결과는 Command를 거쳐 프로덕션에 반영되었습니다. Asana가 사람과 에이전트로 이루어진 팀을 어떻게 실현하는지 보여주는 사례입니다.”
이달고는 작업 속도를 높이기 위해 먼저 Codex의 GPT‑6 Astra로 코드베이스 구조를 파악하고 에이전트가 각 모델 요청을 구성하는 방식을 설명하도록 했습니다. GPT‑6 Astra는 에이전트가 고정 지침과 도구 정의는 캐싱하지만, 계속 쌓이는 페이지 텍스트와 스크린샷 이력은 캐싱하지 않는다는 점을 발견했습니다. 그 결과 모든 요청에서 이력을 다시 전송하며 할인 없는 요금을 지불하고 있었습니다.
또한 에이전트는 거의 매 단계마다 오래된 스크린샷을 삭제하고 텍스트를 잘라냈습니다. 이렇게 수정할 때마다 이력이 바뀌기 때문에 이력을 캐싱하는 것만으로는 도움이 되지 않았을 것입니다. 게다가 정보가 사라지면 에이전트가 이미 읽은 페이지를 다시 방문해야 할 수도 있었습니다.
이달고는 GPT‑6 Astra가 제안한 개선안을 검토한 뒤 테스트할 항목 세 가지를 선정했습니다.
캐싱 범위를 에이전트의 탐색 이력까지 확대
보관할 수 있는 텍스트 분량 확대
매 단계마다 스크린샷을 삭제하는 대신 한꺼번에 삭제
GPT‑6 Astra는 어떤 변수가 중요한지 파악하기 위해 간단한 테스트부터 시작했습니다. 기존 코드가 통제 실험용으로 설계되지 않았기 때문에, 이후 코드를 리팩터링해 하나의 프런트엔드와 백엔드에서 서로 다른 설정을 가진 여러 워크플로를 병렬로 실행할 수 있도록 했습니다.
Astra는 이력 보관 한도 12만 자와 48만 자, 캐싱 및 스크린샷 정책 6가지를 조합해 전체 연구를 수행했습니다. 각 조합은 네 가지 모델에서 각각 세 번씩 테스트했습니다(아래 표 참조). 가장 성능이 좋은 정책은 스크린샷이 20장 쌓이면 가장 최근의 한 장만 남기는 방식이었습니다. 이 방식은 삭제 간격을 늘려 이전 이력이 더 오래 바뀌지 않고 유지되도록 했습니다. 여기에 더 큰 이력 보관 한도를 적용해 최적화 워크플로를 완성했습니다. 모든 설정에서 동일한 작업을 수행했습니다. 공개 데모 도서 목록에서 책 32권에 대해 각각 6개 항목의 정보를 수집하는 작업으로, 일부 Asana 고객이 StackAI에서 실행하는 작업의 대표적인 예입니다.
모델 | 설명 | 가격 |
|---|---|---|
모델 A | 다른 프런티어 AI 연구소가 2025년 가을에 출시한, 규모가 작고 가격이 저렴한 모델 | GPT‑6.1 Sol 가격의 절반 |
모델 B | 기존 프로덕션 환경에서 사용하던 모델로, 모델 A와 같은 연구소에서 2026년 여름에 출시 | GPT‑6.1 Sol과 동일한 가격 |
모델 C | 2026년 가을에 출시된 모델 B의 업데이트 버전 | GPT‑6.1 Sol과 동일한 가격 |
GPT‑6.1 Sol | OpenAI의 모델 |
GPT‑6 Astra는 워크플로를 실행하고 요청, 사용 기록, 출력을 분석했으며, 별도의 모델 세션들이 이 작업을 검토했습니다. 모든 세션의 요청, 데이터 추적 기록, 결과는 Asana의 소프트웨어 배포 플랫폼인 Command(새 창에서 열기)에 기록되어, 팀이 나중에 전체 연구를 검토할 수 있었습니다. Command에서 연구 결과는 티켓으로, 이어서 풀 리퀘스트로 전환되었고, 변경 사항은 프로덕션 환경에 반영되었습니다.
“직접 했다면 한두 달은 걸렸을 겁니다. Codex에서 GPT-6 Astra를 활용하니 약 일주일이 걸렸습니다. 잠자리에 들기 전에 /goal을 설정하고 아침에 결과를 검토했죠.”
모델 B에서는 최적화를 통해 실행당 추정 모델 비용이 최소 36.21달러에서 1.24달러로, 29분의 1로 줄었습니다. 기존 실행 중 일부는 완료 전에 단계 한도에 도달했으므로 원래 비용은 이보다 더 높을 수 있습니다. GPT‑6.1 Sol의 최적화 워크플로는 비용이 그보다도 2.6분의 1 수준인 0.47달러였습니다. 최적화 워크플로에서는 모든 실행이 작업을 완료하고 정확한 답을 반환했습니다.
3회 실행의 평균입니다. ≥: 기준 설정에 한도에 도달한 실행이 포함되어 있으므로, 이 평균은 하한값입니다.
오른쪽의 두 배율은 최적화된 모델 B와 비교한 값입니다. 동일한 연구에서 모델 B는 1차에, 모델 C와 Sol 6.1은 2차에 실행했습니다(점선으로 구분).
GPT‑6.1 Sol만 놓고 보더라도, 이력 보관 한도를 확대한 상태에서 새 캐싱 및 스크린샷 정책을 적용하자 실행당 비용이 1.97달러에서 0.47달러로, 4분의 1로 줄었습니다. 입력의 89%가 캐시에서 제공되어 캐싱되지 않은 입력 요금의 5%만 부과된 덕분에, 호출당 비용이 약 3분의 1로 줄었습니다. 실행 속도도 빨라졌습니다. 모델 B의 기존 설정에서는 최소 22.5분이 걸렸지만, GPT‑6.1 Sol의 최적화 워크플로에서는 약 4분이 걸렸습니다.
3회 실행의 평균이며, 오차 막대는 표준편차를 나타냅니다. ≥: 평균에 한도 도달 또는 미완료 실행이 포함되어 있으므로, 실제 값은 이 값 이상입니다.
막대는 파란색 계열로 표시했습니다. 캐싱 효과는 보관 한도를 48만 자로 확대한 막대를 기준으로 비교하세요.
실행 마커와 표준편차 오차 막대는 원본 이미지에서 근사적으로 재구성했습니다. 개별 실행 값과 표준편차의 원자료는 제공되지 않았습니다.
3회 실행의 평균이며, 오차 막대는 표준편차를 나타냅니다. ≥: 평균에 한도 도달 또는 미완료 실행이 포함되어 있으므로, 실제 값은 이 값 이상입니다.
막대는 파란색 계열로 표시했습니다. 캐싱 효과는 보관 한도를 48만 자로 확대한 막대를 기준으로 비교하세요.
실행 마커와 표준편차 오차 막대는 원본 이미지에서 근사적으로 재구성했습니다. 개별 실행 값과 표준편차의 원자료는 제공되지 않았습니다.
이번 분석은 이력 관리 방식이 에이전트의 답변 생성 여부 자체에도 영향을 미친다는 점을 보여주었습니다. GPT‑6.1 Sol이 탐색 이력을 더 많이 보관할 수 있도록 하자 답을 생성한 실행 횟수가 늘었습니다. 보관 한도가 작을 때는 18회 중 3회에 그쳤지만, 한도를 늘리자 18회 모두 답을 생성했고 전부 정확했습니다. 이달고가 보는 비즈니스 가치는 지속 가능한 운영 비용을 유지하면서 고객에게 더 빠르고 성능이 뛰어난 모델을 제공하는 데 있습니다.
“예전에는 이런 워크로드에 대해 고객에게 제공할 수 있는 모델이 비용 때문에 제한됐습니다. 에이전트의 효율을 높인 덕분에 운영 비용을 낮추면서도 고객에게 더 뛰어나고 빠른 모델을 제공할 수 있게 되었습니다.”
Asana는 StackAI의 브라우저 탐색 기능에 이번 변경 사항을 적용했으며, 유사한 실험을 더 쉽게 반복할 수 있는 도구를 개발하고 있습니다. 장기적으로 팀은 이 테스트를 플랫폼의 평가 체계에 통합할 계획입니다. 이를 통해 고객과 내부 팀은 에이전트를 설정할 때 비용, 실행 시간, 답변 품질을 비교할 수 있게 됩니다.
“이제 병목은 출시 속도가 아니라 사람이 쏟을 수 있는 주의력입니다. 모든 엔지니어가 여러 에이전트를 이끄는 PM이 되는 세상이 머지않았습니다.”
Asana는 이제 Codex의 GPT‑6 Astra로 출시 전 제품 기능을 테스트하고 있습니다. Astra가 플랫폼을 탐색하고 다양한 입력을 시도한 뒤, 사람이 진행하는 QA 검토를 위해 버그를 보고합니다. 이달고는 이를 다수의 클라우드 에이전트 세션이 기능을 병렬로 테스트하는 새로운 소프트웨어 개발 수명 주기의 토대로 보고 있습니다.
전체 연구 결과는 Asana(새 창에서 열기)와 StackAI(새 창에서 열기) 블로그에서 확인할 수 있습니다.
