Google Agentic Code Security, 제출 전 취약점 검사로 전환

Google은 자사의 에이전트형 보안 시스템이 이제 수억 줄에 이르는 인프라 코드의 모든 변경 사항을 스캔해, 취약한 변경이 프로덕션 환경에 들어가기 전에 차단한다고 밝혔다. Google agentic code security 파이프라인은 AI 스캐닝, 구조적 검증, 야간 테스트, 인간 검토를 거친 패치를 결합한다. Google에 따르면 이 프로세스는 매달 수백 건의 취약점이 코드베이스나 프로덕션 시스템에 유입되는 것을 막는다.

핵심 변화는 단순히 Google이 Gemini를 사용해 버그를 찾는다는 데 있지 않다. Google은 AI 지원 보안을 제안된 모든 코드 변경이 거치는 경로 안으로 옮겼다. 이는 개발자가 많은 변경 사항을 통합한 뒤 광범위한 보안 스캔을 실행해 온 기존 모델에 도전한다.

이번 발표는 OpenAI, Anthropic, Cisco, Microsoft, Google이 소프트웨어 결함을 찾아내거나 수정하는 AI 시스템을 확대하는 가운데 나왔다. 이러한 시스템은 방어 역량을 높일 수 있지만, 동시에 까다로운 운영 문제도 만든다. 더 많은 취약점을 발견하는 일은 팀이 이를 검증하고 우선순위를 정하며 안전하게 패치할 수 있을 때에만 도움이 된다.

Google Agentic Code Security, 코드 반영 전부터 시작

Google은 일부 늦은 시점의 저장소 전체 보안 작업을 개별 코드 변경에 의해 촉발되는 좁은 범위의 검토로 대체하고 있다.

Google은 2026년 9월 18일 이 시스템을 공개했다. 회사는 이 시스템이 글로벌 네트워크, AI 시스템, 사용자 대상 서비스를 뒷받침하는 인프라 전반에서 작동한다고 밝혔다.

제안된 각 변경 사항은 Google 엔지니어가 이미 사용하는 개발 도구 안에서 제출 전 스캔을 받는다. 제출 전 스캔은 코드가 공유 코드베이스의 일부가 되기 전에 검사하는 것을 의미한다. 이 시스템은 보안 피드백을 별도의 감사가 아니라 컴파일러 경고나 가독성 검토에 더 가깝게 다룬다.

이 시점이 중요한 이유는 개별 변경 사항이 전체 저장소보다 적은 양의 자료를 담고 있기 때문이다. 에이전트는 관련 없는 모든 구성 요소를 처리하지 않고도 수정된 코드, 즉각적인 의존성, 관련 위협 가정을 살펴볼 수 있다.

좁은 범위의 검토는 스캐너에 더 유용한 질문도 제공한다. 방대한 저장소에 의심스러운 요소가 있는지를 묻는 대신, 시스템은 하나의 변경이 도달 가능한 보안 약점을 도입하는지를 묻는다.

Google의 설명은 워크플로를 여러 단계로 나눈다:

• 경량 에이전트가 제안된 각 코드 변경을 검사한다.

• 로컬 위협 모델이 영향을 받는 구성 요소에 보안 맥락을 제공한다.

• 트리아지 에이전트가 의심되는 공격 경로가 구조적으로 도달 가능한지 확인한다.

• 야간 통합 테스트가 여러 변경 사항 간 상호작용으로 생긴 문제를 찾는다.

• 복구 에이전트가 인간 검토를 위한 수정 제안과 뒷받침 증거를 준비한다.

회사는 이 파이프라인이 수억 줄의 배포된 인프라 코드 전반에서 작동한다고 밝혔다. 또한 시스템이 매달 수백 건의 취약점을 차단한다고 주장한다. 이 수치는 Google이 제시한 것이며 독립적인 감사를 받지 않았다.

“발견”과 “예방”의 차이는 주목할 만하다. 엔지니어가 경고를 무시하거나 대부분을 오탐으로 판별한다면, 스캐너는 보안을 개선하지 못한 채 많은 경고만 생성할 수 있다.

Google은 자사의 권고안이 내부에서 널리 채택되고 있다고 말한다. 그러나 이번 발표는 채택 비율, 심각도 분류, 기존 스캐너와의 비교를 공개하지 않았다.

