AI API 게이트웨이의 비용을 조용히 갉아먹는 5가지 비용 함정과 해결 방법

지난 포스트에서는 게이트웨이를 502 오류 제조기로 만드는 조용한 운영상의 살인자인 핵심 캐시 무효화(cache invalidation)에 대해 이야기했습니다. 오늘은 그만큼 위험하지만 훨씬 더 교활한 주제인 **비용 함정(cost traps)**에 대해 이야기하고자 합니다.

이것들은 버그가 아닙니다. 크래시(crash)도 아닙니다. 게이트웨이는 잘 작동하고 사용자들도 만족합니다. 그러다 재무팀에서 Slack 메시지를 보냅니다: "지난달 OpenAI 청구 금액이 왜 4배나 뛰었나요?"

저는 세 곳의 회사에서 여러 팀을 대상으로 LiteLLM Proxy를 운영해 왔습니다. 제가 직접 경험하며 손해를 보았던 다섯 가지 비용 함정과, 각각의 상황에서 수천 달러를 아껴줄 수 있었던 설정법을 소개합니다.

함정 #1: 재시도 소용돌이(The Retry Spiral) — num_retries=3이 실제로는 15번을 의미할 때

문제점

LiteLLM의 재시도(retry) 로직은 똑똑합니다. 너무 똑똑해서 문제입니다. 요청이 실패하면 재시도합니다. 재시도한 요청이 폴백 모델(fallback model)에 도달했는데 그것마저 실패하면, 다시 재시도합니다. 만약 각 3회의 재시도를 설정한 5개의 모델로 구성된 폴백 체인(fallback chain)을 구성했다면, 단 한 번의 사용자 요청이 최대 **15번의 업스트림 API 호출(upstream API calls)**을 유발할 수 있습니다. 그리고 토큰을 소비한 후 에러가 발생한 호출을 포함하여 모든 호출에 대해 비용을 지불해야 합니다.

발생하는 이유

LiteLLM의 기본 num_retries 값은 3입니다. 대부분의 팀은 이를 설정한 뒤 잊어버립니다. 하지만 재시도는 폴백 체인을 따라 배수로 늘어납니다. 계산식은 다음과 같습니다:

요청(Request) → 모델 A 실패 → 재시도 A (1) → 재시도 A (2) → 재시도 A (3)
       → 모델 B로 폴백(Fallback) → 실패 → 재시도 B (1) → 재시도 B (2) → 재시도 B (3)
       → 모델 C로 폴백(Fallback) → 실패 → 재시도 C (1) → 재시도 C (2) → 재시도 C (3)
...

만약 모델 C가 GPT-4o이고 각 재시도가 타임아웃(timeout)이 발생하기 전 2K의 입력 토큰을 소비한다면, 단 한 번의 실패한 요청에 24K 토큰이 소모되는 것입니다.

해결 방법

모델별로만 제한하지 말고, 전체 체인에 걸친 총 시도 횟수를 제한하세요:

# litellm_config.yaml
litellm_settings:
  num_retries: 2           # 모델별 재시도 횟수
...

핵심 통찰: 폴백 모델은 기본 모델과 비용이 같아서는 안 되며, 더 저렴해야 합니다. GPT-4o가 실패한다면 Claude Opus가 아니라 GPT-4o-mini로 폴백해야 합니다.

함정 #2: 프리미엄 모델로 돈을 쏟아붓게 만드는 폴백 체인 (Fallback Chains)

문제점

이것은 제가 단 한 번의 주말 동안 2,300달러를 날리게 만든 함정입니다. 의도는 좋았던 한 엔지니어가 다음과 같은 폴백 체인 (fallback chain)을 설정했습니다:

# 비싼 방식 — 이렇게 하지 마세요
router_settings:
  fallbacks:
...

논리는 타당해 보였습니다: "저렴한 모델이 실패하면, 더 나은 모델을 시도한다." 하지만 실제로 일어난 일은 다음과 같습니다: 트래픽 급증 중에 GPT-4o-mini의 속도 제한 (rate-limited, 곳곳에서 429 에러 발생)이 걸렸고, 그 결과 모든 요청이 GPT-4o를 거쳐 Claude 3.5 Sonnet으로 흘러 들어갔습니다. 6시간 동안 우리는 체인 내에서 가장 비싼 모델들로 트래픽의 100%를 처리하고 있었습니다.

발생하는 이유

