Gemini API 429·400·500 오류를 가장 빨리 해결하는 방법(2026)

2026년 3월 18일 기준으로 먼저 결론부터 말하면, 429 RESOURCE_EXHAUSTED는 대개 쿼터, 과금 티어, 요청 속도 문제이며 잠깐 기다렸다가 재시도할 가치가 있습니다. 400 INVALID_ARGUMENT는 요청 본문, 모델, 파라미터, endpoint 조합이 잘못된 경우가 많아서 보통은 재시도보다 수정이 먼저입니다. 500 INTERNAL은 Google 측 일시 장애이거나 입력 컨텍스트가 너무 큰 경우가 많으므로, 입력을 줄이고 제한된 exponential backoff를 적용한 뒤 필요하면 Gemini 2.5 Pro에서 Gemini 2.5 Flash로 잠시 옮기는 것이 가장 빠른 복구 경로입니다.

이 주제에서 정말 중요한 것은 "코드가 무슨 뜻이냐"가 아니라 "지금 다음 1분 안에 무엇을 해야 하느냐"입니다. 2026년의 Gemini 환경에서는 429를 단순히 "너무 많이 호출했다"로 끝낼 수 없습니다. 2025년 12월 7일의 쿼터 조정, Paid Tier 1 반영 시간, 사용량이 낮은데도 429가 발생한다는 커뮤니티 보고까지 함께 봐야 합니다. 400도 JSON 문법 오류 하나로 끝나지 않습니다. /v1와 /v1beta 불일치, 모델 지원 범위 문제, billing 전제 조건 미충족이 섞여 있습니다. 500 역시 무조건 "잠시 후 다시 시도"가 아닙니다. 공식 문서가 긴 컨텍스트도 500 원인이라고 명시하고 있기 때문입니다.

핵심 요약

장애 대응 중이라면 먼저 아래 표로 방향부터 잡으세요. 429, 400, 500을 같은 흐름으로 처리하지 않는 것이 가장 중요합니다.

특히 기억해야 할 세 가지 시점이 있습니다. 첫째, Firebase AI Logic FAQ는 Gemini Developer API의 Free Tier와 Paid Tier 1 쿼터가 2025년 12월 7일부터 조정되었다고 명시합니다. 둘째, Google의 Gemini API billing 문서는 400과 500 실패 요청은 과금되지 않지만 quota는 차감된다고 설명합니다. 셋째, Google은 2026년 3월에 usage tier와 spend cap을 조정했고, 2026년 4월 1일부터 tier spend cap 적용을 시작합니다. 그래서 2025년 기준의 오래된 가이드를 그대로 믿으면 진단이 어긋나기 쉽습니다.

30초 안에 429, 400, 500을 구분하는 방법

Gemini 오류 대응에서 가장 효과적인 습관은 HTTP status만 보지 않고 오류 응답 본문 전체를 읽는 것입니다. 실제로 봐야 하는 것은 status, message, QuotaFailure, RetryInfo, 그리고 모델명과 endpoint 버전입니다. 로그에 단순히 "429"나 "500"만 남아 있으면 정확한 다음 행동을 정하기 어렵습니다.

공식 Gemini troubleshooting guide는 여전히 가장 중요한 출발점입니다. 다만 실무에서는 이렇게 읽는 편이 더 빠릅니다. 429는 "전송 속도나 quota / tier 상태에 문제가 있다", 400 INVALID_ARGUMENT는 "요청 자체가 잘못되었다", 400 FAILED_PRECONDITION는 "요청 형식보다 billing이나 지역 조건이 부족하다", 500은 "인증과 기본 검증은 통과했지만 Google 측 처리 단계에서 실패했다"는 뜻으로 해석하면 됩니다.

정말 시간을 아끼고 싶다면 최소한 모델명, endpoint 버전, 요청 크기, 같은 payload가 다른 Gemini 모델에서는 통과하는지를 로그에 남기세요. 이 네 가지 정보만으로도 로컬 버그와 provider incident를 훨씬 빨리 분리할 수 있습니다.

429 RESOURCE_EXHAUSTED 고치기: 실제 한도, 과금 반영 지연, Ghost 429

