에이전트 비용은 프롬프트보다 도구 목록에서 터진다 — 토큰 효율화 실전 패턴

에이전트 비용을 잡겠다고 하면 보통 프롬프트부터 줄인다. 지시문을 한 줄이라도 덜 쓰고, 시스템 프롬프트를 압축하고, 예시를 빼는 식이다. 물론 의미는 있다. 그런데 운영 환경에서는 더 큰 구멍이 따로 있다. 도구 목록이다.

에이전트가 호출할 수 있는 도구가 많아질수록, 그리고 그 도구 설명과 JSON 스키마가 길수록 매 턴 컨텍스트가 조용히 비대해진다. 프롬프트는 2KB인데 도구 메타데이터가 12KB면, 비용은 사실상 도구 목록에서 터지는 셈이다.

이 문제를 실무적으로 잘 보여주는 사례가 GitHub Agentic Workflows다. GitHub는 실제 운영 워크플로를 계측한 뒤, 가장 흔한 비효율이 불필요한 MCP 도구 등록이라고 공개했다. 포인트는 단순하다. 안 쓰는 도구도 모델에게는 매번 설명해야 한다.

왜 프롬프트보다 도구 목록이 더 비싼가

LLM API는 기본적으로 stateless다. 매 요청마다 모델은 현재 턴에 필요한 문맥을 다시 받아야 한다. 이때 에이전트 런타임은 보통 다음을 같이 보낸다.

• 시스템 프롬프트
• 사용자 요청
• 이전 대화 일부
• 사용 가능한 도구 이름
• 각 도구의 설명
• 각 도구의 입력 JSON 스키마

여기서 마지막 세 항목이 생각보다 크다. 특히 MCP(Model Context Protocol) 서버를 붙이면 도구가 표준화된 형태로 잘 노출되는 대신, 그 메타데이터도 같이 커진다.

GitHub 사례에서는 GitHub MCP 서버에 도구가 40개 있을 때, 도구 스키마만으로 턴당 10KB에서 15KB가 추가될 수 있다고 설명했다. 에이전트가 실제로 두 개만 써도 나머지 38개는 그냥 고정비다. PR마다 자동 실행되는 워크플로라면 이 비용은 바로 누적된다.

MCP를 많이 붙일수록 좋은 게 아니다

MCP는 훌륭한 표준이다. AI 애플리케이션이 외부 시스템과 연결되는 방식을 통일해준다. 파일, 데이터베이스, GitHub, 브라우저 같은 도구를 같은 방식으로 붙일 수 있다. 문제는 표준화가 곧 공짜는 아니라는 점이다.

도구를 많이 연결하면 에이전트는 더 많은 일을 할 수 있다. 동시에 더 많은 선택지를 매 턴 검토해야 한다. 운영 관점에서는 두 가지 비용이 생긴다.

첫째, 컨텍스트 비용이다. 도구 설명이 길수록 입력 토큰이 커진다. 둘째, 추론 비용이다. 모델이 “어떤 도구를 쓸지” 판단하는 단계 자체가 늘어난다.

그래서 에이전트 설계에서는 “붙일 수 있는가”보다 “매 턴 노출해야 하는가”를 먼저 물어야 한다.

패턴 1. MCP tool pruning: 안 쓰는 도구부터 빼라

가장 먼저 할 일은 pruning이다. 말 그대로 도구 가지치기다. 워크플로가 실제로 쓰는 도구만 남기고 나머지는 제거한다.

잘못된 예시는 이렇다.

mcp:
  github: all
  filesystem: all
  browser: all

처음 만들 때는 편하다. 나중에는 대부분 독이 된다. 실제 워크플로는 대개 좁고 반복적인 도구 집합만 쓴다. 예를 들어 PR 리뷰 자동화라면 필요한 건 보통 이 정도다.

mcp:
  github:
    - pull_request_diff
    - pull_request_comments
    - changed_files

GitHub는 smoke test 워크플로에서 불필요한 MCP 도구를 제거하자 호출당 컨텍스트가 8KB에서 12KB 줄었다고 밝혔다. 동작은 그대로인데 매 실행마다 수천 토큰을 아낀 셈이다.

운영 팁은 간단하다.

• 최근 7일 실행 로그에서 실제 호출된 도구 목록을 뽑는다
• 한 번도 호출되지 않은 도구를 제거 후보로 둔다
• 워크플로 목적과 무관한 범용 도구를 우선 제거한다
• 변경 전후 토큰 수가 아니라 턴당 평균 입력 토큰을 비교한다

중요한 건 “혹시 필요할지도 모른다”는 이유로 도구를 남겨두지 않는 것이다. 에이전트 비용은 보험처럼 붙여둔 도구에서 자주 새어난다.

패턴 2. Prefetch: 어차피 필요한 데이터는 먼저 받아둬라

두 번째 패턴은 prefetch다. 에이전트가 항상 필요로 하는 데이터는 모델이 판단해서 가져오게 하지 말고, 워크플로 시작 전에 먼저 받아 workspace 파일로 내려놓는다.

예를 들어 PR 리뷰 에이전트는 거의 항상 다음이 필요하다.

• PR diff
• changed files 목록
• 기존 리뷰 코멘트

이걸 MCP 도구 호출로 가져오면, 모델은 도구를 고르고, 인자를 만들고, 응답을 다시 컨텍스트에 넣어야 한다. 한 번의 데이터 조회가 곧 한 번의 추론 루프가 된다.

