모델을 바꾸기 전에 토큰이 어디서 새는지 보라

Diagnose Token Spend Before Optimizing the Model

핵심 주장: AI 비용 최적화는 프롬프트를 짧게 만드는 게 아니라, 컨텍스트·도구 출력·검색·재시도·에이전트 루프·산출물 전체에서 성공 1건당 비용을 측정하는 운영 문제다.

왜 "짧은 프롬프트"는 틀린 출발점인가

많은 팀이 비용이 오르면 프롬프트부터 줄인다. 하지만 실제 소비의 대부분은 프롬프트 본문이 아니라 매 턴 자동으로 실려 들어가는 것들에서 나온다. 누적 대화, 도구가 뱉는 긴 출력, 검색 결과, 실패한 재시도. 프롬프트를 반으로 줄여도 이것들이 그대로면 청구서는 거의 그대로다.

토큰 소비원 7개

1. 누적 대화 컨텍스트 — 길어질수록 매 턴 되실린다
2. 중복 지시 — 같은 규칙을 매번 반복
3. 불필요한 파일·로그 — 통째로 읽어 붙이는 습관
4. 과도한 웹 검색 결과 — 요약 없이 원문 투입
5. 에이전트 재시도·루프 — 실패 반복이 곱으로 든다
6. 모델별 입력·출력 — 큰 모델을 쉬운 일에 쓰기
7. 성공 못 한 작업에 쓴 비용 — 청구서엔 남지만 가치는 0

실제 진단 한 방 (현장 사례)

최근 세션에서 매 턴 비용이 이상하게 컸다. 프롬프트가 길어서가 아니었다. 진단해 보니 배경에서 도는 메모리 플러그인이 (1) 매 턴 도구 스키마 약 19개를 컨텍스트에 얹고, (2) 파일을 읽을 때마다 관측치를 수천 토큰씩 주입하고 있었다. 대화 내용과 무관한 상시 오버헤드였다.

조치는 프롬프트 수정이 아니라 소비원 제거였다. 그 플러그인을 끄자 다음 세션부터 상시 오버헤드가 사라졌다. 핵심은 "무엇을 짧게 쓸까"가 아니라 "무엇이 매 턴 새는가"를 먼저 본 것이다.

성공률이 높아도 비용은 나쁠 수 있다

지표는 성공률이 아니라 성공 1건당 비용이어야 한다. 재시도로 결국 성공해도, 그 성공 하나에 3번의 실패 비용이 붙었다면 단위 경제성은 나쁘다. eval gate는 "정답을 내는가"뿐 아니라 "얼마에 내는가"를 함께 봐야 한다.

모델 라우팅과 유지/폐기 판단

• 작은 모델 / 큰 모델 / 로컬 도구의 역할 분리 — 요약·분류·상태확인은 작은 모델이나 코드로, 설계·복잡 디버깅만 큰 모델로.
• 요약·메모리·검색 결과는 언제 유지하고 언제 버릴지 규칙화 — 다음 턴에 안 쓸 것은 컨텍스트에 남기지 않는다.
• 프롬프트 캐싱 등 제공사 기능으로 반복되는 고정 컨텍스트 비용을 낮춘다.

실패 가능성과 안전장치

• 토큰 줄이려다 품질 저하 → 절감 전후 동일 eval을 통과해야만 반영(품질 게이트).
• 진단 과정에서 비밀 노출 → 프로파일러는 원문·비밀값을 저장하지 않고 집계값만 남긴다.

내 경험과의 연결

품질 현장의 원가절감은 "재료를 아끼자"가 아니라 공정별 손실을 계측하는 데서 시작했다. 어디서 수율이 새는지 측정하지 않고 아끼면 엉뚱한 곳을 조인다. 토큰도 같다. 소비원별 계측이 먼저다.

다음에 만들 것 — One-shot Token Source Profiler

영어 면접 질문 3개

출처

• OpenAI — Prompt caching (docs)
• Anthropic — Prompt caching
• Anthropic — Building effective agents (에이전트 루프의 비용 관점)

관련 글: 코드보다 먼저 문제를 배포하라 · 지시는 채널로, 데이터는 기기에