Gemini API 사용량 한도 2026: 프로젝트·등급·처리 경로별 429 진단

Gemini API에는 모든 제품과 계정에 공통으로 적용되는 단일 사용량 한도가 없습니다. Developer API의 실제 한도는 프로젝트, 모델, 사용 등급, 지표, 처리 경로에 따라 달라지며 공개 표를 보장값으로 보지 말고 AI Studio에서 확인해야 합니다.

요청이 실패하면 코드나 결제 설정을 바꾸기 전에 HTTP 상태와 전체 오류 본문을 보존하십시오. 429 RESOURCE_EXHAUSTED는 한도 소진 분기이고 503 UNAVAILABLE은 일시적인 서비스 용량 분기입니다. 일일 한도, 롤링 지출, 선불 잔액, 명시적 할당량은 재시도 횟수를 늘린다고 풀리지 않습니다.

요청이 도착한 Google 제품부터 구분한다

Gemini라는 이름은 소비자 앱, 개발자 API, Firebase, Google Cloud에 함께 쓰입니다. 같은 모델 이름이 보여도 할당량 소유자와 확인 화면이 같다는 뜻은 아닙니다. SDK, 엔드포인트, 프로젝트, 인증 방식을 기준으로 실제 요청 경로를 확정해야 합니다.

이 분리를 거치면 모순처럼 보이는 현상이 풀립니다. Gemini 앱에서 사용 제한 알림이 떠도 Developer API 프로젝트에는 여유가 있을 수 있습니다. Firebase에서는 모델 제공자 할당량이 남았지만 특정 사용자만 게이트웨이 한도에 걸릴 수 있습니다. Vertex AI의 429는 Cloud 용량 계약에서 발생해 AI Studio에는 이상이 보이지 않을 수도 있습니다.

Developer API는 ai.google.dev 계약과 API 키로 호출하는 Gemini API를 뜻합니다. Firebase와 Vertex AI에는 별도의 플랫폼 소유 계층이 있으므로 “같은 Gemini 모델”이라는 이유만으로 진단 절차를 합치지 않습니다.

Developer API 한도는 지표·프로젝트·모델·등급의 조합이다

Google의 사용량 한도 공식 문서는 세 가지 핵심 지표를 설명하고, 한도가 API 키가 아니라 프로젝트 단위로 적용된다고 명시합니다.

어느 한 지표라도 적용 한도를 넘으면 429가 발생할 수 있습니다. RPM이 낮아도 입력 TPM을 소진할 수 있고, 요청이 짧아도 하루 동안 누적되면 RPD에 도달합니다. “몇 번만 호출했다”는 설명에는 같은 프로젝트를 사용하는 운영 서비스, 노트북, 배치 작업, 팀원의 키가 포함되지 않습니다.

모델과 모달리티에 따라 TPD(일일 토큰 수), IPM(분당 이미지 수), Batch 전용 한도도 나타납니다. 이 값들은 모델과 처리 경로에 속합니다. 이미지 생성 IPM이 원인이라면 Gemini 이미지 429 진단으로 범위를 좁혀야 합니다.

운영에서 기억할 규칙은 두 가지입니다. 첫째, 같은 프로젝트의 여러 API 키는 하나의 풀을 공유합니다. 키 회전은 자격 증명 변경이지 용량 확장이 아닙니다. 둘째, 공개 문서는 구조를 설명하고 현재 값은 AI Studio가 소유합니다. Google도 문서에 적힌 한도가 보장되지 않으며 실제 용량이 달라질 수 있다고 밝힙니다.

미리보기나 실험 모델은 더 엄격한 한도를 가질 수 있습니다. 무료 사용 가능 여부와 가격 경로도 별도로 바뀝니다. 모델 자격이 아직 불분명하다면 Gemini API 무료 등급 가이드에서 “호출 자격”과 “남은 할당량”을 분리하십시오.

1분 안에 한도 소유자를 좁히는 기록

다른 팀이나 지원 담당자에게 전달해도 재현 가능한 정보를 남깁니다.

• 제품 표면과 전체 엔드포인트
• 비밀 키가 아닌 프로젝트 ID와 키의 소유 프로젝트
• 정확한 모델과 처리 모드
• HTTP 상태, 오류 상태, 전체 메시지
• 시간대를 포함한 발생 시각
• 입력 크기, 동시 실행 수, 직전 재시도 횟수
• 같은 시간대의 AI Studio 또는 Cloud 사용량 화면

