제미나이 무료 API, 키 발급, 분당·일일 한도, 유료 전환 | 기능별 예산 체크리스트는?

체크리스트는 위에서 아래로 한 번에 훑는 용도가 아닙니다. 단계마다 “통과/보류/유료 검토”를 적고, 보류 항목만 다시 돌리면 됩니다. 사이드 앱에 채팅·요약·야간 리포트가 같이 있으면 이 순서가 특히 중요합니다.

공식 한도 설명은 Rate limits, 단가는 Pricing에 있습니다. 글 안의 숫자는 계산 연습용이며, 대시보드·공식 표가 항상 우선입니다.

같은 제미나이 모델이라도 진입 경로가 세 갈래입니다. 경로를 먼저 고정하지 않으면 키·IAM·청구 계정이 뒤섞입니다. 체크 한 줄마다 예/아니오로 답하고, “아니오”가 두 개 이상이면 무료 단독 경로를 재검토하세요.

사용 티어(Free → Tier 1 → 2 → 3)는 청구 연동·누적 지출에 따라 올라가고, 티어가 오르면 보통 한도도 넓어집니다. Tier 1의 대표 조건은 활성 청구 계정 연결입니다. Tier 2·3은 누적 결제 금액·경과일 조건이 붙는 경우가 많아, 정확한 자격은 공식 Rate limits 문서의 Usage tiers를 확인합니다. 사이드 프로젝트는 Free에서 관측 → Tier 1로 넓히기가 현실적인 순서입니다.

경로 비교를 표로 더 깊게 보려면 스튜디오 vs Vertex·부가세 글을 참고하세요.

발급 자체는 짧습니다. 사고는 대개 발급 직후 30분에 납니다. 키를 채팅에 붙여 넣거나, 프론트 번들에 넣고, 같은 프로젝트에 테스트·운영 키를 섞는 패턴입니다. 순서를 고정해 두면 실수가 줄어듭니다.

키를 여러 개 만들어도 같은 프로젝트면 RPM·RPD가 합산되는 경우가 많습니다. “키를 늘려 한도를 우회한다”는 전제는 쓰지 마세요. 한도를 늘리려면 사용 티어 승급(청구 연동·누적 사용) 또는 공식 상향 경로를 봅니다. 멀티 키는 로테이션·폐기 편의용이지, 무료 용량 확장용이 아닙니다.

첫 curl 스모크 테스트와 환경 변수 분리는 핸즈온 튜토리얼에 단계가 더 있습니다. 발급이 끝나면 바로 “한도 캡처”로 넘어가면 됩니다.

블로그에 적힌 “무료는 분당 몇 회” 숫자를 외우지 마세요. 모델·티어·시점에 따라 다르고, 프리뷰 모델은 Free 칸이 비어 있는 경우도 있습니다. 배포 체크리스트에 넣을 것은 오늘 캡처한 표입니다.

세 한도 중 가장 먼저 터질 것을 미리 표시해 두면 설계가 쉬워집니다. 짧은 프롬프트 다량 호출은 RPM·RPD, 문서 통째 요약·긴 생성은 TPM이 먼저입니다. 에이전트가 한 사용자 요청에 내부 호출을 5번 하면, 사용자 1명이 RPD를 5씩 깎습니다. 이 배수(multiplier)를 빼먹으면 일일 예산이 과장됩니다.

한 앱에 기능이 늘면 RPD는 “사용자 수 × 기능 수 × 내부 호출 배수”로 불어납니다. 무료로 버티려면 기능을 없애기보다 일일 슬롯을 배분하는 편이 낫습니다. 아래 표에 본인 숫자를 채워 보세요. 합계가 캡처한 RPD의 70%를 넘기면 기능을 줄이거나 캐시·배치로 옮깁니다.

표의 숫자는 예시입니다. 본인 RPD가 1,000이면 합계 700 이하를 목표로 잡고, 나머지 30%는 스파이크·재시도·버그 루프용 여유로 둡니다. 여유 없이 100%를 쓰면 재시도 한 번에도 하루가 끝납니다.

캐시와 요청 큐로 합계를 깎는 실습 코드는 캐시·큐 분리 글에 있고, 쿼터 미터·소프트 캡 코드는 쿼터 미터 실습을 보면 됩니다. 여기서는 “어디에 예산을 쓸지”만 체크합니다. 예산 표가 비어 있으면 소프트 캡 코드도 의미가 없습니다.

무료 티어에서 가장 나쁜 UX는 “갑자기 500 에러”입니다. 그보다 나은 순서는 우리 쪽 소프트 캡 → 친절한 대기 메시지 → 지수 백오프 → 기능 플래그 off입니다. 429를 없앨 수는 없어도, 사용자가 원인 없는 실패를 받는 횟수는 줄일 수 있습니다.

서버에 일일 게이트와 스트리밍을 붙이는 순서는 서버 게이트 실습에 정리돼 있습니다. 체크리스트만으로 끝내도 되지만, 코드가 없으면 관측이 안 됩니다. “로그에 RPD 사용률이 보인다”까지를 통과 조건으로 두면 이후 유료 전환 판단이 쉬워집니다.

