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.
비슷한 글
에이전트 시대의 Eclipse 플러그인 — 작업 컨텍스트는 20년 전에도 문제였다
Mylyn 이 2000년대에 풀려던 문제와 지금 에이전트 컨텍스트 문제는 같습니다. 달라진 건 그 컨텍스트를 읽는 쪽에 사람만 있는 게 아니라는 점입니다.
김영상
에이전트 시대의 VS Code 확장 — 개발자는 에디터에서 무엇을 보는가
코드 작성 비용이 무너진 뒤 개발자의 시간은 판단과 승인으로 옮겨갔습니다. 그 일들이 왜 에디터 밖에 있으면 안 되는지, VS Code 확장을 만들며 내린 선택들.
이승백
이클립스는 그대로 쓰셔도 됩니다 — IDE 연동과 ITSM 연동에 대한 답
개발툴로 이클립스를 쓰는데 어떻게 연동되냐는 질문과, ITSM 과 연동되냐는 질문은 거의 항상 같이 나온다. 표준 Git 프로토콜이라는 답의 의미, 그리고 ITSM 연동 요구의 진짜 본질이 증적 체인이라는 이야기.
백재민