LLM을 POC로 띄울 때는 한 달 API 비용이 200달러 정도 나옵니다. 그런데 운영에 올린 다음 어느 날 갑자기 한 주 비용이 2만 달러로 튀는 경험은 LLM 운영자라면 거의 다 해봐요. 코드가 바뀌지 않았는데 비용이 튀는 거예요. 이 글은 운영 환경에서 LLM 비용이 폭주하는 6가지 전형적인 패턴과 그것을 사전에 막는 guardrail을 정리합니다. 마케팅 자동화 파이프라인을 LLM으로 운영하는 팀에게 특히 절실한 주제예요.
왜 LLM 비용은 갑자기 튀는가
전통 SaaS는 비용이 비교적 예측 가능합니다. 사용자가 두 배 늘면 서버 비용이 두 배 늘죠. LLM은 그렇지 않습니다.
- 같은 요청이라도 답변이 길어지면 토큰이 두 배
- retry 한 번이 비용 두 배, 두 번이 세 배
- 한 사용자의 context를 누적하면 매 요청마다 토큰이 선형 증가
- 모델을 한 단계 업그레이드하면 토큰당 단가가 5배
- "tool use" 한 사이클이 LLM 호출 3~5번
이 5가지가 동시에 발생하면 비용이 10배 폭주합니다. 사용자는 늘지 않았는데도요.
비용은 토큰·호출 수의 곱이다. 6가지 guardrail은 곱의 한 축이 갑자기 폭발하지 않게 잡아주는 안전핀이다.
비용 폭주의 6가지 전형 패턴
| # | 패턴 | 증상 | 1차 원인 |
|---|---|---|---|
| 1 | Retry storm | 일시적 5xx 후 비용 10배 | 백오프 없는 즉시 재시도 |
| 2 | Prompt drift | 같은 기능 비용이 한 달 새 두 배 | 시스템 프롬프트가 누적 추가 |
| 3 | Context 누적 | 사용자가 오래 쓸수록 매 호출 비용 증가 | 대화 history를 매번 다 보냄 |
| 4 | 모델 자동 승격 | 모델 alias가 새 버전으로 자동 갱신 | claude-3-5-sonnet-latest 같은 floating alias |
| 5 | Agent loop 폭주 | 한 요청이 LLM 호출 50번 | tool use loop의 종료 조건 미설계 |
| 6 | 캐시 무효화 | cache hit 99%였는데 갑자기 0% | 프롬프트 한 글자 바뀜 → 캐시 키 전체 무효 |
이 6가지를 사전에 막지 않으면 비용 폭주는 한 분기 안에 무조건 한 번 일어납니다.
Guardrail 1 — Retry는 exponential backoff + 최대 횟수
LLM API는 가끔 5xx를 줍니다. 자연스러운 일이에요. 그런데 retry를 즉시·무제한으로 돌리면 한 요청이 100번 재시도되어 비용이 100배가 됩니다.
표준 정책:
- 1차 retry는 1초 후
- 2차 retry는 2초 후
- 3차 retry는 4초 후
- 최대 3회까지만 재시도
- 그 이후는 실패로 처리하고 사용자에게 에러 표시
이 정책이 안 박혀있는 LLM 클라이언트는 운영에 올리면 안 됩니다. 공식 SDK(Anthropic, OpenAI, Google)는 기본 retry 정책이 들어가 있지만 직접 wrapping한 경우는 한 번 더 확인이 필요해요.
⚠️ 429 (rate limit) 응답에는 retry-after를 따른다
429 응답은 retry-after 헤더에 "몇 초 후 재시도"가 들어있습니다. 이걸 무시하고 즉시 재시도하면 영구 차단될 수 있어요. 표준 SDK는 자동으로 따르지만 직접 wrapping한 경우 빠뜨리는 일이 흔합니다.
Guardrail 2 — 프롬프트는 git으로 관리, 길이 모니터링
운영 중에 프롬프트가 슬금슬금 길어지는 일은 굉장히 흔합니다. "이 케이스도 처리해야 해요" 한 줄, "여기 예시도 넣어주세요" 한 단락. 6개월 지나면 시스템 프롬프트가 처음의 5배가 돼있고 매 요청 비용도 5배가 됐어요.
guardrail:
- 프롬프트는 코드처럼 git에 둠 (별도 prompt 파일 또는 yaml)
- PR마다 토큰 수 diff를 자동 코멘트
- 운영 메트릭에 "평균 input 토큰" 추적
- 시스템 프롬프트가 5000 토큰을 넘으면 알림
프롬프트 자체를 데이터로 보고 관리하는 거예요. 사람이 자유롭게 수정하게 두면 항상 길어집니다.
Guardrail 3 — Context window는 명시적 잘림 정책
대화 history를 매 요청에 다 보내면 사용자 한 명이 100턴 대화한 시점에 매 호출이 100배 비용이 됩니다. 그런데 잘 보면 그 100턴 중 사람이 실제로 기억해야 할 건 보통 마지막 3~5턴이에요.
guardrail:
- context 최대 토큰 한도를 설정 (예: 8000)
- 한도 넘으면 가장 오래된 메시지부터 잘림
- 잘리기 전에 summary 메시지로 압축
- "tool use" 결과는 더 짧은 요약으로 압축
이걸 "context compaction"이라고 부릅니다. Anthropic·OpenAI 모두 권장하는 표준 운영 패턴이에요.
💡 prompt caching이 있다면 잘림 위치를 신중히
Anthropic prompt caching은 cache breakpoint 이전이 동일해야 hit합니다. 그래서 잘림 위치가 매번 바뀌면 cache hit이 사라져요. 잘림 정책을 "토큰 한도 넘으면 N개씩 한 번에 잘림"으로 두면 cache key가 유지됩니다.
Guardrail 4 — 모델 버전은 pin, alias는 절대 운영에 금지
claude-3-5-sonnet-latest 같은 floating alias를 운영 코드에 박아두면 어느 날 자동으로 새 모델로 승격되어 단가가 변합니다. 더 무서운 건 새 모델이 답변 길이가 평균 30% 더 길게 나오는 경향이 있어 output 토큰까지 증가한다는 점이에요.
guardrail:
- 운영 코드에는 정확한 모델 ID를 박는다 (예:
claude-opus-4-7) - 새 모델로 옮길 때는 PR로, A/B 비교를 하고 옮긴다
- 모델 ID는 환경변수로 빼서 한 곳에서 관리
- 모델별 단가 변경은 알림 잡으로 감지
Guardrail 5 — Agent loop의 max iteration
ReAct, plan-and-execute 같은 agent 패턴은 LLM 호출을 여러 번 합니다. tool use 결과를 받고 다시 LLM에 묻고, 또 tool 부르고, 그렇게 5~10번이 한 사용자 요청.
종료 조건 설계가 약하면 무한 루프가 됩니다. 같은 tool을 100번 부르는 agent를 만나본 적 있을 거예요. 한 사용자 요청이 100만 토큰을 쓰고 끝나는 사고예요.
guardrail:
- max_iterations 한도 (보통 5~10)
- 같은 tool·같은 argument 반복 감지하면 종료
- 한 요청당 토큰 한도 (예: 100k 넘으면 강제 종료)
- agent 로그를 실시간으로 모니터링, 비정상 패턴은 알림
agent를 운영에 올리는 팀이라면 multi-agent-orchestration·ai-agent-evaluation에서 더 깊게 다뤘으니 같이 읽으면 좋습니다.
Guardrail 6 — Prompt cache hit율 모니터링
Anthropic prompt caching은 같은 시스템 프롬프트를 90% 할인된 단가로 처리합니다. cache hit율이 90%면 비용이 1/10이고, 0%면 단가가 그대로예요.
cache가 깨지는 흔한 원인:
- 시스템 프롬프트에 timestamp가 들어감 (매 요청 다름)
- 사용자별 데이터가 시스템 프롬프트 안에 들어감
- 프롬프트 한 글자가 바뀌어 cache key 무효
- cache breakpoint가 너무 짧음 (5분 TTL)
guardrail:
- cache_creation·cache_read 토큰을 메트릭으로 추적
- hit율이 50% 아래로 떨어지면 알림
- 시스템 프롬프트와 사용자 데이터의 경계를 명확히 분리
- 자주 호출되는 프롬프트는 1시간 TTL cache로
prompt caching의 단가 절약 효과는 prompt-caching-1000-90에서 더 깊게 정리했어요. 운영 LLM의 비용 1순위 guardrail은 사실 이 캐싱입니다.
모니터링 대시보드의 핵심 메트릭
비용 폭주를 사후에 발견하지 말고 사전에 막으려면 다음 메트릭이 한 대시보드에 있어야 합니다.
- 일일 비용 (어제·평균 대비 차이)
- 평균 input 토큰 (프롬프트 길이 추적)
- 평균 output 토큰 (답변 길이 추적)
- 평균 호출 수 per user (agent loop 폭주 감지)
- cache hit율 (Anthropic caching)
- retry 비율 (5xx 폭주 감지)
- 모델별 호출 분포 (자동 승격 감지)
이 7개 메트릭 중 한 개가 평소의 1.5배 넘으면 알림이 와야 해요. 사후 결산서가 와서 놀라는 일은 피할 수 있습니다.
📌 비용 모니터링은 OpenTelemetry로 표준화하는 추세
Anthropic, OpenAI 모두 OpenTelemetry로 LLM 메트릭을 export하는 표준을 채택하는 중입니다. Datadog·Grafana 같은 일반 APM에서 LLM 메트릭을 native로 보는 게 1년 안에 표준이 될 듯해요.
{/* TODO_HUNY: 매드업에서 LLM 자동화를 운영해보신 경험이 있다면 이 6가지 중 어느 패턴에 가장 자주 부딪혔는지, 그리고 어떻게 해결하셨는지 한두 단락. 특히 prompt drift나 context 누적은 운영자만 아는 사례가 풍부할 것 같습니다. */}
마치며
LLM 운영의 비용 폭주는 거의 100% 사전에 막을 수 있습니다. 6가지 guardrail이 다 있으면 비용이 10배 튈 일이 없어요. 한 달에 한 번 빈도로 비용 회고만 해도 폭주는 사전에 잡힙니다.
다음 글은 마케터가 매일 다루는 데이터의 가장 가까운 자리 — MMP raw export 컬럼 사전 mmp-raw-export-appsflyer-adjust-branch로 이어집니다.
Top comments (0)