Gemini 4 Carbon의 두 가지 59점: 지능 1위가 코딩 에이전트 1위는 아니다

Gemini 4 Carbon은 종합 지능 평가에서 59점으로 1위에 올랐고, 코딩 에이전트 평가에서도 59점을 받았지만 2위였습니다. 같은 숫자라도 서로 다른 지수이므로 합치거나 동일한 성공률로 읽으면 안 됩니다.

Artificial Analysis의 10월 28일 평가는 이 차이를 명시합니다. Google의 같은 날 발표는 초기 접근을 일부 사이버 방어 담당자와 신뢰할 수 있는 파트너부터 단계적으로 제공한다고 설명합니다. 아래는 10월 30일 원문 검토이며, Carbon 호출이나 독립 벤치마크 재실행은 하지 않았습니다.

점수 옆에 평가 단위를 적으면 해석이 달라진다

다음 표는 평가 기관의 10월 28일 발표에 기록된 값을 다시 정리한 것입니다. 실시간 순위표나 CodeBridge 측정치가 아닙니다.

여기서 첫 번째 질문은 “어느 모델이 더 똑똑한가”이고 두 번째는 “특정 실행 환경에서 어떤 코딩 시스템이 결과를 냈는가”에 가깝습니다. 코딩 시스템은 모델뿐 아니라 도구, 관찰, 재시도, 컨텍스트 관리와 종료 조건으로 구성됩니다. 숫자가 같다고 측정 대상까지 같아지지는 않습니다.

62와 59의 차이도 3%포인트의 성공률 차이가 아닙니다. 또한 이 발표만으로 그 차이의 통계적 유의성이나 우리 저장소에서의 우열이 입증되는 것은 아닙니다. 작업별 결과와 불확실성이 있어야 그런 결론을 검토할 수 있습니다.

하네스를 고정하라는 조언이 답하지 못하는 질문

실제 도입에는 서로 다른 두 비교가 필요합니다.

오늘 구매해서 사용할 도구를 고르는 비교라면 각 제품의 기본 하네스를 포함해 시험하는 편이 맞습니다. 도구를 바꿀 수 없는 사용자는 제품 전체의 결과를 받기 때문입니다. 대신 결론도 “이 모델이 낫다”가 아니라 “이 설정의 제품이 이 작업에서 낫다”여야 합니다.

모델 교체의 효과를 확인하는 비교라면 하네스, 도구 스키마, 예산, 환경과 데이터셋을 고정해야 합니다. 다만 두 모델을 같은 하네스에서 지원하지 않는다면 비교를 억지로 만들지 말아야 합니다. high와 max라는 이름도 서로 같은 연산 예산을 뜻한다고 볼 수 없습니다.

따라서 공개 순위표는 후보를 좁히는 근거가 됩니다. 모델만 바꿨을 때의 인과 효과를 알려주는 실험으로 사용할 수는 없습니다. 모델과 하네스를 구분하는 글에서 이 차이를 더 설명합니다.

비용 23% 감소의 정확한 범위

Artificial Analysis는 Intelligence Index의 표준 가격 비용을 Carbon $7.76, Opus 5.5 max $10.04로 보고합니다. 절감률 계산은 다음과 같습니다. Node.js 18 이상에서 cost.mjs로 저장해 node cost.mjs로 실행할 수 있으며, 추가 설치나 API 호출은 없습니다.

const carbon = 7.76;
const opus = 10.04;
const reduction = 100 * (opus - carbon) / opus;
console.log(`${reduction.toFixed(1)}%`);

로컬에서 실행한 출력:

22.7%

이 계산이 재현하는 것은 두 공개 비용 값의 상대 차이뿐입니다. 원래 평가를 재현한 것도, 코딩 비용 22.7% 절감을 측정한 것도 아닙니다. 할인 가격과 표준 가격을 섞거나, 이 값을 Coding Agent Index 점수로 나눠 “코딩 성공당 비용”이라고 부르면 서로 다른 과제를 한 식에 넣게 됩니다.

실제 개발 작업에서는 실패한 시도 비용도 남습니다. 동일한 작업 집합에서 모든 시도의 총비용을 외부 검증을 통과한 작업 수로 나눠야 팀의 성공 작업당 비용을 얻을 수 있습니다. 성공이 0건이면 그 지표는 계산 불가로 보고해야 합니다. 리뷰 시간이나 테스트 인프라 비용을 포함하는지도 따로 명시해야 합니다.

접근권을 기다리는 동안 만들 수 있는 비교 기록

아래는 CodeBridge가 제안하는 기록 예시이며, 실제 모델 실행 결과나 API 설정 파일이 아닙니다.

comparison_goal: choose an available coding product
task_id: regression-017
repo_commit: <fixed commit>
environment_digest: <pinned test image>
system: <model + harness version + reasoning setting>
budget: <same time limit, cost ceiling, retry limit>
acceptance: <failing regression plus preserved behavior>
result: <pass / fail / blocked; independent test evidence>
spend: <all attempts, cache and discount rules included>

회귀 버그를 예로 들면 수정 전에 실패하는 테스트와 수정 후 유지되어야 하는 정상 동작을 준비합니다. 에이전트가 테스트를 바꾸거나 도구 오류를 성공으로 보고하는 경우를 걸러내기 위해 최종 검증은 작업 실행과 분리해야 합니다. 모델 이름과 최종 diff만 저장하면 실패한 재시도나 비용을 나중에 복원하기 어렵습니다.

이는 앞으로 수행할 비교 절차입니다. 여기서는 데이터셋을 만들거나 모델을 실행하지 않았고, 비공개 접근을 전제로 명령이나 모델 ID를 추정하지도 않았습니다. 공개되지 않은 하드웨어·실행 예산·세부 설정을 임의로 채워 넣지 않습니다.

Carbon의 발표는 평가 후보를 바꿀 만한 소식입니다. 그러나 팀의 도구를 바꾸는 결정에는 실제 접근 가능성, 사용할 하네스, 검증할 작업과 예산이 함께 필요합니다. 보안 점수의 서로 다른 분모는 기존 Carbon 보안 평가 글에서 다루므로 여기서는 반복하지 않습니다.

아래 공개 유료 강의는 모델을 둘러싼 실행·검증·루프 구조를 이해하는 학습 선택지입니다. Carbon 이용권이나 해당 평가의 재현을 제공하는 강의는 아니며, 링크는 홍보 링크입니다.