Tokenminning (openai.chat.completions.create를 작성하는 사람들을 위한 가이드)

당신의 팀이 에이전트(agent)를 출시했습니다. 데모는 마법 같았습니다. 그러자 재무팀에서 왜 엔지니어 한 명의 코딩 어시스턴트가 기능 백로그(feature backlog)는 그대로인데 한 달 만에 4만 달러($40k)를 태웠는지 물어왔습니다.

tokenmaxxing 이후의 숙취에 오신 것을 환영합니다. 이는 토큰 지출을 출시된 결과물과 연결하지 않은 채, 종종 내부 리더보드에서 찬사를 받는 원시 LLM 사용량을 극대화하려는 습관을 의미합니다.

이에 대한 대응책에는 이름이 있습니다: 바로 tokenminning입니다. 저널리스트들은 이를 token minimizing이라고 부릅니다. 엔지니어링 팀은 이를 계측(metering), 모델 라우팅 (model routing), 컨텍스트 위생 (context hygiene), 엄격한 예산 (hard budgets), 그리고 CI 강제 적용 (CI enforcement)으로 공식화할 때 tokenminning이라고 부릅니다.

이것은 개발자를 위한 요약본입니다. 철학은 Manifesto에 담겨 있습니다. 법은 Constitution에 담겨 있습니다. 이 포스트는 당신이 금요일 전까지 출시해야 할 내용입니다.

요약 (TL;DR)

• **토큰 (token)**은 과금 단위(~단어 파편)입니다. 제공업체는 **입력 (input)**과 **출력 (output)**을 별도로 청구합니다.
• **에이전트 루프 (agent loops)**에서는 입력이 대개 지배적입니다. 전체 히스토리와 도구 덤프(tool dumps)가 매 턴마다 다시 전송되기 때문입니다.
• Tokenminning = 동일한 출력 품질을 유지하면서, 실행 가능한 최소한의 토큰 지출을 달성하는 것.
• 순서가 중요합니다: 계측 (meter) → 프롬프트 위생 (prompt hygiene) → 모델 라우팅 (model routing) → 캐싱 (caching) → 컨텍스트 위생 (context hygiene) → 상한선 (caps).
• 소프트한 가이드는 소프트한 예산을 만듭니다. 하드한 천장(Hard ceilings)은 코드에 있어야 합니다.

Tokenmaxxing vs tokenminning (openai.chat.completions.create를 작성하는 사람들을 위한 가이드)

	Tokenmaxxing	Tokenminning
목표	토큰 볼륨 극대화	토큰당 가치 극대화
...

Meta, Uber, Walmart, 그리고 Amazon은 모두 2026년에 방향을 전환했습니다 — 상한선(caps), 제한(limits), 리더보드 제거 등입니다. Uber는 예상했던 연간 AI 예산을 4개월 만에 다 써버렸습니다. NYT는 이 변화를 기록했습니다. 당신의 인보이스(invoice)는 개인의 실패가 아닙니다. 그것은 누락된 제약 계층(constraint layer)의 문제입니다.

당신의 청구서가 폭발한 이유 (프로덕션에서의 한 가지 버그가 아닌 세 가지 버그)

1. 하드코딩된 프런티어 모델 (Hardcoded frontier models)

