72.4%는 무엇의 점수인가 — LLM 벤치마크를 읽는 법#

2026-10-18

작은 로봇 하나가 높은 나무 자, 저울, 바늘 계기판, 유리 돔 속 시험지 묶음처럼 서로 다른 측정 도구 네 개 앞에 서 있고, 도구마다 다른 색으로 빛나는 모습

내가 옮겨 적은 숫자#

지난주 2026-10-11 AI 뉴스 브리프에서 필자는 Claude Haiku 5.5를 소개하며 이렇게 적었습니다. “컴퓨터를 직접 조작하는 능력을 재는 OSWorld 2.1(오프라인 부분집합)에서 72.4%로 Haiku 4.5의 15.7%를 크게 넘었고”, “터미널 작업 평가 Terminal-Bench 4.0에서는 39.2%”. 그런데 브리프를 다시 읽다가 필자가 이 두 벤치마크를 제대로 공부한 적이 없다는 사실을 깨달았습니다. 숫자를 옮겨 적었을 뿐, 그 숫자가 무엇을 쟀는지는 몰랐습니다.

확인해 보니 72.4%는 “과제의 72.4%를 해냈다"는 뜻이 아니었습니다. Anthropic 발표 페이지의 OSWorld 차트 세로축에는 부분 점수(partial-credit score) 라고 적혀 있습니다. 과제를 끝까지 못 해도 진척한 만큼 점수를 주는 방식입니다. 시스템 카드를 인용한 2차 자료에 따르면, 같은 실행에서 과제를 끝까지 완수한 비율인 엄격 통과율은 37.1%입니다. 노력(effort) 설정을 가장 낮은 Low로 두면 같은 부분 점수가 42.0%로 내려간다는 차트 판독도 있습니다. 모델은 하나인데, 무엇을 어떤 조건에서 재느냐에 따라 숫자는 37%에서 72%까지 오갑니다.

이 글은 그 숫자를 이해하려고 LLM(Large Language Model, 대규모 언어 모델) 평가 전반을 조사한 기록입니다. 결론부터 적으면 이렇습니다. 벤치마크 숫자는 모델 하나의 점수가 아니라 과제, 채점, 실행 조건이 합쳐진 점수입니다. 그래서 공개 벤치마크는 후보를 고르는 데 쓰고, 최종 판단은 내 일로 만든 평가로 해야 한다는 것이 지금 필자의 생각입니다.

벤치마크를 이루는 세 가지#

모든 벤치마크는 “무엇을 시키고(과제), 누가 판정하며(채점), 어떤 조건에서 돌렸는가(실행 조건)“로 이루어집니다.

과제는 객관식 지식 문제일 수도, 실제 코드 저장소의 버그 수정일 수도, 가상 머신 안의 데스크톱 작업일 수도 있습니다.

채점 방식은 크게 네 가지입니다.

정답 일치: 객관식이나 수치 답을 맞춰 봅니다. 싸고 객관적이지만 쉬운 과제에만 쓸 수 있습니다.
실행 검증: 결과물에 테스트를 돌립니다. 코딩 벤치마크 대부분이 이 방식입니다.
상태 검사: 작업이 끝난 뒤 파일, 앱, 설정의 상태를 스크립트로 확인합니다. 컴퓨터 사용 벤치마크가 주로 씁니다.
사람 또는 LLM의 판정: 루브릭(채점 기준표)에 따라 LLM이 채점하거나, 사람이 두 답변 중 나은 쪽을 고릅니다. 주관적인 품질을 잴 수 있지만 채점자의 편향이 섞입니다.

지표도 여러 가지입니다. 같은 실행 결과라도 어떤 지표로 요약하느냐에 따라 숫자가 크게 달라집니다.

지표	의미
pass@1	한 번 시도해 성공한 비율. 여러 번 돌려 평균을 내는 경우가 많음
pass@k	k번 시도 중 한 번이라도 성공한 비율. 숫자가 후하게 나옴
pass^k	k번 모두 성공한 비율. 실무 신뢰도에 가까움
부분 점수 / 엄격 통과	일부 진척에 점수를 주느냐의 차이. 두 배 가까이 벌어지기도 함

