--- title: "구글, 크롬 보안 버그를 23개 릴리스치보다 더 많이 고친 비결은 인공지능이었다" published: 2026-07-31T07:29:22.000Z canonical: https://jeff.news/article/5275 --- # 구글, 크롬 보안 버그를 23개 릴리스치보다 더 많이 고친 비결은 인공지능이었다 구글은 크롬 보안 프로세스 전반에 대규모 언어 모델과 다중 에이전트 워크플로를 넣어 취약점 발견, 분류, 수정, 배포 속도를 끌어올리고 있다고 설명함. 크롬 149와 150 두 마일스톤에서 보안 버그 1072개를 고쳤고, 이는 이전 23개 마일스톤 전체 수정량을 넘어선 수치임. ## 인공지능이 크롬 보안 파이프라인 전체에 들어감 - 구글은 크롬 보안팀이 취약점 발견부터 수정, 배포, 업데이트 적용까지 전 과정에 인공지능을 넣고 있다고 공개함 - 2023년에는 대규모 언어 모델로 퍼징 범위와 성능을 늘리는 작업을 했음 - 2024년에는 프로젝트 제로와 함께 취약점 연구용 도구를 모델에 붙인 ‘냅타임’을 만들었음 - 2025년에는 딥마인드, 프로젝트 제로와 ‘빅슬립’을 협업했고, 이 에이전트가 V8 자바스크립트 엔진과 그래픽 스택에서 버그를 찾았음 - 2026년 초에는 제미나이를 이용한 취약점 탐지 하네스를 더 넓은 크롬 코드베이스에 적용함 - 이 과정에서 13년 넘게 코드베이스에 숨어 있던 샌드박스 탈출 버그를 찾았음 - 렌더러가 이미 뚫린 상황에서 브라우저를 속여 로컬 파일을 읽게 만들 수 있는 종류의 버그였음 - 구글 내부에서는 이 사례가 인공지능 기반 취약점 탐지의 가능성을 확실히 보여준 순간이었다고 봄 > [!WARNING] > 취약점 발견 속도가 빨라지면 좋은 일만 생기는 게 아님. 수정과 배포가 느리면 공개된 패치를 보고 공격자가 역추적하는 패치 공백이 더 위험해질 수 있음. - 탐지 시스템은 그냥 모델 하나 돌리는 구조가 아님 - 공개 가중치 모델과 독점 모델을 같이 쓰기 위해 모델 상호운용성을 추가함 - 과거 크롬 취약점, 전체 깃 히스토리, 크롬 지식 베이스를 붙여 모델의 훈련 데이터 바깥 맥락까지 보강함 - 개발자들이 보안 경계와 위협 모델을 설명하는 시큐리티 문서를 넣도록 유도하고, 별도 비평 에이전트가 이 문서를 읽게 함 - 모델의 비결정성을 감안해 같은 코드베이스를 여러 번 돌리는 방식도 넣었음 ```mermaid sequenceDiagram participant 코드베이스 participant 탐지에이전트 participant 비평에이전트 participant 수정에이전트 participant 개발자 코드베이스->>탐지에이전트: 취약점 후보 분석 탐지에이전트->>비평에이전트: 보안 경계와 근거 검토 요청 비평에이전트-->>탐지에이전트: 오탐과 위험도 피드백 탐지에이전트->>수정에이전트: 검증된 이슈 전달 수정에이전트->>비평에이전트: 수정 후보 여러 개 제출 비평에이전트-->>개발자: 최종 검토용 패치와 근거 제공 ``` ## 분류와 수정도 자동화로 밀어붙임 - 취약점 보고서 분류는 규칙 기반 시스템과 인공지능을 섞어 처리함 - 예전에는 보안 보고서 하나를 분류하는 데 5분에서 30분 이상 걸렸고, 사람의 경험에 크게 의존했음 - 지금은 스팸 여부, 중복 여부, 크롬 보안 취약점인지부터 자동으로 거름 - 재현 가능한 버그는 영향받는 운영체제와 브라우저 버전에서 테스트하고, 스택 트레이스 같은 수정 단서도 붙임 - 심각도, 최초 유입 시점, 담당 컴포넌트와 소유자 배정까지 자동화함 - 구글은 이 자동 분류만으로도 매달 개발자 시간을 수백 시간 절약한다고 추정함 - 사람이 해야 할 일은 사라진 게 아니라, 더 어려운 보안 판단과 수정 검토 쪽으로 이동함 - 심각도 평가는 자동화하되 개발자가 수정할 수 있게 열어둔 것도 현실적인 설계임 - 수정 단계에서는 다중 에이전트 워크플로를 쓴다고 함 - 수정 에이전트가 특정 이슈 맥락을 읽고 여러 수정 후보를 냄 - 비평 에이전트가 어떤 수정이 더 적절한지 평가하고, 코드 리뷰처럼 반복함 - 테스트 작성 에이전트는 크롬이 지원하는 여러 플랫폼과 설정에서 돌아갈 테스트를 미리 작성함 - 구글은 이 과정이 경우에 따라 개발자 시간을 몇 주까지 아낄 수 있다고 봄 > [!IMPORTANT] > 크롬 149와 150 두 마일스톤에서 고친 보안 버그는 1072개임. 이전 23개 마일스톤 전체 수정량을 넘어섰다는 게 이 글에서 제일 센 숫자임. ## 문제는 ‘고쳤다’가 끝이 아니라는 점 - 보안 패치가 오픈소스 코드베이스에 올라가면 공격자는 바로 역공학을 시작할 수 있음 - 이른바 엔데이 공격과 패치 공백 문제임 - 크롬 메인 브랜치에 들어간 수정이 대부분 사용자가 쓰는 안정 채널까지 가는 데는 보통 몇 주가 걸림 - 그래서 구글은 보안 수정 사항을 심각도에 따라 안정 릴리스 브랜치로 직접 병합하고 있음 - 릴리스 주기도 더 촘촘하게 가져가려 함 - 크롬은 주요 마일스톤을 2주 주기로 전환하고, 보안 업데이트는 매주 제공하는 방향으로 가고 있음 - 더 나아가 주 2회 보안 릴리스를 시험 중임 - 릴리스 노트와 취약점 설명 생성도 자동화해 수작업 병목을 줄이려 함 - 사용자 재시작도 보안 병목으로 보고 있음 - 크롬은 2008년부터 백그라운드 자동 업데이트를 밀었지만, 실제 패치 적용은 브라우저 재시작이 필요함 - 구글은 분류, 수정, 테스트, 릴리스까지 1~2일이면 끝나는 상황에서 사용자가 재시작을 미루는 시간이 위험을 키운다고 봄 - 그래서 렌더러나 그래픽 처리 같은 백그라운드 자식 프로세스를 실행 중에 새 바이너리로 갈아끼우는 동적 패칭을 연구 중임 - macOS에서는 창이 모두 닫혀 있지만 앱은 백그라운드에 남아 있는 상태를 활용해, 업데이트가 대기 중이면 자동 재시작하는 변경도 크롬 150에 넣었음 ## 장기전은 메모리 안전성과 의존성 관리임 - 크롬은 여전히 대부분이 C++ 코드라서 런타임 완화책이 1차 방어선임 - 해제 후 사용 취약점을 줄이기 위해 미라클포인터 계열을 확장하고 있음 - 그래픽 처리 메인 스레드에서는 미라클오브젝트로 해제 후 사용 취약점의 최대 90%를 무력화하는 걸 목표로 함 - 포인터와 크기 조합을 표준 스팬 타입으로 바꾸는 작업도 진행 중이고, 크롬 1차 코드의 97%가 엄격한 위험 버퍼 경고를 통과함 - 하지만 구글은 C++ 완화책이 몇 년 안에 한계효용 감소를 맞을 거라고 봄 - 런타임 체크는 컴파일 단계 보장보다 비용이 크고, 샌드박싱도 성능 제약을 만든다는 판단임 - 그래서 장기적으로 러스트를 새 컴포넌트의 자연스러운 선택지로 만들기 위해 중앙화된 러스트 개발 도구 묶음을 만들고 있음 - 복잡한 데이터 파서, 이미지 코덱, 폰트 스택처럼 과거 버그 밀도가 높았던 영역부터 러스트로 바꾸려 함 - 외부 오픈소스 의존성도 엄청난 규모임 - 크롬은 V8, 보링에스에스엘, 스키아, 앵글, 던 같은 프로젝트를 포함해 2300개가 넘는 서드파티 의존성을 갖고 있음 - 이 중 약 1700개는 어떤 형태로든 사용자에게 배포됨 - 올해부터는 크롬의 모든 서드파티 의존성을 최신 업스트림 버전으로 자동 업데이트하는 파이프라인으로 옮기기 시작함 --- ## 기술 맥락 - 구글이 고른 방향은 취약점 탐지 도구 하나를 추가하는 게 아니라, 보안 개발 생명주기 전체를 자동화하는 쪽이에요. 발견만 빨라지면 보고서 분류, 수정 코드 작성, 테스트, 릴리스, 사용자 업데이트가 줄줄이 병목이 되거든요. - 다중 에이전트 구조를 쓰는 이유도 여기 있어요. 한 모델이 패치를 뚝딱 만드는 방식보다, 수정 에이전트와 비평 에이전트가 코드 리뷰처럼 반복하는 편이 대형 코드베이스에서는 더 현실적이에요. 크롬은 플랫폼과 설정 조합이 많아서 테스트 작성까지 자동화해야 효과가 나요. - 패치 공백을 줄이려는 주 2회 보안 릴리스와 동적 패칭은 배포 레이어의 선택이에요. 취약점을 고쳐도 사용자가 재시작하지 않으면 보호가 적용되지 않으니, 브라우저 구조 자체를 이용해 업데이트 적용 부담을 사용자에게서 빼려는 거예요. - 메모리 안전성 전략은 단기와 장기를 나눠 잡았어요. 기존 C++ 코드는 미라클포인터, 스팬 전환, 힙 분리 같은 완화책으로 버티고, 새롭거나 버그가 잦은 컴포넌트는 러스트로 옮겨 컴파일 단계 보장을 늘리려는 흐름이에요. ## 핵심 포인트 - 제미나이 기반 취약점 탐지 하네스가 13년 넘게 숨어 있던 샌드박스 탈출 버그를 찾음 - 크롬 149와 150에서 보안 버그 1072개를 수정해 이전 23개 마일스톤 합계를 넘어섬 - 취약점 분류 자동화로 개발자 시간을 매달 수백 시간 절약한다고 추정함 - 패치 공백을 줄이기 위해 주 2회 보안 릴리스와 동적 패칭을 실험 중임 - 장기적으로는 C++ 완화책과 러스트 전환을 병행해 메모리 안전성을 강화하려 함 ## 인사이트 이건 단순히 ‘인공지능이 버그를 찾았다’ 뉴스가 아니라, 대형 소프트웨어 조직의 보안 운영 방식이 바뀌고 있다는 신호에 가까움. 발견 속도가 빨라지면 수정, 테스트, 배포, 사용자 재시작까지 전부 병목이 되기 때문에 보안 파이프라인 전체를 자동화해야 한다는 얘기임.