웹 에이전트에게 꼭 맞는 도구만 남기는 법, AutoTailor를 읽고

AutoTailor: Automatic, User-Aligned Capability Selection and Adaptation for Web Agents는 arXiv에 arXiv 번호 2609.13548로 공개된 연구입니다. 원문 링크는 제목 아래에 걸어두었습니다. 이 연구가 내세우는 주장은 한 문장으로 정리됩니다. 웹에서의 행동 궤적에서 뽑아낸 MCP API를 오프라인에서 다듬고 온라인에서 다시 고르면, 훨씬 적은 수의 도구로 정확도를 유지하거나 높이면서 요청 토큰 비용과 지연시간을 함께 낮출 수 있다는 것입니다.

왜 이 논문을 끝까지 읽게 됐을까

웹 에이전트 논문은 보통 비슷한 흐름으로 시작합니다. 브라우저를 직접 다루는 에이전트가 매번 클릭과 입력과 스크롤을 반복하느라 토큰을 많이 쓰고 속도도 느리다는 이야기죠. 저도 처음에는 이번 연구가 그런 문제를 말하는 또 하나의 논문이라고 생각했습니다. 그런데 페이지를 넘기면서 생각이 바뀌었는데요. 이 연구는 도구를 미리 만들어서 주는 쪽이 아니라, 에이전트가 실제로 일한 기록에서 도구를 깎아내고, 그 다음에는 쓰는 모습을 보면서 다시 고른다는 데까지 나아갑니다.

제가 이 논문에서 가장 흥미롭게 본 부분은 도구의 개수를 줄였다는 결과 자체가 아니라, 줄이는 기준을 두 층으로 나눴다는 점입니다. 오프라인에서는 품질과 쓰임새로 걸러내고, 온라인에서는 실제 쓰임과 실패를 보고 더하고 뺍니다. 말로 하면 쉬워 보이지만, 막상 시스템으로 만들려면 어디에서 무엇을 재고 언제 버릴지를 정해야 합니다. 이 글에서는 그 선택의 과정을 처음부터 따라가 보려고 합니다. 그렇다면 에이전트는 왜 매번 같은 곳에서 헤맬까요?

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

브라우저를 다루는 에이전트의 하루를 상상해 보시면 됩니다. 아침에 쇼핑몰에서 주문 상태를 확인하고, 점심에는 게시판에 글을 올리고, 오후에는 설정 화면에서 옵션을 바꿉니다. 사람에게는 모두 익숙한 클릭 몇 번이지만, 낮은 수준에서만 움직이는 에이전트에게는 매번 새로운 탐험입니다. 어떤 버튼이 진짜 제출 버튼인지, 목록이 더 있는지, 폼을 다 채웠는지, 매번 눈으로 확인하듯 DOM을 읽고 다음 행동을 정해야 합니다.

이런 방식은 유연합니다. 처음 보는 사이트에서도 어떻게든 움직이니까요. 그런데 그 유연함에는 값이 따릅니다. 같은 일을 해도 주고받는 토큰이 많아지고, 단계가 길어질수록 지연시간이 쌓이며, 중간에 한 번만 어긋나도 뒤의 계획이 함께 흔들립니다. 반면 자주 쓰는 흐름을 도구로 묶어두면 이야기가 달라집니다. 로그인하고 검색하고 필터를 거는 일련의 동작이 하나의 호출로 끝나면, 모델이 매번 낮은 수준의 결정을 반복하지 않아도 됩니다.

여기서 재미있는 질문이 생깁니다. 도구가 좋다는 것은 누구나 아는데, 왜 모두가 미리 좋은 도구를 만들어두지 않을까요? 이유는 웹이 고정되어 있지 않기 때문입니다. 사이트마다 구조가 다르고, 사용자마다 자주 하는 일이 다르며, 오늘 잘 통하던 순서가 내일은 바뀝니다. 그래서 미리 손으로 만든 도구는 금방 어긋나고, 너무 많은 도구를 주면 모델이 고르는 일 자체가 다시 부담이 됩니다. 문제는 그다음입니다. 도구를 자동으로 만들 수는 없을까, 그리고 만든 뒤에도 계속 고를 수는 없을까?

도구를 외우는 게 아니라 깎아 만드는 일

AutoTailor를 한마디로 말하면, 궤적에서 도구를 뽑아내는 메타 에이전트 구조입니다. 여기서 궤적이란 에이전트가 웹에서 일하면서 남긴 행동의 기록을 말합니다. 클릭했고, 입력했고, 페이지를 넘겼고, 성공했고 실패했다는 순서가 담겨 있죠. 연구진은 이 기록을 그대로 외우지 않습니다. 기록에 자주 등장하는 흐름을 찾아서, 매개변수를 가진 브라우저 자동화 프로그램으로 다시 씁니다.

