Google이 본 첫 AI 제로데이, 보안의 시간표가 바뀐다

AI 요약

• 무슨 일: Google Threat Intelligence Group이 AI로 개발된 것으로 판단한 첫 제로데이 exploit 사례를 공개했습니다.
  • 보고서 날짜는 2026년 5월 12일이며, 인기 있는 오픈소스 웹 기반 시스템 관리 도구의 2FA bypass 취약점을 노렸습니다.
• 핵심 신호: LLM은 crash를 찾는 scanner가 아니라, 개발자의 trust assumption을 읽는 취약점 분석 도구가 되고 있습니다.
• 실무 영향: 보안팀은 제로데이 대응을 90일 공개 주기가 아니라 AI-assisted weaponization 속도로 다시 봐야 합니다.
  • AI 제품팀에는 agent skill, API connector, package, 권한 위임 계층이 새로운 supply chain 표면이라는 경고이기도 합니다.

Google이 AI 보안 논쟁의 기준선을 한 단계 앞으로 밀었습니다. 2026년 5월 12일, Google Threat Intelligence Group(GTIG)은 AI Threat Tracker 보고서에서 범죄 행위자가 AI 모델의 도움으로 개발한 것으로 판단되는 제로데이 exploit을 확인했다고 밝혔습니다. 보고서의 표현은 조심스럽습니다. Gemini가 쓰였다고 보지는 않으며, "AI가 만들었다"고 수학적으로 증명했다는 뜻도 아닙니다. 그러나 GTIG은 코드 구조와 정황을 근거로, AI 모델이 취약점 발견과 weaponization을 지원했다는 데 높은 확신을 둔다고 설명합니다.

이 사건이 중요한 이유는 "AI가 해커가 됐다"는 자극적인 문장 때문이 아닙니다. 더 정확한 변화는 보안의 시간표입니다. 지금까지 많은 조직은 취약점 발견, PoC 작성, 패치, 공개, exploit 확산 사이에 어느 정도의 인간 속도가 있다고 가정했습니다. 뛰어난 공격자는 빠르지만, 대규모로 의미론적 로직 결함을 읽고 재현 가능한 exploit을 다듬는 데는 시간이 걸린다는 전제입니다. GTIG 보고서는 이 전제가 흔들리고 있음을 보여줍니다.

이번 사례에서 취약점은 메모리 corruption이나 흔한 입력 검증 오류가 아니었습니다. Google은 인기 있는 오픈소스 웹 기반 시스템 관리 도구에서 2FA를 우회하는 결함이라고 설명했습니다. 더 구체적으로는 개발자가 코드 안에 하드코딩한 신뢰 가정, 즉 특정 조건에서는 추가 인증을 요구하지 않아도 된다는 의미론적 예외가 문제였습니다. 기존 fuzzer와 static analyzer는 crash, sink, tainted input, unsafe call 같은 형태를 잘 찾습니다. 반면 이런 로직 결함은 "개발자가 무엇을 의도했는가"와 "코드가 실제로 어떤 예외를 허용하는가"를 같이 읽어야 합니다.

LLM이 바로 그 중간 지점에 들어옵니다. 모델은 완벽하지 않고, hallucination도 합니다. 하지만 많은 코드를 읽고, 주석과 제어 흐름을 요약하고, 인증 경계가 어디서 느슨해지는지 설명하는 작업에는 이미 충분히 강합니다. GTIG은 해당 Python exploit script에 교육용 docstring이 과도하게 많고, hallucinated CVSS score가 들어 있으며, 교과서적인 Python 구조와 상세 도움말, 깔끔한 ANSI color class 같은 LLM 학습 데이터 특유의 흔적이 있었다고 적었습니다. 이것은 법정 증거라기보다 위협 인텔리전스의 판단 근거입니다. 그래도 보안팀이 무시하기에는 충분히 구체적입니다.

단순한 취약점 하나가 아니라 공격 생산라인의 변화입니다

이번 보고서의 제목은 제로데이 하나보다 넓습니다. GTIG은 2026년 2월 AI 관련 위협 활동 보고서 이후, 위협 행위자들이 생성형 AI를 실험적 도구에서 산업 규모의 공격 워크플로로 옮기고 있다고 봅니다. Mandiant 사고 대응, Gemini 관련 관측, GTIG의 사전 연구를 합쳐 보면, AI는 공격 생명주기의 여러 지점에 동시에 들어가고 있습니다.

