구글, 크롬 보안 버그를 23개 릴리스치보다 더 많이 고친 비결은 인공지능이었다

인공지능이 크롬 보안 파이프라인 전체에 들어감

• 구글은 크롬 보안팀이 취약점 발견부터 수정, 배포, 업데이트 적용까지 전 과정에 인공지능을 넣고 있다고 공개함

  • 2023년에는 대규모 언어 모델로 퍼징 범위와 성능을 늘리는 작업을 했음
  • 2024년에는 프로젝트 제로와 함께 취약점 연구용 도구를 모델에 붙인 ‘냅타임’을 만들었음
  • 2025년에는 딥마인드, 프로젝트 제로와 ‘빅슬립’을 협업했고, 이 에이전트가 V8 자바스크립트 엔진과 그래픽 스택에서 버그를 찾았음

• 2026년 초에는 제미나이를 이용한 취약점 탐지 하네스를 더 넓은 크롬 코드베이스에 적용함

  • 이 과정에서 13년 넘게 코드베이스에 숨어 있던 샌드박스 탈출 버그를 찾았음
  • 렌더러가 이미 뚫린 상황에서 브라우저를 속여 로컬 파일을 읽게 만들 수 있는 종류의 버그였음
  • 구글 내부에서는 이 사례가 인공지능 기반 취약점 탐지의 가능성을 확실히 보여준 순간이었다고 봄

• 탐지 시스템은 그냥 모델 하나 돌리는 구조가 아님
  • 공개 가중치 모델과 독점 모델을 같이 쓰기 위해 모델 상호운용성을 추가함
  • 과거 크롬 취약점, 전체 깃 히스토리, 크롬 지식 베이스를 붙여 모델의 훈련 데이터 바깥 맥락까지 보강함
  • 개발자들이 보안 경계와 위협 모델을 설명하는 시큐리티 문서를 넣도록 유도하고, 별도 비평 에이전트가 이 문서를 읽게 함
  • 모델의 비결정성을 감안해 같은 코드베이스를 여러 번 돌리는 방식도 넣었음

sequenceDiagram
    participant 코드베이스
    participant 탐지에이전트
    participant 비평에이전트
    participant 수정에이전트
    participant 개발자
    코드베이스->>탐지에이전트: 취약점 후보 분석
    탐지에이전트->>비평에이전트: 보안 경계와 근거 검토 요청
    비평에이전트-->>탐지에이전트: 오탐과 위험도 피드백
    탐지에이전트->>수정에이전트: 검증된 이슈 전달
    수정에이전트->>비평에이전트: 수정 후보 여러 개 제출
    비평에이전트-->>개발자: 최종 검토용 패치와 근거 제공

분류와 수정도 자동화로 밀어붙임

• 취약점 보고서 분류는 규칙 기반 시스템과 인공지능을 섞어 처리함

  • 예전에는 보안 보고서 하나를 분류하는 데 5분에서 30분 이상 걸렸고, 사람의 경험에 크게 의존했음
  • 지금은 스팸 여부, 중복 여부, 크롬 보안 취약점인지부터 자동으로 거름
  • 재현 가능한 버그는 영향받는 운영체제와 브라우저 버전에서 테스트하고, 스택 트레이스 같은 수정 단서도 붙임
  • 심각도, 최초 유입 시점, 담당 컴포넌트와 소유자 배정까지 자동화함

• 구글은 이 자동 분류만으로도 매달 개발자 시간을 수백 시간 절약한다고 추정함

  • 사람이 해야 할 일은 사라진 게 아니라, 더 어려운 보안 판단과 수정 검토 쪽으로 이동함
  • 심각도 평가는 자동화하되 개발자가 수정할 수 있게 열어둔 것도 현실적인 설계임

• 수정 단계에서는 다중 에이전트 워크플로를 쓴다고 함

  • 수정 에이전트가 특정 이슈 맥락을 읽고 여러 수정 후보를 냄
  • 비평 에이전트가 어떤 수정이 더 적절한지 평가하고, 코드 리뷰처럼 반복함
  • 테스트 작성 에이전트는 크롬이 지원하는 여러 플랫폼과 설정에서 돌아갈 테스트를 미리 작성함
  • 구글은 이 과정이 경우에 따라 개발자 시간을 몇 주까지 아낄 수 있다고 봄

문제는 ‘고쳤다’가 끝이 아니라는 점

• 보안 패치가 오픈소스 코드베이스에 올라가면 공격자는 바로 역공학을 시작할 수 있음

  • 이른바 엔데이 공격과 패치 공백 문제임
  • 크롬 메인 브랜치에 들어간 수정이 대부분 사용자가 쓰는 안정 채널까지 가는 데는 보통 몇 주가 걸림
  • 그래서 구글은 보안 수정 사항을 심각도에 따라 안정 릴리스 브랜치로 직접 병합하고 있음

