huny.log

기술 포스트 · AI·LLM

LLM 운영 비용 폭주를 막는 6가지 guardrail — 마케팅 자동화의 cost·latency·품질 동시 관리

LLM을 운영에 올리면 어느 날 갑자기 비용이 10배로 튑니다. retry storm·프롬프트 폭증·모델 자동 승격·context 누적 등 폭주 패턴 6가지와 그것을 막는 guardrail을 정리합니다.

· llmcostguardrailopstoken-economics

LLM을 POC로 띄울 때는 한 달 API 비용이 200달러 정도 나옵니다. 그런데 운영에 올린 다음 어느 날 갑자기 한 주 비용이 2만 달러로 튀는 경험은 LLM 운영자라면 거의 다 해봐요. 코드가 바뀌지 않았는데 비용이 튀는 거예요. 이 글은 운영 환경에서 LLM 비용이 폭주하는 6가지 전형적인 패턴과 그것을 사전에 막는 guardrail을 정리합니다. 마케팅 자동화 파이프라인을 LLM으로 운영하는 팀에게 특히 절실한 주제예요.

왜 LLM 비용은 갑자기 튀는가

전통 SaaS는 비용이 비교적 예측 가능합니다. 사용자가 두 배 늘면 서버 비용이 두 배 늘죠. LLM은 그렇지 않습니다.

  • 같은 요청이라도 답변이 길어지면 토큰이 두 배
  • retry 한 번이 비용 두 배, 두 번이 세 배
  • 한 사용자의 context를 누적하면 매 요청마다 토큰이 선형 증가
  • 모델을 한 단계 업그레이드하면 토큰당 단가가 5배
  • “tool use” 한 사이클이 LLM 호출 3~5번

이 5가지가 동시에 발생하면 비용이 10배 폭주합니다. 사용자는 늘지 않았는데도요.

LLM 운영 비용 폭주를 막는 6가지 guardrail 다이어그램
비용은 토큰·호출 수의 곱이다. 6가지 guardrail은 곱의 한 축이 갑자기 폭발하지 않게 잡아주는 안전핀이다.

비용 폭주의 6가지 전형 패턴

#패턴증상1차 원인
1Retry storm일시적 5xx 후 비용 10배백오프 없는 즉시 재시도
2Prompt drift같은 기능 비용이 한 달 새 두 배시스템 프롬프트가 누적 추가
3Context 누적사용자가 오래 쓸수록 매 호출 비용 증가대화 history를 매번 다 보냄
4모델 자동 승격모델 alias가 새 버전으로 자동 갱신claude-3-5-sonnet-latest 같은 floating alias
5Agent 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한 경우는 한 번 더 확인이 필요해요.

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 모두 권장하는 표준 운영 패턴이에요.

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배 넘으면 알림이 와야 해요. 사후 결산서가 와서 놀라는 일은 피할 수 있습니다.

마치며

LLM 운영의 비용 폭주는 거의 100% 사전에 막을 수 있습니다. 6가지 guardrail이 다 있으면 비용이 10배 튈 일이 없어요. 한 달에 한 번 빈도로 비용 회고만 해도 폭주는 사전에 잡힙니다.

다음 글은 마케터가 매일 다루는 데이터의 가장 가까운 자리 — MMP raw export 컬럼 사전 mmp-raw-export-appsflyer-adjust-branch로 이어집니다.

참고

AI·LLM 카테고리의 다른 글

전체 보기 →