필사 모드: AI가 6월 한 달에 2년치 크롬 버그를 잡은 방법 — 1,072개라는 숫자를 읽는 법

• 들어가며 — 1,072 대 1,036
• 계보 — 2023년의 퍼즈 타깃 생성에서 2026년의 에이전트 하네스까지
• 왜 하필 거대한 C++ 코드베이스의 메모리 안전 버그인가
• 이 숫자가 말하는 것과 말하지 않는 것
• 병목은 발견에서 배포로 옮겨 갔습니다
• 크롬 규모가 아닌 팀이 실제로 복사할 수 있는 것
• 마치며 — 많이 찾았다는 것은 내내 거기 있었다는 뜻입니다
• 참고 자료

들어가며 — 1,072 대 1,036

2026년 7월 30일, 구글이 Stronger with every update라는 제목의 보안 블로그를 냈습니다. 핵심 숫자는 두 개입니다. 6월에 나온 크롬 149와 150, 단 두 개의 마일스톤에서 고친 보안 버그가 1,072개입니다. 그 앞 2년, 23개 마일스톤에서 고친 것이 1,036개입니다.

그리고 그중 하나는 침해된 렌더러가 브라우저를 속여 로컬 파일을 읽게 만드는 샌드박스 탈출이었는데, 13년 넘게 코드베이스에 살아 있던 버그였습니다. 크롬 엔지니어링 디렉터 Doug Turner는 TechCrunch에 "Gemini 같은 모델을 적용해 취약점을 선제적으로 고치고 있으며, 공격자보다 앞서 나가고 있다"고 말했습니다.

이런 숫자를 만나면 두 가지 잘못된 반응이 나옵니다. 하나는 그대로 믿고 "AI가 보안을 풀었다"고 결론 내리는 것이고, 다른 하나는 마케팅이라고 일축하는 것입니다. 둘 다 실무에 남는 게 없습니다. 이 글이 하려는 것은 세 가지입니다 — 실제로 돌아가고 있는 메커니즘이 무엇인지, 이 숫자가 코드 품질에 대해 무엇을 말하고 무엇을 말하지 않는지, 그리고 크롬 규모가 아닌 보통 팀이 그중 무엇을 복사할 수 있는지.

계보 — 2023년의 퍼즈 타깃 생성에서 2026년의 에이전트 하네스까지

이 결과는 갑자기 나온 게 아니라 4년치 누적입니다. 구글 발표문에 실린 순서를 따라가면 이렇습니다.

2023년, 퍼즈 타깃 작성. 크롬 보안 팀이 LLM으로 퍼징 커버리지를 넓히는 작업을 시작합니다. 아이디어는 단순합니다 — 퍼징의 성과는 퍼저가 아니라 하네스가 결정하는데, 하네스를 손으로 쓰는 일이 지루하고 프로젝트마다 다릅니다. 이걸 LLM에 맡기는 것입니다. OSS-Fuzz 쪽 공개 결과를 보면 성과가 구체적입니다. C/C++ 프로젝트 300개 이상에 적용해 커버리지가 30퍼센트 늘었고, 272개 프로젝트에서 37만 줄 이상이 새로 커버됐으며, LLM이 만든 타깃 없이는 발견될 수 없었을 버그 26개가 나왔습니다. 그중 하나가 OpenSSL의 CVE-2024-9143인데, 20년 동안 수십만 시간의 퍼징을 견디고 살아남았던 경계 밖 읽기/쓰기였습니다.

이 단계의 루프는 네 단계로 공개돼 있고, 그대로 복사할 수 있습니다 — 초안 하네스를 쓰고, 컴파일해서 컴파일 오류를 모델이 고치고, 실행해서 런타임 문제를 고치고, 계속 돌리면서 크래시를 모델이 분류합니다.

2024년, Naptime. Project Zero와 함께 LLM에 취약점 연구용 도구(디버거, 코드 브라우저, 실행 환경)를 쥐여 주는 방향으로 갑니다. 코드를 "읽고 추론하는" 쪽입니다.

2025년, Big Sleep. DeepMind와 Project Zero의 협업으로, 실제로 V8 자바스크립트 엔진과 그래픽 스택에서 버그를 찾아냅니다.