다음 순서로 분류합니다.

1. 제품 표면: Gemini 앱, Developer API, Firebase AI Logic, Vertex AI 중 무엇인가?
2. 상태: 429 한도 사건인가, 503 일시 용량 사건인가?
3. 지표: RPM, 입력 TPM, RPD, 롤링 지출, 잔액, Priority, Batch 중 어느 후보인가?
4. 집계 경계: 어떤 프로젝트나 결제 계정이 소유하며 어떤 워크로드가 공유하는가?
5. 처리 경로: Standard, Priority, Batch, Firebase 게이트웨이, Vertex 용량 중 어디인가?
6. 관리 화면: 소유자 화면의 같은 시간대 데이터가 오류와 일치하는가?
7. 조치: 입증된 소유자에 영향을 주는 가장 작은 변경 하나를 선택한다.
8. 검증: 같은 프로젝트, 모델, 부하, 지표로 회복을 확인한다.

사용 등급, 롤링 지출, 잔액, 지출 상한은 서로 다르다

“결제를 켰는데 429가 계속된다”는 말은 여러 재무 제어를 하나로 볼 때 생깁니다. 2026년 7월 14일 기준 Google의 한도 문서와 결제 문서를 다시 확인하면 최소 네 가지를 나눠야 합니다.

등급 자격은 연결된 결제 계정 기준이고, Developer API 요청 풀은 프로젝트 기준입니다. 두 프로젝트가 같은 결제 계정 덕분에 같은 등급을 가져도 요청 풀은 합쳐지지 않습니다. 반대로 프로젝트 지출 상한을 올려도 이미 소진한 모델 RPD는 사라지지 않습니다.

이 수치는 모두 변동 가능성이 높습니다. 운영 변경 직전 공식 사용 등급과 지출 제한 및 AI Studio 활성 값을 다시 확인해야 합니다. 결제 이력, 계정 상태, 입금 반영, 보고 지연이 결과에 영향을 줄 수 있습니다.

예를 들어 Tier 2 프로젝트에서 RPM이 낮아 보이는데 429가 지속된다면, 비싼 요청이 10분 롤링 지출 제한에 닿았을 수 있습니다. 이때 동시성이나 키를 늘리면 실패만 늘어납니다. 롤링 지출이 정상이어도 Prepay 잔액이 0이면 1분 대기는 무의미합니다. 둘 다 정상인데 RPD가 소진됐다면 추가 결제도 잘못된 조치입니다.

Standard, Priority, Batch는 서로 다른 처리 계약이다

처리 경로는 오류가 난 뒤 붙이는 이름이 아니라 처음부터 용량 설계에 포함되는 계약입니다.

Google의 Batch API 문서는 최대 24시간의 비동기 완료를 전제로 하며 작업 생성이 멱등적이지 않다고 설명합니다. 클라이언트 측 영구 ID를 먼저 만들고 반환된 작업 이름을 저장하십시오. 생성 요청이 타임아웃됐다고 즉시 다시 제출하면 중복 작업이 생길 수 있습니다.

Batch는 “다른 곳에서 계속 재시도”하는 기능이 아닙니다. 기다릴 수 있는 오프라인 부하를 대화형 트래픽에서 분리하는 계약입니다. Priority도 모든 프로젝트에 자동으로 추가 용량을 주지 않으므로 자격, 자체 한도, 대화형 합산을 함께 봐야 합니다.

기다림이나 트래픽 모양이 결과를 바꿀 때만 재시도한다

Google 문제 해결 문서는 429와 503을 다른 분기로 다룹니다. 재시도 구현도 같은 결정을 먼저 해야 합니다.

다음 함수는 429를 자동 재시도하지 않습니다. 호출자가 “짧게 기다리면 소유자 상태가 달라진다”고 판정한 경우에만 허용합니다.

javascript
const sleep = (ms) => new Promise((resolve) => setTimeout(resolve, ms));

