매번 처음부터 헤매지 않는 웹 에이전트

Token Efficient Task Execution via Application Behavior Modeling for Web Agents는 arXiv에 공개된 연구로 식별 번호 2609.13491을 갖고 있습니다. 이 연구가 내세우는 주장은 한 문장으로 정리됩니다. 웹 애플리케이션의 동작 모델을 성공한 시연에서 미리 만들어 두면 웹 에이전트가 훨씬 적은 토큰으로 과제를 마칠 수 있다는 것입니다. 원문은 제목 아래 연결해 두었습니다.

이 논문이 다루는 대상부터 분명히 하겠습니다. 웹 에이전트는 사람이 자연어로 설명한 웹 과제를 대신 수행하는 시스템인데요. 화면의 UI를 읽고 버튼을 누르고 입력란을 채우면서 일을 진행합니다. 그런데 요즘 이 에이전트들의 성능이 좋아질수록 토큰 처리 비용이 빠르게 늘고 있으며, 에이전트 인프라에 전례 없는 투자가 이어지는데도 비용 문제는 그대로 남는다고 연구는 진단합니다. 그래서 저자들이 제안한 OdoBot은 기존 웹 에이전트보다 훨씬 적은 비용으로 과제를 끝내는 새로운 구조입니다.

요금이 먼저 눈에 들어온 이유

제가 이 논문을 집어 든 이유는 성능표가 아니라 비용 이야기 때문이었습니다. 요즘 에이전트 데모를 보면 이것도 되고 저것도 된다는 말이 먼저 나오는데요. 정작 운영을 해보면 청구서가 먼저 말을 겁니다. 토큰이 조용히 새는 지점을 찾지 못하면 데모는 성공하고 사업은 실패하죠. 저는 그래서 토큰을 줄였다는 주장을 보면 반사적으로 조건부터 묻게 됩니다.

연구가 그리는 배경도 저와 비슷했습니다. AI 에이전트가 여러 과제에서 강한 모습을 보이면서 관련 인프라 투자가 크게 늘었는데, 토큰을 처리하는 비용은 오히려 빠르게 증가하고 있다는 것이죠. 이 대목은 생각보다 중요합니다. 모델이 똑똑해졌다고 비용이 자동으로 내려가지 않기 때문입니다. 오히려 더 긴 추론, 더 많은 화면 읽기, 더 잦은 재시도가 비용을 밀어 올립니다. 그렇다면 다음 질문은 자연스럽습니다. 똑똑함은 유지하면서 어디에서 낭비를 걷어낼 수 있을까요.

저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 비용을 줄이는 방법이야 여러 가지가 있겠지만, 어떤 비용이 반복해서 발생하는지를 먼저 알아야 하니까요. 웹 에이전트의 토큰은 대개 한 번 쓰고 마는 것이 아니라 매 단계마다 다시 쓰입니다. 이 반복 구조를 건드리지 않으면 모델을 바꿔도 청구서는 크게 달라지지 않습니다. OdoBot이 흥미로운 지점도 바로 여기입니다. 모델을 키우는 쪽이 아니라 반복을 줄이는 쪽을 택했기 때문입니다.

매번 화면을 처음 보는 에이전트

웹 에이전트의 기본 동작을 천천히 따라가 보겠습니다. 사용자가 과제를 말하면 에이전트는 현재 화면을 읽습니다. 버튼과 메뉴와 입력란의 배치를 파악하고, 다음에 무엇을 눌러야 할지 정합니다. 그리고 실제로 클릭이나 입력을 수행한 뒤 다시 화면을 읽습니다. 화면이 바뀌었으니까요. 이런 읽고 정하고 누르기의 반복이 과제 끝까지 이어집니다.

문제는 그다음입니다. 화면을 읽는 일은 매번 거의 처음부터 다시 벌어집니다. 이전 단계에서 같은 앱을 이미 봤는데도 다음 단계에서는 화면 전체를 다시 해석하는 식이죠. 사람으로 치면 같은 건물을 열 번 들어가면서 매번 1층 안내도를 처음 보는 셈입니다. 엘리베이터가 어디 있는지 어제 봤는데 오늘 또 안내데스크에 묻는 것과 비슷하죠. 이러면 토큰이 나갈 수밖에 없습니다. 화면 설명이 길수록, 단계가 많아질수록, 재시도가 늘어날수록 비용이 불어나니까요.