속도 제한 (Rate limits)은 게이트웨이 기준이 아니라 모델별로 적용됩니다. gpt-4o-mini에 대한 OpenAI의 TPM (Tokens Per Minute) 제한에 도달하면, LiteLLM은 충실하게 폴백 (fallback)을 수행합니다. 하지만 트래픽 급증이 (특정 모델의 장애가 아닌) 전체적인 볼륨 때문에 발생한 것이라면, 폴백 모델 역시 처음에 429 에러를 유발했던 것과 동일한 볼륨을 받게 됩니다. 문제를 해결하는 것이 아니라, 단지 다른 모델을 사용하기 위해 10배의 비용을 더 지불하고 있는 셈입니다.

해결 방법

폴백을 성능 계층 (capability tier)이 아닌 비용 계층 (cost tier) 기준으로 구조화하세요:

# 스마트한 방식 — 상위 모델로 올라가지 말고, 동일 가격대 내에서 폴백
router_settings:
  fallbacks:
...

또한 알림 (alerting)을 추가하세요. 만약 폴백 비율이 전체 트래픽의 5%를 초과한다면, 구조적으로 무언가 잘못된 것입니다:

# LiteLLM 커스텀 콜백 (custom callback) 내의 prometheus 메트릭
from litellm.integrations.custom_logger import CustomLogger
import litellm
...

함정 #3: 캐싱 부재 = 동일한 답변에 1,000번 비용 지불

문제점

대부분의 팀은 "우리의 프롬프트 (prompts)는 동적이다"라는 이유로 LiteLLM의 내장 캐싱 (built-in caching)을 활성화하지 않습니다. 하지만 실제로 트래픽의 상당 부분은 거의 동일합니다. 시스템 프롬프트 (system prompts)는 동일하고, 사용자 메시지의 처음 500 토큰 (tokens)은 종종 상용구 (boilerplate)이며, 많은 사용자가 정확히 똑같은 질문을 던집니다.

제가 한 팀의 트래픽을 감사(audit)했을 때, 요청의 34%가 지난 한 시간 동안 발생한 요청과 정확히 동일한 중복 요청임을 발견했습니다. 그들은 동일한 완료(completions) 결과에 대해 OpenAI에 하루 약 $400를 지불하고 있었습니다.

발생하는 이유

LiteLLM에는 Redis 캐싱 (caching) 기능이 내장되어 있습니다. 하지만 기본적으로 비활성화되어 있으며, 문서에서도

그리고 예산 초과를 감지하기 위한 웹훅 (webhook)을 설정하세요:

# LiteLLM 프록시 설정에서
litellm_settings:
  proxy_budget_respecting_alerting:
...

인턴의 무한 루프(loop)는 어떻게 되었을까요? 하루 $50의 키 예산과 100 RPM 제한이 있었다면, 100번의 호출 이후에는 스로틀링 (throttling)이 발생했을 것이고, $50에 도달한 후에는 완전히 차단되었을 것입니다. 총 피해액은 약 $0.80에 불과했습니다.

함정 #5: 스트리밍 세금 (Streaming Tax) — 보지도 못한 토큰에 비용을 지불하고 있습니다

문제점

스트리밍 모드 (stream=True)는 사용자 경험 (UX) 측면에서 매우 훌륭합니다. 사용자는 토큰이 실시간으로 나타나는 것을 볼 수 있습니다. 하지만 대부분의 팀이 깨닫지 못하는 사실이 있습니다. 스트리밍 요청이 중간에 중단되더라도, 생성된 전체 토큰에 대해 비용을 지불해야 한다는 점입니다.

사용자가 요청을 시작함 → GPT-4o가 2,000개 토큰의 응답을 스트리밍하기 시작함 → 사용자가 50개 토큰 이후에 페이지를 벗어남 → 클라이언트 연결이 끊김 → 하지만 업스트림 (upstream) API 호출은 완전히 완료됨 → 당신은 2,000개 토큰 전체에 대한 비용을 지불함.

규모가 커지면 이는 치명적입니다. 저는 클라이언트가 조기에 연결을 끊어버리는 바람에 전체 토큰 지출의 23%가 사용자가 전혀 보지 못한 토큰에 낭비되는 팀들을 목격했습니다.

발생하는 이유

