Google Gemini API 키 보안 논란: 23분 지연과 과금 폭탄을 막는 법
2026년 5월 Google Gemini API key security 23 minutes 보도가 AI 앱 운영자에게 남긴 실무 점검표
Gemini API 키 보안 논란, 왜 지금 봐야 하나
Gemini API 키 보안 논란은 모델 성능보다 운영 리스크에 가깝습니다. 키가 유출됐을 때 과금, quota, private data 접근이 어디까지 번지는지 확인해야 하며, 한국 시간 2026년 5월 25일 기준 Google Gemini API key security 23 minutes May 2026 보도는 그 점을 다시 꺼내 놓았습니다.
TechCrunch는 2026년 5월 24일 PDT에 Google Cloud COO 인터뷰를 싣고, 기업 AI 보안·거버넌스·감사 가능성을 초기부터 요구해야 한다는 메시지를 전했습니다. 같은 기사 안에서 Gemini API 키 악용, 과금 피해, 삭제 지연 논란도 함께 다뤘습니다. 한국 시간으로는 2026년 5월 25일 당일 뉴스입니다.
제가 먼저 보게 되는 대목은 모델 이름이 아니라 키의 위치입니다. AI Studio에서 만든 키가 있고, Cloud Console Credentials에만 보이는 키가 있으며, 예전 데모나 프론트엔드 번들에 남은 키도 있을 수 있습니다. 작은 팀일수록 이 목록이 문서화되어 있지 않은 경우가 많습니다.
그래서 이번 이슈는 사건 요약보다 운영 점검표로 읽는 편이 낫습니다. 보도된 사례, Google 공식 문서로 확인되는 기준, 오늘 바로 손볼 수 있는 항목을 나눠 보면 과장과 실무 대응이 조금 분명해집니다.
무엇이 바뀌었나: 공개 API 키가 AI 과금 리스크가 된 이유
예전에는 일부 Google API 키가 공개 client 식별자처럼 쓰였습니다. 하지만 Gemini가 활성화된 project에서는 같은 키가 quota, billing, private data 접근과 연결될 수 있어, '키가 노출됐다'는 문제가 곧 AI 비용과 데이터 접근 문제로 번집니다.
Truffle Security의 분석은 여기서 출발합니다. Google API 키 형식은 여러 Google 서비스에서 오래 쓰였고, Maps 같은 용도에서는 브라우저 코드 안에 들어가는 사례도 많았습니다. 문제는 Gemini API가 같은 Cloud project의 과금과 민감한 데이터 접근 가능성에 연결될 때입니다. 공개되어도 된다고 여겼던 습관이 더 이상 같은 의미를 갖지 않습니다.
Google AI for Developers 문서도 production web 또는 mobile app에서 Gemini API 키를 client-side에 직접 노출하지 말라고 안내합니다. 서버가 Gemini API를 호출하고, 앱은 자체 backend를 거치도록 설계하는 방식이 기본에 가깝습니다.
한국 사용자 입장에서는 초기 프로토타입이 특히 애매합니다. AI Studio에서 빠르게 테스트하고, billing을 붙이고, 데모 페이지에 키를 넣은 뒤 그대로 방치하는 흐름이 생기기 쉽기 때문입니다. 편의상 남겨 둔 한 줄이 과금과 사고 대응 비용으로 돌아올 수 있다는 점이 이번 Google Gemini API key security 23 minutes May 2026 이슈의 실무적 의미입니다.
타임라인: 2025년 보고부터 2026년 5월 보도까지
날짜를 놓고 보면 이 논란은 하루짜리 해프닝이 아닙니다. 2025년 취약점 보고, 2026년 2월 연구 공개, 3월 Google 비용 통제 발표, 5월 과금 피해·삭제 지연 보도가 이어졌고, 각 단계의 출처 성격도 다릅니다.
| 날짜 | 무슨 일이 있었나 | 읽을 때의 기준 |
|---|---|---|
| 2025-11-21 | Truffle Security가 Google VDP에 Google API 키와 Gemini 권한 확장 문제를 보고했다고 공개 | 보안 연구사의 보고 경위 |
| 2026-02-25 | Truffle Security가 Google API 키와 Gemini 접근·과금 문제를 공개 분석 | 구조적 배경 설명 |
| 2026-03-16 | Google이 Gemini API 비용 통제 기능과 spend cap을 공식 발표 | 공식 제품 기능과 한계 |
| 2026-05-15 | The Register가 Gemini API 무단 사용 과금 피해와 일부 환불 사례를 보도 | 보도된 사례로 한정 |
| 2026-05-21 | Aikido가 Google API 키 삭제 후 최대 약 23분 인증 가능성을 주장 | 테스트 관측값, 일반화 금지 |
| 2026-05-24 PDT | TechCrunch가 Google Cloud AI 보안 메시지와 Gemini API 키 논란을 연결 보도 | 당일 뉴스 맥락 |
여기서 볼 부분은 공식 문서와 보안 연구의 주장 수준입니다. spend cap과 API key 보안 안내는 Google이 직접 설명한 내용입니다. 반면 삭제 후 최대 약 23분 인증은 Aikido가 테스트로 관측했다고 밝힌 내용입니다. 모든 키에 항상 같은 시간이 적용된다는 뜻은 아닙니다.
> 날짜를 따라 읽으면, 질문은 하나로 좁혀집니다. 한 번 유출된 키를 얼마나 빨리 끊고, 그 사이 비용과 데이터 접근을 어떻게 줄일 것인가.
왜 중요한가: 23분은 사고 대응에서 긴 시간이다
Aikido가 관측한 최대 약 23분은 모든 키에 항상 적용되는 보편값이 아니라 테스트에서 나온 최대 관측값입니다. 다만 키 유출 상황에서는 삭제 직후에도 인증 성공 가능성을 가정하고 모니터링해야 한다는 점에서 운영상 의미가 큽니다.
Aikido는 키 생성·삭제 후 초당 여러 차례 인증 요청을 보내 마지막 성공 시점을 측정했다고 설명했습니다. The Register도 이 테스트 방법을 보도했습니다. 숫자만 떼어내 'Google API 키는 삭제 후 23분간 무조건 작동한다'고 쓰면 틀린 설명입니다.
실제로 확인할 부분은 사고 대응 절차입니다. 키가 유출됐다고 판단해 삭제 버튼을 눌렀다면, 그 시점이 사고 종료가 아닙니다. 최소한 삭제 시각, 마지막 성공 요청 시각, 의심 traffic window, project ID, billing account, spend cap과 budget 설정을 기록해야 합니다.
AI 서비스에서 23분은 짧지 않습니다. 자동화된 호출이 붙어 있으면 몇 분 안에도 토큰 사용량과 비용이 늘고, 파일 업로드나 캐시 대화처럼 private data가 엮인 project라면 접근 범위도 확인해야 합니다. 그래서 Google Gemini API key security 23 minutes May 2026 논란은 보안 뉴스로만 넘기기보다 운영 runbook에 넣어 둘 사안입니다.
과금 폭탄은 spend cap 하나로 끝나지 않는다
Gemini API spend cap은 필요한 장치지만 혼자서는 부족합니다. Google 공식 설명상 적용 지연이 있을 수 있고, Google Cloud budget alert는 자동 차단이 아니라 알림이므로 API restriction, quota, Pub/Sub 자동화, 수동 대응 runbook을 같이 봐야 합니다.
Google은 2026년 3월 Gemini API 비용 통제 강화를 발표하면서 project-level monthly spend cap, 비용·사용량 대시보드, rate limit dashboard 개선을 설명했습니다. 다만 공식 글은 spend cap에도 약 10분 지연이 있을 수 있고, 그 사이 초과분은 사용자 책임이라고 안내합니다.
Google Cloud budget alert도 이름 때문에 오해하기 쉽습니다. budget은 비용을 자동으로 막는 cap이 아니라 threshold를 넘으면 알림을 보내는 기능입니다. budget alert만 걸어 두고 '이제 과금 폭탄은 막혔다'고 생각하면 실제 사고 때 대응이 늦습니다.
| 장치 | 막는 것 | 못 막는 것 |
|---|---|---|
| API key restriction | 특정 키가 호출할 수 있는 API 범위 제한 | 이미 허용된 API 안의 악용 전체 |
| Gemini API spend cap | project-level 월간 비용 상한에 가까운 제어 | 공식 설명상 지연 중 발생한 초과분 |
| Google Cloud budget alert | threshold 초과 알림과 Pub/Sub 연동 출발점 | 사용량 자동 차단 그 자체 |
| quota/rate limit | 호출량 급증 완화 | 데이터 접근 권한 설계 오류 |
저라면 작은 AI 앱이라도 spend cap, budget alert, quota를 각각 다른 안전장치로 봅니다. 하나가 실패했을 때 다른 장치가 시간을 벌어야 하기 때문입니다. 이번 이슈는 보안팀만의 문제가 아니라 FinOps, 온콜, 고객지원 기록까지 이어지는 운영 문제에 가깝습니다.
오늘 점검할 순서: 키, 프로젝트, 예산, 로그
한국 개발자라면 Google AI Studio와 Cloud Console Credentials를 나란히 열어 모든 project의 API key를 먼저 맞춰 보는 편이 좋습니다. 그다음 Generative Language API가 켜진 project, 공개 client key, Gemini 전용 key, 과금 설정을 분리해 확인해야 합니다.
오늘 바로 보는 순서는 길지 않습니다. 다만 한 화면에서 끝나지 않는다는 점을 염두에 둬야 합니다.
1. Google AI Studio API Keys 화면에서 Gemini API 키 목록을 확인합니다.
2. Cloud Console Credentials에서 AI Studio에 보이지 않는 project의 API key까지 확인합니다.
3. APIs & Services의 Enabled APIs & Services에서 Generative Language API 활성화 여부를 봅니다.
4. 프론트엔드 번들, public repository, CI logs, `.env.example`에 `AIza` 형식 키가 남아 있는지 secret scanner로 확인합니다.
5. Maps/Firebase 같은 공개 client 용도 키와 Gemini private data 접근 키를 분리합니다.
6. production Gemini 호출은 backend proxy를 거치고, key restriction과 quota를 적용합니다.
7. spend cap, budget alert, Pub/Sub notification, 담당자 호출 절차를 한 문서에 묶습니다.
중요한 것은 삭제보다 구조입니다. 유출된 키를 삭제하는 일은 필요하지만, 같은 패턴으로 새 키를 다시 배포하면 사고는 반복됩니다. 키 회전은 새 키 생성, 동일 restriction 적용, 서비스 교체, 정상 동작 확인, 이전 키 삭제 순서로 진행해야 합니다.
2026년 5월 27일 KST 현재 Google 문서는 2026년 6월 19일부터 Gemini API에서 unrestricted traffic keys 지원을 중단할 예정이라고 안내합니다. 아직 미래 일정이라 바뀔 가능성은 남아 있습니다. 그래도 unrestricted key를 운영에 남겨 둘 이유는 더 줄었습니다.
도입 시뮬레이션: 첫 테스트부터 운영 모델까지
이 글은 특정 GitHub 저장소 설치기가 아닙니다. 다만 실무 적용은 작은 Google Cloud test project에서 Gemini API key, Generative Language API restriction, spend cap, budget alert를 검증한 뒤 production project로 옮기는 흐름이 안전합니다.
가장 작은 첫 테스트는 새 Cloud project를 하나 만들고, Gemini API 전용 키를 발급한 뒤, Generative Language API만 허용하도록 restriction을 걸어 backend proxy에서 짧은 요청 한 번을 보내는 방식입니다. 이후 Google AI Studio usage dashboard와 Cloud Billing 쪽 비용 표시가 어떻게 잡히는지 확인합니다.
운영에서는 Gemini API 키를 앱에 직접 넣지 않습니다. backend proxy 또는 serverless endpoint가 Gemini를 호출하고, client는 자체 인증을 거친 뒤 backend만 호출하게 둡니다. 로그에는 원문 프롬프트나 민감 데이터를 그대로 남기지 말고, key ID, request count, status code, model name, cost window처럼 사고 대응에 필요한 메타데이터를 남기는 편이 낫습니다.
함께 쓰기 좋은 도구는 TruffleHog 같은 secret scanner, Google Cloud Budget API와 Pub/Sub notification, Google AI Studio Spend dashboard입니다. GitHub Actions나 CI를 쓰는 팀이라면 PR 단계에서 `.env`, 빌드 산출물, public bundle에 Google API key가 들어가지 않았는지 자동 점검을 붙이는 방식이 현실적입니다. 반대로 backend proxy를 만들 권한이 없거나 billing이 연결된 production project에서 바로 실험해야 하는 상황이라면, 이 순서로 테스트를 진행하지 않는 편이 낫습니다.
오해하면 안 되는 것들
이 사건을 'Gemini가 해킹됐다'고 쓰면 부정확합니다. 쟁점은 API 키 권한 모델, 기존 키의 Gemini 접근 가능성, 삭제 propagation, 과금·관측성·운영 대응 절차입니다.
삭제된 키가 늘 같은 시간 동안 작동한다고 단정하면 안 됩니다. Aikido가 공개한 것은 테스트에서 나온 최대 관측값입니다. 다만 운영자는 삭제 후에도 일정 시간 요청이 통과할 수 있다는 보수적 가정을 두는 편이 안전합니다.
The Register의 환불 보도도 Google의 보편 환불 정책처럼 읽으면 안 됩니다. 일부 사례가 보도됐다는 사실과 모든 고객에게 같은 결과가 보장된다는 주장은 다릅니다.
또 하나, spend cap과 budget alert를 같은 것으로 보면 안 됩니다. 하나는 Gemini API 비용 제어 장치이고, 다른 하나는 Cloud Billing 알림 장치입니다. 둘 다 필요하지만, 둘 다 단독으로 사고 대응 전체를 대신하지는 않습니다.
제가 보기에는 이번 Google Gemini API key security 23 minutes May 2026 이슈의 교훈은 '더 강한 모델을 쓰지 말자'가 아닙니다. AI 기능을 제품에 넣는 순간, API 키와 과금이 제품 안정성의 일부가 된다는 점을 인정하자는 이야기입니다.
자주 묻는 질문
Q. Gemini API 키가 유출되면 어떤 과금 리스크가 생기나?
A. Google 공식 문서는 유출된 Gemini API 키로 다른 사람이 project quota를 쓰고, billing이 켜진 경우 비용을 발생시킬 수 있다고 안내합니다. 파일 같은 private data 접근 위험도 함께 언급되므로 단순 사용량 증가 문제로만 보면 안 됩니다.
Q. Google API 키 삭제 후 최대 23분간 요청이 통과했다는 연구는 무엇을 의미하나?
A. Aikido의 테스트에서 관측된 최대값이라는 뜻이지 모든 키가 항상 23분간 작동한다는 뜻은 아닙니다. 실무적으로는 키 삭제 직후에도 최소 30분가량 usage, billing, quota, log를 확인하는 대응 절차가 필요하다는 의미로 읽는 편이 안전합니다.
Q. Gemini API spend cap은 과금 폭탄을 완전히 막아 주나?
A. 완전한 hard stop으로 단정하면 안 됩니다. Google 공식 발표는 spend cap에 약 10분 지연이 있을 수 있고, 그 사이 발생한 overage는 사용자 책임이라고 설명합니다. API restriction, quota, budget alert, 담당자 호출 절차를 함께 써야 합니다.
Q. Google Cloud budget alert와 spend cap은 무엇이 다른가?
A. budget alert는 threshold를 넘을 때 알림을 보내는 Cloud Billing 기능이고, 사용량이나 과금을 자동 차단하는 cap이 아닙니다. Gemini API spend cap은 Gemini API 비용 제어 장치지만 지연 가능성이 있으므로 두 기능을 분리해 이해해야 합니다.
Q. 기존 Google Maps나 Firebase용 API 키도 Gemini 리스크가 될 수 있나?
A. 같은 Cloud project에서 Gemini 관련 API와 billing이 연결되어 있고 키 제한이 느슨하다면 점검 대상입니다. 특히 공개 client key와 Gemini private data 접근 키를 같은 key나 같은 project 운영 습관으로 묶어 둔 경우 분리가 필요합니다.
Q. 2026-06-19 unrestricted traffic key 지원 중단 예정은 무엇을 준비하라는 뜻인가?
A. 2026년 5월 27일 KST 현재 Google 문서상 예정 일정이므로 바뀔 수는 있습니다. 그래도 unrestricted key를 찾아 API restriction을 적용하고, Gemini가 필요 없는 key에서는 Generative Language API 접근을 제거하는 준비가 필요합니다.
함께 읽으면 좋은 글
참조 링크
- Everyone is navigating AI security in real time -- even Google — Google Cloud COO의 AI 보안 메시지와 Gemini API 키 과금·삭제 지연 논란을 연결한 당일 뉴스 원문입니다.
- Google API keys keep working after you delete them — 삭제된 Google API 키가 일부 테스트에서 최대 약 23분간 인증됐다는 주장의 원출처입니다.
- Threat hunters find Google API keys still usable 23 minutes after deletion — Aikido 테스트 방식과 삭제 지연 논란을 보도한 보안·개발자 매체 기사입니다.
- Google reimburses Register sources who were victims of API fraud — Gemini API 무단 사용 과금 피해와 일부 환불 사례를 확인하는 배경 보도입니다.
- Using Gemini API keys — Gemini API 키 보안, 서버 측 호출 권장, API key restriction, unrestricted traffic key 예정 변경을 확인하는 공식 문서입니다.
- Giving you more transparency and control over your Gemini API costs — Gemini API spend cap, 비용·사용량 대시보드, 지연 가능성을 확인하는 Google 공식 발표입니다.
- Create, edit, or delete budgets and budget alerts — Google Cloud budget alert가 자동 과금 차단이 아니라 알림 기능이라는 점을 확인하는 공식 문서입니다.
- Creating and managing API keys — Cloud Console에서 API key 생성, 제한, 삭제, 상태 확인을 관리하는 공식 문서입니다.
- Google API Keys Weren't Secrets. But then Gemini Changed the Rules. — 기존 공개 Google API 키 관행과 Gemini 이후 권한·과금 리스크 변화를 설명하는 보안 연구입니다.