회사가 공개한 가장 강력한 성능 지표는 트리아지 단계와 관련 있다. Google은 해당 에이전트가 92% 이상의 정밀도에 도달하며 1분 이내에 응답한다고 밝혔다.

정밀도는 도구가 발견한 기존 취약점의 수가 아니라, 보고된 발견 사항 중 실제 문제인 비율을 측정한다. 시스템은 정밀한 경고를 내면서도 어려운 결함을 놓칠 수 있다. Google은 두 번째 문제를 측정하는 데 도움이 될 재현율을 공개하지 않았다.

Google은 일부 상황에서 오탐률이 3%까지 낮다고도 보고했다. “일부 사례에서”라는 표현은 독자가 이 수치를 얼마나 폭넓게 적용해야 하는지를 제한한다. 언어, 구성 요소, 취약점 유형, 위협 모델에 따라 결과는 크게 달라질 수 있다.

그럼에도 이 아키텍처는 소프트웨어 보안의 의미 있는 변화를 가리킨다. Google은 AI 검토를 별도 보안 팀을 위한 가끔의 보조 도구가 아니라 지속적인 프로덕션 통제로 다루고 있다.

이 점은 이번 발표를 또 하나의 모델 벤치마크보다 더 중요한 것으로 만든다. 시스템의 가치는 개발자가 코드를 제출하기 전 짧은 시간 안에 신뢰할 수 있는 결정을 내릴 수 있는지에 달려 있다.

빨라진 취약점 발견, 패치 팀에 부담 가중

AI는 취약점 발견 비용을 낮추고 있지만, 개선 작업은 여전히 테스트, 검토, 배포 역량의 제약을 받는다.

보안 팀은 오랫동안 발견과 수정 사이의 불균형을 관리해 왔다. 정적 분석기, 퍼저, 연구자, 사고 보고서는 유지보수자가 즉시 조사할 수 있는 것보다 더 많은 문제를 식별할 수 있다.

AI는 이러한 불균형을 키운다. 에이전트는 모든 시도에 상응하는 인간 시간을 요구하지 않고도 저장소를 반복적으로 검사하고, 공격 가설을 세우며, 개념 증명 입력을 생성할 수 있다.

하지만 신뢰할 수 있는 발견 사항은 각각 업무를 만든다. 누군가는 악용 가능성을 확립하고, 영향을 받는 버전을 파악하며, 심각도를 평가하고, 안전한 수정안을 설계해 테스트한 뒤 배포를 조율해야 한다.

Google 자체 보안 조직도 이 병목 현상을 인정했다. 회사는 자동화된 OSS-Fuzz 패치에 대한 설명에서 순수 에이전트형 스캐너가 높은 오탐률을 낼 수 있다고 밝혔다. 또한 지속적인 최전선 모델 스캐닝은 많은 프로젝트에 여전히 비용이 너무 많이 들 수 있다고 언급했다.

이 자동화된 패치 파이프라인은 OSS-Fuzz와 Google DeepMind가 개발한 에이전트인 CodeMender를 결합한다. OSS-Fuzz는 재현 가능한 크래시를 제공하고, CodeMender는 원인을 조사해 수정안을 제안한다.

이 조합은 원시적인 모델 역량만으로는 충분하지 않은 이유를 보여준다. 재현 가능한 크래시는 광범위한 코드 검토 중 생성된 제약 없는 의심보다 복구 에이전트에 더 강한 증거를 제공한다.

Google의 인프라 시스템도 제출 전에 유사한 원칙을 적용한다. 스캐닝 에이전트가 문제를 제안하지만, 별도의 트리아지 에이전트가 코드 구조와 도달 가능성을 검토한다.

호출 그래프는 어떤 함수가 다른 함수를 호출할 수 있는지 보여준다. 추상 구문 트리 파싱은 소스 코드를 일반 텍스트가 아닌 구조화된 프로그램 요소로 표현한다. 이 도구들은 함께 공격자가 제어하는 데이터가 위험한 연산에 도달할 수 있는지 판단하는 데 도움을 준다.

