취약점 후보를 많이 찾는 모델과, 정상 동작을 유지하면서 그 취약점을 고치는 모델은 같은 기준으로 평가할 수 없습니다. Gemini 4 Carbon의 세 보안 점수도 서로 다른 시험의 결과입니다. 이를 하나의 “보안 정확도”로 묶으면 도입 판단에 필요한 차이가 사라집니다.

Google의 10월 28일 발표는 SEC-bench Pro 88.2%, ExploitGym 54.8%, CWE-bench 71.0%를 제시합니다. 해당 외부 보안 평가는 guardrails 없이 수행했다고 명시합니다. 초기 접근은 일부 사이버 방어 담당자와 Fairwind 파트너에 제한되며, 일반 개발자 제공은 예정입니다. 이 글은 10월 29일 자료 검토이며 Carbon을 사용하지 않았습니다.

세 시험은 어떤 실패를 드러내는가

자료 원문에서 확인한 평가 대상 결과를 업무에 옮길 때의 질문
SEC-bench Pro 취약점 발견과 PoC 생성, 컨테이너·메타데이터·검증 하네스 보고한 결함을 고정된 환경에서 재현할 수 있는가
ExploitGym 실제 취약점에 기반한 exploit 개발, userspace·V8·Linux 대상 알려진 결함의 악용 가능성을 확인하는 능력과 신규 발견을 구분했는가
CWE-bench 코드베이스를 감사하고 수정, 결함 차단과 기존 기능 보존 수정이 재현 사례만 막고 정상 요청도 막아버리지는 않는가

벤치마크 제작자의 정의와 Google의 결과 보고는 근거의 역할이 다릅니다. 제작자 문서는 “무엇을 시험하는가”를 설명하고, Google 발표는 “그 시험에서 얼마를 얻었다고 보고하는가”를 설명합니다. 열어 본 SEC-bench 페이지에서 Carbon의 88.2%를 별도 확인하지는 못했습니다. 세 수치 모두 독립 재현으로 표시하지 않습니다.

서로 다른 과제의 점수를 평균내는 데는 공통된 표본과 가중치의 근거가 없습니다. 세 값을 곱해 “발견부터 수정까지 성공할 확률”로 쓰는 것도 불가능합니다. 뒤 단계가 앞 단계에서 성공한 동일 사례에 조건부로 측정됐다는 자료가 필요하기 때문입니다.

패치 평가에서는 분모와 시도 횟수가 함께 움직인다

CWE-bench의 현재 v1 설명은 120개 과제에 모델마다 4회 rollout을 수행하고, high reasoning과 회당 1시간 한도를 둡니다. 프로그램 기반 판정과 에이전트 심사 결과를 나란히 구분합니다. 이것은 제작자의 현재 프로토콜 설명이며, Google 발표의 세 평가가 모두 이 조건을 썼다는 뜻은 아닙니다.

왜 시도 횟수가 중요할까요? 한 번에 들어맞는 패치와 여러 패치를 만들고 나중에 정답을 고른 결과는 다른 제품 경험입니다. 운영 환경에서 재시도를 허용하려면 검증 비용과 잘못된 패치를 되돌리는 비용도 부담해야 합니다. pass@1과 pass@4를 같은 성공률처럼 비교하면 이 차이가 가려집니다.

또한 테스트가 취약점 재현 한 가지만 검사하면, 문제 기능을 통째로 지우는 수정도 성공처럼 보일 수 있습니다. CWE-bench가 기존 기능 보존과 판정 무결성을 따로 다루는 이유를 실제 리뷰에도 적용할 수 있습니다. 점수의 높고 낮음보다 어떤 실패를 판정기가 놓치는지부터 읽어야 합니다.

우리 저장소에서 필요한 것은 ‘발견 수’보다 증거 묶음

다음은 보안 패치를 받기 위한 CodeBridge의 제안입니다. Carbon 실험 결과나 공식 권장 설정이 아닙니다. 실제 서비스 대신 권한이 있는 격리된 테스트 코드와 합성 데이터에 적용하는 검토 기준입니다.

단계 남길 산출물 거절하거나 검토를 이어갈 조건
발견 영향받는 함수·버전·입력 조건 원인 대신 추측만 있는 경우
재현 수정 전 실패하는 최소 회귀 테스트 환경을 고정해도 재현되지 않는 경우
수정 변경 diff와 원인 제거 설명 검증기 우회나 기능 삭제로 통과한 경우
보존 정상 입력과 경계 입력의 테스트 원래 허용되어야 할 요청이 실패하는 경우
전달 미확인 범위, 의존성, 남은 위험 “안전함”만 주장하고 범위를 설명하지 않는 경우

예를 들어 경로 검증 패치라면 잘못된 경로가 거절되는 것 외에 정상 상대 경로가 계속 동작하는지 확인해야 합니다. 파일 읽기를 모두 막는 패치는 특정 재현 테스트를 통과해도 제품의 요구사항을 충족하지 못합니다. 이 사례는 검토 시나리오이며 실제 취약 코드나 exploit을 실행하지 않았습니다.

긴 작업에서도 같은 기준이 필요합니다. 시간이 오래 걸렸다는 사실은 정확성의 증거가 아닙니다. 시도별 커밋, 실패 이유, 재현 결과를 남겨야 사람이 최종 패치까지의 경로를 확인할 수 있습니다. AI 보안 벤치마크 글과 함께 보면 모델 순위와 운영 가능한 결과를 나눠 읽는 데 도움이 됩니다.

지금 준비할 수 있는 도입 조건

일반 접근이 열리지 않은 상태에서 API 모델 ID나 설치 명령을 추정할 이유는 없습니다. 먼저 과거에 수정한 결함 중 재현 가능한 사례를 모으고, 당시 패치를 숨긴 평가용 복사본에서 수정 전 실패·수정 후 통과·정상 기능 보존을 확인할 체계를 준비할 수 있습니다.

guardrails 없는 능력 평가를 실제 제공 제품의 동작으로 그대로 치환해서도 안 됩니다. 접근 정책과 실행 환경이 달라질 수 있습니다. 발표된 전체 수치의 표본, 예산, 구성에 대한 독립 확인과 자체 재현은 이 글에서 완료하지 않았습니다.

Carbon의 발표가 던지는 유용한 질문은 “어느 모델이 보안 1위인가”보다 “패치 하나를 신뢰하려면 어떤 증거가 필요한가”입니다. 그 기준을 먼저 정하면 새 모델을 사용할 수 있게 됐을 때에도 같은 기준으로 비교할 수 있습니다.

아래 공개 유료 강의는 에이전트의 실행·검증 구조를 배우는 선택지입니다. Carbon 접근권이나 보안 벤치마크 실습을 제공한다고 의미하지 않습니다. 링크는 홍보 링크입니다.