AI가 Chrome 결함 1,072건 패치 지원하며 Amazon Google 보안 경쟁 변화

Google은 AI 지원 보안 도구가 버전 149와 150 전반에서 Chrome 취약점 1,072건을 패치하는 데 도움이 됐다고 밝혔다. 이는 자동화된 방어 역량의 인상적인 새 기준점이다. 이 수치는 Chrome의 이전 23개 마일스톤에서 수정된 보안 버그를 모두 합친 수보다 많았다. 이 급증은 더 넓은 amazon google 경쟁을 단순한 클라우드 모델 경쟁보다 더 중요한 문제로 만든다.

핵심은 AI 모델이 의심스러운 코드 패턴을 많이 찾아냈다는 데 있지 않다. Google은 취약점 발견, 재현, 분류, 배정, 패치, 테스트, 릴리스 및 문서화를 지원하는 에이전트를 구축했다. 인간 개발자는 여전히 후보 수정안을 검토하지만, 이제 자동화는 프로세스의 거의 모든 단계에 관여한다.

이는 소프트웨어 보안의 핵심 제약을 바꾼다. 결함을 찾는 일은 한때 제한된 팀이 수행하는 비용이 많이 들고 전문적인 작업이었다. 이제 AI는 조직이 결과물인 수정안을 안전하게 검증, 릴리스, 배포할 수 있는 속도보다 더 빠르게 발견 사항을 생성할 수 있다.

Amazon, Microsoft, Anthropic 및 다른 주요 기술 기업도 같은 변화에 직면해 있다. 이들의 우위는 유능한 모델을 보유했는지보다, 그 주변에 신뢰할 수 있는 보안 파이프라인을 운영하는지에 더 크게 달려 있게 될 것이다.

Google의 Chrome 수정 1,072건이 패치 규모를 재정의하다

Chrome의 기록적인 수정 건수는 AI 지원 취약점 작업이 고립된 실험 단계를 넘어 프로덕션 엔지니어링으로 진입했음을 보여준다.

Google은 2026년 7월 30일 자사의 Chrome 보안 파이프라인에 관한 상세 설명에서 이 수치를 공개했다. 회사에 따르면 Chrome 149와 Chrome 150에는 1,072건의 보안 버그 수정이 포함됐다.

그 이전 23개 Chrome 마일스톤의 전체 수정 건수는 이보다 적었다. 독립 보고서에 따르면 이전 건수는 1,036건으로, 두 번의 릴리스에서 발생한 급증은 약 2년간의 이전 산출량보다 컸다.

이 수치는 신중하게 해석해야 한다. 수리된 모든 버그가 언어 모델에 의해 독립적으로 발견됐다는 의미는 아니다. 또한 1,072개의 결함이 모두 동일한 심각도를 지녔거나 쉽게 악용될 수 있었다는 뜻도 아니다.

그럼에도 Google의 더 제한적인 주장은 중요하다. 이제 대규모 언어 모델은 해당 프로세스에 들어오는 대부분의 취약점에 대해 후보 수정안을 생성한다. AI는 발견, 분류, 재현, 테스트 생성 및 이슈 라우팅도 지원한다.

이 구분은 취약점 관리가 하나의 사슬이기 때문에 중요하다. 엔지니어가 악용 가능한 결함을 중복 항목, 노이즈 또는 저위험 강화 기회와 구별할 수 없다면, 수천 건의 경고를 내놓는 탐지기는 거의 보호 효과를 제공하지 못한다.

Google은 자동화된 분류 시스템이 먼저 보고서가 관련성 있고, 완전하며, 중복되지 않는지를 확인한다고 밝혔다. 이어 영향을 받는 브라우저 및 운영체제 구성에서 문제를 재현하려고 시도한다.

파이프라인은 추정 심각도와 결함이 코드베이스에 유입된 시점 등을 포함한 메타데이터를 추가한다. 마지막으로 보고서를 책임 있는 인간 담당자에게 배정한다.

개발자는 자동화된 심각도 평가를 수정할 수 있다. 또한 에이전트가 생성한 보조 산출물과 함께 후보 패치를 검토한다.

이 구조는 1,072건이라는 수치를 독립형 코드 스캐너의 결과보다 더 의미 있게 만든다. 이는 단지 내부 대기열에 쌓인 모델 생성 경고가 아니라, 안정화된 Chrome 릴리스에 도달한 수정안이었다.

Google은 자동화된 분류가 매달 수백 시간의 개발자 업무를 절감한다고 추정한다. 또한 테스트 작성 에이전트가 Chrome의 수많은 지원 플랫폼과 구성에 관련된 작업에서 수 주를 줄일 수 있다고 밝혔다.

한 발견 사례는 이 접근법의 잠재적 깊이를 보여준다. 보도에 따르면 2026년 초 Gemini 에이전트 하네스는 Chrome 코드베이스에 13년 넘게 남아 있던 샌드박스 탈출 취약점을 찾아냈다.

