Gemini 4 Carbon 발표에서 성능과 접근 범위를 따로 봐야 하는 이유

발표의 중심은 오래 걸리는 엔지니어링 작업

Google DeepMind는 10월 28일 Carbon을 발표하며 여러 도구를 거치는 코딩과 보안 작업을 강조했습니다. 공개한 사례에는 대형 코드베이스에서 결함의 원인을 찾고 수정하는 작업이 포함됩니다. 발표에 나온 내부 사례는 제공사가 운영한 환경에서 나온 결과이므로, 개별 팀의 코드베이스에서 같은 결과가 나온다고 볼 근거로는 부족합니다.

벤치마크는 어떤 작업을 측정했나

Google이 공개한 수치에서 SEC-bench Pro의 취약점 탐지는 88.2%, CWE-bench의 수정은 71.0%였습니다. 탐지와 수정은 별도 과제이며, 발표는 외부 벤치마크 평가에 가드레일을 적용하지 않았다고 명시합니다. 자체 도입을 검토한다면 원인 분석이 맞았는지, 패치가 회귀 테스트를 통과했는지, 사람의 검토 시간이 얼마나 들었는지를 따로 기록하는 것이 비교에 도움이 됩니다.

발표 시점에 누가 써볼 수 있었나

초기 제공 대상은 일부 보안 방어팀이었습니다. Google은 이후 Fairwind 프로그램을 통해 신뢰할 수 있는 파트너로 접근을 넓히겠다고 밝혔습니다. 따라서 10월 28일을 기준으로 기록하는 이 글에서는 모델 발표일과 일반 개발자의 이용 가능 시점을 구분합니다.

팀이 재현할 수 있는 평가로 바꾸기

긴 코드 작업에 모델을 쓰려는 팀이라면, 이미 수정이 끝나 정답을 아는 사내 이슈를 먼저 고르는 편이 좋습니다. 재현 절차와 작업 전 커밋을 준비한 뒤, 현재 쓰는 도구와 새 모델에 같은 권한과 시간을 줍니다. 보고서에는 모델이 지목한 파일과 원인, 수정 범위, 실행한 검사, 리뷰어가 다시 확인한 시간을 적습니다. 단순히 패치를 만들었는지만 비교하면 손대지 말아야 할 코드를 건드렸거나 정작 재현 조건을 놓친 경우가 묻힙니다.

탐지와 수정도 따로 채점할 수 있어요. 원인을 정확히 찾았는데 기존 동작을 깨뜨리는 수정이라면 탐지 점수와 패치 점수는 달라요. 반대로 테스트가 통과해도 테스트가 결함을 재현하지 못했다면 해결 근거가 약합니다. 몇 건을 짧게 비교할 때는 점수 평균과 함께 실패 사례 하나를 남기는 것이 좋습니다. 모델이 오랫동안 탐색할 수 있다는 특성이 실제로 복잡한 문제에서 도움이 되는지, 검토자가 확인해야 할 범위만 넓어지는지 판단할 수 있기 때문입니다.

접근이 열리기 전에도 준비할 수 있는 것

발표 당시에 대상이 아니었던 팀은 특정 모델을 전제로 작업 흐름을 바꾸기보다 재현 가능한 평가 묶음을 먼저 준비할 수 있어요. 실패한 테스트 하나, 결함 설명 하나, 기대하는 동작과 허용된 수정 범위를 한 세트로 정리하는 식입니다. 나중에 접근할 수 있게 되면 같은 자료로 기존 도구와 비교할 수 있고, 접근이 늦어져도 그 자료는 다음 코드 리뷰와 회귀 검사에 쓸 수 있어요. Carbon 발표를 검토하는 출발점은 수치가 가장 높은 표를 고르는 일이 아니라, 우리 팀이 반복해서 측정할 수 있는 작업을 정하는 일입니다.