여기서 재미있는 질문이 생깁니다. 에이전트가 매번 화면을 다시 읽어야 하는 이유는 무엇일까요. 웹 화면이 동적으로 바뀌기 때문이라는 답이 먼저 떠오릅니다. 그런데 동적이라는 말은 두 가지 뜻을 갖고 있습니다. 하나는 내용이 바뀌는 것이고, 다른 하나는 동작 방식이 바뀌는 것입니다. 내용은 매번 바뀌어도 동작 방식은 꽤 오래 유지되는 경우가 많습니다. 게시판 글은 매일 바뀌지만 글쓰기 버튼의 위치와 다음 화면의 흐름은 그대로인 식이죠. 그렇다면 내용과 동작 방식을 같은 무게로 매번 다시 읽을 필요가 있을까요. 저는 이 구분에서 논문의 출발점을 읽었습니다.

앱의 버릇을 기억한다는 발상

OdoBot의 제안은 말 그대로 앱의 버릇을 미리 배워두자는 것입니다. 정확히 말하면 특정 과제의 답을 외우는 것이 아니라, 그 앱이 보통 어떻게 반응하는지에 대한 동작 모델을 갖고 과제에 들어갑니다. 성공한 과제 수행 시연을 분석해서 만든 모델인데요. 이 모델이 있으면 매번 화면 전체를 해석하는 대신 다음에 무엇을 기대해야 하는지, 어디를 보면 되는지, 어떤 순서로 움직여야 하는지를 훨씬 가볍게 판단할 수 있습니다.

생각해보면 사람도 비슷하게 일합니다. 처음 가는 구청에서는 안내문을 한 줄씩 읽지만, 세 번째 방문부터는 창구 순서가 몸에 남습니다. 서류를 어디에 내고 번호표를 언제 뽑는지 아니까 안내문을 처음부터 다시 읽지 않죠. 물론 그날그날 접수 내용이 바뀌는 것은 확인해야 합니다. 하지만 건물 구조까지 매번 다시 외울 필요는 없습니다. OdoBot이 노리는 절약도 이와 같은 결에 있습니다. 바뀌는 내용은 그때그때 읽되, 바뀌지 않는 동작 방식은 미리 가진 지식으로 건너뛰는 것이죠.

그렇다면 이 동작 모델은 과제의 지름길 모음일까요. 저는 그렇게 읽지 않았습니다. 지름길은 특정 과제에만 통하지만, 동작 모델은 여러 과제에 걸쳐 재사용될 수 있기 때문입니다. 예를 들어 과제 제출 흐름을 이해한 에이전트는 제출 마감 확인, 제출물 수정, 제출 이력 조회 같은 이웃 과제에서도 같은 흐름을 활용할 수 있습니다. 한 번 배운 건물 구조로 여러 볼일을 보는 것과 같습니다. 그래서 이 연구의 절약은 과제 하나를 잘 푸는 기술이 아니라 앱 하나를 이해하는 기술에 가깝습니다. 이 차이는 생각보다 중요합니다. 과제가 늘어날수록 재사용의 이득이 쌓이기 때문입니다.

이 아이디어가 아닌 것들

여기서는 조금 조심해서 읽을 필요가 있습니다. 동작 모델이라는 말이 캐시나 하드코딩된 스크립트를 떠올리게 만들기 때문입니다. 그런데 연구가 말하는 것은 단순 저장이 아닙니다. 성공한 시연을 분석해서 만든 행동 모델을 실행에 활용한다는 것이지, 특정 화면의 좌표를 외우거나 특정 과제 순서만 고정한다는 뜻이 아니죠. 좌표를 외우면 화면이 조금만 바뀌어도 깨지고, 과제 순서를 고정하면 과제가 조금만 달라져도 못 씁니다. 반면 동작 방식에 대한 이해는 화면 문구가 바뀌거나 과제 목표가 달라져도 어느 정도 버팁니다.