export async function withGeminiRetry(run, {
  maxAttempts = 5,
  baseDelayMs = 750,
  maxDelayMs = 20_000,
  isTransient429 = () => false,
  onRetry = () => {},
} = {}) {
  let lastError;
  for (let attempt = 1; attempt <= maxAttempts; attempt += 1) {
    try {
      return await run();
    } catch (error) {
      lastError = error;
      const status = Number(error?.status ?? error?.code ?? 0);
      const retryable = status === 500 || status === 503 || status === 504 ||
        (status === 429 && isTransient429(error));
      if (!retryable || attempt === maxAttempts) throw error;

      const ceiling = Math.min(
        maxDelayMs,
        baseDelayMs * 2 ** (attempt - 1),
      );
      const delayMs = Math.floor(Math.random() * ceiling);
      onRetry({ attempt, status, delayMs, message: error?.message });
      await sleep(delayMs);
    }
  }
  throw lastError;
}

함수 밖에는 프로젝트와 모델별 동시성 제한기를 둡니다. 여러 워커가 같은 시각에 깨어나면 백오프 이후 새 피크를 만들기 때문입니다. 가능한 작업에는 멱등 키를 사용하고 중복 입력을 캐시하며 전체 재시도 시간을 사용자 지연 예산 안에 둬야 합니다.

isTransient429는 짧은 RPM 피크처럼 시간이 실제 소유자를 바꾼다는 증거가 있을 때만 true입니다. RPD 소진, 선불 잔액 0, 지출 상한, 거절된 증액 요청, 설정 변경이 필요한 소유자는 false로 유지합니다.

Firebase AI Logic에는 사용자별 게이트웨이 한도가 추가된다

Firebase AI Logic을 사용해도 모델 제공자 할당량은 사라지지 않습니다. Firebase 할당량 문서는 제공자 한도가 우선하며 Firebase 게이트웨이가 별도의 사용자별 요청 한도를 추가한다고 설명합니다. 2026년 7월 14일 기준 문서 기본값은 사용자당 100 RPM입니다.

따라서 많은 사용자가 각각 Firebase 한도 아래에 있어도 제공자 프로젝트 한도를 함께 소진할 수 있습니다. 반대로 한 버그가 있는 클라이언트만 사용자별 한도에 걸리고 제공자 용량은 남아 있을 수 있습니다.

동일 요청의 Firebase 계층, App Check 신원, 제공자 사용량을 대조하십시오. 사용자 한도를 높여도 제공자 용량은 늘지 않습니다. 제공자 용량을 늘려도 의도적으로 낮게 둔 사용자 보호 한도는 없어지지 않습니다.

Vertex AI 429는 Cloud 용량 계약에서 확인한다

Vertex AI 요청은 Google Cloud 프로젝트, 위치, 엔드포인트, 용량 제어를 사용합니다. Vertex AI 429 공식 문서는 pay-as-you-go와 Provisioned Throughput을 다른 메시지와 해결책으로 구분합니다.

Pay-as-you-go에서는 지원되는 경우 global endpoint 사용, 트래픽 평준화, 제한된 재시도, 할당량 기반 모델 증액 신청, 용량 계획 변경이 후보입니다. Provisioned Throughput에서는 구매한 처리량 안인지, 초과분이 pay-as-you-go로 처리되는지 확인해야 합니다. 상태 코드만 저장하지 말고 오류 문구를 보존하십시오.

Vertex 요청을 AI Studio만 보고 진단하지 않습니다. Cloud 프로젝트, 엔드포인트, 위치, 할당량 화면, Provisioned Throughput 상태가 첫 확인 대상입니다. 해결해야 할 문제가 용량 사건이 아니라 플랫폼 선택이라면 Gemini API와 Vertex AI 비교로 분리합니다.

증명된 소유자에 영향을 주는 순서로 용량을 바꾼다

작고 되돌리기 쉬운 변화부터 적용합니다.

1. 낭비 제거: 중복 요청 캐시, 반복 컨텍스트 제거, 재귀 재시도 차단, 포기한 요청 취소.
2. 수요 형상화: 버스트 큐잉, 프로젝트·모델별 동시성 제한, 대화형 트래픽 여유 예약.
3. 적격 경로 선택: 기다릴 수 있는 작업은 Batch로, Priority는 계약과 여유가 맞을 때만.
4. 작업 모양 변경: 요구 품질을 만족하는 가벼운 모델, 입력 분할, 불필요한 출력 축소.
5. 재무 소유자 수정: 적격 잔액 복구, 올바른 상한 조정, 등급 자격 반영 대기.
6. 용량 확보: 한도 증액을 요청하거나 Cloud 관리·예약 용량이 필요하면 적절한 Vertex 경로 채택.
7. 진단 뒤 분산: 단일 제공자 집중이 입증된 신뢰성 위험일 때 다중 모델 fallback 설계.