첫째, 취약점 연구입니다. 보고서는 PRC와 DPRK 관련 위협 클러스터가 AI 기반 취약점 discovery에 큰 관심을 보였다고 설명합니다. 일부 행위자는 모델에게 "임베디드 장비를 감사하는 senior security auditor" 같은 역할을 부여하고, TP-Link firmware나 OFTP 구현체를 분석하는 시나리오를 만들었습니다. 또 다른 경우에는 WooYun의 과거 취약점 사례 85,000건 이상을 정리한 repository를 Claude code skill plugin처럼 활용해 모델이 seasoned expert처럼 로직 결함을 우선순위화하도록 유도한 정황도 언급됩니다.

둘째, exploit 검증과 자동화입니다. GTIG은 APT45가 수천 개의 반복 prompt를 보내 여러 CVE를 재귀적으로 분석하고 PoC exploit을 검증한 사례를 적었습니다. 이것은 한 명의 분석가가 밤새 붙잡고 있는 작업이 아니라, 모델을 반복 루프에 넣고 여러 candidate를 기계적으로 좁히는 방식에 가깝습니다. 더 나아가 OpenClaw, OneClaw 같은 agentic tool과 의도적으로 취약한 테스트 환경을 함께 사용해 payload 신뢰성을 높이려는 움직임도 관측됐습니다.

셋째, autonomous malware입니다. 보고서의 PROMPTSPY 분석은 특히 불편합니다. ESET이 처음 식별한 Android backdoor인 PROMPTSPY는 Gemini API를 이용해 Android UI를 해석하고, 접근성 API로 화면 계층을 XML 비슷한 형태로 직렬화한 뒤, 모델에게 어떤 좌표를 클릭하거나 스와이프해야 하는지 JSON으로 받는 구조를 포함했습니다. GTIG은 이 모듈이 특정 persistence 동작뿐 아니라 여러 종류의 device interaction으로 확장 가능하도록 설계됐다고 봅니다. malware가 단순 명령 실행기를 넘어, 화면 상태를 읽고 다음 행동을 고르는 agent로 진화하는 셈입니다.

넷째, 모델 접근 자체의 산업화입니다. 공격자가 모델을 쓰려면 계정, 결제, API key, quota가 필요합니다. GTIG은 anti-detect browser, account pooling, relay service, 자동 가입 및 취소 스크립트, OpenAI-compatible proxy를 묶어 premium LLM 접근을 익명화하고 대량화하려는 생태계를 관측했습니다. 이것은 악용 계정을 하나씩 차단하는 문제를 넘어섭니다. 공격자는 모델 사용량을 supply chain처럼 조달하고, quota를 분산하고, safety monitoring을 회피하려 합니다.

왜 2FA 우회 사례가 특히 의미 있는가

2FA 우회라는 말만 보면 이미 익숙한 공격처럼 들릴 수 있습니다. 피싱 proxy, session cookie theft, SIM swap, push bombing, OAuth consent abuse 등 2FA를 우회하는 방법은 많았습니다. 그러나 이번 사례는 결이 다릅니다. Google이 강조한 것은 사용자를 속여 인증 코드를 빼앗는 social engineering이 아니라, 애플리케이션의 인증 로직 자체에서 예외를 찾았다는 점입니다.

이 차이는 개발팀에 직접적인 의미가 있습니다. 많은 제품은 인증 경계를 단일 파일이나 단일 middleware로 끝내지 않습니다. 관리자 예외, migration path, legacy API, service account, internal callback, password reset, remember device, recovery flow가 얽힙니다. 코드 한 줄만 보면 합리적인 예외가 시스템 전체에서는 우회로가 됩니다. 사람 리뷰어는 제품 맥락을 알아야 하고, scanner는 그 맥락을 잘 모릅니다. LLM은 완벽한 제품 이해를 갖지는 못하지만, 파일 여러 개를 읽고 "여기서만 두 번째 인증이 빠진다"는 형태의 후보를 만드는 데 점점 유용해지고 있습니다.

Google의 Figure 3도 이 지점을 시각화합니다. 전통적 discovery mechanism은 낮은 수준의 구현 결함에 강합니다. 반면 frontier LLM은 아직 복잡한 enterprise authorization logic 전체를 안정적으로 탐색하지 못하더라도, hardcoded exception과 developer intent 사이의 모순을 찾는 능력이 커지고 있습니다. 보안팀 입장에서는 위협 모델에 새 문장을 추가해야 합니다. "우리 코드의 논리적 예외를 공격자가 모델에게 설명시킬 수 있는가?"

방어자도 같은 속도를 얻지만, 조직은 아직 느립니다