이 차이는 생각보다 중요합니다. 궤적을 그대로 저장하면 특정 상품명이나 특정 게시판에만 통하는 조각이 됩니다. 하지만 매개변수화된 프로그램으로 바꾸면 같은 뼈대에 다른 값을 넣어 여러 장면에서 쓸 수 있습니다. 예를 들어 특정 게시판에 글을 올린 기록이 있다면, 그 기록을 게시판 이름과 제목과 본문을 받는 하나의 동작으로 바꾸는 식입니다. 이렇게 되면 도구가 특정 기억이 아니라 재사용 가능한 동작이 됩니다.

저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 도구를 만드는 주체가 사람이 아니라, 궤적을 읽고 프로그램을 쓰는 또 하나의 에이전트 흐름이라는 점입니다. 사람이 일일이 규칙을 적어주지 않아도, 실제 행동에서 반복되는 뼈대가 드러나면 그것을 묶어내는 것이죠. 생각해보면 사람도 비슷하게 배웁니다. 처음에는 매번 헤매다가, 몇 번 해보고 나면 손에 익은 순서를 만드니까요. 그렇다면 뽑아낸 후보를 그대로 쓰면 될까요? 연구진의 답은 아니오에 가깝습니다.

이 연구가 말하는 게 아닌 것들

여기서는 조금 조심해서 읽을 필요가 있습니다. AutoTailor는 궤적을 모아서 검색하는 시스템이 아닙니다. 비슷한 일을 했던 기록을 찾아서 붙여넣는 방식과는 결이 다릅니다. 기록을 프로그램으로 다시 쓰기 때문에, 입력이 바뀌어도 같은 구조로 실행할 수 있고, 중간 단계의 토큰 왕복을 줄일 수 있습니다.

또한 미리 정해둔 고정 도구 모음을 자랑하는 연구도 아닙니다. 고정된 도구는 처음에는 편하지만, 사용자가 자주 하지 않는 기능까지 품고 있으면 선택이 어려워집니다. 이 연구는 오히려 반대쪽을 봅니다. 처음에는 많이 뽑아낸 뒤에, 꼭 필요한 것만 남기고 계속 고르는 쪽입니다. 그래서 도구가 많다는 말이 아니라, 맞는 도구가 적다는 말이 됩니다.

흔한 오해를 하나 더 짚으면, 이 연구는 낮은 수준의 조작을 완전히 없애자는 주장도 아닙니다. 뒤에서 살펴보겠지만, Tailored API만으로 풀 수 없는 일은 ReAct 같은 낮은 수준의 흐름으로 넘어가는 여지를 둡니다. 전부 자동화하겠다는 말이 아니라, 자주 통하는 길은 묶어서 빠르고 싸게 가고, 낯선 길은 여전히 눈으로 보고 가자는 것입니다. 운영 측면에서 보면 이 태도가 상당히 현실적입니다. 모든 경우를 하나의 도구로 덮으려 하면, 예외 하나에 전체가 멈추기 때문입니다.

궤적 한 뭉치를 프로그램 하나로 바꾸는 법

이제 오프라인 과정을 따라가 보겠습니다. 출발점은 웹 궤적의 모음입니다. 에이전트가 여러 작업에서 남긴 행동 기록이 쌓여 있는데, 처음에는 정제되지 않은 API 후보가 1,283개에 이릅니다. 이 숫자는 실패작이 많다는 뜻이 아니라, 자동 추출의 출발선이 원래 넓다는 뜻입니다. 같은 일을 조금씩 다르게 한 기록도 각각 후보가 되니까요.

이 후보들을 다듬는 첫 단계는 궤적을 프로그램으로 바꾸는 일입니다. 기록에 나타난 클릭과 입력의 순서를 그대로 두지 않고, 반복되는 뼈대를 찾은 뒤에 바뀌는 부분을 매개변수로 빼냅니다. 검색어가 달라져도, 게시판이 달라져도, 날짜 범위가 달라져도 같은 프로그램이 통하도록 만드는 것이죠. 이 과정을 거치면 도구는 특정 장면의 녹화가 아니라, 여러 장면에 꽂을 수 있는 틀이 됩니다.

저는 여기서 멈칫했습니다. 프로그램으로 바꾸는 일이 말처럼 쉽지 않기 때문입니다. 궤적에는 성공한 단계만 있는 게 아니라, 헤맸던 단계와 되돌아간 단계도 섞여 있습니다. 어디까지가 도구의 본체이고 어디부터가 그날의 헤맴인지 가르는 눈이 필요합니다. 연구진이 곧바로 품질 체를 두는 이유도 여기에 있습니다. 뽑아내는 일과 고르는 일은 처음부터 한 쌍으로 움직여야 합니다.

