Astra, SlopCodeBench에서 Opus 5.5를 앞서다: xhigh는 해롭다
TMT참고: 이 글은 2026년 10월 보고서의 1부, 4분기 슬롭(slop) 현황입니다. @gorlanski와 SlopCodeBench 팀이 2부에서 분석 결과와 함께 슬롭 패턴을 더 정성적으로 깊이 파고든 내용을 공유할 예정입니다. SlopcodeBench에 관해 제가 이전에 쓴 글은 새로운 프런티어 벤치마킹과 fable 5, sol, kimi k3 벤치마킹을 참고하세요. 두 글 모두 SCB의 핵심 구조와 각 챌린지가 체크포인트로 나뉘는 방식을 더 깊이 다룹니다.
SCB 결과가 마지막으로 발표된 5월에 gpt-5.5는 slopcodebench에서 14.8%의 엄격 통과율(strict pass rate)을 기록했습니다. 이번 달 저는 프런티어 모델들을 같은 캠페인으로 돌렸고, 가장 높은 점수를 낸 모델은 16.3%를 기록한 gpt-6 astra였습니다.
SlopCodeBench란?
자세한 내용은 위 링크에 훨씬 많지만, 간단히 다시 짚어 보겠습니다. SlopCodeBench에서 모델은 하나의 코드베이스 안에서 연이은 코딩 과제를 수행합니다. 한 챌린지(challenge)를 이루는 3~8개의 체크포인트(checkpoint)를 모두 거치는 동안, 모델은 자신이 앞서 한 작업을 그대로 물려받습니다.
결과
이 벤치마크는 여러 가지 통과율을 보고하지만, 저희가 주목하는 것은 엄격 통과율입니다. 모든 회귀 테스트를 계속 통과하면서 모든 테스트 케이스까지 통과한 체크포인트가 몇 개인지를 나타냅니다. 이번에 테스트한 아래 프런티어 모델들의 엄격 통과율은 12.2~16.3% 범위였습니다.
- Opus 5.5
- Fable 5.1
- SOL 6 및 6.1
- Astra
- GLM 5.3
비교하자면, 이 벤치마크는 덜 엄격한 "핵심 통과율"(core pass rate)도 보고하는데, 이 모델들의 핵심 통과율은 65.8~74.0% 범위입니다.
여기서 제가 파고들 흥미로운 점이 하나 있습니다. 일부 최신 모델에서는 medium 추론 강도(effort)가 XHigh보다 좋은 성적을 냈습니다. 두 설정을 모두 실행한 세 쌍에서 XHigh의 비용은 Medium의 2.11~4.22배였는데, 가장 눈에 띄는 점은 opus 5.5가 xhigh보다 medium에서 더 좋은 성적을 냈다는 것입니다. (참고: 이 벤치마크에서 Astra/Sol 모델은 xhigh에서 *실제로* 더 좋은 성능을 내는 것으로 보입니다)
지난 몇 달 동안 저는 벤치마크의 일부만 돌렸습니다. 처음에는 문제 3개로 시작했고, 그다음에는 6개를 시도했습니다. 이번에는 설정마다 문제 36개, 체크포인트 196개입니다. 앞선 글들에서는 일부만 썼기 때문에, 그 결과와 비교해 성능이 나아졌는지 나빠졌는지는 측정할 수 없습니다. 전체 벤치마크를 쓰면 이번 결과를 공식 연구 결과와 비교할 수 있습니다. 또한 두 글 중 뒤의 글에서 나온 fable 5의 30% 점수는 흥미롭긴 하지만, 문제 36개 중 6개만 다룬 결과라서 여기서는 비교할 수 없습니다.
SCB 더 알아보기
SlopCodeBench는 코딩 에이전트에게 문제를 단계별로 줍니다. 에이전트는 프로그램을 작성하고, 새 요구 사항을 받고, 기존 코드를 수정합니다. 뒤쪽 체크포인트는 새 동작과 기존 동작을 모두 테스트합니다.
이렇게 하는 이유는 이 방식이 소프트웨어가 실제로 만들어지는 과정, 즉 만드는 동안 요구 사항이 불분명하고 계속 바뀌는 상황에 더 가깝기 때문입니다.
이 결과를 재현해 보고 싶은 분들을 위해 적어 두면, 저는 고정된 v1.0 카탈로그, 기본 just-solve 프롬프트, 시드 42, any-case 러너 통과 정책, 그리고 Python 3.12와 uv를 갖춘 Docker를 사용했습니다.
모델과 추론 강도 설정마다 한 번씩 실행했습니다. 각 체크포인트는 앞선 체크포인트의 코드 위에서 진행됩니다. 어떤 문제는 다른 문제보다 체크포인트가 많습니다. 모든 체크포인트는 통과율에 똑같이 반영되므로, 체크포인트가 많은 문제일수록 비중이 커집니다.
핵심 통과율과 엄격 통과율
- 엄격: 회귀(Regression) 범주를 포함해 모든 테스트 범주가 통과합니다.
- 핵심: 비어 있지 않은 핵심(Core) 범주의 테스트가 모두 통과합니다. 예를 들어 모델이 체크포인트 2에서 실패하더라도, ck2 테스트가 계속 실패한 채로 남아 있어도 이후 체크포인트에서는 핵심 통과를 받을 수 있습니다.
엄격 통과는 196개 중 24~32개입니다. 엄격 통과를 포함한 핵심 통과는 129~145개입니다. 음영 부분은 엄격 성공이 그만큼 더 있다는 뜻이 아닙니다.
이번 스냅숏에서 엄격 통과가 가장 많은 것은 Astra XHigh입니다. 하지만 SOL 6.1 Medium과의 차이는 체크포인트 2개뿐입니다.
Opus Medium은 핵심 성공에서 145/196으로 1위지만, 엄격 통과는 28/196에 그칩니다.
추론 강도를 높이면 비용은 늘지만, 결과가 꼭 나아지지는 않는다
세 쌍 모두에서 XHigh의 비용이 더 많이 들었지만, 엄격 성공이 오른 것은 Astra뿐입니다. 한 번씩만 실행한 결과로는 추론 강도를 원인으로 따로 떼어 낼 수 없습니다.
그렇다고 추론을 더 많이 하면 코딩이 나빠진다는 것이 증명되지는 않습니다. 이 결과가 말해 주는 것은 이번 실행에서는 추론 강도를 높이는 것이 엄격 통과를 더 얻는 믿을 만한 방법이 아니었다는 점입니다. 설정마다 캠페인을 한 번씩만 돌려서는 실행할 때마다 생기는 편차가 얼마나 되는지 알 수 없습니다.
엄격 점수 12.24~16.33% 범위 안에서, 기록된 비용 추정치는 178.51~1,550.07달러에 걸쳐 있습니다.
GPT-6.1 Medium의 기록된 비용이 178.51달러로 가장 낮고, 엄격 통과 수는 Astra Medium과 같습니다. Fable의 기록된 추정치는 그 8.68배 정도인데, 엄격 통과는 3개 더 적습니다.
최종 코드는 여전히 테스트에 실패한다
체크포인트에서 성공했다고 해서 마지막에 동작하는 프로그램이 남는 것도 아닙니다.
코드 품질 결과: 아직 흐릿하다
먼저, 모델들은 작업하는 동안 쓰레기 코드와 임시 코드를 잔뜩 남겼습니다. 처음에는 품질 점수에서 이런저런 임시 파일을 빼려고 했습니다. 하지만 gabe와 이야기를 나눴더니 좋은 지적을 해 주었습니다. 벤치마크는 모델이 코드베이스에 쓰레기를 얼마나 남기는지 측정해야 한다는 것입니다. 코드를 읽지 않을 거라면 측정이라도 해야 합니다. 테스트, 임시 코드, 생성된 사본도 주 프로그램이 아니라는 이유만으로 그냥 넘어가서는 안 될 것입니다.
다만 설치된 패키지, 가상 환경, 캐시는 고정된 폴더 이름 목록을 써서 두 분석 모두에서 제외했습니다.
주요 결과는 남아 있는 코드 전체를 분석합니다. 비교를 위해, 고정된 목록에 있는 임시 파일과 생성된 파일을 제거한 뒤 같은 지표도 계산합니다. 그러면 정리 작업이 수치를 얼마나 바꾸는지 볼 수 있습니다. 규칙과 실제 차이는 아래에 있습니다.
이 수치는 36개 문제 전체가 아니라 완료된 실행 10개 모두에 공통된 문제 28개를 다룹니다. 스캐너가 8개 문제에서 일부 파일을 제대로 측정하지 못했기 때문에(자세한 내용은 나중에 gabe가 올릴 업데이트에서 다룹니다), 모든 모델에서 그 문제들을 뺐습니다.
"이 코드 중 몇 %가 슬롭 규칙에 하나 이상 걸리는가"를 계산하는 방식을 큰 틀에서 설명하면 다음과 같습니다.
- 스캐너는 각 파일 안에서 슬롭 패턴과 반복되는 코드를 찾아 표시합니다.
- "커버리지"(Coverage)는 이 검사들이 표시한 소스 줄의 비율입니다.
- 여러 검사가 같은 줄을 표시하더라도 그 줄은 한 번만 셉니다.
- 검사 하나가 함수 전체를 표시할 수 있지만, 그렇다고 그 함수의 모든 줄이 문제라는 뜻은 아닙니다.
28개 문제 전체에서 표시된 줄과 소스 줄을 각각 합한 뒤, 나누어 비율을 구합니다. 따라서 규모가 큰 프로그램일수록 비중이 커집니다. 이전 글에서는 이와 달리 문제별 비율을 평균했습니다.
Opus XHigh의 슬롭 비율이 77.75%로 가장 낮고, Opus Medium은 94.25%입니다. 흥미롭게도 이번에도 엄격 통과는 xhigh 버전이 25개로, Medium의 28개보다 적습니다.
Opus 5.5 Medium이 엄격 통과는 더 많았지만, Opus 5.5 XHigh가 쓴 코드는 5배 가까이 더 깔끔했습니다.
이런 결과는 최신 모델에 새롭거나 다른 슬롭 패턴이 나타나기 때문일 수도 있습니다. 논문에 처음 실린 200개가 넘는 린터 묶음은, 2026년 3월 첫 발표와 2026년 5월 v1.1 발표에 앞선 몇 달 동안 에이전트가 작성한 PR에서 사람이 직접 골라 정리한 패턴에 맞춰져 있습니다. 새 모델들은 저희가 아직 린터를 만들지 않은 새로운 유지보수성 안티패턴을 만들어 낼 수도 있습니다(자세한 내용은 Gabe의 후속 글에서 다룹니다).
필터링한 뒤에도 코드를 가장 많이 남긴 것은 Opus Medium입니다. 테스트를 전부 제거하지는 않습니다.
필터링한 점수에서는 _work, tmp, temp, scratch, generated, build, dist라는 이름의 폴더와 *_pb2.py, *_pb2_grpc.py 파일을 뺍니다. 모든 실행에 같은 규칙을 적용합니다. 코드가 생성된 것처럼 보이는지 추측하지 않고, 테스트를 통째로 제외하지도 않습니다. 이번 실행에서 필터가 제거한 것은 _work 파일뿐이었습니다. 파일 45개, 소스 4만 1,265줄로, 모두 Opus Medium의 최종 dynamic_buffer 코드에서 나왔습니다. 그 결과 Opus Medium의 전체 소스는 21만 6,881줄에서 17만 5,616줄로 줄고, 슬롭 존재 비율은 92.90%로 떨어집니다. 그래도 슬롭 존재 비율은 여전히 가장 높습니다. 다른 모델에서는 필터가 아무것도 바꾸지 않습니다.
Fable의 평균 복잡도가 3.57로 가장 낮고, GPT-6 SOL Medium이 11.70으로 가장 높습니다.
예상하셨겠지만, 코드를 헬퍼 함수로 더 잘게 나누면 코드를 바꾸기 쉬워지지 않아도 평균 복잡도는 낮아질 수 있습니다. 코드가 적다고 늘 좋은 것도 아닙니다.
지표는 이 밖에도 훨씬 많습니다. 이 결과물의 정성적인 측면을 Gabe가 어떻게 보는지 무척 기대됩니다.
정리하며
전체 벤치마크는 제가 중요하게 여기는 지점에서 어렵습니다. 에이전트가 주요 동작을 맞히는 경우는 요구 사항이 바뀌는 동안 테스트한 동작을 모두 유지하는 경우보다 훨씬 많습니다.
시간이 지나도 코드베이스를 유지하는 능력은 나아지고 있습니다(5월에서 9월 사이 14.8%에서 16.3%로). 하지만 사람들이 믿게 하려는 것만큼 빠르지는 않습니다. 앞으로도 한동안은 사람이 유지보수를 계속 맡아야 할 것 같습니다.
참고: 이 글은 2026년 10월 보고서의 1부, 4분기 슬롭 현황입니다. Gabe와 SlopCodeBench 팀이 2부에서 분석 결과와 함께 슬롭 패턴을 더 정성적으로 깊이 파고든 내용을 공유할 예정입니다.
