AWS AI 취약점 탐지는 버그를 잡아내지만, 오탐은 신뢰 격차를 드러낸다

AWS는 범용 AI 모델 12개를 테스트한 결과 뚜렷한 충돌을 발견했다. 모델들은 대부분의 취약점을 찾아냈지만, 안전한 코드까지 위험하다고 판정하는 경우가 잦았다.

새로운 Deception Benchmark는 AWS AI 취약점 탐지 주장을 기존 버그 탐지 리더보드보다 더 엄격하게 시험한다. 의심스러워 보이는 코드가 실제로는 작동하는 완화 조치로 보호되고 있음을 모델이 알아차릴 수 있는지를 묻는다. 직접 프롬프팅 환경에서 테스트된 모델들은 안전한 샘플의 41%에서 99%를 취약한 것으로 표시했다.

이 결과는 AI 보안 도구를 둘러싼 논쟁의 초점을 바꾼다. 모든 경보가 엔지니어링 시간을 소모하는 상황에서는 의심스러운 패턴을 찾는 것만으로 충분하지 않다. 이제 핵심 경쟁은 빠른 패턴 인식과 증거 기반 검증 사이에서 벌어지며, 그 차이에 따른 비용은 보안팀이 부담한다.

AWS는 2026년 9월 9일, 16개 프로그래밍 언어와 70개 이상의 Common Weakness Enumeration 범주에 걸친 14,822개 샘플로 구성된 벤치마크를 공개했다. AWS가 제시한 최소 기준인 오탐률과 미탐률을 모두 10% 미만으로 유지한 테스트 구성은 없었다.

AWS는 안전한 코드가 위험해 보이도록 만든 벤치마크를 구축했다

이 벤치마크는 모델이 익숙한 취약점 패턴을 인식하는지가 아니라, 실제로 악용 가능한지 이해하는지를 테스트한다.

많은 보안 평가는 취약한 소프트웨어에서 시작해 AI 시스템이 결함을 식별하거나 악용할 수 있는지 묻는다. 이 접근법은 유용한 공격 역량을 드러내지만, 방어 성능을 완전하게 보여주지는 못한다. 실제 운영 환경의 검토자는 실제 공격 경로를 만들지 않으면서 취약점처럼 보이는 코드를 기각할 수 있어야 한다.

AWS는 이러한 차이를 중심으로 Deception Benchmark를 설계했다. 안전한 샘플에는 현실적인 프레임워크, 위험해 보이는 데이터 흐름, 식별 가능한 보안 냄새가 포함된다. 미묘한 완화 조치가 악용 경로를 차단하며, 모델은 그 보호가 실제로 작동하는지를 판단해야 한다.

벤치마크 공개 자료에 설명된 한 사례는 사용자 입력을 받아 데이터베이스를 조회하는 Flask 엔드포인트와 관련된다. 주변 패턴은 SQL 인젝션과 유사하다. 그러나 매개변수화된 문이 입력값이 실행 가능한 쿼리 문법이 되는 것을 막는다.

패턴 인식에서 멈추는 모델은 취약점을 보고할 것이다. 전체 데이터 흐름을 추적하는 모델은 해당 샘플을 안전하다고 분류해야 한다. 이 차이는 출력이 유용한 근거가 될지, 아니면 수동 조사가 필요한 또 하나의 경보가 될지를 결정한다.

벤치마크에는 코드 수준의 과제 6,988개가 포함된다. 이 과제들은 미묘한 수정만으로 달라지는 취약 버전과 안전한 버전을 제시한다. 두 버전 모두 의심스러워 보일 수 있지만, 실제로 악용 가능한 것은 하나뿐이다.

또 다른 2,707개 과제에는 배포 컨텍스트가 추가된다. 소스 코드는 취약해 보일 수 있지만 인프라 제어가 공격을 차단한다. 예로는 서버 측 요청 위조를 막는 Kubernetes Network Policy나 권한 상승을 방지하는 ID 경계가 있다.

이런 환경 제약 사례가 중요한 이유는 엔터프라이즈 보안이 한 파일에서 끝나는 경우가 드물기 때문이다. 악용 가능성은 구성, 네트워크 도달성, 권한, 런타임 동작, 보완 통제에 달려 있다. 이런 조건을 무시하는 스캐너는 배포 환경에서는 발생할 수 없는 그럴듯한 공격을 설명할 수 있다.

