SWE-bench Verified 500개 태스크 전수 측정과, 그 숫자로 주장할 수 없는 것

SWE-bench Verified는 실제 GitHub 이슈를 저장소 상태 그대로 재현하고, 모델이 만든 패치가 숨겨진 테스트를 통과하는지로 채점합니다. 부분 점수가 없어서 “거의 맞음”이 존재하지 않습니다.

측정 조건

500개 태스크 전체

를 공식 하니스에서 실행했습니다. 부분 집합을 뽑거나 실패한 태스크를 재시도해 평균을 올리지 않았고, 결과는 394/500, 78.80%입니다. 나머지 106개는 미해결로 계상했으며, 그중 5건은 패치가 비어 있었습니다. 채점하지 못한 태스크는 없습니다.

전수 실행을 고른 이유는 비용이 아니라 비교 가능성입니다. 부분 집합 점수는 어떤 부분 집합이었는지를 함께 밝히지 않으면 다른 보고와 비교할 수 없고, 태스크마다 난이도가 크게 달라 어떤 태스크가 뽑혔는지에 따라 점수가 달라집니다.

저장소별 분포는 고르지 않았습니다. scikit-learn 30/32와 xarray 20/22가 가장 높았고 pylint 4/10이 가장 낮았습니다. django는 231개로 전체의 46%를 차지합니다.

이 숫자가 무엇을 말하지 않는가

78.80%는 스캐폴드의 점수가 아닙니다. 에이전트 벤치마크 점수는 모델의 능력과 스캐폴드의 능력이 합쳐진 값이고, 같은 500개에서 모델만 단독으로 돌린 대조군을 만들지 않았기 때문에 이 실행만으로는 둘을 가를 수 없습니다. 사용한 모델 자체가 강한 모델이라 상당 부분은 모델이 한 일입니다.

Verified는 포화된 벤치마크입니다. 2026년 2월 OpenAI가 공개 보고를 중단했고, 하드 서브셋에서 결함 있는 테스트 케이스가 다수 발견됐다는 감사와, 프런티어 모델들이 사람이 작성한 정답 패치를 그대로 재생산한다는 학습 데이터 오염 정황이 근거였습니다. 그래서 이 숫자는 기준선이지 기록 주장이 아닙니다.

이 두 문장을 먼저 적는 이유는 방어가 아닙니다. 스캐폴드에 값이 있는지는 별도의 통제 실험으로만 알 수 있고, 그래서 두 건을 따로 돌렸습니다.

통제 실험 1 — 선택 절차의 기여분

모델과 태스크 50개를 고정하고, 후보 패치를 만드는 방식과 고르는 방식만 바꿨습니다.

조건	해결률
단일 시도	54%
재현 기반 후보 선택	76% (38/50)

여기서 바뀐 것은 검색이 아니라 선택입니다. 하나의 워크트리를 재사용해 후보를 여러 번 만들고, 각 후보가 스스로 만든 재현 명령을 다른 후보들에 대해 교차 실행해서, 실행 결과로 순위를 매깁니다. 판정 신호가 모델의 자기 평가가 아니라 테스트 실행이라는 점이 이 절차의 전부입니다.

이 실험이 성립하려면 재현 → 수정 → 재검증 루프가 먼저 있어야 합니다. 실패를 재현하지 못하면 후보를 실행으로 가를 방법도 없습니다.

통제 실험 2 — 툴셋만 바꾼 A/B

코드그래프 검색이 값을 하는지는 다시 한 번 분리했습니다. 모델과 스캐폴드와 프롬프트를 전부 고정하고 에이전트에게 주는 검색 도구만 교체했습니다. 지표는 해결률이 아니라 파일 로컬라이제이션(수정해야 할 파일이 상위 5개 안에 들어오는가)입니다.

조건	file@5
텍스트 검색 기반	65.2%
코드그래프 검색	70.1% (n=465)

+4.9pp는 큰 숫자가 아닙니다. 중요한 것은 크기가 아니라 방향의 일관성입니다. 같은 A/B를 더 쉬운 SWE-bench Lite에서 돌리면 +1.1pp로 줄어들고, 별도의 파일 로컬라이제이션 벤치에서는 동률입니다. 그래프가 성능을 떨어뜨린 구간은 어디에도 없었습니다. 이득이 나는 곳은 저장소가 크고 이슈가 심볼 이름을 직접 부르지 않는 구간입니다.

