Carbon의 보안 점수 세 개는 하나의 성공률이 아니다: 평가 조건·접근·단가 분리

보안 에이전트의 도입 제안서를 읽을 때 가장 위험한 요약은 서로 다른 점수 옆에 화살표를 붙여 하나의 자동 해결 과정으로 만드는 것이다. 취약점을 찾는 시험, 악용 가능성을 검증하는 시험, 원인을 고치는 시험은 모두 보안 업무와 관련되지만 같은 문제를 끝까지 해결했는지 측정한 하나의 실험은 아니다. 숫자가 높다는 사실보다 그 숫자로 어떤 결정을 내릴 수 있는지를 먼저 나눠야 한다.

Google은 2026년 10월 28일 Gemini 4 Carbon을 발표했다. 이 글은 10월 31일 수집·검증된 공식 발표문과 가격 각주를 바탕으로, 세 보안 점수의 해석 범위를 정리한다. 11월 1일은 이 글의 예정 공개일이지 모델 발표일이나 일반 제공 개시일이 아니다. 이 글은 발표문에 근거한 편집 분석이며, Carbon 실행이나 독립 벤치마크 재현 결과가 아니다.

1. 세 점수는 세 개의 다른 질문에 답한다

공식 발표가 제시한 수치는 SEC-bench Pro의 취약점 탐지 88.2%, ExploitGym의 악용 가능성 검증 54.8%, CWE-bench의 패치 71.0%다. 모두 공급자가 보고한 값이다. 이 글은 순위나 타사 대비 우위를 독립 검증한 것으로 다루지 않는다.

평가	발표 수치	묻는 질문	이 숫자만으로 알 수 없는 것
SEC-bench Pro	88.2%	취약점을 찾아내는 과제를 얼마나 수행했나?	우리 저장소에서 놓칠 취약점 수와 오탐 부담
ExploitGym	54.8%	주어진 평가에서 악용 가능성을 얼마나 검증했나?	탐지된 동일 취약점 전체의 검증 성공률
CWE-bench	71.0%	해당 패치 과제를 얼마나 해결했나?	탐지부터 배포까지 이어진 자동 수정 성공률

탐지·악용 검증·패치는 서로 다른 외부 평가다. 공급자 수치이며 같은 문제의 연속 성공률이 아니다. 출처: blog.google/innovation-and-ai/models-and-research/gemini-models/introducing-gemini-4-carbon.

발표문은 이 세 값이 동일한 문제 집합을 순서대로 통과한 조건부 확률이라고 설명하지 않는다. 따라서 값을 곱해 전체 성공률을 만들거나, 평균을 내어 대표 보안 성능으로 제시하면 실험이 제공하지 않은 의미를 만들어낸다. 같은 백분율 표기를 쓴다고 분모가 같아지는 것은 아니다. 원문만으로 각 시험의 정확한 인스턴스 수, 반복 횟수, 신뢰구간, 원시 실행 로그는 확인할 수 없으므로 임의로 보충하지 않는다.

특히 패치 점수를 우리 서비스의 자동 복구 확률로 바꾸려면 빠진 연결이 많다. 실제 입력 저장소, 발견 결과가 검증 단계로 넘어가는 기준, 패치 뒤 회귀 테스트, 사람의 승인, 배포 후 영향까지 같은 평가에 묶였는지가 필요하다. 발표의 수치는 후속 시험의 이유가 될 수 있지만 그 연결을 대신 증명하지 않는다.

2. 가드레일 없는 평가와 운영 보호장치는 별도다

공식 본문은 위 외부 벤치마크를 가드레일 없이 평가했다고 명시한다. 이는 점수를 읽을 때 반드시 붙여야 할 조건이다. 보호장치가 켜진 실제 제품에서도 같은 수치가 재현된다는 뜻은 아니며, 반대로 모든 실제 배포가 보호장치 없이 제공된다는 뜻도 아니다. 발표는 모델 학습, 실시간 오용 방어, 프롬프트 주입 대응, 사고 과정 모니터링을 포함한 다층 안전 체계도 별도로 설명한다.

