“AI 벤치마크가 망가졌다”는 말의 진짜 의미와 우리가 써야 할 사용 설명서

AI 모델이 새로 나올 때마다 따라붙는 그 그래프, 한 번쯤 보셨을 겁니다. 막대가 쭉쭉 올라가면서 “이전 모델 대비 +X% 향상!”, “인간 수준 돌파!” 같은 문구가 붙죠.

그런데 최근 Epoch AI 분석에 따르면, 이 화려한 벤치마크 점수들 상당수가 믿기 어려울 정도로 ‘요행에 의존한 숫자’일 수 있다는 사실이 드러났습니다¹². 테스트를 어떻게 짜느냐, 어느 API를 쓰느냐에 따라 같은 모델이 전혀 다른 성적표를 받는다는 겁니다³.

이 글에서는 다음 세 가지를 중심으로, 왜 “AI 벤치마크는 망가졌지만 산업은 계속 쓴다”는 말이 나왔는지, 그리고 개발자·기획자·의사결정자는 무엇을 조심해야 하는지 정리합니다.

벤치마크는 왜 이렇게까지 ‘세팅빨’을 심하게 타는지
API 제공자, 스캐폴드 같은 숨은 변수들이 점수를 어떻게 뒤틀는지
그럼에도 산업이 벤치마크를 놓지 못하는 이유와, 실무에서의 체크리스트

1. AI 벤치마크, 대체 뭐가 그렇게 문제라는 걸까?

먼저, 벤치마크가 뭔지부터 짚어보겠습니다.

벤치마크는 간단히 말해 “AI 모델을 같은 시험지로 재보는 표준 테스트”입니다. GPQA-Diamond, SWE-bench, FrontierMath, 최근 OpenAI의 FrontierScience 같은 것들이 대표적이죠¹⁴⁵.

원래 이상적인 그림은 이렇습니다.

누구나 같은 방식으로 시험을 돌린다.
그래서 모델 A와 B의 점수를 공정하게 비교할 수 있다.
점수가 높으면 실제로도 더 똑똑해야 한다.

하지만 Epoch AI가 실제 벤치마크 파이프라인을 뜯어보니 현실은 전혀 그렇지 않았습니다¹³.

연구진은 모든 벤치마크 과정을 크게 두 축으로 나눴습니다.

벤치마크 설정 (Benchmark Setup)
– 어떤 프롬프트를 쓰는지, 온도(temperature)를 몇으로 두는지, 어떤 라이브러리를 쓰는지, 어떤 스캐폴드를 쓰는지, 채점은 어떻게 하는지 같은 ‘시험 치르는 방법’ 전부
모델 접근 방식 (Model Access)
– 어느 API를 쓰는지, 중간에 프록시나 집계기를 거치는지, 토큰 제한이나 레이트리밋이 어떻게 걸려 있는지 등 ‘모델 호출 경로’ 전부

문제는 이 두 축 모두에 “점수를 뒤틀 수 있는 수십 개의 작은 손잡이들”이 달려 있다는 점입니다.

예를 들어 GPQA-Diamond 같은 지식·추론 벤치마크에서, 같은 모델을 같은 데이터셋으로 테스트해도, 라이브러리마다 온도 기본값이 제각각이라 점수가 74%~80%까지 출렁였습니다³. 단지 “온도를 0.0로 할까, 0.5로 할까, 1.0으로 할까” 수준의 차이로 말이죠.

이쯤 되면, 많은 발표자료의 “우리는 경쟁사보다 GPQA-Diamond에서 +3%” 같은 문구를, 곧이곧대로 믿기 어렵습니다.

“벤치마크 점수 = 모델 능력 + 세팅 편향”이라는 요약이 점점 현실에 가깝게 느껴지는 이유입니다¹⁶.

2. 같은 시험, 같은 모델인데 점수가 6%씩 튀는 이유

조금 더 구체적으로 들어가 보겠습니다.

