Opus 5도 장기 코딩 벤치마크에선 24%만 통과함

• SlopCodeBench는 기존 코딩 벤치마크의 빈틈을 찌르는 방식임

  • 보통 코딩 벤치마크는 문제 전체를 처음부터 다 보여주고, 모델이 한 번에 해결하게 만듦
  • SlopCodeBench는 요구사항을 여러 체크포인트로 나눠서 공개함
  • 모델은 미래 요구사항을 모른 채 현재 요구사항을 구현하고, 다음 단계에서 그 코드베이스를 계속 이어받아야 함

• 이게 왜 중요하냐면, 실제 개발은 대체로 이런 식으로 굴러가기 때문임

  • 제품 요구사항은 한 번에 완벽하게 나오지 않음
  • 오늘 만든 설계가 다음 주 요구사항을 버틸 수 있어야 함
  • 그래서 이 벤치마크는 ‘문제 하나 풀기’보다 ‘코드베이스를 망치지 않고 계속 진화시키기’를 봄

실험 구성

• 글쓴이는 SlopCodeBench에서 3개 문제, 총 17개 체크포인트를 골라 테스트함

  • circuit_eval: 쉬움, 8개 체크포인트
  • database_migration: 중간, 5개 체크포인트
  • dynamic_config_service_api: 어려움, 4개 체크포인트

• 테스트한 모델은 Claude 계열 3종임

  • Opus 4.8
  • Sonnet 5
  • Opus 5
  • 세 모델 모두 같은 프롬프트를 받았고, Claude Code 하네스에서 병렬로 실행됨

• 핵심 지표는 strict pass였음

  • 현재 체크포인트의 새 테스트만 통과하면 되는 게 아님
  • 이전 체크포인트에서 물려받은 회귀 테스트까지 전부 초록불이어야 함
  • 체크포인트 4에서 깨진 버그가 있으면, 그 결함이 고쳐지지 않는 한 뒤 체크포인트도 계속 실패로 이어짐

sequenceDiagram
    participant 모델 as 코딩 모델
    participant 코드 as 코드베이스
    participant 평가 as 평가 하네스
    participant 테스트 as 숨겨진 테스트
    모델->>코드: 체크포인트 1 구현
    평가->>테스트: 체크포인트 1 검증
    모델->>코드: 체크포인트 2 구현
    평가->>테스트: 체크포인트 1과 2 회귀 검증
    모델->>코드: 다음 요구사항 누적 구현
    평가->>테스트: 이전 동작까지 전부 재검증

결과는 꽤 매움

• 9번의 테스트 실행에서 어떤 모델도 문제 하나를 끝까지 결함 없이 통과하지 못함

  • 심지어 쉬움으로 분류된 circuit_eval도 끝까지 strict pass를 유지한 모델이 없음
  • Opus 5가 제일 낫긴 했지만, ‘덜 망했다’에 가까운 결과였음

• strict pass 기준으로 Opus 5는 17개 중 4개를 통과함

  • 통과율은 24%
  • circuit_eval의 처음 3개 체크포인트와 database_migration의 첫 체크포인트만 통과함
  • 즉 4개 중 3개가 한 문제의 초반부였다는 얘기임

• Opus 4.8과 Sonnet 5는 각각 17개 중 1개만 통과함

  • 통과율은 6%
  • 둘 다 database_migration의 첫 체크포인트 하나만 strict pass를 기록함

• 원 논문 기준으로도 이 벤치마크는 아직 포화되지 않았음

  • 당시 최고 모델이었던 GPT-5.4는 11% strict pass
  • Opus 4.6은 17% strict pass
  • 이번 작은 실험에서 Opus 5가 24%까지 올라가긴 했지만, 압도적 돌파라고 보긴 어려움

코드 품질 지표도 좋은 그림은 아님

• 모든 모델에서 시간이 갈수록 verbose하고 복잡한 코드가 늘어남

  • SlopCodeBench는 체크포인트마다 41개 품질 지표를 계산함
  • 소스 라인 수, 파일 수, 함수 수, 복잡도, 중복, 린트 오류, 의존성 그래프 같은 지표가 포함됨

• Opus 5는 같은 문제 세트에서 Opus 4.8보다 함수와 callable을 5배 많이 작성함

  • 다만 실제 프로덕션 코드 볼륨만 보면 약 1.8배에 가까웠다고 함
  • 글쓴이의 해석은 ‘비싼 verbose함이 성능 향상으로 직결되진 않았다’에 가까움

• slop rule에 걸린 코드 라인 비율도 꽤 높았음

  • Opus 4.8: 평균 98%
  • Opus 5: 평균 93%
  • Sonnet 5: 평균 89%
  • verbose로 표시된 라인은 circuit_eval에서 체크포인트 1의 약 65%에서 체크포인트 8의 약 80%까지 올라감

• 복잡도와 중복도 모델마다 다른 방식으로 나빠짐
  • Opus 4.8은 circuit_eval에서 중복률이 4.6%에서 16.8%까지 올라감
  • 체크포인트 3 근처, 즉 새 요구사항이 초기 설계와 충돌하기 시작하는 지점에서 변화가 커짐
  • Opus 4.8의 최악 함수는 cyclomatic complexity 93까지 올라감
  • Opus 5는 평균 복잡도는 낮았지만 함수 수가 2000개 수준으로 많아지는 트레이드오프가 있었음

