1,072개를 고친 브라우저 — 병목은 사라지지 않고 이사를 갑니다

1913년 미국 미시간주 하이랜드파크. 헨리 포드의 공장에 이동식 조립라인이 들어섰습니다. 사람이 자동차를 찾아가는 대신 자동차가 사람 앞으로 흘러오게 만들자, 섀시 한 대를 조립하는 시간이 열두 시간 반에서 한 시간 반 남짓으로 줄었습니다.

그런데 라인이 빨라지자 예상 못 한 일이 생겼습니다. 조립을 마친 차가 공장 뒤편에 쌓이기 시작한 것입니다. 범인은 페인트였습니다. 당시 자동차 도료는 마르는 데 며칠이 걸렸고, 앞 공정이 빨라진 만큼 건조장은 병원 대기실처럼 붐볐습니다. 포드의 해법은 유명하지요. 빨리 마르는 검은색 에나멜 하나로 색을 통일해버린 것입니다. "어떤 색이든 좋습니다. 검은색이라면."

기술의 역사가 반복해서 가르쳐주는 교훈이 여기에 있습니다. 병목은 해결되는 것이 아니라 이사를 갑니다. 한 공정을 열 배 빠르게 만들면, 그 뒤에 조용히 서 있던 가장 느린 공정이 새 주인공으로 올라섭니다.

2026년 7월 30일, 구글이 크롬 보안에 관한 발표를 하나 내놓았습니다. 저는 이 발표를 읽으면서 하이랜드파크의 페인트 건조장을 떠올렸습니다.

구글은 보안 블로그에서, 최근 두 마일스톤인 크롬 149와 150에서 보안 버그 1,072개를 수정했다고 밝혔습니다. 직전 23개 마일스톤에서 고친 것을 모두 합친 수보다 많습니다. 2년 가까이 걸려 잡던 양을 두 번의 릴리스에 몰아 잡은 셈입니다.

무엇이 달라졌는가. 구글은 2026년 초부터 Gemini와 다른 모델들을 엮은 '에이전트 하네스(agent harness)'를 만들어 크롬 코드베이스 전반을 훑게 했다고 설명합니다. 자기 표현으로는 "더 높은 효율과 더 낮은 오탐"입니다. 다만 한 가지는 분명히 해두겠습니다. 구글이 저 1,072개를 전부 AI가 찾아냈다고 못 박은 것은 아닙니다. SecurityWeek는 급증 시점과 정황이 AI를 시사할 뿐, 인과를 구글이 명시하지는 않았다고 유보했습니다. 숫자는 사실이고, 원인은 강한 정황입니다.

▸ 스캔하고, 진짜로 터뜨려보고, 고친다

이 파이프라인에서 눈여겨볼 이름은 Big Sleep과 CodeMender입니다. Big Sleep은 2024년 Project Zero와 DeepMind가 함께 공개한 취약점 탐색 에이전트인데, 2025년 크롬에 투입되어 V8 자바스크립트 엔진과 그래픽 스택의 버그를 찾아냈습니다. 지금은 두 도구가 모두 CI 시스템 안에 들어앉아 24시간마다 모든 코드 변경을 훑습니다.

특히 CodeMender의 동작 방식이 인상적입니다. 스캔하고, 검증하고, 수정합니다. 메모리 손상이나 인젝션 같은 후보를 찾아낸 다음, 실제로 익스플로잇을 작성해 샌드박스에서 실행해봅니다. 터지면 진짜 버그이고, 안 터지면 오탐으로 버립니다. 그리고 통과한 것에 대해 패치를 코드 diff로 제출해 사람 개발자의 승인을 받습니다.

정적 분석 도구가 수천 건의 "의심스러움"을 쏟아내던 시절과 결정적으로 다른 지점이 여기입니다. 리포트가 아니라 증명과 수정안이 함께 옵니다. 성과도 상징적입니다. 손상된 렌더러가 브라우저를 속여 로컬 파일을 읽게 만드는 샌드박스 탈출 취약점 하나가 발견됐는데, 이 버그는 13년 넘게 코드 안에 조용히 살아 있었습니다. 2026년 5월 한 달만 보면 20건 이상이 프로덕션에 도달하기 전에 차단됐고, 그중 하나는 최고 등급이었습니다.

▸ 그래서 병목은 어디로 갔을까 : 4주에서 2주로

자, 이제 이 글의 본론입니다. 24시간마다 코드를 훑는 기계가 CI 안에 상주하면, 병목은 더 이상 '찾기'가 아닙니다. 찾아낸 것을 사용자의 브라우저에 꽂아넣는 일이 새 병목이 됩니다. 고쳐놓은 패치가 저장소에 앉아 릴리스를 기다리는 동안, 그 취약점은 여전히 세상에 열려 있는 문이니까요.

구글의 다음 행보가 정확히 그 방향입니다. 크롬은 2026년 9월 8일 버전 153부터 마일스톤 주기를 4주에서 2주로 줄일 예정입니다. 데스크톱과 안드로이드, iOS가 모두 대상이고 마일스톤 사이의 주간 보안 업데이트는 그대로 유지됩니다. 여기서 더 나아가 주 2회 보안 릴리스도 파일럿 형태로 검토되고 있고, 업데이트를 적용하려고 브라우저를 다시 시작하지 않아도 되게 만드는 구상까지 거론된다고 합니다. 아직 확정된 것은 없습니다. 다만 방향은 한쪽으로 뚜렷합니다. 발견의 속도가 배포의 속도를 앞질렀으니, 배포를 갈아엎겠다는 것입니다.