깎아내는 두 개의 체가 하는 일

오프라인 필터는 두 겹으로 되어 있습니다. 첫 번째는 Quality Filter인데, 입도가 맞지 않는 API와 기능이 겹치는 API를 덜어냅니다. 너무 잘게 쪼개진 도구는 낮은 수준의 조작과 다를 바가 없고, 너무 크게 묶인 도구는 자주 쓸 수 없습니다. 게다가 서로 같은 일을 하는 도구가 여러 개 있으면, 모델은 고르는 데에만 힘을 쓰게 됩니다.

두 번째는 Usage Likelihood Filter인데, 넓게 쓰일 법한 동작을 우선하면서 의미의 범위는 유지합니다. 자주 쓰일 것 같은 것만 남기되, 특정 의미 영역이 통째로 비어버리지는 않게 보는 것이죠. 예를 들어 게시물 관리와 검색과 설정 변경이 각기 다른 의미라면, 그중 하나를 전부 잘라내지는 않습니다. 적게 쓰이지만 꼭 필요한 동작까지 지워버리면, 나중에 그 영역에서 계속 실패하기 때문입니다.

이 두 체를 거치면 1,283개의 정제되지 않은 후보가 87개로 줄어듭니다. 숫자만 보면 많이 버린 셈인데, 버렸다는 표현보다 다듬었다는 표현이 어울립니다. 같은 일을 하는 중복을 합치고, 쓰기 어려운 입도를 고르고, 의미의 구멍이 생기지 않게 남겼기 때문입니다. 그런데 여기서 끝내면 한 가지 불안이 남습니다. 오프라인에서 고른 87개가 실제 작업에서도 맞는 선택일까요? 연구진은 이 질문을 온라인으로 가져갑니다.

온라인에서 다시 고르는 이유

웹은 가만히 있지 않습니다. 사용자가 자주 시키는 일이 바뀌고, 사이트 구조가 바뀌며, 오프라인에서 예상한 쓰임과 실제 쓰임이 어긋납니다. 그래서 AutoTailor는 온라인 Dynamic Reselection을 둡니다. 작업을 풀면서 과제 결과와 API 사용 기록을 보고, 반복해서 비는 자리를 찾으면 후보를 더하고, 계속 쓰이지 않는 동작은 덜어냅니다.

이 장치를 길게 보면 결국 적응의 문제로 돌아옵니다. 오프라인 선택이 한 번 찍은 사진이라면, 온라인 재선택은 그 뒤에 이어지는 관찰 일지에 가깝습니다. 어떤 API가 자주 불리는지, 어떤 작업에서 자꾸 낮은 수준의 흐름으로 떨어지는지, 어디에서 같은 실패가 반복되는지를 봅니다. 자주 비는 자리가 보이면 그 자리를 메울 후보를 올리고, 오래 비어 있는 자리는 정리하는 것이죠.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 언제 더하고 언제를 뺄 것인가? 너무 빨리 바꾸면 아직 익숙해지지 않은 도구를 잃을 수 있고, 너무 늦게 바꾸면 안 맞는 도구를 오래 품고 가야 합니다. 연구진이 결과와 사용을 함께 본다는 점이 그래서 눈에 띕니다. 성공했는지뿐 아니라, 어떻게 성공했는지까지 보기 때문입니다. 이 관찰을 거치면 87개의 집합이 106개의 WebArena Postmill 과제 기준으로 33개까지 줄어듭니다. 줄어든 숫자 자체보다, 줄어드는 동안 비는 자리를 메웠다는 점이 더 중요합니다.

1283개가 33개로 줄어도 성적이 오른 이유

이제 숫자를 볼 차례입니다. 이 숫자는 그대로 믿기 전에 조건을 봐야 합니다. 먼저 ReAct fallback이 함께 있을 때, 33개 API 집합은 90.6%의 정확도를 냈고, ReAct만 썼을 때는 87.5%였습니다. 정확도가 소폭 올랐는데, 평균 전체 요청 토큰 비용은 57.8% 줄었고 지연시간은 29.4% 줄었습니다. 성적이 유지된 채로 비용과 시간이 함께 내려갔다는 점이 이 결과의 표면입니다.

같은 결과를 뒤집어서 보면, 도구가 적어졌는데 성적이 오른 셈입니다. 어떻게 이런 일이 가능할까요? 이유는 도구가 일을 대신해서가 아니라, 모델이 헤매는 구간을 줄여주기 때문입니다. 자주 통하는 흐름이 하나의 호출로 묶이면, 낮은 수준의 판단이 반복되지 않고, 중간에 어긋날 자리도 줄어듭니다. 남는 힘으로 낯선 부분에 더 집중할 수 있으니, 전체 성공률이 오히려 올라갈 자리가 생깁니다.