AWS는 모든 샘플이 벤치마크를 위해 제작됐으며 실제 보안 패턴에 기반한다고 밝혔다. 회사는 과제를 생성하고, 최첨단 모델을 상대로 테스트하며, 쉬운 사례를 강화한 뒤 이 과정을 반복하는 적대적 개발 루프를 사용했다.

이 방법은 데이터세트를 의도적으로 어렵게 만든다. 동시에 결과를 모든 소스 리포지토리의 대표적인 실패율로 해석해서는 안 된다는 뜻이기도 하다. 이 벤치마크는 일상적인 코드 검토의 무작위 표본이 아니라, 피상적인 추론을 드러내도록 설계된 사례를 선택한다.

그 가치는 특정 역량을 분리해 측정하는 데 있다. 모델은 실제 약점과 설득력 있는 미끼를 구분할 만큼 충분히 멀리까지 공격 체인을 따라갈 수 있는가? 이 질문은 신뢰할 수 있는 AWS AI 취약점 탐지의 핵심에 놓여 있다.

공개된 벤치마크 리포지토리에는 14,822개 샘플 전체가 담겨 있다. AWS는 이 중 9,695개를 채점하고 5,127개는 채점하지 않는다. 제외된 샘플에는 논쟁의 여지가 있거나 의도적으로 모호하게 설계된 사례가 포함된다.

라벨은 공개적으로 제공되지 않는다. 참가자는 AWS가 정확도 및 오류율 결과를 반환하기 전에 설명을 포함해 모든 샘플의 예측을 제출해야 한다. 이 접근법은 암기와 벤치마크 특화 튜닝을 제한하기 위한 것이다.

AWS는 독립 검토자들이 라벨을 반복적으로 검토했다고도 밝혔다. 논쟁이 있는 샘플은 수정된 라벨을 받는 대신 미채점 풀로 이동했다. 회사에 따르면 무작위로 선택한 채점 샘플 100개를 사람이 검토한 결과 오류는 발견되지 않았다.

그렇다고 데이터세트가 비판의 여지가 없다는 뜻은 아니다. 독립 연구자들은 여전히 구성 방식, 범주 균형, 채점 과정, 실제 환경으로의 전이 가능성을 검토해야 한다. 다만 이번 공개는 외부 팀이 동일한 적대적 조건에서 시스템을 비교할 수 있는 공통 기준을 제공한다.

AWS AI 취약점 탐지 결과는 두 가지 나쁜 선택지를 드러낸다

직접 프롬프트는 너무 많은 오경보를 만들고, 더 엄격한 증명 요건은 모델이 실제 취약점을 더 많이 놓치게 한다.

AWS는 두 가지 프롬프팅 전략으로 5개 제공업체의 모델 12개를 평가했다. 직접 프롬프팅은 각 모델에 코드가 취약한지 안전한지 분류하도록 요청했다. 악용 증명 프롬프팅은 취약성을 선언하기 전에 구체적인 익스플로잇을 구성하도록 요구했다.

벤치마크는 서로 다른 운영상 실패를 유발하기 때문에 두 오류 유형을 구분한다. 오탐은 안전한 코드를 취약하다고 표시하는 것이고, 미탐은 실제 취약점을 안전하다고 분류하는 것이다.

AWS에 따르면 직접 프롬프팅에서 모델들은 대체로 민감도를 우선했다. 실제 취약점의 최대 95%를 포착했다. 그러나 안전한 코드 역시 41%에서 99%를 취약하다고 표시했다.

이런 편향은 모델을 적극적이고 신중해 보이게 할 수 있다. 동시에 실제로 발견한 취약점의 비율을 측정하는 재현율을 보호하는 쉬운 방법이기도 하다. 모든 것을 취약하다고 판정하는 시스템은 취약점을 놓치지 않지만, 사용자를 쓸모없는 경보 속에 묻어버린다.

Mistral Large는 이 실패 양상을 잘 보여준다. 직접 프롬프트 구성에서 오탐률은 99%, 미탐률은 0%를 기록했다. 사실상 모든 안전한 사례를 위험하다고 취급해 취약 사례를 찾아냈다.

다른 여러 직접 구성도 비슷하게 동작했다. GPT-5.6 Sol은 오탐률 92.5%, 미탐률 0.9%를 기록했다. Claude Haiku 4.5는 미탐 없이 오탐률 92.1%에 도달했다.