• 릴리스 주기도 더 촘촘하게 가져가려 함

  • 크롬은 주요 마일스톤을 2주 주기로 전환하고, 보안 업데이트는 매주 제공하는 방향으로 가고 있음
  • 더 나아가 주 2회 보안 릴리스를 시험 중임
  • 릴리스 노트와 취약점 설명 생성도 자동화해 수작업 병목을 줄이려 함

• 사용자 재시작도 보안 병목으로 보고 있음

  • 크롬은 2008년부터 백그라운드 자동 업데이트를 밀었지만, 실제 패치 적용은 브라우저 재시작이 필요함
  • 구글은 분류, 수정, 테스트, 릴리스까지 1~2일이면 끝나는 상황에서 사용자가 재시작을 미루는 시간이 위험을 키운다고 봄
  • 그래서 렌더러나 그래픽 처리 같은 백그라운드 자식 프로세스를 실행 중에 새 바이너리로 갈아끼우는 동적 패칭을 연구 중임
  • macOS에서는 창이 모두 닫혀 있지만 앱은 백그라운드에 남아 있는 상태를 활용해, 업데이트가 대기 중이면 자동 재시작하는 변경도 크롬 150에 넣었음

장기전은 메모리 안전성과 의존성 관리임

• 크롬은 여전히 대부분이 C++ 코드라서 런타임 완화책이 1차 방어선임

  • 해제 후 사용 취약점을 줄이기 위해 미라클포인터 계열을 확장하고 있음
  • 그래픽 처리 메인 스레드에서는 미라클오브젝트로 해제 후 사용 취약점의 최대 90%를 무력화하는 걸 목표로 함
  • 포인터와 크기 조합을 표준 스팬 타입으로 바꾸는 작업도 진행 중이고, 크롬 1차 코드의 97%가 엄격한 위험 버퍼 경고를 통과함

• 하지만 구글은 C++ 완화책이 몇 년 안에 한계효용 감소를 맞을 거라고 봄

  • 런타임 체크는 컴파일 단계 보장보다 비용이 크고, 샌드박싱도 성능 제약을 만든다는 판단임
  • 그래서 장기적으로 러스트를 새 컴포넌트의 자연스러운 선택지로 만들기 위해 중앙화된 러스트 개발 도구 묶음을 만들고 있음
  • 복잡한 데이터 파서, 이미지 코덱, 폰트 스택처럼 과거 버그 밀도가 높았던 영역부터 러스트로 바꾸려 함

• 외부 오픈소스 의존성도 엄청난 규모임

  • 크롬은 V8, 보링에스에스엘, 스키아, 앵글, 던 같은 프로젝트를 포함해 2300개가 넘는 서드파티 의존성을 갖고 있음
  • 이 중 약 1700개는 어떤 형태로든 사용자에게 배포됨
  • 올해부터는 크롬의 모든 서드파티 의존성을 최신 업스트림 버전으로 자동 업데이트하는 파이프라인으로 옮기기 시작함

기술 맥락

• 구글이 고른 방향은 취약점 탐지 도구 하나를 추가하는 게 아니라, 보안 개발 생명주기 전체를 자동화하는 쪽이에요. 발견만 빨라지면 보고서 분류, 수정 코드 작성, 테스트, 릴리스, 사용자 업데이트가 줄줄이 병목이 되거든요.

• 다중 에이전트 구조를 쓰는 이유도 여기 있어요. 한 모델이 패치를 뚝딱 만드는 방식보다, 수정 에이전트와 비평 에이전트가 코드 리뷰처럼 반복하는 편이 대형 코드베이스에서는 더 현실적이에요. 크롬은 플랫폼과 설정 조합이 많아서 테스트 작성까지 자동화해야 효과가 나요.

• 패치 공백을 줄이려는 주 2회 보안 릴리스와 동적 패칭은 배포 레이어의 선택이에요. 취약점을 고쳐도 사용자가 재시작하지 않으면 보호가 적용되지 않으니, 브라우저 구조 자체를 이용해 업데이트 적용 부담을 사용자에게서 빼려는 거예요.

• 메모리 안전성 전략은 단기와 장기를 나눠 잡았어요. 기존 C++ 코드는 미라클포인터, 스팬 전환, 힙 분리 같은 완화책으로 버티고, 새롭거나 버그가 잦은 컴포넌트는 러스트로 옮겨 컴파일 단계 보장을 늘리려는 흐름이에요.