SlopCodeBench 10월, 최고 16% — 테스트 없이 고치면 기존 기능이 깨지고, '5배 깨끗'은 과장이었다
요구사항이 바뀌어도 기존 기능을 지키는지 보는 SlopCodeBench 10월 결과를 요약하고, AI가 내게 빙의해 테스트 비공개 조건과 slop 지표의 한계를 따져 물었다.
HumanLayer의 Dex Horthy가 최신 코딩 모델들을 SlopCodeBench 전체에 돌려 본 10월 보고서를 읽었다. 질문은 AI가 내게 빙의해서 했고, 숫자가 실제로 무엇을 재는지에 집중해 세 가지를 물었다.
HumanLayer의 Dex Horthy가 최신 코딩 모델들을 SlopCodeBench에 돌려 본 10월 보고서입니다. SlopCodeBench는 요구사항이 단계별로 바뀌는 상황에서 AI가 기존 코드를 고쳐 나가며 예전 기능까지 지켜 내는지 보는 벤치마크예요. 문제 36개, 체크포인트 196개 전체를 썼습니다.
- 엄격 통과율: 새 기능과 이전 기능 테스트를 모두 통과한 비율인데, 최고가 GPT-6 Astra(XHigh)의 16.3%입니다. 5월 GPT-5.5의 14.8%보다 1.5%포인트 올랐을 뿐이에요. 이전 기능 테스트를 빼고 보는 '핵심 통과율'은 66~74%라, 새 기능은 대체로 맞히지만 기존 기능을 깨뜨리는 게 문제라는 뜻입니다.
- 추론 강도: 추론을 더 많이 하는 XHigh 설정은 Medium보다 비용이 2.1~4.2배 들었지만, 세 쌍 중 Astra만 점수가 올랐습니다. Opus 5.5는 오히려 28개에서 25개로 줄었어요. 저자도 모델·설정마다 한 번씩만 돌린 결과라 우연한 차이일 수 있다고 인정합니다.
- 코드 품질: 지저분한 패턴(slop)이 걸린 줄의 비율은 Opus 5.5 Medium이 94%로 가장 높고 XHigh가 78%로 가장 낮았습니다. 통과 개수와 코드 깔끔함이 반대로 움직인 거예요. 다만 품질 검사 규칙이 올해 초 모델 기준으로 만들어져 새 모델의 나쁜 패턴은 못 잡을 수 있다고 덧붙입니다.
| 설정 | 엄격 통과 | 추정 비용 |
|---|---|---|
| GPT-6 Astra XHigh | 32/196 | $759 |
| GPT-6.1 SOL Medium | 29/196 | $179 |
| Opus 5.5 Medium | 28/196 | $193 |
| Fable 5.1 XHigh | 26/196 | $1,550 |
저자의 결론은 "코드베이스를 오래 유지하는 능력은 나아지고 있지만, 다들 말하는 것만큼 빠르지는 않다"입니다.
실패한 테스트 대부분이 회귀 쪽이라는데, 에이전트는 작업할 때 이전 체크포인트 테스트를 볼 수 있어? 실무에선 CI가 기존 테스트를 다 돌려주니까, 그걸 안 주고 잰 거면 모델 실력보다 작업 환경을 잰 숫자 아냐?
맞아요, 에이전트는 테스트를 전혀 못 봅니다. 논문에 "에이전트는 명세 문장과 그 안의 예시만 보고, 실제 테스트나 그 결과는 절대 보지 못한다"고 적혀 있어요. 체크포인트마다 받는 건 다음 세 가지뿐입니다.
- 새 명세와 예시(CLI·API로 겉에서 보이는 동작만 정의)
- 직전 체크포인트까지 자기가 짠 코드
- 그뿐이고, 이전 대화 맥락은 넘겨주지 않음
회귀 테스트는 채점할 때만 돌아갑니다. "이전 체크포인트의 모든 테스트"를 다시 돌려 보는 방식이에요.
그래서 지적하신 대로 이 숫자는 CI라는 안전망이 없을 때의 실력입니다. 다만 논문은 이걸 일부러 설계한 것으로 봅니다. 숨겨 둔 테스트를 맞히게 하는 게 아니라, 명세만 보고 기존 동작을 스스로 지켜 내는지 보려는 거예요. 에이전트가 직접 테스트를 짜서 돌리는 것도 막지 않았습니다. 기사의 품질 분석에 "남긴 테스트 파일"이 나오는 것도 그래서입니다.
실무처럼 기존 테스트를 주고 CI를 돌렸다면 엄격 통과율이 꽤 올라갔을 가능성이 높습니다. 다만 얼마나 오를지는 이 벤치마크에서 재지 않아 알 수 없어요. 그 대신 이 결과는 "테스트가 없는 코드를 에이전트에게 맡기면 기존 기능이 쉽게 깨진다"는 경고로는 그대로 유효합니다.
출처: SlopCodeBench 논문
테스트를 안 주니까 에이전트가 직접 테스트나 임시 코드를 짜야 하는데, 그게 남아 있으면 slop으로 잡히잖아. 그럼 스스로 검증을 많이 할수록 품질 점수는 깎이는 구조 아냐?
구조적으로는 그렇습니다. 기사도 이걸 알고 일부러 그렇게 정했어요.
저자는 처음에 임시 파일을 품질 점수에서 빼려고 했습니다. 그런데 공동 연구자 Gabe가 "코드를 읽지 않을 거라면, 모델이 코드베이스에 남긴 쓰레기 양 자체를 재야 한다"고 반대했어요. 그래서 테스트·임시 코드·생성된 사본도 모두 점수에 넣었습니다. 별도로 tmp·scratch 같은 폴더를 뺀 점수도 계산했지만, 테스트는 일괄로 빼지 않았습니다.
그 결과 기사 데이터에서도 비슷한 모양이 보입니다.
| Opus 5.5 Medium | Opus 5.5 XHigh | |
|---|---|---|
| 엄격 통과 | 28 | 25 |
| slop 비율 | 94% (임시 폴더 빼면 93%) | 78% |
| 남긴 코드 | 21.7만 줄로 최다 (그중 4.1만 줄이 작업 폴더) | — |
검증 코드를 많이 남긴 쪽이 통과는 더 하고 점수는 나쁘게 나온 셈이라, 말씀하신 가설과 맞아떨어집니다. 하지만 기사는 테스트 코드만 따로 떼어 세지 않아서 이게 원인인지는 확인할 수 없습니다.
실무 관점에서 보면 이 지표가 깎는 건 검증 자체가 아니라 뒷정리를 안 한 것입니다. 검증하고 나서 임시 코드를 지우거나 정식 테스트로 정리하면 됩니다. 다만 쓸모 있는 테스트까지 감점되는 건 지표의 한계가 맞아요. 기사도 2부에서 더 따져 보겠다고 했습니다.
코드의 78~94%가 slop으로 걸리는데 이 지표가 모델을 제대로 구분하긴 해? 기사에서 XHigh가 "~5배 깨끗하다"고 한 것도 안 걸린 줄 비율(22% 대 6%)을 비교한 거라 과장 아냐?
네, 과장에 가깝습니다. 기사 숫자로 직접 계산해 보면 이렇습니다.
| 기준 | Opus XHigh | Opus Medium | 배수 |
|---|---|---|---|
| slop이 걸린 줄 | 77.75% | 94.25% | 1.2배 |
| 안 걸린 줄 | 22.25% | 5.75% | 약 3.9배 |
| 안 걸린 줄 (임시 폴더 제외) | 22.25% | 7.10% | 약 3.1배 |
"~5배 깨끗하다"는 어느 기준으로 계산해도 나오지 않습니다. 가장 유리한 기준에서도 4배가 안 되고, 걸린 줄로 보면 1.2배 차이예요.
이 지표가 모델을 잘 구분하는지에도 의문이 남습니다.
- 기준이 느슨함: 규칙 하나라도 걸리면 그 줄은 slop으로 셉니다. 검사 하나가 함수 전체를 표시하기도 해서, 대부분의 코드가 걸리는 쪽으로 쏠리기 쉽습니다.
- 심각도 구분 없음: 몇 개 규칙에, 얼마나 나쁘게 걸렸는지는 따지지 않습니다.
- 큰 코드에 가중치: 줄 수로 합산해서, 코드를 많이 남긴 문제가 결과를 좌우합니다. 기사도 이전 글(문제별 평균)과 계산 방식이 달라졌다고 밝혔어요.
저자도 이 절 제목을 "code quality findings - blurry(흐릿하다)"로 달았습니다. 그러니 이 숫자는 "XHigh가 확실히 깨끗하다"보다는 "통과 수와 품질 지표가 엇갈린다" 정도로 읽는 게 안전합니다. 더 정성적인 분석은 2부에서 나온다고 합니다.
정리
- 엄격 통과율은 최고 16.3%(GPT-6 Astra XHigh)로 5월보다 1.5%포인트 올랐을 뿐이고, 추론 강도 XHigh는 비용만 2~4배 늘고 점수는 일관되게 오르지 않았다.
- 에이전트는 테스트를 전혀 못 보고 명세·예시·자기 코드만으로 작업한다. 그래서 이 숫자는 CI 안전망이 없을 때의 실력이고, 테스트를 줬다면 얼마나 오를지는 재지 않았다.
- 품질 지표는 남긴 테스트·임시 코드까지 감점한다. 검증 코드를 많이 남긴 Opus Medium이 통과는 많고 slop 비율은 높았지만, 원인인지는 확인할 수 없다.
- "XHigh가 ~5배 깨끗하다"는 기사 수치로 계산하면 안 걸린 줄 기준 약 3.9배, 걸린 줄 기준 1.2배라 과장에 가깝다. 저자도 품질 결과를 '흐릿하다'고 했다.
이 대화, 이어서 해 보기
글 주소와 함께 질문이 채워진 채로 열립니다.