2026년 10월 15일 - Dex Horthy (Gabe Orlanski 기여)
참고: 이 글은 2026년 10월 작성된 내용의 파트 I입니다. Gabe과 SlopCodeBench 팀이 분석 및 슬롭 패턴에 대한 보다 정성적인 심층 분석을 Part II에서 공유할 예정입니다.
SlopcodeBench에 대한 저의 이전 글들은 benchmarking-opus-5-on-slop-code-bench.md와 benchmarking-sol-fable-kimi-on-slop-code-bench.md를 참고하십시오. 두 글 모두 SCB의 핵심 구조와 각 챌린지가 어떻게 체크포인트로 나뉘는지에 대한 심층 분석을 포함하고 있습니다.
SCB가 마지막으로 발표된 지난 5월, gpt-5.5는 slopcodebench에서 **14.8%의 엄격 통과율(strict pass rate)**을 기록했습니다. 이번 달에는 제가 최신 모델들로 동일한 캠페인을 실행했으며, 가장 높은 점수를 받은 모델은 gpt-6 astra였고, **16.3%**를 기록했습니다.
벤치마크는 여러 다른 통과율을 보고하지만, 우리가 중점을 두는 것은 **엄격 통과율(strict pass rate)**입니다. 즉, 모델이 모든 테스트 케이스를 통과하면서도 회귀 테스트(regression tests)를 모두 통과한 체크포인트의 개수입니다. 현재 테스트된 최신 모델들의 엄격 통과율은 12.2-16.3% 범위에 있었습니다:
- Opus 5.5
- Fable 5.1
- SOL 6 및 6.1
- Astra
- GLM 5.3
비교를 위해, 이 벤치마크는
지난 몇 달 동안 저는 벤치마크의 일부를 실행했습니다. 처음에는 세 가지 문제로 시작했고, 그 다음에는 여섯 개를 시도했습니다. 이번에는: 36개의 문제와 설정당 196개의 체크포인트입니다. 이전에 하위 집합을 사용했기 때문에, 이전 하위 집합을 사용하여 개선 또는 감소를 측정할 수는 없습니다. 전체 벤치마크를 사용하면 이러한 결과를 공식 연구 결과와 비교할 수 있습니다. 또한, 앞서 언급된 두 가지 중 후자의 30% fable 5 점수가 흥미롭지만, 이는 단지 36개 문제 중 6개만 다루기 때문에 여기에서는 비교할 수 없습니다.
SlopCodeBench는 코딩 에이전트에게 문제를 단계적으로 제공합니다. 프로그램 코드를 작성하고, 새로운 요구사항을 받고, 기존 코드를 수정하는 방식입니다. 나중 체크포인트들은 새로운 동작과 이전의 동작 둘 다를 테스트합니다.
여기서 핵심 아이디어는 이것이 소프트웨어가 실제로 구축되는 방식, 즉 빌드 과정 중에 불분명하고 진화하는 요구사항에 더 가깝다는 것입니다.
이러한 연구 결과를 재현해 보고 싶은 분들을 위해 알려드립니다. 저는 고정된 v1.0 카탈로그와 기본 just-solve 프롬프트, 시드 42, any-case 러너 통과 정책, 그리고 Python 3.12 및 uv를 사용하는 Docker를 사용했습니다.
저는 각 모델과 노력 설정을 한 번씩 실행했습니다. 각 체크포인트는 이전 체크포인트의 코드를 기반으로 구축됩니다. 일부 문제는 다른 문제보다 더 많은 체크포인트를 가집니다. 모든 체크포인트가 통과율에 동등하게 기여하므로, 체크포인트가 더 많은 문제는 더 큰 비중을 갖습니다.
Strict: 회귀(Regression)를 포함하여 모든 테스트 카테고리에서 통과해야 합니다.Core: 공백이 아닌 Core 카테고리의 모든 테스트가 통과해야 합니다. 예를 들어, 모델이 체크포인트 2에 실패하더라도, ck2 테스트가 계속 실패하더라도 나중 체크포인트에서는 여전히 core pass를 받을 수 있습니다.
Strict 통과: 196개 중 24-32개. Core 통과 (Strict 포함): 129-145. 색이 칠해진 부분은 추가적인 Strict 성공을 의미하지 않습니다.
| Complete campaign | Strict passes | Strict rate | Core rate | Estimated cost |
|---|
| GPT-6 Astra XHigh | 32/196 | 16.33% | 69.39% | $758.62 |
| ... | | | | |
| Astra XHigh가 이 스냅샷에서 가장 많은 Strict pass를 기록했습니다. 하지만 SOL 6.1 Medium과의 격차는 단지 두 개의 체크포인트에 불과합니다. | | | | |
Opus Medium은 Core에서 145/196의 성공률을 보였지만, 엄격(strict)하게 통과한 건수는 28/196에 불과합니다.
XHigh는 세 쌍 모두에서 비용이 더 많이 들었으며, 엄격 성공률은 Astra에서만 증가했습니다. 이 단일 실행으로는 노력의 원인을 분리할 수 없습니다.
| Model | Strict: Medium → XHigh | Core: Medium → XHigh | Estimated cost multiplier |
|---|
| Opus 5.5 | 28 → 25 | 145 → 141 | 4.22x |
| ... | | | |
이것이 추론(reasoning)이 코딩에 해롭다는 것을 증명하는 것은 아닙니다. 이것은 더 높은 노력이 이 실행들에서 더 많은 엄격 통과를 보장하는 신뢰할 수 있는 방법이 아니었음을 의미합니다. 설정별로 하나의 캠페인만으로는 실행 간 변동성(run-to-run variation)이 얼마나 되는지 알 수 없습니다.
기록된 추정 비용은 12.24%16.33%의 엄격 점수 범위 내에서 $178.51$1,550.07에 걸쳐 분포합니다.
GPT-6.1 Medium이 $178.51로 가장 낮은 기록 비용을 보였으며, Astra Medium과 동일한 엄격 통과 횟수를 가졌습니다. Fable의 기록된 추정 비용은 약 8.68배 더 높았지만, 엄격 통과는 세 개 적었습니다.
체크포인트 성공률 역시 작동하는 프로그램으로 끝나는 것과 같지는 않습니다.
여기서는 각 문제의 마지막 체크포인트만 계산됩니다. 실패한 테스트 케이스는 별개의 버그가 아니며, 건너뛴(skip) 경우는 분리되어 기록됩니다.
| Complete campaign | Strict final checkpoints, out of 36 | Final failed test cases | Of those, Regression |
|---|
| GPT-6 Astra XHigh | 3 | 1,435 | 1,178 |
| ... | | | |
첫째, 모델들은 작업하는 동안 많은 쓰레기 코드(junk)와 스크래치 코드를 남겼습니다. 제 첫 반응은 품질 점수에서 임의의 임시 파일을 제거하는 것이었습니다. 하지만 gabe와 대화했는데, 그가 좋은 지적을 했습니다. 벤치마크는 모델들이 코드베이스에 얼마나 많은 쓰레기를 남기는지를 측정해야 합니다. 우리가 코드를 읽지 않는다면, 그것을 측정해야 합니다. 테스트, 스크래치 코드, 생성된 복사본은 주 프로그램이 아니라는 이유만으로 자유롭게 통과해서는 안 됩니다.
저는 설치된 패키지, 가상 환경(virtual environments), 캐시를 분석에서 제외하기 위해 고정된 폴더 이름 목록을 사용했습니다.
주요 결과는 남아 있는 모든 코드를 분석합니다. 비교를 위해 임시 파일 및 생성된 파일을 고정 목록으로 제거한 후에도 동일한 지표를 계산했습니다. 이를 통해 정리 작업이 수치에 얼마나 변화를 주는지 확인할 수 있습니다. 규칙과 실제 차이는 아래와 같습니다.
이 수치는 전체 36개 문제가 아닌, 동일한 28개 문제를 기준으로 모든 10회 실행을 거쳐 측정된 것입니다. 스캐너가 8개 문제의 일부 파일은 완전히 측정할 수 없었기 때문에(자세한 내용은 gabe의 추후 업데이트에서 다룰 예정), 해당 문제는 모든 모델에서 제외했습니다.
'이 코드 중 몇 %가 최소 하나의 slop 규칙을 트리거하는지'를 계산하는 방법에 대한 몇 가지 높은 수준의 세부 정보는 다음과 같습니다:
- 스캐너는 각 파일 내에서 slop 패턴과 반복되는 코드를 표시합니다.
- '커버리지(Coverage)'는 이러한 검사로 플래그가 지정된 소스 라인의 비율입니다.
- 여러 검사가 해당 라인을 플래그 지정하더라도 한 번만 계산합니다.
- 하나의 검사는 모든 라인이 문제가 아니더라도 전체 함수를 플래그 지정할 수 있습니다.
우리는 28개 문제에 걸쳐 플래그가 지정된 라인과 소스 라인을 합산한 다음, 백분율을 얻기 위해 나눕니다. 따라서 프로그램이 클수록 가중치가 더 높습니다. 이전 게시물에서는 각 문제의 백분율을 평균했습니다.
Opus XHigh는 slop 백분율이 **77.75%**로 가장 낮았으며, Opus Medium은 **94.25%**였습니다. 흥미롭게도, xhigh 버전이 다시 한번 더 엄격한 패스(strict passes)가 적었습니다: 25개 대 28개.
Opus 5.5 Medium보다 Opus 5.5 XHigh가 코드를 작성했을 때 ~5배 더 깨끗했습니다.
이는 새로운 모델이 새롭거나 다른 slop 패턴을 가지고 있기 때문일 수 있습니다. 그리고 논문에서 제시된 200개 이상의 린터(linters) 배터리는 2026년 3월에 원래 발표되었고 2026년 5월의 v1.1에서 나온 에이전트가 작성한 PR(Pull Request)에서 파생된 수작업으로 선별된 패턴 세트에 초점을 맞추고 있습니다. 이러한 새로운 모델은 우리가 아직 린터를 구축하지 않은 새로운 유지보수성 안티패턴을 생성할 수 있습니다(자세한 내용은 Gabe의 후속 게시물에서 다룰 예정입니다).
Opus Medium이 필터링 후 가장 많은 코드를 남깁니다. 테스트를 모두 제거하는 것은 아닙니다.
필터링된 점수의 경우, _work, tmp, temp라는 이름의 폴더는 제외합니다.
, scratch`
, generated
, build
, 또는 dist
, 그리고 *_pb2.py
및 *_pb2_grpc.py 파일을 포함합니다. 모든 실행에 동일한 규칙을 적용합니다. 코드가 생성된 것처럼 보이는지 추측하거나 테스트를 그룹으로 제외하지 않습니다. 이러한 실행에서 필터는 _work 파일만 제거했습니다:
45개 파일과 41,265개의 소스 라인, 모두 Opus Medium의 최종 dynamic_buffer 코드에서 가져왔습니다. 총량은 216,881개에서 175,616개 소스 라인으로 감소했으며, 슬롭(slop) 존재율은 92.90%로 떨어졌습니다. 여전히 슬롭 존재도 면에서 가장 빈번하게 나타납니다. 이 필터는 다른 모델들에게는 아무런 변화를 주지 않습니다.
Fable이 평균 복잡도가 3.57로 가장 낮고, GPT-6 SOL Medium이 11.70으로 가장 높습니다. 함수와 메서드 각각에 투표가 하나씩 부여됩니다.
예상하셨겠지만, 코드를 더 많은 헬퍼 함수로 분할하는 것이 코드를 변경하기 더 쉽게 만들지 않으면서 평균 복잡도를 낮출 수 있습니다. 코드 양이 적다고 항상 좋은 것은 아닙니다.
훨씬 더 많은 지표들이 있으며, 이 출력물들의 좀 더 정성적인 측면에 대한 Gabe의 의견을 듣게 되어 기대됩니다.
전체 벤치마크는 저에게 중요한 방식으로 어렵습니다. 에이전트들은 요구사항이 변경될 때 모든 테스트된 동작을 유지하는 것보다 주요 동작은 훨씬 자주 맞춥니다.
저희는 시간이 지남에 따라 코드베이스를 유지하는 능력이 향상되고 있지만(5월→9월 동안 14.8%에서 16.3%로), 누군가 믿게 될 만큼 빠르지는 않습니다. 당분간은 운영을 계속할 수 있을 것이라고 생각합니다.
참고: 이것은 2026년 10월 작성물의 파트 I입니다. Gabe와 SlopCodeBench 팀이 Part II에서 슬롭 패턴에 대한 분석과 좀 더 정성적인 심층 분석을 공유할 예정입니다.