구글은 자사 내부 AI 도구가 6월에 두 번의 브라우저 릴리스에서 크롬의 보안 버그 1,072건 수정을 도왔다고 밝혔다. 이는 약 2년에 걸친 이전 23개 릴리스에서 기록된 수정 1,036건보다 많은 수치다.

이 수치는 AI 보조 취약점 발견 및 패치에 관한 구글의 백서와 함께 공개됐으며, 대규모 언어 모델이 소프트웨어 보안의 경제성을 어떻게 바꾸고 있는지 보여주는 구체적인 사례다. 브라우저 제조사와 기업 IT 팀에게 이 변화는 공격자가 악용하기 전에 더 많은 결함을 찾아낼 수 있다는 의미가 될 수 있지만, 동시에 수정 사항을 검증하고 우선순위를 정하며 배포하는 데 훨씬 더 큰 운영 부담을 뜻하기도 한다.

구글에 따르면 이번 비교는 6월에 출시된 두 개의 “마일스톤”인 Chrome 149와 Chrome 150을 포함한다. 이전 기간은 2024년 6월의 Chrome 126에서 시작됐다. 구글은 숫자에 대한 독립적인 검증이나, 얼마나 많은 수정이 AI에 의해 직접 생성·발견·가속됐는지 보여주는 상세한 내역을 제공하지 않았다.

구글이 말하는 크롬 보안의 변화

크롬 엔지니어링 디렉터 더그 터너는 TechCrunch에 대규모 언어 모델이 취약점 발견을 대부분 수작업이던 활동에서 산업 규모로 작동하는 자동화된 프로세스로 바꿔 놓았다고 말했다. 그는 구글이 Gemini 같은 모델을 적용해 공격자가 사용하기 전에 결함을 식별하고 대응하고 있다고 밝혔다.

이 구분은 중요하다. 구글의 헤드라인 수치는 공개된 크롬 버전에서 수정된 버그를 설명할 뿐, 반드시 AI 시스템만으로 발견된 취약점을 의미하지는 않는다. 회사의 공개 설명에 따르면 AI 도구는 코드 분석, 의심스러운 패턴 식별, 수정안 제안, 그리고 엔지니어가 테스트와 출시 과정을 통해 패치를 진행하도록 돕는 등 더 넓은 워크플로를 지원했다.

6월의 두 릴리스는 합쳐서 1,072건의 보안 수정이었고, 이전 23개 릴리스에서는 1,036건이었다. 단순 평균으로 보면 릴리스당 수정 건수가 크게 증가한 것이다. 그러나 이 비교만으로 AI가 모든 추가 수정을 만들었다고 결론내릴 수는 없다. 릴리스 범위, 보고 관행의 변화, 보안 연구 활동, 그리고 구글의 보안 버그 정의도 총수에 영향을 줄 수 있다.

따라서 구글의 그래프와 백서는 통제된 성능 벤치마크라기보다 변화하는 보안 운영의 증거로 읽는 것이 가장 적절하다. 회사가 결과를 직접 보고하고 있으며, 제공된 증거에는 방법론에 대한 제3자 감사가 포함되어 있지 않다.

더 넓은 AI 보조 취약점 경쟁

구글의 발표는 마이크로소프트의 비슷한 주장에 이어 나온 것이다. 7월 초, 마이크로소프트는 월간 Patch Tuesday 릴리스에서 자사 제품군 전반에 걸쳐 기록적인 570개의 보안 결함을 수정했으며, 그 증가의 일부는 AI 사용 덕분이라고 밝혔다.

이 두 발표는 오래된 사이버보안 우려를 뒷받침한다. AI 시스템이 결함을 더 잘 찾아낼수록 방어자들은 더 많은 취약점을 더 빠르게 발견할 수 있다. 조직이 신속히 패치하면 보안은 향상되지만, 이전에는 놓쳤던 제품의 약점을 드러내고 보안 팀의 작업량을 늘릴 수도 있다.

이 패턴은 주요 기술 기업 전반에서 균일하지 않다. TechCrunch가 인용한 독립 집계에 따르면 애플은 2026년에 482건의 버그를 수정해, 전년도 총합과 비슷하거나 이를 넘길 속도인 것으로 나타났다. 애플은 해당 매체의 კომენტ 요청에 응답하지 않았고, 공개된 증거로는 애플의 내부 AI 사용이 구글이나 마이크로소프트와 다른지 알 수 없다.

