CyberGym 벤치마크 해설: E2E 점수가 실제로 측정하는 것

가장 널리 유포되는 CyberGym 점수, 즉 출시 게시물에 나온 숫자이자 모델 간 비교에 쓰이는 숫자는 131개의 필터링된 과제에 대한 과제 성공률이다. 여기서 성공이란 에이전트가 패치되지 않은 C/C++ 빌드를 크래시시키는 개념 증명(PoC) 입력을 생성하고, 그 크래시를 막는 패치를 작성했으며, 프로젝트의 개발자가 작성한 테스트를 깨뜨리지 않았다는 뜻이다. BenchLM의 집계에서 MiMo-V2.6-Flash가 95.1%로 선두이고 MiMo-V2.6-Pro가 94.0%이며, DeepSeek-V4.1-Flash는 80%대 후반에서 몇 점 뒤처진다. 그 표를 인용하면서 숫자의 비교 가능성을 좌우하는 세 가지를 언급하는 사람은 거의 없다: 벤치마크가 둘 이상의 구현으로 존재한다는 점, 대부분의 행이 독립 실행이 아니라 제공업체의 자체 보고라는 점, 그리고 가장 흥미로운 단일 단계는 기록되지만 집계되지 않는다는 점이다. 그것은 동일한 출처 표기 기준, 즉 AI 사고 아카이브가 자체 항목에 적용하는 기준이다 — 출처 없는 주장은 결과가 아니다 — 그리고 CyberGym 코퍼스는 평판이 시사하는 것보다 더 자주 그 기준을 충족하지 못한다.

이 문서는 벤치마크가 에이전트에게 무엇을 요구하는지, 과제 세트가 어떻게 구축되었는지, 구현들이 어디에서 서로 갈리는지, 그리고 방어자가 높은 점수로부터 무엇을 결론지어야 하고 무엇을 결론지어서는 안 되는지를 설명하는 안내서입니다.

과제: 아무것도 망가뜨리지 않고 찾기, 재현하기, 패치하기

CyberGym은 버클리 책임 있는 탈중앙화 지능 센터(Berkeley Center for Responsible, Decentralized Intelligence)에서 나왔으며, 그 전제는 의도적으로 좁습니다. 각 과제는 널리 사용되는 오픈소스 C/C++ 프로젝트의 메모리 안전 취약점을 겨냥합니다. 에이전트는 버그를 찾아내고, 새니타이저 크래시를 유발하는 개념 증명 입력을 작성한 다음, 크래시가 더 이상 재현되지 않도록 코드를 패치해야 하며, 그동안 프로젝트 자체 테스트는 계속 통과해야 합니다. 바로 그 순서가 핵심입니다. "버그를 찾아라"만 요구하는 벤치마크는 패턴 인식을 보상할 것입니다. 작동하는 크래시 입력과 기존 기능을 깨뜨리지 않는 패치를 요구함으로써, 에이전트는 의심에서 입증된 결함으로, 다시 수정으로 이어지는 순환을 완성하도록 강제됩니다.

RDI는 공격 및 방어 단계 전반에 걸친 AI 사이버 역량을 추적하는 더 넓은 관측소 안에서 이 벤치마크를 운영하며, 그 설정은 주목할 만하다. CyberGym은 ExploitGym 및 엔드투엔드 변형과 함께 하나의 벤치에 놓인 측정 도구 중 하나다. 이를 독립형 리더보드로 읽으면 그 맥락을 잃게 되는데, 이는 수치가 다른 맥락으로 잘 옮겨가지 않는 이유 중 하나다.

4개의 스테이지, 그중 3개는 점수가 산정됩니다

채점 규칙은 이 벤치마크에서 가장 보고가 적은 부분입니다. 바로 이 지점에서 그럴듯하게 들리는 점수가 실제로 벌어진 일과 어긋날 수 있기 때문입니다.

1단계는 재현 단계입니다: 에이전트의 개념 증명(PoC) 입력이 패치되지 않은 빌드를 크래시시키는지 확인합니다. 2단계는 패치 단계입니다: 제출된 변경이 그 특정 크래시를 막는지 확인합니다. 3단계는 회귀 단계입니다: 개발자가 작성한 기능 테스트가 여전히 통과하는지 확인합니다. 이 세 단계가 점수를 산출합니다.

4단계는 패치가 실제 정답(ground-truth) 취약점을 수정하는지를 묻고, 이는 집계되지 않고 진단용으로 기록됩니다. 그 비대칭성은 잠시 짚고 넘어갈 가치가 있습니다. 왜냐하면 그것은 "에이전트가 크래시를 사라지게 할 수 있다"와 "에이전트가 버그를 고칠 수 있다"의 차이이기 때문입니다. 둘 다 유용한 주장이지만, 같은 주장은 아닙니다. 신호를 잡아내거나, 범위 검사를 오버플로 너머까지 넓히거나, 코드 경로를 완전히 비활성화하는 방식으로 크래시를 억제하는 에이전트는 1단계부터 3단계까지는 점수를 얻고 4단계에서는 실패할 것입니다. 어떤 보고서가 4단계가 고려되었는지 말하지 않은 채 단일 숫자만 보고한다면, 두 가지 중 무엇이 측정되었는지 알 수 없습니다. 그리고 그 진단은 바로 여러분이 그것을 물어볼 수 있도록 존재합니다.

