SlopCodeBench에서 Opus 5 성능 측정

이전에 다음과 같은 내용을 작성한 적이 있습니다:

완전히 사실은 아니었습니다. 저는 좋은 리드(lede)를 숨기는 것보다 더 좋아하는 것은 없습니다.

지난 금요일에 UW Madison의 @GOrlanski 연구실에서 나온 비교적 새로운 (2026년 3월) 장기 호라이즌 코딩 벤치마크인 SlopCodeBench를 깊이 파고들었습니다. 이 벤치마크는 제가 코딩 벤치마크에 대해 가장 거슬리는 점, 즉 '더 크다'고 주장되는 복잡한 벤치마크조차도 전체 문제를 처음부터 노출한다는 점을 다루고 있습니다:

반면, SlopCodeBench의 각 도전 과제는 여러 개의 '체크포인트(checkpoints)'를 가지고 있습니다. 모델은 전체 문제를 미리 알지 못하며, 새로운 요구 사항이 공개됨에 따라 시간이 지남에 따라 코드베이스를 진화시켜야 합니다.

좋은 논문입니다. 길지도 않습니다. 읽어보시는 것이 좋습니다.

이 벤치마크의 멋진 점은 **포화되지 않았다(unsaturated)**는 것입니다. 테스트 당시, 사용 가능한 최고 모델인 GPT-5.4와 Opus 4.6은 각각 11%와 17%의 엄격한 통과율을 기록했습니다.

금요일에 저는 세 가지 claude 모델(Opus 4.8, Sonnet 5, 그리고 Opus 5)을 SlopCodeBench의 하위 집합에 걸쳐 실행하고 6시간 동안 라이브로 지켜보았습니다. 기술적으로는 Opus 5가 승리했지만, 제 생각에는 어느 것도 아주 잘 수행하지 못했습니다. 곧 Fable과 5.6 Sol을 포함하여 더 많은 결과를 게시할 예정입니다.

주요 내용은 제가 실행한 이 벤치마크의 작은 하위 집합에서 Opus 5가 **24%**를 기록했다는 것입니다. 이는 원본 논문에서 Opus 4.6이 기록한 17%의 엄격한 통과율보다 크게 높지 않은 수치입니다. 테스트된 모든 모델은 각 도전 과제 과정에서 명확하게 증가하는 산만함(verbosity), 복잡성, 그리고 여러 가지 다른 코드 스멜 지표를 보였으며, Opus 5는 동일한 일련의 도전 과제 동안 Opus 4.8보다 다섯 배 많은 수의 함수/콜러블을 작성했습니다.

이 23% 통과율에 대한 저의 개인적인 해석은 SlopCodeBench가 마침내 제가 그저 느낌으로만 주장할 수 있었던 것에 대한 신호를 제공한다는 것입니다. 즉, 실제 형태를 갖춘 소프트웨어 엔지니어링 작업을 수행하는 데 있어, 한 번에 하나의 이슈를 구축하는 과정에서 오늘날의 모델들은 조향(steering) 없이는 전원을 끄고 돌릴 수 있다는 확신을 주기 어렵다는 것입니다.

저는 claude에게 레포지토리에서 문제 3개를 골라달라고 했고, 총 17개의 체크포인트(checkpoint)가 있었으며, 쉬움/보통/어려움 난이도로 분류된 문제가 혼합되어 있었습니다:

• circuit_eval —
  쉬움(8개 체크포인트) - database_migration —
  보통(5개 체크포인트) - dynamic_config_service_api —
  어려움(4개 체크포인트)

모든 17개 체크포인트에 대한 상세 설명은 끝부분의 부록(appendix)에 있지만, 여기에는 모두 넣지 않겠습니다.

그리고 저는 이 세 모델을 모든 모델에 대해 병렬로 실행했고, 각 체크포인트마다 새로운 컨텍스트 창(context window)을 사용했습니다. 모든 모델은 동일한 프롬프트를 받았고 claude 코드 하네스(code harness)에서 실행되었습니다.