circuit_eval이 보여주는 함정

• circuit_eval 초반 3개 체크포인트만 봐도 요구사항이 꽤 빠르게 커짐

  • ck1은 --help, --version, JSON 출력 모드, .circ 파일 검증 CLI를 만드는 단계임
  • ck2는 입력을 넣으면 회로 출력을 계산하는 eval 명령이 추가됨
  • ck3부터는 단일 비트 신호가 data[7:0] 같은 벡터로 바뀌고, slicing, indexing, concatenation, MUX, reduction, EQ, width check, --radix 출력까지 붙음

• 여기서 모델이 초반 설계를 대충 잡으면 뒤에서 바로 빚이 터짐

  • 처음엔 단일 비트만 처리하면 되니까 단순한 구조로도 통과 가능함
  • 그런데 벡터, 3-valued logic, 다중 포맷, Graphviz export, optimizer까지 붙으면 초기 추상화가 버텨야 함
  • 이게 바로 장기 유지보수 벤치마크가 단발 문제보다 매운 이유임

글쓴이가 보는 진짜 신호

• 글쓴이는 코드 품질 지표 하나만으로 유지보수성을 판단하긴 어렵다고 봄

  • 작은 함수가 많다고 무조건 나쁜 것도 아님
  • 중복률, 복잡도, 함수 수 같은 지표는 각각 reward hacking이 가능함
  • 하지만 여러 지표를 합쳐 보면 모델이 시간이 지날수록 코드베이스를 어떻게 흐트러뜨리는지 방향성은 보임

• 더 중요한 건 strict pass가 실제 개발 흐름을 꽤 잘 닮았다는 점임

  • SWE-bench류 문제가 ‘소프트웨어 문제 하나를 푸는 능력’을 잘 봤다면
  • SlopCodeBench는 ‘요구사항이 계속 바뀌는 코드베이스를 유지하는 능력’을 봄
  • 글쓴이는 이쪽이 코딩 에이전트의 실전 투입 가능성을 보는 더 좋은 신호라고 주장함

• 흥미로운 제안도 있음

  • Opus 5나 Fable, GPT-5.6-Sol 같은 강한 모델이 앞의 N개 체크포인트를 구현하게 함
  • 그다음 Sonnet 5나 GPT-5.6-Terra 같은 약한 모델에게 N+1 체크포인트를 맡김
  • 약한 모델이 쉽게 이어받아 구현할 수 있다면, 앞선 강한 모델이 변경하기 쉬운 코드베이스를 남겼다는 신호가 됨

결론은 ‘아직 불 끄고 맡기긴 이르다’ 쪽

• 글쓴이의 개인적 해석은 꽤 분명함

  • 실제 소프트웨어 엔지니어링처럼 생긴 작업에서는 현재 모델을 사람 개입 없이 굴리기 어렵다는 것
  • 특히 이슈를 하나씩 쌓아가며 코드베이스를 유지해야 하는 작업에서는 steering이 필요하다는 것

• 이 결과가 모든 걸 증명하는 건 아님

  • 실험은 SlopCodeBench 전체가 아니라 3개 문제, 17개 체크포인트의 작은 부분집합임
  • 프롬프트도 기본 just-solve 버전이었고, 품질 지표 피드백이나 리뷰 루프는 없었음
  • adversarial review, 복잡도 제한, 중복 억제 같은 guardrail을 넣으면 결과가 달라질 수 있음

• 그래도 벤치마크 방향 자체는 꽤 중요해 보임

  • 모델이 80% 이상을 안정적으로 찍는 날이 오면, 그때는 코딩 에이전트를 훨씬 더 믿고 맡길 근거가 생김
  • 반대로 지금처럼 24%에서 멈춘다면, 자동화보다 ‘검토 가능한 보조자’로 쓰는 쪽이 현실적임

기술 맥락

• 여기서 중요한 선택은 코딩 모델을 단발 문제 풀이가 아니라 누적 요구사항 처리로 평가했다는 점이에요. 실제 개발에서는 한 번에 완성된 명세를 받는 일이 드물고, 이전 설계 위에 새 기능을 계속 얹어야 하거든요.

• strict pass가 빡센 이유는 현재 기능만 보는 게 아니라 과거 기능까지 계속 살아 있는지 확인하기 때문이에요. 이 방식은 회귀 테스트가 쌓이는 실제 제품 개발과 닮아 있어서, 모델이 ‘지금 당장 돌아가는 코드’가 아니라 ‘다음 변경에도 버틸 코드’를 만들었는지 드러내요.

• 코드 품질 지표 41개는 유지보수성을 직접 증명하진 못해요. cyclomatic complexity나 중복률 같은 숫자는 참고 신호일 뿐이고, 작은 함수가 많은 설계가 항상 나쁜 것도 아니거든요. 그래도 체크포인트가 진행될수록 verbose 코드와 복잡도가 올라간다는 반복 패턴은 그냥 넘기기 어렵죠.

• 한국 개발팀 입장에서는 이 결과를 AI 코딩 도구 도입 기준으로 볼 만해요. PR 하나를 빠르게 만드는 성능보다, 몇 주 뒤 다른 개발자가 그 코드를 고칠 수 있는지가 비용을 더 크게 좌우하니까요.