429가 발생했다고 API 키를 바꾸거나 결제 계정을 먼저 연결하지 마세요. 우선 어느 서비스 경로인지, 어떤 프로젝트인지, 정확한 모델은 무엇인지, 어떤 지표 또는 처리 lane에 도달했는지, 그 제한이 언제 갱신되는지 다섯 가지를 기록해야 합니다. 이 정보가 없으면 기다려야 하는지, 트래픽을 줄여야 하는지, tier를 바꿔야 하는지 판단할 수 없습니다.
Gemini Developer API의 실제 값은 Google AI Studio 속도 제한 화면에서 대상 Google Cloud 프로젝트와 모델 행을 확인합니다. Gemini 앱, Firebase AI Logic, Vertex AI는 서로 다른 계수 방식과 용량 계약을 사용하므로 하나의 “Gemini 사용 횟수”로 합치면 안 됩니다.
| 실제 사용 경로 | 현재 값을 확인할 곳 | 첫 조치 |
|---|---|---|
| Gemini Developer API | AI Studio의 정확한 프로젝트·모델 행 | RPM, 입력 TPM, RPD, IPM, TPD, 지출, Priority, Batch 중 먼저 도달한 항목을 찾는다 |
| Gemini 앱 | 설정 → 사용량 한도 | 기능별 남은 사용량과 표시된 회복 시각을 확인한다 |
| Firebase AI Logic | Firebase 사용자별 gateway 설정과 upstream provider 할당량 | 두 계층을 모두 확인하고 더 낮은 값을 실효 한도로 본다 |
| Vertex AI | Google Cloud의 Dynamic Shared Quota 또는 Provisioned Throughput | 공유 용량과 구매 용량을 Developer API와 분리해 진단한다 |
중지 규칙: API 키를 돌려 쓰거나 원인을 모른 채 계속 재시도하지 마세요. 429 RESOURCE_EXHAUSTED는 할당량·속도·지출 같은 admission 증거를 먼저 보라는 신호이고, 503 UNAVAILABLE은 서비스 용량이나 일시적 가용성을 보라는 신호입니다. 분기를 확인한 뒤 workload를 바꿔야 합니다.
고정 표보다 현재 프로젝트 행을 확인한다
Gemini Developer API 공식 속도 제한 문서는 제한의 구조를 설명하고, 로그인한 AI Studio 화면은 특정 프로젝트와 모델에 적용되는 현재 값을 보여 줍니다. 공개 웹페이지의 모델별 숫자는 용어를 이해하는 데는 도움이 되지만, 내 프로젝트의 tier, account standing, preview 상태와 실제 활성 값을 증명하지는 못합니다.
Developer API 제한은 보통 서로 독립적인 세 차원으로 표시됩니다.
- RPM(requests per minute)은 1분 동안의 호출 수를 셉니다. 작은 요청이 많으면 token보다 RPM이 먼저 찰 수 있습니다.
- 입력 TPM(tokens per minute)은 prompt와 context 입력 token을 셉니다. 요청 수가 적어도 입력이 길면 이 제한이 먼저 걸립니다.
- RPD(requests per day)는 해당 프로젝트·모델 행에 일일 제한이 있을 때 적용됩니다. 현재 공식 규칙상 RPD는 태평양 시간 자정에 초기화됩니다.
일부 모델이나 기능은 IPM(images per minute) 또는 TPD(tokens per day)도 표시합니다. 적용되는 차원 중 하나라도 초과하면 속도 제한 응답을 받을 수 있습니다. Preview·experimental 모델은 더 엄격한 값을 가질 수 있으므로 모델군 이름으로 추정하지 말고 요청에서 정확한 model ID를 복사해야 합니다.
이 제한은 API 키가 아니라 Google Cloud 프로젝트 단위입니다. 같은 프로젝트의 두 키는 같은 pool을 사용합니다. 두 번째 키는 credential rotation이나 서비스 분리에 유용할 수 있지만 RPM, TPM, RPD를 늘리지 않습니다. 실제 API 응답이 아니라 AI Studio 화면의 제한 메시지가 문제라면 Google AI Studio 속도 제한 복구 가이드로 분리해서 확인하세요.
Google은 표시된 속도 제한이 보장된 용량은 아니라고 설명합니다. 프로젝트 행은 ceiling과 admission 조건이지, 지역 또는 서비스 전체의 용량 문제가 있을 때 그 아래 모든 요청이 반드시 처리된다는 약속은 아닙니다.
Tier와 지출 조건은 바뀔 수 있다
2026년 7월 15일 기준 Google 공개 문서는 다음 tier 자격 조건을 제시합니다. 이 조건은 바뀔 수 있으므로 load test 직전에도 다시 확인해야 합니다.
| Tier | 해당 날짜의 공개 자격 조건 | 계정에서 다시 확인할 내용 |
|---|---|---|
| Free | 활성 프로젝트 또는 free trial 상태 | 프로젝트에서 사용할 수 있는 모델과 실제 행의 값 |
| Tier 1 | 활성 billing account 연결 | 결제 활성화 뒤 표시되는 tier와 모델 행 |
| Tier 2 | 누적 결제액 100달러 이상, 첫 성공 결제 후 3일 이상 | account standing과 Google이 표시하는 현재 tier |
| Tier 3 | 누적 결제액 1,000달러 이상, 첫 성공 결제 후 30일 이상 | account standing과 Google이 표시하는 현재 tier |
같은 문서는 rolling 10분 동안 평가되는 지출 기반 admission 한도도 설명합니다. 2026년 7월 15일 기준 Tier 1은 10달러, Tier 2와 Tier 3은 200달러입니다. 금액과 적용 범위는 freshness-sensitive하므로 incident runbook이나 부하 시험에 고정하기 전에 공식 속도 제한 문서와 로그인한 프로젝트를 다시 대조하세요.
결제를 연결하면 tier 자격이 달라질 뿐 모든 제한이 사라지는 것은 아닙니다. 유료 프로젝트도 RPM, 입력 TPM, RPD, 지출 window, Batch 또는 serving capacity에 도달할 수 있습니다. 특정 모델을 결제 없이 쓸 수 있는지는 Gemini API 무료 티어 가이드에서 별도로 확인하세요.
분·일·지출·처리 lane을 따로 본다
분 단위 지표에 여유가 있어도 일일 또는 지출 조건에서 거절될 수 있습니다. Standard, Priority, Batch도 하나의 한도를 다르게 부르는 말이 아니라 각각 관찰해야 할 처리 경로입니다.
| 지표 또는 lane | 제어하는 대상 | 남겨야 할 증거 | 흔한 계획 오류 |
|---|---|---|---|
| RPM | 1분당 online 호출 수 | request timestamp 분포와 현재 RPM 행 | 평균 RPS만 보고 burst를 무시한다 |
| 입력 TPM | 1분당 prompt·context 입력 | 입력 token 분포 | 모든 요청 크기가 같다고 가정한다 |
| RPD | 적용되는 경우 하루 요청 수 | 현재 RPD 행과 Pacific reset 시각 | 짧은 backoff로 일일 한도가 회복된다고 생각한다 |
| 지출 window | 해당 rolling window의 지출 admission | billing tier와 현재 공식 조건 | 월 예산과 혼동한다 |
| Priority | 우선 처리 전용 한도 | 요청한 service tier와 x-gemini-service-tier | 무제한 추가 용량으로 본다 |
| Batch | 비동기 처리 전용 pool | 동시 job, file size, enqueued tokens | 긴급한 대화형 요청을 Batch로 보낸다 |
Priority inference 문서는 현재 기본 Priority 한도를 대응하는 Standard 모델·tier 한도의 0.3배로 설명합니다. Priority 용량이 소진되면 단순 실패가 아니라 Standard로 처리될 수 있으므로 latency나 cost가 lane에 의존한다면 응답의 x-gemini-service-tier를 기록하세요.
Batch는 대화형 호출과 별도 pool을 사용해 긴급하지 않은 작업에 적합합니다. 2026년 7월 15일 기준 Batch API 문서는 동시 batch request 100개, 입력 파일당 2 GB, 전체 file storage 20 GB, 모델·tier별 enqueued token 한도를 제시합니다. 이 값도 확인 날짜가 붙은 조건이며 영구 상수가 아닙니다.
좋은 부하 시험 기록에는 target RPS만 있지 않습니다. 정확한 모델과 프로젝트, 입력 token의 p50/p95, burst 계수, 요청한 serving tier, p95 latency, 하루 volume, 지출 노출, retry 비율, 동기 응답 필요 여부를 함께 남겨야 합니다.
실측값으로 안전한 처리량을 계산한다
대상 프로젝트 행을 확인했다면 먼저 분 단위에서 어느 ceiling이 먼저 걸리는지 계산합니다.
요청 상한 = min(현재 RPM, 현재 입력 TPM ÷ 요청당 평균 입력 token)
이 값은 수학적 출발점이지 production target이 아닙니다. 입력 크기는 흔들리고, 트래픽은 burst로 들어오며, retry는 부하를 늘리고, 실제 capacity는 표시 값보다 낮을 수 있습니다. 관측된 변동성과 비즈니스 위험에 맞춰 headroom을 정하세요. Google이 모든 시스템에 동일한 여유율을 지정하지는 않습니다.
가정을 밝힌 계산 예시
현재 행이 60 RPM, 120,000 입력 TPM이고 관측된 요청의 평균 입력이 4,000 token이라고 가정합니다.
- RPM 기준 상한은 분당 60 request입니다.
- 입력 TPM 기준 상한은 120,000 ÷ 4,000 = 분당 30 request입니다.
- 더 작은 값이 먼저 걸리므로 headroom 전 상한은 분당 30 request입니다.
- 이 예시에서 팀이 20% headroom을 선택하면 초기 운영 목표는 분당 24 request, 즉 0.4 RPS입니다.
- 관측 p95 latency가 2초라면 steady-state concurrency는 0.4 × 2 = 0.8로 추정할 수 있습니다. 실제로는 concurrency cap 1에서 시작해 queue, burst, retry 동작을 측정합니다.
20%는 설명을 위한 engineering assumption이며 Google 권장값이 아닙니다. 변동이 큰 consumer 서비스는 더 넓은 여유가 필요할 수 있고, 입력 크기를 엄격히 통제하는 offline queue는 다른 값이 적절할 수 있습니다.
분 단위 계산만으로는 충분하지 않습니다. 분당 24 request를 24시간 계속하면 이론상 하루 34,560회를 시도합니다. 현재 RPD 행과 비교하고 지출 window도 별도로 확인하세요. 10분 시험이 성공했다고 하루 종일 같은 속도로 실행할 수 있는 것은 아닙니다.
입력 크기가 일정하지 않다면 평균뿐 아니라 분위수를 사용합니다.
| 관측값 | 알려 주는 내용 |
|---|---|
| 평균 입력 token | 정상 상태 처리량의 초기 추정값 |
| p95 입력 token | 일반적인 peak에서 TPM에 도달하는지 |
| 허용 최대 입력 | 한 종류의 긴 요청이 1분 예산을 모두 쓰는지 |
| p95 latency | 안전한 RPS를 초기 concurrency cap으로 바꾸는 값 |
| Retry rate | 부분 장애 때 증폭되는 추가 부하 |
| Cache hit rate | 반복 context를 hot path에서 뺄 수 있는지 |
모델, prompt template, context 길이, tool use, traffic mix, tier, serving lane이 달라질 때마다 다시 계산하세요. 용량 계획은 한 번 하는 나눗셈이 아니라 측정과 조정의 반복입니다.
재시도하기 전에 429와 503을 구분한다
공식 troubleshooting 문서는 429 RESOURCE_EXHAUSTED와 503 UNAVAILABLE을 다른 의미로 다룹니다. 둘 다 일시적일 수 있고 bounded exponential backoff와 jitter가 도움이 될 수 있지만, 먼저 봐야 하는 증거와 장기 조치는 다릅니다.
| 응답 | 첫 진단 | 확인할 증거 | 유효한 조치 | 중지 조건 |
|---|---|---|---|---|
429 RESOURCE_EXHAUSTED | 할당량, 속도, RPD, 지출 또는 다른 admission limit | 전체 error body, headers, Retry-After, 프로젝트·모델 행, 최근 usage | queue, rate 감소, 입력 축소, 올바른 window 대기, 공식 quota 경로 | 소진된 차원과 reset을 모른 채 하는 재시도를 중지 |
503 UNAVAILABLE | 일시적 과부하, 용량 또는 서비스 비가용 | request ID, timezone 포함 시각, endpoint/region, model, service status | 상한 있는 backoff, traffic smoothing, 적절한 global endpoint, 증거 기반 escalation | retry budget을 넘거나 영향이 지속될 때 중지 |
분 단위 burst로 생긴 429는 window가 이동하면 회복될 수 있습니다. RPD에 도달한 429는 몇 초마다 재시도해도 해결되지 않습니다. 지출 한도라면 해당 rolling window 또는 billing 조치가 필요합니다. 503이 계속되면 project quota에 여유가 있어도 service status와 capacity path를 확인해야 합니다.
재시도 정책에는 횟수와 시간 한도가 필요하다
운영 retry policy는 최소한 다음을 정의해야 합니다.
- retry할 status code와 즉시 중지할 status code
- 같은 작업을 반복해도 중복 처리가 생기지 않는지
- 최대 시도 횟수와 전체 경과 시간 예산
- randomized jitter를 포함한 exponential backoff
- 응답에
Retry-After가 있을 때의 처리 - 동기화된 retry storm을 막는 queue 또는 circuit breaker
- 원본 호출과 retry traffic을 분리한 metrics
- request ID, 정확한 model, endpoint, timezone 포함 timestamp, 응답 상세, 영향을 담은 escalation packet
API 키는 증거 packet에 포함하지 마세요. 키 변경은 프로젝트 할당량을 늘리지 않으며 어떤 credential과 service가 실패했는지 추적하기 어렵게 만듭니다. 제한을 피하려고 프로젝트를 분산하는 것도 하지 마세요. 별도 프로젝트는 실제 ownership, billing, security, environment 경계가 있을 때만 사용합니다.
구현 코드에서도 중요한 판단은 먼저 소진된 clock을 찾은 뒤 retry, wait, quota request, capacity 조치 중 하나를 선택하는 것입니다. 원인을 모른 채 backoff 코드만 추가하면 일일 한도나 지출 window에서는 호출량만 키울 수 있습니다.
증상이 아니라 먼저 찬 제한을 고친다
가장 작고 안전한 조치는 실제로 먼저 도달한 지표가 결정합니다.
| 먼저 도달한 제한 | 단기 제어 | 지속 가능한 설계 | 피할 지름길 |
|---|---|---|---|
| RPM | burst를 평탄화하고 concurrency를 제한하며 queue에 넣는다 | workload별 admission control과 budget | 같은 project의 키를 늘린다 |
| 입력 TPM | context를 줄이고 중복 지시를 제거하며 batch size를 낮춘다 | 안정적인 prefix를 cache하고 큰 job을 분리한다 | token을 측정하지 않고 request만 센다 |
| RPD | 불필요한 호출을 멈추고 해당하면 Pacific reset을 기다린다 | 일일 volume을 예측하고 적절한 tier를 검토한다 | 짧은 간격으로 계속 재시도한다 |
| 지출 window | admission volume을 줄이고 해당 rolling window를 기다린다 | cost alert와 cost-aware admission | billing이 모든 제한을 없앤다고 본다 |
| Priority | 실제 반환된 tier를 확인하고 Standard fallback 허용 여부를 정한다 | latency-sensitive workload에만 사용하고 별도 모니터링한다 | 일반적인 여유 pool로 취급한다 |
| Batch token 또는 job | 제출 시간을 분산하고 job을 줄인다 | 현재 Batch 조건에 맞춘 비동기 scheduler | 즉시 응답이 필요한 처리를 옮긴다 |
| 503 용량 | 상한 있는 backoff와 traffic smoothing | global routing, capacity planning, 필요 시 Provisioned Throughput | 용량 증거 없이 project quota만 쫓는다 |
Cache는 큰 안정적 prefix가 반복될 때 효과적이고, queue는 기다릴 수 있는 수요에, Batch는 대화형 응답이 필요 없는 처리에 적합합니다. 모델 변경은 대체 모델이 현재 사용 가능하고 품질 요구를 충족하며 그 모델의 활성 행이 실제 제한을 개선할 때만 의미가 있습니다. 오래된 표에 남은 model name은 fallback 계획이 아닙니다.
할당량 상향을 요청하려면 project, model, traffic distribution, 먼저 도달한 지표, 성장 예측, 이미 적용한 완화책, business impact를 함께 제공하세요. “RPM을 늘려 달라”는 문장만 보내는 것보다 판단 가능한 증거가 됩니다.
Gemini 앱, Firebase, Vertex의 제한을 섞지 않는다
Gemini라는 이름은 여러 제품에 쓰이지만 제한을 세는 단위는 공통이 아닙니다.
Gemini 앱은 consumer account 사용량을 센다
Gemini 앱 제한은 선택한 모델이나 기능, prompt 복잡도, 파일, 대화 길이 등에 따라 달라질 수 있습니다. 2026년 7월 15일 기준 Gemini 앱 도움말은 주간 한도에 도달하기 전에는 사용 가능량이 5시간마다 갱신되고, 구체적인 회복 시각은 설정 → 사용량 한도에 표시되며, capacity에 따라 값이 바뀔 수 있다고 설명합니다.
앱 subscription은 Developer API 프로젝트의 RPM, TPM, RPD를 자동으로 늘리지 않습니다. consumer subscription과 billed API project는 서로 다른 사용 경로입니다.
Firebase AI Logic은 두 계층을 확인한다
Firebase AI Logic은 upstream model provider quota 앞에 사용자별 gateway limit을 둘 수 있습니다. 2026년 7월 15일 기준 Firebase는 기본 사용자별 제한을 100 RPM으로 안내합니다. 동시에 upstream Gemini 프로젝트·모델 할당량도 계속 적용됩니다.
실효 한도는 적용되는 두 계층 중 낮은 값입니다. 한 사용자만 제한되고 project usage에 여유가 있다면 Firebase gateway를 확인하세요. 많은 사용자가 함께 실패하고 Gemini 프로젝트 행이 소진됐다면 gateway 설정만 바꿔서는 해결되지 않습니다.
Vertex AI는 별도의 용량 계약을 사용한다
Vertex AI PayGo의 최신 Gemini 모델에 대해 Google Cloud는 고정된 단일 project quota 대신 Dynamic Shared Quota를 설명합니다. Vertex의 429는 shared pool 경쟁을 뜻할 수 있으므로 traffic smoothing, 적절한 global endpoint, bounded retry, Provisioned Throughput가 이 경로의 선택지입니다.
Developer API RPM/RPD를 Vertex 계획에 그대로 옮기지 마세요. 예측 가능한 enterprise throughput이 필요하면 관측한 PayGo 동작과 Provisioned Throughput를 비교해야 합니다.
이미지 생성은 IPM, 앱 이미지 횟수, Vertex image capacity처럼 더 구체적인 제한이 추가될 수 있습니다. 실제 문제가 이미지 처리라면 Gemini 이미지 생성 속도 제한 가이드로 분리하고 일반 Developer API 설명만으로 결정하지 마세요.
배포 전에 제한 조건을 기록한다
운영 전 기록은 다음 질문에 답할 수 있어야 합니다.
- 경로: Developer API, Gemini 앱, Firebase AI Logic, Vertex AI 중 무엇인가
- 소유: 어떤 project, billing account, consumer account, Firebase project가 소유하는가
- 모델: 정확한 model ID와 현재 status는 무엇인가
- 지표: RPM, 입력 TPM, RPD, IPM, TPD, 지출, Batch, Priority 중 무엇이 적용되는가
- window: 언제 reset 또는 이동하며 어디서 다시 확인하는가
- traffic 형태: p50/p95 입력 token, p95 latency, burst 계수, 일일 volume, retry rate는 얼마인가
- admission 제어: 어떤 queue, concurrency cap, token budget, shed rule이 운영 목표 아래로 유지하는가
- 오류 분기: 429와 503을 따로 기록하고 각각 retry 상한과 중지 조건이 있는가
- 처리 lane: Standard, Priority, Batch를 분리해 관찰하는가
- 공유 가능한 증거: credential 없이 request ID, 시각, model, project, response, impact를 남길 수 있는가
부하 시험에는 hello가 아니라 운영과 비슷한 입력 크기를 사용하세요. 짧은 burst와 지속 구간을 모두 시험하고 retry가 추가 부하로 보이는지 확인합니다. Alert는 공개 ceiling이 아니라 팀이 정한 운영 목표보다 앞에서 울리게 설정합니다.
유용한 dashboard는 모델별 숫자를 늘어놓는 화면이 아닙니다. 장애 중에 어느 경로가 실패를 소유하고, 어떤 지표가 먼저 찼으며, 무엇이 바뀌었고, 어떤 조치가 안전한지를 짧은 시간 안에 답해야 합니다.
자주 묻는 질문
Gemini API 속도 제한은 API 키 단위인가요?
아닙니다. Developer API 제한은 Google Cloud 프로젝트 단위입니다. 같은 프로젝트의 여러 키는 하나의 할당량 pool을 공유합니다.
Gemini API에 일일 제한이 있나요?
일부 프로젝트·모델 행에는 RPD 또는 TPD가 있지만 모든 모델에 공통인 숫자는 없습니다. RPD가 적용될 때 현재 규칙은 태평양 시간 자정에 초기화됩니다. 정확한 AI Studio 행을 확인하세요.
결제한 프로젝트도 왜 429를 반환하나요?
결제는 tier 자격을 바꿀 수 있지만 RPM, 입력 TPM, RPD, 지출 window, Batch 등은 남습니다. 429는 결제 실패의 증명이 아니라 먼저 도달한 차원을 찾으라는 증거입니다.
Gemini 429 뒤에 몇 분을 기다려야 하나요?
소진된 window에 따라 다릅니다. Retry-After가 있으면 따르고 error body와 현재 프로젝트 행을 대조하세요. 분 단위 압력에 도움이 되는 짧은 대기도 RPD는 초기화하지 못합니다.
Batch API 할당량은 별도인가요?
네. Batch는 interactive request와 다른 pool을 사용하며 동시 job, 입력 file, storage, enqueued token 제한이 있습니다. 운영 volume을 정하기 전에 최신 Batch 조건을 다시 확인하세요.
Gemini 앱 유료 요금제가 API 한도도 늘리나요?
그렇다고 가정하면 안 됩니다. Gemini 앱 allowance는 consumer account와 기능에 속하고, Developer API 할당량은 Cloud project, model, tier, 현재 AI Studio 행에 속합니다.
Vertex AI의 Gemini 제한은 Developer API와 같은가요?
아닙니다. 최신 Vertex AI PayGo Gemini traffic은 Dynamic Shared Quota를 사용하며 Provisioned Throughput는 구매한 용량입니다. Google Cloud 쪽 증거로 진단해야 합니다.
여러 Google Cloud 프로젝트를 쓰면 용량을 늘릴 수 있나요?
실제 environment, billing, security, organizational 경계가 있으면 프로젝트별 제한을 가질 수 있습니다. 하지만 할당량 회피를 위해 프로젝트를 만들거나 전환하면 안 됩니다. 합법적인 multi-project 구조라면 routing, spend, data policy, failure isolation을 명시하세요.
지원 요청에는 무엇을 보내야 하나요?
제품 경로, 안전하게 공유할 수 있는 project ID, 정확한 model, endpoint 또는 region, timezone 포함 timestamp, request ID, 전체 error code와 details, 현재 제한 행, 최근 traffic과 token 분포, retry 동작, 영향을 보내세요. API 키나 다른 credential은 절대 포함하지 마세요.
