대규모 언어모델(LLM)이 보안 산업의 전제를 바꾸고 있다. 사람의 전문성만으로는 감당하기 어려웠던 취약점 발굴을 자동화해 규모를 키우면, 공격자보다 앞서기 위한 방어 전략 자체도 달라져야 한다. 구글이 크롬 보안 전 과정에 Gemini를 비롯한 AI를 투입하고 있다고 밝힌 배경에는 이런 판단이 깔려 있다. 취약점 발견, 검증과 분류(triage), 수정, 배포에 이르는 생애주기의 모든 단계를 최대한 빠르게 만드는 것이 목표다.
크롬 보안팀의 AI 활용은 갑작스러운 일이 아니다. 2023년 퍼징(fuzzing)의 커버리지와 성능을 높이는 데 LLM을 적용했고, 2024년에는 프로젝트 제로와 함께 취약점 연구용 도구를 LLM에 쥐어준 냅타임(Naptime)을, 2025년에는 딥마인드·프로젝트 제로와 함께 빅슬립(Big Sleep)을 만들어 V8 자바스크립트 엔진과 그래픽 스택에서 실제 버그를 찾아냈다. 그리고 2026년 초, 크롬 코드베이스 전반을 훑는 에이전트 하니스를 구축했다. 이 과정에서 나온 대표 사례가 13년 넘게 조용히 남아 있던 샌드박스 탈출 버그다. 손상된 렌더러가 브라우저를 속여 로컬 파일을 읽게 만드는 결함으로, AI 기반 탐지의 잠재력을 팀 내부에서 확신하게 만든 순간으로 소개됐다.
발견보다 처리 속도가 관건
버그를 많이 찾는 것만으로는 부족하다. 오히려 발굴이 폭증하면 검증과 분류가 병목이 된다. 실제로 크롬 취약점 보상 프로그램(VRP)에는 2026년 초부터 신고가 늘더니 3월에는 한 달 만에 2025년 한 해 전체보다 많은 신고가 들어왔다. 구글은 이에 맞춰 VRP 정책을 내부에서 이미 찾아내는 것과 겹치지 않고, 자동화된 처리 파이프라인이 쉽게 소화할 수 있는 신고에 집중하도록 손봤다.
분류 작업도 규칙 기반 시스템과 AI를 결합한 방식으로 옮겨가고 있다. 과거에는 신고 하나를 분류하는 데 5분에서 30분 이상이 걸렸고 사람의 판단에 크게 의존했지만, 네 단계로 나뉜 자동 분류 절차가 처리량과 정확도를 함께 끌어올렸다. 구글은 이 방식으로 매달 수백 시간의 개발자 시간을 절약하는 것으로 추정한다. 수정 단계에서도 다중 에이전트 워크플로를 활용해 대부분의 취약점에 대해 LLM이 후보 패치를 생성하고 있다. 그 결과 최근 두 밀스톤인 크롬 149와 150에서 1,072건의 보안 버그를 수정했는데, 이는 직전 23개 밀스톤을 합친 것보다 많은 수치다.
패치 격차와 배포 주기
수정이 오픈소스 저장소에 공개되는 순간, 공격자는 사용자에게 패치가 닿기 전에 이를 역분석해 악용할 수 있다. 이른바 N-데이 공격이자 '패치 격차(patch gap)' 문제다. 메인 트리에 반영된 수정이 대다수 사용자가 쓰는 스테이블 채널에 도달하기까지 보통 수 주가 걸리기 때문에, 이 격차를 줄이는 일이 핵심 과제가 된다. 구글은 주요 밀스톤을 2주 주기로 전환하며 주간 보안 업데이트를 병행하려 하고, 나아가 주 2회 보안 릴리스를 시험하고 있다. 빅슬립과 코드멘더(CodeMender)는 CI에 통합돼 24시간마다 모든 변경 목록(CL)을 검사하며, 5월 한 달에만 20건이 넘는 취약점이 프로덕션에 도달하는 것을 막았다. 여기에는 치명적 등급인 S1+ 사안도 포함됐다.
다만 배포가 빨라져도 사용자가 브라우저를 재시작하지 않으면 보호가 지연된다. 크롬은 2008년 무음 백그라운드 업데이트를 도입했지만, 재시작을 미루는 이용자의 습관은 여전한 위험 요인이다. 구글은 재시작 부담을 사용자에게서 덜어내는 방향을 모색 중이며, 공개 대응 측면에서는 릴리스 노트와 CVE 설명 생성을 자동화해 발견과 공개 사이의 간극을 좁히려 한다. 실무 관점에서 기업 IT 관리자에게 주는 시사점은 분명하다. 배포 주기가 짧아지고 자동화될수록, 조직 내 업데이트 정책과 강제 재시작 관리가 곧 실효 보안 수준을 좌우한다.
개별 버그를 넘어 버그 계열 제거로
구글의 시선은 개별 결함 수정을 넘어 취약점 계열 자체를 없애는 데 있다. 크롬은 두 갈래의 메모리 안전 전략을 편다. 하나는 방대한 C++ 코드베이스를 위한 런타임 강화로, 하드닝된 표준 템플릿 라이브러리와 UAF(Use-After-Free)를 무력화하는 미라클Ptr 계열이 대표적이다. 다른 하나는 러스트 같은 메모리 안전 언어로의 장기적 전환이며, 최상위 UI를 HTML·CSS·타입스크립트로 구현해 C++ 프레임워크 의존을 줄이는 방안도 검토 중이다. 구글은 런타임 완화책이 몇 년 안에 한계 효용에 다다를 것으로 본다. 컴파일 타임 보장보다 비용이 크고, 'Rule of Two' 준수를 위한 엄격한 샌드박싱이 성능을 갉아먹기 때문이다.
대규모 코드베이스를 한 번에 훑는 방식은 크롬의 빠른 개발 속도를 따라잡지 못한다. 그래서 커밋 큐(CQ) 파이프라인에 방어형 모델을 배치해, 코드 제출 시점에 가깝게 diff를 검사하고 스패니피케이션 수정 제안, 댕글링 포인터 탐지, 수치 안전성 강제를 수행한다. 특히 홀로 있을 때는 안전하던 코드가 무관한 다른 변경 탓에 취약해지는 '잠복 보안 이슈'를, LLM 기반 의미 분석으로 트리에 반영되기 전에 잡아내려 한다. 크롬은 지구상에서 가장 큰 오픈소스 프로젝트인 크로미움을 안고 있으며, 2,300개가 넘는 서드파티 의존성 중 약 1,700개가 사용자에게 배포된다. 구글이 알파-오메가 프로젝트에 1,250만 달러를 기부하고 아크리테스(Akrites) 프로젝트의 창립 멤버로 참여한 것도, 방어의 규모가 결국 생태계 전체의 문제라는 인식과 맞닿아 있다.