Benchmark는 무엇을 측정하는가

Qwen3.8-27B는 270억 개의 Parameters를 가진 비교적 작은 모델입니다. Model Weights가 Apache 2.0 License로 공개되어 있어 자체 Infrastructure에서도 운영할 수 있습니다. SWE-bench Pro에서는 61.7%를 기록합니다. Anthropic의 대형 상용 모델 Claude Opus 4.6은 같은 비교표에서 53.4%로 표시됩니다. [1][2]

처음 보면 결론은 놀랄 만큼 단순해 보입니다. Coding Agents를 비교하는데 한 모델은 61.7%, 다른 모델은 53.4%라면 Qwen3.8-27B가 더 좋은 Coding Agent라고 생각하기 쉽습니다. 기술 비교에 긴 논쟁이 필요하지 않고, 표에서 가장 큰 숫자만 보면 되는 것처럼 보이기도 합니다.

하지만 그런 결론을 내리기 전에 아주 평범한 질문 하나를 먼저 해야 합니다. 이 퍼센트는 실제로 무엇을 의미할까요?

흥미롭게도 첫 번째 복잡성은 Qwen Model Card 안에서 바로 확인할 수 있습니다. 표에는 실제로 Qwen3.8-27B가 61.7, Qwen이 “Opus4.6 Max”라고 표시한 비교 항목이 53.4로 적혀 있습니다. Anthropic 자체 자료에서는 이 값을 Claude Opus 4.6의 53.4%로 보고합니다. 여기서 별도의 “Opus 4.6 Max” 모델이 존재한다고 해석할 근거는 없습니다. [1][2]

표 바로 아래에는 Evaluation Setup도 설명되어 있습니다. 가져온 Opus 점수를 제외한 비교 모델들은 Claude Code Harness, temperature=1.0, top_p=0.95, 256K Context Window 조건으로 평가되었습니다. Qwen은 문제가 있는 Tasks를 수정한 뒤 이 “refined benchmark”에서 Baseline Models를 다시 실행했다고도 명시합니다. Opus 점수는 예외입니다. 같은 환경에서 다시 평가한 값이 아니라 Anthropic이 공식적으로 발표한 Score를 그대로 사용했습니다. [1]

Dataset 출처도 추적할 수 있습니다. Qwen이 공개한 Eval Metadata는 ScaleAI/SWE-bench_Pro를 가리키며, 이 Dataset의 공개 Test Split은 731개 Tasks로 구성됩니다. 전체 SWE-bench Pro는 더 크며 Held-out 및 Commercial 영역도 포함합니다. [1][6]

이 사실들이 숫자를 틀리게 만들거나 의심스럽게 만드는 것은 아닙니다. 다만 같은 표에 나란히 적힌 두 퍼센트도 자동으로 완전히 동일한 조건의 비교값이 되는 것은 아니라는 뜻입니다. 모델, Harness, Sampling Settings, Dataset Variant, 그리고 비교값의 출처까지 모두 해석에 포함되어야 합니다.

문제는 Score가 아니라 Score를 해석하는 방식입니다.

Benchmark란 무엇인가?

Benchmark는 우선 특별히 신비로운 개념이 아닙니다. 가능한 한 정의된 조건에서 시스템을 측정하고 비교하기 위한 표준화된 Test 또는 Task Collection입니다.

Benchmark는 완전한 직업 능력 평가라기보다 시험에 가깝다고 생각하는 편이 좋습니다. 수학 시험은 특정 수학 문제를 얼마나 잘 푸는지 의미 있게 측정할 수 있습니다. 높은 점수는 분명 중요한 정보입니다. 하지만 그 점수만으로 그 사람이 엔지니어로서 모호한 Requirements를 얼마나 잘 다루는지, Decisions를 잘 문서화하는지, 10년 된 시스템을 얼마나 잘 발전시키는지는 알 수 없습니다.

Coding Benchmark도 마찬가지입니다. 좋은 Benchmark는 특정 Software Engineering Capability를 특정 조건에서 상당히 잘 측정할 수 있습니다. 그렇다고 전문적인 Software Development에 필요한 모든 능력을 측정하는 것은 아닙니다.

Benchmark는 모델에 대한 판결이 아닙니다. 측정 도구입니다. 숫자를 비교하기 전에 이 도구가 실제로 무엇을 측정하는지 이해해야 합니다.

SWE – Software Engineering

요즘 SWE라는 약어는 여러 곳에서 등장합니다. SWE-bench, SWE-bench Verified, SWE-bench Pro, SWE-Lancer, SWE-rebench가 대표적입니다.

뜻은 생각보다 단순합니다.

SWE는 Software Engineering의 약자입니다.

이 이름은 이런 Benchmark들이 짧은 설명을 보고 함수 하나를 생성하는 것보다 더 넓은 Software Engineering Capability를 측정하려 한다는 의미를 담고 있습니다. 실제 업무에 얼마나 가까운지는 Benchmark마다 다릅니다.

SWE-bench – Coding Problem에서 Repository로

