Gemini API 비용 관리법: rate limit, fallback, 캐시를 먼저 설계하기

요약: Gemini API를 포함한 LLM API 운영에서 가장 흔한 실패는 모델 품질이 아니라 비용과 제한 관리입니다. 개발자는 프롬프트를 잘 쓰기 전에 rate limit, fallback, cache, retry, token budget을 먼저 설계해야 합니다.

핵심 키워드: Gemini API 비용 관리, LLM rate limit, AI API fallback, 토큰 예산, LLM 캐시 전략

왜 비용 관리가 먼저인가

LLM 기능은 프로토타입 단계에서는 싸고 빨라 보입니다. 하루에 수십 번 호출할 때는 토큰 비용도, rate limit도 크게 문제가 되지 않습니다. 문제는 사용자 트래픽이 생긴 뒤입니다. 같은 기능이라도 사용자가 1,000명이 되면 요청 수가 늘고, agent 구조를 붙이면 한 번의 사용자 행동이 여러 번의 모델 호출로 바뀝니다. 여기서 비용이 갑자기 튀어 오릅니다.

Gemini API든 OpenAI API든 Anthropic API든 기본 운영 문제는 비슷합니다. 분당 요청 수 제한, 토큰 제한, 모델별 quota, 일시적 429, 긴 context로 인한 비용 증가, retry 폭증이 생깁니다. 특히 무료 티어나 낮은 요금제에서 테스트하다가 프로덕션으로 넘어갈 때 제한을 제대로 보지 않으면 기능이 간헐적으로 멈춥니다.

그래서 AI 기능은 모델 호출 코드보다 운영 정책이 먼저입니다. 어떤 기능이 어떤 모델을 쓰는지, 최대 입력 길이는 얼마인지, 실패하면 어떤 모델로 fallback할지, 같은 결과를 얼마나 캐시할지, 사용자별로 하루 몇 번 허용할지 정해야 합니다. 이 기준이 없으면 “모델이 가끔 느리다”가 아니라 “서비스가 예측 불가능하다”가 됩니다.

rate limit을 기능 단위로 나누기

많은 팀이 rate limit을 전체 API key 단위로만 봅니다. 하지만 실무에서는 기능 단위로 나눠야 합니다. 예를 들어 검색 요약, 코드 리뷰, 이미지 설명, 고객문의 자동응답, 긴 문서 분석이 같은 API key를 쓰면 한 기능의 급증이 전체 기능을 막을 수 있습니다. 가장 위험한 패턴은 백그라운드 batch job이 사용자-facing 기능의 quota를 먹어버리는 경우입니다.

해결책은 traffic class를 나누는 것입니다. interactive class는 사용자가 기다리는 요청입니다. p95 latency와 성공률이 중요합니다. background class는 리포트 생성, 크롤링 요약, nightly job처럼 늦어도 되는 요청입니다. admin class는 내부 운영자가 쓰는 요청입니다. 각 class마다 별도 queue와 rate limiter를 두면 장애 범위를 줄일 수 있습니다.

구현은 복잡할 필요가 없습니다. Redis나 DynamoDB에 minute window counter를 두고, feature별 quota를 설정합니다. interactive 요청은 quota가 부족하면 즉시 작은 모델 fallback 또는 “잠시 후 다시 시도”를 반환합니다. background 요청은 queue에서 대기시키면 됩니다. retry는 exponential backoff를 쓰되, 사용자 요청에서는 무한 재시도하지 않습니다.

fallback은 품질 등급까지 포함해야 한다

fallback은 단순히 “A 모델 실패하면 B 모델 호출”이 아닙니다. 모델이 바뀌면 답변 품질, 비용, 속도, context 길이, tool support가 달라집니다. 따라서 fallback 정책에는 허용 가능한 품질 등급을 같이 적어야 합니다. 예를 들어 고객에게 보이는 법률성 답변은 작은 모델 fallback을 금지하고, 내부 태그 분류는 작은 모델 fallback을 허용할 수 있습니다.

fallback 결과에는 표시도 필요합니다. 사용자가 보는 UI에 반드시 “작은 모델로 처리됨”을 노출할 필요는 없지만, 로그에는 남겨야 합니다. 그래야 나중에 품질 저하가 특정 fallback 경로에서 발생했는지 알 수 있습니다. 모델명, fallback reason, latency, input token, output token, cache hit 여부를 같이 기록하세요.

또 fallback은 provider 간에도 고려해야 합니다. 특정 provider의 regional 장애나 quota 문제가 생길 수 있습니다. 다만 provider fallback은 prompt와 response schema 차이 때문에 테스트가 필요합니다. JSON output을 기대한다면 각 provider별 schema validation을 통과하는지 미리 eval해야 합니다.

