AI 브라우저 작업 비용, Asana의 76배 절감 실험

2026년 10월 8~9일 공개된 StackAI 브라우저 에이전트 실험 — 숫자 읽는 법과 한계

2026년 10월 8일, Asana의 StackAI CTO 프랭크 이달고가 브라우저 에이전트 비용 절감 실험기를 게시했습니다. 다음 날인 10월 9일 OpenAI가 같은 사례를 별도로 소개했습니다. 헤드라인은 "76배 저렴, 5배 빠름"입니다.

핵심 요지는 세 줄입니다.

① 76배·5배는 기존 프로덕션 Model B 설정(하한)과 최적화한 GPT-6.1 Sol 흐름을 비교한 값입니다. 모든 브라우저 에이전트에 적용되는 절감률이 아닙니다.

② 절감의 축은 모델 교체만이 아닙니다. 브라우저 에이전트가 누적 기록을 다루는 방식, 즉 캐시와 스크린샷 정리 방식을 바꾼 것이 큰 몫을 했습니다.

③ 실험은 조건당 3~4회의 소규모 반복입니다. 넓은 경향을 보여주는 결과이지, 독립 재현된 업계 표준 성능이 아닙니다.

이 글은 확정된 사실과 아직 모르는 부분을 나눠서 읽는 방법을 정리합니다. 브라우저 자동화를 운영하거나 도입을 검토 중이라면, 자기 워크로드에서 무엇을 측정해 볼지까지 가져가시면 됩니다.

76배는 어떤 비교인가: 모델 교체와 기록 처리 방식 효과 분리하기

76배는 "새 모델 + 새 기록 처리 방식"을 "옛 모델 + 옛 설정"과 비교한 숫자입니다. 한 가지 변수의 효과가 아닙니다.

OpenAI가 공개한 수치를 비교 대상별로 풀어 보면 이렇습니다.

① Sol 최적 vs Model B 기준: 비용 76배 절감, 속도 5배. Sol 최적 조건은 실행당 평균 추정 모델 비용이 0.47달러였고 실행 시간은 약 4분이었습니다. 입력의 89%가 캐시에서 읽혔습니다.

② Model B 자체 최적화: 29배 절감, 4배 빠름. 비용은 실행당 최소 36.21달러에서 1.24달러로, 시간은 최소 22.5분에서 단축됐습니다.

③ Sol 내부 정책 비교: 1.97달러에서 0.47달러, 약 4배 감소. 큰 기록 예산 조건에서 캐시·스크린샷 정책만 바꾼 결과입니다.

세 숫자를 나란히 놓으면 구조가 보입니다. 같은 Model B에서 기록 처리 방식을 고치는 것만으로 29배가 나왔습니다. 같은 Sol 안에서는 정책 변경으로 약 4배가 나왔습니다. 76배는 이 효과에 모델 교체 효과가 겹친 값입니다.

주의할 점이 하나 있습니다. 세 비교는 기준선이 서로 다릅니다. 29배와 4배를 곱해 76배를 설명하려 들면 안 됩니다. 기준 설정(Model B 최적화 전 최소 36.21달러)과 Sol의 정책 비교 기준(1.97달러)은 출발점이 다르기 때문입니다. 이 글의 수치는 각각의 비교 안에서만 읽으세요.

그리고 기준값은 하한입니다. Model B 기준 실행 일부가 단계 제한에 걸려 완료되지 않았습니다. 끝까지 돌았다면 비용과 시간은 더 컸을 가능성이 있고, 그만큼 절감 배수도 더 커 보일 수 있습니다. 반대로 말하면 "정확히 76배"가 아니라 "기준을 보수적으로 잡은 값"입니다.

실험 설계: 책 32권, 사실 192개를 모으는 작업

평가 작업은 하나의 업무 흐름이었습니다. 공개 데모 도서목록에서 책 32권을 골라 권당 6개 항목, 총 192개 사실을 수집하는 일입니다.