흥미로운 점은 Google이 같은 보고서에서 방어 측 AI도 강조한다는 것입니다. Google은 Big Sleep 같은 AI agent로 software vulnerability를 찾고, Gemini reasoning capability를 CodeMender 같은 자동 수정 흐름에 활용한다고 설명합니다. 즉 이 이야기는 "공격자만 AI를 얻었다"가 아닙니다. 방어자도 더 빠른 triage, patch suggestion, exploitability analysis, incident summarization을 얻습니다.

문제는 조직의 나머지 부분입니다. 모델이 취약점을 빨리 찾아도, patch가 release branch에 들어가고, 고객이 upgrade하고, 운영팀이 maintenance window를 잡고, 보안팀이 exception을 승인하는 절차는 여전히 느립니다. AI가 줄이는 것은 분석 시간입니다. 하지만 실제 위험은 분석 이후의 배포 지연에서 폭발합니다. 공격자가 patch diff를 읽고 exploit을 생성하는 시간이 짧아질수록, "이번 분기 안에 올리자"는 보안 업데이트 문화는 더 위험해집니다.

여기서 90일 공개 관행도 다시 논쟁의 대상이 됩니다. 90일 disclosure가 항상 느리다는 뜻은 아닙니다. 취약점 생태계에는 공급업체 조율, 사용자 보호, 패치 품질, 연구자 권리라는 복잡한 균형이 있습니다. 그러나 AI-assisted exploit generation이 현실화되면, 공개 후 exploit 확산까지의 시간이 줄어듭니다. 보안팀은 공개 날짜가 아니라 exploit 자동화 가능성을 기준으로 패치 우선순위를 정해야 합니다. 특히 인증 우회, 관리 콘솔, 인터넷 노출 관리 도구, CI/CD credential 경계는 단순 CVSS 점수보다 "모델이 빠르게 이해하고 재현할 수 있는가"를 봐야 합니다.

AI 제품팀에는 supply chain 경고입니다

이번 GTIG 보고서의 후반부는 AI를 공격 도구로만 보지 않습니다. AI software ecosystem 자체가 공격 표면이 되고 있다고 봅니다. OpenClaw skill package, wrapper library, API connector, third-party data connector, PyPI package, GitHub Actions compromise가 모두 언급됩니다. 핵심은 모델 자체를 뚫지 않아도 된다는 것입니다. 모델 주변의 실행 계층, 권한 위임 계층, 도구 연결 계층을 장악하면 충분합니다.

이 메시지는 AI agent를 만드는 팀에 특히 중요합니다. agent는 일반 SaaS 기능보다 더 많은 권한을 요구합니다. 파일을 읽고, 명령을 실행하고, repository를 수정하고, browser를 조작하고, 내부 문서와 ticket system에 접근합니다. 이 권한은 생산성을 만듭니다. 동시에 악성 skill 하나, 취약한 connector 하나, 검증되지 않은 MCP server 하나가 사용자의 환경 전체를 공격자에게 열어줄 수 있습니다.

GTIG은 VirusTotal 연구진이 OpenClaw ecosystem에서 악성 또는 취약한 skill package 위험을 보고했고, OpenClaw가 ClawHub에 VirusTotal Code Insight 기반 자동 scanning을 통합했다고 설명합니다. 이 방향은 다른 agent marketplace에도 그대로 적용됩니다. "설치 가능한 agent component"는 npm package나 VS Code extension만큼, 어쩌면 그보다 더 높은 보안 기준을 가져야 합니다. 이유는 간단합니다. 많은 agent component는 설치 직후 자연스럽게 credential, local file, shell, browser session 근처에서 작동하기 때문입니다.

개발팀이 지금 바꿔야 할 체크리스트

이번 뉴스는 거대한 보안 담론으로 끝나기 쉽지만, 실제로는 몇 가지 실무 습관을 바꾸라는 신호입니다.

첫째, 인증과 권한 경계에 대한 LLM-assisted review를 방어 목적으로 먼저 도입해야 합니다. 단순히 "취약점 찾아줘"라고 묻는 수준이 아니라, recovery flow, remember device, admin bypass, service-to-service callback, migration flag, feature flag, legacy route를 모델에게 설명시키고 예외 목록을 만들게 해야 합니다. 모델 출력은 신뢰하지 말고, reviewer가 후보를 검증해야 합니다. 목적은 완전 자동 판정이 아니라 사람이 놓치는 semantic candidate를 늘리는 것입니다.

둘째, scanner가 통과했다는 사실을 로직 안전의 증거로 취급하면 안 됩니다. SAST와 DAST는 계속 필요합니다. 그러나 이번 사례가 말하는 영역은 "코드가 의도와 다르게 믿는다"는 문제입니다. 특히 하드코딩된 trust list, internal IP 예외, localhost 예외, debug mode, tenant isolation, admin impersonation 같은 코드는 사람이 제품 맥락과 함께 봐야 합니다.