제가 중요하게 생각하는 지표는 **엄격 패스(strict pass)**입니다. 즉, 이전 체크포인트에서 상속된 모든 회귀 테스트(regression test)를 포함하여 새로 추가되는 모든 것이 녹색으로 표시되어야 합니다.

모델이 체크포인트에 실패하는 경우는 솔루션에 **결함(defect)**이 있는 경우입니다. 결함은 모델의 출력을 가져와서, 실행용 CLI 또는 경우에 따라 API 서버 등을 사용하여, 생성된 진입점(entrypoint)을 대상으로 보류된 블랙박스 테스트(black-box test) 세트를 실행함으로써 감지됩니다.

• 모델이 ck1에 대한 코드를 작성합니다.
• 평가 하네스(Eval harness)가 ck1에 대해 블랙박스 테스트를 실행합니다.
• 모델이 ck2에 대한 코드를 작성합니다.
• 평가 시스템이 ck1과 ck2에 대한 블랙박스 테스트를 실행합니다.
• 등등

다시 말하지만, 엄격 패스 기준은 만약 모델이 체크포인트 4에서 무언가를 잘못 처리하면, 그 실패한 코드 부분이 다음 체크포인트로 전달되기 때문에 이후의 체크포인트를 통과할 수 없다는 것을 의미합니다 (물론 모델이 우연히 체크포인트 6에서 평가 시스템이 체크포인트 4에서 고장 났던 부분을 수정하는 경우를 제외하고는, 실제로는 이런 일이 발생하지 않았습니다).

모든 9개의 테스트 실행에서, 어떤 모델도 모든 것이 통과된 채로 어떤 도전 과제(challenge)의 끝까지 도달하지 못했습니다. 심지어

처음 두 시간 동안 Opus 5는 엄격한 통과(strict passes)를 기록한 유일한 모델이었습니다. 연속으로 세 번이나 성공했죠.

시간이 지나면서 상황은 변했습니다. Claude는 HTML을 부지런히 업데이트했습니다.

다른 모델들과 비교했을 때, Opus 5는 문제 1(circuit_eval)에서 기술적으로 더 나았습니다. 하지만 처음 세 개의 체크포인트를 통과한 후, 이후의 모든 솔루션에는 적어도 하나의 결함(실패 테스트 케이스)이 있었습니다.

만약 성공의 정의가 '결함 없이 최종 체크포인트에 도달하는 것'이라면, Opus 5는 세 문제 모두 실패했지만, 다른 모델들보다는 약간 덜 나쁜 결과를 보였습니다.

비용 대 결함 보고서에 대해서는 Claude 특유의 표현을 정말 싫어하지만, 이번에는 남기기로 했습니다:

모든 달러가 정확성을 구매했습니다. 아무도 충분히 사지 못했습니다.

(물론 이 작은 규모의 벤치마크만으로는 더 많은 비용 지출이 더 높은 통과율로 이어질 것이라고 단정적으로 말할 수 없습니다.)

엄격한 통과 측면에서, Opus 5는 네 번의 성공을 거두었습니다 (24% 통과율) (circuit_eval의 처음 세 개 체크포인트와 database_migration ck1).

Opus 4.8과 Sonnet 5 모두 한 번의 엄격한 통과(6% 통과율)를 기록했으며, 이는 Opus 5가 얻은 것과 같은 database_migration ck1이었습니다.

따라서 승리자는 17개 중 4개를 클리어했고, 그중 3개가 하나의 문제에 대한 시작 체크포인트였습니다. 보아하니 우리는 다음 세대의 모델을 위한 포화되지 않은 벤치마크를 가지고 있는 것 같습니다. @GOrlanski와 팀에게 수고하셨습니다.

저는 아직 '슬롭(slop)을 제거하는 것'에 완전히 설득되지는 않았습니다. 특정 코드베이스 체크포인트의 '유지보수성(maintainability)'을 결정론적으로 파싱하는 것이 아직 가능하지 않다고 생각하기 때문입니다. 하지만 흥미로우니 계속 지켜볼 가치는 있습니다.

코드 품질 메트릭은 주시할 만하며, 아마도 방향성은 맞습니다.