샌드박스 탈출은 침해된 브라우저 콘텐츠가 격리 경계를 넘어 보호돼야 할 리소스에 도달하도록 한다. Google은 이 결함으로 브라우저가 로컬 파일을 읽도록 속일 수 있었다고 밝혔다.

해당 결함의 오래된 존재만으로 AI가 숙련된 보안 연구자를 일관되게 능가한다는 점이 증명되지는 않는다. 이는 모델이 서로 다른 탐색 전략, 더 넓은 역사적 맥락 및 훨씬 많은 반복 시도로 성숙한 코드를 다시 검토할 수 있음을 보여준다.

Google은 통합 도구가 5월 동안 20건이 넘는 취약점이 프로덕션에 도달하는 것을 차단했다고도 보고했다. 이 수치에는 회사의 최고 심각도 범주에 속하는 이슈 1건이 포함됐다.

따라서 amazon google 키워드 뒤의 비교는 헤드라인 수치보다 더 광범위하다. 이는 어떤 기업이 모델을 실제 리포지터리, 테스트, 이슈 이력, 검토 시스템 및 릴리스 인프라와 연결할 수 있는지에 관한 문제다.

모델은 몇 초 만에 패치를 제안할 수 있다. 하지만 신뢰할 수 있는 보안 조직은 여전히 그 패치가 관련 없는 동작을 망가뜨리지 않으면서 올바른 조건을 수정한다는 점을 입증해야 한다.

Google의 발표가 가장 큰 무게를 갖는 지점은 이 운영 계층이다. 이는 AI 보안을 추측성 코드를 생성하는 챗봇이 아니라 관리되는 프로덕션 시스템으로 제시한다.

Amazon Google 보안 경쟁이 파이프라인에 관한 이유

공격자가 같은 결함을 악용하기 전에 모델 출력을 검토되고 배포된 보호 조치로 전환할 수 있는 조직이 경쟁 우위를 차지한다.

Google의 시스템은 수년간 점점 더 전문화돼 온 보안 연구를 기반으로 한다. 2023년 Chrome 엔지니어들은 비정상적인 입력을 소프트웨어에 넣어 충돌과 안전하지 않은 동작을 드러내는 퍼징을 개선하기 위해 언어 모델을 사용했다.

2024년 Google Project Zero는 취약점 연구에 필요한 도구를 언어 모델에 제공하는 프레임워크인 Naptime을 개발했다. 이어 Google DeepMind와 Project Zero는 Chrome의 V8 엔진과 그래픽 스택에서 결함을 찾은 에이전트 Big Sleep을 선보였다.

최신 워크플로는 발견을 넘어선다. 수정 에이전트는 여러 후보 패치를 생성하고, 별도의 비평 에이전트는 선택지를 평가해 개발자를 위한 자료를 준비한다.

수정 및 비평 에이전트는 검토 루프 안에서 작동한다. 이후 테스트 작성 에이전트는 개발자가 변경을 승인하기 전에 Chrome의 지원 환경 전반에서 작동하도록 설계된 검사를 생성한다.

이러한 역할 분담은 단일 보조 도구보다 보안 엔지니어링 팀에 더 가깝다. 각 에이전트는 더 좁은 책임을 맡으며, 파이프라인은 중요한 지점에서 인간 검토를 유지한다.

Google은 이전에 식별된 취약점과 프로젝트의 Git 이력을 담은 Chrome 지식 기반도 구축했다. 이 맥락은 모델이 원래 학습 데이터에서 이용 가능한 패턴을 넘어 추론하도록 돕는다.

리포지터리 수준의 SECURITY.md 파일은 신뢰 경계와 로컬 위협 가정을 설명한다. 비평 에이전트는 해당 지침을 별도로 읽어 수정 에이전트의 초기 추론에 대한 의존도를 낮춘다.

회사는 모델 출력이 비결정적이기 때문에 같은 코드에 대해 모델을 반복 실행한다. 다른 실행은 또 다른 경로를 탐색하거나, 다른 상호작용을 식별하거나, 이전 결론을 기각할 수 있다.

Chrome에서는 규모가 특히 중요하다. Google에 따르면 Chromium 및 관련 프로젝트에는 2,300개가 넘는 서드파티 의존성이 포함돼 있으며, 이 가운데 약 1,700개는 어떤 형태로든 사용자에게 도달한다.

이러한 의존성에는 V8 JavaScript 엔진, Skia 그래픽 라이브러리, ANGLE 그래픽 번역 계층 및 BoringSSL 암호화 라이브러리가 포함된다. 브라우저 취약점은 이러한 경계를 가로지르는 상호작용에서 발생할 수 있다.

