이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- AI 비용 폭증은 어떤 원인으로 발생하는가?
- tenant별 quota와 기능별 budget은 어떻게 설계하는가?
- 비용 장애가 발생했을 때 어떤 순서로 대응해야 하는가?
개요
AI 비용은 요청 수만으로 설명되지 않는다. token 길이, retry, output 길이, eval, embedding, vector search, observability가 모두 비용을 만든다.
비용 폭증은 운영 장애다.
비용 원인
- 긴 context
- 무제한 output token
- retry storm
- batch/eval 실행
- embedding 재색인
- prompt cache hit rate 하락
- 특정 tenant 과사용
- 로그 원문 저장
Quota 설계
quota는 여러 층으로 둔다.
- 사용자별 분당 요청 수
- 사용자별 일일 token
- tenant별 월간 token
- 기능별 max input/output token
- batch/eval 별도 budget
- admin override
코드로 이해하기
public void checkAndConsume(AiUsage usage) {
quotaRepository.requireRemaining(
usage.tenantId(),
usage.inputTokens() + usage.outputTokens()
);
quotaRepository.consume(
usage.tenantId(),
usage.inputTokens() + usage.outputTokens()
);
}실제 구현에서는 동시성 제어와 실패 보상이 필요하다.
장애 대응 순서
- tenant별 사용량을 본다.
- prompt version별 token 증가를 본다.
- retry count를 본다.
- batch/eval 실행을 확인한다.
- cache hit rate를 본다.
- 임시 quota 제한이나 feature flag를 적용한다.
인프라 협업 포인트
비용 알림은 application metric과 billing metric이 함께 필요하다. 인프라팀과 daily burn rate, tenant budget, provider quota, log storage 비용을 맞춘다.
실전 팁
- 비용은 기능 출시 첫날부터 기록한다.
- retry count를 usage event에 포함한다.
- eval key와 production key를 분리한다.
- prompt 변경 PR에 token 변화 예상을 적는다.
위험 신호!
- tenant별 비용을 모른다.
- max output token이 없다.
- batch/eval이 production quota를 쓴다.
- retry 비용을 계산하지 않는다.
확인 질문
확인 질문
- 비용 폭증을 장애로 다뤄야 하는 이유는 무엇인가?
- 예산 초과, quota 차단, 서비스 중단, 사용자별 불공정 사용으로 이어질 수 있기 때문이다.
- prompt 변경이 비용에 영향을 주는 방식은 무엇인가?
- input token 증가, cache hit rate 하락, output 길이 증가를 만들 수 있다.
Spring AI 적용 연결
- Spring AI 비용 폭증은 token budget, model profile, request cap, usage metric을 함께 봐야 잡힌다. 운영 지표와 알림 설계는 11. Observability와 장애 대응 런북에서 이어진다.
- quota와 예산 한도를 인프라 운영 계약으로 합의하는 방법은 12. Production Readiness와 인프라 협업을 함께 본다.