2026년 5월 현재 Google AI Studio와 Gemini API를 사용 중인 개발자들에게 한 통의 메일이 발송되고 있습니다. 핵심은 단 하나, 2026년 6월 19일까지 프로젝트 내 모든 무제한(unrestricted) API 키에 제한을 걸지 않으면 Gemini API 호출 자체가 거부된다는 내용입니다. 단순한 권고가 아니라 정책 변경이고, 마감일 이후에는 키가 살아 있어도 통하지 않습니다.
그런데 이 변화가 왜 지금 필요해졌을까요. 그동안 Google API 키는 사실상 "비밀이 아닌 식별자"로 취급되어 왔습니다. Google Maps JavaScript SDK 같은 클라이언트사이드 라이브러리는 키가 HTML 소스에 노출되는 것을 전제로 설계됐고, 도메인이나 패키지 단위 제한이 그 보안을 대신했습니다. 그러나 Gemini API가 등장하고, 같은 프로젝트의 "무제한" 키로도 LLM 호출이 가능해지면서 상황이 완전히 달라졌습니다. 한 번 유출된 Maps 키 하나가 수만 유로의 Gemini 청구서로 돌아오는 사고가 잇따라 보고됐습니다.
이 문서에서는 Google이 보낸 정책 메일이 정확히 어떤 의미인지, 무제한 키가 왜 LLM 시대에 위험한 자산이 됐는지, 그리고 6월 19일 이전에 어떤 순서로 점검하고 마이그레이션해야 하는지를 정리합니다. AI Studio 콘솔에서 클릭만으로 끝나는 작업도 있지만, 레거시 Firebase·Maps 키와 얽힌 프로젝트는 의외로 손이 많이 갑니다.
핵심 포인트: 2026년 6월 19일 이후 무제한 API 키는 Gemini API 호출이 차단됩니다. 단순한 권장이 아닌 강제 정책이며, 무제한 키를 "비밀 아닌 식별자"로 취급하던 과거의 운영 방식은 더 이상 통하지 않습니다. 마감 전 모든 키의 application restriction과 API restriction 두 축을 점검해야 합니다.
1. 정책 변경의 배경과 실제 피해 사례
Google Cloud의 API 키는 본래 두 종류의 제한을 걸 수 있습니다. 하나는 애플리케이션 제한(어디서 호출할 수 있는가, 즉 HTTP 리퍼러·Android 패키지·iOS 번들 ID·IP 주소)이고, 다른 하나는 API 제한(어떤 Google API를 호출할 수 있는가)입니다. 무제한 키란 두 제한이 모두 비어 있는 키, 즉 키 문자열만 알면 그 프로젝트에서 활성화된 모든 API를 어디서든 호출할 수 있는 키를 뜻합니다.
Maps나 YouTube Data API만 쓰던 시절에는 이런 무제한 키가 새어 나가도 피해가 제한적이었습니다. 일일 쿼터를 넘으면 차단되고, 단가 자체도 낮았습니다. 그러나 Gemini API는 다릅니다. 토큰 기반 과금이라 호출 한 번에 수십~수백 원이 빠져나가고, 자동화된 봇이 키를 발견하면 짧은 시간에 수만 달러가 누적됩니다.
1.1. 실제로 보고된 청구 사고
- 6만 7천 달러 폭탄 (2016년산 Firebase 키): 2016년에 Firebase가 자동 생성한 안드로이드 키가 무제한 상태로 남아 있었고, 2024년 5월 Google의 자동 제한 정책 적용 대상에서 누락됐습니다. 결과적으로 19시간 만에 Gemini API 호출로 약 67,000달러가 청구됐습니다.
- 5만 4천 유로 (Firebase 브라우저 키): 제한이 걸리지 않은 Firebase 브라우저 키가 13시간 동안 Gemini로 우회 호출되며 약 54,000유로의 비용이 발생했습니다. 80유로 예산 알림은 사후 통보 수준이었습니다.
- 3만 6천 8백 유로 (레거시 Maps 키): 제한이 없던 옛 Maps 키가 Gemini API 활성화 직후 악용돼 단기간에 막대한 청구로 이어진 사례입니다.
- 5만 5천 달러 (학생 GitHub 푸시 사고): 한 학생이 비공개 저장소라고 믿고 푸시한 Gemini 키가 단 한 번의 커밋 노출로 5만 달러대의 청구를 발생시켰습니다.
- Truffle Security 스캔 결과: 보안 회사 Truffle Security는 공개 웹사이트에서 약 3,000개의 활성 Google API 키를 발견했고, 상당수가 Gemini 호출에 그대로 사용 가능했다고 보고했습니다.
공통점은 명확합니다. "내 키는 Maps용이니까 새어 나가도 괜찮다"는 가정이 Gemini API 활성화 순간 무너진다는 것입니다. Google이 2024년 5월부터 신규 키에 자동 제한을 걸기 시작했지만, 그 이전에 만들어진 레거시 키와 자동화 도구가 만들어낸 키들이 사각지대로 남아 있었고, 이번 2026년 6월 19일 데드라인이 그 사각지대를 닫는 마지막 단계입니다.
1.2. 무제한 키와 제한 키의 구조 비교
| 구분 | 무제한 키 | 애플리케이션 제한 키 | API 제한 키 | 서비스 계정 바인딩 키 |
|---|---|---|---|---|
| 호출 위치 제한 | 없음 | 도메인·앱·IP 한정 | 없음(별도) | 없음(별도) |
| 호출 가능한 API | 활성화된 전체 | 활성화된 전체 | 지정한 API만 | 지정한 API만 |
| 유출 시 피해 | 매우 큼 | 보통 | 작음 | 매우 작음 |
| Gemini 차단 대상(2026.6.19) | 예 | API 제한 없으면 예 | 아니오 | 아니오 |
| 권장도 | 사용 금지 | 클라이언트 코드 한정 | 서버 코드 권장 | 운영 환경 최상위 권장 |
2. 6월 19일 전에 해야 하는 점검 순서
메일을 받았다면 가장 먼저 "내 프로젝트에 키가 몇 개 있고, 그 중 무제한 상태인 것이 무엇인지" 파악해야 합니다. 의외로 키 목록을 한 번도 들여다본 적 없는 개발자가 많고, Firebase·Maps·OAuth 자동 생성 키가 잠들어 있는 경우도 많습니다.
2.1. 1단계: 키 인벤토리 확인
- Google Cloud Console에서 해당 프로젝트의
API 및 서비스 → 사용자 인증 정보메뉴를 엽니다. - 키 목록에서 "제한사항" 컬럼이 없음 또는 무제한으로 표시된 키를 모두 표시합니다.
- 각 키의 생성일·생성자·최근 사용일을 함께 기록합니다. 1년 이상 미사용 키는 삭제 후보입니다.
- AI Studio에서 발급한 키는 별도로 AI Studio UI의 키 관리 화면에서도 확인합니다. AI Studio 발급 키는 기본적으로 Gemini API에만 묶여 있지만, 같은 프로젝트의 다른 무제한 키가 있으면 똑같이 위험합니다.
2.2. 2단계: 애플리케이션 제한 적용
키가 어디서 사용되는지에 따라 제한 유형을 다르게 선택합니다.
- 웹 클라이언트(JavaScript SDK): HTTP 리퍼러 제한을 사용해 본인 도메인만 허용. 와일드카드(
*.example.com)는 가능하지만 너무 넓게 잡지 않기. - Android 앱: 패키지 이름과 SHA-1 인증서 지문을 함께 등록. SHA-1 누락 시 우회가 쉬워집니다.
- iOS 앱: 번들 식별자 등록. 단, 모바일 앱은 디컴파일로 키 추출이 가능하므로 추가 방어가 필요합니다.
- 서버사이드 호출: IP 주소 제한 사용. 고정 IP가 없는 서버리스 환경이라면 다음 단계의 서비스 계정 바인딩이 더 안전합니다.
2.3. 3단계: API 제한 적용
- 키마다 "이 키는 어떤 Google API를 호출하는가"를 명시합니다. Gemini만 쓰는 키라면
Generative Language API하나만 체크합니다. - Maps와 Gemini를 같은 키로 쓰던 관행은 폐기합니다. 용도별로 키를 분리하세요.
- API 제한이 걸려 있고 그 목록에 Gemini가 없으면 유출돼도 Gemini로 청구되지 않습니다. 이번 정책의 핵심 방어선이 바로 이것입니다.
2.4. 4단계: 서비스 계정 바인딩 (운영 환경 권장)
Google은 이번 정책과 함께 서비스 계정 바인딩 키(service account-bound keys)라는 더 강력한 옵션을 제공합니다. API 제한이 Gemini APIs(generativelanguage.googleapis.com)로 설정돼 있으면 조직 정책 변경 없이 자동으로 바인딩이 허용됩니다.
- 키를 특정 서비스 계정에 묶으면, 그 서비스 계정의 IAM 권한 범위를 벗어나는 호출은 차단됩니다.
- 서비스 계정 자체에는 별도 IAM 역할 부여가 필요 없으며, 키 단독 사용 대비 노출 시 피해 범위가 극도로 줄어듭니다.
- GKE·Cloud Run 환경이라면 Workload Identity Federation을 함께 사용해 키 없는 인증을 구성하는 것이 이상적입니다.
3. 키 관리의 일반 원칙: 정책 그 이후
6월 19일 데드라인은 시작일 뿐입니다. API 키 관리는 일회성 설정이 아니라 수명주기 관점의 운영 과제입니다. OpenAI, Stripe, AWS 등 주요 서비스가 공통으로 권고하는 원칙을 Gemini 환경에 맞춰 정리하면 다음과 같습니다.
3.1. 코드와 분리하기
- 키를 절대 소스코드·공개 저장소·클라이언트 번들에 직접 포함하지 마세요. GitHub은 매년 수천만 건의 자격증명 유출을 탐지합니다.
- 환경변수,
.env파일(반드시.gitignore), 또는 Secret Manager(Google Secret Manager·AWS Secrets Manager·HashiCorp Vault)에 저장합니다. .env파일을 실수로 커밋했다면 키 회전 후 git 히스토리에서 제거합니다. 단순 삭제 커밋은 무효입니다.
3.2. 정기 로테이션
- 90일 또는 180일 주기 로테이션을 설정합니다. AWS Secrets Manager는 Lambda 함수 기반 자동 로테이션을 지원합니다.
- Google Cloud는 자동 로테이션 기능이 제한적이므로, 자체 스크립트로 신규 키 발급·배포·구 키 폐기 흐름을 만들어 둡니다.
- 인력 변동(퇴사·외주 종료) 시점에는 즉시 로테이션합니다.
3.3. 모니터링과 예산 알림
- Google Cloud Billing의 예산 알림을 여러 단계(50%·90%·100%·150%)로 설정합니다. 단일 알림은 사후 확인용에 불과합니다.
- Cloud Monitoring으로 분당 호출량 급증을 감지하는 알림을 추가합니다.
- Quota 화면에서 분당·일당 요청 한도를 명시적으로 설정해 사고 시 자동으로 멈추도록 합니다. 이것이 청구 폭탄을 막는 마지막 안전망입니다.
3.4. 팀원·환경별 분리
- 한 팀에서 한 키를 공유하지 않습니다. 팀원·환경(개발·스테이징·운영)별로 다른 키를 발급합니다.
- 어떤 키가 어디에 쓰이는지 키 이름과 라벨로 명시합니다.
web-prod-gemini,mobile-android-maps같은 명명 규칙이 사고 대응 속도를 결정합니다. - 사용 로그를 정기적으로 검토해 "누가 언제 어디서" 호출했는지 추적할 수 있게 만듭니다.
3.5. AI 에이전트와 키 위임의 새로운 위험
2025년 이후 새롭게 부상한 위험은 AI 에이전트에게 API 키를 직접 넘기는 패턴입니다. 사용자가 자신의 OpenAI·Gemini·Stripe 키를 AI 에이전트에 붙여 넣고 자동화 작업을 맡기는 경우가 늘었지만, 에이전트의 프롬프트 인젝션·로그 유출·과도한 권한 위임 등 새로운 공격 벡터가 보고되고 있습니다. Auth0 등은 OAuth 기반 위임 인증을 권고하고 있으며, 키 자체를 에이전트에 노출하지 않는 구조가 점차 표준이 될 가능성이 큽니다.
4. 마이그레이션 시나리오별 체크리스트
실제로 마감 전에 작업을 진행할 때 자주 겪는 시나리오를 유형별로 정리하면 다음과 같습니다.
| 시나리오 | 우선 조치 | 추가 권장 |
|---|---|---|
| AI Studio에서만 키 1개 사용 | AI Studio UI에서 신규 키 발급 후 교체 | 환경변수 분리, 예산 알림 설정 |
| Maps 키와 Gemini 키 공용 | 용도별 키 분리, 각 키에 API 제한 적용 | 서버사이드 호출은 IP 제한 추가 |
| Firebase 자동 생성 레거시 키 | 미사용 시 즉시 삭제, 사용 시 패키지·SHA-1 제한 적용 | Firebase 콘솔에서도 키 상태 확인 |
| GitHub 등 공개 저장소 푸시 이력 의심 | 즉시 키 회전, git 히스토리 정리 | Secret scanning 활성화 |
| 운영 서버에서 Gemini 호출 | 서비스 계정 바인딩 키로 전환 | Workload Identity Federation 검토 |
| 모바일 앱 내 키 임베드 | 백엔드 프록시로 호출 구조 변경 | 키를 클라이언트에서 제거 |
특히 모바일 앱 내 키 임베드는 애플리케이션 제한을 걸어도 디컴파일·MITM·런타임 후킹으로 우회가 가능하다는 점을 이해해야 합니다. 가능하다면 키를 앱에서 빼고, 자체 백엔드 서버를 거쳐 Gemini를 호출하는 프록시 구조로 바꾸는 것이 본질적인 해법입니다.
5. 마무리
위에서 살펴본 Gemini API 키 제한 의무화 정책의 핵심 내용을 정리하면 다음과 같습니다.
핵심 요약:
- 2026년 6월 19일 이후 무제한 API 키는 Gemini API 호출이 차단되며, 이는 권고가 아닌 강제 정책입니다.
- 무제한 키는 같은 프로젝트의 Gemini API를 통해 67,000달러·54,000유로 등 단기간에 막대한 청구를 유발한 실제 사례가 다수 존재합니다.
- API 키 제한은 "애플리케이션 제한"(어디서)과 "API 제한"(무엇을) 두 축으로 구성되며, 둘 다 적용해야 의미가 있습니다.
- AI Studio 신규 발급 키는 기본 제한이 걸려 있지만, 같은 프로젝트의 레거시 Firebase·Maps 키가 사각지대로 남아 있을 수 있습니다.
- 운영 환경에서는 서비스 계정 바인딩 키 또는 Workload Identity Federation으로 키 자체를 최소화하는 구조가 권장됩니다.
- 키 관리는 코드 분리, 정기 로테이션, 다단계 예산 알림, 환경별 키 분리를 포함한 수명주기 관점의 운영 과제입니다.
실무에서는 이번 주 안에 프로젝트별 키 인벤토리부터 작성하고, 미사용 키는 삭제, 사용 중인 키는 용도별로 분리해 애플리케이션 제한과 API 제한을 동시에 적용하는 순서로 진행하는 것이 안전합니다. 운영 트래픽이 큰 프로젝트라면 6월 19일 직전이 아니라 지금 마이그레이션을 끝내고, 마감 직전에는 모니터링만 강화하는 일정이 사고 위험을 가장 낮춥니다.
자주 묻는 질문
- AI Studio에서 새로 발급한 키도 6월 19일에 차단될 수 있나요?
AI Studio가 발급하는 신규 키는 기본적으로 Gemini API에만 사용 가능하도록 제한이 걸려 있어 차단 대상이 아닙니다. 다만 같은 Google Cloud 프로젝트 안에 다른 경로(Cloud Console·Firebase·Maps 등)로 만들어진 무제한 키가 있다면 그 키들이 차단 대상이 됩니다. 따라서 AI Studio UI뿐 아니라 Cloud Console의 사용자 인증 정보 메뉴에서도 전체 키 목록을 반드시 확인해야 합니다.
- 무제한 키를 그대로 두면 6월 19일 이후 정확히 어떤 일이 벌어지나요?
Gemini API(generativelanguage.googleapis.com) 엔드포인트가 해당 키로 들어오는 요청을 거부합니다. HTTP 401 또는 403 응답이 반환되며, 애플리케이션 측에서는 인증 실패로 표시됩니다. 다른 Google API(Maps, YouTube 등) 호출은 영향을 받지 않지만, Gemini를 사용하는 모든 기능이 즉시 멈추므로 운영 서비스라면 사전 마이그레이션이 필수입니다.
- 애플리케이션 제한과 API 제한 중 하나만 걸어도 되나요?
두 가지를 모두 적용하는 것이 표준입니다. 애플리케이션 제한은 "어디서 호출 가능한가"를, API 제한은 "무엇을 호출 가능한가"를 통제하므로 역할이 다릅니다. 특히 이번 정책은 API 제한 여부를 핵심 판단 기준으로 삼기 때문에, API 제한이 비어 있으면 애플리케이션 제한이 걸려 있어도 무제한 키로 분류될 수 있습니다. 가능하면 둘 다 적용하세요.
- Firebase가 자동으로 만든 키는 어디서 확인하나요?
Firebase 콘솔의 프로젝트 설정과 Google Cloud Console의 사용자 인증 정보 메뉴 두 곳 모두에서 확인할 수 있습니다. Firebase는 안드로이드·iOS·웹용 키를 프로젝트 생성 시 자동으로 발급하는 경우가 많고, 2024년 5월 이전에 생성된 키는 자동 제한 정책의 대상에서 제외돼 있을 수 있습니다. 사용하지 않는 레거시 키는 즉시 삭제하고, 사용 중인 키는 패키지 이름과 SHA-1 지문을 추가해 제한을 강화하세요.
- 키가 이미 GitHub에 노출된 것 같으면 어떻게 해야 하나요?
가장 먼저 해당 키를 즉시 폐기하고 신규 키로 회전(rotate)합니다. 그 다음 Google Cloud Billing 화면에서 비정상 청구 내역을 확인하고, 의심 사례가 있으면 Google Cloud 지원에 문의해 청구 면제 가능성을 타진할 수 있습니다. git 히스토리에서 키를 삭제하더라도 이미 누군가가 복제했을 가능성이 있으므로 회전이 우선이며, 이후 GitHub Secret Scanning을 활성화해 재발을 방지합니다.
- 서비스 계정 바인딩 키는 일반 API 키와 어떻게 다른가요?
일반 API 키는 키 문자열만 알면 누구나 호출할 수 있는 반면, 서비스 계정 바인딩 키는 특정 서비스 계정의 IAM 권한 범위 안에서만 동작합니다. 키가 유출되더라도 해당 서비스 계정에 부여된 권한 이상은 사용할 수 없으므로 피해 범위가 크게 줄어듭니다. API 제한이 Gemini APIs로 설정돼 있으면 조직 정책 변경 없이 자동으로 바인딩이 허용되며, 운영 환경에서 권장되는 가장 안전한 구성입니다.
- 예산 알림만 잘 걸어두면 무제한 키를 써도 괜찮지 않나요?
예산 알림은 사후 통보 수단에 불과합니다. 실제 사고 사례 중에는 80유로 알림이 울린 시점에 이미 5만 유로 이상이 청구된 경우가 있고, 알림과 실제 차단 사이에 시간차가 큽니다. 청구 자체를 막으려면 키 단계의 제한, Quota 한도 설정, IP·도메인 제한이 함께 작동해야 합니다. 알림은 마지막 안전망일 뿐 1차 방어선이 될 수 없습니다.