작은 모델로 바꿨다는 이야기도 아닙니다. 논문이 보고하는 절약은 모델을 가볍게 바꿔서 얻은 것이 아니라 일을 처리하는 구조를 바꿔서 얻은 것으로 읽힙니다. 이 구분은 운영 관점에서 꽤 큽니다. 작은 모델은 대개 추론 품질과의 교환이 따르지만, 불필요한 읽기를 줄이는 쪽은 품질 손상 없이 비용을 내릴 여지가 있기 때문입니다. 물론 실제로 품질이 유지됐는지는 숫자로 확인해야 합니다. 그 이야기는 뒤에서 다시 다루겠습니다.

또 하나 짚을 점은 이 방법이 프롬프트 몇 줄로 되는 요령이 아니라는 것입니다. 시연을 모으고 분석해서 모델을 만드는 과정이 필요하니까요. 공짜 절약은 없습니다. 다만 이 비용은 과제마다 반복되는 비용이 아니라 앱마다 한 번 드는 성격에 가깝습니다. 매 과제마다 토큰을 더 쓰는 것과, 미리 한 번 배워두고 여러 과제에서 아끼는 것은 회계 구조가 다릅니다. 저희가 새로운 AI 구조를 볼 때도 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다. 그런 눈으로 보면 OdoBot은 반복 비용을 선행 투자로 옮기는 시도에 가깝습니다.

성공한 시연에서 건져 올리는 것

이제 논문의 중심 장치로 들어가 보겠습니다. OdoBot은 성공한 과제 수행 시연을 분석해서 앱의 동작 모델을 만든다고 연구는 설명합니다. 이 문장을 곱씹을수록 두 가지 선택이 눈에 띕니다. 하나는 성공한 시연만 쓴다는 점이고, 다른 하나는 개별 과제 기록이 아니라 앱에 대한 모델을 만든다는 점입니다.

왜 성공한 경우만 쓸까요. 실패한 기록에도 배울 점은 있을 것 같은데요. 그런데 실패 기록은 원인이 너무 흩어집니다. 모델이 잘못 판단한 경우도 있고, 화면이 늦게 뜬 경우도 있고, 과제를 잘못 이해한 경우도 있습니다. 이런 기록을 섞으면 앱의 정상 동작과 에이전트의 실수가 뒤섞여 버립니다. 반면 성공한 시연은 적어도 한 번은 통했던 경로를 보여줍니다. 앱이 실제로 어떻게 반응했고, 어떤 순서가 끝까지 갔는지를 말이죠. 그래서 성공 기록은 앱의 사용 설명서 대용으로 쓰기 좋습니다. 완벽한 설명서는 아니지만, 적어도 허황된 설명서는 아니니까요.

다음으로, 개별 기록을 그대로 쓰는 것이 아니라 모델로 만든다는 점이 중요합니다. 기록을 그대로 쌓으면 과제가 달라질 때마다 옛날 기록을 뒤적여야 합니다. 하지만 기록에서 앱의 화면 전환, 메뉴 구조, 작업 흐름 같은 반복 패턴을 뽑아두면 새 과제에도 바로 쓸 수 있습니다. 단골 식당으로 치면 영수증을 모아두는 것이 아니라, 이 집은 주문하고 선결제하고 번호를 받는다는 순서를 외우는 것에 가깝습니다. 메뉴가 바뀌어도 순서는 그대로 쓸 수 있죠. 저는 이 대목에서 논문이 말하는 효율의 원천을 봤습니다. 읽는 양이 줄어드는 것이 아니라 읽어야 할 이유가 줄어들기 때문입니다.

그렇다면 이 모델은 실행 시간에 어떻게 쓰일까요. 연구가 공개한 범위 안에서는 큰 그림으로 이해하는 편이 안전합니다. 에이전트가 매 단계마다 화면 전체를 맨바닥에서 해석하는 대신, 동작 모델이 다음 흐름을 좁혀주는 식이죠. 어디를 봐야 하는지, 무엇을 누르면 어떤 화면이 나올 가능성이 높은지, 지금 단계가 전체 흐름의 어디쯤인지를 아는 것만으로도 판단에 필요한 입력이 줄어듭니다. 입력이 줄면 출력도 흔들릴 여지가 줄어들고, 재시도도 줄어듭니다. 토큰 절약은 이렇게 한 번이 아니라 여러 고리에서 겹쳐 일어납니다.

