코딩 벤치마크가 뭐야

AI 모델의 프로그래밍 능력을 재기 위해 만든 표준 시험이다. 실제 오픈소스 저장소의 이슈를 가져와 고치게 하거나, 터미널에서 여러 단계 작업을 시키거나, 보안 취약점을 찾게 하는 식으로 과제를 주고 성공률을 백분율로 매긴다. 대표적인 것이 SWE-bench 계열, Terminal-Bench, CyberGym 같은 것들이다.

왜 같은 모델인데 점수가 이렇게 달라

재는 대상이 다르기 때문이다. 실제 사례로 GLM-5.3은 CyberGym에서 84.5%, Terminal-Bench 3.0에서 28.3%를 받았다. 세 배 차이지만 모순이 아니다. 하나는 보안 과제 성공률이고 다른 하나는 터미널 다단계 작업 성공률이다. 과제 난이도와 채점 기준이 애초에 다른 시험이다.

벤치마크 점수 믿어도 돼

발표 주체를 먼저 확인해야 한다. 모델 공개 시 함께 나오는 점수는 대부분 개발사가 직접 측정해 발표한 값이다. 시도 횟수, 사용한 도구, 프롬프트 구성에 따라 같은 모델도 점수가 크게 달라지므로, 제3자가 동일 조건에서 재현한 결과가 나올 때까지는 '주장'으로 읽는 것이 안전하다.

코딩 벤치마크란 — 같은 모델이 28%와 84%를 동시에 받는 이유

코딩 벤치마크는 AI 모델이 소프트웨어 작업을 얼마나 해내는지 정해진 문제 집합으로 채점한 점수다. 같은 모델이 벤치마크마다 28%와 84%처럼 크게 다른 점수를 받는 일이 흔한데, 이는 벤치마크마다 재는 대상과 채점 규칙이 다르고 대부분의 점수가 개발사 자체 발표치이기 때문이다

새 AI 모델이 나오면 표가 하나 따라온다. 벤치마크 점수표다.

그런데 그 표를 자세히 보면 이상한 일이 벌어진다. 같은 모델이 한 줄에서는 84.5%를, 다른 줄에서는 28.3%를 받는다. 세 배 차이다.

둘 다 사실이다. 왜 그런지 정리한다.

1. 코딩 벤치마크가 하는 일

원리는 학교 시험과 같다.

미리 정한 문제 집합을 준비한다
모델에게 풀게 한다
정답 여부를 자동으로 판정한다
성공률을 백분율로 낸다

차이는 '정답 판정'에 있다. 코딩 벤치마크는 대부분 테스트 코드 실행으로 채점한다. 모델이 낸 수정안을 실제로 돌려서 테스트가 통과하면 성공이다. 사람이 코드 품질을 보고 점수를 주는 것이 아니다.

2. 계열별로 무엇이 다른가

계열	예시	재는 것	난이도 성격
실제 이슈 해결	SWE-bench, DeepSWE	오픈소스 저장소의 실제 버그·기능 요청 처리	코드베이스 이해가 필요
터미널 다단계	Terminal-Bench	명령줄에서 여러 단계 작업 완수	도구 사용·상태 관리가 필요
보안 공격/탐지	CyberGym, ExploitBench	취약점 탐지·실증 코드 작성	좁고 패턴화된 영역
자동화	AutomationBench	반복 작업 자동화	과제 정의가 비교적 명확

세 배 차이의 정체가 여기에 있다. 보안 계열은 문제 유형이 상대적으로 정형화돼 있어 높은 점수가 나오기 쉽고, 터미널 다단계 작업은 중간에 한 단계만 어긋나도 전체가 실패로 처리되므로 점수가 낮게 나온다.

3. 실제 사례로 보기 — GLM-5.3 (2026년 8월 14일 공개)

벤치마크	점수
CyberGym	84.5%
DeepSWE 1.1	66.9%
ExploitBench	54.4%
AutomationBench	48.2%
Terminal-Bench 3.0	28.3%

이 다섯 줄은 서로 모순되지 않는다. 다섯 개의 다른 시험을 본 것이다.

여기서 흔한 오독이 나온다. 홍보 자료가 84.5%를 앞세우고, 기사가 그 숫자만 옮기고, 독자가 '이 모델은 84% 잘한다'고 이해하는 흐름이다. 같은 표의 맨 아래에 28.3%가 있다는 사실은 사라진다.