SlopCodeBench를 사용하면 다양한 품질 메트릭에 걸쳐 각 체크포인트 이후의 결과를 얻을 수 있습니다. 결과 파일에는 41개의 메트릭이 있습니다. 대략적으로 그룹화하자면:

size— 소스 라인, 파일, 함수, 메서드, 클래스, 스테이트먼트, 그리고 해당 체크포인트에서 추가 및 제거된 라인 수 complexity— 순환 복잡도(cyclomatic complexity) 평균, 최대값, 분산, '높음'과 '극심함' 범위에 속하는 함수 개수, 복잡도가 얼마나 집중되어 있는지, 최대 중첩 깊이, 그리고 평균 함수 길이 duplication— 클론된 라인 수, 그리고 소스 대비 클론 라인의 비율 decomposition— 단일 사용 함수(single-use functions), 사소한 래퍼(trivial wrappers), 미사용 변수, 심볼당 라인 수 rule violations— 린트 오류(lint errors) 및 자동 수정 가능한 오류 개수, 테스트 슬롭 규칙에 대한 ast-grep 히트 수, 그리고 플래그가 지정된 라인의 비율 verbose dependency graph— 전파 비용(change가 얼마나 멀리 파급되는지), 순환 의존성 질량(cyclic dependency mass), 의존성 엔트로피(dependency entropy)(개인적으로 가장 흥미로운 부분)

이 모든 지표들은 각 체크포인트 이후의 현재 코드 상태를 사용하여 결정론적으로 계산됩니다.

아래 차트는 circuit_eval 챌린지에서 ck1 점수 대 ck8 점수에 대한 모델 간의 분산을 보여줍니다. (즉, 슬롭 지표가 챌린지 체크포인트 기간 동안 얼마나 증가했는지입니다.) 가장 흥미로운 점은 대부분의 지표들이 모델들을 구별해 주지 못한다는 것입니다.

이러한 측정치들이 반복 가능하고 판단을 위해 특정 모델을 사용하지 않는다는 점이 좋습니다. 하지만 이들 중 어느 하나와

그리고 특히, 너무 장황하다고 표시된 라인 수는 모든 모델의 궤적에서 증가하여, Opus 5에서도 ck1에서 약 65%에서 ck8까지 80%에 달합니다.

사실 저는 이것이 일부 코드 품질 측정 기준들이 다소 과도하게 공격적이라는 신호라고 말하고 싶습니다. 저희는 이 규칙 세트를 타입스크립트 모노레포에 적용해 보았지만, 현재 slop-code-bench 감지기는 파이썬 전용입니다.

그래서 5.6-Sol에게 타입스크립트를 위한 하위 규칙 세트를 만들게 했지만, 76개의 슬롭 감지기(SCB 파이썬 라이브러리의 200개 이상과 비교)밖에 나오지 않았습니다. 하지만 방향성을 제시하는 몇 가지 발견을 했습니다. Opus 5가 lights-off로 생성한 솔루션은 저희의 99%-AI-생성되었지만 신중하게 검토된 타입스크립트 모노레포보다 kLOC당 슬롭 트리거가 11배 이상 많았습니다 (이는 1000% 증가입니다).

분명히 이 발견에는 많은 별표(규칙이 적고, 동등성을 검토하지 않았음 등)가 붙지만, 흥미하다고 말할 수 있는 것은 분명합니다.

또 다른 흥미로운 데이터 포인트는 Opus 5가 다른 두 모델보다 5배 더 많은 함수를 작성했다는 것입니다. 하지만 Opus 4.8이 단일 사용 함수(그 함수의 거의 50%가 정확히 한 번 호출됨)의 비율을 더 높게 기록했습니다. 그리고 Sonnet 5의 단일 사용 함수 비중은 71.5%로 가장 높습니다.

솔직히 말해서, 작은 함수가 많다는 것이 나쁘다고 생각하지 않습니다. 요즘에는 어느 정도는 반신반의하지만, 예전에는 열렬한 Clean Code 지지자였습니다. 작고 설명적인 함수 이름이 많은 주석보다 훨씬 낫습니다, 뭐 그런 식이죠.