2026년 초, Gemini 에이전트 하네스. 크롬 코드베이스 전체를 훑되 오탐을 줄이는 데 초점을 둔 하네스가 들어갑니다. 발표문에 적힌 설계가 흥미롭습니다. 코드를 정적 상태로만 분석하고, 인터넷이 차단된 격리 머신에서 돌리며, 네트워크 요청은 엄격한 허용 목록으로 가로챕니다. 모델의 비결정성은 같은 코드베이스를 여러 번 스캔하는 것으로 상쇄하고, 과거 CVE 전체와 git 이력을 지식 베이스로 붙여 "이 프로젝트에서 버그가 나던 모양"을 참조하게 합니다. 그리고 별도 문맥의 비평가 에이전트가 발견 결과를 평가합니다.

발견 이후도 자동화돼 있습니다. 트리아지는 네 단계입니다 — 스팸과 중복을 걸러 보안 관련성을 확인하고, 개념 증명으로 재현하고, 도입 시점과 심각도 같은 메타데이터를 채우고, 담당 컴포넌트 오너에게 자동 배정합니다. 수정 단계도 수정 에이전트와 비평가 에이전트가 코드 리뷰를 흉내 낸 루프를 돌고, 테스트 작성 에이전트가 개발자 리뷰 전에 크로스 플랫폼 테스트를 만들어 붙입니다. 구글은 이 트리아지 자동화만으로 월 수백 개발자 시간을 아꼈다고 추정하면서 "정확히 재기는 어렵다"는 단서를 스스로 달았습니다.

왜 하필 거대한 C++ 코드베이스의 메모리 안전 버그인가

이 성과가 재현 가능한지를 판단하려면 문제의 성질을 봐야 합니다. 메모리 안전 버그 사냥은 LLM에게 유독 유리한 조건을 네 개나 갖고 있습니다.

첫째, 판정이 기계적입니다. ASan, MSan, UBSan, LeakSanitizer로 계측된 바이너리에서 크래시 리포트가 뜨면 그건 논쟁의 여지가 없는 버그입니다. 사람 판단이 필요 없습니다. 이것이 결정적인 이유는, LLM 기반 자동화의 최대 약점이 자기 출력에 대한 자기 평가라는 데 있기 때문입니다. 새니타이저는 모델 바깥에 있는 심판이고, 모델이 아무리 그럴듯하게 우겨도 결과를 바꾸지 못합니다.

둘째, 재현 케이스가 값쌉니다. 퍼징에서 버그의 증거는 바이트열 하나입니다. 저장하고, 자동으로 최소화하고, 회귀 테스트로 그대로 붙일 수 있습니다. 로직 버그처럼 "특정 계정이 특정 시각에 특정 순서로 요청했을 때"를 서술할 필요가 없습니다.

셋째, 버그의 모양이 국소적이고 반복적입니다. 경계 검사 누락, 해제 후 사용, 타입 혼동은 코드 몇 줄 범위에서 판별되는 패턴입니다. 게다가 크롬에는 20년치 CVE와 커밋 이력이 있어서, "이 프로젝트에서 이 클래스의 버그가 어떻게 생겼는지"에 대한 학습 자료가 이미 축적돼 있습니다. 구글이 지식 베이스에 과거 CVE와 git 이력을 통째로 넣은 이유입니다.

넷째, 공격 표면이 거대합니다. 크롬은 세상의 모든 신뢰할 수 없는 입력을 파싱합니다 — 이미지, 폰트, 비디오 코덱, 네트워크 프로토콜, 자바스크립트. 파서가 많다는 것은 퍼징이 잘 먹히는 표면이 많다는 뜻입니다.

반대로 이 네 조건이 없는 영역에서는 같은 방법이 잘 작동하지 않습니다. 권한 검사 누락, 비즈니스 규칙 위반, 경합 조건 중 새니타이저가 못 잡는 종류, 설계 수준의 결함에는 기계 오라클이 없습니다. 그래서 이 발표를 "AI가 보안을 자동화했다"로 읽으면 틀립니다. 정확한 문장은 기계가 채점할 수 있는 취약점 클래스에서 탐색 비용이 급락했다입니다.

이 숫자가 말하는 것과 말하지 않는 것

1,072개는 진짜 숫자이고 의미도 있습니다. 발견돼 고쳐진 버그 하나는 공격자에게 남은 발판 하나가 줄어든 것입니다. 다만 이 숫자가 무엇에 대한 지표인지를 정확히 두어야 합니다. 이것은 발견율 지표이지 결함 밀도 지표가 아닙니다.

이 표의 오른쪽이 해커뉴스 토론에서 나온 지적과 정확히 겹칩니다. 가장 자주 반복된 질문은 "자동 수정 중 몇 개가 되돌려졌고 몇 개가 새 버그를 만들었나"였고, 한 댓글은 발표문이 "잘된 것은 전부 세고 잘못될 수 있는 것은 하나도 세지 않았다"고 요약했습니다. 크롬 팀 엔지니어가 그 스레드에 답하지는 않았습니다.

