Agent in a Bottle: 비싼 AI 작업을 저렴한 재사용 도구로 바꿀 수 있을까?

배경과 문제

LLM은 제품 설명에서 속성 추출, 금융 보고서 구조화 같은 좁고 반복적인 작업을 자동화하는 데 점점 많이 쓰인다. 하지만 매번 범용 LLM을 호출하면 총 추론 비용이 인스턴스 수에 거의 선형적으로 증가한다. 예를 들어 수백만 건의 상품 설명에서 특정 속성을 뽑아내야 한다면, 각 건마다 거대 모델을 호출하는 것은 엄청난 비용이 든다. 그런데 각 작업은 모델의 능력 중 아주 좁은 부분만 필요로 하는 경우가 많다. 최근 연구들은 이런 작업에 소형 언어 모델(SLM)로 충분하다고 주장하며, 증류(distillation)나 재사용 가능한 프로그램 같은 경량 아티팩트를 만드는 접근을 제안했다.

보틀링(bottling)은 범용 능력을 특정 작업용 도구로 바꾸는 능력이다. 비유하면 요리사에게 매 끼니를 주문하는 대신, 반복 주문에 맞는 조리 도구와 절차를 한 번 만들게 하는 셈이다. 처음 만드는 비용을 많은 처리 건수에 나눠 부담하므로, 준비에 얼마나 투자할지와 남은 자원으로 전체 작업을 끝낼지를 함께 판단해야 한다. 실험에서는 정답 레이블을 숨긴 전체 입력을 처음부터 보여 주고, 정해진 예산 안에서 모든 입력의 예측을 요구한다.

기존 접근의 한계

기존 연구는 LLM 호출 비용을 줄이기 위해 여러 메커니즘을 사용해 왔다. 대표적으로 큰 모델의 능력을 작은 모델로 증류하거나, 크고 작은 모델을 협업시키거나, 모델을 직접 압축하거나, 비용과 능력이 다른 모델들 사이에서 쿼리를 라우팅하는 방법 등이 있다. 또 에이전트 궤적을 자연어 설명이나 실행 코드로 패키징하는 연구도 있다. 하지만 이런 방법들은 대개 사람이 미리 정한 절차를 따르거나, 에이전트가 전체 작업 부하를 보기 전에 궤적을 생성한다는 한계가 있다.

BOTTLED는 기존 접근과 달리 에이전트가 전체 비라벨 작업 부하를 처음부터 보고, 어떤 아티팩트를 만들지 스스로 결정하게 한다. 또한 증류 메커니즘을 강제하지 않고, 규칙 기반 프로그램, 파인튜닝된 소형 모델, 검색 인덱스, 또는 어려운 부분만 다시 LLM에 라우팅하는 하이브리드 방식 등 어떤 형태든 허용한다. 이는 에이전트가 upfront 구축 비용, 다운스트림 추론 비용, 작업 품질 사이의 균형을 스스로 판단해야 함을 의미한다. 기존 벤치마크가 에이전트의 ML 실험이나 소프트웨어 엔지니어링 능력을 평가했다면, BOTTLED는 '값비싼 범용 모델 호출을 더 싼 전용 솔루션으로 대체할 수 있는가'라는 다른 질문을 던진다.

연구방법을 단계별로

세 과제는 수백만 건을 한꺼번에 처리하는 설정이다. MAVE는 약 477만 상품-속성 쌍에서 값을 뽑으며 F1으로 평가한다. ESCI는 약 262만 검색어-상품 쌍을 정확히 맞음·대체품·보완품·무관함으로 분류하고, 클래스별 성능을 같은 비중으로 평균하는 macro-F1을 쓴다. RAID는 약 562만 문서의 AI 작성 가능성을 예측하고 AUROC로 평가한다. 정답 레이블은 채점자가 보유하며 에이전트에게 주어지지 않는다.

