같은 AI 모델이 같은 개발 과제를 수행해도 연결된 도구와 실행 방식에 따라 토큰 비용이 수십 배 달라진다. 에이전트를 둘러싼 도구 구성과 대화, 검증, 종료 규칙을 스캐폴드라 부르며 모델 사용료와 작업 성공률을 함께 좌우한다. 특히 코딩 에이전트를 운영하거나 도입 비용을 비교하는 조직은 모델 성능표만으로 예산을 계산할 수 없다. 비용 차이는 도구 호출 방식과 컨텍스트 관리에서 갈렸으며 얇은 구성이 유리한 조건도 뚜렷했다.
에이전트 비용은 모델만으로 결정되지 않는다. 도구를 언제 보여 주고 대화 기록을 어떻게 관리하며 언제 검증하고 멈출지를 정하는 스캐폴드도 비용과 성공률을 좌우한다.
Composio가 모델과 MCP(Model Context Protocol) 도구를 고정한 채 여덟 개 하네스를 비교하자 통과율은 68~88%, 성공 1건당 비용은 0.46~1.96달러로 4.3배 차이 났다. 호출 횟수가 402회와 223회로 크게 다른 두 하네스가 똑같이 18개 과제를 통과했다. 도구 호출 수와 성과는 비례하지 않았다.
다른 통제 실험에서는 같은 모델을 세 하네스에 연결했을 때 통과율 차이는 0~8%였지만 해결당 토큰은 최대 40배 벌어졌다. 평균 턴 수는 21~27회로 비슷했다. 작업량보다 행동 없는 턴마다 누적 컨텍스트를 다시 처리하는 방식이 차이를 키웠다.
SWE-bench Verified에서는 같은 모델로 같은 과제를 풀어도 총 토큰이 최대 30배 달랐고, 더 많은 토큰이 더 높은 정확도로 이어지지 않았다. 완료율만으로는 하네스의 효율을 판단하기 어렵다.
안 쓰는 도구 설명까지 매 턴 다시 읽는다
같은 GitHub 조회인데 토큰이 왜 32배나 갈릴까? GitHub 저장소의 언어와 라이선스를 찾는 같은 작업에서 CLI는 1,365토큰을 썼고 MCP는 44,026토큰을 썼다. 약 32배 차이다. 전체 과제에서도 격차는 4~32배였다. CLI는 25회 모두 성공했지만 MCP는 네트워크 시간 초과 때문에 18회만 성공했다. 다만 이 실패는 토큰 오버헤드와 별개의 안정성 문제다.
일부 MCP 구성은 서버에 등록된 도구의 이름, 설명, 인자와 제약을 처음부터 컨텍스트에 넣는다. 실제로 한두 개만 써도 여러 서버의 도구 정의 전체가 들어간다. 대화가 길어지면 모델은 이 고정 입력과 누적 기록을 거듭 처리한다. 쓰지 않는 설명까지 매 턴 다시 읽는 구조다.
이 부담을 줄이려면 MCP는 유지하되 도구를 필요할 때만 불러오면 된다. Anthropic은 도구를 파일처럼 탐색하고 코드로 호출해 15만 토큰 규모의 작업을 2천 토큰으로 줄였다. 120개 도구를 사용한 별도 측정에서도 25턴의 사용량이 362,350토큰에서 5,181토큰으로 감소했다.
그런데 프롬프트 캐시는 청구액만 낮출 뿐, 컨텍스트를 작게 만들지는 않는다. 입력이 길어지면 모델이 작업 기록과 지시를 놓치기도 한다. OctoBench에서 개별 지시의 준수율은 약 80~86%였지만 모든 지시를 지킨 실행은 9.66~28.11%에 그쳤다. 도구 정의를 직접 측정한 결과는 아니지만, 컨텍스트 관리도 신뢰성 문제라는 말이다.
모델 크기에 맞춰 하네스를 깎아라
도구 설명은 고정된 채로 수만 토큰을 차지한다. 로컬 모델은 컨텍스트가 작아 이 부담을 특히 크게 받는다. 도구 정의가 공간을 먼저 차지하면 탐색 결과, 오류 원인, 검증 조건을 함께 유지하기 어려워진다.
소형 모델용 하네스 little-coder는 시작할 때 불러오는 확장과 지침을 줄이고 도구 수와 추론 예산을 조정했다. 같은 Qwen3.5 9.7B의 Aider Polyglot 통과율은 기본 Aider의 19.11%에서 45.56%로 올랐다. 여러 요소를 함께 바꾼 결과라 개별 효과를 분리할 수는 없지만, 모델 크기에 맞춘 스캐폴드가 성과를 가른다는 말이다.
반대로 과제가 짧고 도구가 적으며 결과를 자동 검사할 수 있으면 얇은 하네스가 유리하다. git, gh, bash처럼 모델에 익숙한 인터페이스는 긴 설명도 덜 필요하다. 파일시스템과 터미널만 제공한 에이전트가 일부 기업 자동화 과제에서 MCP나 웹 GUI와 대등하거나 더 나은 결과를 더 낮은 비용으로 냈다.
그런데 기업 환경에서는 MCP의 추가 입력에도 근거가 있다. OAuth 2.1 인가, 자격증명 격리, 호출 기록 같은 통제가 필요하기 때문이다. 규제 대상 환경에서 MCP의 토큰 비용은 접근 통제와 감사를 위한 운영 비용 이다.
싼 실행은 일찍 실패한 실행일 수 있다
싼 실행은 곧 효율일까? 평균 비용에는 실패한 실행이 쓴 토큰도 포함된다. Scaffold Effect 연구에서 어떤 하네스는 추론 중 일찍 멈췄고, 다른 하네스는 검증이나 최대 턴까지 계속했다. 같은 모델이라도 종료 규칙에 따라 실패 비용은 달라지기 마련이다. 싼 실행도 사실은 일찍 실패해 비용이 덜 든 경우일 수 있다.
오래 재시도한다고 품질이 보장되지도 않는다. SlopCodeBench에서는 20개 반복 개선 과제를 끝까지 해결한 에이전트가 없었고 최고 해결률도 17.2%에 그쳤다. 실행의 89.8%에서는 코드 중복이 늘었다.
완료율에 성공 1건당 토큰, 청구액, 무행동 턴, 도구 호출 수, 종료 원인, 재시도 총비용을 더하면 그림이 달라진다. Anthropic도 턴 수, 도구 호출, 총 토큰, 지연 시간을 따로 추적 할 것을 권한다. 여러 번 중 한 번 성공하는 pass@k만 보면 재시도 비용이 가려진다.
단가를 결정하는 것은 도구를 부르는 방식과 컨텍스트 관리다. 필요한 도구만 제때 불러오고 누적 컨텍스트와 무행동 반복을 줄이며 검증과 종료 조건을 분명히 하는 것이 관건이다. 보안과 감사가 필요하다면 추가 비용은 통제의 대가인 경우가 많다. 모델과 스캐폴드는 하나의 시스템이다.
비용을 줄인 실행이 좋은 실행인가는 절감된 토큰이 어디서 빠졌는지가 가른다. 불필요한 컨텍스트를 줄여 비용이 준 경우와 검증 전에 멈춰 비용이 준 경우는 같은 비용표라도 운영 결과가 전혀 다르다. 검증을 건너뛴 절감은 숫자만 남기고, 품질 기준은 사라진다.