Google은 모든 Chrome 서드파티 의존성을 자동화된 업데이트 파이프라인에 배치할 계획이다. 이 파이프라인은 취약점 데이터베이스를 포함한 내부 피드와 공개 리소스를 사용해 이용 가능한 업스트림 수정안을 식별한다.

이 지점에서 amazon google 경쟁은 인프라 경쟁이 된다. 두 회사 모두 대규모 클라우드 플랫폼, 광범위한 소프트웨어 포트폴리오 및 오픈소스 구성 요소로 가득한 공급망을 운영한다.

Amazon은 모델과 보안 이니셔티브가 클라우드 인프라를 통해 개발자에게 도달하는 Anthropic과도 중대한 전략적 연결고리를 갖고 있다. 그러나 모델 접근 권한을 보유하는 것만으로 Chrome 내부에서 Google과 같은 통합 깊이가 자동으로 만들어지는 것은 아니다.

Google은 브라우저 리포지터리, 지속적 통합 시스템, 릴리스 프로세스, 텔레메트리, 테스트 환경 및 방대한 취약점 이력을 통제한다. 이 조합은 외부 모델 제공업체가 쉽게 재현할 수 없는 맥락을 제공한다.

DeepMind의 더 최근 사이버보안 모델은 이 점을 강화한다. Google은 Gemini 3.5 Flash Cyber가 반복적이고 저비용인 모델 호출을 통해 취약점을 찾고, 검증하고, 패치하도록 최적화됐다고 밝혔다.

회사는 고정 호출 횟수 평가에서 고유하게 확인된 V8 이슈 55건을 보고했다. Google의 테스트 조건에서 주력 Gemini 모델은 47건을, Claude Opus 4.6은 36건을 찾아냈다.

이는 독립 감사가 아니라 회사가 보고한 벤치마크 결과다. Google은 제공업체의 안전 정책이 어떤 경쟁 모델 버전이 평가를 완료할 수 있는지에 영향을 미쳤다고도 언급했다.

그럼에도 이 메커니즘은 주목할 만하다. 더 작고 전문화된 모델이 방대한 탐색 공간에서 반복 실행된 뒤, 에이전트 시스템을 통해 작업을 통합할 수 있다.

이 접근법은 최대 모델 지능에서 컴퓨팅 및 검토 노력 단위당 유용한 발견으로 관심을 옮긴다. 보안 팀에는 유려한 설명보다 폭넓은 적용 범위, 재현 가능한 증거 및 관리 가능한 보고서가 필요하다.

Amazon과 다른 클라우드 제공업체는 기업 고객에게 이에 상응하는 파이프라인을 제공해야 한다는 압박에 직면하게 될 것이다. 구매자는 서비스가 결함을 찾고, 도달 가능성을 검증하며, 수정안을 제안하고, 신뢰할 수 있는 테스트를 생성할 수 있는지 묻게 될 것이다.

또한 소스 코드가 어디로 이동하는지, 모델이 무엇을 보존하는지, 에이전트가 외부 시스템에 접속할 수 있는지도 물을 것이다. 코드 노출을 확대하는 보안 도구는 줄이겠다고 약속한 위험 자체를 만들어낼 수 있다.

Google은 내부 스캐닝 모델이 일반 인터넷 접근이 없는 잠금 상태의 머신에서 작동한다고 밝혔다. 네트워크 요청은 애플리케이션 및 목적지 허용 목록을 통해 가로채고 통제된다.

하위 에이전트는 로컬 시스템을 수정하거나 지정된 소스 디렉터리 밖의 파일에 접근할 수 없다. 자율 보안 분석은 가치 있는 소스 코드와 약점을 탐색할 수 있는 도구를 결합하기 때문에 이러한 통제는 필수적이다.

따라서 amazon google 보안 경쟁의 다음 단계는 격리와 증거에 의해 좌우될 것이다. 모델 점수만으로는 기업이 민감한 리포지터리 내부의 에이전트를 신뢰해야 하는지에 답할 수 없다.

AI가 버그 발견과 수정의 경제학을 바꾸다

핵심 변화는 경제적이다. 자동화된 발견은 보안 발견 사항을 풍부하게 만드는 반면, 인간의 판단은 여전히 희소하다.

Chrome 엔지니어링 디렉터 Doug Turner는 언어 모델이 취약점 발견을 산업 규모의 자동화 작업으로 바꿨다고 TechCrunch에 말했다. 보도된 수정 건수는 그 주장에 대한 가시적인 근거를 제공한다.

전통적인 취약점 연구에는 프로그래밍 언어, 운영체제, 익스플로잇 기법 및 대상의 아키텍처를 이해하는 전문가가 필요하다. 이러한 역량은 여전히 필수적이지만, 이제 모델은 매우 낮은 한계 비용으로 탐색의 일부를 반복할 수 있다.

