LLM은 벤치마크 결함을 찾아낼 수 있을까?

문제

코딩 에이전트 벤치마크는 AI 발전의 핵심 도구입니다. RL 학습 신호를 만들어 주고, 모델 출시 때 성능 지표가 되고, 연구 방향까지 정합니다. 그런데 이 벤치마크 자체에 버그가 있습니다.

• SWE-bench: OpenAI가 task 1,699개에 annotator를 3명씩 붙여 감사했더니 68%가 결함으로 판정됐습니다. 문제 설명이 불명확하거나, 올바른 답을 떨어뜨리는 테스트가 있는 경우였습니다. 이런 task를 걸러내고 만든 것이 SWE-bench Verified(500개)입니다.
• Terminal-Bench 2: task 89개 중 31%가 커뮤니티와 저자의 수정 PR로 고쳐졌습니다. 부실한 테스트, 오해를 부르는 artifact, 환경 문제 등이 원인이었습니다.
• Terminal-Bench 1: task 229개에 커뮤니티 수정 PR이 108건 올라왔습니다(2026년 5월 기준).

이런 결함이 사라지지 않는 이유는 노력이 부족해서가 아니라 수동 감사로는 규모를 감당할 수 없기 때문입니다. 게다가 모델이 강해질수록 새로운 결함이 드러납니다. 프론티어 모델의 SWE-bench Verified 점수가 포화된 뒤 남은 실패 사례를 감사했더니, 그중 59%는 모델의 한계가 아니라 테스트 결함 때문이었습니다.

Task Verification Bench

Task Verification Bench(TVB)를 소개합니다. 벤치마크의 버전 간 diff를 GT로 삼는 메타 벤치마크입니다. 저자가 v2를 내면서 어떤 task를 고쳤다면, 그 task는 v1에서 결함이 있었다는 뜻이 됩니다.

벤치마크 세 계열에서 라벨을 모았습니다.

• SWE-bench: annotator 3명 감사에서 나온 결함 task 1,160개 (필터링 후 결함 129개 + 정상 129개 = 258개)
• Terminal-Bench 2: 결함 26개 + 정상 26개 = 52개
• Terminal-Bench 1: 결함 65개 + 정상 56개 = 121개 (GT 노이즈 필터링 후)

LLM 에이전트에게는 원본 task 자료(문제 설명, 테스트, 정답 패치)만 줍니다. 에이전트는 task에 결함이 있는지 판정하고, 그 원인까지 정확히 짚어야 합니다.

원인까지 맞혔는가 (Root-Cause Matching)

설계의 핵심은 하나입니다. 결함이 있다는 것만 맞혔는지가 아니라 원인까지 맞혔는지로 평가합니다.

에이전트가 task에 결함이 있다고 판정해도 원인이 틀리면 그 진단으로는 고칠 수 없습니다. 그래서 에이전트가 지적한 결함이 GT annotation과 맞아야 맞힌 것으로 칩니다. LLM judge는 에이전트의 분석과 GT를 비교해 이렇게 묻습니다. 에이전트가 지적한 결함을 고치면 GT의 결함도 같이 해결되는가?

이 구분에 따라 결과가 크게 달라집니다. 결함 유무만 보는 판정 recall은 원인 매칭 recall보다 최대 54%p 높게 나옵니다.

주요 결과

벤치마크별 기본 성능 (GPT-5.4, verify-only + sandbox)

원인 매칭 recall은 35~60% 수준입니다. 사전 분류(triage)에는 쓸 만하지만, 감사를 완전히 자동화하기에는 아직 부족합니다.

Self-Attribution Anchoring

SWE-bench에서 파이프라인 ablation을 돌리다가 흥미로운 현상을 발견했습니다. GPT-5.4에게 task를 먼저 풀게 한 뒤, 자기가 짠 코드를 sandbox에서 볼 수 있는 상태로 검증을 시키면 벤치마크가 아니라 자기 코드를 탓합니다. 그 결과 원인 매칭 recall이 78.3%에서 53.9%로 떨어졌습니다.

우리는 이를 self-attribution anchoring이라고 부릅니다. 에이전트가 실패한 자기 패치를 검토하다가 테스트 실패를 자기 구현 탓으로 돌리고, 원래라면 지적했을 결함을 그냥 넘겨 버리는 현상입니다.

반면 Gemini 3.1 Pro는 이런 영향을 거의 받지 않았고, 모든 조건에서 원인 매칭 recall이 70~76%로 안정적이었습니다. 파이프라인 설계보다 어떤 모델을 쓰느냐가 더 중요합니다.

텍스트 결함과 인프라 결함

에이전트는 텍스트에 드러나는 결함에는 강합니다. 문제 설명과 테스트 assertion을 비교해 서로 안 맞는 부분을 잘 찾아냅니다. 반면 인프라 쪽 결함은 사각지대입니다. 환경 문제, Dockerfile 유출, oracle 회귀 같은 결함은 더 긴 추론이 필요해서 에이전트가 번번이 놓칩니다.

표본으로 살펴본 사례 가운데 에이전트가 맞힌 6건은 모두 텍스트 결함이었고, Terminal-Bench에서 틀렸거나 GT와 어긋난 8건은 모두 인프라 결함이었습니다.

시사점

LLM을 활용한 감사는 텍스트 결함에서는 사람의 검토 부담을 크게 줄여 줍니다. 하지만 인프라 쪽 검증에는 여전히 사람의 전문성이 필요합니다.

가장 좋은 방식은 AI가 먼저 분류하고, 사람은 중요한 곳을 집중해서 보는 것입니다. LLM은 사람을 대신하는 것이 아니라, 사람이 어디를 봐야 할지를 짚어 줍니다.

Delphik은 바로 이런 도구를 만들고 있습니다.

논문 보기

“Can LLMs Detect Benchmark Defects? A Meta-Benchmark from Benchmark Version Diffs”
ICML 2026 DL4C Workshop 제출 논문.

논문 다운로드 (PDF)

Task Verification Bench 데이터셋과 평가 코드는 논문 게재 후 공개할 예정입니다.