캐시 전략: 모든 응답을 캐시하지 말 것

LLM 캐시는 비용을 줄이는 강력한 방법이지만, 무작정 쓰면 위험합니다. 캐시하기 좋은 요청은 입력이 안정적이고, 시간이 지나도 답이 크게 바뀌지 않고, 사용자별 개인정보가 적은 요청입니다. 예를 들어 문서의 기본 요약, 공개 URL 요약, 코드베이스 구조 설명, FAQ 초안은 캐시 후보입니다.

캐시하면 안 되는 요청도 있습니다. 사용자 개인 정보가 포함된 상담, 최신 데이터가 중요한 주가·뉴스 요약, 권한별로 결과가 달라지는 내부 문서 검색, 결제나 의료처럼 민감한 판단은 조심해야 합니다. 캐시 key에 사용자 권한과 데이터 버전을 포함하지 않으면 다른 사용자의 결과가 섞일 수 있습니다.

실무에서는 response cache와 context cache를 나눠보는 편이 좋습니다. response cache는 같은 질문에 같은 답을 재사용합니다. context cache는 긴 시스템 프롬프트, 문서 chunks, 코드 요약처럼 반복 입력을 줄입니다. agent 제품에서는 context cache의 효과가 더 큽니다. 매번 전체 문서를 다시 넣지 말고 요약 상태를 관리해야 합니다.

token budget을 제품 요구사항으로 쓰기

토큰은 개발자만 보는 내부 숫자가 아닙니다. 제품 요구사항입니다. “이 기능은 평균 3초 안에 끝나야 한다”처럼 “이 기능은 입력 8,000 token, 출력 1,000 token을 넘지 않는다”를 정해야 합니다. 그래야 프롬프트가 계속 길어져도 비용을 제어할 수 있습니다.

긴 문서를 처리할 때는 먼저 압축 전략을 정하세요. 전체 문서를 한 번에 넣기보다, section summary를 만들고, 질문과 관련된 section만 다시 넣는 방식이 좋습니다. 코드 리뷰도 전체 repository를 매번 넣지 말고, 변경 파일, 의존 파일, 프로젝트 규칙만 넣어야 합니다. 사용자가 긴 입력을 넣으면 즉시 호출하지 말고 “요약 후 처리” 단계를 둡니다.

budget 초과 시 정책도 필요합니다. 자동으로 작은 모델로 바꿀지, 일부 문서를 제외할지, 사용자에게 범위를 좁히게 할지 정해야 합니다. 아무 정책 없이 model context limit에 걸리면 UX가 나빠지고 retry 비용만 늘어납니다.

운영 대시보드에 넣을 지표

AI API 운영 대시보드에는 최소 10개 지표가 필요합니다. request count, input token, output token, cost estimate, p95 latency, error rate, 429 rate, retry count, fallback count, cache hit rate입니다. 여기에 feature, model, user tier, traffic class를 dimension으로 붙이면 문제를 빨리 찾을 수 있습니다.

예를 들어 비용이 늘었을 때 전체 token만 보면 원인을 모릅니다. feature별로 보면 문서 분석 기능의 output token이 늘었는지, agent retry가 늘었는지, cache hit rate가 떨어졌는지 구분할 수 있습니다. 429가 늘었을 때도 interactive 요청인지 background job인지 알아야 대응이 다릅니다.

알림 기준도 정해야 합니다. 429 rate가 5분 동안 3%를 넘으면 background job을 멈추고, interactive fallback을 켜는 식입니다. 비용은 일 단위 budget을 두고, 80% 도달 시 내부 알림, 100% 도달 시 저우선순위 기능 제한을 걸 수 있습니다. 사용자가 많은 서비스라면 user tier별 quota도 필요합니다.

실행 체크리스트

• 기능별로 사용하는 모델, 최대 입력 토큰, 최대 출력 토큰을 적었는가?
• interactive, background, admin traffic을 분리했는가?
• feature별 rate limiter와 queue가 있는가?
• 429 발생 시 retry 횟수와 backoff 정책이 정해져 있는가?
• fallback 가능 기능과 fallback 금지 기능을 나눴는가?
• fallback 결과를 로그와 품질 평가에 남기는가?
• response cache와 context cache를 구분했는가?
• 캐시 key에 사용자 권한, 데이터 버전, locale이 포함되는가?
• 비용, latency, error, token, cache, fallback 지표를 대시보드에서 보는가?
• budget 초과 시 어떤 기능을 제한할지 미리 정했는가?

Gemini API를 쓰든 다른 LLM API를 쓰든 결론은 같습니다. 프로덕션 AI 기능은 프롬프트보다 운영 설계가 먼저입니다. rate limit과 비용을 기능 요구사항으로 다루면 모델이 바뀌어도 서비스가 흔들리지 않습니다.