AI 에이전트는 왜 이렇게 많은 토큰을 쓰는가 (20단계 예시)

에이전트에게 질문 하나를 던졌는데 몇 분 동안 작업하고 나면 사용량 페이지에 수십만 토큰이 찍힌다. 뭔가 고장 난 게 아니다. 에이전트는 루프이고, 루프의 매 턴마다 지금까지 오간 모든 것(도구 목록, 히스토리, 도구가 반환한 것 전부)을 입력 토큰으로 다시 보낸다. 에이전트가 쓴 답변은 아주 작다. 하지만 계속해서 다시 읽는 것은 그렇지 않다.

한 장으로 보는 에이전트#

채팅 모델은 한 번 답한다. 에이전트는 도구를 쥔 루프 안의 같은 모델이다: 파일 읽기, 웹 검색, 명령 실행. 그리고 모델은 호출 사이에 아무것도 기억하지 못한다. 전화를 끊을 때마다 모든 걸 잊어버리는 비서를 떠올려 보자: 다시 전화할 때마다 처음부터 메모를 읽고, 한 줄을 덧붙인다. API가 작동하는 방식이 바로 이렇다.

Anthropic의 도구 사용 문서(2026년 10월 26일 확인)는 이 루프를 이렇게 설명한다:

1. 앱이 사용자 메시지와 도구 목록을 보낸다.
2. 모델이 stop_reason: "tool_use"와 tool_use 블록으로 답한다: 어떤 도구를, 어떤 인자로 쓸지.
3. 앱이 도구를 실행하고 두 번째 요청을 보낸다. 여기에는 이전 메시지들, 모델의 도구 호출, tool_result 블록, 그리고 같은 도구 목록이 들어간다.
4. 모델이 답하거나 또 다른 도구를 요청하고, 루프가 다시 돈다.

같은 문서에 따르면 도구 사용 요청은 tools 파라미터를 포함해 보낸 총 입력과 출력에 대해 과금된다. 따라서 3단계는 결코 "새로 추가된 부분만"이 아니다: 전체 대화가 다시 들어간다.

Request 1  tools + system + task
Request 2  tools + system + task + call 1 + result 1
Request 3  tools + system + task + call 1 + result 1 + call 2 + result 2
...

긴 채팅이 더 비싼 이유와 같은 메커니즘인데, 속도만 더 빠르다. 채팅은 입력할 때 메시지 하나씩 늘어난다. 에이전트는 매 단계마다 두 블록씩 늘어나고, 아무도 아무것도 입력하지 않는다.

매 단계마다 따라붙는 세 가지#

도구 목록. 모든 도구의 이름, 설명, 파라미터 스키마가 매 요청에 들어간다. 이번 턴에 모델이 하나도 쓰지 않더라도 마찬가지다. 문서에 작은 추가 사항이 있다: 도구를 켜면 API가 자체 도구 사용 프롬프트를 더하는데, Claude Sonnet 5.5, Opus 5.5, Haiku 5.5에서는 286 토큰이고 다른 모델은 수치가 다르다.

히스토리. 당신의 작업, 모델의 이전 도구 호출, 모델의 메모.

도구 출력. 이게 교활한 녀석이다. 에이전트가 읽은 파일, 검색 결과 한 페이지, 테스트 로그: 일단 히스토리에 들어가면 이후 모든 단계에서 다시 값을 치른다.

토큰은 짧은 단어 하나나 그 일부에 해당하는 작은 텍스트 조각인데, 이 세 가지가 모두 토큰으로 계산된다.

20단계 실행, 계산해 보기#

세 가지 도구(파일 읽기, 검색, 테스트 실행)를 가진 작은 코딩 에이전트를 돌리고, 20단계가 걸리는 작업을 준다고 하자. 다음과 같이 가정한다:

• 도구 정의: 1,500 토큰, 시스템 프롬프트: 500, 당신의 작업: 200, 따라서 모든 요청은 2,200 토큰에서 시작한다;
• 매 단계마다 모델이 150 토큰짜리 도구 호출을 쓰고, 도구가 800 토큰을 반환한다;
• 둘 다 히스토리에 합류하므로, 매 단계마다 다음 요청에 950 토큰이 더해진다.