실험 규모는 StackAI 보고 기준으로 이렇습니다.

① 6개 정책 × 2개 기록 예산 × 4개 모델 × 조건당 3회 = 144회

② 후속 실행 12회

비교 모델은 GPT-6.1 Sol과 제품명을 공개하지 않은 Model A·B·C입니다. 역할은 이렇게 알려져 있습니다.

① Model B는 실험 전 StackAI 프로덕션에서 쓰던 모델입니다.

② Model A는 OpenAI 비교표에서 다른 프런티어 연구소의 저가 모델로, 2025년 가을 출시됐고 GPT-6.1 Sol의 절반 가격으로 기재됐습니다.

③ Model C의 상세는 공개 자료에 더 나와 있지 않습니다.

A·B·C의 실제 제품명은 공개되지 않았습니다. 출시 시기나 가격대로 특정 제품을 짐작하는 것은 근거가 없는 추측이므로 이 글에서도 하지 않습니다.

작업 분담도 알아 둘 만합니다. 실험에서는 GPT-6 Astra가 Codex에서 조사와 실험을 맡았고, 사람이 목표·기준 설정과 결과 검토를 담당했습니다. AI가 비용 최적화 실험 자체를 돌리고 사람이 판단 기준을 쥐는 구조였다는 점이 이 사례의 또 다른 특징입니다.

비용이 새던 곳: 호출마다 다시 읽히는 기록

비용 문제의 중심은 모델 단가가 아니라, 매 호출에 실려 가는 입력이었습니다.

브라우저 에이전트는 한 번 호출할 때마다 보내는 것이 많습니다. 도구 정의와 시스템 지침, 그리고 지금까지 쌓인 웹페이지 텍스트와 스크린샷 기록이 모두 포함됩니다. 작업이 길어질수록 기록이 불어나고, 그 기록이 호출마다 반복해서 입력으로 들어갑니다.

여기서 프롬프트 캐싱이 등장합니다. 캐시는 요청의 앞부분이 이전 호출과 같을 때 그 부분을 싼 단가로 읽는 방식입니다. 확인 시점인 2026년 10월 9일 OpenAI 개발자 문서의 GPT-6.1 Sol 표준 단가는 100만 토큰당 다음과 같습니다.

① 입력 2달러

② 캐시 입력 0.10달러

③ 출력 10달러

캐시 입력 단가는 일반 입력의 5%입니다. 캐시에 잘 맞기만 하면 반복 입력 비용이 크게 줄어듭니다.

문제는 에이전트가 기록을 매번 편집할 때 생깁니다. 오래된 스크린샷을 호출마다 지우는 식으로 기록을 손보면, 요청의 변경 없는 앞부분이 달라집니다. 앞부분이 달라지면 캐시 재사용이 깨질 수 있습니다. StackAI는 캐시가 깨지면 호출마다 전체 입력 비용을 부담할 수 있다고 설명했습니다.

직관과 반대되는 지점입니다. 기록을 줄이면 입력이 짧아져서 싸질 것 같지만, 줄이는 방식이 캐시를 깨면 오히려 더 비쌀 수 있습니다. 이 실험은 그 가능성을 정면으로 건드렸습니다.

다만 단가표만으로 총비용을 단정할 수는 없습니다. 실제 총비용은 캐시 적중률과 출력량 등 호출별 사용량에 따라 달라집니다. 캐시 입력이 싸다는 사실과 "캐시를 쓰면 총비용이 언제나 줄어든다"는 주장은 다릅니다.

무엇을 바꿨나: 기록 전체 캐시, 스크린샷 묶음 정리, 기록 예산 확대

개선안은 세 가지 조정으로 요약됩니다. 보고된 설정을 그대로 정리합니다.

① 누적 기록까지 캐시한다. 도구·시스템 지침뿐 아니라 쌓여 가는 기록도 캐시 대상에 넣었습니다.

