Google조차 따라잡을 수 없는 ─ AI 시대의 보안은 "초 단위"의 싸움이 되었다

Google조차 "달리면서 지키는" 시대에 들어섰다

AI는 기업의 생산성을 높이는 도구일 뿐만 아니라, 보안 담당자에게는 새로운 공격 면 자체가 되고 있다. 생성 AI, 사내 에이전트, 학습 데이터, 프롬프트, 외부 SaaS, 멀티클라우드 환경. 과거에는 네트워크 경계나 단말, 서버, ID 관리를 중심으로 생각하면 되었던 방어의 대상이 이제는 "AI가 닿는 모든 것"으로 확장되고 있다.

TechCrunch가 보도한 Google Cloud COO, Francis de Souza 씨의 발언은 그 변화를 상징하고 있다. 그는 기업이 AI를 도입한다면, 보안은 나중에 덧붙이는 것이 아니라 처음부터 플랫폼 설계에 포함시켜야 한다고 강조했다. 직원이 마음대로 외부의 AI 도구를 사용하는 "섀도우 AI", 여러 클라우드에 걸친 데이터 관리, 감사 가능성, 거버넌스. 이러한 것들은 이미 정보 시스템 부서만의 과제가 아니라, 경영층이나 이사회가 다루어야 할 리스크가 되고 있다.

특히 중요한 것은 AI 도입이 "편리한 새로운 기능의 추가"로 끝나지 않는다는 점이다. AI 에이전트가 사내 시스템을 가로질러 작동하게 되면, 사람이 잊고 있던 오래된 데이터 저장소, 업데이트되지 않은 접근 권한, 방치된 SharePoint나 오래된 업무 파일까지 파헤쳐질 가능성이 있다. 지금까지 "아무도 찾지 않아서 문제가 되지 않았던" 데이터가 AI에 의해 한꺼번에 가시화된다. 즉, AI는 공격자뿐만 아니라 기업 내부의 "과거 관리 부실"까지도 고속으로 발견해버린다.

공격은 "시간"이 아니라 "초"로 진행된다

de Souza 씨는 침해에서 다음 공격 단계로 진행되기까지의 평균 시간이 과거의 몇 시간 단위에서 초 단위로 줄어들고 있다고 설명하고 있다. 이는 보안 담당자에게 극히 무거운 의미를 가진다. 사람이 경고를 보고 상황을 확인하고 관계자를 모아 판단하고 수작업으로 차단하는 동안, 공격은 이미 다음 단계로 진행되고 있다.

이 흐름 속에서 Google Cloud 측이 제시하는 답은 "AI 네이티브 방어"이다. 사람이 직접 모든 것을 조작하는 것이 아니라, AI 에이전트가 감시, 방어, 초기 대응을 하고, 사람은 그것을 감독한다. 공격이 기계의 속도로 진행된다면, 방어도 기계의 속도로 움직일 수밖에 없다는 발상이다.

이 생각 자체는 합리적이다. 그러나 동시에 거기에는 큰 모순도 있다. AI를 사용하여 지키려면 그 AI 자체가 안전해야 한다. AI가 참조하는 데이터, AI를 호출하는 API, AI가 사용하는 인증 정보, AI의 이용 요금을 관리하는 과금 시스템. 그것들의 기반에 구멍이 있으면 AI 방어는 방어가 아니라 새로운 리스크가 된다.

Gemini API 키 문제가 보여준 "오래된 전제"의 붕괴

이번 TechCrunch 기사가 흥미로운 것은 Google Cloud의 보안 제언을 소개할 뿐만 아니라, Google 자체가 직면하고 있는 문제에도 언급하고 있는 점이다. 특히 주목받은 것은 Gemini API를 둘러싼 일련의 고액 청구 문제이다.