이 결과를 어떻게 신뢰할 수 있게 만들었는가

실험 전에 가설과 기각 임계값과 “실패는 어떤 형태로 나타나는가”를 문서에 기록하고, 등록 시점의 커밋 해시를 함께 남겼습니다. 결과를 본 뒤에 기준을 옮기지 않았다는 사실을 나중에 검증하기 위해서입니다.
지표가 개선되어도 원인을 설명할 수 없으면 채택하지 않았습니다.
재현에 실패한 이득, 두 번째 독립 실행에서 유지되지 않은 p값, 오라클과 대조한 뒤 되돌린 커밋을 전부 별도 기록으로 남겼습니다. 이 사이트의 다른 연구 기록 세 편이 그것입니다.

하니스에서 배운 것

첫 전수 실행은 476/500 지점에서 외부 SIGKILL로 죽었습니다. 예측 결과를 저장소 단위로 체크포인트하고 있었기 때문에, 하나의 저장소로 231개가 묶여 있던 django의 메모리 내 패치 약 207개가 그대로 사라졌습니다. 약 27시간과 700달러어치의 연산이었습니다.

수정은 두 가지입니다. 체크포인트를 인스턴스 단위로 내려 패치를 만드는 즉시 기록하고, 하나의 저장소를 여러 프로세스로 쪼갤 수 있게 했습니다. 재실행한 django는 6시간에 오류 0건으로 끝났습니다. 스코어링 배치를 반복해서 깨뜨리던 간헐적 네트워크 단절에는 대기 후 재시도 래퍼를 붙이고 이미지를 미리 받아두어, 테스트 실행이 네트워크에 의존하지 않게 했습니다.

체크포인트 단위를 잘못 잡으면 평소에는 아무 증상이 없다가 가장 비싼 순간에만 손실이 나옵니다. 27시간을 쓰기 전에는 이것이 설계 결함으로 보이지 않았습니다.

공개하지 않는 것

코드그래프의 스키마, 검색 시딩과 랭킹 알고리즘, 에이전트 실행 모델의 구체적인 구현은 제품의 핵심 자산이라 적지 않았습니다. 위에 적은 것은 무엇을 측정했고 무엇을 통제했는지까지입니다.

측정 기록

항목	값
실행 시점	2026년 6월, 전수 1회 및 django 재실행 1회
채점 하니스	공식 `swebench` 4.1.0 — 공식 네임스페이스 이미지, 환경 단위 캐시
아키텍처	x86_64 표준 프리빌트 이미지 (리더보드 기준 아키텍처), 84개 배치로 분할
모델	`anthropic/claude-opus-4.8` (OpenRouter 직결)
검색	어휘 + 밀집 임베딩(3,072차원) + 코드그래프 Personalized PageRank 융합, 제품과 같은 코드 경로
루프	Docker 안에서 재현 → 수정 → 재검증, 후보 5개 생성 후 실행 기반 선택
패치 생성 비용	약 $1,800–1,900 (크래시로 소실된 약 $700 포함). 채점은 연산만 사용
통제 실험 1	같은 하니스, 50개 서브셋, 모델 고정, 선택 절차만 교체
통제 실험 2	SWE-bench Verified n=465에서 file@5, 도구만 교체

측정 기록 원본은 Consilience 저장소의 docs/archive/verified-500-report.md(전수 실행), docs/code-graph-eval/benchmark-paper.md(툴셋 A/B), docs/details/ultra-mode-implementation-plan.md(선택 절차)에 있습니다. 하니스는 src-tauri/src/code_graph/eval_live.rs와 eval_bench.rs이고, 두 통제 실험은 이 하니스에서 모델만 바꿔 돌렸습니다.

통제 실험 2의 n=465는 500이 아닙니다. 해당 실행은 완료 직전에 중단됐고, 집계 파일 대신 로그에서 인스턴스 단위 file@5를 복원했습니다. @1과 @10, 함수 단위 지표는 남아 있지 않습니다.