② 스크린샷을 매 호출 지우지 않고 모아 두었다가 묶음으로 정리한다. 보고된 설정은 스크린샷을 최대 20장 쌓은 뒤 최근 1장만 남기는 방식입니다.

③ 기록 예산을 늘린다. 기록 예산을 120,000자에서 480,000자로 늘렸습니다.

①과
②는 짝입니다. 기록을 캐시하려면 요청의 앞부분이 안정적이어야 합니다. 스크린샷을 매번 지우면 앞부분이 계속 바뀌지만, 20장이 쌓일 때까지 그대로 두면 그동안은 앞부분이 유지되어 캐시가 이어집니다. 정리가 일어나는 순간에는 한 번 캐시가 깨지겠지만, 그 빈도가 호출마다에서 스무 장에 한 번 수준으로 줄어듭니다.

이 설명은 StackAI가 밝힌 원리를 풀어 쓴 것입니다. 20장·1장이라는 숫자 자체는 이 실험에서 보고된 설정이며, 다른 작업에서 최적이라는 근거는 이 실험에서 제시되지 않았습니다.

③은 성격이 다릅니다. 이건 비용 절감 장치가 아니라 정확도와 관련된 조정이었습니다.

기록 예산을 늘렸더니 정답 응답이 3/18에서 18/18로

GPT-6.1 Sol은 기록 예산을 키우자 정답 응답이 18회 중 3회에서 18회 중 18회로 올랐습니다.

① 작은 예산(120,000자): 정답 응답 3/18

② 큰 예산(480,000자): 정답 응답 18/18

기록이 짧게 잘리면 에이전트는 앞서 수집한 정보를 잃어버릴 수 있습니다. 192개 사실을 모으는 작업에서 이미 모은 책의 정보가 기록에서 밀려나면 다시 찾거나 틀리게 됩니다. 이 설명은 실험의 맥락에서 자연스러운 해석이지만, 공개된 요약에는 원인 분석이 상세히 제시되지 않았으므로 해석으로만 받아들이시기 바랍니다.

여기서 반드시 같이 읽어야 할 한계가 있습니다.

실험 실행은 480,000자 예산에 실제로 도달하지 않았습니다. 예산이 상한이었을 뿐 실제로 그만큼 기록이 쌓이지는 않았다는 뜻입니다. 이 결과는 해당 작업·설정에서 나온 것입니다. 긴 기록이 모든 에이전트의 정확도를 높인다는 일반 증거가 아닙니다.

해석은 이 정도가 안전합니다. 이 작업에서는 120,000자 예산이 너무 빡빡해서 정보가 잘렸고, 예산을 넉넉히 주자 문제가 사라졌다. 예산이 어느 정도면 충분한가는 작업마다 다를 것이다.

왜 지금 이 실험에 주목하나

브라우저 에이전트의 병목이 "모델이 얼마나 똑똑한가"에서 "호출 하나하나가 얼마나 싼가"로 옮겨 가고 있기 때문입니다.

이 판단은 이번 실험이 보여주는 구조에서 나옵니다. 브라우저 에이전트는 한 작업에 호출을 수십 번, 때로는 그 이상 반복합니다. 호출마다 기록 전체가 실려 가므로, 단가가 같아도 기록 처리 방식에 따라 총비용이 크게 갈립니다. 실제로 Model B 안에서만 정책을 바꿔도 최소 36.21달러가 1.24달러가 됐습니다.

또 하나는 공개 방식입니다. 이번 사례는 StackAI가 먼저 실험기를 냈고 OpenAI가 다음 날 같은 사례를 별도로 소개하며 브라우저 내비게이션 변경을 StackAI에 배포했다고 밝혔습니다. 모델 사업자와 플랫폼 사업자가 같은 결과를 각자의 관점에서 설명한 드문 경우입니다.