포드가 조립 속도를 얻은 대가로 색깔의 선택을 포기했다는 사실을 기억하실 겁니다. 병목을 옮길 때는 늘 무언가를 내놓아야 합니다. 크롬이 내놓는 것은 릴리스의 안정감입니다.

▸ 선물이자 청구서 : 축하하기 전에 짚어야 할 것들

그렇지만 한 발 물러서 보면, 이 발표를 그대로 승리 선언으로 읽기는 어렵습니다.

첫째, 발견 수는 안전의 지표가 아닙니다. 1,072개의 심각도 분포는 공개되지 않았고, 그중 몇 개가 실제로 악용 가능했는지도 알 수 없습니다. 숫자는 틀리지 않았지만, 그 숫자가 전부를 말해주지도 않습니다. 게다가 이 발표의 1차 출처는 구글 자신의 홍보 채널입니다.

둘째, 패치 부담이 이전됩니다. 브라우저 벤더가 빨리 고칠수록 검증과 배포, 재기동은 그것을 쓰는 조직의 일이 됩니다. 2주 릴리스는 선물이면서 동시에 청구서입니다.

셋째, 사람 쪽에서 벌어지는 일도 있습니다. 구글은 크롬 버그바운티 보상을 내리고 안드로이드를 올렸습니다. 일부 크롬 버그 보상이 종전의 10분의 1 수준이라는 연구자 지적이 나왔습니다. 물론 풀체인 익스플로잇은 여전히 최대 25만 달러(약 3억 5천만 원)이고, 구글은 2025년에 사상 최대인 1,710만 달러를 지급했다고 밝혔습니다. 그래도 저는 걱정이 남습니다. AI가 잡는 버그와 세계 최상위권 연구자가 잡는 버그는 같은 종류가 아닙니다. 앞의 것이 흔해질 때 뒤의 사람들이 어디로 가는지를, 회색 시장과 흑색 시장이 늘 지켜보고 있습니다.

넷째, AI가 새 공격면을 함께 들여왔습니다. 같은 브라우저에서 악성 확장이 Gemini Live 패널을 탈취할 수 있는 취약점(CVE-2026-0628, CVSS 8.8)이 보고됐습니다. 그리고 크롬은 2026년에 실제로 악용된 제로데이를 다섯 건 맞았습니다. V8 자바스크립트 엔진만이 아니라 그래픽 라이브러리와 WebGPU 구현까지 번갈아 뚫렸습니다. 방어자가 도구를 손에 쥔 만큼 공격자도 쥐고 있다는 뜻입니다.

▸ 속도 격차가 곧 노출 시간입니다

이 이야기가 한국의 실무 현장에 닿는 지점은 아주 구체적입니다.

국내 금융과 공공 환경을 떠올려보십시오. 표준 브라우저 버전이 고정돼 있고, 내부 웹 애플리케이션 호환성 검증 절차가 붙어 있고, 폐쇄망 구간은 업데이트 배포 자체가 별도 작업입니다. 크롬이 2주마다 마일스톤을 내보내도, 조직의 검증 사이클이 6주라면 그 조직의 실질 패치 주기는 6주입니다. 그 사이의 간격이 무엇인지 냉정하게 이름을 붙여야 합니다. 그것은 지연이 아니라 노출 시간입니다.

브라우저 벤더가 8주 지원의 Extended Stable을 남겨둔 것도 이 현실을 알기 때문입니다. 다만 그것은 유예이지 해결이 아닙니다. 앞으로 몇 년, 보안 조직의 실력은 취약점을 찾아내는 능력보다 남이 찾아준 수정을 얼마나 빨리 안전하게 삼킬 수 있는지로 갈릴 가능성이 큽니다. 우리가 흔히 말하는 정보보호 인력난도 AI 덕에 줄어드는 게 아니라 모양이 바뀌는 것이지요. 찾는 사람이 아니라 판정하고 배포하는 사람이 부족해집니다.

1969년, 에츠허르 데이크스트라는 이런 말을 남겼습니다. "프로그램 테스팅은 버그의 존재를 보여줄 수 있을 뿐, 부재를 증명하지는 못한다." 1,072개를 고쳤다는 사실은 크롬이 안전해졌다는 증명이 아닙니다. 그동안 그만큼이 거기 있었다는 증명이고, 앞으로도 계속 나올 것이라는 예고입니다.

포드의 라인은 결국 페인트 문제까지 풀고 하루 수천 대를 뽑아냈습니다. 그리고 그다음에는 판매망이, 그다음에는 도로가 병목이 됐지요. 병목은 늘 앞으로 도망갑니다. 구글이 배포의 병목을 부수고 나면, 다음 병목은 아마 우리 쪽에 서 있을 것입니다. 여러분의 조직에서 패치는 지금 어디에 줄 서서 기다리고 있습니까.