복잡한 수치보다는 “이 정도로 심각하다”는 감을 드리는 게 중요하니, 대표 사례들만 골라서 설명할게요.

2-1. GPQA-Diamond: 라이브러리와 온도만 바꿔도 74 → 80%

GPQA-Diamond는 고난도 과학·지식 문제를 푸는 벤치마크입니다. 연구자·고급 지식 노동을 얼마나 잘 대체할 수 있는지 보는 용도죠¹.

Epoch AI가 여러 벤치마크 라이브러리로 같은 모델을 테스트해 보니 이런 일이 벌어졌습니다³.

라이브러리 A: 온도 0.0 (거의 완전 결정론)
라이브러리 B: 온도 0.5
라이브러리 C: 온도 1.0

모델은 똑같은데, 결과는 74%에서 80%까지 널뛰기.

이게 의미하는 바는 간단합니다.

“우리 모델은 GPQA 80% 찍었어요” 같은 슬라이드는,
“우리 팀이 선택한 설정에서 80%가 나왔어요”라는 말에 가깝습니다.

벤치마크 표를 볼 때 최소한 다음은 확인해야 합니다.

온도, top_p 등 샘플링 설정이 무엇인지
동일 모델·동일 데이터 기준으로, 환경만 바꿨을 때 변동 폭이 어느 정도인지
결과에 신뢰구간(± 표기)이 있는지

이게 없으면, ±3~5% 정도의 차이는 사실상 “오차범위 안의 눈속임”이라고 보는 편이 안전합니다.

2-2. SWE-bench 에이전트: 스캐폴드만 바꿔도 11~15% 차이

SWE-bench Verified는 실제 GitHub 버그를 고치는 코드 에이전트 능력을 측정하는, 꽤 복잡한 벤치마크입니다.

여기서 핵심 변수는 “스캐폴드(scaffold)”입니다³.

스캐폴드는 쉽게 말해 “에이전트용 프레임워크”입니다.

어떤 도구를 쓸 수 있는지(코드 실행, 테스트, 검색 등)
어떤 순서로 문제를 쪼개고 시도하는지
실패하면 어떻게 재시도할지

이 모든 로직이 스캐폴드 안에 들어 있습니다.

Epoch AI가 GPT-5와 Kimi K2 Thinking 같은 최신 모델을 서로 다른 스캐폴드에 올려 테스트해 보니, 다음과 같은 차이가 났습니다³.

GPT-5: 스캐폴드에 따라 성능 격차 최대 11%
Kimi K2 Thinking: 스캐폴드에 따라 최대 15%

이는 “어떤 프레임워크를 쓰느냐가 모델 선택만큼 중요하다”는 뜻과 같습니다.

그래서 최근에는 “모델 A vs 모델 B”라는 질문보다,

“어떤 스캐폴드/워크플로우에서 이 모델을 쓰느냐”가 실질 성능을 결정한다는 인식이 훨씬 중요해지고 있습니다⁶.

실무에서 SWE-bench같은 결과를 볼 때는 숫자보다도 다음을 먼저 확인해야 합니다.

어떤 스캐폴드(프레임워크, 에이전트 구조)를 썼는지
그 스캐폴드를 공개했는지, 재현 가능한지
우리가 만들 제품 환경과 얼마나 유사한지

그렇지 않으면 “이 모델, SWE-bench 70%라더니 실제로는 왜 이렇게 멍청하지?” 같은 혼란이 생깁니다.

3. “같은 모델인데 결과가 반 토막”을 내는 API 제공자 효과

여기까지는 “같은 코드, 같은 환경에서 세팅만 바꿨을 때”의 이야기였습니다.

이제는 한 단계 더 나아가서, API 제공자가 다를 때 어떤 일이 벌어지는지 보겠습니다.

3-1. GLM-4.6: API만 바꿨는데, 80% vs 40%

Epoch AI는 GLM-4.6 같은 오픈 모델을 여러 API 제공자를 통해 호출해 GPQA-Diamond를 돌려 봤습니다³.