Amazon의 Nova 2 Lite도 예외는 아니었다. 직접 프롬프팅에서 AWS는 오탐률 89.2%, 미탐률 1.2%를 보고했다. Amazon 자체 모델을 포함한 점은 이번 공개가 외부 제공업체만 겨냥한 비교가 아님을 보여준다.

Claude Opus 5는 나열된 시스템 가운데 직접 프롬프트 기준으로 가장 우수한 균형을 보였다. 정확도는 77.3%, 오탐률은 41.5%, 미탐률은 5.2%였다. 그럼에도 이 결과는 AWS가 밝힌 운영 기준을 크게 벗어났다.

정확도만으로는 이런 차이가 가려진다. 벤치마크는 안전 사례와 취약 사례가 대체로 균형을 이루므로, 항상 “취약함”이라고 답하는 분류기도 50%에 가까운 점수를 얻을 수 있다. 겉으로 보이는 정확도는 모든 안전한 샘플이 경보가 된다는 사실을 숨긴다.

이에 AWS는 넉넉한 최소 기준이라고 부른 기준선을 설정했다. 운영 준비가 된 구성은 두 오류율을 모두 10% 미만으로 유지해야 한다. 테스트된 구성 가운데 이 목표에 도달한 것은 없었다.

직접 결과는 AI 취약점 탐지를 재현율만으로 평가할 수 없는 이유를 보여준다. 실제 결함을 거의 빠짐없이 찾아낸다는 점은 안심될 수 있지만, 대부분의 안전한 코드까지 경고를 유발했다는 사실을 알게 되면 이야기가 달라진다.

이는 단순한 외관상의 품질 문제가 아니다. 모든 오경보는 워크플로에 유입된다. 누군가는 코드를 검토하고, 주장된 경로를 재현하며, 구성을 확인하고, 담당 팀과 협의한 뒤, 해당 발견을 종료할 수 있는 이유를 문서화해야 한다.

엔터프라이즈 규모에서는 이러한 검토 비용이 자동화가 약속한 속도 이점을 지워버릴 수 있다. 또한 너무 많은 이전 경보가 틀렸기 때문에 엔지니어가 발견 사항을 기각하기 시작하는 경보 피로를 초래할 수 있다.

보안상 결과는 불편하다. 모델이 뛰어난 재현율을 갖추더라도 높은 오탐률은 간접적으로 위험을 높일 수 있다. 중요한 경보는 수십 건의 그럴듯한 오류와 관심을 두고 경쟁한다.

이전 학술 연구에서도 같은 패턴이 확인됐다. 2024년 보안 평가는 228개 코드 시나리오에서 8개 언어 모델을 테스트해 높은 오탐률을 보고했다. 모델들은 테스트된 코드가 패치된 뒤에도 취약점을 계속 표시하는 경우가 있었다.

이 연구는 단순한 코드 변경에도 비결정적인 답변과 취약한 추론이 나타난다는 점도 발견했다. AWS의 더 큰 규모의 공개는 더 많은 언어, 약점 범주, 모델, 그리고 적대적으로 구성된 안전 사례 전반으로 이러한 우려를 확장한다.

악용 증명은 노이즈를 줄이지만 새로운 사각지대를 만든다

증거를 요구하면 규율은 개선되지만, 테스트된 모델들은 종종 실제 취약점을 간과하는 대가로 그 정밀도를 얻었다.

악용 증명 프롬프팅은 모델에 의심을 넘어설 것을 요구한다. 코드를 취약하다고 표시하기 전에 공격자가 사용할 수 있는 구체적인 경로를 설명해야 한다. 이는 판단 기준을 “위험해 보인다”에서 “공격이 어떻게 작동하는지 설명할 수 있다”로 바꾼다.

AWS는 이 전략이 오탐률을 17~74%포인트 낮췄다고 보고했다. 이는 의미 있는 개선이다. 그러나 더 엄격한 접근법에서는 미탐률도 증가했으며, 7%에서 44% 범위였다.

GPT-5.4는 이 상충 관계를 가장 분명하게 보여준다. 직접 구성은 오탐률 81%, 미탐률 1.5%를 기록했다. 악용 증명 프롬프팅은 오탐을 10.1%로 낮췄지만, 미탐은 33.6%로 올랐다.

