Split View: 코딩 벤치마크는 에이전트 시대와 어긋나 있다 — 리더보드가 에이전트를 잘못 비교하는 세 가지 이유
코딩 벤치마크는 에이전트 시대와 어긋나 있다 — 리더보드가 에이전트를 잘못 비교하는 세 가지 이유
들어가며 — 모델을 재던 잣대로 시스템을 비교하다
코딩 에이전트는 이제 많은 팀에서 소프트웨어를 만드는 주된 방식이 되었습니다. 그런데 우리가 그것들을 줄 세우는 잣대는 여전히 모델 하나 를 재던 시절의 것입니다. 앞서 코딩 평가에서 신호와 잡음을 가려내는 글에서 리더보드가 오염과 인프라 잡음으로 흔들린다는 걸 봤고, UniClawBench 글에서 더 나은 에이전트 벤치마크가 어떻게 생겨야 하는지 한 가지 구체적인 답을 봤습니다. 이번 글이 볼 논문은 그 사이를 잇는 질문에 정면으로 답합니다 — 왜 어긋나는가, 무엇이 구조적으로 잘못됐는가.
Tessl 연구진(Maria I. Gorinova 외)이 2026년 6월 16일 arXiv에 올린 포지션 논문 "Position: Coding Benchmarks Are Misaligned with Agentic Software Engineering" 의 주장은 제목 그대로입니다 — 오늘날의 코딩 벤치마크는 에이전트형 소프트웨어 엔지니어링과 근본적으로 어긋나 있다는 것입니다.
어긋남의 뿌리는 단순합니다. 지금의 벤치마크는 개별 모델 을 평가하려고 에이전트 이전 시대에 설계됐습니다. 그래서 하나의 정답(reference solution)에 맞춰 단 하나의 종단(end-to-end) 점수 를 내고, 중간 과정에 대한 신호는 주지 않습니다. 문제는 우리가 그 잣대를 모델이 아니라 시스템 을 비교하는 데 쓰고 있다는 점입니다.
코딩 에이전트는 모델이 아니라 시스템이다
논문의 중심 재구성은 여기 있습니다. 실전의 코딩 에이전트는 모델 하나가 아니라 시스템 하네스(system harness) 입니다 — 모델, 하네스, 컨텍스트, 환경, 피드백 신호가 얽힌 복합체라는 것입니다.
score = f(model, harness, context, environment, feedback)
이 그림에서 결정적인 문장은 이것입니다 — 이 구성 요소 중 어느 하나 만 바꿔도 점수가 인접한 모델 세대 사이의 차이에 맞먹는 폭 으로 움직일 수 있다는 것. 즉 하네스나 컨텍스트를 손보는 것만으로, 마치 한 세대 더 좋은 모델을 쓴 것 같은 점수 변화가 나올 수 있습니다.
그 구성 요소를 구체적으로 그려 보면 도움이 됩니다. 코딩 에이전트에서 하네스는 재시도와 계획 루프이고, 컨텍스트는 검색과 프롬프트 조립이 모델 앞에 놓는 것이며, 환경은 컨테이너·도구·테스트 러너이고, 피드백은 코드를 실행해 돌아오는 것입니다. 각각이 하나의 설계 결정이고, 그 모두가 똑같은 하나의 점수 안으로 접혀 들어갑니다.
그렇다면 리더보드의 숫자 하나는 곤란한 처지에 놓입니다. 모델 A가 모델 B를 이겼다는 표시가, 정말 A가 더 나은 모델이어서인지 아니면 A를 감싼 하네스가 더 좋았을 뿐인지 그 숫자만으로는 구분할 수 없습니다. 앞 글에서 Anthropic이 가중치를 한 줄도 안 바꾸고 컨테이너 설정만으로 점수를 움직였던 실측이 바로 이 주장의 경험적 뒷받침입니다.
세 가지 어긋남
논문은 이 어긋남을 세 가지 구체적 증상으로 정리합니다.
1) 모델과 하네스를 뭉뚱그린다. 벤치마크 점수는 모델과 나머지 하네스를 한 덩어리로 섞어 버립니다. 그래서 어떤 개선이 모델이 좋아진 덕인지, 시스템 설계가 좋아진 덕인지 갈라내지 못합니다. 벤더가 "새 모델이 몇 %p 올랐다"고 말할 때, 그 상승분의 상당량이 사실은 하네스 개선일 수 있습니다.
2) 단일 정답이 정당한 대안을 벌준다. 하나의 정답 솔루션에 맞춰 채점하면, 똑같이 올바른 다른 풀이 가 오답 처리됩니다. 소프트웨어에는 정답이 여럿입니다. 기능적으로 완전히 맞는 접근이라도, 채점이 특정 gold patch의 diff나 테스트에 묶여 있으면 0점이 나옵니다. (앞 글에서 인용한 OpenAI의 관찰 — SWE-bench Verified의 미해결 과제 중 60% 이상이 채점 기준상 애초에 풀릴 수 없었다는 것 — 이 같은 문제의 극단적 사례입니다.)
3) 컴포넌트 단위 신호가 없다. 개별 하네스 컴포넌트 수준의 신호가 부재 하기 때문에, 종단 시스템 점수는 개선을 이끌기가 어렵습니다. 숫자는 하나뿐이고, 그 숫자가 컨텍스트 관리 탓인지, 도구 호출 탓인지, 피드백 루프 탓인지 알려 주지 않습니다. 시스템을 만드는 사람에게는 이게 가장 깊은 문제입니다 — 어디가 문제인지 짚을 수 없으면 무엇을 고쳐야 할지도 알 수 없습니다.
이 셋은 서로 독립적이지 않습니다 — 겹쳐서 증폭됩니다. 뭉뚱그림은 어느 컴포넌트가 점수를 벌었는지 가리고, 단일 정답 채점은 실제로는 옳았던 동작을 가리며, 컴포넌트 신호의 부재는 하네스를 의심하더라도 그것을 확인할 수 없게 만듭니다. 셋이 포개지면 종단 숫자는 순위는 매길 수 있어도 거기서 배울 것은 없는 값이 됩니다.
더 나은 평가는 어떻게 생겼나
한 가지는 분명히 해 둡니다. 이 논문의 초록은 문제를 재정의 할 뿐, 구체적인 대체 벤치마크를 처방하지는 않습니다. 그러니 아래는 논문의 프레임이 자연스럽게 가리키는 방향이자, 앞서 본 UniClawBench 같은 설계가 이미 부분적으로 구현하고 있는 것들입니다. 세 방향은 세 가지 어긋남을 그대로 뒤집습니다.
- 컴포넌트 단위(component-level). 각 구성 요소를 계측하고, 한 번에 하나씩만 바꿔(ablation) 어느 부분이 점수를 움직였는지 보고합니다. 종단 숫자 하나가 아니라, 하네스의 어느 층이 기여했는지가 드러나야 합니다.
- 다중 정답(multi-reference). 하나의 gold patch와 문자열을 대조하는 대신 결과와 동작 으로 채점합니다. UniClawBench가 살아 있는 컨테이너 안에서 단계별 체크포인트로 "그 일이 실제로 일어났는가"를 보는 방식이 이 방향의 구체적 사례입니다.
- 시스템 인식(system-aware). 하네스를 고정하고 문서화한 뒤, 시스템을 시스템으로서 비교합니다. 숫자 하나를 "모델의 실력"이라고 부르는 착시를 멈추는 것입니다.
요약하면, 좋은 에이전트 평가는 무엇이(어느 컴포넌트가) 왜(어떤 동작으로) 움직였는지 를 말해 줘야 합니다. 등수 하나로는 둘 다 알 수 없습니다.
현실적으로 대부분의 공개 리더보드는 이 셋 중 무엇도 주지 않습니다. 그래서 부담은 당신에게 넘어옵니다 — 자기 하네스를 고정하고, 자기 과제의 결과로 채점하고, 자기 컴포넌트를 하나씩 바꿔 보는 것. 표에서 등수를 읽는 것보다 품이 들지만, 당신의 시스템에 대해 무언가를 말해 주는 숫자는 그렇게 얻은 것뿐입니다.
마치며
포지션 논문이라는 성격은 분명히 기억해 둘 필요가 있습니다. 새 벤치마크도, 새 데이터도 아닙니다 — 하나의 관점 입니다. 그러니 결과처럼 인용할 게 아니라 렌즈처럼 써야 합니다. 다만 그 렌즈는 꽤 날카롭습니다.
핵심을 한 문장으로 줄이면 이렇습니다 — 우리가 리더보드 숫자 하나로 두 에이전트를 비교할 때, 사실은 두 개의 시스템 전체 를 비교하면서 마치 두 개의 모델을 비교하는 척하고 있다는 것. 그래서 쓸모 있는 질문은 "누가 1위인가"가 아니라 "어느 컴포넌트가 그 차이를 만들었고, 그걸 내 하네스에서 재현할 수 있는가"입니다. 컴포넌트 단위·다중 정답·시스템 인식 — 이 세 가지가 갖춰지기 전까지, 에이전트 리더보드의 소수점은 대체로 신호가 아니라 배치(configuration)입니다.
참고 자료
Coding Benchmarks Are Misaligned with the Agent Era — Three Reasons Leaderboards Compare Agents Wrong
- Introduction — Measuring Models, Comparing Systems
- A Coding Agent Is a System, Not a Model
- Three Ways the Alignment Breaks
- What Better Evaluation Looks Like
- Closing
- References
Introduction — Measuring Models, Comparing Systems
Coding agents have become a primary way many teams ship software. Yet the yardstick we rank them with still belongs to the era when we measured a single model. In Separating signal from noise in coding evaluations we watched leaderboards wobble under contamination and infrastructure noise; in the UniClawBench piece we saw one concrete answer for what a better agent benchmark could look like. The paper here answers the question sitting between them — why the mismatch exists, and what is structurally broken.
The position paper "Position: Coding Benchmarks Are Misaligned with Agentic Software Engineering" by a Tessl team (Maria I. Gorinova et al.), posted to arXiv on 16 June 2026, argues exactly what its title says: today's coding benchmarks are fundamentally misaligned with agentic software engineering.
The root of the mismatch is simple. Current benchmarks were designed in the pre-agent era to evaluate individual models. So they produce a single end-to-end score against one reference solution, with no signal about the intermediate steps. The trouble is that we now use that yardstick to compare systems, not models.
A Coding Agent Is a System, Not a Model
Here is the paper's central reframing. A coding agent in practice is not one model but a system harness — a composite of models, harnesses, contexts, environments, and feedback signals.
score = f(model, harness, context, environment, feedback)
The decisive claim about this picture: changing any one of these components can move the score by a margin comparable to the gap between adjacent model generations. In other words, adjusting the harness or the context alone can produce a score swing that looks like you upgraded to a whole new model generation.
It helps to make those components concrete. For a coding agent, the harness is the retry and planning loop; the context is what retrieval and prompt assembly put in front of the model; the environment is the container, tools, and test runner; and the feedback is what comes back from executing code. Each is a design decision, and each is folded into the same single score.
That puts a single leaderboard number in an awkward spot. When model A beats model B, the number alone cannot tell you whether A is the better model or whether A simply wore a better harness. The empirical backing is in the previous post: Anthropic moved scores using only container settings, without touching a single weight.
Three Ways the Alignment Breaks
The paper distills the misalignment into three concrete symptoms.
1) It conflates the model with the harness. Benchmark scores blend the model and the rest of the harness into one lump, so you cannot tell whether an improvement came from a better model or from better system design. When a vendor says "the new model gained a few points," much of that gain may actually be harness work.
2) A single reference penalizes valid alternatives. Grading against one reference solution marks equally correct alternatives as wrong. Software has many right answers; a functionally correct approach still scores zero if grading is tied to one gold patch's diff or tests. (OpenAI's observation cited in the earlier post — that over 60% of SWE-bench Verified's unresolved tasks were ungradeable by construction — is an extreme case of the same problem.)
3) There is no component-level signal. Because there is no signal at the level of individual harness components, the end-to-end system score is hard to iterate on. You get one number, and it does not say whether the bottleneck is context management, tool calls, or the feedback loop. For anyone building systems this is the deepest problem — you cannot fix what you cannot localize.
These three are not independent — they compound. Conflation hides which component earned the score; single-reference grading hides behavior that was actually correct; and the missing component signal means that even when you suspect the harness, you cannot confirm it. Stacked together, they turn the end-to-end number into something you can rank with but cannot learn from.
What Better Evaluation Looks Like
One caveat up front: the paper's abstract reframes the problem rather than prescribing a specific replacement benchmark. So what follows is the direction its frame points toward — and what designs like UniClawBench already implement in part. The three directions simply invert the three failure modes.
- Component-level. Instrument each component and vary one at a time (ablation), then report which part moved the number. Instead of a single end-to-end figure, the contribution of each layer of the harness should be visible.
- Multi-reference. Rather than string-matching one gold patch, grade on outcomes and behavior. UniClawBench's step-level checkpoints inside a live container — checking whether the thing actually happened — are a concrete instance of this direction.
- System-aware. Fix and document the harness, then compare systems as systems. It means dropping the illusion that a single number is "the model's ability."
In short, a good agent evaluation should tell you what (which component) moved and why (through which behavior). A single rank tells you neither.
Practically, most public leaderboards give you none of the three. So the burden shifts to you: pin your own harness, grade on your own outcomes, and ablate your own components on your own tasks. That is more work than reading a rank off a table — but it is the only version of the number that tells you anything about your system.
Closing
It is worth remembering this is a position paper. It is not a new benchmark or new data — it is a lens. So use it as a lens, not as a result to cite. That lens, though, is fairly sharp.
Compressed to one sentence: when we compare two agents by a single leaderboard number, we are really comparing two whole systems while pretending to compare two models. The useful question is therefore not "who is number one" but "which component created the gap, and can I reproduce it on my own harness." Until component-level, multi-reference, and system-aware evaluation are in place, the decimals on an agent leaderboard are mostly configuration, not signal.