모델은 오래된 커밋을 검토하고, 구성 요소 전반의 패턴을 비교하며, 테스트 케이스를 구성하고, 이전에 기각된 영역을 다시 살필 수 있다. 또한 예정된 감사를 기다리지 않고 지속적으로 작동할 수 있다.

그에 따른 생산성 향상은 균등하게 나타나지 않는다. 의심스러운 발견을 생성하는 일은 그 발견이 중요하다는 점을 증명하는 것보다 쉽기 때문에, 발견 단계가 먼저 확장된다.

신뢰할 수 있는 보고서는 영향을 받는 코드가 현실적인 조건에서 도달 가능함을 보여야 한다. 또한 위반된 보안 경계를 식별하고 관련 빌드에서 해당 동작을 재현해야 한다.

그런 다음 팀은 심각도와 우선순위를 결정해야 한다. 기술적으로 유효한 메모리 오류라도 영향은 제한적일 수 있는 반면, 작은 로직 결함은 다른 약점과 연결될 경우 위험해질 수 있다.

패치 생성에는 또 다른 입증 기준이 필요하다. 변경 사항은 회귀를 만들거나, 다른 방어를 약화시키거나, 관찰 가능한 증상만 감추지 않으면서 취약한 경로를 차단해야 한다.

소프트웨어 규모가 커질수록 테스트는 더 어려워진다. Chrome은 여러 운영체제, 프로세서 아키텍처, 기기 유형, 엔터프라이즈 구성에서 실행된다.

한 테스트 환경에서 올바르게 동작하는 패치가 다른 환경에서는 실패할 수 있다. 자동화된 테스트 생성이 도움이 되지만, 생성된 테스트 역시 모델의 잘못된 가정을 담을 수 있다.

이 때문에 Google의 분리된 수정 에이전트와 비평 에이전트 활용이 중요하다. 독립적인 컨텍스트는 단일 에이전트가 진단 단계부터 제안한 수정안까지 이어갈 수 있는 모순을 드러낼 수 있다.

그러나 여러 에이전트가 있다고 해서 독립적인 인간 검토자와 동등한 것은 아니다. 이들은 학습 편향을 공유하거나, 동일한 아키텍처를 오해하거나, 그럴듯하지만 불완전한 설명으로 수렴할 수 있다.

따라서 이러한 경제적 변화는 새로운 대기열을 만든다. 보안 조직은 한때 연구자가 검사할 수 있는 양보다 더 많은 코드를 보유했다. 이제는 검토자가 자신 있게 승인할 수 있는 양보다 더 많은 발견 사항과 후보 수정안을 보유하는 경우가 점점 늘고 있다.

Google의 경험은 이미 이러한 압박을 보여준다. Chrome 보안팀은 2026년 3월까지 받은 버그 보고서가 2025년 전체 기간보다 많았다고 밝혔다.

회사는 외부 연구자들이 내부 발견 사항을 넘어선 가치를 더하는 작업을 제출하도록 취약점 보상 프로그램을 조정했다. 또한 자동화된 처리에 더 쉽게 들어갈 수 있는 보고서도 모색했다.

이 정책 변화는 독립 연구자에게 중요한 신호를 보낸다. AI는 일상적인 패턴 탐색을 흡수할 수 있지만, 창의적인 익스플로잇 개발과 컴포넌트 간 추론은 여전히 가치가 있다.

인간 연구자들은 복잡한 공격 체인, 이례적인 신뢰 가정, 의도된 제품 동작과 실제 제품 동작 사이의 격차에 집중할 수 있다. 이러한 영역은 반복적인 리포지터리 스캔으로 환원하기가 더 어렵다.

이에 따라 보안을 둘러싼 노동시장도 달라질 수 있다. 주니어 분석가는 일반적인 티켓을 수동으로 보강하는 데 드는 시간이 줄어들고, 시니어 엔지니어는 검토 기준과 아키텍처 결정에 대해 더 큰 책임을 지게 된다.

개발자 생산성은 모델 접근성만큼이나 정보 관리에 좌우될 것이다. 팀에는 발견 사항, 코드 이력, 위협 가정, 테스트 결과, 소유권, 릴리스 결정을 연결하는 검색 가능한 기록이 필요하다.

이러한 맥락이 없으면 AI 에이전트는 고립된 제안만 내놓는다. 맥락이 있으면 시스템은 발견 사항이 오래된 보고서의 중복인지, 또는 과거 설계 결정과 충돌하는지 판단할 수 있다.

이 메커니즘은 Amazon과 Google의 비교를 어느 회사가 가장 강력한 범용 모델을 제공하는지로만 축소할 수 없는 이유를 설명한다. 보안 성과는 기관의 기억을 기계 속도로 활용 가능하게 만드는 능력에 달려 있다.

이 증거를 가장 잘 정리하는 기업은 각 모델 호출의 관련성을 더 높일 수 있다. 또한 인간 검토자가 자동화된 작업을 수용하거나 거부할 때 더 명확한 근거를 제공할 수 있다.