다만 이 배포는 해당 플랫폼에 적용한 변경 사항입니다. 모든 고객 업무에서 같은 비용·시간 절감이 보장된다는 뜻은 아닙니다.

대상별로 보는 영향

영향은 "에이전트를 직접 만드는 쪽"과 "쓰는 쪽"에서 다르게 나타납니다. 아래는 이 실험이 보여주는 구조에서 끌어낸 시사점이며, 특정 조직의 도입 효과를 말하는 것이 아닙니다.

에이전트를 직접 개발·운영한다면

기록을 어떻게 편집하는지가 비용 구조를 좌우할 수 있습니다. 호출마다 기록을 손보는 설계라면 캐시가 제대로 작동하는지부터 확인할 만합니다. 캐시 적중률이라는 지표를 로그에 남기고 있는지가 출발점입니다.

브라우저 자동화를 외부 서비스로 이용한다면

서비스 가격표만으로는 실제 작업당 비용을 알기 어렵습니다. 같은 모델을 써도 기록 처리 방식이 다르면 작업당 비용이 달라질 수 있기 때문입니다. 이번 실험의 76배를 근거로 공급자에게 같은 폭의 인하를 기대하는 것은 근거가 없습니다.

모델 선택을 고민한다면

이번 결과는 "모델 단가 비교만으로는 총비용을 예측할 수 없다"는 점을 보여줍니다. Model A가 Sol의 절반 가격으로 기재됐다는 사실과, 작업당 총비용이 어느 쪽이 낮은가는 별개의 문제입니다. 후자는 비교표에 한 줄로 나오지 않습니다.

정확도가 중요한 업무라면

기록 예산을 줄여서 비용을 아끼려는 시도가 정확도를 크게 떨어뜨릴 수 있다는 신호입니다. 이번 작업에서는 예산 120,000자일 때 정답 응답이 3/18까지 떨어졌습니다. 비용을 줄이기 전에 정확도 기준을 먼저 정해야 합니다.

확정 수치와 읽는 법

숫자가 많아서 헷갈리기 쉬우므로, 비교 대상별로 한 번에 정리합니다.

Sol 최적 조건의 실행당 평균 추정 모델 비용은 0.47달러, 실행 시간은 약 4분입니다.

이 숫자를 읽을 때의 규칙을 세 가지로 정리합니다.

① "추정 모델 비용"입니다. 청구서 금액이 아니라 모델 호출 비용의 추정치입니다. 브라우저 실행 환경 등 다른 비용은 이 수치에 담긴다고 확인된 바가 없습니다.

② 기준 쪽 수치는 하한입니다. 일부 기준 실행이 단계 제한에 걸려 미완료였습니다.

③ 후속 12회 결과도 있습니다. 후속 실행에서는 스크린샷을 전부 유지했는데, 호출당 비용이 Model B와 GPT-6.1 Sol에서는 최적 조건보다 1.2배 낮았고 Model C에서는 약 5% 낮았다고 StackAI가 보고했습니다. 다시 말해 스크린샷을 전부 유지하는 쪽이 호출당 비용은 오히려 낮게 나온 경우가 있었다는 뜻입니다.

③은 개선안의 "스크린샷 묶음 정리"가 모든 조건에서 호출당 비용을 최소로 만든 것은 아니라는 신호로 읽힙니다. 그래서 StackAI의 단서가 중요합니다. 조건당 3~4회이고 실행별 호출 수가 달라서, 작은 차이를 판별하기보다 넓은 경향을 보여주는 결과라고 스스로 밝혔습니다.

위 차트의 세 값은 모두 OpenAI가 제시한 실행당 비용입니다. 첫 값은 하한이라는 점, 세 번째 값은 Model B가 아니라 Sol의 평균이라는 점을 기억하고 보시기 바랍니다.

이 결과를 이렇게 쓰면 안 됩니다

76배·5배를 인용할 때 빠지기 쉬운 오독이 네 가지 있습니다.