동시 접속이 몰릴 때는 RPM이 먼저입니다. 사용자 요청을 그대로 모델에 붙이지 말고, 초당·분당 토큰 버킷 또는 작업 큐를 한 겹 두는 편이 안전합니다. 큐 길이가 늘면 느린 응답이 나와도, 429 폭풍보다 복구가 쉽습니다.

유료 전환은 감정이 아니라 신호입니다. 하루 막혔다고 바로 결제하기보다, 2주 관측 뒤 아래 항목에 몇 개가 켜졌는지 세어 보세요. 3개 이상이면 개발자 API 청구 연동(Tier 1)을 검토하고, 조직 보안 요건이 겹치면 Vertex를 병행 검토합니다.

신호가 1~2개면 먼저 기능 배분과 소프트 캡을 고칩니다. 신호가 많고 수익·학습 가치가 분명하면 결제 연동으로 한도를 넓히는 편이 싸게 끝나는 경우가 많습니다. 반대로 신호가 많은데 제품 가치가 불명확하면, 유료 전환 전에 기능을 줄이는 쪽이 맞습니다. 카드만 연결하고 예산 알림을 안 걸면 다음 달 청구서에서 놀랍니다.

전환 후에도 소프트 캡은 유지하세요. 유료는 “무한”이 아니라 종량입니다. 월 상한 알림(빌링 예산)을 달러와 원화 감각 둘 다로 걸어 두는 것이 안전합니다. 이미지·멀티모달이 붙는 순간의 비용 점프는 무료 vs 유료 케이스에서 시나리오를 볼 수 있습니다.

공식 단가는 보통 USD/100만 토큰 단위입니다. 카드로 결제하면 환율·해외 결제 수수료·부가세(VAT) 처리 방식이 청구 주체·카드사에 따라 달라질 수 있습니다. 아래는 의사결정용 골격입니다. 배포 전 공식 Pricing 숫자로 덮어쓰고, 첫 달 명세서로 한 번 보정하세요.

연습 예시(단가는 가정): 입력 10M·출력 2M, 입력 $0.30/1M·출력 $2.50/1M이면 USD는 0.3×10 + 2.5×2 = $8입니다. 환율을 1,400원으로 잡으면 약 11,200원이고, 여기에 10%를 더 얹어 보면 약 12,300원 상한 감각이 나옵니다. 실제 단가·환율·세금 처리는 공식 표와 명세서를 따릅니다. 세금 자문이나 회계 판단이 필요하면 전문가 확인이 맞습니다. 이 사이트는 개발 의사결정용 계산 순서만 제공합니다.

Flash 계열 thinking·장문 추론 단가가 붙는 경우는 Flash thinking 가격 글과 함께 보시면 됩니다. 사이드 프로젝트 손익에서 자주 놓치는 항목은 “내 시간”입니다. 매주 한도 때문에 기능을 끄고 설명하는 시간이 2시간이면, 그 기회비용이 월 몇만 원 청구보다 클 수 있습니다. 숫자로 나란히 적어야 전환 논의가 짧아집니다.

한 번 배포했다고 끝이 아닙니다. 모델 ID 변경·신기능·마케팅 유입이 한도를 밀어 올립니다. 주 1회 15분 루틴이면 대부분의 사고를 미리 볼 수 있습니다. 팀 슬랙에 같은 목록을 고정해 두면 좋습니다.

주간 루틴에서 “신호 점수 3 이상”이 두 주 연속이면, 그때가 카드 연결 회의입니다. 반대로 점수가 0~1이면 무료 유지가 맞고, 개발 시간은 제품 기능에 쓰는 편이 이득입니다. 기존 사이드 프로젝트용 전체 목록과 겹치는 항목은 무료 API 체크리스트에도 있으니, 팀 문서에는 한 쪽만 링크로 걸어 중복을 줄이세요.

출시 전날 또는 결제 연동 직전에 이 한 장만 다시 봅니다. 빈칸이 있으면 배포를 하루 미루는 편이 낫습니다.

이 목록을 통과하면 “무료 API로 사이드 기능을 여러 개 붙이다가 하루 만에 멈춤” 사고의 대부분이 줄어듭니다. 한도 숫자는 외우지 말고, 캡처 습관과 기능별 예산을 코드·표에 남기는 쪽이 오래 갑니다.

• Gemini API Rate limits — RPM·TPM·RPD, 프로젝트 단위 한도, 사용 티어
• Gemini Developer API pricing — 무료/유료 단가, 모델별 Free 제공 여부
• Google AI Studio — Get API key — 무료 키 발급
• AI Studio Rate Limit 대시보드 — 계정별 실한도 확인
• Gemini API 문서 허브 — 모델·SDK·가이드 모음
• 내부: 무료 티어 가이드 · 사이드 체크리스트 · Vertex·부가세 · 캐시·큐 · 첫 호출

한도·가격은 2026년 8월 작성 기준으로 서술했으며, 배포 전 공식 페이지에서 재확인하세요.