Llama 3.3 70B도 유사한 패턴을 따랐다. 오탐률은 84.2%에서 10.2%로 떨어졌다. 미탐률은 1.1%에서 44.2%로 상승했으며, 이는 해당 구성이 채점된 취약점의 거의 절반을 놓쳤다는 의미다.

Claude Opus 5는 악용 증명 프롬프팅에서 가장 높은 전체 정확도인 79.3%를 기록했다. 그러나 오탐률 24.9%와 미탐률 16.8%는 여전히 양쪽 모두에서 AWS의 기준을 충족하지 못했다.

이 결과가 악용 증명 프롬프팅이 효과 없다는 뜻은 아니다. 이는 프롬프팅이 모델이 어떤 오류를 저지르는지를 바꾼다는 점을 보여준다. 보안 책임자는 워크플로가 더 많은 오경보, 더 많은 누락된 결함, 또는 신중하게 측정된 조합 중 무엇을 감당할 수 있는지 결정해야 한다.

그 결정은 애플리케이션에 따라 달라진다. 인터넷에 노출된 인증 서비스의 검토는 놓치는 취약점을 더 적게 허용해야 한다. 위험이 낮은 내부 리포지토리는 소규모 엔지니어링 팀의 소진을 막기 위해 정밀도를 우선할 수 있다.

심각도 역시 기준에 영향을 미쳐야 한다. 시스템은 신뢰도가 높은 치명적 발견을 즉각적인 사람 검토로 보내고, 더 약한 경고는 낮은 우선순위의 검증 절차로 처리할 수 있다. 하나의 전역 분류 기준이 모든 코드베이스에 맞을 가능성은 낮다.

바로 이 지점에서 벤치마크의 단일 턴 설계가 중요해진다. AWS는 에이전트 스캐폴딩, 외부 도구, 반복 검증 루프를 의도적으로 제거했다. 목표는 완성된 상용 보안 제품이 아니라 기본 모델 자체의 고유한 추론 능력을 측정하는 것이었다.

따라서 이 결과가 모든 에이전트형 스캐너가 동일한 실패율을 보인다는 점을 입증하는 것은 아니다. 제품은 언어 모델을 정적 분석, 동적 테스트, 리포지토리 맥락, 정책 점검, 결정론적 익스플로잇 검증과 결합할 수 있다. 이런 구성 요소는 운영 특성을 바꿀 수 있다.

AWS도 이러한 차이를 명시적으로 인정한다. 이 벤치마크는 에이전트형 제출물을 단일 턴 모델 결과와 별도로 받는다. 이 구분은 도구 지원 시스템이 뒷받침되지 않는 단일 모델 호출과 동등한 것으로 제시되는 일을 막는다.

이 단서가 기준선의 의미를 없애는 것은 아니다. 모든 에이전트형 워크플로는 기반 모델의 일부 한계를 물려받는다. 약한 판단을 반복하면 누락된 기술적 사실을 보완하지 못한 채 더 정교한 설명만 만들어낼 수 있다.

시스템에는 새로운 증거를 확보할 신뢰할 수 있는 출처가 필요하다. 테스트를 실행하거나, 여러 파일에 걸친 데이터를 추적하거나, 배포 정책을 점검하거나, 엔드포인트에 실제로 접근 가능한지 검증할 수 있다. 모델 호출을 여러 번 한다고 해서 더 깊은 이해가 보장되지는 않는다.

가장 어려운 과제는 안전성을 입증하는 일이다. 공격 테스트는 익스플로잇의 성공 또는 실패라는 눈에 보이는 결과를 자주 제공한다. 하지만 한 번의 시도가 실패했다고 해서 다른 익스플로잇이 존재하지 않음을 입증하는 것은 아니므로, 성공이 없었다는 사실은 여전히 해석하기 어렵다.

AWS의 환경 조건형 사례는 이 문제를 더욱 선명하게 보여준다. 모델은 코드와 인프라를 함께 추론한 뒤, 처음 발견한 경로가 완화 조치에 의해 차단된다는 점을 알아차려야 한다. AWS에 따르면 모델은 위험한 패턴을 자주 포착했지만, 인접한 통제를 무시했다.