실행 조건은 가장 눈에 띄지 않지만 숫자를 가장 크게 바꿉니다. 에이전트를 어떤 하네스(harness, 모델에 도구와 작업 루프를 붙여 주는 실행 틀)로 돌렸는지, 노력 설정은 무엇이었는지, 시간과 토큰 한도는 얼마였는지, 인터넷을 허용했는지, 전체 과제를 돌렸는지 부분집합만 돌렸는지, 그리고 누가 측정했는지가 모두 여기에 들어갑니다. 서두의 72.4%는 Anthropic이 직접, 최대 노력 설정에서, 오프라인 부분집합으로 잰 부분 점수입니다.

SWE-bench — 실제 이슈를 되감아 만든 시험지#

벤치마크 하나를 깊게 들여다보면 나머지가 쉽게 읽힙니다. 지금의 코딩 에이전트 벤치마크 대부분은 SWE-bench의 방식을 이어받았기 때문에, 이 벤치마크를 기준점으로 삼았습니다.

SWE는 Software Engineering(소프트웨어 엔지니어링)의 약자입니다. 미국 테크 업계에서 소프트웨어 엔지니어 직군을 “SWE"라고 줄여 부르는 관행에서 왔습니다. 2023년 10월 Princeton 대학 연구진이 공개한 원 논문의 제목이 컨셉을 그대로 말해 줍니다. “언어 모델이 실제 GitHub 이슈를 해결할 수 있는가?(Can Language Models Resolve Real-World GitHub Issues?)”

비유하자면 신입 개발자에게 실제 오픈소스 프로젝트의 버그 티켓을 하나 주고, 신입이 코드베이스를 읽고 고쳐서 낸 수정안을, 신입에게는 보여 주지 않은 테스트로 채점하는 것입니다.

핵심 아이디어는 문제를 새로 만들지 않고 이미 해결된 과거 이슈를 되감아 쓰는 것입니다. 연구진은 django, scikit-learn, sympy, matplotlib 같은 유명 Python 저장소 12곳에서 “이슈가 있고, 그 이슈를 해결한 PR이 머지됐고, 그 PR에 테스트도 함께 추가된” 사례 2,294개를 모았습니다. 과제 하나는 이렇게 구성됩니다.

모델에게 주는 것: 이슈 본문과, 해결 PR이 머지되기 직전 시점으로 되돌린 저장소 전체 코드
모델이 내는 것: 코드 수정 패치
채점자만 가진 것: 실제 PR에 추가됐던 테스트(수정 전에는 실패하고 제대로 고치면 통과해야 함)와, 원래부터 통과하던 기존 테스트(고친 뒤에도 계속 통과해야 함)

두 테스트 묶음이 모두 통과해야 “해결"로 인정합니다. 함수 하나를 작성하는 퍼즐형 코딩 문제와 달리, 수십만 줄짜리 저장소에서 원인을 찾고, 사람이 쓴 모호한 이슈 문장을 해석하고, 여러 파일에 걸쳐 고치면서 기존 기능을 깨지 않아야 합니다. 공개 당시 최고 모델이던 Claude 2의 해결률은 2%가 안 됐습니다. “코딩 문제는 잘 풀지만 실무는 거의 못 한다"는 사실을 처음 숫자로 보여 준 벤치마크였습니다.

SWE-bench에서 뻗어 나간 계보#

SWE-bench 이후의 코딩 벤치마크는 대부분 “앞 세대의 무엇이 문제였는가"에 대한 답으로 나왔습니다. 계보를 따라가면 평가가 무엇을 고민해 왔는지가 보입니다.

시기	이름	앞 세대에서 고친 점
2023	SWE-bench	출발점. 실제 이슈와 숨겨 둔 테스트
2024	SWE-bench Lite	300개로 줄여 평가 비용을 낮춤
2024	SWE-agent	벤치마크가 아닌 에이전트. 하네스 설계만으로 점수가 크게 오른다는 것을 보임
2024	SWE-bench Verified	사람 개발자가 검수해 풀 수 있고 채점이 공정한 500개만 남김
2024–2025	Multimodal / Multilingual	화면 이미지가 있는 JavaScript 과제, Python 외 언어로 확장
2025	SWE-Lancer	프리랜서 플랫폼의 실제 의뢰와 보수로 경제적 가치를 측정
2025	SWE-bench Pro	41개 저장소, 1,865개 과제. 오염을 줄이고 난이도를 올림
2026	FrontierCode	테스트 통과가 아니라 “메인테이너가 머지할 코드인가"를 채점
2026	DeepSWE	새로 작성한 장기 과제로 학습 데이터 오염을 원천 차단
2026	CursorBench	제품 하네스 안에서 측정하는 회사 자체 벤치마크