기록적인 수정 건수가 입증하지 못하는 것

출시된 수정 건수가 많다는 점은 고무적이지만, 패치 품질, 익스플로잇 감소, 또는 지속적인 방어 우위를 입증하지는 않는다.

Google은 자사 워크플로에 대한 상세한 설명을 공개했지만, 몇 가지 중요한 측정치는 여전히 이용할 수 없다. 회사는 1,072개의 버그가 어떻게 발견됐는지에 대한 완전한 분석을 공개하지 않았다.

또한 모델에서 비롯된 발견 사항을 인간 보고서, 전통적인 퍼징 결과, 의존성 업데이트, 기존 백로그 항목과 공개적으로 구분하지 않았다. 전체 건수에 일관된 심각도 프로필을 부여하지도 않았다.

이러한 부재가 중요한 이유는 버그 건수가 매우 다른 보안 결과를 함께 포함할 수 있기 때문이다. 치명적인 원격 코드 실행 경로를 차단하는 것은 영향이 낮은 검증 오류를 수정하는 것과 동등하지 않다.

팀이 분류나 보고 관행을 바꾸면 수정 총계도 늘어날 수 있다. 조직은 하나의 근본 결함을 여러 티켓으로 나누거나, 관련 발견 사항을 하나의 수정으로 묶을 수 있다.

공개된 총계는 수정 사항이 Chrome 마일스톤에 도달했다는 제한된 의미에서는 여전히 사실이다. 그러나 이것만으로 얼마나 많은 위험이 사라졌는지는 독립적으로 드러낼 수 없다.

Google의 자체 설명은 보완적인 방법을 적절히 유지하고 있다. 회사는 퍼징이 코드베이스의 서로 다른 부분 간 장거리 상호작용으로 발생하는 결함을 찾는 데 여전히 효과적이라고 말한다.

인간 연구자도 Chrome의 취약점 보상 프로그램을 통해 전략의 일부로 남아 있다. 개별 결함을 찾는다고 해서 완전한 범위가 보장되지는 않으므로, 아키텍처 방어, 메모리 안전 언어, 런타임 보호는 여전히 필요하다.

가장 깊은 우려는 잘못된 확신과 관련된다. AI가 생성한 패치는 특히 그럴듯한 설명과 통과한 테스트가 함께 제시될 때 일관성 있어 보이는 경우가 많다.

그럼에도 패치는 또 다른 익스플로잇 가능 경로를 열어둘 수 있다. 또한 기존 테스트가 실행하지 않는 미묘한 회귀를 도입할 수도 있다.

Google은 승인 과정에 인간을 유지하고 있지만, 검토 역량은 유한하다. 후보 수정안이 숙련된 검토자의 가용성보다 더 빠르게 늘어나면 자동화된 작업을 수용하라는 압박이 이 안전장치를 약화시킬 수 있다.

비평 에이전트의 사용은 이 문제를 부분적으로 해결한다. 하지만 Google은 오탐, 놓친 취약점, 패치 회귀, 인간 검토 시간을 포괄하는 독립적인 비교 결과를 공개하지 않았다.

Gemini 3.5 Flash Cyber 결과도 자체 보고된 것이다. 벤치마크 설계는 학습 데이터 오염을 줄이기 위해 비공개 취약점을 사용하지만, 외부 연구자는 이 비공개 테스트를 완전히 재현할 수 없다.

배포 제한은 또 다른 미해결 상충관계를 드러낸다. Google은 사이버 역량의 이중용도 특성을 이유로, 처음에는 CodeMender를 통해 정부와 신뢰할 수 있는 파트너에게만 특화 모델을 제한한다.

방어자를 위해 취약점을 찾는 동일한 모델이 공격자가 취약점을 찾아 익스플로잇하도록 도울 수도 있다. DeepMind는 내부 실험에서 이 모델이 신뢰할 수 있는 원격 코드 실행 익스플로잇을 생성했다고 보고했다.

이 역량은 광범위한 접근을 위험하게 만든다. 하지만 이를 제한하면 고급 방어 도구가 대규모 조직에 집중되는 반면, 소규모 유지관리자는 점점 더 정교해지는 보고서를 계속 받게 된다.

Google은 오픈소스 대응 역량을 지원하고 있지만, 유지관리자는 여전히 비대칭에 직면한다. 자동화 에이전트는 수천 개의 프로젝트를 지속적으로 검색할 수 있는 반면, 작은 프로젝트에는 파트타임 검토자가 한 명뿐일 수 있다.

따라서 발견 사항이 많아지면 일시적으로 생태계의 보안이 더 약해질 수 있다. 공개된 수정 사항은 모든 다운스트림 사용자가 업데이트를 받기 전에 근본 약점을 노출할 수 있다.

