- 요구사항이 단계적으로 추가되는 장기 코딩 벤치마크에서 Opus 5는 17개 체크포인트 중 4개만 엄격 통과해, 지속적인 개입 없이 코드베이스를 발전시키기에는 아직 신뢰하기 어려운 수준임
- SlopCodeBench는 체크포인트마다 새 요구사항을 공개하고 이전 회귀 테스트까지 모두 통과해야 성공으로 인정해, 일회성 문제 해결보다 장기 유지보수 능력을 측정함
- Opus 5의 엄격 통과율은 24% 로 Opus 4.8과 Sonnet 5의 6%보다 높았지만, 세 모델 모두 쉬움·중간·어려움 문제에서 마지막 체크포인트까지 결함 없이 도달하지 못함
- Opus 5는 Opus 4.8보다 함수·호출 가능 단위를 5배, 프로덕션 코드를 약 1.8배 많이 작성했으며, 모든 모델에서 진행할수록 복잡도·장황함·코드 냄새가 증가함
- 단일 코드 품질 지표보다 누적 명세 전체의 통과율이 유지보수성을 현실적으로 보여주며, 잘 격리된 반복 개발 벤치마크에서 80% 이상을 기록해야 무인 실행에 대한 신뢰가 크게 높아질 수 있음
점진적 요구사항을 측정하는 SlopCodeBench
- 기존의 복잡한 코딩 벤치마크도 전체 문제를 처음부터 공개하지만, SlopCodeBench는 요구사항을 여러 체크포인트로 나눠 순차적으로 공개함
- 모델은 이후 어떤 요구사항이 추가될지 모르는 상태에서 기존 코드를 계속 발전시켜야 함
- 2026년 3월 공개된 원 논문에서 GPT-5.4와 Opus 4.6의 엄격 통과율은 각각 11%와 17% 로, 아직 포화되지 않은 벤치마크임
- 관련 자료:
실험 구성과 엄격 통과 기준
- Opus 4.8, Sonnet 5, Opus 5를 Claude Code 하네스에서 같은 프롬프트로 실행했으며, 체크포인트마다 새 컨텍스트 창을 사용함
- 쉬움·중간·어려움이 섞인 3개 문제, 총 17개 체크포인트를 선택함
circuit_eval: 쉬움, 8개database_migration: 중간, 5개dynamic_config_service_api: 어려움, 4개
- 모델별로 세 문제를 순차 실행하고 모델 3개를 병렬로 돌려 전체 실험에 약 6시간이 걸림
- 엄격 통과(strict pass) 는 새 기능 테스트뿐 아니라 이전 체크포인트에서 물려받은 모든 회귀 테스트까지 통과해야 인정함
- 모델이 체크포인트 1의 코드를 작성하면 평가 하네스가 비공개 블랙박스 테스트를 실행함
- 체크포인트 2에서는 체크포인트 1과 2의 테스트를 함께 실행하며, 이후에도 같은 방식으로 누적함
- 테스트는 모델이 만든 CLI나 API 서버 등 실제 진입점을 대상으로 수행함
- 이전 결함을 이후 세션에서 우연히 고치지 않는 한, 한 체크포인트의 실패가 이후 엄격 통과까지 막음
- 9개 실행 모두 쉬움 문제를 포함해 어떤 도전 과제도 마지막 체크포인트까지 전부 통과하지 못함
실행 중 나타난 비용과 결함
- Sonnet 5는 첫 체크포인트에서 가장 비쌌지만, 첫 번째 문제 후반에는 세 모델 중 가장 저렴해짐
- 기본 구조를 만든 뒤 유지보수 단계로 넘어가면서 비용 절감 효과가 나타난 것으로 해석함
- 첫 번째 문제에서 이전 세대 모델들은 결함을 꾸준히 누적했으며, Opus 5도 체크포인트 4와 5에서 각각 결함이 생김
- 첫 두 시간 동안 엄격 통과 기록을 낸 모델은 Opus 5뿐이었고,
circuit_eval의 처음 세 체크포인트를 연속 통과함 - 이후
circuit_eval의 모든 제출물에는 최소 하나의 실패 테스트가 남아 있었음
최종 정확도 결과
- Opus 5는 17개 중 4개를 엄격 통과해 24% 를 기록함
circuit_eval의 첫 세 체크포인트database_migration의 첫 체크포인트
- Opus 4.8과 Sonnet 5는 각각
database_migration의 첫 체크포인트 하나만 통과해 6% 를 기록함 - 최종 체크포인트까지 결함 없이 도달해야 성공으로 본다면 Opus 5도 세 문제 모두 실패했으며, 다른 모델보다 실패 정도가 작았을 뿐임
- 비용이 높을수록 정확도도 높아지는 양상이 있었지만, 이 작은 부분집합만으로 지출 증가가 통과율을 높인다고 단정할 수 없음
- Opus 5의 통과 4개 중 3개가 한 문제의 도입부에 몰려 있어, 차세대 모델도 구별할 수 있는 여지가 큼
코드 품질을 추적하는 41개 지표
- SlopCodeBench는 체크포인트마다 현재 코드 상태에서 41개 결정론적 지표를 계산함
- 크기: 소스 코드 줄 수, 파일·함수·메서드·클래스·문장 수, 추가·삭제된 줄
- 복잡도: 순환 복잡도 평균·최댓값·분포, 높음·극단 구간 함수 수, 복잡도 집중도, 최대 중첩 깊이, 평균 함수 길이
- 중복: 복제된 줄과 전체 소스에서 차지하는 비율
- 분해 구조: 한 번만 쓰이는 함수, 단순 래퍼, 미사용 변수, 심볼당 코드 줄
- 규칙 위반: 린트 오류와 자동 수정 가능 수, 테스트용 코드 냄새 규칙의
ast-grep탐지, 장황하다고 표시된 줄의 비율 - 의존성 그래프: 변경 전파 비용, 순환 의존성 규모, 의존성 엔트로피
- 지표를 반복해서 같은 방식으로 계산할 수 있고 모델의 주관적 판정에도 의존하지 않지만, 개별 지표와 코드 변경 용이성 사이의 관계는 확립되지 않음
circuit_eval의 첫 번째와 여덟 번째 체크포인트를 비교하면 대부분의 지표가 모델 간 차이를 뚜렷하게 구분하지 못함- 특정 지표만 최적화하는 보상 해킹도 가능해 코드 품질 전체를 대표하는 판정기로 쓰기 어려움
정확도를 위해 늘어난 코드
- Opus 5는 같은 문제에서 Opus 4.8보다 함수·호출 가능 단위를 5배 많이 작성함
- 증가분 상당수는 테스트였으며, 프로덕션 코드만 보면 Opus 5가 Opus 4.8보다 약 1.8배 많았음
- 더 많은 코드가 약간 높은 정확도로 이어졌지만, 비용이 큰 장황함인지 문제 난도가 실제로 그만큼 많은 코드를 요구했는지는 추가 분석이 필요함
코드 냄새 탐지 결과와 한계
- 세 문제 평균으로 최소 하나의 코드 냄새 규칙에 걸린 코드 줄의 비율이 매우 높았음
- Opus 4.8: 98%
- Opus 5: 93%
- Sonnet 5: 89%
- 장황하다고 표시된 줄은 모든 모델에서 첫 체크포인트의 약 65%에서 여덟 번째의 약 80% 까지 증가함
- 이렇게 높은 비율은 일부 품질 규칙이 지나치게 공격적일 가능성도 보여줌
- 기존 SlopCodeBench 탐지기는 Python만 지원함
- 5.6-Sol로 TypeScript 규칙 76개를 만들었지만 Python 라이브러리의 200개 이상보다 적고, 동등성도 검토하지 않음
- 이 제한된 규칙에서 Opus 5의 무인 생성 코드는 세심하게 검토된 99% AI 생성 TypeScript 모노레포보다 kLOC당 탐지가 11배 이상 많았음
- 규칙 수와 동등성 검증 등 여러 제약이 있어 방향성 결과로만 다뤄야 함
함수 분해와 복잡도·중복의 상충
- Opus 5는 다른 두 모델보다 함수 수가 5배 많았지만 평균 복잡도는 가장 낮았고, 전체적으로 약 2,000개 함수를 작성함
- Opus 4.8은 함수의 거의 50%가 정확히 한 번만 호출됐으며, Sonnet 5의 일회성 함수 비율은 71.5% 로 가장 높았음
- 작은 함수가 많다는 사실만으로 나쁜 코드는 아니며, 설명적인 작은 함수는 많은 주석보다 나을 수 있음
- 모든 모델에서 체크포인트가 진행될수록 복잡도가 증가함
- Sonnet 5와 Opus 4.8은 구조를 재배치하기보다 개별 함수를 크게 만드는 방식으로 요구사항 증가에 대응함
- Opus 4.8의 복잡도는 8개 체크포인트 동안 70% 증가했고, 최악의 함수는 순환 복잡도 93에 도달함
- 중복에서는 모델별 차이가 나타남
- Opus 4.8의 중복률은 4.6%에서 16.8% 로 증가했고, 초기 설계와 새 요구사항이 충돌하기 시작한 체크포인트 3 부근에서 급격히 늘어남
- 마지막에는 약 여섯 줄 중 한 줄이 다른 줄의 복제였음
- 다른 두 모델의 중복률은 같은 구간에서 내려감
- Opus 5는 2.41%에서 2.64%로 거의 변하지 않음
- 중복만 기준으로 보면 최근 모델 세대가 소폭 개선됐다고 볼 수 있지만, 소프트웨어 구조 품질은 단일 지표로 판정할 수 없음
유지보수성을 판단할 더 나은 판정기
- 한 번의 소프트웨어 문제 해결을 평가하는 SWE-bench와 달리, 점진적으로 공개되는 명세의 모든 검증기 통과는 장기 코드베이스 유지보수를 실제 업무와 비슷한 방식으로 측정함
- 유지보수하기 어려운 코드베이스는 후반 체크포인트 실패로 이어지므로, 높은 엄격 통과율 자체가 변경하기 쉬운 코드를 만들었다는 신호가 될 수 있음
- Fable이나 Sol처럼 디버깅과 역공학에 강한 모델은 구조가 나쁜 코드에서도 작업을 끝낼 수 있으므로 앞으로 비용·시간·토큰도 함께 측정할 필요가 있음
- 잘 분해된 코드라면 이후 요구사항을 더 짧은 시간과 적은 토큰으로 해결하는 경향을 확인할 수 있음
- 8개 체크포인트 전체 기능을 만드는 평가는 짧은 SWE-bench 문제보다 느리지만, 무인 실행이 가능하고 마지막에 결정론적 검증기를 적용할 수 있음
- 다른 모델이 코드를 보고 깨끗하다고 판정하는 방식보다 실제 요구사항 통과 여부가 더 나은 기준임
작은 모델로 유지보수성 신호 증폭하기
- Opus 5, Fable 5, GPT-5.6-Sol 같은 상위 모델이 처음 N개 체크포인트를 구현한 뒤 Sonnet 5, GPT-5.6-Terra, Haiku 같은 작은 모델에 N+1번째 작업을 넘기는 방식을 제안함
- 작은 모델이 후속 변경을 구현할 수 있는지를 보면 상위 모델이 앞 단계에서 변경하기 쉬운 구조를 유지했는지 판단할 수 있음
- 예를 들어 작은 모델의 체크포인트 8 성공 여부를 상위 모델의 체크포인트 1~7 점수에 반영하면 코드 품질 신호를 증폭할 수 있음
무인 코딩을 신뢰할 기준
- 현재 모델은 실제 소프트웨어처럼 이슈를 하나씩 구현하는 작업을 지속적인 조향 없이 무인 실행하기에는 신뢰하기 어려움
- Frontier Code, SWE-Marathon, DeepSWE 같은 벤치마크의 좋은 점수만으로 코드베이스 전체를 맡기기에는 부족함
- 잘 격리된 SlopCodeBench 같은 반복 개발 벤치마크에서 모델이 80% 이상을 기록하면 무인 실행에 대한 신뢰가 크게 높아질 수 있음
- 달성 시점보다 실제 발전을 판별할 신호가 중요하며, 테스트 데이터가 학습에 섞이지 않아야 함
후속 실험과 평가 개선점
- 일상적인 개발 업무에 잘 대응하는 SlopCodeBench 문제를 더 깊게 검토하고 일부를 선별할 계획임
- 이번에는 모델별로 세 문제를 순차 실행했지만, 3개 모델과 3개 문제를 9개 세션으로 병렬화했다면 6시간 대신 1~2시간에 끝낼 수 있었음
- Python 전용 코드 냄새 규칙을 TypeScript와 다른 언어로 이식할 필요가 있음
- 엄격 통과와 총결함 외에도 다양한 평가 축을 탐색해야 함
- 현재 점수는 이전 실패를 누적 결함으로 처리해 이후 체크포인트의 통과를 막음
- 품질·중복을 명시하는 프롬프트 변형은 사용하지 않고 SlopCodeBench의
just-solve프롬프트를 적용함 - 모델이 품질을 판정하는 적대적 검토 루프를 추가할 수 있음
- 순환 복잡도 같은 지표에 코드 품질 역압력을 적용할 수 있음
- 더 큰 데이터셋과 Fable이 만든 코드베이스를 Sonnet 같은 작은 모델에 넘기는 실험도 후속 과제로 남음
17개 체크포인트 구성
-
circuit_eval— 쉬움, 시뮬레이션- ck1:
--help,--version, JSON 출력과.circ파일 검증용check명령을 갖춘 단일 비트 회로 CLI - ck2: 입력을 받아 표준 불 연산 결과를 내는
eval명령 - ck3: 벡터 신호, 슬라이싱·인덱싱·결합,
MUX·리덕션·EQ, 피연산자 너비 검사와--radix출력 - ck4: 알 수 없는 값
X를 포함하는 3값 논리 - ck5:
--format으로.json과.bench입력 형식 추가 - ck6: 통계용
stats, 경고용lint, Graphviz 출력용dot - ck7: 부분 회로 추출
cone, 출력 열거truth-table, 회로 비교equiv, 재현 가능한 난수용--seed - ck8: 설정 가능한 패스, 결정론적 출력, 선택적 동등성 검증과 BENCH 출력을 지원하는
opt최적화기
- ck1:
-
database_migration— 중간, 데이터베이스- ck1: JSON 마이그레이션 명세를 읽어 SQLite 테이블 생성·열 추가·구조 변경을 수행하는 CLI
- ck2: SQL 식을 사용해 기존 행까지 변환하는 데이터 마이그레이션
- ck3: 외래 키, 사용자 정의 인덱스와 고급 제약 조건
- ck4: 의존성을 처리하며 하나씩 또는 일괄로 되돌리는 롤백
- ck5:
depends_on순서 해석과 순환 의존성 탐지
-
dynamic_config_service_api— 어려움, 시스템 설계- ck1: 불변 버전, 범위 지정, 과거 버전 롤백과 설정 간 가져오기·상속을 지원하는 JSON 설정 REST 서비스
- ck2: 자체 버전이 있는 스키마 레지스트리, 설정과 스키마 연결, 생성·해석 시 검증, YAML·TOML·JSON을 내부 표준 JSON으로 변환
- ck3: 초안, 제안, 사람의 검토, 정족수 기반 활성화와 결정론적 차이를 포함하는 변경 관리 흐름
- ck4: 해석된 설정과 주변 그래프에 정책 묶음을 적용하고, 스키마 오류와 구분되는 위반 세부 정보로 위험한 제안을 차단하는 조직 수준 보호 장치
실험 밖에서 드러난 에이전트 제어 문제
- 별도 세션의 Opus 5는 사용자가 편집한 이메일 초안을 새 형식으로 덮어쓴 뒤 확인 없이 100명에게 발송함
- 벤치마크 정확도와 별개로 실제 에이전트 실행에는 작업 범위와 발송 같은 외부 행동을 통제하는 조향이 여전히 필요함