Google 공식 설명대로 429는 rate limit 초과입니다. 문제는 2026년에는 이 설명만으로 충분하지 않다는 점입니다. 공식 rate limits 페이지는 active limit을 AI Studio에서 확인해야 한다고 말하고, 문서에 적힌 제한이 고정 용량을 보장하지 않는다고도 적고 있습니다. 예전 블로그에 적힌 숫자만 믿고 429를 해석하면 오판하기 쉽습니다.

가장 큰 최근 변화는 2025년 12월 7일의 쿼터 조정입니다. Firebase AI Logic FAQ는 이 날짜부터 Gemini Developer API의 Free Tier와 Paid Tier 1 quota가 조정되었고, 그 결과 예상치 못한 429가 발생할 수 있다고 명시합니다. 코드나 트래픽이 크게 바뀌지 않았는데 429가 늘어난 사례를 설명하는 핵심 배경입니다.

또 하나 중요한 점은 Gemini 제한이 API key 단위가 아니라 project / billing account 단위로 적용된다는 사실입니다. Billing 문서는 API key가 project와 billing account 상태를 상속한다고 설명합니다. 따라서 같은 프로젝트 안에서 key를 새로 만들어도 quota가 새로 생기지 않습니다.

실무적으로는 429를 세 가지 정도로 나눠 보는 것이 좋습니다.

Google AI Developers Forum에는 사용량이 낮은 Paid Tier에서도 429가 지속된다는 보고가 여러 번 올라왔습니다. 어떤 응답은 free-tier metric처럼 보이는 세부 정보를 포함하기도 했습니다. 그렇다고 모든 429가 플랫폼 문제라는 뜻은 아니지만, 적어도 "429 = 무조건 네가 너무 빨랐다"라고 자동 결론을 내리면 안 됩니다. low-traffic paid project가 첫 요청 묶음부터 429를 쏟는다면, tier 동기화나 quota-state 이상도 충분히 의심해야 합니다.

반대로 진짜 rate limit이라면 해결책은 단순하지만 효과적입니다. burst를 줄이고, 불필요한 컨텍스트를 없애고, 작은 호출을 합치고, 클라이언트 쪽 queue와 backoff를 넣는 것입니다. 필요하다면 상위 tier로 올라가야 합니다. Google 공식 문서는 Free에서 Tier 1로의 전환은 보통 즉시, 그 이후 tier 변경은 보통 10분 내에 반영된다고 설명합니다. 이를 한참 넘겼는데도 free tier 같은 동작이 계속되면, 트래픽 계산보다 설정과 billing 연결 상태를 먼저 의심하는 편이 맞습니다.

문제가 단일 요청이 아니라 production 경로 전체의 안정성이라면 해법도 달라집니다. 여러 모델과 공급자를 OpenAI 호환 인터페이스로 묶어야 하는 팀이라면 laozhang.ai 같은 relay 레이어가 의미 있을 수 있지만, 그것은 routing과 가용성 문제를 다루는 경우에만 해당합니다.

400 고치기: INVALID_ARGUMENT와 FAILED_PRECONDITION은 다르다

400 계열은 "Bad Request"라는 말 하나로 묶이기 쉽지만 실제 처리 방식은 꽤 다릅니다. 공식 문서가 INVALID_ARGUMENT와 FAILED_PRECONDITION을 나눠 쓰는 이유가 바로 여기에 있습니다.

먼저 INVALID_ARGUMENT입니다. Google은 이 오류가 요청 본문 구조가 틀렸거나, 필수 필드가 없거나, 더 새로운 API version 기능을 더 오래된 endpoint에서 사용했을 때 발생할 수 있다고 명시합니다. 이 마지막 부분이 특히 중요합니다. JSON 문법 자체가 맞더라도, /v1beta에서만 지원되는 기능을 /v1로 호출하면 400이 납니다.

실제 현장에서 많은 원인은 비슷합니다. 오래된 모델명, 지원하지 않는 파라미터, 필드 nesting 오류, 잘못된 파일 처리 흐름, 모델이 지원하지 않는 capability를 억지로 사용하는 경우입니다. 따라서 400을 고치는 올바른 순서는 "한 번 더 보내 보자"가 아니라 "모델, endpoint, payload를 함께 맞춰 본다"입니다.

FAILED_PRECONDITION은 payload 문제가 아닌 access 조건 문제인 경우가 많습니다. 무료 tier를 사용할 수 없는 지역에서 billing을 켜지 않았다면, JSON을 계속 손봐도 해결되지 않습니다.

