SlopCodeBench 2026년 10월 결과 — Astra가 strict pass rate 1위, XHigh는 비용 대비 일관된 개선을 보이지 않았습니다

AI 요약

SlopCodeBench는 코딩 에이전트가 단계별 요구사항을 받아 기존 프로그램을 수정하는 과정을 평가합니다. 각 단계에서 새 기능뿐 아니라 이전 기능의 회귀 테스트도 통과해야 합니다. 이번 평가는 36개 문제와 설정별 196개 체크포인트를 사용했습니다. 앞선 평가가 일부 문제만 다뤄 전체 결과와 직접 비교하기 어려웠던 만큼 이번에는 전체 벤치마크 결과를 제시합니다. 재현 설정은 고정된 v1.0 카탈로그, 기본 just-solve 프롬프트, seed 42, any-case 통과 정책, Python 3.12와 uv를 사용하는 Docker입니다.

통과율과 비용

가장 엄격한 지표인 strict pass rate는 체크포인트의 모든 테스트와 회귀 테스트를 통과한 비율입니다. GPT-6 Astra XHigh가 196개 중 32개를 통과해 16.33%로 1위를 기록했습니다. GPT-6 SOL Medium은 30개, GPT-6 Astra Medium과 GPT-6.1 SOL Medium은 각각 29개를 통과했습니다. Opus 5.5 Medium은 28개로 14.29%였고, Opus 5.5 XHigh는 25개로 12.76%였습니다. 비교적 느슨한 core pass rate에서는 Opus 5.5 Medium이 73.98%로 가장 높았습니다.

Medium과 XHigh를 모두 실행한 세 모델에서는 XHigh 비용이 2.11~4.22배였습니다. Opus 5.5는 strict 통과가 28개에서 25개로 줄었고, GPT-6 SOL은 30개에서 26개로 줄었습니다. Astra만 29개에서 32개로 늘었습니다. 작성자는 설정별 실행이 한 번뿐이라 실행 간 변동을 분리할 수 없으며, 이 결과만으로 높은 reasoning effort가 코딩 성능을 떨어뜨린다고 결론 내릴 수는 없다고 설명합니다. 이번 실행의 기록 비용은 GPT-6.1 SOL Medium의 178.51달러부터 Fable 5.1 XHigh의 1,550.07달러까지였습니다.

체크포인트 통과와 문제의 마지막 단계까지 완성하는 결과도 다릅니다. 마지막 체크포인트의 strict 통과는 Astra XHigh와 GPT-6.1 SOL Medium이 각각 36개 중 3개였습니다. Opus 5.5 Medium은 마지막 체크포인트를 strict하게 통과한 문제가 없었습니다. Astra XHigh는 마지막 단계에서 실패한 테스트 케이스가 1,435개였고 그중 1,178개가 회귀 테스트였습니다.

생성 코드의 slop 측정

작성자는 모델이 남긴 임시 파일과 스크래치 코드도 코드베이스 품질의 일부로 보고 분석에 포함했습니다. 설치 패키지와 가상환경, 캐시 폴더는 제외했습니다. slop 스캐너는 파일 안의 패턴과 반복 코드를 검사하고, 전체 소스 라인 중 규칙에 걸린 라인의 비율을 계산합니다. 여러 규칙이 한 줄을 잡아도 한 번만 셉니다. 전체 28개 문제의 라인 수를 합산한 뒤 비율을 구하므로 큰 프로그램에 더 큰 가중치가 실립니다.