이러한 행동은 보안 검토에서 흔히 나타나는 인간의 편향과 닮아 있다. 검토자가 익숙한 취약점 형태를 알아보면 반증보다 확증이 더 빠르게 받아들여질 수 있다. 언어 모델은 패턴 인식이 답변 생성 방식의 핵심이기 때문에 이 문제를 증폭시킨다.

구매자에게 실무적 교훈은 분명하다. AI 보안 제품이 익스플로잇 가능성을 검증하는지, 그리고 두 오류율을 어떻게 측정하는지 물어야 한다. 거짓 양성 데이터가 없는 재현율 수치는 제품이 만들어내는 업무량을 거의 보여주지 않는다.

AWS의 자체 보안 시스템이 아키텍처의 중요성을 보여주는 이유

AWS의 프로덕션 주장은 코드가 안전한지를 뒷받침 없이 판단하는 모델이 아니라, 계층화된 에이전트, 결정론적 점검, 인간 승인에 기반한다.

이 벤치마크는 AWS가 두 가지 에이전트형 보안 시스템을 설명한 지 몇 달 뒤에 나왔다. 이러한 기존 공개는 Amazon이 이제 직접 측정된 한계를 어떻게 관리하려 하는지 보여준다는 점에서 중요한 반대 사례를 제공한다.

RuleForge는 공개적으로 이용 가능한 익스플로잇 사례에서 탐지 규칙을 생성한다. AWS는 이 시스템이 2025년 마지막 4개월 동안 수작업 프로세스 대비 규칙 생산성 을 336% 높였다고 밝혔다.

아키텍처는 과제를 전문화된 단계들에 나눈다. 한 구성 요소는 취약점 정보를 수집하고 우선순위를 정한다. 생성 에이전트는 여러 탐지 규칙을 제안한다. 별도의 심사기가 이를 평가하고, 합성 테스트가 규칙을 실행하며, 트래픽 데이터가 추가 검증을 뒷받침한다.

보안 엔지니어는 최종 승인 관문으로 남는다. RuleForge가 AI 모델의 자신감을 배포를 위한 충분한 증거로 취급하지 않는다는 점에서 이 인간의 역할은 중요하다.

AWS는 생성 모델이 자신의 작업을 평가하라는 요청을 받았을 때 거의 모든 규칙을 높게 평가했다고 밝혔다. 회사의 RuleForge 분석에 따르면, 평가를 별도 모델로 옮기자 진양성 탐지 수를 유지하면서 거짓 양성이 67% 줄었다.

심사기는 도메인 특화 질문도 받았다. 규칙이 올바르게 보이는지를 묻는 대신, 악성 요청을 놓칠 가능성이 있는지를 물었다. 또한 규칙이 취약점 메커니즘을 포착하는지, 아니면 단지 상관관계가 있는 표면적 특징만 잡는지도 테스트했다.

이 구분은 Deception Benchmark와 맞닿아 있다. 느슨한 표현식은 작은따옴표가 포함된 입력과 일치할 수 있지만, 해당 문자가 일치한다고 해서 SQL injection이 입증되는 것은 아니다. 규칙은 익스플로잇 행위와 동일한 특징을 공유하는 정상 트래픽을 구분해야 한다.

AWS Security Agent는 자동화된 침투 테스트에 유사한 전략을 사용한다. 전문화된 에이전트가 애플리케이션을 탐색하고 후보 발견 사항을 생성하는 동안, 검증기는 익스플로잇 증거를 요구한다.

AWS는 자사 시스템이 캡처 더 플래그 지침과 채점기 피드백을 받았을 때 CVE Bench v2.0에서 92.5%의 공격 성공률을 달성했다고 보고했다. 이러한 지원이 없을 때는 80%로 떨어졌고, 학습 마감일이 벤치마크보다 앞선 모델에서는 65%에 도달했다.

이 수치는 방어 정밀도가 아니라 공격 성공을 측정한다. CVE Bench는 취약한 애플리케이션을 포함하며, 에이전트가 알려진 결함을 익스플로잇할 수 있는지 테스트한다. 시스템이 안전한 코드를 얼마나 자주 취약하다고 지목할지는 답하지 않는다.

그럼에도 에이전트 아키텍처는 벤치마크의 약점에 대한 신뢰할 만한 대응을 보여준다. 후보 발견 사항은 결정론적 및 모델 기반 점검을 거치며, 보고서에는 익스플로잇 증거와 기술적 맥락이 포함된다.