많은 전통적 Coding Benchmark는 서로 독립적인 Task를 사용합니다. 모델은 Problem Description과 Function Signature를 받고 Implementation을 만든 뒤 Tests로 평가됩니다.

단순화하면 다음과 같습니다.

문제 설명
↓
함수 구현
↓
Tests 실행

유용한 방식이지만 개발자의 실제 업무 중 일부만 측정합니다. 기존 프로젝트에서는 누군가 완벽한 설명과 함께 빈 함수를 건네주는 일이 드뭅니다. 먼저 어떤 Files가 관련되어 있는지 찾고, 기존 시스템을 이해하고, 요구사항이 실제로 어떤 변경을 뜻하는지 파악하고, 기존 동작이 깨지지 않도록 해야 합니다.

SWE-bench는 Evaluation을 실제 Software Repository에 더 가깝게 옮겼습니다. 원래 Benchmark는 12개의 인기 Python Repositories에서 수집한 2,294개 Tasks를 포함합니다. 실제 GitHub Issues와 그에 대응하는 변경사항을 기반으로 만들어졌습니다. 시스템은 인간이 수정하기 이전 Repository State와 원래 Problem Description을 받고 문제를 해결하는 Patch를 생성해야 합니다. 이후 Evaluation은 실패하던 Tests가 통과하는지, 기존 동작이 유지되는지를 확인합니다. [3]

기본 흐름은 이런 모습입니다.

Repository State
+
GitHub Issue
↓
Codebase 분석
↓
관련 위치 탐색
↓
Patch 생성
↓
Tests 실행
↓
resolved / unresolved

고립된 함수 하나보다 Software Engineering에 훨씬 가까운 평가입니다. 시스템은 낯선 Code 안에서 방향을 찾고 변경을 기존 Context에 통합해야 합니다.

하지만 여전히 통제된 Task입니다. 3년 뒤 Architecture가 이해 가능할지, Naming이 팀의 Domain Language와 맞는지, Patch가 장기 Migration Strategy에 자연스럽게 들어가는지는 자동으로 평가되지 않습니다. SWE-bench는 단순 Code Completion보다 훨씬 현실적인 것을 측정하지만 여전히 정의된 일부 영역을 측정합니다.

“61.7% resolved”는 무슨 뜻인가?

SWE-bench 계열 Leaderboard에서는 보통 Benchmark의 평가 규칙에 따라 해결된 Task 비율을 % Resolved로 표시합니다. [3]

따라서 61.7%는 대략 다음을 의미합니다.

명시된 Evaluation 조건에서 테스트된 Benchmark Tasks 중 61.7%가 이 Benchmark의 규칙에 따라 해결된 것으로 판정되었다.

거의 당연한 말처럼 들리지만 이 글 전체에서 가장 중요한 번역입니다. 이 퍼센트의 분모는 Benchmark Tasks입니다. 모든 가능한 Software Tasks도 아니고, 개발자가 수행하는 모든 업무도 아니며, 특정 회사가 겪는 모든 상황도 아닙니다.

그러므로 61.7% SWE-bench Pro는 모델이 전체 Software Tasks의 61.7%를 해결할 수 있다는 뜻이 아닙니다. “61.7%의 Software Engineer”라는 뜻도 아니고 개발자 한 명의 61.7%를 대체한다는 뜻도 아닙니다.

SWE-bench 61.7%는 Software Engineer 61.7%가 아닙니다.

SWE-bench Verified는 왜 생겼나?

실제 GitHub Projects를 사용하는 것은 분명한 장점이 있습니다. Benchmark를 위해 인공적으로 만들어 낸 문제가 아니기 때문입니다. 하지만 현실의 Repositories, Issues, Dependencies, Tests는 애초에 과학적으로 깨끗한 측정 도구를 만들기 위해 작성된 것이 아닙니다.

기존 SWE-bench Tasks는 상당 부분 자동으로 수집되었습니다. 이후 일부 Task가 모호하거나 설명이 부족하거나 Tests와 Environment 자체에 문제가 있다는 사실이 드러났습니다. 기능적으로 올바른 Solution이 지나치게 좁은 Test 때문에 실패할 수도 있었고, Hidden Test가 Problem Description에 없는 정보를 전제로 하는 경우도 있었습니다. Python Version, OS, Dependency State 차이도 재현성에 영향을 줄 수 있었습니다. [4][5]

그래서 OpenAI와 SWE-bench 팀은 경험 많은 Software Engineers에게 1,699개의 Candidate Tasks를 검토하게 했습니다. 각 Task는 세 명의 전문가가 독립적으로 평가했고, 그 결과 500개의 선별된 Tasks로 구성된 SWE-bench Verified가 만들어졌습니다. [4][5]

여기서 “Verified”는 가능한 모든 Evaluation이 수학적으로 완벽하다고 증명했다는 뜻이 아닙니다. 사람이 Task와 평가 방식을 검토하고 부적절한 사례를 걸러냈다는 뜻입니다.

합리적인 개선이었습니다. 동시에 이후의 역사는 Software Engineering을 지속적으로 잘 측정하는 도구를 만드는 일이 얼마나 어려운지도 보여 줍니다.

