Tokenmaxxing은 2026년의 안티 패턴입니다: 팀의 토큰 비용이 10배 급증한 이유와 우선적으로 줄여야 할 것들

현재 엔지니어링 트위터(Engineering Twitter) 사이에서 아무도 자신에게 해당된다는 사실을 인정하고 싶어 하지 않는 단어가 떠돌고 있습니다. 바로 tokenmaxxing입니다. Tom's Hardware는 2026년 5월 23일 기사를 통해, 에이전트형 AI (Agentic AI) 스택이 "표준 AI 호출보다 최대 1000배 더 많은 토큰"을 소비하기 시작한 이후 Microsoft, Meta, Amazon이 기업 차원에서 비용을 줄이고 있다고 지적했습니다. OpenClaw의 제작자인 Peter Steinberger는 충격적인 수치를 공개했습니다. 그의 팀은 단 한 달 만에 토큰 비용으로 130만 달러를 소모했습니다.

만약 당신이 프로덕션 환경에서 에이전트를 운영하는 소규모 팀이고, 이번 분기에 청구서가 3~10배 급증했다면, 그것은 착각이 아니며 아마도 가격 인상의 피해자도 아닐 것입니다. 토큰당 가격은 지난 2년 동안 _하락_해 왔습니다. 비용이 증가하는 이유는 작업당 토큰 수가 토큰당 절감액보다 더 빠르게 증가하고 있기 때문입니다. 이것이 바로 tokenmaxxing 패턴입니다. "나중에 최적화하면 돼"라는 명목하에 더 많은 모델, 더 많은 재시도 (Retries), 더 많은 "생각 (Thinking)" 단계, 더 많은 도구 호출 (Tool calls), 그리고 모든 프롬프트에 더 많은 컨텍스트 (Context)를 채워 넣는 것입니다.

이 글은 2026년 스택에서 tokenmaxxing이 나타나는 네 가지 형태에 대한 현장 가이드이며, 어떤 형태가 가장 많은 비용을 발생시키고 있는지 자신의 로그를 통해 10분 만에 감사(Audit)할 수 있는 방법을 제시합니다.

내가 계속 목격하고 있는 네 가지 형태

나는 지난 90일 동안 소규모 AI 운영사들의 LLM 청구서 19건을 감사했습니다. 그중 17건에서 지출의 최소 60%가 아래 네 가지 형태 중 하나에 집중되어 있었습니다. 이 중 어느 것도 모델의 문제는 아니었습니다. 모두 아키텍처 (Architecture)의 문제입니다.

형태 1: 조용한 재시도 폭풍 (The silent retry storm)

부수 효과를 일으키는 도구 호출 (이메일, 결제, 캘린더, 데이터베이스 쓰기 등)이 200 OK를 반환합니다. 에이전트에게 결과 확인 계층 (Outcome-assertion layer)이 없기 때문에, 에이전트는 부수 효과가 실제로 발생했는지 알지 못합니다. 오케스트레이터 (Orchestrator)는 "도구가 반환됨"을 확인하고 다음 단계로 넘어갑니다. 고객은 아무 일도 일어나지 않았다고 보고합니다. 고객 지원 팀은 이를 에스컬레이션(Escalate)합니다. 엔지니어링 팀은 트레이스 (Trace)를 확인하고 에러가 없는 것을 본 뒤, "만약을 대비해" 재시도를 추가합니다. 이제 단 한 번의 사용자 요청에 대해 동일한 호출이 3~4번 실행됩니다.

한 감사(audit) 사례에서, 3명으로 구성된 팀이 고객 지원 에이전트(customer support agent)를 위해 매달 11,400달러를 지출하고 있었습니다. 그중 4,800달러는 에이전트가 "안전하게" 하기 위해 티켓당 4번씩 실행했던 Salesforce 업데이트에 대한 단일 재시도 루프(retry loop) 때문이었습니다. 단 두 줄의 결과 단언(outcome assertion) 코드가 이를 잡아냈습니다.

빠른 신호(Quick signal): 사용자 요청당 grep -c "200 OK" your-trace.log를 실행한 뒤, 이를 고유한 사용자 요청 수로 나눕니다. 만약 부수 효과(side-effecting)가 있는 도구에 대해 평균값이 1.3을 초과한다면, 재시도 폭풍(retry storm)이 발생하고 있는 것입니다.

형태 2: "사고(thinking)"의 함정

추론 모델(Reasoning models)은 1년 전과 비교하면 저렴해졌지만, 이를 사용하는 에이전트 청구서에서는 여전히 가장 비중이 큰 항목입니다. 함정은 추론 모델을 사용한다는 사실 그 자체가 아닙니다. 추론 모델이 필요하지 않은 작업에 추론 모델을 사용하고 있다는 점이 함정입니다. 분류(Classification), 포맷팅(formatting), 추출(extraction), 짧은 요약(short summarization) 등은 대부분의 프레임워크에서 기본적으로 전체 추론 과정을 거치게 됩니다.