이것은 “AI 취약점 탐지”를 하나의 기법으로 취급할 때만 명백한 모순처럼 보인다. 기본 모델 벤치마크는 단일 패스에서의 취약한 판단을 드러낸다. AWS의 프로덕션 시스템은 증거를 수집하고 그 판단을 제약하는 워크플로에서 가치를 얻는다고 주장한다.

비교는 더 정밀한 결론을 뒷받침한다. 범용 모델은 보안 자동화에 유용한 구성 요소이지만, 그 출력을 운영상 신뢰할 만한지 여부는 이를 둘러싼 시스템이 결정한다.

공급업체는 반복 프롬프트에 에이전트라는 라벨을 붙인다고 해서 그 격차를 해소할 수 없다. 관련 질문은 도구, 증거, 보정, 실패 처리, 인간 감독에 관한 것이다. 구매자는 최초의 의심과 최종 발견 사이에서 무엇이 바뀌는지 물어야 한다.

제품은 취약하다고 주장하는 경로를 실제로 실행하는가? 인프라 통제를 점검하는가? 리포지토리 경계를 넘어 데이터를 추적할 수 있는가? 결과를 결정론적 분석기와 비교하는가? 검토자는 발견 사항이 왜 검증을 통과했는지 알 수 있는가?

팀은 조사 과정에서 지속적인 맥락도 필요하다. 아키텍처 메모, 이전 예외 사항, 위협 모델, 수정 결정은 여러 문서와 대화에 흩어져 있는 경우가 많다. 검색 가능한 엔지니어링 지식 기반은 검토자가 그러한 맥락을 되찾는 데 도움이 될 수 있지만, 기술적 검증을 대체하지는 않는다.

조달 평가는 세 가지 계층을 구분해야 한다. 첫 번째는 Deception Benchmark가 공통 기준선을 제공하는 기반 모델이다. 두 번째는 시스템이 추가 증거를 수집하는 방식을 결정하는 검증 아키텍처다. 세 번째는 검토 책임과 허용 가능한 위험을 포함한 운영 프로세스다.

제품은 한 계층에서는 뛰어나고 다른 계층에서는 부진할 수 있다. 유능한 모델도 모호한 프롬프트와 누락된 맥락으로 약화될 수 있다. 성능이 낮은 모델도 좁은 범위의 도구와 엄격한 검증이 결정을 제약하면 더 유용해질 수 있다.

AWS의 공개 내용 역시 프로덕션 성능에 대한 독립 감사가 아니라 회사가 보고한 결과를 담고 있다. 336% 생산성 주장과 67% 거짓 양성 감소는 Amazon의 평가 환경에서 RuleForge를 설명한 것이다. 이를 관련 없는 리포지토리나 제품으로 일반화해서는 안 된다.

이 불확실성은 공개 벤치마크의 필요성을 더욱 강화한다. 공급업체는 완전한 시스템을 Deception Benchmark에 제출하고, 별도의 에이전트형 결과를 보고할 수 있다. 그러면 고객은 호환되지 않는 사례 연구에 의존하는 대신 공통 과제 아래에서 제기된 주장을 비교할 수 있다.

거짓 양성은 AI의 속도를 인간의 업무로 바꾼다

비즈니스 위험은 AI가 아무것도 찾지 못하는 데 있지 않다. 그럴듯한 실수가 실제 발견 사항을 확인해야 하는 사람들의 시간을 소모한다는 데 있다.

보안 도구는 오랫동안 거짓 양성 문제에 시달려 왔다. 전통적인 정적 애플리케이션 보안 테스트는 전체 런타임 맥락 없이도 위험한 흐름이나 구문을 찾기 위해 소스 코드를 스캔한다. AI는 더 나은 의미론적 추론을 약속하지만, AWS의 결과는 인식 가능한 패턴이 여전히 강한 영향을 미친다는 점을 보여준다.

긴급한 SQL injection 경고를 받는 개발 팀을 생각해 보자. 엔지니어는 계획된 작업을 멈추고, 관련 담당자를 찾고, 쿼리 경로를 검토한 뒤, 파라미터 바인딩이 injection을 막는다는 점을 확인한다. 이후 알림이 다음 스캔에서 다시 열리지 않도록 종료 메모도 남겨야 한다.