성공한 Benchmark가 시스템의 일부가 될 때

SWE-bench Verified는 매우 성공했습니다. Model Vendors가 Scores를 공개하고, Agent Developers가 성공과 실패 Trajectory를 분석하고, Harness가 Repository Work에 더 잘 맞도록 발전했으며 Benchmark 자체가 Coding Capability를 판단하는 중요한 기준이 되었습니다.

바로 그 성공이 시간이 지나면서 Evaluation 조건을 바꿉니다.

Contamination

Benchmark Evaluation에서 Contamination은 Eval Data 또는 매우 유사한 정보가 이미 모델의 Training이나 Post-Training 과정에 존재했을 위험을 뜻합니다.

SWE-bench에서는 이 문제가 직관적입니다. 원래 Repositories는 공개되어 있고 Issues도 공개되어 있으며, 인간의 Solution을 포함한 Pull Requests나 Commits도 공개된 경우가 많습니다. 모델이 대규모 Public Code와 기술 커뮤니케이션으로 Training되었다면 Benchmark Material과의 중복을 단순히 배제할 수 없습니다.

그렇다고 모델이 Evaluation 중에 저장된 Solution을 그대로 “조회한다”는 뜻은 아닙니다. Training Data의 단순 중복, 프로젝트에 대한 일반적인 Knowledge, 이미 알려진 Solution을 실제로 재현하는 것은 서로 다른 문제입니다. Contamination은 우선 Evaluation Risk이며 조작 의혹이 아닙니다.

OpenAI는 2026년 2월 SWE-bench Verified를 다시 분석했고, 현재 Frontier Models를 평가하기에는 Benchmark가 이런 효과와 남아 있는 Task Problems의 영향을 너무 많이 받는다고 판단했습니다. 조사된 일부 Tasks에서 모든 테스트된 Frontier Models가 Gold Patch 또는 매우 구체적인 Problem Information을 재현하는 사례가 관찰되었습니다. OpenAI는 이후 자체 모델에 대해 SWE-bench Verified Scores 보고를 중단했습니다. [4]

다른 연구들도 정적이고 공개된 Software Engineering Benchmarks의 이 문제를 해결하려고 합니다. 대표적인 방법은 계속 새로운 Tasks를 수집하고 Evaluation을 오래된 Training Data와 시간적으로 분리하는 것입니다. [12][13]

Benchmark Overfitting

Contamination과 Benchmark Overfitting은 같은 개념이 아닙니다.

Benchmark가 충분히 중요해지면 Models, Post-Training, Prompts, Agent Harnesses가 Benchmark가 보상하는 능력에 점점 더 최적화될 수 있습니다. 구체적인 정답을 알고 있을 필요는 없습니다. 흔한 Task Structure, Tool Sequence, 성공적인 Strategy를 더 잘 다루는 것만으로도 Score는 올라갈 수 있습니다.

학교 시험 비유가 잘 맞습니다. 시험 형식이 몇 년 동안 거의 같고 과거 시험지가 전부 공개되어 있다면 학생들은 수학뿐 아니라 “이 시험을 효율적으로 푸는 방법”도 배웁니다. 여전히 진짜 Knowledge가 필요할 수 있지만 시험 성적과 일반적 능력을 분리하기는 점점 어려워집니다.

AI만의 문제도 아닙니다. Machine Learning은 오랫동안 Dataset, Benchmark, Leaderboard에 대한 Overfitting을 다뤄 왔습니다. 어떤 Metric이 중요해질수록 바로 그 Metric을 최적화할 유인은 강해집니다.

따라서 한 Benchmark에서 큰 성능 향상이 있었다고 해서 모든 Software Engineering Tasks에서도 같은 비율의 향상이 발생한다고 볼 수는 없습니다.

SWE-bench Pro는 왜 생겼나?

Scale AI는 이런 한계를 더 밀어내기 위해 SWE-bench Pro를 만들었습니다. Benchmark는 41개 Repositories에서 1,865개 Tasks를 포함합니다. 731개는 Public Split, 858개는 Held-out 영역, 276개는 Commercial Codebases에서 가져왔습니다. Python, Go, JavaScript, TypeScript를 포함합니다. [6]

Tasks는 평균적으로 기존 SWE-bench보다 더 큽니다. Scale은 평균 4.1개 Files에서 107.4 Lines of Code가 변경된다고 보고합니다. 원래 Commit Messages나 Issues가 충분한 Context를 제공하지 않는 경우, Human Experts가 Problem Statement와 Requirements를 보완하지만 구체적인 Implementation 자체를 알려 주지는 않습니다. [6]

각 Split은 다른 문제를 겨냥합니다. Public Split은 공개 Evaluation과 재현성을 제공합니다. Held-out Tasks는 전체 Dataset으로 공개되지 않기 때문에 정확한 Eval Tasks에 직접 최적화하기 더 어렵습니다. Commercial Tasks는 Private Codebases에서 오기 때문에 해당 Repository States와 Solutions가 Public Training Data에 이미 포함되어 있을 가능성도 더 낮습니다.