여기에 제가 덧붙이고 싶은 방법론적 주의가 하나 더 있습니다. 비교 단위가 마일스톤인데 마일스톤의 길이가 바뀌고 있습니다. 직전 2년의 23개 마일스톤은 대략 월 1회 주기였고, 6월에는 두 개가 나왔습니다. 게다가 구글은 같은 발표에서 메이저 릴리스를 2주 주기로 옮기고 주간 보안 업데이트를, 나아가 주 2회 보안 릴리스를 시범 운영한다고 밝혔습니다. 릴리스가 잦아지면 "마일스톤당 수정 건수"의 분모가 계속 바뀝니다. 시계열 비교를 하고 싶다면 단위 시간당으로 정규화한 수치가 필요한데, 그 수치는 발표문에 없습니다.

그리고 가장 중요한 해석 하나. 버그가 많이 발견됐다는 것은 그 버그들이 내내 거기 있었다는 뜻입니다. 13년짜리 샌드박스 탈출이 그 증거입니다. 이 발표는 크롬 코드가 6월에 좋아졌다는 근거가 아니라, 그동안 우리가 얼마나 못 찾고 있었는지에 대한 증거에 가깝습니다. 그리고 같은 도구는 공격자도 씁니다.

병목은 발견에서 배포로 옮겨 갔습니다

이 발표에서 실무자에게 가장 쓸모 있는 대목은 사실 1,072이라는 숫자가 아니라 구글이 그다음에 무엇을 바꿨는가입니다.

취약점 발견 비용이 떨어지면 병목은 즉시 아래로 이동합니다. 찾는 속도가 고치는 속도를 앞지르고, 고치는 속도가 배포하는 속도를 앞지릅니다. 크롬에서 수정이 메인 트리에서 스테이블 브랜치까지 흘러가는 데 몇 주가 걸립니다. 발견이 10배 빨라져도 이 구간이 그대로면 사용자가 보호되는 시점은 거의 안 바뀝니다.

그래서 구글의 대응이 릴리스 파이프라인 쪽에 몰려 있습니다 — 메이저 주기 2주로 단축, 주간 보안 업데이트, 주 2회 보안 릴리스 시범, CVE와 릴리스 노트 생성 자동화(사람 손이 병목이었다는 뜻입니다), 그리고 전체 재시작 없이 백그라운드 프로세스를 교체하는 동적 패치 연구. 마지막 항목은 아직 연구 단계라고 스스로 밝히고 있습니다.

동시에 구조적 방어도 계속 갑니다. 1차 크롬 코드의 97퍼센트가 엄격한 unsafe-buffer 경고를 켜고 컴파일되는 스팬화 작업, 할당 계산에 checked math 적용, 포인터와 비포인터를 분리하는 힙 파티셔닝, 해제 후 사용을 무력화하는 MiraclePtr과 MiracleObject, 그리고 파서·코덱·폰트처럼 버그 밀도가 높은 영역에 Rust를 선별 투입하는 계획입니다. 여기서 구글이 솔직하게 적어 둔 문장이 하나 있습니다 — 런타임 완화 기법은 몇 년 안에 수확 체감에 도달할 것으로 본다는 것입니다. 그래서 언어 수준의 해결로 옮겨 가고 있습니다.

크롬 규모가 아닌 팀이 실제로 복사할 수 있는 것

구글의 자원을 흉내 낼 수는 없지만, 이 파이프라인에서 값싸고 이식 가능한 조각은 분명히 있습니다. 순서가 중요합니다.

1. LLM보다 새니타이저가 먼저입니다. 이 모든 것의 전제는 기계 오라클입니다. C/C++ 프로젝트라면 CI에 ASan과 UBSan 빌드를 하나 추가하는 것이 어떤 AI 도구를 붙이는 것보다 먼저입니다. 심판 없이 에이전트를 붙이면 잡히는 건 없고 오탐만 늘어납니다.

# 오라클부터. 이게 없으면 나머지는 의미가 없다.
cmake -B build-asan -DCMAKE_BUILD_TYPE=RelWithDebInfo \
  -DCMAKE_C_FLAGS="-fsanitize=address,undefined -fno-omit-frame-pointer" \
  -DCMAKE_CXX_FLAGS="-fsanitize=address,undefined -fno-omit-frame-pointer"
cmake --build build-asan -j