131개의 과제가 어떻게 선정되었는지 — 그리고 그것이 점수에 미치는 영향

원본 데이터셋은 채점 대상 세트보다 크며, 필터링은 비교 가능성에 가장 큰 영향을 미치는 단일 요인입니다. RDI의 데이터셋은 Google의 OSS-Fuzz에서 가져온 139개 오픈소스 프로젝트 전반의 920개 취약점을 포함합니다. 서드파티 추적기가 사용하는 엔드투엔드 변형은 이를 131개 태스크로 좁히며, 프로젝트당 하나의 태스크를 난이도에 따라 선정하고, 오라클 누출이나 샌드박스 호환성 제약이 있는 태스크는 제외합니다.

세 가지 결과가 곧바로 뒤따른다. 첫째, 프로젝트당 하나의 작업은 점수가 깊이보다는 폭에 의해 좌우된다는 뜻이다. 즉, 여러 프로젝트에서 평균 수준인 에이전트가 세 개에서 탁월한 에이전트보다 더 나은 성과를 낼 것이며, 이는 방어 가능한 설계 선택이자 "이 에이전트가 얼마나 많은 취약점을 고칠 수 있는가"와는 다른 측정이다. 둘째, 오라클 누출 제외는 정답이 추론되는 것이 아니라 환경에서 발견 가능한 작업을 제거하므로, 남은 집합은 특정한 방식으로 더 어렵다. 즉, 쉬운 작업을 제거하는 것이 아니라 지름길을 제거하는 것이다. 셋째, 작업당 90분의 예산은 프로젝트의 OSS-Fuzz 이미지로 구축된 샌드박스 내부에서 성공의 정의 일부이지 세부 사항이 아니다. 왜냐하면 실제 취약점 작업의 상당 부분이 바로 그런 종류의 제약으로 한정되며, 무제한 탐색에 의존하는 에이전트는 다른 곳에서는 성공하더라도 여기서는 실패할 것이기 때문이다.

과제 선택 규칙을 무시하는 모든 비교는 이름만 같은 두 개의 서로 다른 테스트를 비교하는 것이다.

두 가지 구현, 그리고 그것들이 반드시 일치할 필요가 없는 이유

혼란의 대부분은 바로 여기에서 비롯됩니다. CyberGym-E2E는 RDI 벤치마크로도 존재하고 제3자 평가자가 실행하는 구현으로도 존재하는데, 이 둘이 동일한 모델에 대해 같은 수치를 산출한다고 보장되지는 않습니다. 평가자 자체 문서에서도 이를 분명히 밝힙니다. 그 구현은 난이도에 따라 선택된 프로젝트당 하나씩인 131개 과제로 구성된 필터링된 세트를 사용하며, 각 과제를 프로젝트의 OSS-Fuzz 이미지로 구축된 격리 샌드박스에서 자체 에이전트 하네스를 사용해 과제당 90분의 예산으로 실행합니다.

그 문장에는 점수를 결정하는 두 변수가 들어 있습니다. 하네스는 에이전트가 실행되는 루프입니다 — 도구 출력을 어떻게 관찰하는지, 몇 단계까지 수행할 수 있는지, 실패한 시도에서 어떻게 복구하는지. 더 강한 하네스와 더 약한 모델의 조합은 그 반대 조합을 이길 수 있으며, 하네스는 모델 가중치의 일부가 아닙니다. 예산은 둘 모두와 상호작용합니다. 따라서 CyberGym 수치는 "이 모델, 이 하네스, 이 구현"으로 제대로 표기해야 하며, 구현 없이 인용된 수치는 분모 없는 숫자입니다.

언급할 가치가 있는 2차 효과가 있습니다. 하네스가 실제 작업을 수행하기 때문에 두 모델 버전 간의 CyberGym 점수 향상은 부분적으로 하네스 개선일 수 있으며, 자체 하네스 결과를 보고하는 벤더는 모델 역량이 아니라 시스템 역량을 보고하는 것입니다. 둘 다 타당하지만, 둘을 혼동하는 것은 타당하지 않습니다.

트래커 표를 솔직하게 읽기

대부분의 사람이 접하는 표는 2차 편집물이며, 그 자체로 출처를 표시합니다. 표시를 읽어 보면 바로 그 부분이 유용합니다. 29개 행 중 7개는 벤치마크 소유자 또는 독립 실행에서 나왔고, 21개는 공급자 자체 보고이며, 하나는 2차 보고입니다. 이 편집물은 해당 표를 참고용으로 제시할 뿐 그에 기반해 순위를 매기지 않는다고 분명히 밝히고, 대부분의 행이 자체 보고이므로 주의 깊게 읽으라고 권고합니다. 페이지에서 가장 유용한 줄은 이 편집물 자체의 포화 관련 주석입니다. 상위 3개는 약 70점에 걸쳐 퍼져 있는 반면 상위 10개는 대략 10점 이내에 몰려 있어, 표는 여전히 모델들을 구분하지만 순서가 빈약한 최상위 구간에서는 그렇지 않습니다.