발표의 가드레일 없는 평가 조건과 팀이 확인할 운영 권한을 분리했다. 운영 항목은 편집 제안이다. 출처: blog.google/innovation-and-ai/models-and-research/gemini-models/introducing-gemini-4-carbon.

실무에서는 성능 기록과 권한 기록을 같은 칸에 넣지 않는 편이 낫다. 예를 들어 평가 보고서에는 실행 조건과 과제 범위를 적고, 운영 계획에는 허용 저장소, 읽기·쓰기 범위, 네트워크 접근, 승인과 되돌리기 경로를 적는다. 이는 원문에서 검증한 운영 절차가 아니라 발표 조건에서 도출한 편집 제안이다. 성능을 확인하기 위해 운영의 승인 경계를 지워야 한다는 결론은 나오지 않는다.

보조 안전 수치도 같은 원칙으로 읽는다. 발표에는 프롬프트 주입 평가의 공격 성공 0.0%, Terminal-Bench 4.0의 부정행위 성공 0.0%와 시도 0.4%가 나온다. 여기서 4.0은 평가의 버전이다. 성공과 시도는 다른 지표이며, 서로 다른 시험에서 나온 영점을 합쳐 무위험 인증으로 해석할 수 없다. 발표문에 정확한 공격·시도 분모가 없으므로 앞으로의 공격 성공 가능성이 영원히 없다는 통계적 보장도 계산하지 않는다.

3. 접근 계획과 가격표는 성능표 밖에 둔다

발표 시점의 접근 계획은 일부 사이버 방어 담당자에게 우선 제공하고 Fairwind Program을 통해 신뢰 파트너를 점진적으로 늘리는 방식이다. 개발자·기업·소비자 대상으로는 향후 확대를 예고한다. 발표문의 '이번 주'는 10월 28일 발표 시점에 묶인 표현이며 이 글의 공개 주간에 대한 새 약속으로 옮기지 않는다.

따라서 발표가 존재한다는 이유만으로 독자의 계정에서 호출할 수 있다고 말할 수 없다. 이 글은 현재 모델 식별자, 계정별 권한, 모든 API의 제공 여부를 확인하지 않았다. 일반 제공 날짜 역시 이 발표문에는 명시돼 있지 않다. 실제 시험 계획에는 이용 가능한 계정과 호출 경로를 별도로 확인하는 단계가 필요하다.

발표의 가격 조건	입력 100만 토큰당	출력 100만 토큰당	해석 경계
도입 가격	$2	$10	발표에 제시된 조건이며 독자의 청구서 확인이 아님
도입 기간 종료 후 가격 각주	$4	$20	각주 1의 안내이며 종료 날짜는 이 근거에 명시되지 않음

도입 가격 설명에는 캐시 입력 토큰이 입력 가격보다 95% 할인된다는 조건도 있다. 그러나 캐시 적격성이나 향후 기간에도 같은 할인 조건이 이어지는지는 이 각주만으로 추정하지 않는다. 입력·출력 단가를 모두 안다고 해서 재시도, 도구 실행, 검토와 배포를 포함한 작업 전체 비용이 정해지는 것도 아니다. 예정 공개일인 11월 1일에도 같은 요금이 적용된다는 보장으로 쓰지 않는다.

발표 시점 접근 계획과 기간별 토큰 단가는 별도 조건이다. 실제 계정 접근·청구나 일반 제공일을 확인한 그림이 아니다. 출처: blog.google/innovation-and-ai/models-and-research/gemini-models/introducing-gemini-4-carbon.

4. 도입 제안서는 점수 대신 증거 필드로 비교한다

아래 표는 이 발표를 실제 검토 문서로 바꾸기 위한 작성 예시다. 제품을 사용해 얻은 결과가 아니라, 무엇을 공급자 주장으로 남기고 무엇을 우리 환경에서 확인해야 하는지 분리하는 의사결정 도구다. 탐지 점수는 탐지 후보를 검토할 근거이고, 패치 적용 권한을 승인하는 근거는 아니다.