이 결정론적 계층은 기존 애플리케이션 보안 제품에 압력을 가한다. 가능한 문제로 대시보드만 채우는 스캐너는 경로를 검증하고 패치를 제안하는 시스템 옆에서 덜 유용해 보이기 때문이다.

개발자도 이러한 압력을 받는다. 코드 검토에 직접 배치된 보안 시스템은 유용한 결과를 빠르게 반환해야 한다. 느린 스캔은 업무를 방해하고, 시끄러운 발견 사항은 개발자가 경고를 무시하도록 학습시킨다.

Google은 빠른 검증 단계가 1분 이내에 완료된다고 밝혔다. 이 성능이 다양한 코드베이스 전반에서 유지된다면, 개발자를 별도의 워크플로로 몰아넣지 않고도 빈번한 스캔을 지원할 수 있다.

이 접근 방식은 중앙화된 보안 팀의 역할도 바꾼다. 전문가는 도메인 규칙과 위협 가정을 정의하고, 에이전트는 일상적인 코드 변경 전반에 이 맥락을 적용할 수 있다.

이는 인간 보안 업무를 없애지 않는다. 대신 전문가는 통제 설계, 이례적인 발견 사항 검토, 잠재적 영향이 가장 큰 변경의 검토에 더 집중하게 된다.

경쟁사들도 관련 모델을 추진하고 있다. OpenAI는 저장소를 분석하고, 샌드박스에서 의심되는 취약점을 테스트하며, 수정안을 제안하는 에이전트로 Codex Security를 소개했다. 회사는 테스트 과정에서 거의 800건의 심각한 문제와 10,500건 이상의 고심각도 문제를 발견했다고 밝혔다.

이는 독립적으로 확인된 측정치가 아니라 OpenAI가 제시한 수치다. 그럼에도 해당 워크플로는 맥락 기반 분석, 익스플로잇 검증, 제안된 개선 조치를 결합하는 Google의 방식과 매우 유사하다.

Anthropic도 AI 지원 취약점 발견을 추진해 왔고, Cisco는 제품 전반에 걸쳐 멀티모델 스캐닝을 도입했다. Cisco는 Axios에 8주 동안 25개 프로그래밍 언어에 걸쳐 18억 줄의 코드를 스캔했다고 전했다.

Cisco는 보안 공개 주기도 월 1회에서 월 2회로 옮겼다. 이 변화는 더 큰 발견 역량이 조직으로 하여금 공개 및 개선 프로세스를 가속하도록 강제한다는 더 넓은 제약을 보여준다.

따라서 주된 경쟁 구도는 Google과 특정 벤더 한 곳의 대결이 아니다. 이는 지속적이고 맥락을 인지하는 검토와, 탐지를 개발에서 분리하는 지연된 광범위 스캐닝의 대결이다.

기존 스캐너가 사라지지는 않을 것이다. 시그니처 검사, 의존성 분석, 퍼징, 수동 검토는 각각 서로 다른 실패 유형을 탐지한다. Google의 시스템은 이러한 역량을 둘러싼 새로운 오케스트레이션 계층을 추가한다.

승리하는 접근 방식은 확률적 에이전트와 결정론적 증거를 결합할 가능성이 높다. 에이전트는 익숙하지 않은 코드 전반에서 가설을 세울 수 있고, 구조적 도구와 테스트는 근거 없는 결론을 배제할 수 있다.

이 조합은 Google의 주장에 핵심적이다. 회사는 하나의 모델이 의문의 여지 없는 보안 검토자로 행동하도록 요구하지 않는다. 스캐닝, 트리아지, 테스트, 복구, 인간 승인을 별개의 통제로 분리한다.

Google AI 취약점 스캐닝이 탐색 범위를 좁히는 방식

이 시스템은 여러 전문 에이전트에 제한된 책임과 코드별 맥락을 부여해 정밀도를 높인다.

대규모 저장소를 검토하는 범용 모델은 맥락 문제에 직면한다. 코드만으로는 어떤 자산이 중요한지, 신뢰 경계가 어디에 있는지, 어떤 호출자가 신뢰할 수 없는 입력을 제공할 수 있는지를 거의 설명하지 못한다.