LiteLLM(및 대부분의 API 게이트웨이)은 스트리밍 중에 클라이언트가 연결을 끊더라도 업스트림 요청을 자동으로 취소하지 않습니다. 게이트웨이는 프록시 (proxy) 역할을 수행하고 있기 때문에, 아무도 듣고 있지 않더라도 OpenAI로부터 토큰을 기쁘게 수신하여 전달하려고 시도합니다.

해결 방법

클라이언트 연결 끊김 감지 및 업스트림 취소 기능을 활성화하세요:

litellm_settings:
  # 스트리밍 중 클라이언트가 연결을 끊으면 업스트림 요청을 취소함
  stream_options:
...

이전 버전을 사용 중이거나 더 세밀한 제어가 필요한 경우, 커스텀 미들웨어 (custom middleware)를 추가하세요:

from litellm.proxy.custom_proxy_admin_logic import CustomProxyAdminLogic

class StreamCancellationMiddleware(CustomProxyAdminLogic):
...

또한, 스트리밍 엔드포인트에 대해 max_tokens를 보수적으로 설정하는 것을 고려하십시오:

model_list:
  - model_name: gpt-4o-stream
    litellm_params:
...

스트림 취소 기능을 구현한 후, 낭비되던 23%의 지출은 2% 미만으로 감소했습니다.

다섯 가지 함정 뒤에 숨겨진 패턴

이러한 패턴의 핵심을 주목하세요: 이 모든 함정은 규모가 커질 때 위험해지는, 합리적인 기본 설정(default)들이라는 점입니다. 재시도(Retries)는 좋습니다. 하지만 폴백(fallbacks)을 통해 배수로 늘어나기 전까지만 그렇습니다. 폴백은 좋습니다. 하지만 트래픽을 더 비싼 프리미엄 모델로 몰아넣기 전까지만 그렇습니다. 캐싱(Caching)은 선택 사항입니다. 하지만 비용의 30%를 차지하기 전까지만 그렇습니다.

해결책은 결코 "기능을 비활성화하는 것"이 아닙니다. 항상 "제약 조건(constraints)을 추가하는 것"입니다. 예산(Budgets), 상한선(caps), 쿨다운(cooldowns), TTL(Time To Live) 등이 그 예입니다. 게이트웨이는 당신을 위해 작동해야지, 당신이 게이트웨이에 휘둘려서는 안 됩니다.

LiteLLM이나 다른 AI API 게이트웨이를 배포하고 있다면, 다음 사항을 빠르게 점검(audit)해 보세요:

1. 실질적인 재시도 배수(effective retry multiplier)는 얼마인가요? (num_retries × fallback_depth)
2. 폴백 체인이 가격이 더 높은 모델로 올라가는(fall UP) 경우가 있나요?
3. 캐싱이 활성화되어 있나요? (5초 안에 대답할 수 없다면, 아마 활성화되지 않았을 것입니다)
4. 모든 API 키에 예산 상한선(budget cap)이 설정되어 있나요?
5. 스트리밍 토큰 중 실제로 전달되는 비율은 몇 퍼센트인가요?

이 질문 중 하나라도 불안함을 느꼈다면, **AI API Gateway Pitfall Map**을 확인해 보시기 바랍니다. 제가 제작한 이 한 페이지 분량의 운영 생존 가이드는 이러한 함정들(그리고 몇 가지 더)을 다루고 있으며, 출력해서 책상 앞에 붙여둘 수 있는 형식으로 되어 있습니다. 제가 비싼 대가를 치르며 이 교훈들을 배우기 전에 가졌더라면 좋았을 체크리스트입니다.

실제 운영 환경에서 이러한 함정에 빠진 적이 있나요? 아니면 제가 놓친 다른 함정을 발견하셨나요? 댓글을 남겨주세요. 다음 포스트를 위해 여러분의 경험담(war stories)을 수집하고 있습니다.

태그: #litellm #ai #devops #costoptimization

🎁 무료: AI API Gateway 배포 전 체크리스트

배포하기 전에 인증(auth), 비용 제어(cost control), 캐싱(caching), 폴백(fallbacks), 보안(security), 모니터링(monitoring), 그리고 운영 준비 상태(production readiness)를 다루는 이 43가지 항목의 체크리스트를 실행해 보세요. 무료입니다. 여기서 받으세요:

👉 무료 배포 전 체크리스트 (PDF)

그리고 위에서 언급한 각 함정에 대한 상세한 해결책이 포함된 전체 함정 지도(pitfall map)를 원하신다면, 여기에서 확인하실 수 있습니다: AI API Gateway Pitfall Map ($9)