의사결정	지금 보유한 근거	추가로 채울 증거 필드	아직 승인하지 않는 결론
탐지 시험 후보로 검토	SEC-bench Pro의 공급자 보고	대상 언어·저장소, 정답 기준, 오탐·누락 검토 방식	우리 코드에서 같은 탐지율 보장
위험 검증 범위 설계	ExploitGym의 공급자 보고	허가된 격리 환경, 시험 범위, 성공 판정	운영 서비스 대상의 무제한 악용 시험
패치 제안 검토	CWE-bench의 공급자 보고	실패 테스트 재현, 변경 diff, 회귀 검사, 승인자	검토 없는 운영 배포
실제 호출 가능성 판단	제한 접근·점진 확대 계획	사용 계정, 확인 시각, 승인된 호출 경로	전 계정 즉시 사용 가능
예산 검토	도입 단가와 종료 후 각주	적용 기간, 실제 토큰 사용, 캐시 조건, 도구 비용	전체 업무의 고정 비용 확정

탐지 후보·검증 범위·패치 제안마다 추가로 채울 증거를 대응시킨 의사결정 도식이다. 제품 실행 결과가 아니다. 출처: blog.google/innovation-and-ai/models-and-research/gemini-models/introducing-gemini-4-carbon.

예컨대 팀에 '취약점 경고를 정리하고 패치 후보를 제안하는 읽기 중심 시험'이 필요하다면, 먼저 탐지와 패치 제안의 평가 기록을 별도 행에 둘 수 있다. 제안된 수정이 존재한다는 것과 그 수정이 안전하게 배포됐다는 것은 다른 상태다. 이때 성공 기준은 발표 수치의 복사가 아니라, 우리 코드의 정답과 회귀 검사로 명시해야 한다. 이 예시는 시험 설계에 대한 편집 분석이며 Carbon이 그 절차를 실제 수행했다는 사례가 아니다.

5. 빈칸을 실패나 보장으로 바꾸지 않는 법

표에 '확인하지 않음'이 남는 것은 잘못된 결론을 낸 것과 다르다. 계정 접근을 확인하지 않았다는 사실은 접근이 거절됐다는 증거가 아니다. 인스턴스 수를 모른다는 사실 역시 평가가 무가치하다는 증거는 아니다. 다만 빈칸을 지우고 전체 성공률이나 확정 예산을 적을 수 없다는 뜻이다.

검토 문서에는 출처의 주장, 조건, 아직 모르는 값, 팀이 내린 판단을 구분해 남기면 좋다. 추후 계정 권한이나 가격을 확인하면 해당 필드를 갱신하고, 보안 시험을 실행하면 실제 입력과 결과를 추가한다. 그때도 과거 발표의 조건과 새 관측을 섞지 않아야 변화의 이유를 설명할 수 있다. 원문에 없는 표본 수나 일반 제공 일정을 추측해 채우는 것보다, 확인 대상이 무엇인지 정확히 적는 편이 다음 행동에 유용하다.

결론적으로 Carbon의 세 보안 점수는 서로 다른 평가 과제를 검토할 출발점이다. 가드레일 없는 평가 조건, 제한 접근 계획, 기간별 토큰 단가는 각각 별도 근거다. 이들을 하나의 운영 성공률로 압축하지 않을 때, 무엇을 시험할지와 무엇을 아직 승인하지 않을지가 분명해진다.

6. 근거와 읽기 범위

• 공식 발표: Google, Gemini 4 Carbon: our next frontier model — 2026년 10월 28일. 보안 평가, 가드레일 조건, 제한 접근, 가격 본문과 각주 1을 확인했다.
• 이 글의 표와 그림은 해당 발표에서 작성한 비교·경계 도식이다. 실험 화면, 모델 실행 결과 또는 Google의 공식 운영 지침이 아니다.
• 별도 관련 글 링크는 추가하지 않았다. 이번 패키지는 동결된 단일 발표의 평가 조건과 가격 각주를 깊게 읽는 범위이며, 확인되지 않은 내부 글 주소를 만들어 연결하지 않는다.