구글(Google)의 AI 에이전트 PageBreak가 자체 웹 애플리케이션에서 500건이 넘는 크로스사이트스크립팅(XSS) 취약점을 찾고 실제 공격 가능성까지 검증했다.
구글은 24일 공식 블로그에서 PageBreak를 제품 보안팀이 개발한 내부 AI 에이전트라고 밝혔다. PageBreak는 2025년 11월 파일럿으로 시작해 2026년 1월 정식 프로젝트로 전환됐으며, 취약점 탐색 자동화로 보안팀의 수작업을 줄이는 것이 목표다.
PageBreak는 취약점 후보를 제시하는 데서 멈추지 않는다. 의심스러운 문제를 찾으면 별도로 개발된 검증 도구가 실제 실행 환경에서 공격 페이로드를 작동시켜 해당 취약점이 재현되는지 확인한다.
구글은 실행 환경에서 취약점을 검증하는 방식으로 오탐률을 '거의 0'에 가깝게 낮췄다고 설명했다. 오탐은 실제 문제가 아닌데 취약점으로 판정하는 경우다.
검증 방식은 취약점 유형에 따라 달라진다. XSS는 삽입된 자바스크립트가 실제로 실행되는지 확인하고, SQL 인젝션은 데이터베이스 질의가 조작되는지를 점검한다. 경로 탐색, 원격 코드 실행(RCE), 서버 측 요청 위조(SSRF)도 각각 별도 검증 절차를 거친다.
PageBreak는 구글의 자체 웹 애플리케이션에서 500건이 넘는 XSS 취약점을 찾았다. 반면 구글의 '고신뢰성' 웹 프레임워크로 구축된 수백 개 애플리케이션에서는 9월 4일 기준 XSS 취약점이 2건만 확인됐다.
구글은 확인된 2건이 내부 애플리케이션이나 보안 강화가 부족한 디버그 엔드포인트에 한정됐다고 설명했다. 두 수치는 AI 탐지 도구의 성능과 함께 소프트웨어 설계 방식에 따라 취약점 발생 양상이 달라질 수 있음을 보여준다.
취약점을 사후에 찾아내는 자동화만으로는 보안 문제를 모두 해결하기 어렵다. 구글은 특정 취약점이 애초에 발생하기 어렵도록 설계하는 '보안 내재화' 접근도 필요하다고 제시했다.
다만 이번 비교는 구글 내부 애플리케이션과 구글 자체 프레임워크를 대상으로 한 결과다. 다른 기업의 코드 구조와 보안 환경에서도 같은 수준의 결과가 나올지는 추가 확인이 필요하다.
PageBreak에도 한계가 있다. 검증 도구가 모든 취약점 유형이나 복잡한 공격 경로를 다루지는 못해 실제 취약점을 놓치는 미탐 가능성이 남아 있기 때문이다.
구글은 검증되지 않은 후보를 제품팀에 전달하는 대신 향후 탐색을 위한 단서나 검증 도구 개선 자료로 활용한다고 밝혔다. 실제 공격 가능성을 확인한 결과와 아직 검증하지 못한 후보를 구분하는 방식이다.
구글은 PageBreak를 자동 수정 에이전트 CodeMender와 연결할 계획이다. PageBreak가 검증한 취약점의 원인을 CodeMender가 분석하고 수정안을 제시한 뒤, 최종 적용 전 엔지니어가 검토하고 승인하는 구조다.
구글은 2025년 CodeMender를 공개하며 제미나이 모델을 활용해 취약점의 원인을 분석하고 패치를 생성·검증한다고 밝혔다. PageBreak가 탐지와 검증을 맡고 CodeMender가 수정안 생성에 초점을 맞추는 방식이다.
이 같은 흐름은 AI가 공개된 가상자산 코드에서 취약점과 공격 경로를 찾아낸 사례와도 맞닿아 있다. 다만 PageBreak 사례는 구글이 자체 웹 애플리케이션을 대상으로 탐지 결과의 재현 여부까지 확인했다는 점에 초점이 있다.
PageBreak가 보여준 변화는 AI가 취약점을 많이 찾는 데만 있지 않다. 의심 단계의 결과를 실제 공격 가능성이 있는 증거로 좁힌 뒤 수정 단계까지 연결하는 보안 자동화 흐름을 구글 내부 사례로 제시했다는 데 의미가 있다.

김미래 기자
댓글0
첫 댓글을 남겨 보세요.