여기서 한 가지 구분은 중요합니다. Held-out이 자동으로 “Training에서 절대 본 적 없음”을 뜻하지는 않습니다. 우선은 Eval Data를 공개하지 않고 보류했다는 의미입니다. 실제 Training Overlap을 얼마나 배제할 수 있는지는 데이터의 출처와 모델의 Training Pipeline에 달려 있습니다. Private Commercial Codebases는 단순히 공개하지 않은 Benchmark Tasks보다 더 강한 분리를 제공합니다.

Held-out과 Private Data는 Contamination Risk를 줄여 줍니다. 그렇다고 Benchmark가 자동으로 오류가 없어지는 것은 아닙니다.

그리고 SWE-bench Pro도 Audit되었다

2026년 7월 OpenAI는 SWE-bench Pro Audit 결과를 공개했습니다. 몇 달 전만 해도 OpenAI가 Verified에서 Pro로 옮길 것을 권장했다는 점에서 특히 흥미롭습니다. [4][7]

새 분석은 Public SWE-bench Pro Split의 731개 Tasks를 대상으로 했습니다. 자동 분석 Pipeline은 200개, 즉 27.4%를 문제 있는 Task로 표시했습니다. 이어진 Human Annotation에서는 249개, 즉 34.1%에서 관련 문제가 확인되었습니다. OpenAI는 이를 바탕으로 대략 30% 정도가 problematic 또는 “broken”할 수 있다고 조심스럽게 요약했고, SWE-bench Pro를 일괄 추천했던 이전 입장을 철회했습니다. [7]

문제로 지적된 내용에는 지나치게 엄격한 Tests, 불충분한 Prompt, 부족한 Test Coverage, 일부 오해를 유발하는 Task Description이 포함됩니다. 이 수치는 OpenAI Audit의 결과입니다. 전체 SWE-bench Pro 중 정확히 30%가 객관적이고 논쟁의 여지 없이 사용할 수 없다는 뜻은 아닙니다. 자동 분석과 Human Review 사이에서도 결과가 달랐다는 사실이 Evaluation 자체에도 판단이 필요하다는 것을 보여 줍니다.

그래서 이 사례가 중요합니다. SWE-bench Pro는 누군가 문제를 발견했다고 무가치해진 것이 아닙니다. 오히려 실제 Software Change를 현실적이고, 재현 가능하고, 자동으로 평가 가능하게 만드는 일이 얼마나 어려운지 보여 줍니다.

실제 Software Engineering을 측정하는 일 자체가 어려운 Software Engineering Problem입니다.

매우 최근의 예는 SWE-bench Multimodal에서도 볼 수 있습니다. 최초 Version은 Visual Information이 있는 517개 Issues를 포함했습니다. 2026년 9월 1일, SWE-bench 팀은 Reproducible Evaluation에 적합하도록 선별한 480개 Tasks로 Version 2를 공개했습니다. 알려진 Flaky 또는 안정적으로 평가하기 어려운 Tests를 제거하고, Dependency와 Browser Drift를 줄이기 위해 Docker Environments를 다시 만들었으며, JavaScript Grading과 Visual Test Assets 처리도 강화했습니다. [14]

Benchmark는 돌에 새겨진 자가 아니라 지속적인 유지보수가 필요한 기술 제품에 더 가깝습니다.

Model Score인가, System Score인가?

Coding Agent에서 특히 놓치기 쉬운 부분이 있습니다. Agentic Coding Benchmark는 흔히 Bare Base Model만 측정하지 않습니다.

Model과 최종 Patch 사이에는 전체 Runtime Environment가 존재합니다. 어떤 Files를 검색할 수 있는지, 어떤 Tools를 사용할 수 있는지, Shell Commands를 어떻게 실행하는지, Test Results를 Model에 어떻게 돌려주는지, Context를 어떻게 관리하는지, Agent가 몇 번 더 시도할 수 있는지를 결정합니다.

생각을 위한 모델로 Score를 다음처럼 볼 수 있습니다.

물론 수학 공식은 아닙니다. 각 요소를 실제로 더할 수 있다는 뜻이 아니라 관찰된 Score가 전체 시스템의 상호작용에서 나온다는 점을 기억하기 위한 그림입니다.

Qwen Example은 이를 매우 명확히 보여 줍니다. Model뿐 아니라 Claude Code를 Harness로 사용했다는 점, 256K Context Window, 구체적인 Sampling Parameters, 수정된 Task State까지 함께 공개합니다. [1]

우리가 61.7%만 가져오면 실험 설명의 큰 부분을 버리는 셈입니다.

Harness – 모델에게 작업 환경을 준다

이전 글에서 Agent Harness를 소개했습니다. Model 주변의 Runtime 및 Control Layer입니다.

Harness는 Files를 검색하고, Tool Calls를 구조화하고, Shell Output을 다시 전달하고, Context를 관리하고, Iterations를 조직하며, Agent가 언제 어떤 방식으로 Task를 끝내는지 정할 수 있습니다. 같은 Base Model을 사용하더라도 다른 Harness에서는 결과가 달라질 수 있습니다.