한 감사 사례에서, 3명 규모의 팀은 이메일 분류(email triage, "이것이 고객 에스컬레이션인가? 예/아니오"라는 이진 작업)에 o3를 사용하고 있었습니다. 그들 청구서의 78%는 모델이 200개의 토큰을 사용해 생각하든 20,000개의 토큰을 사용하든 정답이 바뀌지 않는 작업에 사용된 추론 토큰(reasoning tokens)이었습니다. 그들은 이를 월 9달러의 4B 로컬 모델(local model)로 옮겼고, o3는 아주 예외적인 케이스(long-tail cases)에만 남겨두었습니다.

빠른 신호(Quick signal): 트레이스(traces)를 output_tokens / input_tokens 비율로 정렬하십시오. 추론 비중이 높은 작업은 이 비율이 5:1을 넘습니다. 만약 사고 사슬(chain of thought)이 필요하지 않은 작업의 비율이 50:1로 나타난다면, 당신은 결코 읽지 않을 토큰에 비용을 지불하고 있는 것입니다.

형태 3: 컨텍스트 채워넣기 (Context stuffing)

당신의 에이전트는 검색(retrieval)을 수행합니다. 검색기(retriever)가 12개의 청크(chunks)를 반환합니다. 에이전트는 "모델에게 컨텍스트를 제공하기 위해" 12개 모두를 프롬프트에 채워 넣습니다. 그 청크들 중 대부분은 무관한 내용입니다. 하지만 모델은 어쨌든 그것들을 읽습니다. 비용은 청크 수에 따라 선형적으로(linearly), 청크 크기에 따라 이차적으로(quadratically) 증가합니다.

한 감사 사례에서, 월 300달러였던 청구서는 팀이 주입(injection) 전 재정렬(re-rank) 단계를 거치는 3개 청크 제한 방식으로 전환했을 때 월 90달러로 줄어들었습니다. 정확도는 떨어지지 않았습니다. 모델은 어차피 무관한 청크들을 무시하고 있었기 때문입니다.

빠른 신호 (Quick signal): 검색 증강 (Retrieval-augmented) 프롬프트를 살펴보세요. 청크 (Chunks)의 개수를 세어보십시오. 만약 지속적으로 5개 이상의 청크를 입력하고 있다면, 이는 컨텍스트 크기 (Context-size)의 문제가 아니라 관련성 (Relevance)의 문제입니다. (그리고 컨텍스트 윈도우 (Context window)는 비용의 상한선이지, 품질의 목표가 아닙니다.)

형태 4: 에이전트들의 에이전트 (The agent-of-agents)

팀원 중 누군가가 LangGraph에 대해 읽고 흥분하여, 원래는 단일 선형 프롬프트 (Single linear prompt)로 해결 가능했던 문제에 대해 4-에이전트 감독 패턴 (4-agent supervisor pattern)을 구축했습니다. 이제 사용자 요청당 1번이었던 모델 호출 (Model calls)이 4번으로 늘어났습니다. 각 호출은 입력 토큰 (Input tokens)을 추가하고 (감독 에이전트가 이전의 전체 트랜스크립트를 전달함), 출력 토큰 (Output tokens)을 추가합니다 (각 하위 에이전트가 자신의 작업 내용을 감독 에이전트에게 다시 설명함).

이 방식은 네 가지 형태 중 가장 비용이 많이 드는데, 그 이유는 되돌리기가 가장 어렵기 때문입니다. 팀이 의도적으로 아키텍처 (Architecture)를 구축했기 때문입니다. 에이전트를 추가하면 항상 호출 횟수가 늘어나므로 비용 증가가 "자연스럽게" 보입니다. 함정은 에이전트들이 병렬 작업 (Parallel work)을 하는 것이 아니라, 단일 체인 (Single chain)으로 처리할 수 있었던 직렬 작업 (Serial work)을 수행하고 있다는 점입니다.

빠른 신호 (Quick signal): 모든 멀티 에이전트 시스템 (Multi-agent system)에 대해, 사용자 작업당 총 토큰 수를 기록하십시오. 만약 작업당 비용이 단일 프롬프트 버전 비용의 3배를 초과한다면, 해당 멀티 에이전트 구조는 제값을 못 하고 있는 것입니다.

10분 감사 (The 10-minute audit)

가장 비용이 많이 드는 에이전트를 선택하십시오. 지난 7일간의 트레이스 (Traces)를 추출하십시오. 각 사용자 요청에 대해 다음 항목을 기록하십시오:

1. 총 입력 토큰 (Total input tokens)
2. 총 출력 토큰 (Total output tokens)
3. LLM 호출 횟수 (Number of LLM calls)
4. 도구 호출 횟수 (Number of tool calls) (특히 부수 효과 (Side-effecting)를 일으키는 것들)
5. 최종 결과가 검증되었는지 여부 (단순히 "도구가 200을 반환함"이 아닌지 확인)

