구글이 7월 30일 공식 블로그에서 밝힌 수치는 단순한 자랑거리가 아니다. Chrome 149와 150, 최근 두 개 마일스톤에서 고친 보안 버그가 1072건으로, 그 이전 23개 마일스톤에서 고친 버그를 모두 합한 것보다 많다. 이 변화를 이끈 것은 Gemini 기반 에이전트로, 버그를 찾아내는 단계부터 분류하고 고치고 배포해 실제로 사용자 컴퓨터에 적용되기까지 다섯 단계 전체에 관여하고 있다.
구글은 보안 버그의 일생을 발견(found) → 분류(triaged) → 수정(fixed) → 배포(release) → 적용(apply) 다섯 단계로 나누고, 이 각 단계를 얼마나 빠르게 통과시키느냐가 목표라고 설명한다.
13년 넘게 숨어 있던 버그를 어떻게 찾아냈나
Chrome 보안팀의 LLM 활용은 갑자기 시작된 것이 아니다. 2023년에는 LLM으로 보안 퍼징(무작위 입력을 넣어 결함을 찾는 테스트)의 범위와 성능을 늘리는 방법을 개발했고, 2024년에는 Project Zero와 함께 LLM에 취약점 연구용 전용 도구를 붙인 'Naptime'을 만들었다. 2025년에는 DeepMind, Project Zero와 함께 'Big Sleep'을 내놓아 V8 자바스크립트 엔진과 그래픽 스택에서 실제 버그를 찾아냈다.
2026년 초에는 Gemini를 활용한 새 에이전트 하네스를 만들어 Chrome 코드베이스 전반에서 더 높은 효율과 더 적은 오탐으로 취약점을 찾기 시작했다. 이 에이전트가 찾아낸 것 중에는 손상된 렌더러가 브라우저를 속여 로컬 파일을 읽게 만드는 샌드박스 탈출 버그가 있었는데, 코드베이스에 13년 넘게 조용히 남아 있던 결함이었다.
이후 구글은 이 에이전트 하네스를 다음과 같이 개선했다. 오픈웨이트 모델과 독점 모델을 함께 쓸 수 있게 모델 상호운용성을 추가했고, 기존에 확인된 모든 CVE와 Chrome의 전체 Git 히스토리를 담은 지식 베이스를 구축해 모델의 추론 범위를 학습 데이터 밖으로 넓혔다. 또 개발자들에게 신뢰 경계와 위협 모델을 명확히 담은 SECURITY.md 파일 작성을 권장하고, 이 파일을 별도 컨텍스트에서 참고하는 '크리틱' 에이전트를 추가했으며, 모델의 비결정성과 시간에 따른 성능 개선을 반영하기 위해 같은 코드베이스를 여러 번 스캔하는 기능도 넣었다.
안전장치도 함께 설계했다. AI는 소스코드를 정지 상태로만 분석하며, 일반 인터넷 접속이 차단된 폐쇄망에서 동작한다. 이 내부 스캔 전용 환경은 모든 네트워크 요청을 가로채 요청 애플리케이션과 목적지 기준의 엄격한 허용목록만 통과시키고, 의심스러운 모델 행동은 차단한다. 모델을 무제한 모드로 실행하지 않으며, 서브에이전트가 지정된 소스코드 디렉터리 밖의 파일에 접근하거나 로컬 시스템을 수정하는 것도 엄격히 제한한다.
외부 연구자 대상 취약점 보상 프로그램(VRP)에도 변화가 생겼다. 2026년 초부터 모든 범주에서 제보가 점진적으로 늘더니 3월에는 그해 누적 제보 건수가 2025년 한 해 전체를 넘어섰다. 이에 구글은 VRP 기준을 바꿔, 내부적으로 이미 찾아내는 것과 겹치지 않고 자동화된 처리 파이프라인이 소화하기 쉬운 제보에 연구자들이 집중하도록 유도하고 있다.
사람이 건당 30분 걸리던 분류를 4단계 자동화로 대체
취약점 발견량이 늘면서 구글은 검증·분류·수정 단계도 AI로 함께 확장했다. 기존에는 보안 제보 하나를 분류하는 데 5분에서 30분 이상이 걸렸고, 대부분 사람의 전문성에 의존했다. 지금은 규칙 기반 시스템과 AI를 함께 쓰는 자동 분류 체계로 처리량과 정확도를 동시에 높이고 있다.
자동 분류는 네 단계로 진행된다. 첫째, 노이즈 필터링 단계에서 스팸 여부, 중복 여부 등 접수 기준 충족 여부, Chrome 보안 취약점을 명확히 기술했는지를 확인한다. 둘째, 재현 단계에서는 개념 증명(PoC)이 있는지 확인하고, 재현 가능한 버그는 영향을 받는 운영체제·브라우저 버전에서 실제로 테스트한 뒤 스택 트레이스 같은 세부 정보를 첨부해 수정에 참고하도록 한다. 셋째, 메타데이터 보강 단계에서는 버그가 처음 유입된 시점, 심각도 등급 같은 필수 정보를 채웁니다. 심각도 가이드라인을 자동 적용하기 쉽게 다듬었고, 개발자가 등급이 잘못됐다고 판단하면 직접 수정할 수 있으며 SECURITY.md 파일로 모델이 보안 경계를 더 잘 추론하도록 돕는다. 넷째, 자동 배정 단계에서 이슈를 올바른 컴포넌트와 담당자에게 자동으로 라우팅한다.
정확히 측정하기는 어렵지만, 구글은 이 새 프로세스가 매달 수백 시간의 개발자 시간을 절약하고 있으며, 그 시간을 다른 보안 우선순위 작업에 돌리고 있다고 설명한다.
사람이 검토하기 전에 에이전트끼리 후보 수정안을 검증한다
버그를 고치는 단계는 멀티 에이전트 워크플로로 짜여 있다. 특정 이슈의 맥락을 가져오는 초기 빌드 단계 이후, '수정 에이전트'가 여러 개의 후보 수정안을 만들어 낸다. 이어서 '크리틱 에이전트'가 어떤 안이 가장 적합한지 평가하고, 개발자가 수정안을 검토할 때 참고할 자료를 함께 만든다. 수정 에이전트와 크리틱 에이전트는 일반적인 코드 리뷰 과정을 흉내 내는 루프를 돌며 코드가 실제로 동작하는지, Chromium과 구글 스타일 가이드 및 다른 로컬 코드 관행을 지키는지 확인한다. 여기에 '테스트 작성 에이전트'가 더해져 개발자가 수정안을 검토하기도 전에 Chrome이 지원하는 모든 플랫폼과 설정에서 테스트가 통과하는지 확인하는데, 이 과정만으로 개발자 작업 시간을 최대 몇 주까지 절약한다고 설명한다.
그 결과가 앞서 말한 수치다. Chrome 149와 150 두 마일스톤에서 고친 보안 버그가 1072건으로, 이전 23개 마일스톤에서 고친 버그를 모두 합한 것보다 많다. 구글은 DeepMind, Project Zero와 함께 만든 BigSleep, CodeMender도 지속적통합(CI) 시스템에 통합해 모든 코드 변경 목록(CL)에 대해 24시간마다 실행하고 있으며, 5월 한 달 동안만 치명적 등급인 S1+ 취약점 1건을 포함해 20개가 넘는 취약점이 프로덕션에 도달하기 전에 막았다.
고친 패치를 사용자에게 더 빨리 보내는 방법
패치가 공개 오픈소스 트리에 반영된 뒤부터 실제 사용자에게 도달하기 전까지는 공격자가 그 변경 내역을 역공학해 먼저 익스플로잇을 만들 여지가 생긴다. 이를 'N-day' 공격이라 부르고, 그 사이 간격을 '패치 갭'이라 부른다. 메인 트리에 반영된 수정이 대다수 사용자가 쓰는 Chrome 안정 채널에 도달하기까지 보통 몇 주가 걸렸기 때문에, 이 간격을 줄이는 것이 핵심 전략이다.
심각도에 따라 보안 수정은 메인 트리에서 안정 배포 브랜치로 직접 병합되며, 이 브랜치는 새로운 크래시나 회귀가 없는지 계속 모니터링된다. 구글은 주요 Chrome 마일스톤 주기를 2주로 전환하는 중이며 매주 보안 업데이트를 내보내고 있다. 여기서 한 걸음 더 나아가, 빠르게 움직이는 AI 기반 공격에 대응하기 위해 주 2회 보안 릴리스로 전환하는 것을 시범 운영하고 있다. 내부에서 찾았든 외부에서 제보받았든 Chrome 안정 채널에 반영되는 모든 보안 버그는 표준적으로 문서화하고 공개하며, 릴리스 노트와 CVE 설명 작성도 자동화해 발견부터 공개까지의 시간을 줄이는 작업을 진행 중이다.
재부팅 없이 패치를 적용하는 방법
Chrome은 2008년 백그라운드에서 조용히 새 바이너리를 내려받아 대기시키는 무음 업데이트 방식을 처음 선보였다. 다음에 브라우저를 재시작할 때 업데이트가 적용되고 사용자가 보호받는 구조다. 문제는 분류·수정·테스트·배포까지 걸리는 1~2일에 비해, 사용자가 재시작을 미루는 시간이 N-day 노출 위험에서 상당한 비중을 차지한다는 점이다.
재시작이 번거롭고 일정 조율이 필요하며 우선순위에서 밀리는 것은 자연스러운 일이기 때문에, 구글은 그 부담을 사용자에게서 덜어내는 방향을 연구하고 있다. 첫째, '동적 패칭'으로 대부분의 경우 전체 브라우저 재시작 자체를 없애는 것을 목표로 한다. Chrome의 멀티프로세스 구조를 활용해 렌더러·GPU 같은 백그라운드 자식 프로세스를 실행 중에 순차적으로 최신 바이너리로 교체하는 방식으로, 아직 연구·개발 단계다. 둘째, 더 많은 상태를 로컬에 저장해 복잡한 경우에도 세션을 매끄럽게 복원하는 방법을 찾고 있다. 셋째, 안전하게 세션을 복원할 수 있는 시점을 찾아 자동으로 재시작한다. 예를 들어 Chrome 150에서는 macOS에서 모든 창을 닫아도 애플리케이션이 백그라운드에서 계속 실행되는 특성을 활용해, 이 '창 없는 상태'에서 대기 중인 업데이트가 있으면 자동으로 재시작하도록 바꿨다.
기업 사용자를 위한 권장 사항도 함께 안내한다. IT 관리자는 대기 중인 업데이트 적용을 위해 재시작을 안내하고 일정 시간이 지나면 강제 재시작으로 단계를 높이는 RelaunchNotification 정책을 적용하거나, 변경 사항을 반드시 검증해야 하는 민감한 환경에는 Chrome Extended Stable 채널을 쓰거나, Chrome Enterprise Core나 Premium이 제공하는 OS 무관 대시보드로 전체 브라우저 버전 현황을 더 세밀하게 추적할 수 있다.
버그 자체를 줄이는 장기 전략: 메모리 안전과 Rust
구글은 개별 버그를 고치는 것을 넘어 버그 유형 전체를 없애는 데도 투자하고 있다. Chrome은 이중 메모리 안전 전략을 실행 중이다. 하나는 레거시 C++ 취약점을 무력화하도록 런타임 환경을 강화하는 것이고, 다른 하나는 장기적인 구조적 회복력을 위해 메모리 안전 언어로 옮겨가는 것이다.
Chromium 코드베이스 대부분은 여전히 C++로 되어 있어 즉각적인 툴체인·런타임 완화가 1차 방어선이다. Use-After-Free(UAF) 취약점을 무력화하는 MiraclePtr 계열 기술을 이미 대규모로 적용했고, 이를 Skia, ANGLE, Dawn, C++ 이터레이터, std:: 컨테이너로 확장하고 있다. GPU 메인 스레드에서는 MiracleObject로 UAF 취약점의 최대 90%를 무력화하는 것을 목표로 하며, 이를 위해 국지적인 런타임 성능을 일부 포기하는 선택을 하고 있다. 공간 안전(Out-of-Bounds) 오류를 없애기 위한 '스패니피케이션' 작업도 진행 중으로, 현재 1차 Chrome 코드의 97%가 엄격한 unsafe-buffer 경고를 통과하며 이 요구를 Skia, ANGLE, Dawn 같은 기반 코드베이스로 확장하고 있다. 여기에 메모리 할당과 관련된 계산에는 checked math를 적용해 정수 오버플로를 막고, 포인터를 담는 타입과 그렇지 않은 타입을 힙에서 분리하는 파티셔닝도 추가하고 있다.
런타임 완화는 몇 년 안에 한계 수익이 줄어들 것으로 보고, 장기적으로는 Rust로 코드베이스를 옮기는 것을 핵심 해법으로 삼고 있다. 개발자가 새 언어 생태계의 속도 저하를 전부 떠안지 않도록 Chromium API와 도구를 Rust에 노출하는 중앙 집중형 Rust SDK를 구축하고 있고, 복잡한 파서·이미지 코덱·폰트 스택처럼 역사적으로 버그가 몰려 있던 코드 구간을 전략적으로 Rust로 교체하며, 새 모듈형 컴포넌트를 Rust로 작성해 브라우저 프로세스처럼 높은 권한을 가진 프로세스 안에서도 샌드박싱에 따른 성능 손실 없이 복잡한 기능을 안전하게 실행하는 방향을 추진하고 있다. 브라우저 최상위 UI를 HTML, CSS, TypeScript로 구현해 전통적인 C++ 프레임워크 의존을 더 줄이는 방안도 검토 중이다.
버그가 코드에 반영되기 전에 잡아내는 작업도 병행한다. 지속적통합(CI)과 커밋 큐(CQ) 파이프라인에 들어간 방어용 모델이 diff 단위로 스패니피케이션 수정을 제안하고, 댕글링 포인터를 표시하고, 숫자 안전성을 강제하는 식으로 코드 제출 시점에 최대한 가깝게 취약점을 막는다. 특히 다른 곳에서는 안전하던 코드가 전혀 무관한 사소한 변경 하나로 치명적 취약점이 되는 '잠재적 보안 이슈'는 전통적인 정적 분석으로 놓치기 쉬운데, CQ 안에서 LLM 기반 의미 분석을 지속적으로 돌려 이런 복합 위험을 코드가 트리에 반영되기 전에 가로채고 있다.
크롬 밖 오픈소스 생태계에도 투자한다
Chrome을 지키는 일은 Chrome 자체를 넘어선다. 구글은 최근 메인테이너가 취약점 제보에 빠르게 대응할 수 있도록 지원하는 Alpha-Omega 프로젝트에 다른 기업들과 함께 1250만 달러를 기부했다. 또 업스트림 메인테이너의 부담을 덜기 위해 취약점 제보를 위한 중앙 창구와 보안 사고 대응팀을 제공하는 Akrites 프로젝트의 창립 멤버로도 참여하고 있다.
Chromium과 V8 자바스크립트 엔진, BoringSSL 암호화 라이브러리, Skia·ANGLE·Dawn 같은 그래픽 구성 요소를 포함한 위성 프로젝트를 합치면 서드파티 의존성이 2300개가 넘고, 이 중 약 1700개는 안드로이드 기기부터 엣지 컴퓨팅, 대규모 클라우드 엔터프라이즈 스택까지 실제 사용자에게 다양한 형태로 배포된다. 이 의존성들을 최신 상태로 유지하기 위해 구글 내부 피드와 함께 미국 정부의 국가 취약점 데이터베이스(NVD), 오픈소스 취약점 데이터베이스(OSV) 같은 외부 피드를 결합한 자동 스캔 파이프라인을 운영하고 있다. 올해부터는 서드파티 의존성을 최신 업스트림 버전으로 선제적으로 올리는 자동 업데이트 파이프라인으로 옮기는 작업을 시작했고, 이 과정에서 발생할 수 있는 다른 위험을 점검하기 위해 구글의 오픈소스 보안 인텔리전스 플랫폼(GOSSIP)이 제공하는 안전 신호도 함께 활용한다.
출처: Google, Stronger with every update: How we're making Chrome and the web safer in the AI Era