이것을 Benchmark에서 반드시 제거해야 하는 잡음으로 볼 필요는 없습니다. Coding Agent에서는 Harness도 제품의 일부입니다. 더 나은 Tooling이 모델에게 관련 File을 더 빨리 찾게 하거나 실패한 Test를 더 잘 이해하게 만든다면 실제 사용에서도 가치가 있습니다.

문제가 되는 것은 그 결과로 나온 System Score를 전적으로 Base Model의 능력이라고 표현할 때입니다.

현재 Leaderboard들도 이 변수를 일부 통제하려고 합니다. 예를 들어 SWE-bench Verified는 Bash Only View를 제공하여 Models를 동일한 mini-SWE-agent Environment에서 비교합니다. [3] 모든 차이가 사라지는 것은 아니지만 Harness Variation의 일부는 표준화됩니다.

Pass@1과 Pass@k

Benchmark 뒤에 붙는 작은 숫자 하나도 의미를 크게 바꿀 수 있습니다. k입니다.

Pass@1은 단순화하면 한 번의 시도로 성공하는 경우를 봅니다. Pass@k는 여러 Candidates를 생성했을 때 그중 적어도 하나가 성공할 가능성을 설명하거나 추정합니다. 이 개념은 Codex의 HumanEval Evaluation을 통해 널리 알려졌습니다. [8]

각 시도마다 어느 정도 성공 확률이 있다면 여러 번 시도할수록 적어도 하나의 성공 결과를 얻을 가능성은 자연스럽게 올라갑니다. 8개의 Candidates를 만들고 성공한 것을 선택하는 실험은 정확히 한 번만 시도하는 실험과 다릅니다.

그렇다고 pass@8이 pass@1보다 나쁘다는 뜻은 아닙니다. 실제 제품에서는 여러 Solution을 병렬 생성한 뒤 자동 또는 Human Review로 선택하는 방식이 충분히 합리적일 수 있습니다. 중요한 것은 두 Score가 동일한 횟수의 기회를 가졌다고 생각하며 비교하지 않는 것입니다.

k는 통계학적인 각주가 아니라 Experiment Setup의 일부입니다.

Token과 Compute Budget

Compute Budget도 마찬가지입니다. 몇 번의 Iteration과 50,000 Tokens로 Task를 처리하는 Agent와, 수백만 Tokens와 수많은 Tool Calls, 많은 추가 Steps를 허용받는 Agent는 다른 조건에서 일합니다.

더 많은 Compute가 본질적으로 나쁜 것은 아닙니다. 추가 Inference가 안정적으로 더 좋은 결과를 만들고 실제 Use Case가 그 Budget을 허용한다면 합리적인 기술 선택일 수 있습니다.

Benchmark Comparison에서는 각 시스템이 어떤 Resources를 사용할 수 있었는지 알아야 합니다. 그렇지 않으면 능력뿐 아니라 허용된 작업량도 동시에 비교하게 됩니다.

SWE-rebench Leaderboard에 공개된 Token Consumption 분석(2026년 9월 10일 접속)은 그 차이를 매우 잘 보여 줍니다. 같은 Task Family에서 비교되는 Agent Systems 사이의 Token Consumption이 30배 이상 차이 나기도 합니다. [12]

그 추가 Budget이 경제적으로 가치 있는지는 별개의 질문입니다. 이 Series 후반부에서 다룹니다.

Infrastructure만으로도 점수가 움직일 수 있다

전통적인 Text Benchmark에서는 답을 생성한 Machine이 잘 드러나지 않습니다. Coding Agent는 환경과 적극적으로 상호작용합니다. Dependencies를 설치하고, Compiler를 시작하고, Tests를 실행하고, CPU 또는 Memory Intensive Process를 만들기도 합니다.

Anthropic은 2026년 초 Terminal-Bench 2.0으로 이 영향을 조사했습니다. Model, Harness, Task Set은 동일하게 유지하고 Resource Configuration만 바꿨습니다. 가장 제한적인 환경과 가장 여유로운 환경 사이에는 6 percentage points 차이가 났습니다. 더 중간 수준의 설정들 사이에서도 약 2 points의 차이가 남았습니다. [9]

모든 Benchmark Score가 6 points씩 틀렸다는 의미는 아닙니다. Agentic Eval에서는 Runtime도 Experiment Setup의 일부라는 의미입니다. Memory Limit 때문에 Process가 종료된 Task도 최종 결과에서는 Agent가 잘못된 코드를 만든 Task와 똑같이 “unresolved”로 보일 수 있습니다.

Leaderboard 차이가 1~2 points에 불과하다면 “Model A가 Model B를 명확히 이긴다”는 표현은 조심해서 사용할 필요가 있습니다.

Benchmark 자체가 바뀌면

Terminal-Bench는 2026년에 또 다른 좋은 예를 제공합니다. Version 2.1은 Terminal-Bench 2.0의 89개 Tasks 중 28개를 수정했고 Continuous Validation을 도입했습니다. 다시 Evaluation하자 일부 Scores가 크게 변했습니다. 공개 비교에서 Claude Opus 4.6 + Claude Code는 58.0에서 70.1%로 올라갔습니다. [10]