이 표에서 필자가 눈여겨본 흐름은 세 가지입니다.

첫째, 문제의 품질을 다듬는 흐름입니다. Verified는 “점수가 낮은 이유가 모델이 못해서인지, 문제가 이상해서인지” 가리려고 만들어졌습니다. OpenAI가 원저자들과 함께 사람 개발자에게 과제를 하나하나 검수하게 해, 이슈 설명이 부족하거나 테스트가 불공정한 과제를 걸러 냈습니다.

둘째, 오염을 피하는 흐름입니다. 문제와 정답이 모두 공개 저장소에 있으니 모델이 학습 중에 정답을 봤을 수 있습니다. Pro는 상용 저장소와 라이선스 제약이 있는 저장소를 섞었고, DeepSWE는 아예 과제를 새로 썼습니다.

셋째, “통과"의 기준을 올리는 흐름입니다. 테스트를 통과해도 리뷰에서 반려될 코드는 많습니다. FrontierCode는 오픈소스 메인테이너가 직접 과제와 채점 기준을 만들고, 리뷰에서 바로 거절할 결함이 하나라도 있으면 0점을 줍니다.

이 계보는 코드 밖으로도 이어졌습니다. “실제 일을 시키고, 결과를 실행해서 검증한다"는 SWE-bench의 컨셉은 터미널 작업 전반으로 넓힌 Terminal-Bench, 데스크톱 조작으로 넓힌 OSWorld, 여러 SaaS를 가로지르는 업무 흐름으로 넓힌 AutomationBench로 퍼졌습니다. 서두의 두 벤치마크도 결국 이 계보의 먼 후손입니다.

포화 — 시험지가 천장에 닿을 때#

벤치마크가 계속 새로 나오는 가장 큰 이유는 포화입니다. 포화는 “점수가 높다"가 아니라 “이 시험으로는 더 이상 모델 사이의 차이를 잴 수 없다"는 판정입니다. 수능에서 만점자가 쏟아진 해에 변별력이 없다고 말하는 것과 같습니다.

MMLU가 대표적인 예입니다. 57개 과목의 4지선다 문제 약 1만 4천 개로 이루어진 지식 시험으로, 점수는 맞힌 문항의 비율입니다. 무작위로 찍으면 25%, 원 논문이 추정한 분야 전문가 수준은 약 89.8%입니다. 지금 상위 모델들은 대체로 90% 안팎에 몰려 있다고 보고됩니다. 그런데 이 시험은 정답 라벨이 틀린 문항이 일부 섞여 있어 실질적인 천장이 100%보다 낮습니다. 천장 근처에서는 0.몇 %p 차이가 프롬프트 형식이나 실행할 때마다의 흔들림에 묻힙니다. 2026년 ICML에서 발표된 한 연구는 자주 인용되는 벤치마크 60개 중 절반 가까이가 이미 포화됐다고 보고했습니다.

포화에는 오염 의심이 따라붙습니다. SWE-bench Verified가 그 사례입니다. OpenAI는 2026년 2월 Verified 점수를 더 이상 보고하지 않겠다고 밝혔습니다. 자체 감사에서 풀리지 않던 과제들을 다시 검토해 보니 상당수가 테스트가 지나치게 좁거나 넓어 사실상 풀 수 없는 문제였고, 여러 프런티어 모델이 과제 ID만 보고도 원래의 정답 패치나 이슈 문장을 그대로 재현했다는 것입니다. OpenAI 평가팀은 이 벤치마크가 “사실상 포화됐고 심하게 오염됐다"고 표현하며 SWE-bench Pro를 대안으로 지목했습니다.