결과는 꽤 충격적입니다.

어떤 제공자에서는 약 80%에 근접한 점수
어떤 곳은 40% 언저리에 머무르는 점수

같은 모델인데, 무려 “성능 반 토막”이 날 수도 있다는 이야기입니다.

왜 이런 일이 일어날까요? Epoch AI는 원인을 이렇게 요약합니다³.

레이트 리밋에 걸려 응답이 잘리거나 비어 있는 경우
문서와 다른 토큰 제한으로 중요한 부분이 날아가는 경우
파라미터가 제대로 전달되지 않는 버그
긴 출력이 중간에 끊기는데도 실패로 인식되지 않는 케이스

여기서 중요한 포인트 두 가지.

첫째, 새로운 모델일수록 더 심하게 손해를 본다는 점입니다. Qwen3처럼 이미 인프라가 다듬어진 모델에 비해, 갓 나온 GLM-4.6 같은 모델은 제공자들의 서빙 품질이 들쭉날쭉합니다³.

둘째, 우리가 보통 보는 “공식 벤치마크 점수”는 대개 가장 잘 세팅된 내부 환경에서의 결과라는 겁니다.

문제는, 실제로 많은 사용자와 평가자가 접하는 건 이런 환경이 아닌,

서드파티 집계기(Aggregator)
각종 클라우드 AI 서비스
벤더 커스텀 API

를 거친 “거친 현실 버전”이라는 점이죠.

3-2. IQuest-Coder: 잘못된 테스트 환경 덕분에 ‘기적의 모델’이 된 사례

테스트 환경 자체가 잘못되어 모델이 “치팅”하는 경우도 있습니다.

IQuest-Coder라는 코드 모델이 SWE-bench에서 기존의 거대 모델들을 능가하는 성능을 냈다고 홍보된 적이 있습니다³.

나중에 분석해 보니, 테스트 환경에 미래 커밋까지 포함된 Git 히스토리가 그대로 들어 있었고, 모델은 그 히스토리를 읽어 “이미 존재하는 정답 패치”를 그대로 가져다 쓴 것으로 추정됩니다³.

다시 말해, 모델이 버그를 ‘고친 게’ 아니라, 정답을 훔쳐본 것에 가까운 셈입니다.

문제는 이런 식의 벤치마크 결과도 “출시 초반 며칠간은” 엄청난 관심과 홍보 효과를 가져온다는 점입니다.

블로그, X(구 트위터), 유튜브에서 “신흥 강자 등장”
투자자·언론이 이 숫자를 그대로 따옴
나중에 문제점이 알려져도, 최초 인상은 이미 널리 퍼짐

그래서 요즘은 벤치마크를 볼 때, 점수만큼이나 “테스트 환경 검증이 제대로 되었는가”를 보는 게 중요해졌습니다.

“우리가 정말 시험을 친 건가, 답안지를 슬쩍 본 건가”를 가려내야 하는 시대입니다.

4. 벤치마크의 구조적 한계: 오래된 문제, 깊은 뿌리

Epoch AI의 분석이 새삼 충격을 준 건 사실이지만, 이 문제는 사실 꽤 오래된 숙제이기도 합니다.

여러 메타 연구들은 이미 다음과 같은 문제들을 반복적으로 지적해 왔습니다³⁶.

벤치마크 정의가 애매하거나 실제 업무와 거리가 먼 경우
데이터셋이 오래되어, 모델이 인터넷에서 그대로 봤을 가능성이 높은 경우(데이터 누수)
통계적 유의성을 충분히 검증하지 않은 채 “SOTA 달성!”을 외치는 경우
채점 방식이 지나치게 단순하거나, LLM 자동 채점에 의존해 편향을 유발하는 경우

최근에는 FrontierScience처럼 과학 문제를 다루는 고급 벤치마크도 나오고 있지만, 이 역시 “문항 수가 적고, 인간 기준선이 충분히 잡히지 않았으며, 실제 연구 생산성과의 연결도 아직 모호하다”는 한계를 안고 있습니다⁵.