Opus 5.5 XHigh의 slop 비율은 77.75%로 Opus 5.5 Medium의 94.25%보다 낮았습니다. 반면 strict 통과 수는 XHigh가 더 적었습니다. 임시 파일 필터를 적용해도 Opus Medium은 slop 비율이 92.90%로 가장 높았습니다. 이 필터는 _work, tmp, temp, scratch, generated, build, dist 폴더와 특정 생성 파일을 제외합니다. 실제 이번 실행에서 제외된 것은 Opus Medium의 dynamic_buffer 결과에 있던 _work 파일 45개뿐이었습니다. 작성자는 기존 200개 이상의 linter 규칙이 2026년 3월 이전 에이전트 코드에서 수집한 패턴을 바탕으로 해 새 모델의 유지보수 문제를 놓칠 수 있다고 덧붙였습니다. 함수별 평균 복잡도는 Fable이 3.57로 가장 낮았고 GPT-6 SOL Medium이 11.70으로 가장 높았습니다. 다만 helper function을 늘리면 평균 복잡도가 낮아져도 코드 변경이 쉬워진다고 단정할 수 없다고 설명합니다.

Hacker News 반응

• @hedgehog — 제가 직접 대표성 있는 일부 문제를 실행할 방법이 있을까요? (수정: 작성자가 재현 설정과 문제 저장소를 안내한 내용을 덧붙였습니다.)
  • @dhorthy — 일부 문제로 시작했지만 대표성이 있다고 보지는 않았습니다. 예를 들어 6개 문제로 만든 부분집합에서 Fable은 33%를 기록했지만 전체 문제에서는 14~15%에 가까웠습니다.
• @a3w — 36개 테스트가 있으니 0개부터 36개까지 통과할 수 있습니다. 해결 정확도를 유효숫자 다섯 자리로 제시하는 건 데이터의 성격에 맞지 않습니다. 데이터 과학도 그래서는 안 됩니다.
• @throwaway219450 — Astra는 코드를 잘 쓰지만 줄바꿈을 거의 생략하는 등 읽기 어려운 코드 골프를 만들 때가 있습니다. 요청한 대로 동작하더라도 지저분합니다. 기존 제약을 지키면서 요구사항을 만족하는 최소 diff 같은 지표가 있어야 한다고 생각합니다.
  • @ttul — 줄바꿈 문제는 Prettier 같은 포매터로 쉽게 고칠 수 있습니다. 이런 사용성 문제는 결정론적인 도구가 맡는 편이 낫습니다.
• @meffmadd — 원시 출력도 공개된 곳이 있나요? SlopCodeBench 결과를 조사하고 있는데 더 크고 대표성 있는 데이터셋이 있으면 도움이 되겠습니다.
• @mordae — 실제 프로젝트의 이슈를 패치로 반복 해결하게 하고 테스트 통과뿐 아니라 리팩터링 유사도를 평가하는 모델을 훈련하는 곳은 없나요?
• @theodorewiles — 유지보수성과 코드 장황함 지표를 개선하는 simplify skill을 만들었습니다. 하지만 벤치마크에서는 테스트 통과율의 개선 추세를 확인하지 못했습니다. 유지보수성 지표에 관해 생각할 거리를 줍니다.
• @softwaredoug — LLM의 slop은 지나치게 방어적인 프로그래밍에서 자주 나옵니다. 코드를 제거하고 단순화하기보다 회귀를 막으려고 복잡한 해법을 덧붙이는 경향이 있습니다. 사람이 코드를 읽고 복잡성을 물으며 불필요한 요구사항을 덜어내도록 이끌어야 합니다.
  • @skrtskrt — 기존 구조를 작은 구성요소로 나눠 새 요구사항과 기존 사용 사례를 함께 처리하기보다 새 코드를 덧대 우회하는 경향도 있습니다.
• @0xbadcafebee — 변경 뒤 의도하지 않은 결과가 생기는 문제는 소프트웨어 개발에서 익숙합니다. 모델이 뛰어난 프로그래머가 되길 기다리기보다 프레임워크와 개발 절차, 설계 패턴 같은 구조를 강제하는 하네스가 필요합니다.
• @visiondude — 코드가 지저분한지 수치화하는 방식은 흐릿하고 조작하기 쉽다고 봅니다. 가장 좋은 코드는 이해하기 쉽고 성능도 같은 수준으로 갖춘 코드인데, 일부 지표는 helper function을 추가하는 식으로 그 기준과 어긋날 수 있습니다.

원문: Hacker News / 번역·요약: Trawling