이 기간은 패치 갭으로, 공격자가 공개된 변경 사항을 리버스 엔지니어링해 패치되지 않은 시스템을 노리는 때다. 발견 속도가 빨라질수록 이 기간을 줄이는 일이 더 중요해진다.

Chrome의 공개 security updates는 제공, 메모리 안전성, 의존성 최신 상태가 여전히 활발한 엔지니어링 과제임을 보여준다. AI는 이들 중 어느 것도 없애지 않는다.

이 기록이 릴리스 이전의 Chrome이 유난히 안전하지 않았음을 의미하지도 않는다. 더 높은 수정 건수는 이미 존재하던 결함을 더 잘 가시화한 결과일 수 있다.

반대로, 장기간 존재한 버그가 많이 발견됐다는 사실은 안일함을 막아야 한다. 13년 된 샌드박스 문제는 성숙하고 철저히 검토된 소프트웨어도 위험한 가정을 유지할 수 있음을 보여준다.

이 교훈은 Google을 넘어선다. Amazon, Microsoft, Apple, Mozilla 및 엔터프라이즈 소프트웨어 공급업체는 모두 새로운 컴포넌트와 상호작용하는 오래된 코드를 유지한다.

합리적인 해석은 축하도 경보도 아니다. AI는 수정 가능한 보안 작업의 관측 가능한 규모를 늘렸지만, 순위험 감소에 관한 증거는 여전히 불완전하다.

더 빠른 발견은 릴리스 속도를 새로운 격전지로 만든다

이제 보안은 적대자가 근본 결함을 재구성하고 익스플로잇하기 전에 패치가 실행 중인 브라우저에 도달하는지에 달려 있다.

Google은 취약점의 생애를 발견, 분류, 수정, 릴리스, 설치의 다섯 단계로 설명한다. AI는 초기 단계를 가속하지만, 마지막 단계가 완료되기 전까지 사용자는 보호받지 못한다.

Chrome의 오픈소스 개발 모델은 릴리스 시점을 특히 민감하게 만든다. 보안 수정 사항이 공개 코드에 들어가면 공격자는 취약한 동작에 대한 단서를 얻기 위해 변경 내용을 검사할 수 있다.

Google은 수정 사항이 일반적으로 메인 개발 트리에서 안정 채널로 이동하는 데 몇 주가 걸린다고 말한다. 심각한 수정 사항은 활성 안정 브랜치에 직접 병합될 수 있다.

Chrome은 주요 마일스톤에 대해 2주 주기로 전환하고 있으며, 여기에 주간 보안 업데이트가 수반된다. Google은 주 2회 보안 릴리스도 시범 운영하고 있다.

더 빠른 주기는 노출 기간을 줄이지만, 테스트와 엔터프라이즈 변경 관리에 더 큰 압박을 가한다. 관리자는 대규모 기기군 전체에 브라우저 변경을 배포하기 전에 호환성을 평가해야 하는 경우가 많다.

빈번한 릴리스는 업데이트 피로도 유발할 수 있다. 사용자는 탭, 양식, 통화 또는 진행 중인 작업을 유지하려 할 때 브라우저 재시작을 미룰 수 있다.

Chrome은 백그라운드에서 업데이트를 다운로드하고 준비하지만, 많은 변경 사항은 재시작 후에만 적용된다. Google은 분류, 수정, 테스트, 릴리스에 하루 또는 이틀밖에 걸리지 않을 때 이 지연이 상당해질 수 있다고 말한다.

회사는 전체 브라우저를 재시작하지 않고 특정 하위 프로세스를 교체하는 동적 패칭을 연구하고 있다. Chrome은 이미 멀티프로세스 아키텍처로 이들을 분리하므로, 렌더러와 그래픽스 프로세스가 잠재적 대상이다.

Chrome 150은 업데이트가 대기 중이고 열려 있는 창이 없을 때 브라우저를 자동으로 재시작하는 macOS 동작도 도입했다. 목표는 중단이 적은 시점에 보호를 적용하는 것이다.

이러한 제공 개선은 보이는 것보다 더 중요하다. 뛰어난 수정 사항을 만드는 AI 시스템도 보호된 소프트웨어가 디스크에서 비활성 상태로 남아 있다면 공격자를 능가할 수 없다.

따라서 엔터프라이즈 팀은 릴리스 발표만이 아니라 배포 데이터를 통해 브라우저 보안을 평가해야 한다. 어떤 기기가 오래된 버전을 실행하는지, 그리고 그 기기들이 얼마나 오래 뒤처져 있는지에 대한 가시성이 필요하다.

Amazon과 Google의 보안 경쟁은 이 운영 계층까지 이어진다. 두 회사 모두 분산된 엔드포인트, 클라우드 워크로드, 소프트웨어 의존성, 까다로운 가용성 요구 사항을 가진 조직에 서비스를 제공한다.