실행 총계를 구하려면 20개 요청을 모두 더한다. 2,200의 기본값은 20번 보내지고, 회차는 이후 단계로 이월된다: 1단계는 0회, 2단계는 1회, 이런 식으로 19단계까지 가면 총 190회다.

20 × 2,200 = 44,000

950 × 190 = 180,500

44,000 + 180,500 = 224,500 입력 토큰, 그리고 20 × 150 = 3,000 출력 토큰.

에이전트는 3,000 토큰을 쓰고 224,500 토큰을 읽었다. 출력 토큰은 입력 토큰보다 개당 비싸지만(입력 vs 출력 토큰 참고), 개수가 너무 적어서 청구서는 여전히 입력 쪽이 결정한다. 현재 가격으로 이 실행을 계산하면 다음과 같다:

DeepSeek-V4-Flash에서는 이런 실행 하나가 $0.0037이고, GLM-5.3-Flash에서는 $0.0046이다. 100번 실행하면 22,450,000 입력과 300,000 출력 토큰이다: DeepSeek-V4-Flash에서 $0.367. 위 표는 입력과 출력을 합쳐 계산했고, 총합으로 보면 그 모델들이 OpenRouter보다 저렴하다.

단계 수는 보이는 것보다 더 중요하다. 같은 가정으로 5단계 실행을 하면:

5 × 2,200 = 11,000

950 × 10 = 9,500

11,000 + 9,500 = 20,500 입력 토큰. 단계가 네 배가 되자 입력은 약 열한 배가 되었다. 새 단계마다 이전 단계를 모두 다시 읽기 때문이다.

줄일 곳: 네 가지 습관#

도구 결과 하나가 가장 쉬운 절약 지점이다. 3단계에서 테스트 실행이 4,000 토큰짜리 로그를 반환한다고 하자. 그러면 이후 17개 요청이 그 로그를 다시 보낸다:

• 전: 4,000 × 17 = 그 로그 하나가 끌고 가는 입력 토큰 68,000개;
• 후, 도구가 관련된 40줄만(약 400 토큰) 반환한다면: 400 × 17 = 6,800.

같은 작업, 같은 답, 그 결과 하나에서 나오는 입력이 10분의 1이다. 여기서 네 가지 습관이 나온다:

• 도구에서 덜 반환하라. 로그 전체가 아니라 오류 주변 줄만; 파일 전체가 아니라 함수만. 더 긴 설명은 도구 출력을 컨텍스트 밖으로 빼기에 있다.
• 에이전트에 도구를 더 적게 줘라. 모든 정의가 매 요청에 따라붙는다.
• 단계 수를 제한하라 그리고 예전 히스토리가 더 이상 중요하지 않으면 새 작업을 시작하라.
• 매 단계의 사용량을 합산하라, 그리고 미리 정한 예산에서 실행을 멈춰라. 추정 쪽은 AI 에이전트 비용을 추정하는 방법을 참고하라.

직접 실행한 것을 세어 보라#

모든 응답은 usage 필드에 입력으로 받은 토큰 수와 출력한 토큰 수를 보고한다. 모든 단계에 걸쳐 합산하면 내 가정 대신 당신 에이전트의 실제 수치를 얻는다. CheapTokens를 가리키는 OpenAI Python SDK로 작성한 스케치(messages와 tools은 당신 에이전트의 것):

from openai import OpenAI

client = OpenAI(base_url="https://api.cheaptokens.dev/v1", api_key="YOUR_API_KEY")

total_in = total_out = 0
for step in range(20):  # your agent loop
    resp = client.chat.completions.create(
        model="deepseek-ai/DeepSeek-V4-Flash-0731",
        messages=messages,
        tools=tools,
    )
    total_in += resp.usage.prompt_tokens
    total_out += resp.usage.completion_tokens
    # ...run the tool, append the result to messages

print(total_in, total_out)

두 총계는 위의 비용 표에 바로 대입된다. 이렇게 긴 히스토리의 경우 DeepSeek-V4-Flash는 380K 컨텍스트 윈도우와 답변당 최대 32,768 출력 토큰을 시간에 관계없이 단일 가격으로 제공한다; GLM-5.3-Flash는 390K 컨텍스트와 최대 8,192 출력 토큰을 갖는다. 설정은 문서에 있고, 모든 모델의 현재 가격은 가격 페이지에 있으며, 해당 모델에는 자체 페이지 저렴한 DeepSeek이 있다.