Google은 로컬화된 위협 모델로 이러한 약점을 해결한다. 위협 모델은 시스템의 보호 대상 자산, 예상 공격자, 신뢰 경계, 그럴듯한 악용 경로를 기록한다.

회사는 이러한 모델이 분리된 문서가 아니라 실시간 코드베이스 메타데이터에서 정보를 가져온다고 밝혔다. 오래된 위협 모델은 더 이상 존재하지 않는 아키텍처를 바탕으로 확신에 찬 발견 사항을 만들 수 있기 때문에, 이 연결은 중요하다.

Google은 오픈 소스 멀티 에이전트 검토 하니스인 Mantis를 발전시켜 스캐닝 에이전트를 이러한 로컬화된 모델과 연결했다. 하니스는 기반 모델을 중심으로 프롬프트, 도구, 증거, 인계 과정을 조율한다.

Mantis 검토 하니스는 시스템 아키텍처를 단일 모델 릴리스와 분리한다는 점에서 중요하다. Google은 잘 설계된 하니스가 모델 간 변동성을 보완할 수 있다고 밝혔다.

첫 번째 에이전트는 관련 보안 맥락을 사용해 제안된 변경 사항을 검토한다. 의심스러운 데이터 흐름, 누락된 권한 부여 검사, 안전하지 않은 메모리 연산 또는 다른 잠재적 약점을 식별할 수 있다.

그런 다음 두 번째 에이전트가 프로그램 구조를 통해 해당 가설을 검증한다. 호출 그래프를 순회하고, 구문을 파싱하며, 인덱싱된 안전 규칙을 적용해 취약한 경로가 도달 가능한지 판단한다.

이 단계는 신뢰성 필터로 작동한다. 코드가 단순히 취약한 패턴과 닮았는지가 아니라, 공격자가 의심되는 결함을 실제로 실행할 수 있는지를 묻는다.

이 차이는 보고된 정밀도를 설명하는 데 도움이 된다. 많은 정적 분석 경고는 이론적으로 안전하지 않은 코드를 설명하지만 공격자가 제어하는 입력으로 실행될 수는 없다. 도달 가능성 분석은 이러한 경고 중 일부를 제거할 수 있다.

그러나 도달 가능성만으로 악용 가능성의 모든 요소가 입증되지는 않는다. 런타임 구성, 권한, 배포 토폴로지, 그리고 드러나지 않은 환경적 가정 역시 공격 성공 여부를 좌우할 수 있다.

Google은 여러 변경 사항에 걸친 취약점을 포착하기 위해 야간 포스트서밋 검사를 추가한다. 프리서밋 스캐너는 개별 기여를 명확하게 볼 수 있지만, 별도의 변경 사항들이 상호작용하며 만들어내는 동작은 놓칠 수 있다.

이는 이중 속도 모델을 만든다. 빠른 검사는 개발자 흐름을 보호하고, 더 느린 통합 작업은 사용량이 적은 시간대에 광범위한 시스템 영향을 찾는다.

파이프라인이 취약점을 검증하면, 수정 에이전트는 발견 사항과 생성된 증명을 전달받는다. 이 증명은 취약한 동작을 어떻게 실행할 수 있는지 보여주는 코드 예시다.

그런 다음 에이전트는 Google의 코딩 표준에 맞는 패치를 구성한다. 승인 없이 배포하는 대신, 검토를 위해 원래 변경 요청에 제안을 첨부한다.

사람의 검토는 중요한 안전장치다. 패치는 하나의 익스플로잇을 차단하는 동시에 정상 동작을 망가뜨리거나, 다른 통제를 약화시키거나, 더 미묘한 취약점을 만들 수 있다.

Google의 이전 작업은 유용한 맥락을 제공한다. 2024년 기술 보고서는 Gemini가 생성한 수정안이 단위 테스트 중 발견된 sanitizer 버그의 15%를 해결했다고 밝혔다. 이 결과는 C++, Java, Go를 포괄했으며 수백 건의 패치로 이어졌다.

그 AI 패치 연구는 sanitizer 발견 사항이 대량으로 발생하기 때문에 제한적인 성공률도 가치가 있다고 설명했다. 자율 복구가 일반적인 소프트웨어 보안 문제를 해결했다는 주장은 아니었다.

