Google은 9월 3일 Mantis를 공개하며, 자사 내부에서 기계 속도로 취약점을 찾고 수정하는 접근 방식의 일부라고 설명한 하네스를 오픈소스 프레임워크로 선보였습니다. Mantis는 탐지, 분류, 재현, 패치를 자동화하며, 비평 및 검토 에이전트에 샌드박스화한 재현 기능을 결합해 결과를 검증합니다.
잘못 읽히고 있는 문장
Google의 게시물은 이렇게 설명합니다. "AI 코드 스캐닝의 부주의는 종종 환각된 버그와 7% 미만의 낮은 진짜 양성률로 이어지지만, 우리는 비평 및 검토 에이전트 같은 업계 표준의 에이전트형 기법과 취약점의 샌드박스화된 재현을 결합해 Mantis가 효과적이도록 설계했다." 이 수치는 Google이 대비 대상으로 삼고 있는 분야의 현황을 설명합니다. 이는 제품의 점수가 아니라 문제 제기입니다.
흔한 해석이 놓치는 점
몇 시간 안에 7% 수치는 Mantis 자체의 진짜 양성률로 퍼졌고, 이는 주장 전체를 정반대로 뒤집었습니다. 경쟁 접근법에 대한 비판을 Google 도구에 대한 사실상 인정으로 바꿔버린 셈입니다. 더 중요한 점, 그리고 짚고 넘어갈 부분은 해당 게시물 어디에도 Mantis의 정확도 수치는 없다는 사실입니다. 진짜 양성률도, 벤치마크 결과도, 비교표도 없습니다. 독자는 설명된 아키텍처와 효과에 대한 주장만 접하게 됩니다. 출처가 없는 7% 수치는 대신 인용할 측정값이 없기 때문에, 보도에서 증거 역할을 떠맡고 있습니다.
그라운딩이 설계상의 핵심인 이유
핵심 공개는 아키텍처입니다. 환각된 취약점 보고서는 AI 코드 스캐너를 유지보수자들에게 부담으로 만든 실패 양상입니다. 모든 오탐은 사람의 분류 시간을 잡아먹고, 오픈소스 프로젝트들은 AI가 생성한 보고서를 아예 거부하기 시작했습니다. Mantis의 해법은 샌드박스화된 재현입니다. 하네스가 취약점을 실제로 유발할 수 있어야 그 발견은 발견으로 인정됩니다. 이는 올바른 아키텍처적 대응이며, 코드를 실행해 보는 누구나 검증할 수 있습니다. 오픈소스로 배포할 때 가능한 장점이 바로 이것입니다.
빠진 부분
게시물은 라이선스를 명시하지 않았습니다. 유지보수자와 중요 인프라 운영자를 겨냥한 오픈소스 공개에서 라이선스는 사소한 세부사항이 아닙니다. 누가 상업적으로 이 하네스를 어떤 조건으로 사용할 수 있는지를 결정하기 때문입니다. 도입을 검토하는 이들은 발표문보다 저장소를 먼저 읽어야 합니다.