저는 약 1년 동안 모델들이 시간이 지남에 따라 코드베이스 품질을 저하시키고 있다고 말해왔는데, 주로 느낌에 의존했습니다. 하지만 이제 데이터가 있습니다.

어떤 모델도 체크포인트 전반의 복잡성 증가 없이 모든 도전을 통과하지 못했습니다. Opus 5가 평균 복잡성은 가장 낮지만, 함수는 2000개를 작성했습니다. 여기에는 상충 관계가 있습니다: 작은 함수가 많은지 아니면 큰 함수가 적은지. 저는 이 복잡성 지표들 중 어느 것도 단독으로 설 수 없다고 생각하지만, 일종의 종합적인 신호를 제공합니다.

sonnet과 Opus 4.8은 개별 함수를 재배치하기보다는 더 크게 만듦으로써 도전 과제 체크포인트의 증가하는 복잡성에 대응했습니다. Opus 4.8은 8개 체크포인트에 걸쳐 최대 70%까지 증가했으며, 가장 낮은 성능을 보인 단일 함수는 순환 복잡도(cyclomatic complexity)가 93에 달했습니다.

중복성(Duplication)이 그들이 갈라지는 지점입니다. Opus 4.8은 4.6%에서 16.8%로 증가하며, ck3에서 변곡점을 보입니다. 이는 새로운 요구사항이 초기 설계와 충돌하기 시작하는 대략적인 지점입니다.

참고: circuit_eval의 처음 세 가지 체크포인트가 요청하는 사항은 다음과 같습니다 (모든 도전 과제에 대한 전체 목록은 마지막 부록을 참조하세요):

ck1— --help, --version이 있는 CLI, JSON 출력 모드, 그리고 .circ 회로 파일을 구문 분석하고 유효성을 검사하는 check 명령어가 필요합니다. 모든 신호는 단일 비트입니다.ck2— eval 명령: 회로에 일부 입력을 전달하여 출력을 받습니다. 여전히 신호당 하나의 비트이며, 표준 불리언 연산자만 사용됩니다.ck3— 신호가 **벡터(vectors)**가 됩니다. data 대신 data[7:0]와 같은 형태를 사용하며, 슬라이싱, 인덱싱, 연결(concatenation), 새로운 연산자, 그리고 모든 피연산자에 대한 너비 확인이 추가됩니다.

결국 여섯 줄 중 한 줄은 다른 줄의 복사본입니다. 나머지 두 모델은 같은 구간에서 성능이 하락했습니다.

하지만 Opus 5는 기본적으로 평탄하여 2.41에서 2.64 사이를 유지합니다. 저는 이전에

즉, 유지보수가 어려워지는 코드베이스는 후반 단계에서 실패하는 체크포인트를 유발할 수 있으므로, 높은 엄격 통과율(strict pass rate)은 모델이 유지보수 가능한 코드베이스를 구축하는 데 능숙하다는 신호가 됩니다.

Fable이나 Sol 같은 최첨단 모델(frontier models)들이 전문가 수준의 디버거이자 리버스 엔지니어임이 입증되면서, 비용/시간/토큰 메트릭을 통합하는 것이 시간이 지남에 따라 더욱 중요해질 수 있습니다. Fable과 Sol 같은 최첨단 모델들은 아마도 가장 엉망인(NASTIEST) 코드베이스에서도 작업을 수행할 수 있겠지만, 저는 잘 구조화된(well-factored) 코드베이스가 미래 문제에 대해 더 짧고 토큰 효율적인 해결책을 도출하는 경향이 있을 것이라고 추측합니다.

그리고 '8개 체크포인트를 거쳐 전체 기능을 구축하는 것'은 '15분 SWE-bench 다국어 문제를 해결하는 것'보다 훨씬 느리지만, 사람이 개입하지 않은 상태에서 실행될 수 있고 마지막에 결정론적 동작 검증기(deterministic behavior verifiers)의 대상이 됩니다. 따라서 제 생각에는 다른 모델이 이 코드가 깨끗하다고 생각하는지 여부 같은 것보다 훨씬 더 나은 오라클입니다.