새 인프라 파이프라인은 더 큰 목표를 제시한다. 알려진 sanitizer 실패에만 모델을 적용하는 대신, 일반적인 개발 수명 주기 안에서 발견, 검증, 수정을 결합한다.

이 아키텍처는 단계 간 유용한 독립성도 만든다. Google은 개발, 스캔, 트리아지 에이전트의 규칙, 컨텍스트, 하네스를 분리해 유지할 것을 권고한다.

이러한 분리는 상관된 오류를 줄인다. 한 에이전트가 코드를 작성한 뒤 동일한 컨텍스트로 자신의 출력을 판단하면, 같은 잘못된 가정을 반복할 수 있다.

독립적인 트리아지 시스템은 원래의 추론에 이의를 제기할 가능성이 더 크다. 결정론적 검사도 하나의 모델 설명에 대한 의존도를 낮춘다.

이 원칙은 금융 및 안전 엔지니어링에서 확립된 통제와 닮아 있다. 변경을 만드는 주체가 그 변경의 수용 가능성을 판단하는 유일한 주체여서는 안 된다.

유사한 시스템을 검토하는 기업에 숨은 요건은 조직의 기억이다. 지역별 위협 모델, 의존성 맵, 안전 규칙, 과거 검토 기준은 최신 상태로 유지되어야 한다.

AI는 조직이 한 번도 포착하지 않은 컨텍스트를 활용할 수 없다. 파편화된 문서와 문서화되지 않은 아키텍처는 에이전트가 위험한 동작과 정당한 예외를 구분하는 능력을 제한한다.

이는 검색 가능한 엔지니어링 지식 기반의 인접한 역할을 만든다. 자동화된 검토가 이를 효과적으로 활용하려면, 팀은 아키텍처 결정, 코드 소유권, 보안 가정에 신뢰성 있게 접근할 수 있어야 한다.

따라서 기술적 메커니즘은 “agentic”이라는 라벨이 암시하는 것만큼 마법적이지 않다. Google은 모델을 구조화된 코드 분석, 유지 관리되는 컨텍스트, 비동기 테스트, 검토 게이트와 결합한다.

그 장점은 이러한 요소를 모든 변경 사항 주변에 배치하는 데서 나온다. 모델은 보안 가설을 실행 가능한 증거로 전환하도록 설계된 시스템의 한 구성 요소다.

자동화된 AI 패칭에는 여전히 검증 문제가 있다

Google의 내부 결과는 유망하지만, 공개된 증거만으로는 재현율, 의미적 정확성, 일반 기업으로의 이식 가능성이 입증되지 않는다.

가장 분명한 불확실성은 측정에 관한 것이다. Google은 정밀도와 일부 거짓 양성 수치를 공개했지만, 독립적인 평가 데이터셋은 제공하지 않았다.

또한 탐지된 결함 중 얼마나 많은 것이 심각했는지, 프로덕션에서 악용 가능했는지, 또는 agentic 스캐닝에 고유한 것이었는지도 밝히지 않았다. 수백 건의 취약점 예방은 심각도와 신뢰도 면에서 매우 넓은 범위를 포괄할 수 있다.

또 다른 누락된 지표는 재현율이다. 실제 취약점 10개를 보고하고 오경보가 없는 스캐너는 정밀해 보이지만, 다른 100개의 결함을 탐지하지 못한다면 여전히 불완전하다.

전체 취약점 수는 알 수 없기 때문에 재현율 측정은 어렵다. 연구자들은 종종 삽입된 결함이나 과거 사례를 사용하지만, 두 방법 모두 결과를 왜곡할 수 있다.

과거 벤치마크에는 학습 데이터에 공개 버그 보고서와 개발자 패치가 포함될 수 있어 오염 위험이 있다. 에이전트가 낯선 취약점을 추론하는 대신 기억한 수정안을 재현할 수 있다.

새로운 연구는 이 문제를 보여준다. PatchBench는 기억된 공개 예시에서 수정안을 찾아내기 더 어려운, 이식 및 수정된 취약점을 대상으로 에이전트를 평가한다.

저자들은 에이전트 패치의 25%가 과거 개발자 수정안과 상당한 유사성을 보였다고 밝혔다. 또한 개념 증명만을 이용한 검증은 해결률을 평균 1.83배 부풀렸다고 확인했다.