포화는 측정 대상을 위로 밀어 올립니다. 지식(MMLU)에서 어려운 추론(GPQA, Humanity’s Last Exam)으로, 함수 단위 코딩(HumanEval)에서 저장소 단위 코딩(SWE-bench)으로, 그리고 지금은 에이전트가 실제 업무를 끝까지 해내는가로 옮겨 왔습니다. 측정 대상이 에이전트 작업이 되면서 점수의 주어도 바뀌었습니다. 모델 혼자가 아니라 “모델과 하네스의 조합"이 시험을 보게 된 것입니다. SWE-agent가 2024년에 보여 준 것도 바로 이 점이었습니다.

지금 자주 보이는 벤치마크들#

2026년 9–10월에 나온 Claude Opus 5.5, Haiku 5.5, GPT-6 Sol / Luna의 발표 자료와 독립 평가 기관의 지수에 반복해서 등장한 것들을 영역별로 골랐습니다.

코딩 에이전트

Terminal-Bench 4.0 (Stanford, Laude Institute): 서비스 배포, 수학 정리 증명, GPU 커널 작업처럼 터미널에서 끝까지 해내야 하는 장기 과제 66개
SWE-bench Pro (Scale AI): Verified의 후속. 더 어렵고 오염이 덜한 저장소 이슈
DeepSWE (Datacurve): 5개 언어, 91개 저장소에서 새로 작성한 장기 과제 113개
FrontierCode (Cognition): 메인테이너가 만든 루브릭으로 머지 가능성을 채점. 과제는 비공개
CursorBench (Cursor): Cursor의 실제 에이전트 하네스 안에서 측정

컴퓨터 사용

OSWorld 2.x (HKU xlang): 사람 기준 중앙값 1.6시간짜리 데스크톱 장기 과제 108개. 2.1에서 인터넷 없이 돌리는 오프라인 부분집합이 추가됨

업무 자동화와 전문 업무

GDPval / GDPval-AA (OpenAI / Artificial Analysis): 44개 직업의 실제 산출물을 전문가 수준과 비교. AA 버전은 여러 LLM 심판의 블라인드 비교로 Elo 점수를 매김
AutomationBench (Zapier): 가상 SaaS 47종을 오가는 업무 흐름 600개. 최종 상태로 채점
Agents’ Last Exam (UC Berkeley RDI, Snorkel AI): 직업 분류 체계에 따른 전문 업무를 전체 OS 샌드박스에서 수행

추론과 지식

Humanity’s Last Exam (CAIS, Scale AI): 각 분야 전문가가 출제한 최고난도 문제 모음
ARC-AGI 시리즈 (ARC Prize Foundation): 처음 보는 퍼즐 규칙을 일반화하는 능력

종합 지수와 독립 측정

Artificial Analysis Intelligence Index, Vals Index: 여러 벤치마크를 같은 조건으로 다시 돌려 하나의 지수로 묶음
METR time horizon: 사람 기준으로 몇 시간짜리 일까지 해내는지를 추적
LMArena: 사람의 선호 투표로 매기는 Elo 점수

한 가지 새로운 흐름도 보입니다. GPT-6 발표에는 사실 오류율과 함께, 에이전트가 자기 코드가 하는 일을 사실과 다르게 설명하는 비율인 코딩 기만율이 실렸습니다. “얼마나 잘하나"에 더해 “얼마나 믿을 수 있나"를 재기 시작한 것입니다.

채점기도 틀린다#

실행 검증과 상태 검사는 객관적으로 보이지만 채점기 역시 사람이 만든 코드입니다. 서두의 Terminal-Bench 4.0이 좋은 예입니다.

벤치마크 품질을 감사하는 Epoch AI는 Terminal-Bench 4.0의 66개 과제 중 30개(45.5%)에서 공개적으로 지적된 채점 결함을 확인하고 이 벤치마크를 “Flawed"로 분류했습니다. 결함은 세 종류였습니다. 오답을 통과시키는 결함의 예로, 한 과제는 테스트가 돌기 전에 검증기의 성공 신호를 직접 써 넣으면 60개 테스트가 모두 통과했습니다. 정답이 새는 결함으로는 채점 키가 저장소 안에 들어 있거나 입력 파일명에 랜덤 시드가 들어 있는 경우가 있었습니다. 반대로 문제에 적혀 있지 않은 요구사항으로 채점해 정답을 떨어뜨리는 결함도 11개 과제에서 나왔습니다.