Canvas라는 운동장에서 45개 과제로 묻다

실험 환경을 보면 연구가 무엇을 증명하려 했는지 드러납니다. 연구팀은 Canvas 학습 관리 시스템에서 45개 과제로 실험했다고 밝히는데요. Canvas는 강좌와 과제와 성적을 관리하는 웹 애플리케이션입니다. 실제 학교와 교육기관에서 쓰는 구조라서 메뉴와 화면 흐름이 비교적 정돈돼 있고, 과제를 제출하고 확인하고 수정하는 식의 다단계 작업이 자연스럽게 나옵니다.

왜 하필 학습 관리 시스템일까요. 저는 이 선택이 꽤 정직하다고 봤습니다. 동작 모델이라는 아이디어를 시험하려면 앱의 버릇이 실제로 존재하고, 그 버릇이 여러 과제에서 반복돼야 하기 때문입니다. 매번 구조가 완전히 바뀌는 앱에서는 배워둘 것이 없습니다. 반면 학습 관리 시스템은 학기 내내 같은 구조 안에서 다른 내용이 오갑니다. 강좌는 바뀌어도 과제 제출 흐름은 비슷하고, 학생은 바뀌어도 성적 확인 흐름은 비슷합니다. 이런 환경은 동작 모델에게 유리한 운동장입니다. 그래서 숫자를 읽기 전에 조건을 먼저 적어둬야 합니다. 이 결과는 반복 구조가 있는 앱에서 나온 결과라는 것이죠.

45개라는 숫자도 같은 맥락에서 봐야 합니다. 아주 작은 데모는 아니지만, 웹 전체를 대표하는 규모도 아닙니다. 하나의 애플리케이션 안에서 여러 과제를 풀어낸 기록으로 읽는 편이 맞습니다. 저는 여기서 논문의 태도가 분명하다고 느꼈습니다. 처음부터 모든 웹을 정복하겠다는 말이 아니라, 앱을 이해하면 그 앱 안에서는 크게 아낄 수 있다는 말을 하려는 것이죠. 범위를 좁힌 대신 그 안에서는 비교 대상과 나란히 붙은 셈입니다. 그렇다면 비교 상대는 누구였을까요. 그 이야기로 넘어가 보겠습니다.

44퍼센트와 80퍼센트를 어떻게 읽을까

연구가 보고한 숫자는 직접적입니다. OdoBot은 Agent-E보다 44퍼센트, WebVoyager보다 80퍼센트 적은 토큰을 썼다고 합니다. 두 비교 대상은 연구에서 최신 경쟁 에이전트로 소개됩니다. 한 문장에 두 개의 절약률이 나란히 놓이니 언뜻 보면 같은 선상의 기록처럼 보이는데요. 저는 이 두 숫자를 조금 다르게 읽었습니다.

먼저 단위부터 정리하겠습니다. 여기서 말하는 퍼센트는 토큰 사용량의 상대 차이입니다. Agent-E가 쓰던 토큰을 기준으로 OdoBot이 44퍼센트 덜 썼고, WebVoyager 기준으로는 80퍼센트 덜 썼다는 것이죠. 포인트 차이가 아니라 비율 차이이므로 기준이 다르면 절약의 절대량도 다릅니다. 그리고 토큰이 줄었다는 말과 돈이 같은 비율로 줄었다는 말은 엄밀히는 다릅니다. 입력 토큰과 출력 토큰의 단가가 다르고, 모델 요금제와 재시도 비용이 얽히기 때문입니다. 그럼에도 방향은 분명합니다. 특히 80퍼센트라는 차이는 오차로 뭉갤 수준이 아닙니다. 구조가 달라졌다는 신호로 읽힙니다.

