보안팀의 패치 주기와 모니터링 체계는 여전히 "공격자가 취약점을 찾고 무기화하는 데 시간이 걸린다"는 전제를 깔고 있는 경우가 많습니다. 문제는 이 전제가 점점 덜 안전해지고 있다는 점입니다.
이번 사건의 핵심은 구글이 AI로 개발됐다고 보는 제로데이 악용 시도를 대규모 공격 전에 차단했다는 데 있습니다.1 구글 위협 인텔리전스 그룹은 공격자가 인기 있는 오픈소스 웹 기반 시스템 관리 도구의 2FA 우회 취약점을 Python exploit로 구현했으며, 벤더와 협력해 패치했다고 밝혔습니다.2
진짜 변화는 "AI도 해킹한다"가 아니라 "발견 비용이 낮아진다"다
이번 취약점은 전통적인 메모리 손상 버그나 단순 입력 검증 실패가 아니라, 인증 흐름 안의 하드코딩된 신뢰 가정에서 나온 논리 결함으로 설명됩니다.3 공격에는 유효한 계정 정보가 필요했지만, 2FA를 우회할 수 있었다는 점에서 초기 침투 이후의 위험이 큽니다.
구글은 exploit 코드 안의 과도한 교육용 주석, 교과서식 Python 구조, 존재하지 않는 CVSS 점수 같은 흔적을 근거로 AI 개입 가능성을 높게 봤습니다.2 다만 이것은 "확정적 증명"이라기보다 코드 형태와 취약점 성격을 종합한 고신뢰 판단에 가깝습니다. Gemini가 사용됐다는 증거도 없다고 밝혔습니다.3
중요한 해석은 여기서 나옵니다. AI가 갑자기 초인적 해커가 됐다는 이야기가 아닙니다. 그보다 취약점 후보를 읽고, 논리적 모순을 찾고, exploit 형태로 다듬는 과정의 시간과 비용이 줄어들 수 있다는 뜻입니다. 과거에는 숙련된 연구자가 병목이었다면, 이제는 공격자가 여러 제품과 버전을 동시에 훑는 규모의 문제가 될 수 있습니다.
기존 보안 플레이북에서 먼저 깨지는 부분
가장 먼저 흔들리는 것은 "알려진 CVE 중심"의 방어입니다. 제로데이는 당연히 CVE 목록에 오르기 전 악용됩니다. 여기에 AI가 취약점 탐색 속도를 높이면, 공개된 취약점만 추적하는 조직은 한 박자 늦을 가능성이 커집니다.
두 번째는 느린 패치 사이클입니다. 구글의 2025년 제로데이 리뷰에 따르면, 해당 해 추적된 제로데이는 90건이었고 이 중 엔터프라이즈 기술 대상이 43건, 약 48%였습니다.4 특히 보안 장비, 네트워크 장비, 웹 관리 도구처럼 권한이 높고 외부에 노출되는 시스템은 공격자에게 효율적인 진입점입니다.
세 번째는 2FA에 대한 과신입니다. 이번 사례는 2FA 자체가 무용하다는 뜻은 아닙니다. 오히려 반대입니다. 2FA는 여전히 필요하지만, 구현 흐름의 예외 처리, 세션 전환, 백업 인증, 관리자 기능 같은 주변부가 공격 표면이 됩니다. "2FA를 켰다"가 아니라 "2FA가 어떤 경로에서도 우회되지 않는가"를 물어야 합니다.
지금 올려야 할 방어 우선순위
방어자가 할 일은 AI 공포에 맞춰 모든 것을 갈아엎는 것이 아닙니다. 인간 속도에 맞춰 설계된 절차를 줄이는 것입니다.
우선 외부 노출 자산 목록을 더 자주, 더 정확하게 갱신해야 합니다. 관리 콘솔, VPN, 보안 어플라이언스, 오픈소스 관리 도구는 "있을 것"이 아니라 "정확히 어디에 어떤 버전으로 있는지" 확인돼야 합니다.
패치 SLA도 현실적으로 재조정해야 합니다. 모든 취약점을 즉시 고칠 수는 없습니다. 대신 인터넷 노출, 인증 우회, 권한 상승, 널리 쓰이는 오픈소스 컴포넌트처럼 exploit 가치가 높은 항목은 별도 트랙으로 다뤄야 합니다.
탐지도 서명 중심에서 행위 중심으로 옮겨야 합니다. 알려진 exploit 문자열을 찾는 방식은 새로운 논리 결함에 약합니다. 비정상 로그인 흐름, 2FA 이후 세션 생성 패턴, 관리자 기능 호출 순서, 평소와 다른 API 사용량 같은 행위 신호가 더 중요해집니다.
AI를 방어에 쓰는 것도 선택지가 아니라 경쟁 조건에 가까워지고 있습니다. 구글은 Big Sleep 같은 AI 에이전트로 취약점을 찾고, CodeMender로 자동 수정 역량을 실험한다고 설명했습니다.5 다만 여기에도 트레이드오프가 있습니다. AI 코드 리뷰는 누락을 줄일 수 있지만, 오탐과 설명 불가능성이 운영 부담을 만들 수 있습니다. 따라서 자동 차단보다 우선순위화, 리뷰 보조, 위협 헌팅 보강부터 적용하는 편이 현실적입니다.
벤더에게 물어야 할 질문이 바뀐다
이 사건 이후 보안·소프트웨어 벤더 평가 질문은 더 구체적이어야 합니다.
"취약점 스캐너가 있습니까?"보다 "논리 결함과 인증 우회 시나리오를 어떻게 테스트합니까?"가 중요합니다. "패치가 빠릅니까?"보다 "제로데이 의심 정황을 발견했을 때 고객에게 어떤 임시 완화책을 몇 시간 안에 제공합니까?"를 물어야 합니다.
또 "AI를 씁니까?"보다 "AI가 찾은 취약점 후보를 사람이 어떻게 검증하고, 제품 보안 프로세스에 어떻게 반영합니까?"가 더 좋은 질문입니다. 공격자도 AI를 쓰고, 방어자도 AI를 씁니다. 차이는 도구 보유 여부가 아니라 대응 루프의 속도와 품질에서 납니다.
이번 사건은 모든 조직이 내일 AI 제로데이에 당한다는 경고가 아닙니다. 하지만 외부 노출 관리 도구, 인증 흐름, 패치 지연, CVE 의존적 운영에 기대는 조직이라면 지금 점검해야 합니다. 앞으로의 보안 질문은 "AI가 우리를 해킹할 수 있나"가 아니라 "우리 보안 프로세스의 어느 부분이 아직 공격자의 인간 속도에 맞춰져 있나"입니다.
참고
1Google stopped a zero-day hack that it says was developed with AI
2Hackers Used AI to Develop First Known Zero-Day 2FA Bypass for Mass Exploitation
3Google discovers weaponized zero-day exploits created with AI
4Look What You Made Us Patch: 2025 Zero-Days in Review
5Google Threat Intelligence Group reports on AI threat trends.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.