현재 가장 타당한 결론은 일부 대형 소프트웨어 공급업체가 AI 도구의 광범위한 도입과 함께 상당한 수준의 보안 수정 증가를 보고하고 있다는 점이다. 그 증가분 중 얼마나 많은 부분이 진정한 새로운 발견 능력을 반영하는지, 아니면 엔지니어링 프로세스나 공개 관행의 변화인지는 여전히 불분명하다.

브라우저와 기업 팀에 이 숫자가 중요한 이유

브라우저는 넓은 공격 표면과 잦은 릴리스를 동시에 갖고 있어 이런 변화에 특히 노출돼 있다. 크롬은 웹 페이지 렌더링, 코드 실행, 미디어 처리, 자격 증명 관리, 운영체제 서비스 연결을 위한 복잡한 구성 요소를 포함한다. 이들 영역 중 미묘한 결함을 찾아내는 도구는 구글이 발견과 수정 사이의 시간을 줄이는 데 도움이 될 수 있다.

Google Chrome 위에 제품과 보안 체계를 구축하는 팀에게 즉각적인 의미는 이론보다 운영에 가깝다. 더 잦은 수정은 더 빠른 브라우저 검증, 더 엄격한 패치 관리 프로세스, 직원 기기에 업데이트를 배포하기 위한 더 명확한 정책을 요구할 수 있다. 브라우저 업데이트를 늦추는 기업은 취약점 발견과 현장 배포 사이의 간격이 더 커질 수 있다.

AI 보조 취약점 발견은 검증 문제도 만든다. 자동 생성된 결과에는 오탐, 중복 보고, 재현하기 어려운 결함이 포함될 수 있다. 제안된 코드 변경은 검토와 테스트가 필요하며, 특히 보안 패치가 성능, 호환성 또는 다른 보안 통제에 영향을 줄 수 있을 때는 더욱 그렇다. 수백만 명이 사용하는 브라우저에서 잘못된 수정은 대규모의 새로운 장애를 만들 수 있다.

경쟁 압력은 공격자에게도 확장된다. 방어 시스템이 코드를 더 빨리 점검하고 약점을 식별할 수 있다면, 공격 연구자와 범죄 집단도 유사한 능력을 사용해 공개 소프트웨어, 브라우저 확장 프로그램, 애플리케이션, 인프라를 탐색할 수 있다. 그 결과 패치 속도와 안전한 배포는 버그를 찾는 원시적 능력만큼 중요해질 수 있다.

다음에 주목할 점

다음으로 유용한 신호는 구글이 측정 과정에 대해 더 자세히 밝히는 것이다. 보안 팀과 연구자들은 1,072건의 수정 중 몇 건이 AI에 의해 발견됐는지, 몇 건이 모델의 도움으로 제안되거나 구현됐는지, 그리고 구글이 절감된 시간을 어떻게 측정했는지 알고 싶어할 것이다.

향후 크롬 출시 데이터도 6월이 이례적인 급증이었는지, 아니면 지속적인 증가의 시작이었는지 보여줄 것이다. 여러 브라우저를 포괄하는 더 넓은 비교는 구글 특유의 프로세스 변화와 업계 전반의 추세를 구분하는 데 도움이 될 수 있다.

기업 구매자들은 크롬의 패치 주기, 긴급 업데이트 빈도, 자동 배포 가이드라인의 변화를 주시해야 한다. 또한 자사의 보안 도구가 엔지니어링 팀을 압도하지 않으면서 더 많은 취약점 보고를 분류해낼 수 있는지도 점검해야 한다.

마지막으로, 독립 연구자들은 증가하는 수정 건수가 더 낮은 악용률, 더 짧은 대응 기간, 또는 사용자에게 도달하는 심각한 취약점 감소와 연결되는지를 살펴볼 수 있다. 더 많은 버그를 수정하는 것은 중요한 운영 지표이지만, 그것만으로 전체 위험이 줄었다는 증거는 아니다.

Creati.ai 관점

구글의 크롬 수치는 AI 보안 논의를 더 구체적으로 만든다. 중요한 변화는 모델이 버그를 찾아낼 수 있다는 사실만이 아니라, AI가 취약점 발견에서 패치 준비까지 보안 라이프사이클의 여러 단계를 압축할 수 있다는 점이다. 이는 자금력이 풍부한 공급업체에게 널리 사용되는 소프트웨어를 보호하는 데 의미 있는 우위를 제공할 수 있다.

하지만 같은 가속은 엄격한 검토의 가치를 높인다. 발견이 풍부해지면 우선순위 지정, 검증, 배포가 병목이 된다. 빌더와 기업 보안 책임자에게 전략적 질문은 AI를 사용할지 여부보다, 그로 인해 생성되는 물량을 엔지니어링 시스템이 안전하게 처리할 수 있는지 여부다.