SWE-bench에도 비슷한 구멍이 있었습니다. 일부 에이전트가 git log --all 같은 명령으로 저장소에 남아 있던 “미래의 커밋”, 즉 정답 PR을 찾아낸 사례가 보고됐고, 이후 평가 환경에서 미래 커밋을 지우는 방향으로 대응이 이어졌습니다. 에이전트는 시험을 푸는 대신 시험지의 허점을 찾을 만큼 유능해졌고, 그만큼 채점 환경도 정교해져야 합니다.

측정 주체에 따라 숫자가 달라지는 문제도 있습니다. Haiku 5.5의 Terminal-Bench 4.0 39.2%는 Anthropic이 Claude Code 하네스로 최대 노력 설정에서 잰 값이고, Artificial Analysis가 따로 측정한 값은 32.8%였다고 합니다. 어느 쪽이 틀린 것이 아니라 조건이 다른 것입니다. OSWorld도 마찬가지입니다. OSWorld 2.0 논문이 발표 당시 최고 성능으로 보고한 Claude Opus 4.8의 결과는 완수율 20.6%, 부분 점수 54.8%였습니다. 같은 벤치마크라도 어느 지표를 제목에 올리느냐에 따라 인상이 완전히 달라집니다.

누가 시험지를 만들고, 누가 고르는가#

조사하면서 궁금했던 것 중 하나는 이 생태계가 어떻게 생겨났느냐였습니다. 결론적으로 AI 제공사가 일방적으로 주도한 것도, 완전히 자생한 것도 아닙니다. 만드는 주체는 다양하고, 살아남는 것은 선택받은 것인 시장에 가깝습니다.

초기에는 학계가 주도했습니다. MMLU는 UC Berkeley, SWE-bench는 Princeton, OSWorld는 홍콩대(HKU)에서 나왔습니다. AI 연구소도 직접 만들었습니다. HumanEval, SWE-bench Verified, GDPval은 OpenAI가 만들었습니다. 이후 ARC Prize, Epoch AI, METR 같은 비영리 기관이 합류했고, 최근에는 Scale AI, Snorkel, Datacurve 같은 데이터 업체와 Cursor, Cognition, Zapier 같은 제품 회사가 벤치마크를 내놓습니다. 영국 AI Security Institute처럼 평가 도구를 공개하는 정부 기관도 있습니다.

선택은 주로 두 관문에서 일어납니다. 하나는 AI 연구소의 모델 발표 표입니다. 여기에 실리면 사실상 표준이 되고, 실리지 않으면 잊힙니다. 다른 하나는 Artificial Analysis, Vals AI, Epoch AI 같은 독립 측정 기관이 지수에 넣어 다시 돌리느냐입니다. 그리고 포화되면 후속 버전에 자리를 내줍니다.

이 구조에는 이해관계가 얽혀 있습니다. 연구소는 자기 모델이 잘 나오는 벤치마크를 골라 실을 유인이 있습니다. 데이터 업체의 벤치마크는 자사 데이터의 품질을 증명하는 영업 수단이기도 합니다. 제품 회사의 벤치마크는 자사 하네스에 유리한 구조일 수 있습니다. 실제로 수학 벤치마크 FrontierMath는 OpenAI의 자금 지원과 데이터 접근 문제가 뒤늦게 알려져 논란이 됐고, LMArena에는 대형 연구소들이 비공개로 여러 변형 모델을 시험해 본 뒤 가장 좋은 것만 공개한다는 비판 논문이 나왔습니다. 벤치마크 자체를 감사하는 역할이 따로 생겨난 이유입니다.

회사의 시스템은 무엇으로 평가하나#

여기까지 오면 자연스럽게 다음 질문이 생깁니다. 모델과 코딩 에이전트를 받아 쓰는 일반 회사가 그 위에 하네스를 얹어 자체 시스템을 만들었다면, 그 시스템을 재는 벤치마크도 있을까요.

조사한 바로는 업계 공통 표준은 사실상 없고, 세 층위로 접근합니다.

