LLM 비용을 통제하는 6가지 패턴 — 월 $4,200 → $890 의 분해
처음에 *LLM 호출 비용은 작다* 라고 가정했고, 6개월 후 청구서가 *$4,200* 였다. 6가지 패턴으로 *$890* 으로 줄인 6주.
LLM 도입 첫 달 청구서 — $420. 작네. 가속한 6개월 후 청구서 — $4,200. 같은 사용자 수, 같은 quality. 비용만 10배.
6주의 비용 통제 작업 후 청구서가 $890 으로. 같은 사용자, 같은 quality. 이 글은 그 6주의 6 패턴 분해.
패턴 1 — 모델 ladder
처음 우리는 모든 호출에 가장 강한 모델 (GPT-5 / Claude Opus 급) 사용. 사실 호출의 60% 가 간단한 분류 — Haiku / Mini 로 충분.
해결: 호출 종류별 모델 매핑.
호출 종류 | 모델
──────────────────────────┼──────────────
간단한 분류 / 라벨링 | Haiku / Mini
중간 복잡도 추론 | Sonnet / GPT-4 mid
복잡한 결정 / 코드 생성 | Opus / GPT-5이 한 변경으로 비용 -45%.
패턴 2 — 프롬프트 캐싱
같은 system prompt 가 모든 호출에 반복. Anthropic / OpenAI 의 prompt caching 활성화.
장기 system prompt (수천 토큰) + 짧은 user input 의 패턴이 우리 사용 80%. 이걸 캐싱하면 반복 부분의 비용 90% 할인.
비용 -25%. 작업 2일.
패턴 3 — 컨텍스트 윈도우 트리밍
긴 대화 history 를 모두 다음 턴에 보내고 있었음. 사실 직전 5턴 + episodic memory 검색 결과 만으로 충분. 긴 history 는 정확도도 떨어뜨림 (lost-in-the-middle).
비용 -15%. 정확도 +5% (예상치 못한 효과).
패턴 4 — 결정 단계 캐싱
같은 입력에 반복적 호출 패턴 발견. 사용자가 같은 액션 을 연속 으로 시도하면 같은 LLM 호출이 수십 번.
해결: 결정 결과 를 입력 hash + 짧은 TTL 로 캐싱. 5분 안에 같은 입력 = cache hit.
비용 -12%. 작업 3일.
패턴 5 — Streaming 의 token 절약 효과
streaming response 사용 시, 사용자가 중도 cancel 하면 남은 토큰은 청구 안 됨. 우리 사용 패턴에서 15% 의 사용자가 답변 일부만 보고 cancel.
해결: 모든 long-form 응답을 streaming 으로 전환. 사용자가 cancel 하면 서버에서 abort signal 로 token 생성 중단.
비용 -7%. 작업 1주.
패턴 6 — 결정론적 fallback
확신도 높은 단순 결정 은 LLM 호출 없이 결정론적 규칙으로. LLM 은 불확실한 결정 에만.
예 — 요청이 명백히 known intent (예: "list my deploys") 면 LLM 호출 X. 직접 API call.
비용 -5%. 작업 4일. 그러나 latency 도 70% 개선 — 추가 효과.
6 패턴 누적
시작: $4,200 / 월
패턴 1 (모델 ladder): $2,310 (-45%)
패턴 2 (프롬프트 캐시): $1,733 (-25%)
패턴 3 (컨텍스트 트림): $1,473 (-15%)
패턴 4 (결정 캐싱): $1,296 (-12%)
패턴 5 (streaming): $1,205 (-7%)
패턴 6 (결정론 fallback): $1,145 (-5%)
─────────────────────────
실제 누적: $890 (총 -79%)수치는 곱셈 이 아니라 순차 적용 이라 간섭 이 있음. 패턴 1 후 패턴 2 가 영향 받는 비율이 다름. 누적 결과 $890.
원칙 한 줄
위 6 패턴의 공통 원칙:
모든 LLM 호출이 동일한 가치를 가지지 않는다. 가치 낮은 호출에 비용을 덜 쓰고, 가치 높은 호출에 비용을 정확히 쓴다.
처음에 모든 호출에 같은 비용 을 쓰고 있었던 게 4,200 의 원인. 가치별로 분배 한 게 890.
LLM 청구서가 빠르게 크는 팀에서 위 6 패턴 중 3개 이상 아직 안 했다면, 6주 작업으로 비용 70~80% 절감 가능. 적용 순서 가 중요 — 모델 ladder 가 항상 첫 번째, 가장 큰 lever.
비슷한 글
기획자가 코드를 배포하면, 장애는 누가 책임질까
AI로 제품 담당자가 직접 코드를 만들고 여러 에이전트가 동시에 작업하는 조직에서, 운영에 나가는 변경을 누가 무엇으로 확인해야 하는지. NIST SSDF, SLSA provenance, Google SRE 포스트모템 문화를 근거로 작성자와 분리된 검증·승인·복구의 역할 설계를 정리했다.
백재민
에이전트 시대의 Eclipse 플러그인 — 작업 컨텍스트는 20년 전에도 문제였다
Mylyn 이 2000년대에 풀려던 문제와 지금 에이전트 컨텍스트 문제는 같습니다. 달라진 건 그 컨텍스트를 읽는 쪽에 사람만 있는 게 아니라는 점입니다.
김영상
에이전트 시대의 VS Code 확장 — 개발자는 에디터에서 무엇을 보는가
코드 작성 비용이 무너진 뒤 개발자의 시간은 판단과 승인으로 옮겨갔습니다. 그 일들이 왜 에디터 밖에 있으면 안 되는지, VS Code 확장을 만들며 내린 선택들.
이승백