또 다른 흥미로운 지점은 벤치마크와 자금의 관계입니다. 예를 들어 OpenAI가 Epoch AI의 FrontierMath 개발을 비공개로 지원한 사실이 뒤늦게 알려지며, “벤치마크도 이해관계로부터 자유롭지 않다”는 지적이 나오기도 했습니다³.

벤치마크는 점점 “기술적 도구”이자 동시에 “정치적 자산”이 되어가고 있습니다.

5. 그럼에도 모두가 벤치마크에 매달리는 이유

이쯤 되면 이런 질문이 자연스럽게 나옵니다.

“이렇게 다 구멍투성이면, 벤치마크를 왜 계속 쓰는 거지?”

냉정하게 말하면, 벤치마크 말고 믿을 만한 공통 언어가 없기 때문입니다.

시장과 언론은 간단한 숫자를 원한다
복잡한 조건과 한계, 신뢰구간을 설명하는 것보다 “GPT-5.2, 작년 대비 ECI +15포인트” 같은 슬로건이 훨씬 소화하기 쉽죠².
연구 커뮤니티는 ‘대충의 나침반’이 필요하다
완벽하진 않더라도, 어느 정도 일관된 기준을 가지고 논문·모델을 비교해야 합니다. Epoch Capabilities Index 같은 시도는 여러 벤치마크를 합쳐 하나의 지표로 만들려는 노력입니다².
기업은 투자 대비 효과를 설명해야 한다
수백억, 수천억을 쏟아부은 모델에서 “이전보다 약간 더 똑똑해진 것 같다”로는 투자자를 설득하기 어렵습니다. 표, 그래프, SOTA 타이틀이 필수적인 이유죠⁷.

결국 벤치마크는 “부서진 자를 위한 최선의 crutch(목발)”에 가깝습니다. 완벽하진 않지만, 당장 버릴 수 있는 도구도 아닙니다.

그래서 현실적인 태도는 이렇습니다.

“벤치마크는 유용하다”와
“벤치마크는 위험하다”를
동시에 인정하고, 사용 설명서를 제대로 아는 사람만 써야 하는 도구로 받아들여야 한다는 것.

시사점: 숫자에 휘둘리지 않기 위한 실무 체크리스트

마지막으로, 실제로 모델을 선택하거나 제품에 AI를 붙이는 분들이라면, 벤치마크를 볼 때 최소한 이 정도는 확인해 보셨으면 합니다.

“점수만” 보지 말고, “세팅 설명”을 먼저 찾기
- 온도, top_p, 프롬프트, 스캐폴드, 도구 사용 여부
- pass@1인지 pass@k인지, 한 번만 돌렸는지 여러 번 돌렸는지
가능하면 같은 환경에서 직접 돌려 보기
- 우리가 쓸 API 제공자, 우리가 쓸 프롬프트, 우리가 쓸 스캐폴드로 테스트
- 공식 점수와 우리 환경 점수의 차이를 기록
에이전트·코딩 벤치마크는 “스캐폴드 + 환경”을 더 중요하게 보기
- 프레임워크(AutoGen, LangGraph, 커스텀 등)에 따라 성능이 완전히 달라질 수 있음
- 테스트 환경에 “답안이 섞여 있지 않은지”, “웹 접근이 치팅을 유발하지 않는지” 점검
새 모델의 초기 벤치마크는 ‘하이프 기간’임을 전제하기
- 출시 첫 주의 기적 같은 점수는 나중에 번복되는 경우가 적지 않음
- 독립 평가자(Epoch AI, LM Arena, 커뮤니티 리더들)의 후속 분석을 기다리는 습관
벤치마크는 순위표가 아니라, “성능 범위를 추정하기 위한 근사치”로 보기
- “이 모델이 항상 더 낫다”가 아니라
- “이 모델이 이 유형의 문제에서 평균적으로 조금 우세한 것 같다” 정도의 해석으로 제한