공급자 자체 보고는 제시 가능한 증거다. 이는 독립적 측정이 아니며, 그 차이는 대부분의 경우보다 이 벤치마크에서 더 중요하다. 하네스 변수는 벤더가 보고하는 수치를 조정할 상당한 여지를 주기 때문이다. 자체 보고와 독립 실행이 불일치하면 독립 실행이 우선한다. 자체 보고만 존재할 때 정직한 해석은 "검증되지 않음, 그럴듯함, 비교 가능한 기준선 없음"이다.

이 벤치마크가 독자들에게 놓는 함정에도 같은 주의가 반대로 적용된다. CyberGym 행이 없는 모델은 0점을 받은 것이 아니다. 그 모델은 해당 하네스에서 측정된 적이 없으며, 이는 다른 이야기다. 부재를 실패로 취급하는 순간 표는 측정을 그치고 리더보드가 된다.

높은 점수가 수비수에게 의미하는 것과 의미하지 않는 것

보안 팀이 실제로 품는 질문은 "어느 모델이 순위표 맨 위에 오르는가"가 아니라 "이 평가에서 좋은 점수를 받은 에이전트가 내 위험에 어떤 영향을 미치는가"입니다. 벤치마크는 제기된 질문보다 더 좁은 질문에 답하며, 그 간극은 이름 붙일 가치가 있습니다.

그것은 다음을 의미합니다 에이전트가 90분 이내에, 알려진 빌드 안에서 실제 오픈 소스 코드의 메모리 안전성 버그를 찾아내고, 작동하는 크래시 입력을 생성하며, 테스트를 깨뜨리지 않고 크래시를 멈추는 변경 사항을 작성할 수 있다는 것을. 그것은 진정한 역량이고, 트리아지와 패치 작업에 직접적으로 관련되며, 유능한 에이전트가 분석가의 대기열을 의미 있게 압축하는 종류의 작업입니다.

그것은 다음을 의미하지 않습니다: 에이전트가 귀하의 코드베이스, 위협 모델 또는 배포 환경을 이해한다는 것. 작업은 정답이 알려진 취약점과 에이전트에게 완료 여부를 알려주는 테스트 스위트가 있는 공개 OSS-Fuzz 대상에서 출제됩니다. 프로덕션 코드에는 그런 오라클이 없습니다. 또한 에이전트가 그 버그를 어떤 버그보다는 찾을 것이라는 뜻도 아닙니다: 4단계가 존재하는 이유는 그것들이 갈라지기 때문이며, 4단계는 집계되지 않습니다.

그리고 그것은 공격적 측면으로 전이되지 않는데, 바로 그곳에서는 동일한 능력이 다르게 해석된다. 메모리 안전 결함을 찾아내고 재현할 수 있는 에이전트는 테스트 권한이 주어지지 않은 코드에서도 그렇게 할 수 있으며, 이것이 바로 이러한 수준의 능력이 시스템 프롬프트의 면책 문구가 아니라 모델 수준의 접근 제어를 촉진하는 이유다.

CyberGym 수치를 신뢰하기 전에 무엇을 물어봐야 할까

잘 작성된 보고서에서는 답할 수 있지만, 출시 게시물에서는 보통 답할 수 없는 다섯 가지 질문.

• 어떤 구현입니까? RDI의 벤치마크인지, 아니면 제3자 평가자가 필터링한 변형인지. 보고서에 명시되지 않았다면 그 수치는 무엇과도 비교할 수 없습니다.

• 누가 실행했는가? 독립 평가인지 제공자 자체 보고인지. 취합 표는 각 행에 이를 표시하지만, 대부분의 마케팅 자료는 그렇지 않다.

• 어떤 하네스이며, 예산은 얼마입니까? 하네스가 공급업체 자체의 것이고 설명되지 않은 경우, 해당 결과를 특정 제품 구성에 대한 시스템 수준의 주장으로 간주하십시오.

• 4단계를 확인했습니까? 진단 정보와 함께 보고된 비율은 패치가 버그를 실제로 수정했는지, 아니면 단지 충돌을 잠재웠는지 알려줍니다.

• 어떤 과제 세트인가요? 난이도에 따라 선택된 프로젝트당 하나씩인 131개 과제가 일반적인 세트이며, 필터가 다르면 다른 테스트입니다.

Cybergym은 어렵고 실제적인 과제를 위한 잘 구성된 벤치마크이며, 그 구성 방식은 리더보드보다 더 흥미롭다. 단계들은 에이전트가 무엇을 해야 했는지 알려주고, 필터링은 그 점수가 무엇에 대한 점수인지 알려주며, 하네스는 누구에게 공을 돌려야 하는지 알려준다. 그 세 가지가 함께 딸린 숫자는 진정으로 유용하다. 홀로 등장하는 숫자는 퍼센트 기호가 붙은 보도자료일 뿐이다.