첫째, 공개 에이전트 벤치마크에 자기 하네스를 붙여 돌리는 방법입니다. 에이전트 벤치마크는 원래 “모델과 하네스의 조합"을 평가하므로 하네스를 바꿔 끼울 수 있습니다. Terminal-Bench의 실행 프레임워크인 Harbor는 원하는 에이전트를 붙여 돌릴 수 있게 돼 있습니다. 외부와 비교할 수 있는 숫자를 얻지만, 과제가 범용이라 회사 업무와는 거리가 있습니다.

둘째, 업종별 공개 벤치마크입니다. 고객 상담 에이전트가 회사 정책을 지키며 일관되게 업무를 처리하는지 pass^k로 재는 τ-bench(Sierra), CRM 업무를 다루는 CRMArena-Pro(Salesforce), SaaS 업무 흐름을 다루는 AutomationBench 등이 있습니다. 자사 시스템의 유형과 맞으면 그대로 돌려 볼 수 있습니다.

셋째, 실무에서 주류인 자체 평가입니다. 실제 업무 입력과 기대 결과를 묶은 고정 데이터셋을 만들고, 코드 검증, 루브릭 기반 LLM 판정, 사람 검수를 섞어 채점기를 만들고, 모델이나 프롬프트를 바꿀 때마다 같은 세트를 다시 돌립니다. 영국 AISI의 Inspect 같은 오픈소스 프레임워크와 여러 상용 평가 도구가 이 과정을 돕습니다.

흥미로운 것은 이 셋째 층위가 거꾸로 모델 평가 자료로 쓰이기 시작했다는 점입니다. Haiku 5.5 발표 페이지에는 HubSpot이 자사 CRM 업무로 만든 평가 세트의 결과(3회 평균)가 실려 있습니다. 모델 제공사가 고객사의 내부 평가를 “실무 근거"로 인용한다는 것은, 공개 벤치마크만으로는 실무 성능을 설득하기 어려워졌다는 뜻으로 읽힙니다.

맺으며 — 내 일의 시험지는 내가 만든다#

72.4%라는 숫자 하나를 따라가다 보니 결국 같은 결론에 닿았습니다. 공개 벤치마크는 모델을 고르는 데 쓸모가 있지만, 그 숫자는 남이 고른 과제를 남이 만든 채점기로 남의 조건에서 잰 값입니다. 내 일에 맞는 모델인지는 내 일로 만든 시험지로만 알 수 있습니다.

필자는 브리프에서 Haiku 5.5를 이 블로그 작업 하네스의 하위 에이전트와 요약 단계에 넣어 보겠다고 적었습니다. 이제 그 실험을 어떻게 할지 분명해졌습니다. 블로그의 콘텐츠 품질 기준 문서를 루브릭으로 삼고, 과거 브리프의 요약 작업 20개 정도를 고정 세트로 만들어, Sonnet과 Haiku를 같은 하네스에서 각각 여러 번 돌려 봅니다. 볼 지표는 한 번의 성공률이 아니라 매번 성공하는가(pass^k)와, 바뀐 토크나이저 아래에서 실제로 쓴 토큰 비용입니다.

지난 브리프의 주제어는 검증 부채였습니다. AI가 만든 결과물이 사람이 확인할 수 있는 속도를 넘어서면서 확인하지 못한 채 쌓이는 몫을 말합니다. 벤치마크 숫자를 출처와 조건 없이 옮겨 적는 것도 작은 검증 부채입니다. 이번에 필자가 갚은 것은 그 숫자 하나였지만, 앞으로 브리프에 벤치마크를 적을 때는 적어도 아래 질문에는 답한 뒤에 적을 생각입니다.

부록: 벤치마크 숫자를 읽을 때 확인할 7가지#

이 벤치마크는 이미 포화됐는가? 포화된 벤치마크의 1–2%p 차이는 의미가 작습니다.
전체 과제인가, 부분집합인가?
지표는 무엇인가? pass@1인지 pass@k인지, 부분 점수인지 엄격 통과인지 확인합니다.
하네스와 노력 설정은 무엇이었고, 비교 대상과 같은 조건이었는가?
누가 측정했는가? 제조사 자체 측정인지 독립 기관 측정인지, 신뢰구간이 있는지 봅니다.
이전 버전의 점수와 섞어 비교하지 않았는가?
벤치마크 자체에 대한 품질 감사가 있는가?