더 강력한 보안 및 의미적 검사 아래에서는 선도적인 에이전트조차 벤치마크 과제의 약 절반만 해결했다. 평가된 11개 에이전트 모두가 해결하지 못한 과제는 67개였다.

PatchBench 평가는 에이전트가 근본 원인을 수정하지 않은 채 보고된 충돌을 억제하는 경우도 발견했다. 이러한 패치는 좁은 범위의 테스트를 통과할 수 있지만, 기저의 취약점은 그대로 남긴다.

이러한 결과가 Google의 내부 주장을 직접 반박하는 것은 아니다. Google의 환경은 단순히 과거 벤치마크만 활용하는 대신, 실제 코드 변경, 지역화된 위협 모델, 구조적 검증, 사람의 검토를 사용한다.

그러나 이 연구는 통과한 증명이 완전한 증거가 될 수 없는 이유를 보여준다. 패치는 더 넓은 취약점 클래스를 차단하면서도 정상 기능을 보존해야 한다.

Google의 야간 테스트는 이 위험을 줄이는 데 도움이 되지만, 테스트 스위트가 완전할 수는 없다. 생성된 패치는 기존 테스트가 다루지 않는 동작을 바꿀 수 있다.

시스템은 위협 모델에서 비롯된 사각지대도 물려받을 수 있다. 정밀하고 최신인 모델은 컨텍스트를 개선하지만, 불완전한 모델은 가장 중요한 공격 경로를 제외할 수 있다.

이러한 모델을 유지하는 일은 반복적인 작업을 만든다. 서비스가 발전함에 따라 팀은 경계, 의존성, 권한, 악용 사례를 업데이트해야 한다.

Google은 광범위한 내부 도구와 보안 전문성을 통해 이러한 노력을 뒷받침할 수 있다. 소규모 조직에는 결과를 재현하는 데 필요한 코드 인덱스, 위협 모델 규율, 컴퓨팅 자원이 부족할 수 있다.

비용 역시 또 다른 미해결 문제다. Google은 추론 지출, 가속기 사용량, 파이프라인 운영의 엔지니어링 비용을 공개하지 않는다.

작은 변경 하나를 스캔하는 비용은 전체 저장소를 반복적으로 스캔하는 비용보다 낮다. 하지만 많은 저장소의 모든 변경에 에이전트를 적용하면 상당한 누적 수요가 발생할 수 있다.

Google은 Trillium 및 Ironwood 시스템을 포함한 자체 TPU 인프라에서 Gemini를 운영한다. 대부분의 조직은 외부 공급자로부터 추론을 구매하거나, 더 제한된 예산 아래 소형 모델을 운영하게 될 것이다.

데이터 거버넌스도 도입을 복잡하게 만들 수 있다. 독점 소스 코드와 위협 정보를 호스팅 모델에 전송하면 계약, 프라이버시, 공급망 관련 문제가 발생한다.

기업은 코드 보존, 모델 학습, 접근 제어, 감사 로그, 테넌트 간 격리에 관한 명확한 경계가 필요하다. 규제가 엄격한 팀은 프라이빗 배포 옵션을 요구할 수 있다.

이해 상충 문제도 있다. 동일한 AI 공급자가 코드 생성, 보안 검토, 클라우드 인프라, 그리고 이 세 가지를 모두 평가하는 모델을 제공할 수 있다.

한 공급업체가 여러 계층을 차지할 때 독립적인 통제가 중요해진다. Axios는 보안 경영진이 기업이 생성과 방어를 하나의 플랫폼에 의존하는 대신 여러 공급자를 혼합해 유지할 것으로 예상한다고 보도했다.

이 우려는 에이전트와 검증 컨텍스트를 분리하라는 Google의 권고를 뒷받침한다. 하지만 한 공급업체 스택 내부의 논리적 분리는 조직적 또는 공급업체 독립성과 동일하지 않다.

사람의 검토는 이러한 불확실성에 맞서는 최종 방어선으로 남는다. 이 안전장치는 검토자가 생성된 패치에 이의를 제기할 충분한 시간, 전문성, 증거를 보유할 때만 작동한다.