Model이 갑자기 더 똑똑해진 것은 아닙니다. 더 공정하고 재현 가능하게 측정하기 위해 Benchmark가 바뀌었습니다.

“Terminal-Bench”라는 이름만으로는 충분하지 않습니다. 공식 Benchmark 개요에는 이미 Terminal-Bench 3.0이 올라와 있는 반면, 이 글에서 인용한 Qwen3.8 Model Card는 여전히 Terminal-Bench 2.1을 사용합니다. [1][10] 비교에서 중요한 것은 구체적인 Version과 각각의 실험 설정이며, 단 하나의 “현재” 기준이 있다는 가정이 아닙니다.

그래서 누군가 “Terminal-Bench Score”를 인용한다면 Version과 실험 설정도 함께 밝혀야 합니다. 서로 다른 Version과 Setup의 점수는 직접 비교할 수 없습니다.

Benchmark Version Number는 사소한 형식 문제가 아니라 Measurement 자체의 일부입니다.

더 높은 Score는 아직 구매 결정이 아니다

처음 예제로 돌아가 보겠습니다. Qwen3.8-27B는 270억 Parameters를 가지고 있으며 Model Weights가 Apache 2.0으로 공개되어 있습니다. Model Card에는 자체 Infrastructure에서 실행하는 여러 방법도 설명되어 있습니다. [1]

의사결정자는 다음 숫자를 볼 수 있습니다.

Qwen3.8-27B:      61.7%
Claude Opus 4.6:  53.4%

그리고 몇 대의 자체 GPU System을 운영하는 편이 상용 Cloud Models보다 분명히 더 좋은 선택이라고 결론 내릴 수도 있습니다.

하지만 Benchmark 하나만으로는 그런 결정을 정당화할 수 없습니다. 실제 구매와 Architecture 결정에는 Task Profile, 필요한 능력, Data Sovereignty, Privacy, Confidentiality, Operations, Concurrency, Latency, Context Requirements, Cost, Review Effort가 함께 고려되어야 합니다.

Local 또는 Self-Hosted Processing도 “데이터가 회사 안에 남는다”보다 더 정확하게 이해해야 합니다. Self-hosted Inference는 Tooling, Telemetry, Monitoring, Retrieval 및 다른 모든 구성요소까지 내부적으로 운영하고 적절히 설정한다면 완전히 내부에서 처리하도록 할 수 있습니다.

반대로 General Benchmark Score가 더 높다고 모든 개발 Task에 가장 강력한 Frontier Model을 사용해야 하는 것도 아닙니다. 범위가 좁고 Specification이 잘 정리된 Implementation Task는 더 작은 모델로 충분할 수 있고, 다른 작업은 훨씬 강한 Analysis나 Exploration을 요구할 수 있습니다.

중요한 결정들이지만 SWE-bench Pro가 측정하는 결정은 아닙니다.

서로 다른 Benchmark는 서로 다른 질문을 한다

SWE-bench가 모든 Software Engineering을 표현하지 못한다고 나쁜 Benchmark가 되는 것은 아닙니다. 하나의 Benchmark가 모든 것을 측정하는 것은 현실적으로 불가능합니다.

여러 Benchmark를 서로 다른 측정 도구로 보면 훨씬 유용합니다.

Benchmark	대략 무엇을 측정하는가?
SWE-bench Pro	현실적인 Software Engineering Task를 기반으로 기존 Repository를 변경하는 능력
Terminal-Bench	Tools, Programs, System Interaction을 포함한 Terminal Environment에서의 Multi-Step Work
SWE-Lancer	실제로 비용이 지급되었던 Freelance Software Tasks와 기술적 의사결정 Tasks
LiveCodeBench	Contamination을 줄이기 위해 지속적으로 새로 수집되고 시간적으로 분리된 Algorithmic Coding Tasks
SWE-rebench	더 Fresh한 Software Engineering Evaluation을 위해 계속 새로 수집되는 Repository Tasks
SWE-bench Multilingual	여러 Programming Languages에 걸친 SWE-bench 스타일 Repository Tasks
SWE-bench Multimodal	Visual Information이 Requirement 일부인 Repository Issues

Terminal-Bench는 Repository Patch를 넘어 Action Space를 확장합니다. Agent는 Terminal Environment에서 Software를 Build하고, Configuration을 수정하고, Programs를 실행하거나 기존 Tools와 상호작용해야 할 수 있습니다. Version 2.0에서 2.1로의 큰 수정은 이런 환경을 Reproducible하게 평가하는 것이 얼마나 어려운지도 보여 줍니다. [9][10]

SWE-Lancer는 다른 측면을 강조합니다. Upwork에서 실제로 의뢰된 1,400개 이상의 Freelance Tasks를 포함하며, 원래 지급된 보상의 합계는 약 100만 달러입니다. 50달러 Bugfix부터 32,000달러짜리 Feature Implementation까지 포함됩니다. Technical Proposal을 평가하는 Management Tasks도 있습니다. [11] 실제 금액과 연결되어 있어 Economic Question에 흥미로운 자료가 되지만 “개발자의 전체 가치”를 측정하는 것은 아닙니다.