마지막 작업에는 laozhang.ai 같은 다중 모델 게이트웨이를 후보로 평가할 수 있습니다. 그러나 Google 프로젝트 할당량을 늘려 주지는 않습니다. 모델 동등성, 타임아웃, 전환 정책, 멱등성, 데이터 처리, 관측성, 비용을 실제로 시험하고 가격, 모델 범위, 속도, 가동률을 검증 없이 약속하지 마십시오.

모든 변경에는 같은 소유자의 검증 지표가 필요합니다. 동일 프로젝트와 모델에서 대표 부하를 실행하고 429 비율, 지연, 중복 작업, 요청·토큰 사용량을 확인합니다. 배포 성공은 할당량 회복의 증거가 아닙니다.

자주 묻는 질문

현재 Gemini API 사용량 한도는 어디서 확인하나요?

AI Studio에서 실패한 요청과 같은 프로젝트와 모델을 선택합니다. 공개 문서는 RPM, 입력 TPM, RPD, 등급, 처리 경로를 설명하지만 값 자체를 보장하지 않습니다. 운영 판단은 활성 한도 화면을 기준으로 합니다.

한도는 API 키별인가요, 프로젝트별인가요?

Developer API는 프로젝트별입니다. 같은 프로젝트의 키는 하나의 풀을 공유합니다. 새 프로젝트는 워크로드, 소유권, 결제, 거버넌스를 실제로 분리해야 할 때만 만듭니다.

RPD는 언제 재설정되나요?

현재 Developer API 문서는 태평양 시간 자정을 기준으로 합니다. 기다리기 전에 RPD가 원인인지 확인하십시오. RPM, 입력 TPM, 지출, 잔액, Firebase, Vertex는 다른 창과 계약을 사용합니다.

결제를 활성화했는데 왜 429가 계속되나요?

결제는 한 가지 분기일 뿐입니다. RPM, 입력 TPM, RPD, 롤링 지출, 프로젝트/계정 상한, Priority, 모델별 한도, Prepay 잔액을 각각 확인해야 합니다.

Priority로 바꾸면 용량이 늘어나나요?

항상 그렇지 않습니다. Priority는 자체 한도를 가진 적격 계약이며 대화형 사용량에도 포함됩니다. 이동 전 Priority와 Standard의 실제 여유를 동시에 확인합니다.

Batch는 대화형 한도를 피할 수 있나요?

Batch는 별도 한도를 가진 비동기 경로지만 무제한이 아닙니다. 동시 작업, 파일, 저장 공간, 대기 토큰 제한이 있고 최대 24시간 완료 시간을 받아들일 수 있어야 합니다.

모든 429를 재시도해야 하나요?

아닙니다. 기다림이나 트래픽 모양이 소진된 소유자를 바꿀 때만 재시도합니다. 일일 한도, 잔액, 지출 상한, 명시 할당량은 별도의 수정이 필요합니다.

사용량과 오류가 맞지 않을 때 무엇을 지원팀에 보내나요?

전체 오류 본문, 시간대가 포함된 시각, 프로젝트 ID, 모델, 엔드포인트, 처리 경로, 입력 크기, 직전 동시성, 같은 시간대 사용량 화면을 보냅니다. API 키와 사용자 데이터는 제거합니다.

운영에서 남길 한 가지 원칙

제품 표면, 지표, 집계 경계, 처리 경로, 수정 조치를 먼저 이름 붙이십시오. 올바른 관리 화면에서 소유자를 확인하고 실제로 영향을 주는 한 가지 변경만 적용한 뒤 같은 부하로 검증합니다. 단단한 경계가 남아 있으면 재시도를 멈추고 올바른 재설정을 기다리거나 수요를 줄이고, 적격 경로를 선택하거나 용량을 확보하십시오.