Asana, GPT-6.1 Sol로 브라우저 에이전트 비용을 76분의 1로 절감: Codex가 이끈 워크플로 최적화

2026년 10월 9일, OpenAI는 Asana에 관한 고객 사례를 공개했다. 숫자는 눈에 띈다. 브라우저 에이전트 테스트에서 Asana는 추정 모델 비용을 76분의 1로 낮추고 실행 속도를 5배로 높였다. 최적화된 워크플로는 GPT-6.1 Sol에서 돌아갔고, 1회 실행당 평균 추정 모델 비용은 0.47달러, 소요 시간은 약 4분이었다. 비교 기준은 Model B에서 쓰던 기존 프로덕션 구성이다. 이 두 수치로 단순 계산하면 기존 비용은 1회당 약 36달러 안팎이 된다. 먼저 짚어 둘 점이 있다. 이것은 벤더가 공개한 사례이고, 비용은 추정치이며, 비교는 Asana가 직접 설계한 144회 실행 연구에서 나왔다. 진지하게 받아들일 만한 엔지니어링 신호이지만, 어느 팀이든 그대로 적용할 수 있는 업계 기준은 아직 아니다.

배경에는 StackAI가 있다. Asana가 인수한 이 플랫폼에서 고객은 코드를 쓰지 않고도 에이전트가 웹사이트를 탐색하고, 양식을 채우고, 정보를 수집하는 워크플로를 만들 수 있다. 한 번의 실행에서는 비효율이 잘 보이지 않는다. 그러나 Asana의 규모에서는 작은 낭비가 막대한 호출량과 곱해진다. 그래서 StackAI의 CTO인 Frank Hidalgo 박사는 브라우저 에이전트를 더 빠르고 더 싸게 만들기로 했다. 그는 팀을 이끌고 손으로 하나하나 점검하는 대신, Codex의 GPT-6 Astra에게 에이전트를 조사하고, 개선안을 시험하고, 결과를 비교하도록 지휘했다. 그의 추정으로는 사람이 직접 했다면 한두 달이 걸렸을 작업이 약 일주일 만에 끝났다.

이 사례에서 가장 배울 점이 많은 부분은 진단 과정이다. Hidalgo는 먼저 GPT-6 Astra에게 코드베이스를 훑게 하고, 에이전트가 모델 요청을 어떻게 구성하는지 설명하게 했다. 그 결과, 에이전트는 고정된 지침과 도구 정의는 캐시하고 있었지만, 계속 늘어나는 페이지 텍스트와 스크린샷 이력은 캐시하지 않고 있었다. 이것이 무엇을 뜻하는지 생각해 보자. 브라우저 에이전트는 한 걸음 나아갈 때마다 지금까지 본 내용과 새 스크린샷을 모델에 넘긴다. 이력이 길어질수록 매 단계에서 처리해야 할 입력이 늘어난다. 이 부분이 캐시에 적중하지 못하면, 같은 내용이 한 번의 실행 안에서 거듭 정가로 과금되고 첫 토큰이 돌아오는 시간도 매번 늘어난다. 낭비는 단계마다 쌓이고, 전체 입력은 단계 수보다 가파르게 늘어난다. 이는 작동 원리에 대한 합리적인 추론이다. OpenAI가 공개한 발췌에는 이후의 모든 변경 사항이 실려 있지 않으며, 빠진 항목을 우리가 지어내서는 안 된다.

다음은 연구 설계다. Asana는 144회의 실행을 했고, 대상은 GPT-6.1 Sol과 본문에서 Model A, B, C라 부르는 세 개의 최첨단 모델이었다. 이 설계의 강점은 모델 선택과 워크플로 개조가 하나의 비교표 안에 들어 있다는 점이다. 동시에 분명히 말해 두어야 할 해석상의 문제도 생긴다. 76배라는 수치는 최적화된 Sol 워크플로를 Model B의 기존 프로덕션 구성과 견준 것이다. 즉 두 변수가 동시에 움직였다. 76배를 전부 모델의 공으로 돌리면 모델의 역할을 과대평가하게 된다. 전부 워크플로의 공으로 돌리면 모델 자체의 가격과 속도 차이를 무시하게 된다. 발췌에는 둘을 가르는 대조군이 보이지 않으며, 주의 깊은 독자가 따져 물어야 할 곳이 바로 여기다. 비용은 추정치라서 각 사의 가격 조정에 따라 달라질 수 있다. 144회라는 표본도 크지 않아서, 결과의 안정성을 확인하려면 더 많은 반복이 필요하다.

두 번째 의미는 일하는 방식에 있다. Asana의 CPO인 Arnab Bose는 이것이 사람과 에이전트 팀이 실제로 일하는 모습이라고 말했다. 엔지니어가 방향을 정하고, GPT-6 Astra가 실험을 돌리고, 결과는 Command를 거쳐 프로덕션에 들어갔다. 이 문장에는 뚜렷한 분업선이 있다. 방향과 취사선택, 출시 결정은 사람에게 남았고, 가장 시간이 많이 드는 부분인 코드 읽기, 가설 세우기, 비교 실행, 데이터 정리는 에이전트에게 넘어갔다. 실험의 한계 비용이 내려가면 최적화는 시간이 날 때까지 기다릴 필요가 없어지고 일상적인 동작이 될 수 있다. 하지만 그만큼 가치의 중심은 평가로 옮겨 간다. 반복 가능한 작업 세트가 있는가. 비교 가능한 지표가 있는가. 결과를 꼼꼼히 읽는 사람이 있는가. 이것이 없다면 실험을 빨리 돌려도 잡음만 늘어난다.

업계에 이 사례는 세 가지 신호를 보낸다. 첫째, 브라우저 에이전트 경쟁은 할 수 있는가에서 한 번에 몇 달러, 몇 분이 드는가로 옮겨 가고 있다. 수십 달러에서 1달러 미만으로 내려가야 하루 수천 건의 기업용 실행이 현실적으로 보인다. 둘째, 캐시 적중 구조는 에이전트 아키텍처 리뷰의 고정 점검 항목이 되어야 한다. 특히 단계마다 길어지는 컨텍스트에서 그렇다. 셋째, 이 작업의 목적 중 하나는 Asana가 고객에게 더 강력한 모델을 제공할 수 있게 하는 것이었다. 비용 절감은 성능을 위한 여지를 사 준다. 독자에게 현명한 길은 숫자가 아니라 방법을 빌리는 것이다. 자신의 요청 중 어느 부분이 캐시되지 않는지 감사하라. 고정된 작업 세트로 통제 비교를 하라. 모델 변경과 워크플로 변경을 따로 시험하라. 그리고 비용을 성공률과 나란히 보고하라. 76분의 1이라는 비용은 인상적이지만, 에이전트가 여전히 일을 제대로 해낼 때에만 의미가 있다.