문제의 중심에 있는 것은 Google Cloud의 API 키의 취급이다. 오랫동안 Google Maps나 Firebase 등에서는 API 키가 클라이언트 측 코드에 내장되는 것이 드물지 않았다. 개발자에게는 이것이 반드시 "비밀번호를 공개하고 있다"는 감각은 아니었다. 서비스 식별이나 과금을 위한 공개 가능한 키로 취급되어 온 면이 있다.

그러나 Gemini API와 같은 고액의 AI 추론 서비스가 같은 프로젝트 내에서 활성화되면, 기존의 API 키가 AI 요청에도 사용할 수 있는 상태가 될 수 있다. 만약 그 키가 오래된 웹사이트의 JavaScript나 공개 리포지토리, 과거의 설정에 남아 있다면, 공격자는 그것을 찾아 Gemini나 이미지·비디오 생성 모델에 대량의 요청을 던져 개발자의 청구 계정에 거액의 비용을 발생시킬 수 있다.

이는 단순히 "개발자가 키 관리를 소홀히 했다"는 이야기로 끝날 수 없다. 왜냐하면 일부 개발자는 당시의 문서나 일반적인 관행에 따라 키를 사용하고 있었기 때문이다. 공개해도 좋다고 생각되었던 식별자가 나중에 고액 AI 서비스의 인증에 가까운 역할을 갖게 되었다. 여기에 AI 시대의 보안의 어려움이 있다. 어제까지 안전했던 설계가 오늘의 새로운 기능 추가로 위험한 설계로 변하는 것이다.

"상한"일 줄 알았던 것이 상한이 아니라는 불신

더욱이 개발자의 불신을 강화한 것은 이용 상한이나 과금 상한에 관한 문제이다. The Register의 보도에서는 Google Cloud의 개발자가 부정한 API 이용으로 인해 수천 달러에서 수만 달러 규모의 청구를 받은 사례가 소개되었다. 그중에는 월 수십 달러 정도였던 이용이 단시간에 1만 달러를 넘게 뛰어오른 경우나, 250달러 정도의 상한을 설정했다고 생각했지만, 계정 이력에 따라 더 높은 이용 한도로 자동으로 상향 조정된 경우도 있다.

Google 측의 논리는 서비스 정지를 피하고 성장하는 고객이 원활하게 이용을 확대할 수 있도록 한다는 것이다. 확실히 급격히 트래픽이 늘어나는 정당한 서비스에 있어서는 경직된 상한은 장애로 이어질 수 있다. AI 앱이 급성장하는 시대에는 이용 한도의 자동 확대는 개발자 경험을 좋게 하는 면도 있다.

그러나 부정 이용이 발생한 순간, 그 설계는 반대 방향으로 작용한다. 공격자에게는 훔친 키로 더 많이 사용할 수 있는 여지가 넓어진다. 이용자에게는 "상한을 설정해 두었는데도 멈추지 않는다"는 감각이 된다. SNS에서 가장 강하게 나타난 반응도 이 점에 집중되어 있었다. 개발자들은 "경고가 아니라, 정말로 멈추는 상한이 필요하다"고 호소하고 있다.

Reddit에서 확산된 분노와 공포

Reddit의 r/googlecloud에서는 Gemini API나 Google Cloud의 고액 청구에 관한 게시물이 잇따르고 있다. 한 게시자는 B2B SaaS를 운영하고 있으며, 보통은 월 50달러 정도였던 Google Cloud 청구가 Veo 3나 Gemini 이미지 출력 토큰으로 인해 1만 달러를 넘게 뛰어올랐다고 설명했다. 본인은 그것들을 제품에서 사용하지 않았으며, Google의 지원에 부정 이용을 호소했지만, 처음에는 "부정의 증거를 확인할 수 없다"고 했다.

다른 게시물에서는 오래된 Google Maps용 API 키가 Gemini API를 활성화한 후에 악용되어 약 3만6800유로의 청구가 발생했다고 한다. 댓글란에서는 "이 문제는 이미 보도되었을 텐데, 아직 행동이 바뀌지 않았나"라는 놀라움의 목소리와 "Google Cloud Console이 무서워졌다. 수만 달러를 발생시키는 키를 가지고 있는 것은 신뢰할 수 없다"는 목소리가 보였다.

