생성형 AI는 보안 분석의 진입 비용을 낮췄지만 결과를 내놓는 주체와 책임지는 주체는 여전히 다르다. 분석 속도가 빨라질수록 조직이 감당할 후속 업무도 늘어난다.
13년 묵은 버그를 찾은 방법
Chrome 보안팀은 2026년, 브라우저의 로컬 파일을 읽을 수 있는 샌드박스 탈출 취약점을 발견했다. 13년 넘게 발견되지 않은 버그였다. 왜 이렇게 오래 숨었을까. 여러 파일에 걸친 신뢰 경계는 퍼징(무작위 입력으로 취약점을 찾는 테스트 기법)이나 코드 리뷰만으로 찾기 어렵다.
그래서 Chrome은 Gemini에 과거 CVE와 Git 이력을 제공해 코드의 변화까지 추적하게 했다. 컴포넌트별 위협 경계를 문서화하고, 별도 에이전트가 결과를 재검토했다. 같은 코드도 여러 번 분석해 오탐을 걸렀다. 오래된 버그는 모델 하나가 아니라 맥락과 검증을 갖춘 시스템이 찾아냈다.
반면 curl은 AI가 만든 저품질 제보가 급증하자 2026년 초 버그 바운티를 종료했다. 소수의 개발자가 검증 비용을 감당할 수 없었기 때문이다. 결국 발견량만 늘면 업무 부담이 커진다.
1,072건을 수정으로 바꾼 파이프라인
Chrome 149와 150에서 수정된 보안 버그는 1,072건이다. 직전 23개 버전의 합계보다 많다. 게다가 외부 제보도 폭증하자 Chrome은 초기 분류를 자동화해 매달 수백 시간의 개발자 시간을 줄였다.
다만 절차의 중심은 여전히 PoC 재현이다.
- 취약한 버전에서만 PoC(개념증명 코드)가 작동하는지는 기계적으로 확인한다.
- 통과한 제보에는 심각도와 담당자를 붙인다.
- 수정 단계에서는 여러 패치 후보를 만들고 별도 에이전트가 비교한다.
- 테스트까지 준비된 뒤에야 개발자가 검토한다.
여기에 CI도 모든 변경 사항을 매일 검사한다. 이런 체계가 발견을 실제 수정으로 연결했다. 결국 6개월간 72건을 수정한 CodeMender 와 Chrome의 1,072건 사이의 차이는 모델보다 처리 역량에서 나온다.
공개된 패치는 공격의 설계도다
보안 패치가 공개되면 공격자는 수정된 위치와 조건을 역추적할 수 있는데, AI는 이 작업을 크게 앞당겼다. 실제로 Anthropic은 Firefox 패치 18개로 PoC 14개와 코드 실행 익스플로잇 8개를 만들었다. 첫 결과는 한 시간 안에, 8개 전부는 약 12시간 만에 나왔다.
심지어 소스가 없는 Windows 커널에서도 완전한 권한 상승 체인 8개를 평균 약 2,000달러에 만들었다. 공격 조직도 이미 AI로 CVE와 PoC를 분석한다. 일부는 과거 취약점 8만5,000건을 모델에 활용했다.
그렇다면 패치 제작만큼 배포 속도도 중요하다. Chrome은 보안 업데이트 주기를 평균 15일에서 7일로 줄였고, 실행 중인 프로세스 교체와 자동 재시작으로 적용 지연도 낮추고 있다. 익스플로잇이 몇 시간 만에 나오는데, 늦은 업데이트 자체가 위험이다.
발견 대신 처리 능력을 측정하라
AI 보안은 코드 전체 탐색보다 패치 적용 과정에서 시작하는 편이 안전하다. 먼저 릴리스부터 실제 적용까지 걸리는 시간을 측정하고 재시작 정책을 정한다. 이후 PoC 재현, 패치와 테스트 생성, CI 상시 검사 순으로 넓힌다. 명확한 판정 기준이 없는 전체 스캔은 마지막 단계가 적절하다.
이때 에이전트에는 자사 CVE와 사고 기록, Git 이력, 서비스별 위협 경계부터 제공한다. 결과는 별도 에이전트가 다시 검토하고, 분석 환경의 인터넷, 네트워크, 파일 접근도 제한해야 한다.
무엇보다 성과 기준은 발견 건수가 아니라 처리 능력이다. 취약점 한 건에 든 사람의 시간, 배포 후 적용까지 걸린 p95(상위 95%가 걸리는 시간), 프로덕션 진입 전에 차단한 비율이 더 중요하다. 외부 제보 역시 AI 사용 여부가 아닌 재현 가능성으로 판단해야 한다.
결국 Chrome의 1,072건은 발견, 재현, 수정, 테스트, 배포, 적용을 끊김 없이 연결한 시스템의 결과다.
AI 도입 이후, 보안팀의 역량을 탐지 건수만으로 설명할 수 있을까. 사람의 판단이 필요한 지점을 얼마나 좁고 분명하게 남겨 두었는지가 운영 수준을 가른다.