① "브라우저 에이전트 비용이 76배 싸진다." 이 실험은 StackAI 브라우저 에이전트의 특정 업무 흐름에 관한 것입니다. 보편적인 절감률로 일반화할 근거는 이 실험에서 제시되지 않았습니다.

② "모델만 바꾸면 76배 절감된다." Model B 안에서 정책만 바꿔도 29배가 나왔고, Sol 안에서 정책만 바꿔도 약 4배가 나왔습니다. 76배는 모델 교체와 처리 방식 개선이 합쳐진 결과입니다.

③ "캐시를 켜면 총비용이 줄어든다." 캐시 입력 단가가 일반 입력의 5%인 것은 사실입니다. 하지만 총비용은 캐시 적중률과 출력량에 따라 달라지고, 기록 편집 방식이 캐시를 깨면 이득이 사라질 수 있습니다.

④ "기록을 길게 주면 정확도가 올라간다." 이 작업에서 480,000자 예산이 효과를 냈지만, 실행이 그 예산에 도달하지도 않았습니다. 일반 법칙으로 읽을 수 없습니다.

아직 모르는 것

공개된 자료만으로는 판단을 유보해야 하는 지점이 분명히 있습니다.

① 독립 재현 여부. StackAI와 OpenAI가 공개한 결과이며, 제3자 재현 결과는 확인된 것이 없습니다.

② 다른 작업에서의 효과. 32권, 192개 사실을 수집하는 도서목록 작업 하나에서 나온 결과입니다. 로그인이 필요한 화면, 양식 입력, 다단계 결제 같은 작업에서 같은 효과가 나오는지는 이 실험이 다루지 않았습니다.

③ Model A·B·C의 정체. 세부 모델명이 공개되지 않아 독자가 같은 비교를 재현하기 어렵습니다.

④ 기준 실행의 실제 비용. 일부 실행이 단계 제한에 걸렸기 때문에 Model B 기준 비용과 시간의 참값은 알 수 없습니다. 공개된 값은 최소치입니다.

⑤ 캐시 정책의 최적 설정. 스크린샷 20장·1장이라는 설정이 다른 작업에서도 좋은지는 알 수 없습니다.

이 글에서 이후 일정이나 후속 발표 계획은 다루지 않습니다. 주제와 관련해 공개된 자료에서 확인되는 후속 일정이 없기 때문입니다.

내 브라우저 에이전트에서 해 볼 수 있는 점검

이 실험을 따라 하려면 76배를 기대하지 말고, 측정 항목부터 갖추세요. 아래 순서는 실험의 구조에서 끌어낸 점검 절차입니다.

Step 1. 호출당 입력 구성을 분해한다

한 번의 호출에서 시스템 지침, 도구 정의, 누적 기록(텍스트와 스크린샷)이 각각 얼마나 차지하는지 확인합니다. 기록이 입력의 대부분이라면 개선 여지가 큽니다.

Step 2. 캐시 적중률을 로그에 남긴다

사용 중인 API가 캐시 입력 토큰을 구분해 보고한다면 그 값을 수집합니다. 이번 실험의 Sol 최적 조건은 입력의 89%가 캐시에서 읽혔습니다. 자기 에이전트의 비율이 이보다 많이 낮다면 점검 후보입니다. 89%를 목표치로 삼을 근거는 없고, 비교용 참고 지점일 뿐입니다.

Step 3. 기록 편집 시점을 확인한다

호출마다 기록을 고치는 로직이 있는지 봅니다. 오래된 스크린샷을 매번 지우거나 요약문으로 바꾸는 방식이라면, 요청의 앞부분이 매번 달라져 캐시가 깨질 수 있습니다.

Step 4. 정리를 묶음 단위로 바꿔 본다

