당신을 걱정시켜야 할 숫자

Chrome 149와 150 버전에는 총 1,072개의 보안 버그 수정 사항이 포함되었습니다. 이는 오타가 아닙니다. 이는 이전 23개의 주요 Chrome 릴리스에서 수정된 버그를 모두 합친 것보다 더 많은 수치입니다.

이 사실을 곱씹어 보십시오. 단 두 번의 릴리스 사이클이 세계 최고 수준의 보안 팀이 거의 2년 동안 내놓은 결과물을 앞질렀습니다. 만약 당신의 첫 번째 반응이 "와, AI는 정말 놀랍다"라면, 두 번째 반응은 "잠깐, 그럼 그 버그들 중 얼마나 많은 수가 지금까지 운영 환경(production)에 방치되어 있었던 거지?"가 되어야 합니다.

왜냐하면 이것이 바로 이 사건의 실체이기 때문입니다. AI가 더 나은 익스플로잇(exploit)을 작성한다는 것이 아니라, AI가 마침내 인간이 결코 할 수 없는 규모로 코드를 읽을 수 있을 만큼 충분히 발전했으며, Chrome의 코드베이스가 그 누구도 인정하고 싶지 않았던 수준의 리스크를 안고 있었다는 사실 말입니다.

13년 동안 모두를 이겼던 버그

가장 핵심적인 발견은 CVE-2026-3545로 추적되는 Chrome 샌드박스 탈출(sandbox escape) 버그이며, CVSS 점수는 9.8입니다. 이 버그는 침해된 렌더러(renderer)가 브라우저를 속여 디스크의 로컬 파일을 읽도록 만들 수 있게 했습니다. 이는 브라우저 보안에서 가장 악질적인 버그 클래스 중 하나인 완전한 샌드박스 탈출(sandbox breakout) 사례입니다.

이 버그는 코드베이스에 13년 이상 머물러 있었습니다. 코드 리뷰(code review)를 통과했고, 퍼징(fuzzing)도 통과했습니다. Chrome의 취약점 보상 프로그램(Vulnerability Reward Program)을 통해 보상금을 노리던 모든 외부 연구자들도 이 버그를 찾아내지 못했습니다. Google은 지난 5월 Chrome 145에서 이를 조용히 패치했으며, 이제서야 공개적으로 언급하기 시작했습니다.

13년이라는 시간은 이 버그가 현재 당신의 운영 스택(production stack)을 보호하고 있는 대부분의 보안 도구보다 앞선 시기에 존재했음을 의미합니다. 이는 OSS-Fuzz가 현재의 형태로 존재하기 전부터 있었습니다. Heartbleed 시대의 편집증, Spectre 시대의 편집증, 그리고 약 4세대의 정적 분석기(static analyzers)를 모두 견뎌냈습니다. 이 버그를 마침내 잡아낸 것은 더 똑똑한 인간이 아니었습니다. 전체 호출 그래프(call graph)를 한 번에 머릿속에 담을 수 있고, 3일째 되는 날에도 지루해하지 않는 에이전트(agent)였습니다.

실제로 내부에서 작동하고 있는 것

Google은 단순히 ChatGPT를 저장소(repo)에 연결해 놓고 요행을 바라는 것이 아닙니다. 실제적인 파이프라인이 존재하며, 여러분의 코드베이스에 무엇을 적용할 수 있을지 이해하려면 다음의 명칭들을 주목해야 합니다:

• Big Sleep — DeepMind 및 Project Zero와 함께 구축된 Gemini 기반의 취약점 발견 에이전트(vulnerability discovery agent)입니다. LLM에 단순한 코드 접근 권한 대신 취약점 연구를 위한 특화된 도구를 제공했던 2024년 Naptime 프로젝트의 후계자입니다.
• CodeMender — Chrome의 지속적 통합(CI) 환경에 직접 연결되어 있습니다. 단순히 릴리스 시점에만 작동하는 것이 아니라, 코드 변경 사항에 대해 24시간마다 실행됩니다.
• 수정 에이전트(fixing agent) → 비판 에이전트(critic agent) 루프 — 한 에이전트가 패치(patch)를 제안하면, 두 번째 에이전트가 인간의 코드 리뷰를 모방하여 회귀(regression)나 불완전한 수정 사항을 찾기 위해 이를 철저히 분석합니다. 이것은 모두가 간과하기 쉬운 부분이자 실제적인 혁신입니다. 단일 LLM이 패치를 생성하는 것은 위험 요소(liability)가 될 수 있습니다. 두 에이전트가 서로의 작업을 적대적으로(adversarially) 검증하는 것이 하나의 프로세스입니다.
• OSS-Fuzz — 여전히 작동 중이며, AI가 취약한 버그 클래스들을 여전히 찾아내고 있습니다. Google은 퍼징(fuzzing)이 장기적인 상호작용 버그(long-range interaction bugs)에 대해 여전히 "특히 효과적"이라고 명시하고 있습니다. AI가 퍼징을 대체한 것이 아닙니다. AI는 백로그(backlog)를 대체한 것입니다.

이 비판 에이전트(critic-agent)에 대한 세부 사항은 Google의 예산이 없더라도 여러분의 팀에 도입할 만한 가치가 있습니다:

def review_patch(candidate_fix, original_code, cve_context):
    # 에이전트 1: 그럴듯한 수정안 생성
    patch = fixer_agent.propose(candidate_fix, cve_context)
...

단일 에이전트에게 "수정안을 작성해줘"라고 하는 것은 데모(demo)에 불과합니다. 두 에이전트의 적대적 리뷰(adversarial review)가 하나의 파이프라인(pipeline)입니다. 만약 여러분이 자신의 취약점 수정 워크플로우에 LLM을 결합하면서 비판(critic) 단계를 건너뛰고 있다면, 여러분은 파이프라인이 아닌 데모를 만들고 있는 것입니다.