로그에 이 다섯 가지 숫자가 없다면, 그것이 가장 먼저 해결해야 할 과제입니다. 하지만 대부분의 Langfuse/LangSmith/Helicone 설정은 기본 대시보드를 통해 이를 보여줍니다.

이제 사용자 요청을 총 비용(모델의 공시 요율로 계산된 입력 + 출력) 기준으로 정렬하십시오. 상위 10%가 전체 비용의 60~90%를 차지할 것입니다. 상위 3개를 골라 질문하십시오: 이들은 네 가지 형태 중 어디에 속하는가?

19건의 감사(Audit) 결과, 답변은 거의 항상 다음과 같았습니다: 트랜잭션 에이전트(Transactional agents)의 경우 형태 1(Silent retry storm, 조용한 재시도 폭풍), RAG 에이전트의 경우 형태 3(Context stuffing, 컨텍스트 채워넣기), 분류/트리아지(Triage/classification) 에이전트의 경우 형태 2(Thinking trap, 사고의 함정), 그리고 "감독자(Supervisor)"를 추가함으로써 확장된 모든 시스템의 경우 형태 4(Agent-of-agents, 에이전트의 에이전트)였습니다.

무엇을 가장 먼저 줄여야 하는가

다음 순서대로 줄이십시오. 비용 절감액은 이 순서대로 크지만, 구현 노력은 이와 반대 순서이기 때문입니다:

1. 부수 효과(Side-effecting)가 있는 모든 도구 호출(Tool call)에 결과 확인(Outcome-assertion) 라인을 추가하십시오. 형태 1을 방지합니다. 가장 많은 비용을 아껴줍니다. 코드 두 줄이면 충분하며, 절감 효과는 즉각적입니다.
2. 검색된 청크(Retrieval chunks)를 3~5개로 제한하고, 재순위화(Re-rank) 단계를 추가하십시오. 형태 3을 방지합니다. 두 번째로 많은 비용을 아껴줍니다. 한 시간 정도의 작업이 소요됩니다.
3. 추론이 필요한 작업은 추론 모델(Reasoning models)로 라우팅하고, 그 외의 모든 것은 소형 모델(Small models)로 라우팅하십시오. 형태 2를 방지합니다. 세 번째로 많은 비용을 아껴줍니다. 라우팅 설정에 오후 한나절 정도가 소요됩니다.
4. 다중 에이전트 직렬 체인(Multi-agent serial chains)을 단일 프롬프트(Single prompts)로 통합하십시오. 형태 4를 방지합니다. 변경 건당 절감액은 가장 적지만, 아키텍처가 의도적인 선택이었기 때문에 정치적 자본(Political capital)이 가장 많이 소모됩니다.

이것의 가치

만약 귀하의 팀이 프로덕션 환경에서 에이전트를 실행 중이고 이번 분기에 토큰 비용이 증가했다면, 위의 감사(Audit)는 10분짜리 작업입니다. 이를 실행에 옮기는 것은 12일 정도의 작업입니다. 절감액은 보통 청구 금액의 4070%에 달합니다.

사람이 직접 귀하의 트레이스(Traces)를 읽고, 네 가지 형태 중 무엇이 귀하를 가장 힘들게 하는지 식별하며, 귀하의 스택에 맞는 구체적인 코드 변경 사항이 담긴 한 페이지 분량의 처방전을 작성하기를 원하신다면 — 그것이 제가 제공하는 서비스입니다. 이는 귀하가 확인하는 것을 잊어버릴 대시보드가 아니라, 실제 로그를 작업 단위로 분석하는 포렌식(Forensic) 읽기입니다. 결과물은 단일 마크다운(Markdown) 파일로 제공됩니다: 형태 진단, 절감액 순으로 정렬된 3~5개의 구체적인 코드 변경 사항, 그리고 무엇이 효과가 있었는지 확인하기 위한 30일간의 사후 관리입니다.

단일 에이전트는 299달러, 최대 3개의 에이전트 군단(Fleet)은 499달러입니다. 결과물의 형태가 어떤 모습인지 확인하고 싶다면 프로필에 있는 링크를 참조하십시오.

이 글에 포함되지 않은 내용

저는 여러분에게 "프롬프트를 최적화하라"거나 "더 저렴한 모델을 사용하라"고 말하지 않을 것입니다. 두 가지 모두 당연한 이야기이며, 실제 문제를 해결해주지도 못합니다. 여러분의 청구서가 10배나 늘어난 이유는 토큰당 가격이 올랐기 때문이 아닙니다. 위에서 언급한 네 가지 형태 중 하나로 인해 작업당 토큰 수가 늘어났기 때문입니다. 해결책은 토큰 수준이 아니라 구조적인 차원에서 찾아야 합니다.

Tom's Hardware의 기사가 증상 보고서라면, 이 글은 진단서입니다. 돈을 아껴주는 것은 바로 이 진단입니다.