한 번의 실수는 관리할 만해 보인다. 그러나 수천 개의 리포지토리와 빈번한 스캔은 계산을 바꾼다. 높은 거짓 양성률은 자동화된 탐지를 반복적인 수동 검증 대기열로 전환한다.

그 대기열은 여러 형태의 비용을 만든다. 수정 작업이 기능 제공을 중단시키기 때문에 엔지니어링 업무가 느려진다. 보안 팀은 스캐너의 신뢰성을 방어하는 데 시간을 쓴다. 애플리케이션 소유자는 알림을 검증되지 않은 제안으로 취급하는 법을 배운다.

결국 신뢰가 약해진다. 실제 취약점이 같은 채널을 통해 들어와도 같은 회의적 반응을 받을 수 있다. 탐지 시스템은 여전히 결함을 “찾았지만”, 운영상으로는 시의적절한 조치를 이끌어내지 못했다.

거짓 음성은 반대의 위험을 만든다. 더 엄격한 시스템은 더 적은 이슈를 보고함으로써 중단을 줄일 수 있지만, 실제 결함의 큰 비중을 놓친다면 침묵은 덜 신뢰할 수 있게 된다.

이것이 AWS의 이중 임계값이 중요한 이유다. 정밀도만 측정하면 거의 아무것도 보고하지 않는 보수적 시스템에 보상이 돌아간다. 재현율만 측정하면 거의 모든 것을 표시하는 공격적 시스템에 보상이 돌아간다. 프로덕션 의사결정에는 취약점 심각도와 코드 맥락별로 구분된 두 값이 모두 필요하다.

팀은 또한 공급업체가 어떻게 정답 기준을 확립했는지 물어야 한다. 코드가 보이는 함수 밖의 이유로 안전할 수 있기 때문에 취약점 레이블링은 어렵다. 의존성, 구성, 인증, 네트워크 통제, 배포 상태는 익스플로잇 가능성을 바꿀 수 있다.

Deception Benchmark 팀은 반복적인 독립 검토를 거치고, 논쟁이 있는 사례를 채점에서 제외함으로써 레이블 오류를 줄이려 했다. 이는 사려 깊은 설계 선택이지만, 또 다른 질문을 제기한다. 명확하게 판정된 샘플이 실제 엔터프라이즈 시스템의 모호성과 얼마나 유사한가?

실제 리포지토리에는 불완전한 테스트, 문서화되지 않은 가정, 오래된 구성, 생성된 코드, 소유권 공백이 존재한다. 도구는 취약 또는 안전이라는 이분법적 답을 강요하는 대신 증거가 불충분하다고 말할 필요가 있을 수 있다.

현재 벤치마크는 그러한 이분법적 판단을 요구한다. 상세한 설명은 필요하지만, 보류는 채점되는 결과로 나열되지 않는다. 향후 평가는 보정된 불확실성이 팀이 검토 노력을 배분하는 데 도움이 되는지 살펴볼 수 있다.

지연 시간과 비용도 주목할 가치가 있다. 다중 에이전트 시스템은 테스트를 실행하고 더 폭넓은 맥락을 점검함으로써 거짓 양성을 줄일 수 있다. 하지만 이러한 개선에는 더 많은 컴퓨팅, 더 긴 검토 시간, 민감한 코드나 인프라에 대한 접근이 필요할 수 있다.

이러한 절충점이 에이전트형 검증의 가치를 무효화하는 것은 아니다. 그것은 해당 검증이 어디에 적합한지를 결정한다. 고위험 변경은 더 깊은 분석을 정당화할 수 있는 반면, 일상적인 코드는 더 저렴한 선별 검사 뒤 선택적 상향 검토가 필요할 수 있다.

보안 리더는 하나의 허영 지표를 다른 지표로 대체하지 않아야 한다. 전체 정확도 점수는 오류의 방향을 숨긴다. 극적인 생산성 수치는 검토 부담을 숨길 수 있다. 인상적인 익스플로잇 성공률은 안전한 코드에 대해서는 거의 말해주지 않는다.

신뢰할 수 있는 평가는 최소 다섯 가지를 공개해야 한다. 거짓 양성률, 거짓 음성률, 적용 범위, 검증 방법, 취약점 범주별 성능이다. 또한 거부와 무효 출력을 조용히 제외하는 대신 식별해야 한다.