Google 블로그 포스트가 과소평가하고 있는 부분

트리아지(Triage, 우선순위 분류). 발견(discovery)이 아니라 — 트리아지입니다.

모든 보안 팀의 진정한 병목 현상(bottleneck)은 결코 "버그를 찾을 수 없다"가 아니었습니다. 그것은 바로 "400개의 버그를 찾았는데, 그중 어떤 것이 중요한지 판단할 엔지니어가 4명뿐이다"라는 점입니다. Google은 자동화된 트리아지(automated triage) — 보고서를 필터링(filtering), 재현(reproducing), 보강(enriching) 및 할당(assigning)하는 과정 — 가 "매달 수백 시간의 개발자 시간을 절약하고 있다"라고 말하며, 이를 정확하게 측정하기는 어렵다는 점을 솔직하게 인정하고 있습니다.

이러한 인정은 대부분의 AI 보안 마케팅보다 더 정직하며, 이것이 단순한 벤더의 발표 자료(vendor deck)가 아니라 실제 상황임을 알려주는 세부 사항입니다. 아무도 지루한 작업들을 정확하게 측정하지 않는 이유는, 바로 그 지루한 작업들이 그동안 실제 레버리지(leverage)가 숨어 있던 곳이기 때문입니다. 발견(discovery)은 매력적인 헤드라인이지만, 트리아지(triage)는 수년 동안 매달 시니어 엔지니어 한 명의 한 달 치 업무량을 조용히 갉아먹고 있었던 병목 현상입니다.

이것이 보안 팀뿐만 아니라 릴리스 주기(release cadence)를 바꾸는 이유

Google은 Chrome을 주간 보안 업데이트를 포함한 **2주 단위의 메이저 릴리스 주기(two-week major release cadence)**로 전환하고 있으며, **주 2회 보안 릴리스(two security releases per week)**를 시범 운영하고 있습니다. 또한 브라우저를 완전히 재시작하지 않고도 수정 사항을 적용하는 "동적 패칭(dynamic patching)"을 구축하고 있습니다.

행간의 의미를 읽어보십시오: AI 파이프라인은 단순히 더 많은 버그를 찾아낸 것이 아니라, 버그를 찾고 수정 사항을 배포하는 과정의 _경제성(economics)_을 깨뜨렸습니다. 트리아지와 패치 생성(patch generation)이 더 이상 병목 현상이 아니게 되면, 여러분의 릴리스 주기는 엔지니어링의 제약 사항이 아닌 비즈니스 결정의 영역이 됩니다. 만약 여러분이 여전히 "보안 검토 속도가 그 정도라서" 매달 업데이트를 배포하고 있다면, 그것이 정말 사실인지, 아니면 이런 도구가 존재하기 전부터 이어져 온 관성(inertia)인지 스스로에게 물어보십시오.

아무도 트위터에 올리지 않는 함정

Google은 실제 가드레일(guardrails)을 갖추고 이를 운영하고 있으며, 이를 명시할 가치가 있습니다. 왜냐하면 이를 모방하려는 대부분의 팀이 이 모든 과정을 건너뛸 것이기 때문입니다:

• AI는 **완전 격리된 상태 (strictly at rest)**에서, 인터넷 접속이 차단된 폐쇄된 머신 상에서 소스 코드를 엄격하게 분석합니다.
• 모델은 절대 제한 없는 모드 (unrestricted mode)로 실행되지 않습니다.
• 엄격한 허용 목록 (allowlists)이 네트워크 요청을 가로채며, 이상 징후는 자동으로 차단됩니다.
• 하위 에이전트 (Subagents)는 할당된 소스 디렉토리 외부의 시스템이나 파일에 접근할 수 없습니다.

이것은 편집증이 아니라, 보안이 중요한 코드베이스에 자율 에이전트 (autonomous agent)를 투입하기 위해 지불해야 하는 실제 입장료입니다. 만약 당신의 계획이 "에이전트에게 셸 접근 권한 (shell access)을 주고 무엇을 찾아내는지 보자"라면, 당신은 프롬프트 인젝션 (prompt injection) 한 번에 당신의 수정 에이전트 (fixer agent)가 공격자의 프록시 (proxy)로 변하는 상황을 맞이하게 될 것입니다. Google은 샌드박스 탐지기 (sandbox-finder)를 둘러싼 샌드박스 (sandbox)를 구축하는 데 실제 엔지니어링 노력을 기울였습니다. CVE 번호보다 덜 흥미롭다고 해서 이 단계를 건너뛰지 마십시오.

실제 시사점

AI가 Chrome을 안전하게 만든 것이 아닙니다. AI는 Google의 기존 20년 보안 투자 — Project Zero, OSS-Fuzz, VRP, 그리고 전설적으로 뛰어난 팀 — 가 마침내 코드베이스가 필요로 하는 속도로 작동할 수 있게 만들었습니다. 13년 된 버그는 AI가 마법이라는 증거가 아닙니다. 그것은 인간만으로 구성된 최고의 보안 프로세스조차 한계가 있으며, Chrome의 코드베이스가 10년 넘게 그 한계 위에서 조용히 존재해 왔음을 증명하는 것입니다.

만약 당신이 2026년에 이러한 종류의 에이전트 파이프라인 (agent pipeline) 없이 보안 팀을 운영하고 있다면, 당신은 AI 유행에 뒤처진 것이 아닙니다. 당신은 분류 처리량 (triage throughput)에서 뒤처진 것이며, 그것은 언제나 당신을 가장 먼저 괴롭히게 될 지표입니다.

출처: Google의 공식 보고서, BleepingComputer, SecurityWeek