LiveCodeBench는 Static Coding Benchmark의 시간 문제를 해결하려고 합니다. LeetCode, AtCoder, Codeforces 같은 Programming Competitions에서 새로운 Tasks를 지속적으로 수집하고 Publication Date를 기록합니다. 모델의 알려진 Training Cutoff 이후에 등장한 Problems로 Evaluation할 수 있습니다. [13] 동시에 Algorithmic Coding, Code Execution, Self-Repair 같은 영역에 초점이 있기 때문에 10년 된 Enterprise Codebase를 이해하는 능력과는 다릅니다.

SWE-rebench는 Repository Level에서 Freshness를 추구합니다. 2025년 원래 Release는 3,400개 이상의 Repositories에서 21,000개 이상의 Interactive Python Tasks를 수집했고, 계속 새 Tasks를 사용해 Contamination에 더 강한 Evaluation을 시도했습니다. 2026년 SWE-rebench V2는 이를 크게 확장해 3,600개 이상의 Repositories, 20개 Programming Languages, 32,000개 이상의 Executable Tasks를 설명하며, 설치 정보와 Metadata가 포함된 120,000개 이상의 추가 Tasks도 공개했습니다. [12] 핵심 아이디어는 같습니다. 한 개의 Static Dataset이 산업 전체의 영구 시험지가 되지 않도록 계속 새로운 문제를 공급하는 것입니다.

SWE-bench Multilingual은 언어 Coverage를 넓힙니다. 42개 Repositories의 300개 Curated Tasks가 C, C++, Go, Java, JavaScript, TypeScript, PHP, Ruby, Rust 아홉 개 Programming Languages에 걸쳐 있습니다. [15] Python 중심 Benchmark만으로는 같은 능력이 다른 Ecosystem으로 얼마나 잘 전이되는지 알기 어렵기 때문에 중요합니다.

SWE-bench Multimodal은 또 다른 질문을 던집니다. Requirement가 Text에만 있지 않다면 어떻게 될까요? Bug Screenshot, Design Mockup, Wireframe, Diagram은 Frontend Project에서 흔한 입력입니다. 2026년 9월 1일 공개된 Version 2는 Reproducible Evaluation을 위해 선별한 480개 Tasks를 포함합니다. [14]

이 중 하나가 “최고의 Benchmark”인 것은 아닙니다. 서로 다른 질문을 할 뿐입니다.

Public Benchmark는 지도이지 우리의 지형은 아니다

Public Benchmarks는 초기 방향을 잡는 데 매우 유용합니다. 우리 Use Case와 관련된 여러 Coding Evals에서 지속적으로 크게 뒤처지는 모델은 여러 측정 도구에서 안정적으로 강한 모델과 다른 신호를 줍니다.

하지만 특정 조직에서 진짜 중요한 질문은 다를 수 있습니다.

업무 대부분이 Python Bugfix가 아니라 Angular Migration일 수 있습니다. Repository가 매우 크고 Architecture가 강하게 Modularized되어 있으며 기존 Boundaries를 지키는 것이 가장 중요한 Quality Criterion일 수도 있습니다. Agents의 주 역할이 Tests 추가, Legacy Code 분석, Proprietary .NET Codebase 변경 준비일 수도 있습니다.

이런 경우에는 자체 Evals가 훨씬 중요해질 수 있습니다.

Internal Eval이 새로운 학술 Benchmark가 될 필요는 없습니다. 작은 규모라도 대표적인 Tasks를 Reproducible하게 구성하면 서로 다른 Model-Agent Systems가 실제 환경에서 어떻게 동작하는지 볼 수 있습니다. 예를 들어 전형적인 Bugfix, Feature, Refactoring, Migration, Test Extension, Repository Analysis를 사용할 수 있습니다.

Public Benchmark와 같은 규율이 필요합니다. 시스템이 어떤 Task를 받는지, 어떤 Repository State를 사용하는지, 어떤 Tools가 허용되는지, Agent에게 얼마나 많은 Budget을 주는지, Success를 어떻게 판단하는지, 그리고 자체 Evaluation이 정말 조직이 중요하게 보는 것을 측정하는지 누가 확인할지를 정해야 합니다.

Public Benchmarks는 모델을 위치시키는 데 도움을 줍니다. 자체 Evals는 구체적인 의사결정을 준비하는 데 도움을 줍니다.

다시 61.7%로

처음에는 두 숫자가 있었습니다.

Qwen3.8-27B      61.7%
Claude Opus 4.6  53.4%

지금까지의 내용을 알고 나서도 이 숫자들은 여전히 흥미롭습니다. Qwen3.8-27B는 이 크기의 모델로서 주목할 만한 SWE-bench Pro 결과를 공개했습니다. Model Weights를 사용할 수 있고 자체 Infrastructure에서 실행할 수 있다는 점도 기술적, 전략적 의미를 가집니다. [1]

다만 이제 숫자가 조금 덜 마법처럼 보여야 합니다.