승리하는 플랫폼은 고객이 발견 사항을 소유권, 패치 검증, 단계적 배포, 검증 가능한 설치와 연결하도록 도울 것이다. 배포 증거가 없는 발견 사항은 미완성 보안 작업이다.

Microsoft의 경험은 이 추세가 브라우저를 넘어선다는 점을 시사한다. 2026년 7월의 대규모 보안 릴리스는 AI 지원 프로세스가 해결된 취약점의 급격한 증가와 연관됐기 때문에 주목을 받았다.

Associated Press 분석도 주요 AI 기업들이 고급 사이버 모델을 방어자에게 제공하려는 노력이 커지고 있다고 설명했다. Amazon, Apple, Google, Microsoft는 핵심 소프트웨어 위험에 초점을 맞춘 Anthropic 연계 이니셔티브에 참여했다.

이는 기업 보안 부서 간의 단순한 경쟁이 아니다. 공격자 역시 모델을 사용해 패치를 연구하고, 익스플로잇 변형을 생성하며, 관련 제품 전반에서 유사한 약점을 찾을 수 있다.

방어자에게는 몇 가지 구조적 이점이 있다. 이들은 소스 리포지터리, 테스트 인프라, 배포 시스템, 과거 버그 기록, 내부 아키텍처 문서를 통제한다.

공격자는 비대칭적인 목표를 유지한다. 방어자는 모든 중요한 경계를 보호해야 하지만, 공격자는 사용할 수 있는 경로 하나만 필요하다.

출시 속도는 이러한 불균형을 줄일 수는 있지만 없앨 수는 없다. 어떤 조직도 모든 결함이 악용되기 전에 이를 안정적으로 발견하고 패치할 수 없기 때문에 구조적 예방은 여전히 필요하다.

따라서 Google의 장기 전략에는 고위험 C++ 구성 요소를 다수의 메모리 오류를 컴파일 단계에서 방지하도록 설계된 언어인 Rust로 대체하는 방안이 포함된다.

또한 포인터 보호 기능을 확대하고, 안전하지 않은 포인터·크기 패턴을 컴파일러가 검사하는 span으로 전환하고 있다. Google은 현재 자체 개발 Chrome 코드의 97%가 엄격한 unsafe-buffer 경고 환경에서 컴파일된다고 밝혔다.

이러한 조치는 취약점을 개별적으로 처리하는 대신 취약점의 전체 범주를 줄인다. AI는 마이그레이션을 가속할 수 있지만, 지속적인 보호를 만들어내는 것은 아키텍처 변화다.

다음으로 의미 있는 기준점은 두 접근 방식을 모두 결합하게 될 것이다. 기업들은 에이전트가 복구 속도를 높이는 동시에 구조적 작업이 프로덕션에 유입되는 결함의 수와 영향을 줄인다는 점을 보여야 한다.

AI 보안이 작동하는지 보여줄 세 가지 신호

다음 단계는 또 다른 기록적 버그 수가 아니라 패치 품질, 배포 지연 시간, 지속적인 위험 감소로 평가해야 한다.

첫 번째 신호는 주당 두 차례 보안 릴리스를 진행한 Google의 경험이다. 이 파일럿은 Chrome이 허용하기 어려운 충돌, 회귀 또는 관리자 저항을 초래하지 않으면서 패치 공백을 줄일 수 있는지 시험할 것이다.

성공적인 파일럿은 발견 규모에 맞춰 전체 파이프라인을 확장할 수 있다는 Google의 주장을 강화할 것이다. 백로그가 늘어나거나 릴리스가 불안정해진다면 자동화가 제약을 단지 하류로 옮겼음을 보여줄 것이다.

검증된 발견 사항부터 설치된 안정 버전 업데이트까지 걸리는 시간을 지켜봐야 한다. 이 지표는 분류, 검토, 테스트, 릴리스, 사용자 재시작 행동을 하나의 실질적 결과로 포착한다.

두 번째 신호는 AI가 생성한 패치 품질에 관한 독립적 증거다. Google은 광범위한 가드레일, 비평 에이전트, 테스트 시스템, 인간 검토를 설명했지만 외부 검증은 여전히 제한적이다.

유용한 공개 정보에는 거짓 양성률, 회귀율, 검토자 투입 시간, 심각도 분포, 주요 수정 없이 채택된 모델 제안 수정의 비중이 포함될 것이다.

이러한 수치는 엔터프라이즈 구매자가 시연이 아닌 결과를 기준으로 보안 에이전트를 비교하는 데 도움이 된다. 또한 특화된 사이버 모델이 전체 작업량을 줄이는지, 아니면 전문가가 검토할 자료만 더 만들어내는지도 드러낼 것이다.

비교에는 성공한 패치와 놓친 결함을 모두 포함해야 한다. 일반적인 패턴은 찾지만 이례적인 신뢰 위반을 간과하는 시스템은 가장 위험한 공격 경로를 포괄하지 못하면서도 인상적인 합계를 기록할 수 있다.