일본의 소규모 기업을 자칭하는 게시자도 Gemini API의 부정 이용으로 약 12만8000달러 상당의 청구 리스크에 직면하고, 파산 가능성까지 언급하고 있었다. 댓글에서는 Google이 임의의 하드 스톱, 즉 일정 금액을 초과하면 확실히 프로젝트나 API를 멈추는 시스템을 제공해야 한다는 의견이 두드러졌다. AI 코딩 도구의 보급으로 Google Cloud를 다루는 개발자가 늘어날수록 "모두가 완벽하게 키를 지킬 수 있다"는 전제는 현실적이지 않다는 지적이다.

Reddit의 반응에는 분노뿐만 아니라, 실무적인 회피책도 포함되어 있었다. API 키를 사용하지 않고, 서비스 계정이나 더 제한된 인증 방식으로 전환하기, Gemini API를 조직 레벨에서 비활성화하기, 공개 서비스와 AI 이용을 별도 프로젝트로 나누기, API 제한을 반드시 설정하기 등의 제안이다. 즉, 커뮤니티는 Google의 대응을 비판하면서도 자위책을 공유하는 장이 되고 있었다.

Hacker News에서는 "설계 사상"에 대한 비판이 강하다

Hacker News에서는 더 설계 사상에 깊이 들어간 논의가 두드러졌다. Truffle Security의 조사를 둘러싼 스레드에서는 Google API 키가 오랫동안 "공개해도 좋은 식별자"에 가까운 취급을 받아왔는데, Gemini에 의해 실질적으로 고액의 AI 이용이나 데이터 접근의 열쇠가 된 점이 문제시되었다.

어떤 댓글에서는 API 키마다 10달러, 100달러와 같은 명확한 지출 상한을 둘 수 있어야 한다는 비교가 이루어졌다. OpenAI나 OpenRouter 등에서는 키 단위·계정 단위로 지출 관리를 쉽게 할 수 있다는 시각도 있으며, Google Cloud의 청구 경고는 지연이 있어 실제 방파제가 되지 않는다는 불만이 나타났다.

또한 "이것은 사용자 이름을 비밀번호로 사용하는 것과 같다"는 비판도 확산되었다. 물론 모든 책임을 Google에 떠넘기는 것은 단순화가 지나치다는 반론도 있다. Gemini API는 기본적으로 모든 프로젝트에 활성화되는 것이 아니라, 프로젝트 소유자가 활성화할 필요가 있다. 따라서 프로젝트를 분리하고, 키를 제한하고, 최소 권한을 지켜야 한다는 의견도 강하다.

그러나 논의 전체로서는 AI에 의해 "오래된 클라우드 관행"이 위험해졌다는 시각이 강하다. 공개 전제의 키, 고액 AI 추론, 지연되는 과금 데이터, 자동 확장되는 이용 한도. 개별적으로는 설명 가능한 사양이라도, 결합되면 소규모 개발자에게 치명적인 리스크가 된다.

키를 삭제해도 끝나지 않는 "23분"의 문제

더욱이 Aikido Security의 조사는 또 다른 불안을 던졌다. 동사의 검증에 따르면 Google API 키를 삭제해도 최대 약 23분 동안 일부 요청이 인증될 가능성이 있다고 한다. 대규모 분산 시스템에서는 설정 변경이 모든 서버에 전파되기까지 시간이 걸리는 것은 드물지 않다. 그러나 인증 정보의 실효에 관해서는 그 지연이 그대로 공격 시간이 된다.

만약 공격자가 유출된 키를 가지고 있고, 이용자가 서둘러 키를 삭제했다 하더라도, 그 후 한동안 대량 요청을 계속 보낼 수 있는 가능성이 있다. Gemini API가 유효하다면 요금을 발생시킬 뿐만 아니라, 업로드된 파일이나 캐시된 대화 내용에 대한 접근 리스크도 문제가 된다.