실험 설정에서 각 에이전트는 NVIDIA A100 GPU 1개(40GB VRAM), 8 CPU 코어, 64GB RAM을 가진 샌드박스 환경에서 작동한다. 시간 예산은 10시간, 토큰 예산은 500만 토큰이다. 토큰 계산은 단순 개수가 아니라 가중치를 적용하는데, 출력 토큰은 비캐시 입력 토큰의 2배, 캐시 입력 토큰은 0.1배로 계산한다. 에이전트는 자신의 모델 API만 호출할 수 있고, 다른 모델 API는 사용할 수 없다. 인터넷 접근은 가능하지만 라벨 유출을 막기 위해 벤치마크 데이터셋이나 그 라벨로 학습된 모델을 호스팅하는 URL은 프록시에서 차단된다. 에이전트는 예산이 소진되기 전에 모든 인스턴스에 대한 예측을 out.txt 파일에 작성해야 하며, 파일이 없거나 불완전하면 작업별 fallback 답변으로 대체된다.

평가를 위해 zero-shot 기준선과 SLM 증류 기준선을 사용한다. zero-shot 기준선은 각 인스턴스를 개별적으로 LLM에 질의하며, 전체 부하에 대한 비용은 1000개 균일 표본에서 추정한다. SLM 증류 기준선은 GLM 5.3 Flash를 교사 모델로 사용하여 500만 토큰 예산이 소진될 때까지 라벨을 만들고, Qwen3-0.6B와 SmolLM2-360M-Instruct 두 학생 모델을 파인튜닝한다. 이 기준선은 에이전트와 동일한 토큰 예산을 쓰지만 에이전트적 의사결정 없이 고정된 스크립트를 따른다. 최종 점수는 작업별 메트릭을 trivial baseline과 gold label 사이의 간격으로 정규화한 상대 이득(relative gain)으로 집계한다.

결과와 숫자의 의미

주요 발견은 zero-shot 성능이 좋다고 보틀링 능력이 좋은 것은 아니라는 점이다. MAVE에서 zero-shot F1은 0.426~0.510 범위로 좁지만, 보틀링 후 F1은 거의 0에 가까운 모델부터 0.461까지 5배 이상 넓게 퍼진다. 예를 들어 GPT 5.6 Terra와 Sonnet 5는 zero-shot F1이 모두 약 0.44로 비슷하지만, 보틀링 후 평균 F1은 각각 0.405와 0.154로 크게 차이난다. ESCI에서도 GLM 5.3과 GPT 5.6 Terra의 zero-shot macro F1이 0.593과 0.573으로 유사하지만, 보틀링 후에는 0.497과 0.265로 갈린다. GLM 5.3은 zero-shot 성능의 약 84%를 유지한 반면 GPT 5.6 Terra는 약 46%만 유지했다.

전체 60회 실행 중 48회가 해당 모델의 zero-shot 95% 신뢰구간 하한보다 낮은 점수를 받았고, 40회는 해당 과제에서 가장 낮은 zero-shot 모델의 95% 신뢰구간 하한보다도 낮았다. 또한 31회는 동일한 토큰 예산을 쓴 두 SLM 증류 기준선 중 더 나은 학생 모델보다 성능이 낮았다. 이는 자율 에이전트에 예산을 주는 것이 단순한 증류 스크립트보다 나쁠 수 있음을 보여준다. 비용 측면에서는 GLM 5.3 Flash가 1달러 미만의 비용으로 약 39%의 상대 이득을 달성해, 약 29달러를 쓴 Opus 5(약 42%)를 제외한 모든 더 비싼 모델을 지배했다. GPT 5.6 Sol은 약 12달러를 썼지만 상대 이득은 약 6%에 그쳤다.

그럼에도 보틀링은 상당한 비용 절감을 가져올 수 있다. ESCI에서 Opus 5는 zero-shot macro F1 0.609의 약 82%인 0.499를 달성하면서 보고된 비용은 26.28달러로, zero-shot 전체 부하 비용 추정치 17,273달러의 약 657분의 1이다. 또한 'system one' 모델인 Jev와 비교하면, Opus 5는 Jev의 macro F1 0.531의 약 94%를 Jev 예상 비용의 약 4분의 1로 달성했다. RAID에서는 Gemini 3.1 Pro가 Jev AUROC 0.846의 97% 이상인 0.822를 Jev 비용의 약 2%로 달성했다. 다만 Jev는 생성 작업인 MAVE에는 사용할 수 없어 비교가 ESCI와 RAID로 제한된다.

구체적인 예시