그럴듯한 수정안이 대량으로 쏟아지면, 잡음이 많은 발견 사항이 대량으로 쏟아지는 것만큼 쉽게 검토자를 압도할 수 있다. 자동화는 병목을 제거하는 대신 이동시킬 수 있다.

Google은 오픈소스 유지 관리자가 이미 검토 가치가 부정적인 AI 생성 기여를 받고 있음을 인정했다. 따라서 CodeMender 프로그램은 베타 기간에 격리된 테스트와 Google 엔지니어의 검토를 사용한다.

이 교훈은 기업 내부에도 동일하게 적용된다. 수정 에이전트는 단순히 더 많은 pull request를 만들어내는 것이 아니라 전체 검토 노력을 줄여야 한다.

따라서 Google 발표에 대한 가장 신뢰할 만한 해석은 제한적이다. 이 회사는 정교한 내부 파이프라인을 구축했고, 고무적인 운영 지표를 공개했다.

이 발표는 자율 에이전트가 보안 엔지니어, 형식 검증, 퍼징, 독립 평가를 대체할 수 있음을 증명하지 않는다. Google 역시 그러한 명시적 주장을 하지 않는다.

대신 이 시스템은 신뢰할 수 있는 발견 사항을 취약점이 나타나는 시점에 더 가깝게 이동시키려 한다. 성공 여부는 AI 출력의 양이 아니라 증거의 품질과 안전한 완화 조치에 달려 있다.

Google Agentic Code Security의 다음 단계

다음 시험대는 Google이 더 폭넓은 측정치를 공개하고, 자사 환경 밖으로 워크플로를 이전하며, 발견량보다 수정 품질을 앞서 유지할 수 있는지 여부다.

Google agentic code security가 지속적인 운영 변화로 자리 잡을지를 결정할 신호는 세 가지다.

첫 번째 신호는 측정 품질이다. Google은 다양한 언어와 인프라 계층에서 재현율 추정치, 심각도 분포, 도입률, 패치 회귀 결과를 공개해야 한다.

외부 평가는 신뢰도를 높일 수 있다. 독립 연구자들은 파이프라인이 알려진 패치를 재현하거나 좁은 벤치마크 조건을 활용하지 않고 새로운 결함을 탐지하는지 시험할 수 있다.

더 정밀한 보고는 “월 수백 건”이라는 주장도 명확히 해줄 것이다. 독자는 이 시스템이 없었다면 얼마나 많은 발견 사항이 프로덕션에 도달했을지, 그리고 그 심각도가 어떻게 확립됐는지 알아야 한다.

Google이 낯선 취약점 전반에서 재현 가능한 결과를 공개한다면 접근 방식에 대한 신뢰는 높아질 것이다. 보고가 선택된 정밀도 수치에 계속 한정된다면 불확실성은 남을 것이다.

두 번째 신호는 Google 외부에서 Mantis가 실제로 도입되는지다. 하네스를 오픈소스로 공개하면 다른 조직도 오케스트레이션 로직에 접근할 수 있지만, Google의 내부 메타데이터나 운영 성숙도까지 얻는 것은 아니다.

외부 팀은 위협 모델, 코드 인덱스, 안전 규칙, 평가 데이터셋, 검토 프로세스를 제공해야 한다. 그 결과는 Google 성능 중 얼마나 많은 부분이 하네스 자체에서 비롯되는지를 보여줄 것이다.

성공적인 도입은 설치 수나 GitHub star 수 이상의 의미를 가져야 한다. 팀은 회귀 증가 없이 프로덕션으로 유출되는 취약점을 줄이고, 수용 가능한 거짓 양성 비율과 더 짧은 완화 시간을 보고해야 한다.

실패 역시 유의미한 정보를 제공할 것이다. 사용자가 컨텍스트를 유지하거나 모델 비용을 통제하는 데 어려움을 겪는다면, 이 접근 방식은 비정상적으로 성숙한 엔지니어링 시스템을 가진 기업에 집중된 채로 남을 수 있다.

세 번째 신호는 경쟁사의 대응이다. OpenAI, Anthropic, Microsoft, Cisco, 그리고 기존 애플리케이션 보안 공급업체들은 검증된 발견과 자동화된 복구로 수렴하고 있다.