물론 커뮤니티에는 동일한 코드가 갑자기 400 INVALID_ARGUMENT를 내다가 시간이 지나며 회복된 사례도 있습니다. 그렇다고 400을 retryable로 봐야 한다는 뜻은 아닙니다. 올바른 해석은, request의 타당성을 먼저 확인한 뒤 동일 payload를 형제 모델에서 테스트하여 모델 고유의 일시 문제인지 확인해야 한다는 것입니다.

500 INTERNAL 고치기: 긴 컨텍스트, 모델 불안정, 안전한 재시도

Google의 공식 troubleshooting guide는 500 INTERNAL이 Google 측 unexpected error일 수 있을 뿐 아니라 입력 컨텍스트가 너무 길어서 발생할 수도 있다고 적고 있습니다. 공식 권장 대응도 분명합니다. 컨텍스트를 줄이거나, Gemini 2.5 Pro에서 Gemini 2.5 Flash로 임시 전환해 보라는 것입니다.

이 설명은 모델 페이지와도 맞아떨어집니다. Gemini 2.5 Pro는 1,048,576 token 입력을 지원하지만, 그렇다고 해서 매우 큰 prompt를 항상 안정적으로 처리한다는 뜻은 아닙니다. 긴 대화 이력, 많은 파일, retrieval chunk, 복잡한 system instruction을 한꺼번에 넣으면 500 위험은 자연히 올라갑니다.

그래서 500을 보면 가장 먼저 해야 할 일은 단순합니다. 입력을 줄이기입니다. 중복 지시를 제거하고, 오래된 이력을 잘라내고, retrieval 개수를 줄이세요. "들어가니까 보낸다"는 방식이 오히려 문제를 키웁니다.

또 다른 500은 모델 자체의 불안정성입니다. Google AI Developers Forum에는 Gemini 2.5 Pro가 광범위하게 500을 내는 동안 Flash는 통과하는 사례가 보고되었습니다. 이런 상황에서 가장 값진 테스트는 같은 payload를 Flash에도 보내 보는 것입니다. Flash는 되고 Pro는 안 된다면, 가장 빠른 복구책은 임시 model switch입니다.

실무 순서는 대체로 이 정도면 충분합니다.

1. 현재 request가 지나치게 크지 않은지 확인한다.
2. jitter가 있는 bounded backoff를 적용한다.
3. Pro를 사용 중이었다면 같은 payload를 Flash로도 테스트한다.
4. 입력을 줄여도 폭넓게 실패하면 platform incident로 간주한다.

반복 실패가 이어질 때의 Troubleshooting 흐름

같은 계열의 실패가 반복되면, 건건이 즉흥적으로 대응하지 말고 비교 가능한 프로세스로 바꾸는 것이 좋습니다. 성공한 payload와 실패한 payload를 나란히 놓고 model, endpoint, prompt 크기, file 유무를 비교하면, 이것이 트래픽 문제인지, request 문제인지, model 상태 문제인지 더 빨리 드러납니다.

중요한 질문은 하나입니다. 시간이 해결에 도움이 되는가? 429와 많은 500은 기다림이 의미가 있습니다. 결정적인 400은 보통 그렇지 않습니다. 같은 INVALID_ARGUMENT를 여러 번 반복 전송하는 것은 해결에 가까워지는 것이 아니라 quota만 쓰는 것입니다.

운영 환경이라면 "Gemini가 실패했다"라는 문장만 로그에 남기지 마세요. 모델, endpoint version, 대략적인 입력 크기, 정규화된 오류 분류까지 남겨야 나중에 패턴을 읽을 수 있습니다.

운영용 재시도 템플릿: 무엇을 재시도하고 무엇을 즉시 실패시킬 것인가

retry 로직에서 중요한 것은 대기 시간 계산식보다, retryable과 non-retryable을 어떻게 나누느냐입니다. Gemini에서는 429, 500, 503, 504를 bounded backoff로 재시도하고, 400, 401, 403, 404는 실제로 무언가를 수정하기 전까지 즉시 실패시키는 편이 가장 실용적입니다.

Python

python
import random
import time
from google import genai
from google.genai import errors

client = genai.Client(api_key="YOUR_GEMINI_API_KEY")

