AI 에이전트 비용 줄이기｜토큰 단가 말고 작업당 비용, 값싼 분류기 라우팅 실험 결과와 적용 순서

"API 단가는 매달 내려가는데 왜 에이전트 청구서는 늘어날까?" 코딩 에이전트를 운영하는 팀이라면 한 번쯤 해 본 질문입니다. 결론부터 말하면, 비용을 결정하는 것은 100만 토큰당 가격이 아니라 '성공한 작업 하나에 든 돈'이고, 구글 실험에서는 가벼운 모델에 낮은 thinking 을 먼저 쓰고, 값싼 분류기로 어려운 일만 위로 올리는 방식이 가장 효율적이었습니다.

✅ 이 글에서 얻을 수 있는 것
1. 작업당 비용을 재는 법과 출력 상한이 비용을 못 줄이는 이유
2. 정규식 라우터가 처음 보는 작업에서 무너진 사례
3. 우리 에이전트에 적용하는 3단계와 예시 코드

실험 개요

1. 출력 상한은 thinking 을 줄이지 않는다

가장 흔한 착각은 maxOutputTokens 를 작게 잡으면 쉬운 문제에서 덜 생각할 것이라는 기대입니다. 실험에서 Flash 를 상한 300 과 4096 으로 나눠 돌렸더니, 쉬운 27문항의 thinking 토큰은 거의 같았습니다. 쉬운 답은 애초에 상한 근처에도 가지 않기 때문입니다.

대신 어려운 25문항 중 7개가 깨졌습니다. 6개는 추론 도중 자리가 모자라 답을 내지 못했고, 1개는 추론을 억지로 줄이다 틀렸습니다. 출력 상한은 천장일 뿐 생각량 조절 손잡이가 아닙니다. 생각을 줄이려면 thinking 수준(예: thinkingLevel: "LOW")을 직접 낮춰야 합니다.

2. 정규식·길이 규칙 라우터가 무너진 이유

비용이 0인 규칙 라우터, 예를 들어 "sequence·modulo 같은 단어가 있거나 35단어가 넘으면 비싼 모델로"는 규칙을 만든 16문항에서 93.8%였습니다. 하지만 코드를 고치지 않고 처음 보는 34문항에 돌리자 70.6% 로 떨어졌습니다.

분류기도 처음에는 "simple 인가 complex 인가" 같은 넓은 질문 하나로 물었을 때 거의 전부를 simple 로 보냈습니다. "한 번에 찾아 끝나는가, 여러 단계 계산·추론이 필요한가" 한 가지만 묻는 예/아니오 질문으로 바꾸자 처음 보는 34문항을 모두 맞혔습니다.

📌 함께 보면 좋은 가이드: OpenAI Decisions API 사용법 — 분류·라우팅 전용 API 로 같은 구조를 만드는 법입니다.

3. 결과: 누가 가장 싸고 빨랐나

• 라우터 없는 최강 설정: Gemini 3.8 Flash low thinking 이 50문항을 모두 풀었습니다. 라우터가 넘어야 할 기준선입니다.
• 분류기 라우터: 모든 과제를 Flash-Lite 로 먼저 보내고, 분류기가 어렵다고 본 것만 Flash low 로 올렸습니다. 역시 50문항을 모두 풀었고, 비용과 응답 시간을 함께 줄였습니다. 과제가 짧아 과제당 비용 차이는 작았고, 대화형 에이전트에서는 기다리는 시간이 줄어드는 효과가 더 컸습니다.
• Flash-Lite 단독: 쉬운 문제는 0.5초 만에 풀었지만 어려운 25문항 중 6개를 놓쳤고, 분류기가 이 6개를 모두 잡아 위로 올렸습니다.
• 규칙 라우터: 더 쌌지만 어려운 5문항을 Flash-Lite 로 잘못 보내 2개를 틀려 48/50 이었습니다.
• 더 무거운 설정으로 올리기: 기본 thinking 으로 올리는 것은 low 를 전부에 쓰는 것보다 비쌌습니다. low 가 실패하기 시작할 때만 의미가 있습니다.

4. 단가표에 안 보이는 두 가지

적용 3단계

1. 라우터보다 thinking 설정이 먼저: 지금 쓰는 모델의 thinking 수준을 낮춰 정답률이 유지되는지부터 봅니다.
2. 짧은 단독 작업만 라우팅: 로그 파싱, 스키마 검사처럼 맥락이 짧은 일만 분류기로 나누고, 질문은 요인 하나당 예/아니오 하나로 쪼갭니다.
3. 실제 지출 측정: 에이전트 트레이스와 thinking 토큰 수를 로그 저장소에 모아, 어떤 작업이 돈을 쓰는지와 잘림·재시도를 확인합니다.

아래는 구조를 보여 주기 위한 예시 코드입니다. 분류기 호출 부분은 쓰는 서비스(자체 호스팅 모델 포함)에 맞게 바꿔야 합니다.

# 예시: 단계가 여러 개 필요한 작업만 위 모델로 올리는 라우터
def needs_multi_step(task_text: str) -> float:
    """분류기에 예/아니오 질문 하나만 묻고 0~1 확률을 받는다 (서비스별로 구현)."""
    question = ("이 작업은 한 번 찾아보거나 형식만 확인하면 끝나는가, "
                "아니면 여러 단계의 계산·시뮬레이션·추론이 필요한가?")
    return classifier.probability(state=task_text, statement=question)

def route(task_text: str) -> dict:
    if needs_multi_step(task_text) >= 0.5:
        return {"model": "flash", "thinking_level": "LOW"}
    return {"model": "flash-lite"}

기준값 0.5 는 임의로 둔 값입니다. 자기 작업 몇십 개에 사람이 난이도를 표시해 두고, 정답률과 비용을 보며 조정하세요.

맺음말

1. 에이전트 비용은 성공한 작업당 비용으로 봐야 하며, 출력 상한은 thinking 을 줄이지 못합니다.
2. 규칙 라우터는 처음 보는 작업에서 70.6% 로 떨어졌고, 질문을 하나씩 쪼갠 분류기는 34/34 를 맞혔습니다.
3. 순서는 낮은 thinking → 짧은 작업만 라우팅 → 지출 측정입니다.

공식 자료

• Cost per task: Using cheap classifiers to route across Gemini models and thinking levels (Google Developers Blog, 2026-11-03)

👉 다음에 읽을 글
- GPT-6.1 Terra 출시와 API 가격 — 같은 작업을 더 싼 모델로 돌릴 때 비교할 가격표입니다.
- 클로드 코드 사용량과 비용 관리 — 클로드 코드에서 한도와 API 비용을 줄이는 습관입니다.