중요한 비교 기준은 어느 모델이 가장 많은 발견 사항을 만들어내는지가 아니다. 악용 가능한 경로를 입증하고, 의미적으로 올바른 수정안을 생성하며, 일상적인 개발 흐름 안에 적합한 시스템이 어느 쪽인지가 핵심이다.

Cisco가 공개 빈도를 늘리기로 한 결정은 AI 기반 탐지가 이미 후속 운영 방식을 바꾸고 있음을 보여준다. 더 많은 공급업체가 릴리스 일정, 검증 역량, 고객 커뮤니케이션을 조정해야 할 것이다.

공격자 역시 더 강력한 분석 도구를 얻게 된다. 방어자가 취약한 호출 경로를 추적하도록 돕는 에이전트는 노출된 소프트웨어를 살피는 사람에게도 비슷한 이점을 제공할 수 있다.

이러한 대칭성은 취약점 발견과 악용 사이의 간격을 단축한다. 방어의 가치는 탐지 자체만큼이나 패치 속도에 점점 더 좌우된다.

Google의 사전 제출(pre-submit) 전략은 공격자가 릴리스된 산출물을 살펴보기 전에 취약점을 제거하는 방식으로 이에 대응한다. 사고 대응이 빠르더라도 배포 후 결함을 발견하는 것보다 더 강력한 위치다.

그렇다고 사전 제출 스캔이 모든 약점을 포괄할 수 있는 것은 아니다. 구성 오류, 런타임 상태, 손상된 종속성, 사회공학 기법, 아키텍처상의 실수는 단일 코드 변경 범위 밖에서 나타날 수 있다.

조직은 에이전트 기반 코드 리뷰를 방어 계층 중 하나로 봐야 한다. 퍼징, 종속성 통제, 침투 테스트, 런타임 모니터링, 접근 제한, 사고 대응은 여전히 필요하다.

개발자에게 당장의 질문은 보안 피드백이 더 관련성 높고 덜 방해적인 방식으로 제공되는가다. 도달 가능한 경로와 검토된 패치를 포함한 1분 이내의 발견은 속도와 신뢰를 모두 높일 수 있다.

보안 리더에게는 에이전트가 경보 생산량을 늘리기보다 전체 위험을 줄이는지가 핵심이다. 이를 위해서는 유출된 결함, 수정 시간, 검토자 노력, 회귀 문제를 함께 측정해야 한다.

엔터프라이즈 구매자에게 핵심 사안은 증거의 이식성이다. Google의 내부 규모는 이 아키텍처가 고도로 엔지니어링된 하나의 환경에서 작동할 수 있음을 보여준다. 다른 환경에서도 동일한 결과를 보장하지는 않는다.

더 큰 변화는 이미 가시화되고 있다. 애플리케이션 보안은 주기적 점검에서 개발 워크플로 내부의 지속적이고 증거 기반인 개입으로 이동하고 있다.

Google의 에이전트 기반 코드 보안은 이 모델을 가장 명확하게 구현한 사례 중 하나다. 해당 에이전트는 코드가 프로덕션에 도달하기 전에 스캔하고, 검증하고, 재테스트하며, 수정안을 제시한다.

향후 몇 달 안에 Google이 더 폭넓은 검증 결과를 공개할지, 외부 Mantis 사용자가 그 성과를 재현할 수 있을지가 드러날 것이다. 이러한 결과는 또 하나의 헤드라인용 발견 건수보다 더 중요하다.

엔지니어링 팀은 자체 기반부터 점검해야 한다. 위협 모델은 최신 상태인가, 종속성은 매핑되어 있는가, 테스트는 의미 있는가, 검토 책임은 명확한가?

이러한 요소가 없다면 에이전트를 추가해도 격차가 드러날 뿐 해결되지는 않는다. 반대로 갖춰져 있다면 지속적인 에이전트 기반 리뷰는 조직의 지식을 더 이른 보안 의사결정으로 전환할 수 있다.

진짜 질문은 더 이상 AI가 의심스러운 코드를 식별할 수 있는지 여부가 아니다. 조직이 각각의 발견 사항을 안전하고 시의적절한 수정으로 전환하는 통제된 프로세스를 구축할 수 있는지가 관건이다.