다음으로 비교 대상이 다르다는 점을 봐야 합니다. Agent-E와 WebVoyager는 같은 일을 하는 쌍둥이가 아니라 서로 다른 설계와 비용 구조를 가진 에이전트입니다. 그래서 44와 80이라는 숫자 자체를 직접 비교해서 어느 상대가 더 대단한지를 논할 필요는 없습니다. 중요한 것은 두 최신 구조에 대해서 모두 같은 방향의 절약이 나왔다는 점입니다. 하나는 절반 가까이, 다른 하나는 5분의 1 수준으로 줄었으니까요. 저는 그래서 이 숫자를 이렇게 받아들였습니다. OdoBot의 절약이 특정 상대의 허점을 찌른 우연이 아니라, 반복 읽기를 줄인 구조에서 비롯된 결과라는 것이죠.

여기서 또 하나의 질문이 남습니다. 이렇게 적게 쓰면서 할 일은 제대로 했을까요. 싼데 못 쓰면 소용없으니까요. 이 질문에 대한 답이 다음 대목에 있습니다.

성공률을 같이 봐야 하는 이유

토큰 이야기가 나올 때마다 제가 스스로에게 던지는 질문이 있습니다. 그래서 과제는 제대로 끝냈습니까. 비용만 내리고 성공률이 무너지면 그건 효율이 아니라 생략이기 때문입니다. 연구는 이 지점에서 WebVoyager와의 비교를 함께 내놓습니다. OdoBot이 WebVoyager보다 성공률이 높았다는 것이죠. 토큰을 훨씬 적게 쓰면서 성공률은 오히려 앞섰다는 말입니다.

이 대목은 논문의 주장에서 꽤 무게를 차지합니다. 단순히 싸게 돌았다는 말이 아니라, 싸게 돌면서도 일을 끝냈다는 말이기 때문입니다. 웹 과제에서는 중간에 한 번만 어긋나도 처음부터 다시 해야 하는 경우가 많습니다. 잘못 누르면 뒤로 가기를 해야 하고, 잘못 읽으면 화면을 다시 봐야 하죠. 이런 재작업은 토큰을 더 먹습니다. 그런데 성공률이 높다는 것은 이런 헛걸음이 적었다는 뜻이기도 합니다. 동작 모델이 다음 흐름을 미리 좁혀주니 실수가 줄고, 실수가 줄니 다시 읽는 일도 줄었다는 해석이 가능합니다. 원인과 결과가 한 방향으로 도는 셈이죠.

다만 여기서는 조금 조심해서 읽을 필요가 있습니다. 연구가 밝힌 범위 안에서는 WebVoyager를 앞섰다는 점까지만 확인할 수 있습니다. Agent-E와의 성공률 비교까지 같은 문장으로 확장해서 읽으면 안 됩니다. 논문이 준 것은 Agent-E에 대한 토큰 비교와 WebVoyager에 대한 토큰 및 성공률 비교이기 때문입니다. 저는 그래서 성공률 이야기를 이렇게 정리했습니다. 적어도 한 최신 에이전트에 대해서는 싸면서도 더 잘했다는 증거가 있다는 것이죠. 이 한 줄이 주는 안심은 작지 않습니다. 토큰 절약이 품질 포기가 아니라는 점을 보여주기 때문입니다.

토큰을 아끼면 시스템에서 무엇이 달라질까

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 토큰이 줄면 청구서 말고 또 무엇이 좋아질까요. 저는 세 가지를 봅니다. 대기 시간과 동시 처리와 운영 여유인데요. 이 셋은 서로 얽혀 있습니다.

먼저 대기 시간입니다. 토큰을 적게 읽고 적게 쓰면 한 단계를 끝내는 데 드는 시간이 줄어들 가능성이 큽니다. 물론 토큰 감소가 곧바로 속도 향상으로 이어진다고 단정할 수는 없습니다. 모델 호출 횟수, 화면 대기, 네트워크 지연 같은 다른 병목이 있기 때문입니다. 하지만 매 단계 입력이 짧아지면 대개 응답도 가벼워집니다. 체감 속도는 이런 작은 차이들이 쌓여서 만들어지죠. 사용자가 기다리는 화면 앞에서 1초씩 아끼는 일은 생각보다 큽니다.