# 기존 테스트를 새니타이저 빌드로 한 번 돌려 보는 것만으로도 대개 뭔가 나온다
ASAN_OPTIONS=detect_leaks=1 UBSAN_OPTIONS=print_stacktrace=1 ctest --test-dir build-asan

2. 모델에게 버그를 찾게 하지 말고 하네스를 쓰게 하세요. 이것이 2023년 구글이 실제로 한 일이고, 성과 대비 비용이 가장 좋은 지점입니다. 파서, 디코더, 직렬화 코드처럼 "바이트열을 받는 함수"를 목록으로 뽑아 각각에 대해 하네스 초안을 생성하게 하고, 컴파일 오류와 런타임 오류를 모델이 고치게 하는 네 단계 루프를 돌리면 됩니다. 여기서 모델의 출력은 곧바로 컴파일러와 퍼저에 의해 검증되므로 환각이 살아남기 어렵습니다.

3. 수정보다 트리아지를 먼저 자동화하세요. 구글이 가장 큰 시간 절약을 본 곳이 여기입니다. 중복 제거, 재현, 심각도 추정, 담당자 배정은 판정 기준이 명확해서 자동화 실패 시 피해도 작습니다. 반면 패치 자동 생성은 잘못되면 새 버그가 되므로 나중에 붙이는 게 맞습니다.

4. 자동 패치에는 회귀 테스트를 강제하세요. 크롬 파이프라인의 테스트 작성 에이전트가 이 역할입니다. 패치와 테스트를 같은 변경에 묶고, 테스트가 패치 없이는 실패하는지를 기계적으로 확인하는 단계를 넣으세요. 이것이 없으면 "고쳤다고 주장하는 패치"와 "실제로 고친 패치"를 구분할 방법이 없습니다.

5. 비평가를 별도 문맥으로 두세요. 같은 세션에서 자기 출력을 평가하게 하면 확인 편향이 그대로 남습니다. 구글도, 앞서 본 대규모 마이그레이션 사례들도 같은 구조를 씁니다.

6. 지표를 발견 건수로 잡지 마세요. 되돌림 비율, 오탐률, 발견에서 배포까지의 시간, 심각도별 분포를 보세요. 발견 건수는 도구를 켠 첫 달에 반드시 치솟고 그다음엔 반드시 떨어집니다. 그 곡선을 성과로 보고하면 두 번째 달에 설명할 게 없어집니다.

7. 배포 경로를 같이 손보세요. 이것이 크롬 사례의 진짜 교훈입니다. 발견을 10배로 늘리고 배포 주기를 그대로 두면, 늘어난 것은 보안이 아니라 미배포 패치의 재고입니다.

마치며 — 많이 찾았다는 것은 내내 거기 있었다는 뜻입니다

1,072개는 크롬이 6월에 안전해졌다는 증거이자, 그 버그들이 그 전까지 전부 살아 있었다는 증거입니다. 13년짜리 샌드박스 탈출이 그 문장을 가장 잘 요약합니다. 그리고 발견 비용을 떨어뜨린 도구는 방어자 전용이 아닙니다.

옮겨 갈 것을 세 줄로 줄이면 이렇습니다.

• 이 성과가 성립한 이유는 모델이 똑똑해서가 아니라 새니타이저라는 기계 판정 오라클이 이미 그 자리에 있었기 때문입니다. 오라클이 없는 취약점 클래스에는 같은 방법이 적용되지 않습니다.
• 가장 값싸게 복사할 수 있는 조각은 버그 탐지가 아니라 하네스 생성과 트리아지 자동화입니다. 둘 다 출력이 즉시 기계 검증됩니다.
• 발견 비용이 떨어지면 병목은 배포로 내려갑니다. 구글이 릴리스 주기를 2주로 당기고 동적 패치를 연구하는 이유가 그것이고, 그것이 이 발표에서 가장 실무적인 부분입니다.

버그 수를 성과 지표로 삼는 순간, 그 지표는 도구를 켠 달에만 좋아 보입니다. 오래 보고 싶다면 되돌림 비율과 배포까지 걸린 시간을 세는 편이 낫습니다.

참고 자료

• Stronger with every update — 구글 크롬 보안 발표문 원문 (2026-07-30)
• TechCrunch — Google says it fixed more Chrome bugs in June than over the past two years (2026-07-30)
• BleepingComputer — 1,072건 수정과 도구 계보 정리
• OSS-Fuzz — Fuzz target generation using LLMs (커버리지 30퍼센트 증가, 4단계 루프)
• Hacker News — 발표에 대한 회의론 토론
• AI로 코드베이스를 옮기는 실전 절차 — 비평가 에이전트와 기계 판정 구조 (관련 글)