세 번째 신호는 Amazon, Microsoft, Anthropic 및 다른 제공업체가 어떻게 대응하는지다. 이들의 제품에는 모델 추론, 비공개 코드, 테스트, 이슈 트래커, 의존성 인텔리전스, 통제된 배포 간의 유사한 연결이 필요하다.

Amazon은 클라우드 영향력과 Anthropic과의 관계 때문에 특히 주목할 만하다. Amazon이 고급 사이버 모델을 일상적인 개발 팀을 위한 감사 가능한 서비스로 전환한다면 amazon google 경쟁은 더욱 치열해질 것이다.

접근 정책도 이러한 대응의 일부가 될 것이다. 고성능 사이버 모델은 실제 이중용도 위험을 제기하지만, 제한적인 배포는 소규모 오픈소스 프로젝트에 충분한 방어 역량을 제공하지 못할 수 있다.

신뢰할 수 있는 업계의 해답은 통제된 접근과 유지관리자 지원을 결합해야 한다. 그렇지 않으면 자금이 더 풍부한 공격자와 대형 벤더는 자동화를 확보하는 반면, 핵심 커뮤니티 프로젝트는 보고 부담을 떠안게 된다.

독자들은 취약점 총수가 궁극적으로 감소하는지도 지켜봐야 한다. 일시적 증가는 에이전트가 수년간 누적된 결함을 발견하고 있다는 해석과 부합한다.

지속적인 증가는 여러 방식으로 해석될 수 있다. 모델이 더 깊은 문제를 계속 찾아낼 수도 있고, 새 코드가 더 빠르게 결함을 도입할 수도 있으며, 분류 관행이 계속 확대될 수도 있다.

가장 강력한 증거는 초기 발견이 많으면서도 프로덕션에 도달하는 심각한 취약점은 줄어드는 상황이다. Google은 이 목표를 위해 지속적 통합 및 커밋 큐 시스템에서 코드 변경 사항 스캔을 시작했다.

이들 모델은 코드가 반영되기 전에 댕글링 포인터, 숫자 안전성 문제, 안전하지 않은 버퍼 패턴을 표시한다. 또한 기존 정적 검사가 놓칠 수 있는 상호작용을 식별하기 위해 의미 분석도 사용한다.

Google은 Big Sleep과 CodeMender가 코드 변경 전반에서 24시간마다 실행된다고 밝혔다. 제출 시점에 가까운 곳으로 탐지를 옮기면 개발자가 주변 변경 사항을 여전히 이해하고 있어 복구 비용을 낮출 수 있다.

예방은 공개 패치 공백도 피하게 한다. 프로덕션 이전에 차단된 취약점은 긴급 업데이트나 리버스 엔지니어링과의 경쟁을 전혀 필요로 하지 않는다.

개발자에게 당장의 교훈은 실용적이다. 모델이 생성한 보안 보고서를 증거로 취급해서는 안 되며, 사람이 먼저 발견하지 못했다는 이유로 이를 무시해서도 안 된다.

재현, 명확한 신뢰 경계, 영향 평가, 표적 테스트, 독립 검토, 배포 증거를 요구해야 한다. 이후 에이전트가 조직의 이력을 바탕으로 추론할 수 있도록 이러한 자료를 보존해야 한다.

엔터프라이즈 구매자는 에이전트가 어디서 실행되고 어떤 파일에 접근할 수 있는지 물어야 한다. 네트워크 요청이 차단되는지, 기록되는지, 또는 대상별로 제한되는지도 확인해야 한다.

또한 서비스가 소스 보존, 모델 학습, 시크릿 노출, 생성된 익스플로잇, 에이전트 권한을 어떻게 처리하는지도 물어야 한다. 모델 주변의 보안 통제는 모델 자체만큼 면밀히 검토할 가치가 있다.

Google의 1,072건 수정은 AI가 성숙한 보안 조직의 처리량을 높일 수 있음을 보여준다. 그러나 자율 시스템이 그 조직을 안전하게 대체할 수 있음을 입증하지는 않는다.

이 구분은 amazon google 보안 경쟁의 다음 단계를 규정할 것이다. 모델은 풍부해지고 있지만, 신뢰할 수 있는 검토, 아키텍처 지식, 신속한 배포는 여전히 부족하다.

팀은 이제 발견부터 설치까지 자체 파이프라인을 점검해야 한다. 자동화된 보고서를 재현하고, 후보 수정안을 검토하고, 영향을 받는 환경을 테스트하며, 사용자가 수정 사항을 받았음을 입증할 수 있는가?

그 질문은 다음 헤드라인 수치보다 더 중요하다. 답이 여전히 불분명하다면 AI는 발견을 가속했을 뿐 방어를 완성하지 못한 것이다.