반대로 먼저 받아두면 된다.

steps:
  - name: Prefetch PR data
    run: |
      gh pr diff $PR_NUMBER > .aw/pr.diff
      gh pr view $PR_NUMBER --json files,comments > .aw/pr.json

  - name: Run agent
    run: agent --prompt-file prompts/review.md

이 방식의 장점은 세 가지다.

• 도구 호출 스키마 비용이 사라진다
• 데이터 조회를 위한 LLM 턴이 줄어든다
• 같은 입력을 여러 번 재사용할 수 있다

GitHub도 이 패턴을 핵심 최적화로 소개했다. PR diff처럼 항상 필요한 정보는 gh로 선행 다운로드하고, 에이전트는 그 파일을 읽기만 하게 만든다. 제일 싼 도구 호출은 애초에 호출하지 않는 것이다.

패턴 3. CLI substitution: 읽기 작업은 도구보다 CLI가 낫다

세 번째는 CLI 대체다. 특히 GitHub API처럼 이미 안정적인 CLI가 있는 경우 효과가 크다.

MCP 도구 호출은 단순 조회라도 모델의 추론 단계를 먹는다. 반면 CLI는 결정적이다. gh pr diff는 그냥 HTTP 요청 하나로 끝난다. 모델이 개입하지 않는다.

# MCP 방식
agent -> "diff를 가져와야 하나?" -> tool schema 포함 요청 -> tool call -> 응답

# CLI 방식
gh pr diff 123 > pr.diff

이 차이는 단순한 토큰 절감 이상이다. 운영 안정성도 좋아진다. 읽기 전용 데이터 조회를 모델 루프 밖으로 밀어내면, 에이전트는 해석과 판단에만 집중할 수 있다.

다만 쓰기 작업까지 무조건 CLI로 내리면 보안 경계가 흐려질 수 있다. GitHub Agentic Workflows는 이 지점을 꽤 보수적으로 다룬다. 에이전트에게 직접 시크릿을 주지 않고, API proxy와 safe outputs로 쓰기 경로를 분리한다. 읽기는 CLI나 prefetch로 단순화하고, 쓰기는 통제된 경로로 남겨두는 식이다.

이 구분은 꼭 필요하다.

• 읽기: 가능하면 prefetch 또는 CLI
• 쓰기: 승인된 도구, 제한된 권한, 감사 로그 유지

비용 절감 때문에 보안 모델을 무너뜨리면 결국 더 큰 운영비가 돌아온다.

계측 없이 최적화하면 착시가 생긴다

토큰 절감은 느낌으로 하면 안 된다. GitHub가 먼저 한 일도 계측이었다. 각 호출의 input, output, cache read, cache write를 남기고 워크플로별로 usage artifact를 쌓았다.

실무에서도 최소한 이 정도는 봐야 한다.

• 실행당 총 입력 토큰
• 턴당 평균 입력 토큰
• 도구 호출 횟수
• 도구별 호출 분포
• 워크플로 실행 빈도

특히 총 토큰만 보면 착시가 생긴다. 이번 주 PR이 커서 토큰이 늘어난 것인지, 도구 구성이 비효율적인 것인지 구분해야 한다. 그래서 턴당 입력 토큰과 도구 호출 수를 같이 봐야 한다.

간단한 운영 규칙을 두면 좋다.

- 새 워크플로 배포 전: 도구 목록 검토
- 주 1회: 실제 호출되지 않은 도구 탐지
- 월 1회: prefetch 가능한 조회 작업 재분류
- 비용 급증 시: 프롬프트보다 도구 메타데이터부터 확인

결국 줄여야 하는 건 추론 루프다

에이전트 비용을 줄이는 가장 좋은 방법은 모델이 덜 생각하게 만드는 것이다. 더 정확히 말하면, 모델이 생각할 필요가 없는 일을 모델에게 넘기지 않는 것이다.

정리하면 우선순위는 이렇다.

1. 안 쓰는 MCP 도구 제거
2. 항상 필요한 데이터는 prefetch
3. 읽기 작업은 CLI로 대체
4. 쓰기 작업만 통제된 도구로 유지
5. 토큰 총량보다 턴당 컨텍스트 크기부터 본다

프롬프트 최적화는 마지막에 해도 된다. 운영 환경에서 진짜 큰 비용은 대개 프롬프트 문장 몇 줄이 아니라, 매 턴 따라붙는 도구 설명과 스키마다. 에이전트가 똑똑해질수록 도구를 많이 붙이고 싶어지지만, 비용 관점에서는 반대로 설계해야 한다. 필요한 것만 노출하고, 나머지는 워크플로 바깥에서 미리 처리해야 한다.

에이전트 비용은 프롬프트보다 도구 목록에서 더 자주 터진다. 이 사실을 먼저 받아들이면 최적화 순서도 자연스럽게 바뀐다.

참고 자료

• Improving token efficiency in GitHub Agentic Workflows : GitHub의 실제 운영 워크플로에서 unused MCP tools, prefetch, CLI 대체로 토큰 효율을 높인 사례
• Under the hood: Security architecture of GitHub Agentic Workflows : zero-secrets, API proxy, safe outputs 등 비용 최적화와 함께 고려해야 할 실행 보안 구조
• What is the Model Context Protocol (MCP)? : MCP의 목적과 기본 개념 정리