한 AWS 결과는 적용 대상에서 제외됐다. 대부분의 구성은 샘플의 최소 98%에서 유효한 답변을 반환했다. proof-of-exploit 프롬프팅을 적용한 GPT-5.6 Sol은 일부 익스플로잇 구축 요청을 제공업체 안전 필터가 거부하면서 93%를 기록했다.

이 세부 사항은 또 다른 프로덕션 제약을 보여준다. 보안 에이전트는 방어 체계를 검증하기 위해 때로는 유해한 기법을 추론해야 한다. 모델 안전 제어가 정당한 평가까지 차단할 수 있으므로, 이로 인해 발생하는 누락 결과는 무시하지 말고 측정해야 한다.

엔터프라이즈 구매자에게 단기적으로 가장 적절한 입장은 통제된 지원이다. AI가 우선순위를 정하고, 설명하며, 증거를 수집하도록 하라. 특히 배포 환경이나 비즈니스 로직이 공격의 성립 여부를 결정하는 고위험 코드 경로에서는 사람의 검증을 유지해야 한다.

이때 가치 제안은 더 좁아지지만 방어 가능성은 높아진다. AI는 탐색 시간을 줄이고 가설을 제시할 수 있다. 출력에 자신감 있는 기술 언어가 담겼다는 이유만으로 AI에 단독 권한을 부여해서는 안 된다.

보안 팀이 다음으로 주시해야 할 점

이 벤치마크가 의미를 가지려면 벤더가 완전한 시스템을 테스트하고, 균형 잡힌 오류율을 공개하며, 실제 리포지터리에서도 성과가 유지됨을 보여야 한다.

첫 번째 신호는 참여다. AWS는 개발자들에게 전체 14,822개 샘플을 실행하고 검증된 채점을 위한 예측 결과를 제출하도록 권한다. 도구를 사용하는 다단계 시스템은 단일 턴 모델과 별도로 평가된다.

독립 제출 결과는 에이전트 기반 검증이 측정된 격차를 해소하는지 보여줄 것이다. 완전한 시스템이 두 오류율을 모두 10% 아래로 낮춘다면, 아키텍처가 약한 기본 판단력을 보완할 수 있다는 AWS의 견해를 뒷받침하게 된다. 그렇지 않다면 신뢰 문제는 더 깊다.

두 번째 신호는 재현성이다. 연구자들은 공개된 샘플, 과제 범주, 채점되지 않은 풀, 숨겨진 레이블 처리 과정을 검토해야 한다. 독립 그룹의 유사한 평가가 나온다면 모델 순위와 실패 패턴이 AWS의 구축 방식 밖에서도 유지되는지 확인할 수 있다.

세 번째 신호는 프로덕션 증거다. 벤더는 사용자가 조사하고, 기각하고, 다시 열고, 최종적으로 수정하는 경고의 수를 공개해야 한다. 이러한 워크플로 결과는 모델의 고립된 분류 점수보다 더 중요하다.

이 벤치마크는 구매자에게 더 나은 제안요청서 기준도 제공한다. 벤더에게 시스템을 제출하고 검증된 거짓 양성 및 거짓 음성 비율을 공유하도록 요구하라. 이어서 중요 코드, 환경 조건에 좌우되는 발견 사항, 지원하지 않는 언어에 대해 검증 절차가 어떻게 달라지는지 물어야 한다.

개발자는 도구가 불확실성을 어떻게 제시하는지 주시해야 한다. 유용한 검토 도구는 확인된 익스플로잇 경로와 그럴듯한 우려 사항, 누락된 맥락을 구분해야 한다. 이 범주들을 동일하게 취급하면 불필요한 작업이 늘고 시스템의 실제 신뢰도도 가려진다.

AWS의 AI 취약점 탐지 연구는 AI 보안 검토가 쓸모없다는 것을 보여주지 않았다. 규율 있는 검증 없는 탐지가 왜 여전히 비용이 많이 들고 위험한지를 보여줬다.

다음 시험대는 제품 팀과 구매자의 몫이다. 발견 사항이 긴급 업무로 엔지니어에게 전달되기 전에 코드 추적, 환경 점검, 재현 가능한 검증을 통과한다는 증거를 요구하라. 귀사의 보안 벤더는 두 종류의 실수를 모두 공개할 것인가, 아니면 그 뒤에 쌓인 검토 대기열은 공개하지 않은 채 속도만 계속 판매할 것인가?