Opus 5를 SlopCodeBench에서 벤치마킹하기

장기 코딩 벤치마크가 모델 성능 저하를 드러냄

현재 최첨단 LLM(예: Opus 5)은 요구사항이 변화함에 따라 코드베이스 품질을 유지하는 데 어려움을 겪기 때문에 아직 "조명 끈" 소프트웨어 엔지니어링에 신뢰할 수 없습니다. Opus 5는 이전 모델에 비해 약간의 개선을 보이지만, 결함을 도입하거나 기술 부채를 증가시키지 않고 복잡하고 다단계 코딩 과제를 완수하지 못합니다.

대부분의 전통적인 코딩 벤치마크는 전체 문제 설명을 한 번에 제공하여 순간적인 문제를 해결할 수 있는 모델에 보상을 줍니다. 반면에 SlopCodeBench(2026년 3월 UW Madison 연구진이 도입)는 모델이 여러 "체크포인트"를 통해 코드베이스를 진화시킬 수 있는 능력을 테스트합니다. 모델은 요구사항을 점진적으로 받으며, 새로운 사양에 맞게 기존 코드를 조정하도록 강요합니다—이는 실제 소프트웨어 엔지니어링을 반영하는 과정입니다.

Opus 5의 SlopCodeBench 성능

Opus 5는 SlopCodeBench의 일부에서 24%의 엄격 통과율을 달성했으며, 이는 원 논문에 보고된 Opus 4.6의 17%보다 약간 개선된 수치입니다. 그러나 모든 새로운 테스트가 통과하고, 상속된 회귀 테스트가 모두 녹색을 유지해야 하는 "엄격 통과" 지표는 상당한 제한점을 드러냅니다.

17개의 체크포인트(쉬움, 보통, 어려움 문제)에서 테스트를 수행한 결과는 다음과 같습니다:

• Opus 5: 4/17 엄격 통과 (24%)
• Opus 4.8: 1/17 엄격 통과 (6%)
• Sonnet 5: 1/17 엄격 통과 (6%)

높은 통과율에도 불구하고 Opus 5는 "비싼 장황함" 경향을 보였습니다. Opus 4.8보다 다섯 배 많은 함수를 작성했으며, 전체 코드 라인 수도 크게 늘어났습니다(다른 모델이 약 9,000줄인 반면 약 29,000줄). 이 중 상당 부분이 테스트에 사용되었지만, 생산 코드 양이 증가했음에도 정확도가 비례적으로 향상되지는 않았습니다.

"Slop" 측정: 코드 품질 및 복잡도

SlopCodeBench는 41개의 결정론적 지표를 사용해 코드베이스 퇴화를 추적하며, 모든 테스트 모델에서 시간이 지남에 따라 복잡도가 증가함을 보여줍니다. 이러한 지표는 크기, 복잡도(예: 순환 복잡도), 중복, 분해, 규칙 위반으로 구분됩니다.

코드 품질에 대한 주요 발견:

• Complexity Growth: 어떤 모델도 체크포인트를 거치면서 복잡도를 증가시키지 않고 과제를 완수하지 못했습니다. Opus 4.8은 가장 극심한 퇴화를 보였으며, 최악의 함수가 순환 복잡도 93에 도달했습니다.
• Code Duplication: Opus 4.8은 새로운 요구사항이 초기 설계와 충돌하면서 중복률이 4.6%에서 16.8%로 상승했습니다. Opus 5는 비교적 평탄하게 유지되었으며(2.41%에서 2.64%로), 구조적 변화를 처리하는 능력이 약간 개선된 것으로 보입니다.
• Slop Density: 대부분의 코드 라인이 "slop rules"(장황함 및 부적절한 패턴에 대한 지표)를 위반했습니다. 세 문제 전체에서 Opus 5의 라인 중 93%가 표시되었습니다. 인간이 검토한 AI 생성 TypeScript 모노레포와 비교했을 때, Opus 5의 "조명 끈" 생성 코드는 kLOC당 슬롭 트리거가 11배 이상 많았습니다.

유지보수 가능한 AI 코드로 가는 길

SlopCodeBench에서 높은 실패율은 코드베이스를 유지하는 능력이 단일 코딩 작업을 해결하는 능력과 별개의 기술임을 시사합니다. 소프트웨어 품질 신호를 개선하기 위해 저자는 "인계" 평가를 제안합니다: 최첨단 모델(예: Opus 5 또는 Fable)이 처음 N개의 체크포인트를 작성하고, 이후 더 작고 "덜 똑똑한" 모델(예: Sonnet 5)이 체크포인트 N+1을 성공적으로 구현할 수 있는지 테스트합니다.

작은 모델이 큰 모델의 작업을 기반으로 구축하지 못한다면, 이는 큰 모델이 깨끗하고 유지보수 가능한 아키텍처를 유지하지 못했음을 강력히 나타냅니다.

커뮤니티 관점 및 반론

실무자들 간의 논의에 따르면, 결과는 모델의 순수한 능력뿐만 아니라 에이전트 하네스와 시스템 프롬프트에 의해 영향을 받을 수 있다고 합니다.

"에이전트가 모든 것을 수정할 수 있을 때 Slop이 누적됩니다. 따라서 에이전트를 하나의 시점에만 제한하고, 제자리에서 편집하기보다 옆에 추가하도록 하면 모델 선택보다 더 큰 영향을 미칩니다."

다른 사용자들은 Opus 5가 속도와 토큰 효율성 측면에서 4.8보다 개선되었지만, 이전 버전이나 Fable과 같은 특화 모델에서 보였던 "혁신적인" 도약은 아닐 수 있다고 지적했습니다.

벤치마크 과제 요약

도전 과제	난이도	초점
circuit_eval	쉬움	CLI, 부울 논리, 벡터 신호, 3값 논리, 최적화
database_migration	보통	SQLite 마이그레이션, 데이터 변환, 외래 키, 롤백
dynamic_config_service_api	어려움	REST API, 버전 관리, 스키마 레지스트리, 변경 관리 워크플로우