여기서 또 다른 조건을 봐야 합니다. ReAct 없이 Tailored 집합만 썼을 때는 정확도가 60.1%였고, 정제되지 않은 집합과 비교하면 요청 토큰 사용량이 94.9% 줄었습니다. 정확도만 떼어놓고 보면 fallback이 있을 때보다 낮지만, 토큰 감소 폭은 매우 큽니다. 저는 이 대목을 마음에 들어하면서도, 여기까지만 일반화하기에는 데이터가 부족하다고 봅니다. 이 결과는 106개의 Postmill 과제라는 특정 무대 위의 기록이고, 도구가 모든 일을 대신할 수 있다는 말이 아니기 때문입니다. 그래서 다음 결과가 중요합니다. 싼 도구가 아니라, fallback과 함께 쓰는 구조가 성적을 만든다는 점입니다.

토큰과 지연시간이 함께 내려간 장면

저희가 새로운 AI 아키텍처를 볼 때도 benchmark 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다. 이 연구에서 토큰과 지연시간이 함께 내려간 이유는 호출의 모양이 바뀌었기 때문입니다. 낮은 수준의 조작에서는 매 단계마다 화면 상태를 읽고 다음 행동을 정해야 해서 왕복이 많습니다. 묶인 API에서는 그 왕복이 하나의 실행으로 접힙니다.

일반 파일에만 남겼을 때와 SOUL에 옮겨 적었을 때의 차이처럼, 어디에 무엇을 두느냐가 결과를 바꾸는 경우와 비슷하게, 여기서는 자주 쓰는 흐름을 어디에 두느냐가 비용을 바꿉니다. 매번 모델에게 묻는 대신 프로그램에게 맡기면, 요청 토큰이 줄고 단계가 짧아지며 지연시간이 내려갑니다. 57.8%와 29.4%라는 한 쌍의 숫자는 그래서 따로 읽으면 안 됩니다. 같은 구조 변화가 만든 두 개의 그림자이기 때문입니다.

좋은 건 알겠는데, 이걸 실제로 어떻게 서빙할까요? 도구가 프로그램이라면 실행 환경과 권한과 타임아웃과 실패 처리를 정해야 합니다. 브라우저 자동화는 중간에 페이지가 늦게 뜨거나 요소가 바뀌는 일이 흔해서, 도구가 실패했을 때 낮은 수준의 흐름으로 자연스럽게 넘어가는 설계가 필요합니다. 이 연구가 ReAct fallback을 함께 둔 것은 그래서 설득력이 있습니다. 빠른 길이 막히면 느린 길로 돌아가는 문을 남겨둔 것이죠. 운영의 아침을 지켜주는 장치는 대개 이런 식으로 생겼습니다.

그래서 사람은 무엇을 시키게 될까

마지막에는 처음으로 돌아올 차례입니다. 도구가 33개로 줄었다는 말은 사람이 시킬 수 있는 일이 줄었다는 말이 아닙니다. 자주 쓰는 동작이 묶였다는 뜻이고, 묶인 동작 위에서 더 큰 일을 시킬 자리가 생겼다는 뜻입니다. 사람은 낮은 수준의 클릭 순서를 외울 필요가 없고, 원하는 결과와 조건을 말하면 됩니다.

그렇다면 사람의 역할은 무엇일까요. 저는 앞으로 보고 싶은 것이 두 가지 있습니다. 하나는 사용자와 맞는다는 말이 실제로 어떻게 재어지는지입니다. 자주 쓰인다는 기록과 사용자가 진짜 원한다는 뜻은 겹치지만 완전히 같지는 않습니다. 많이 불린 API가 정말 만족스러운 결과를 냈는지, 아니면 그럭저럭 통했기 때문에 불린 것인지를 가르는 눈이 필요합니다. 다른 하나는 오래 쓰는 동안 도구가 어떻게 변하는지입니다. 사이트가 바뀌고 습관이 바뀌면, 오늘의 33개가 내일도 33개일 수는 없습니다.

이 논문이 남기는 장면은 그래서 단순한 효율 이야기가 아닙니다. 에이전트가 일한 기록에서 도구를 뽑아내고, 쓰는 모습을 보면서 다시 고르는 순환이 있다는 점입니다. 이 순환이 잘 돌면, 에이전트는 매번 처음부터 헤매지 않습니다. 손에 익은 도구를 먼저 쓰고, 낯선 곳에서만 눈을 크게 뜹니다. 꽤 사람 같기도 합니다. 여러분이 매일 반복하는 웹 일 가운데, 먼저 묶어두고 싶은 흐름은 어떤 것인가요?