4. 점수를 흔드는 네 가지 조건

같은 모델, 같은 벤치마크인데도 점수가 달라지는 경우가 있다. 조건이 다르기 때문이다.

조건	왜 중요한가
시도 횟수	한 번에 맞히는 것(pass@1)과 여러 번 시도해 한 번이라도 맞히는 것(pass@k)은 완전히 다른 숫자다
도구 사용	코드 실행, 파일 검색, 웹 접근을 허용했는지에 따라 성적이 크게 달라진다
스캐폴딩	모델을 감싸는 에이전트 프레임의 성능이 점수에 섞여 들어간다
버전	Terminal-Bench 3.0과 2.0은 다른 시험이다. 버전이 다르면 비교 불가

보도된 점수 두 개를 비교하기 전에 이 네 가지가 같은지부터 확인해야 한다. 하나라도 다르면 그 비교는 성립하지 않는다.

5. 가장 큰 구조적 문제 — 오염

벤치마크에는 근본적인 취약점이 하나 있다. 문제와 정답이 인터넷에 공개돼 있다는 것.

오픈소스 저장소의 이슈를 문제로 쓰는 벤치마크라면, 그 저장소의 코드와 해결 커밋이 이미 학습 데이터에 들어갔을 수 있다. 이 경우 모델은 문제를 '푸는' 것이 아니라 '기억하는' 것에 가까워진다.

이를 데이터 오염(contamination)이라 부른다. 대응책으로 나온 것들이 있다.

최신 이슈만 사용해 학습 시점 이후 데이터로 구성
비공개 문제 집합(holdout) 운영
문제를 변형해 암기 여부 확인

그러나 개별 모델의 오염 정도를 외부에서 검증하는 것은 대부분 불가능하다. 학습 데이터가 공개되지 않기 때문이다.

6. 벤치마크 점수를 읽는 체크리스트

새 모델의 점수표를 만났을 때 확인할 네 가지다.

#	질문	확인 못 하면
1	누가 측정했나 — 개발사인가 제3자인가	주장으로 읽는다
2	시도 횟수는 — pass@1인가 pass@k인가	다른 모델과 비교하지 않는다
3	도구·스캐폴딩은 무엇을 썼나	점수 차의 원인을 모델에 귀속하지 않는다
4	벤치마크 버전이 같은가	비교표를 만들지 않는다

모델 공개와 동시에 발표되는 점수는 거의 전부 1번이 '개발사'다. 이 지면이 GLM-5.3, 딥시크 V4-Pro, 제미나이 3.7 플래시를 다룰 때 매번 '개발사 발표치'라고 적는 이유다.

7. 자주 묻는 것

Q. SWE-bench 70%면 개발자 70% 대체하나? 아니다. SWE-bench는 잘 정의된 이슈를 코드로 고치는 성공률이다. 무엇을 만들지 정하는 일, 요구사항이 모호할 때 되묻는 일, 시스템 설계, 사람과의 조율은 재지 않는다.

Q. 점수가 높으면 실제로도 잘 쓰나? 상관은 있지만 비례하지는 않는다. 벤치마크 점수와 실무 성과의 관계를 정량적으로 확인한 공개 연구를 이 지면이 확인하지 못했다.

Q. 어떤 벤치마크를 봐야 하나? 자기 용도와 가까운 것을 본다. 기존 코드베이스를 고칠 일이 많으면 SWE-bench 계열, 명령줄 자동화가 많으면 Terminal-Bench 계열이다.

Q. 100%가 나오면 그 벤치마크는 끝인가? 사실상 그렇다. 점수가 포화되면 변별력이 사라져 더 어려운 후속 버전이 나온다. 벤치마크에 버전 번호가 붙는 이유다.

8. 남은 것 · 확인되지 않은 것

인용된 점수는 개발사 발표치다. 이 문서의 GLM-5.3 수치는 제3자 검증을 거친 값이 아니다.

오염 여부는 대부분 확인 불가다. 학습 데이터가 비공개인 한 외부에서 판정할 방법이 제한적이다.

실무 성과와의 상관관계를 확인하지 못했다. 벤치마크 점수가 실제 개발 생산성으로 얼마나 이어지는지 정량화한 공개 연구를 이 지면이 확인하지 못했다.

AI 모델 평가 관련 이전 기사는 「프론티어 모델이란」과 「GLM-5.3 공개」에 있다.