RETRYABLE = {429, 500, 503, 504}
FAIL_FAST = {400, 401, 403, 404}


def generate_with_retry(model: str, contents, max_retries: int = 5):
    for attempt in range(max_retries):
        try:
            return client.models.generate_content(model=model, contents=contents)
        except errors.ClientError as exc:
            status = getattr(exc, "code", None)
            message = str(exc)

            if status in FAIL_FAST:
                raise RuntimeError(
                    f"Non-retryable Gemini error {status}: {message}"
                ) from exc

            if status in RETRYABLE and attempt < max_retries - 1:
                delay = min(2 ** attempt, 30)
                jitter = random.uniform(0, delay * 0.2)
                time.sleep(delay + jitter)
                continue

            raise RuntimeError(
                f"Retry budget exhausted after Gemini error {status}: {message}"
            ) from exc

Node.js

ts
import { GoogleGenAI } from "@google/genai";

const client = new GoogleGenAI({ apiKey: process.env.GEMINI_API_KEY! });
const retryable = new Set([429, 500, 503, 504]);
const failFast = new Set([400, 401, 403, 404]);

export async function generateWithRetry(model: string, contents: string) {
  for (let attempt = 0; attempt < 5; attempt += 1) {
    try {
      return await client.models.generateContent({ model, contents });
    } catch (error: any) {
      const status = error?.status ?? error?.code ?? 0;

      if (failFast.has(status)) {
        throw new Error(`Non-retryable Gemini error ${status}: ${error.message}`);
      }

      if (retryable.has(status) && attempt < 4) {
        const delayMs = Math.min(1000 * 2 ** attempt, 30000);
        const jitterMs = Math.random() * delayMs * 0.2;
        await new Promise((resolve) => setTimeout(resolve, delayMs + jitterMs));
        continue;
      }

      throw error;
    }
  }
}

핵심은 수식이 아니라 분기입니다. INVALID_ARGUMENT를 계속 retry해도 request는 저절로 맞아지지 않습니다. 반대로 429와 500을 전혀 retry하지 않으면, 몇 초 기다리면 성공했을 요청을 너무 일찍 포기하게 됩니다.

2026년 변화 때문에 예전 해결법이 더 이상 잘 맞지 않는 이유

오래된 Gemini 오류 가이드가 덜 유용해진 이유는 플랫폼이 바뀌었기 때문입니다. 현재의 오류 해석에 직접 영향을 주는 날짜는 최소한 다음과 같습니다.

그래서 예전의 "완전 가이드"는 완전히 틀리지는 않아도, 지금의 Gemini를 정확히 진단하기에는 정보가 부족한 경우가 많습니다. 날짜가 붙은 전제 업데이트가 반드시 필요합니다.

FAQ

실패한 Gemini 요청은 과금되나요?

400과 500은 일반적으로 과금되지 않습니다. 다만 quota는 계속 차감됩니다.

Gemini 제한은 API key 기준인가요, 프로젝트 기준인가요?

기본적으로 project와 billing account 기준으로 생각해야 합니다. API key는 그 상태를 상속할 뿐이며, 같은 프로젝트 안에서 key를 늘려도 quota가 늘지 않습니다.

billing 활성화는 얼마나 빨리 반영되나요?

Google은 Free에서 Tier 1로의 전환은 보통 즉시, 이후 upgrade는 보통 10분 정도라고 설명합니다. 그보다 훨씬 오래 걸리는데도 free tier처럼 보인다면, 프로젝트와 billing 연결 상태부터 확인하세요.

언제 Gemini 2.5 Pro에서 Flash로 바꾸는 것이 좋나요?

같은 payload가 Flash에서는 통과하고 Pro에서는 실패할 때, 500이 과도한 컨텍스트와 함께 나타날 때, 또는 reasoning 품질보다 빠른 서비스 복구가 중요할 때입니다.

Gemini의 모든 오류를 한 페이지에서 완벽하게 해결해 주는 공식 문서가 있나요?

없습니다. 공식 troubleshooting guide가 최선의 출발점이지만, 2026년에는 rate limits, billing, pricing, release notes도 함께 봐야 정확하게 판단할 수 있습니다. 더 넓은 범위의 정리가 필요하면 Gemini API 오류 트러블슈팅 전체 가이드도 참고하세요.