예산 관리와 도구 해석의 실패도 보고되었다. 60회 중 21회는 토큰 예산을 소진해 중단됐고, 그중 8회는 요구된 완전한 예측 파일 제출 조건을 충족하지 못했다. 한 MAVE 실행에서는 예산을 주시하겠다고 하던 GPT 5.6 Sol이 수천 건을 순차 API로 라벨링하다 중단됐다. Gemini 3.1 Flash-Lite의 ESCI 실행은 도구가 앞부분만 보여 줬다는 경고를 놓치고, 수백만 입력을 49개로 오해했다. 49개 답변만 제출하면서 가중 토큰 예산을 약 495만 남겼다. 이는 지식 부족 외에도 파일 규모 확인과 작업 완료 판단이 결과를 좌우함을 보여주는 사례다.

Sonnet 5는 MAVE 두 실행 모두에서 파인튜닝 없이 오프더셸프 SLM(Qwen2.5-1.5B-Instruct)을 전체 부하에 프롬프트하는 방식을 택했고, F1이 0.194와 0.113에 그쳤다. 이는 Sonnet 5의 zero-shot F1 0.444에 크게 못 미친다. 반면 Opus 5는 MAVE에서 평균 보틀링 F1 0.461을 달성해 zero-shot F1 0.483의 95% 이상을 회복했고, 비용은 31.40달러로 zero-shot 전체 부하 비용 추정치 27,914달러의 약 889분의 1이었다. 이처럼 같은 예산과 환경에서도 에이전트의 전략 선택에 따라 결과가 극명하게 갈린다.

한계와 오해하기 쉬운 점

이 연구의 숫자를 해석할 때 주의할 점이 있다. '48/60'은 실패 실행 비율이 아니라, 60회 보틀링 실행 중 해당 모델의 zero-shot 95% 신뢰구간 하한보다 낮은 점수를 받은 횟수다. zero-shot 비교는 각 과제에서 1000개 표본을 사용하고 95% 부트스트랩 신뢰구간을 계산한 것이다. 또한 '657배 비용 차이'는 논문이 보고한 API 비용과 전체 작업량 외삽 비교이며, F1 0.499/0.609 약 82%를 유지했다는 것이지 정확도 82%나 모든 운영비 657배 절약을 의미하지 않는다. 실행당 하드웨어 조건은 A100 40GB 1개, 8 CPU 코어, 64GB RAM, 10시간이며, 토큰 예산 500만은 가중 토큰(uncached input 1, cached input 0.1, output 2) 기준이다.

증류 비교군은 GLM 5.3 Flash가 레이블을 만든 작은 모델이다. 같은 가중 토큰 예산이지만 각 에이전트와 교사 모델이 동일하지는 않다. 데이터 오염 감사에서는 GLM 5.3 Flash의 RAID 실행 한 건이 해당 데이터로 부분 학습된 탐지기를 사용해 제외됐고, 차단 목록을 보완한 재실행이 주 결과에 들어갔다. 토큰 예산 중단을 해제한 추가 실험에서도 60회 중 47회가 zero-shot 신뢰구간 하한 미달이었다. 따라서 관찰된 성능 격차를 예산 부족만으로 설명할 수는 없다.

실제로 어떻게 활용할까

보틀링은 실제 산업에서 반복적인 대규모 작업을 자동화할 때 유용할 수 있다. 예를 들어 전자상거래 카탈로그에서 수백만 개 상품 설명의 속성을 추출하거나, 콘텐츠 모더레이션에서 대량의 문서를 분류해야 할 때, 매번 프론티어 LLM을 호출하는 대신 에이전트가 만든 경량 아티팩트를 사용하면 비용을 크게 줄일 수 있다. 논문은 보틀링이 'system one' 모델과도 경쟁력이 있다고 보여주는데, 작업 부하가 더 커질수록 Jev 같은 모델은 비용이 선형적으로 증가하지만 보틀링은 계산을 재사용해 비용 증가를 늦출 수 있다.

실무에서는 직접 질의의 품질, 단순한 증류 방식, 에이전트가 만든 도구를 같은 작업에서 비교해 볼 수 있다. 완전한 출력 파일이 나왔는지 먼저 확인하고, 숨겨 둔 평가 자료에서 품질 손실과 구축·실행 비용을 함께 측정해야 한다. 이는 논문의 결과에서 도출한 적용 아이디어이며 특정 모델의 현재 서비스 성능을 보증하지 않는다. 평가가 세 과제와 모델당 과제별 두 번의 실행에 한정되었다는 점도 남는다.