Qwen의 61.7%가 ScaleAI/SWE-bench_Pro에서 Claude Code, 특정 Sampling Settings, 256K Context Window, 수정된 Task State를 사용해 나온 값이라는 것을 알고 있습니다. 같은 Qwen 표의 Claude Opus 4.6 53.4%는 동일한 Qwen Run에서 나온 값이 아니라 Anthropic이 공식적으로 보고한 결과를 가져온 것이라는 점도 알고 있습니다. [1][2]

SWE-bench Pro가 전통적인 고립형 Coding Tasks보다 실제 Repository Work를 더 잘 근사하지만 Software Engineering 전체를 측정하는 것은 아니라는 것도 알고 있습니다. Held-out 및 Private Data가 Contamination Risk를 줄일 수 있지만 새 Benchmark조차 문제가 있는 Tasks를 가질 수 있다는 점도 알고 있습니다. Harness, Tools, Compute Budget, 심지어 Infrastructure도 결과에 영향을 줄 수 있습니다.

이 사실들이 Benchmark의 가치를 없애지는 않습니다. 오히려 반대입니다. 한계를 알아야 측정된 정보를 제대로 사용할 수 있습니다.

Benchmark가 무엇을 측정하는지 이해하면 매우 유용합니다. 위험해지는 순간은 정밀한 숫자에서 Benchmark가 한 번도 측정하지 않은 결론을 끌어낼 때입니다.

Benchmark는 모델에 대한 최종 판결이 아니라 측정 도구입니다.

그리고 거의 부수적으로 한 가지를 더 배웠습니다. Coding Agent를 평가하는 순간 우리는 더 이상 Model만 이야기하지 않습니다. Context, Tools, Harness, Persistent State, 그리고 시스템이 정보를 Model에 어떻게 공급하는지가 모두 결과에 영향을 줍니다.

그래서 같은 모델이 왜 서로 다른 Solution을 만들 수 있는지 이야기하기 전에, 먼저 그 주변 Layer들이 무엇이 다른지 정리할 필요가 있습니다. Context, Memory, Skills, Agents.

다음 글은 바로 그 이야기입니다.

참고 자료

[1] Qwen Team: Qwen3.8-27B Model Card. Hugging Face, 2026; 2026년 8월 14일 공개된 ScaleAI/SWE-bench_Pro Eval Metadata 포함.

[2] Anthropic: Project Glasswing: Securing critical software for the AI era. 2026. Claude Opus 4.6 SWE-bench Pro Score: 53.4%.

[3] Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, Karthik R. Narasimhan: SWE-bench: Can Language Models Resolve Real-World GitHub Issues? ICLR 2024; 2026년 9월 기준 공식 SWE-bench Documentation 및 Leaderboards 포함.

[4] OpenAI: Why SWE-bench Verified no longer measures frontier coding capabilities. 2026년 2월 23일.

[5] OpenAI: Introducing SWE-bench Verified. 2024년 8월 13일.

[6] Scale AI Research Team: SWE-Bench Pro: Raising the Bar for Agentic Coding. 2025년 9월 19일.

[7] OpenAI: Separating signal from noise in coding evaluations. 2026년 7월 8일.

[8] Mark Chen et al.: Evaluating Large Language Models Trained on Code. 2021. arXiv:2107.03374.

[9] Gian Segato / Anthropic: Quantifying infrastructure noise in agentic coding evals. Anthropic Engineering, 2026년 2월 5일.

[10] Terminal-Bench Team: Terminal-Bench 2.1, Release Notes, 2026년 5월 6일; Terminal-Bench 3.0 및 Benchmark 개요 포함, 2026년 9월 10일 접속. 각 Version 표기는 해당 Evaluation에 속합니다.

[11] Samuel Miserendino, Michele Wang, Tejal Patwardhan, Johannes Heidecke: SWE-Lancer: Can Frontier LLMs Earn $1 Million from Real-World Freelance Software Engineering? ICML 2025.

[12] Ibragim Badertdinov et al.: SWE-rebench: An Automated Pipeline for Task Collection and Decontaminated Evaluation of Software Engineering Agents. 2025. arXiv:2505.20411; Ibragim Badertdinov et al.: SWE-rebench V2: Language-Agnostic SWE Task Collection at Scale. 2026. arXiv:2602.23866; SWE-rebench Leaderboard의 Token Consumption 분석 포함, 2026년 9월 10일 접속. 이 동적 Leaderboard는 고정된 Benchmark 시계열이 아닙니다.

[13] Naman Jain et al.: LiveCodeBench: Holistic and Contamination Free Evaluation of Large Language Models for Code. 2024. arXiv:2403.07974.

[14] John Yang, Carlos E. Jimenez, Alex L. Zhang et al.: SWE-bench Multimodal: Do AI Systems Generalize to Visual Software Domains? ICLR 2025; SWE-bench Multimodal v2, 2026년 9월 1일.

[15] Kabir Khandpur, Kilian Lieret, Carlos E. Jimenez, Ofir Press, John Yang: SWE-bench Multilingual. 42개 Repositories, 9개 Programming Languages에 걸친 300개의 Curated Tasks.