셋째, agent component의 설치와 실행 권한을 package 관리처럼 다뤄야 합니다. skill, plugin, MCP server, connector, workflow template은 모두 provenance, permission manifest, network behavior, secret access, update policy가 필요합니다. 개인 개발자 도구에서도 마찬가지입니다. local coding agent가 어떤 skill을 읽고, 어떤 command를 실행하며, 어떤 repository secret에 접근하는지 audit trail을 남겨야 합니다.

넷째, incident response playbook에 LLM 계정과 relay 인프라를 넣어야 합니다. 공격자가 API aggregator, account pool, trial abuse 자동화로 모델 접근을 조달한다면, 방어자는 단순 IP 차단보다 사용 패턴, prompt volume, account lifecycle, proxy endpoint, suspicious automation signal을 함께 봐야 합니다. AI 서비스 제공자는 abuse detection을 제품 보안의 주변부가 아니라 핵심 telemetry로 다뤄야 합니다.

과장하지 않되, 느리게 반응하면 안 됩니다

이 사건을 과장해서는 안 됩니다. Google은 영향을 받은 도구 이름을 공개하지 않았고, 어떤 모델이 쓰였는지도 특정하지 않았습니다. 코드 스타일이 LLM스럽다는 판단은 강한 정황일 수 있지만, 그 자체로 완전한 증명은 아닙니다. 또한 AI가 갑자기 숙련된 exploit developer를 대체했다는 뜻도 아닙니다. 유효한 계정이 먼저 필요했고, 대량 악용은 Google의 counter discovery와 vendor disclosure로 차단됐다고 설명됩니다.

하지만 과소평가도 위험합니다. 보안에서 중요한 변화는 종종 "완전히 새로운 능력"이 아니라 "기존 능력의 단가 하락"으로 옵니다. phishing도 그랬고, ransomware 운영도 그랬고, supply chain 공격도 그랬습니다. AI가 취약점 연구의 모든 단계를 해결하지 못하더라도, 후보를 더 많이 만들고, PoC를 더 빨리 다듬고, 오류 메시지를 해석하고, 테스트 환경을 돌리는 비용을 낮추면 공격자의 전체 처리량은 올라갑니다.

devlery에서 최근 다룬 agent runtime, control plane, sandbox, coding agent 경쟁은 대부분 생산성의 관점이었습니다. 이번 GTIG 보고서는 그 생산성 곡선의 어두운 반대편입니다. 코딩 에이전트가 좋은 코드를 더 빨리 만들 수 있다면, 공격 에이전트도 취약한 경계를 더 빨리 읽을 수 있습니다. 기업이 AI agent를 도입할 때 governance, observability, approval, sandbox를 요구하는 이유가 바로 여기에 있습니다.

보안의 새 기준은 "AI가 읽을 수 있는 약점"입니다

앞으로 보안 리뷰의 질문은 조금 달라질 것입니다. "이 코드는 scanner를 통과하는가"뿐 아니라 "이 코드는 모델에게 설명했을 때 어떤 우회 경로로 요약되는가"를 물어야 합니다. "이 plugin은 공식 marketplace에 있는가"뿐 아니라 "이 plugin이 가진 권한으로 agent가 어떤 rogue action을 할 수 있는가"를 물어야 합니다. "이 취약점은 아직 공개 전인가"뿐 아니라 "공개되면 AI가 exploit candidate를 만드는 데 얼마나 걸릴 것인가"를 물어야 합니다.

GTIG의 보고서는 첫 사례를 선언하는 문서라기보다, 보안 운영의 관측 단위를 바꾸라는 문서에 가깝습니다. 취약점은 더 이상 사람 연구자와 자동 scanner 사이에서만 발견되지 않습니다. malware는 더 이상 정적 payload와 원격 명령 사이에서만 움직이지 않습니다. AI component는 더 이상 애플리케이션의 부가 기능이 아닙니다. 모두가 실행 권한, 데이터 접근, 의사결정 경계를 가진 운영 계층이 되고 있습니다.

AI 제로데이의 시대가 왔다고 단정하는 것은 이릅니다. 그러나 AI가 제로데이의 시간을 줄이는 시대는 이미 시작됐다고 보는 편이 안전합니다. 방어자의 과제는 공포가 아니라 속도입니다. 더 빨리 찾고, 더 빨리 고치고, 더 엄격하게 권한을 나누고, agent 생태계를 소프트웨어 supply chain으로 대우하는 것. 이번 Google 보고서가 던진 실무적 결론은 그 정도로 충분히 선명합니다.