다음은 동시 처리입니다. 같은 예산으로 더 많은 과제를 돌릴 수 있다는 뜻인데요. 에이전트를 수십 개씩 띄워야 하는 운영에서는 토큰 절약이 곧 처리 용량으로 바뀝니다. 특히 학기 초처럼 과제 제출이나 성적 확인이 몰리는 시기에는 이런 차이가 그대로 대기열 길이로 나타납니다. 평소에는 몰랐던 병목이 피크 시간에 갑자기 얼굴을 드러내는 경우를 운영 현장에서는 자주 봅니다. 토큰을 적게 쓰는 구조는 이런 피크에 상대적으로 여유가 있습니다.

마지막은 운영 여유입니다. 토큰을 많이 쓰는 에이전트는 실패 한 번의 대가가 큽니다. 다시 시도할 때마다 청구서가 뛰니까요. 반면 토큰을 적게 쓰는 구조에서는 재시도 정책을 조금 더 너그럽게 가져갈 수 있습니다. 한 번에 통과하지 못해도 다시 해볼 여지가 생긴다는 것이죠. 아이러니하게도 아끼는 구조가 실패에 더 관대해질 수 있습니다. 저는 이 지점이 실무자에게 가장 와닿을 것이라고 봅니다. 비용이 낮아지면 설계 선택지가 넓어지기 때문입니다.

다음에 제가 확인하고 싶은 질문들

좋은 연구는 답과 함께 다음 질문을 남깁니다. 이 논문도 그렇습니다. 제가 앞으로 보고 싶은 것은 크게 세 가지입니다.

첫째, 다른 앱에서도 같은 절약이 나올까요. Canvas는 구조가 정돈된 앱이라 동작 모델에게 유리한 환경입니다. 그렇다면 구조가 자주 바뀌는 앱, 예를 들어 수시로 개편되는 쇼핑몰이나 광고 지면이 뒤섞인 포털에서는 어떻게 될까요. 동작 모델이 낡는 속도가 빨라지면 다시 배우는 비용이 들 텐데요. 그때도 여전히 남는 장사인지가 궁금합니다. 앱의 성격에 따라 절약률이 달라진다면, 어떤 앱에서 먼저 도입해야 하는지에 대한 지침이 나올 것입니다.

둘째, 화면이 바뀌면 모델은 어떻게 따라갈까요. 웹 앱은 조용히 조금씩 바뀝니다. 버튼 문구가 바뀌고 메뉴 순서가 바뀌고 새 팝업이 끼어듭니다. 사람이야 금방 적응하지만, 미리 배운 모델은 이런 변화에 둔할 수 있습니다. 변화 감지와 재학습 주기를 어떻게 가져갈지가 실제 도입의 관건이라고 봅니다. 매번 처음부터 다시 배우면 선행 투자가 반복 비용으로 바뀌어 버리니까요. 작게 고쳐서 따라가는 장치가 있는지, 아니면 주기적으로 다시 모아야 하는지가 궁금합니다.

셋째, 시연을 모으는 비용은 얼마나 될까요. 성공한 시연이 필요하다는 말은 누군가 먼저 과제를 성공시켜야 한다는 뜻입니다. 사람이 직접 보여줄 수도 있고, 기존 에이전트로 돌려서 건질 수도 있겠죠. 어느 쪽이든 공짜는 아닙니다. 앱 하나당 시연 몇 개면 충분한지, 과제가 늘어날 때 추가 시연이 얼마나 필요한지가 나와야 도입 계산이 섭니다. 이 계산이 서면 OdoBot류 접근은 토큰 절약 기술을 넘어 도입 공식에 가까워집니다. 얼마를 먼저 내고 매번 얼마를 아끼는지가 분명해지니까요.

이런 질문이 남는다는 것은 논문의 약점이라기보다 연구가 건드린 지점이 살아 있다는 뜻입니다. 앱을 이해하는 에이전트라는 방향이 한 번은 통했으니, 다음에는 어디까지 통하는지를 물을 차례입니다. 저는 그 다음 답이 궁금해서 이 흐름을 계속 지켜보려고 합니다. 여러분도 에이전트 청구서를 받아든 다음에는 모델 이름보다 그 에이전트가 앱을 기억하는지를 먼저 물어보시면 좋겠습니다. 그 답에 운영의 여유가 달려 있을 때가 많기 때문입니다.