// tokenmaxxing
const response = await openai.chat.completions.create({
  model: 'gpt-4', // 작업 종류와 상관없이 모든 요청에 사용
...

분류 (Classification), 추출 (Extraction), 그리고 JSON 변환 (JSON transforms) 작업에는 최첨단 모델 (Frontier models) 계층이 필요한 경우가 거의 없습니다. 팀들은 실제 트래픽을 기준으로 벤치마크를 수행한 후, 모델 라우팅 (Model routing)만으로도 60–90%의 비용 절감을 보고하고 있습니다.

// tokenminning
const response = await router.complete({
  capability: 'classify-intent',
...

2. 제한 없는 컨텍스트를 사용하는 에이전트 루프 (Agent loops with unbounded context)

채팅 한 턴 (Chat turn)에 수백 개의 토큰이 소모될 수 있습니다. 전체 도구 페이로드 (Tool payloads)를 유지하고, 상태를 전혀 요약하지 않으며, 매 단계마다 모든 것을 다시 전송하는 에이전트는 세션당 수만 개의 토큰 비용이 발생할 수 있습니다. 토큰당 가격은 일정해 보이지만, **컨텍스트 인플레이션 (Context inflation)**으로 인해 요청당 총 토큰 수가 10배로 증가합니다. 컨텍스트 인플레이션이란 무엇인가를 참조하세요.

3. Google Docs처럼 취급되는 프롬프트 (Prompts treated as Google Docs)

시스템 프롬프트 (System prompt)에 포함된 모든 토큰은 모든 요청에 대해 비용이 청구됩니다. 200토큰 정도 늘어나는 프롬프트는 공짜처럼 들릴 수 있습니다. 하지만 월 1,000만 건의 요청이 발생한다면, 이는 무시할 수 없는 비용 항목이 됩니다.

# 스캐폴딩 낭비 (scaffolding waste) (삭제하세요)
"You are a helpful assistant."
"Take a deep breath and think step by step."
...

산문 형태의 포맷팅 규칙을 스키마 강제 (Schema enforcement)로 교체하세요:

{
  "response_format": {
    "type": "json_schema",
...

스키마 출력은 CI에서 검증이 가능하지만, 느낌 (Vibes)은 불가능합니다. 전체 가이드: 프롬프트 위생 (Prompt hygiene).

최적화 순서 (단계를 건너뛰지 마세요)

tokenminning.ai의 어디서부터 시작해야 할까 (Where to start)에서 발췌:

단계	기술	일반적인 영향
0	미터링 (Metering) + 귀속 (Attribution)	전제 조건
...

안티 패턴 (Anti-pattern): 미터링을 하기 전에 프롬프트를 최적화하는 것. 비용 절감을 증명하거나 실제 병목 현상 (Bottleneck)을 찾을 수 없습니다.

안티 패턴 (Anti-pattern): 입력 비용이 지출의 80%를 차지할 때 출력의 max_tokens를 줄이는 것.

이번 주에 시작하기: 실제로 성과를 내는 5가지 PR

PR 1 — 입력 및 출력 토큰을 별도로 기록하기

무엇인가를 변경하기 전에, 다음 질문에 답해 보세요: "이 사용자 작업이 완료되었을 때, USD 기준으로 비용이 얼마였는가?"

최소 기능 구현 수준의 계측 (Minimum viable instrumentation):

const result = await model.complete({ messages, max_tokens: 1024 });

await ledger.record({
...

프롬프트를 최적화하기 전에 Article I: 불변의 계량화 (immutable metering)를 구현하세요.

PR 2 — 스캐폴딩 (scaffolding)을 위한 상위 10개 템플릿 감사

사용량이 가장 많거나 비용이 가장 많이 발생하는 프롬프트를 추출하세요. 신호가 없는 (signal-free) 토큰을 제거하세요. 전후 토큰 수 차이 (Diff)를 확인하세요. 비대해진 템플릿에서 20–25% 절감을 목표로 합니다.

PR 3 — 모든 제한된 작업에 max_tokens 추가

답변의 형태가 정해져 있다면, API 호출 시 제한을 두세요:

await model.complete({
  messages,
  max_tokens: 256, // 불리언 분류 (boolean classification)를 위해 문단 형태의 에세이가 필요하지 않음
...

PR 4 — 캐싱 (caching)을 위한 안정적인 접두사 (Stable prefix)

정적인 시스템 프롬프트 (system prompts)와 도구 정의 (tool definitions)를 가장 먼저 배치하세요. 동적인 사용자 콘텐츠는 그 뒤에 배치합니다.

const messages = [
  { role: 'system', content: STABLE_SYSTEM_PROMPT }, // 캐싱 가능한 접두사 (cacheable prefix)
  { role: 'user', content: dynamicUserInput },
...

제공자(provider)의 접두사 캐싱 (prefix caching)을 활성화하세요. 가이드: 프롬프트 캐싱 (prompt caching).

PR 5 — 우아한 성능 저하 (graceful degradation)를 동반한 세션 예산 설정

엄격한 상한선 (Hard ceilings)은 권장 사항이 아니라 아키텍처입니다. Article IV에서 발췌:

const session = createSession({
  userId: 'usr_123',
  feature: 'document-analysis',
...

예산이 없으면 세션도 없습니다. 운영 환경 (prod)에서 "내부 테스트"라는 예외는 허용되지 않습니다.

모델 라우팅 (Model routing): 상위 모델로 기본 설정하지 말고 단계별로 적용(cascade)하세요

요청 (Request) → 소형 모델 (small model)
            ↓ 품질 검사 통과 → 반환
            ↓ 실패 → 중간 단계 모델 (mid-tier model)
...

모든 프론티어 (frontier) 모델 호출에는 감사 가능한 (auditable) 이유가 필요합니다:

• 임계값 이상의 복잡도 분류기 (Complexity classifier) 점수
• 저렴한 모델의 품질 검사 실패 (로그 기록됨)
• 사용자가 명시적으로 비용이 발생하는 "고품질 (high quality)" 티어를 선택함

허용되지 않는 사유: 개발자의 선호도, "프롬프트가 길어서", 라우팅 계층(routing layer)이 아예 없음.

당신의 데이터로 벤치마크 수행 — 1,000개의 실제 입력값, 병렬 실행, 품질 × 비용 × 지연 시간 (latency) 비교. 블로그 포스트의 절감액이 당신의 절감액은 아닙니다.

Tokenminning이 아닌 것

• 토큰 수를 줄이기 위해 필수 지침을 제거하는 것 (노이즈 제거 (noise removal) ≠ 신호 제거 (signal removal))
• 벤치마크 없이 모든 것에 가장 작은 모델을 사용하는 것
• 12개의 토큰을 아끼려다 엣지 케이스 (edge cases)를 망가뜨리는 취약한 미세 수정 (micro-edits)
• 인프라 구축 없이 엔지니어에게 "더 짧은 프롬프트를 작성하라"고 요구하는 것

Tokenminning은 토큰 팽창 (token bloat)이 물리적으로 배포될 수 없는 시스템을 구축하고, 모든 추론 (inference) 호출이 원장 (ledger)에 기록되도록 하는 것입니다.

현재 당신의 스택에서 가장 비용이 많이 드는 추론 호출 패턴은 무엇입니까 — 그리고 세션당 실제 USD 비용을 실제로 알고 있습니까?