스크린샷을 일정 장수가 쌓일 때까지 유지하고, 그때 한꺼번에 정리하는 방식을 시험합니다. 이번 실험의 설정(20장 쌓고 최근 1장 유지)은 시작점의 한 예일 뿐입니다. 장수는 자기 작업에서 정확도와 비용을 함께 보며 조절해야 합니다.

Step 5. 기록 예산은 정확도 기준으로 정한다

예산을 줄이기 전에, 정답 여부를 판정할 기준을 먼저 만듭니다. 이번 사례에서는 작은 예산이 정답 응답 3/18이라는 큰 손실로 이어졌습니다. 예산 변경 전후의 정답률을 같은 방식으로 세어야 비교가 됩니다.

Step 6. 반복 횟수를 늘려서 비교한다

StackAI도 조건당 3~4회로는 작은 차이를 판별하기 어렵다고 밝혔습니다. 자기 환경에서는 조건당 반복을 더 늘려야 비용과 정확도의 분산이 보입니다. 성공 여부와 호출 수도 같이 기록하세요. 비용만 보면 중간에 실패한 실행이 싸 보이는 착시가 생깁니다.

Step 7. 비교 기준을 완주한 실행으로 맞춘다

이번 실험의 Model B 기준은 일부 실행이 단계 제한에 걸렸습니다. 자기 비교에서는 단계 제한에 걸린 실행을 따로 표시하고, 완주한 실행끼리의 비용·시간도 함께 보세요. 그래야 절감 배수를 부풀리지 않습니다.

자주 묻는 질문

Q. 캐시 입력 단가가 일반 입력의 5%면, 입력 비용이 95% 줄어드는 건가요?

아닙니다. 5%는 캐시에서 읽힌 입력 토큰에만 적용되는 단가입니다. 캐시 적중률이 높아야 입력 비용이 크게 줄고, 출력 토큰은 별도로 과금됩니다. 확인 시점의 Sol 출력 단가는 100만 토큰당 10달러로 입력 단가의 5배입니다. 그래서 총비용은 입력 중 캐시 비율과 출력량이 함께 결정합니다. 이번 사례에서 입력의 89%가 캐시에서 읽혔다는 것은 그 조건의 결과이며, 다른 작업에서는 달라질 수 있습니다.

Q. 이 사례에서 사람은 무엇을 했나요?

사람은 목표와 기준 설정, 결과 검토를 맡았습니다. 조사와 실험은 Codex에서 GPT-6 Astra가 맡았습니다. 어떤 조건을 몇 번 돌릴지 같은 세부 운영 방식은 공개 자료의 요약 범위를 넘어서므로 이 글에서는 단정하지 않습니다.

참고 자료

- stackai.com (StackAI CTO 프랭크 이달고의 실험기, 2026년 10월 8일 게시)

- openai.com (Asana·StackAI 브라우저 에이전트 사례, 2026년 10월 9일)

- developers.openai.com (GPT-6.1 Sol 모델 문서, 2026년 10월 9일 확인)

- https://openai.com/index/asana-browser-agent/

- https://asana.com/inside-asana/cut-browsers-agent-cost

- https://developers.openai.com/api/docs/models/gpt-6.1-sol

마무리

이 사례에서 가져갈 것은 76배라는 숫자가 아니라 질문의 방향입니다. 같은 일을 하는 에이전트라도 기록을 어떻게 다루느냐에 따라 호출 비용 구조가 완전히 달라질 수 있습니다. Model B 안에서만 29배, Sol 안에서만 약 4배가 나왔다는 사실이 그 증거입니다.

반대로, 이 숫자는 조건당 3~4회, 도서목록 수집이라는 하나의 작업, 하한으로 잡힌 기준선 위에서 나왔습니다. 확정된 것은 "이 실험에서 이런 수치가 보고됐다"까지이고, 자기 환경의 절감폭은 직접 재 봐야 압니다. 호출당 입력 구성, 캐시 적중률, 정답률. 세 가지를 로그에 남기는 것부터 시작하시길 권합니다.