이 점은 AI 보안의 핵심에 가깝다. 기존의 클라우드 리소스라면 몇 분의 지연은 허용되는 장면도 있었을지 모른다. 그러나 AI 모델에 대한 요청은 고가이며, 데이터도 기밀성이 높다. 몇 분이면 공격자는 방대한 추론을 실행할 수 있다. AI 시대에는 인증의 "최종적으로 일치한다"는 발상은 비용 면에서도 데이터 보호 면에서도 위험하다.

Google의 제언은 옳다. 그렇기 때문에 물어야 한다

여기서 중요한 것은 Google Cloud COO의 제언 자체는 틀리지 않았다는 것이다. AI 전략에는 데이터 전략과 보안 전략이 필수적이며, 섀도우 AI를 방치해서는 안 된다. 멀티클라우드, SaaS, 외부 파트너, 사내 에이전트를 가로질러 일관된 보안 자세를 가져야 한다. 공격이 기계의 속도가 된 이상, 방어에도 AI를 활용할 필요가 있다.

문제는 그 올바른 제언을 실행하기 위한 기반을 플랫폼 사업자 자신이 어디까지 안전하게 제공할 수 있는가이다. 기업에 "보안을 나중에 덧붙이지 말라"고 말한다면, 클라우드 측도 "AI 기능을 나중에 덧붙인 결과, 기존의 인증·과금 설계가 위험해지는" 사태를 피해야 한다.

이번 소동은 Google만의 문제가 아니다. 모든 클라우드 사업자, AI 플랫폼, SaaS 기업에 공통되는 경고다. AI 기능을 기존 서비스에 연이어 통합할 때, 과거의 설계 전제는 반드시 재검토해야 한다. 공개해도 좋은 키, 내부에서만 사용하는 키, 과금 상한, 데이터 접근 범위, 실효 처리, 감사 로그, 지원 체제. AI 이전의 상식을 그대로 유용하면 어디선가 파탄한다.

기업과 개발자가 지금 당장 재검토해야 할 것

이 문제로부터 얻을 수 있는 실무적인 교훈은 명확하다. 첫째, AI를 활성화하는 프로젝트와 공개 프론트엔드나 Maps, Firebase 등에서 사용하는 프로젝트를 분리할 것. 둘째, 모든 API 키에 API 제한과 애플리케이션 제한을 설정하고, 불필요한 API를 비활성화할 것. 셋째, 단순한 청구 경고가 아니라 실제로 중지하는 지출 상한이나 쿼터를 확인할 것. 넷째, 오래된 웹사이트, 오래된 리포지토리, 오래된 모바일 앱에 남아 있는 키를 재고할 것. 다섯째, AI 이용에서는 API 키보다 서비스 계정이나 OAuth, 최소 권한의 인증 설계를 우선할 것.

그리고 경영층은 AI 도입을 "현장의 편리 도구"가 아니라, 재무 리스크와 정보 유출 리스크를 수반하는 인프라 변경으로 다룰 필요가 있다. 하나의 키 유출이 수천만 엔 규모의 청구나 기밀 데이터 유출로 이어진다면, 그것은 CISO나 개발 팀뿐만 아니라, CFO, 법무, 경영 회의의 테마이다.

AI 보안의 진정한 과제는 "속도 차이"가 아니라 "책임의 설계"

AI 시대의 보안은 확실히 실시간화하고 있다. 공격은 빠르고, 방어도 빠르지 않으면 안 된다. 그러나 진정한 과제는 속도만이 아니다. 누가 리스크를 지는가, 누가 멈출 권한을 가지는가, 무엇이 기본적으로 안전한가, 장애를 피하는 설계와 부정 이용을 막는 설계 중 어느 것을 우선할 것인가. 즉 "책임의 설계"가 물어지고 있다.

Google