구글 ‘PageBreak’, XSS 500건 넘게 검증…AI가 찾고 비AI 도구가 증명한다
구글 제품보안팀이 사내 웹 애플리케이션을 공격자 관점에서 점검하는 AI 에이전트 PageBreak의 운영 결과를 공개했습니다. Gemini 계열 모델이 취약점 가설을 만들고 사람이 작성한 결정론적 검증기가 실제 페이로드로 재현한 뒤 확정된 보고서만 제품팀에 전달하는 구조입니다. 구글은 500건이 넘는 XSS를 찾았다고 밝혔지만 이는 회사 내부 환경의 자체 집계이며, 안전 설계 프레임워크를 쓴 수백 개 앱에서는 2건만 확인됐다는 결과와 함께 읽어야 합니다.
정적 경고가 아니라 실제 악용을 증명한다
구글은 9월 24일 내부 AI 보안 에이전트 ‘PageBreak’의 구조와 운영 결과를 공개했습니다. 이 프로젝트는 2025년 11월 시범 운영을 시작해 2026년 1월 정식화됐으며, 구글의 1차 웹 애플리케이션을 공격자 관점에서 점검합니다. 대부분의 작업에는 Gemini 3.1 Pro나 Gemini 3.5 Flash가 쓰이지만 특정 모델 하나에 묶이지 않도록 설계됐습니다.
핵심은 모델이 그럴듯한 취약점 설명을 쓰는 데서 끝나지 않는다는 점입니다. PageBreak는 실행 중인 환경에서 실제 페이로드를 작동시켜 가설을 닫습니다. 구글은 이 방식으로 자사 웹 앱에서 교차 사이트 스크립팅, 즉 XSS 취약점 500건 이상을 찾아냈고 오탐률이 거의 0에 가깝다고 주장했습니다. 다만 이는 외부 기관이 재현한 평가가 아니라 구글의 내부 운영 보고입니다.
AI의 추론과 사람이 쓴 검증기를 분리
모델이 후보를 찾으면 취약점 유형별 ‘에이전트 검증기’가 인계받습니다. XSS는 자바스크립트 페이로드를 주입해 실제 실행 문맥을 감시하고, SQL 인젝션은 출력이나 응답 시간의 변화를 확인합니다. 경로 조작은 읽을 수 있는 위치에 만든 파일을 다시 읽는지, 원격 코드 실행은 지연·파일 생성·외부 DNS 또는 HTTP 요청이 생기는지를 살핍니다.
이 검증 로직은 AI가 즉석에서 작성한 것이 아니라 보안팀이 통제한 코드입니다. 모델의 유연한 탐색과 반복 가능한 판정 절차를 나눈 셈입니다. 서버사이드 요청 위조도 내부 서비스로 향한 실제 요청을 관찰합니다. 보안팀이 ‘가능성이 있다’는 긴 보고서를 읽는 대신, 재현된 공격 경로와 증거를 받게 하려는 운영 설계입니다.
확인 못 한 후보는 제품팀에 보내지 않는다
검증기가 다루지 못하는 유형이나 복잡한 조건도 있습니다. PageBreak는 이런 비결정적 후보를 버리지 않고 다음 실행의 단서로 저장하거나 새 검증기를 만들 영역으로 표시합니다. 에이전트가 어떤 권한이나 환경 접근이 부족했는지도 피드백으로 남깁니다. 그러나 확인되지 않은 후보는 제품팀에 경보로 전달하지 않는다고 구글은 설명했습니다.
이 원칙은 생성형 AI 보안 도구의 가장 큰 병목인 ‘경고 소음’을 겨냥합니다. 반대로 검증기가 없는 취약점은 놓칠 수 있어 낮은 오탐과 낮은 누락을 동시에 보장하지는 않습니다. 같은 시드를 여러 차례 실행해 서로 다른 탐색 경로를 시도한다는 설명도 완전한 재현성보다는 확률적 탐색을 보완하는 운영 기법에 가깝습니다.
500건과 2건이 함께 말하는 것
PageBreak를 구글의 ‘고보증 웹 프레임워크’로 만든 수백 개 앱에 적용했을 때는 9월 4일 기준 XSS가 2건 확인됐습니다. 두 건 모두 내부 앱이나 강화가 덜 된 디버그 엔드포인트에 한정됐습니다. 전체 자사 앱에서 발견한 500건 이상과 같은 분모가 아니므로 탐지율을 단순 비교할 수는 없지만, 안전한 출력 처리와 기본 정책을 프레임워크에 넣는 예방 설계의 가치를 보여 줍니다.
구글 단일 저장소는 에이전트가 서비스 설정과 코드 흐름을 끝까지 따라가게 하고, 실제 HTTP 트래픽에서 얻은 보안 신호는 URL을 소스 코드와 연결합니다. 기존 인증 스캐너도 내부 사이트 접근에 재사용됩니다. 이 조건은 일반 기업이 그대로 복제하기 어려운 구글 특유의 이점이므로 PageBreak 성과를 상용 도구의 보편적 성능으로 확대 해석해서는 안 됩니다.
발견에서 자동 수정까지, 남은 통제 지점
구글은 PageBreak를 자동 수정 에이전트 CodeMender와 연결하고 있습니다. 장기 목표는 취약점 발견과 재현, 패치 제안까지 기계가 처리하고 제품팀은 수정안을 검토하는 흐름입니다. 실제 결함의 기술 사례를 다룬 Bug Hunters 동반 글에는 캐시 오염과 암호화 보호 우회처럼 단일 정적 규칙으로 찾기 어려운 공격 경로가 소개됐습니다.
자동화 범위가 커질수록 검증 환경 격리, 공격 페이로드의 권한, 패치 회귀시험과 감사 기록이 더 중요해집니다. PageBreak의 의미는 ‘AI가 보안을 해결했다’가 아니라, AI의 가설을 결정론적 도구와 안전한 개발 기본값으로 묶었을 때 실무 경고로 바꿀 수 있다는 데 있습니다. 외부 도입자는 발견 건수보다 검증 증거, 누락률 측정, 수정 승인 경계를 먼저 요구해야 합니다.
기사가 마음에 드셨다면 하트를 눌러주세요.
기사 읽고, 잠깐 게임 한 판 어떠세요?
전국을 여행하며 지역과 특산물을 만나는 한글 타자게임
미니게임 고르기 ▶