# SlopCodeBench로 본 Opus 5의 장기 코딩 성능 > Clean Markdown view of GeekNews topic #31913. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=31913](https://news.hada.io/topic?id=31913) - GeekNews Markdown: [https://news.hada.io/topic/31913.md](https://news.hada.io/topic/31913.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-07-28T22:37:04+09:00 - Updated: 2026-07-28T22:37:04+09:00 - Original source: [github.com/humanlayer](https://github.com/humanlayer/advanced-context-engineering-for-coding-agents/blob/main/benchmarking-opus-5-on-slop-code-bench.md) - Points: 1 - Comments: 1 ## Topic Body - 요구사항이 단계적으로 추가되는 **장기 코딩 벤치마크**에서 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](https://arxiv.org/html/2603.24755v1)는 요구사항을 여러 **체크포인트**로 나눠 순차적으로 공개함 - 모델은 이후 어떤 요구사항이 추가될지 모르는 상태에서 기존 코드를 계속 발전시켜야 함 - 2026년 3월 공개된 원 논문에서 GPT-5.4와 Opus 4.6의 엄격 통과율은 각각 **11%와 17%** 로, 아직 포화되지 않은 벤치마크임 - 관련 자료: - [SlopCodeBench 실행기](https://github.com/SprocketLab/slop-code-bench) - [SlopCodeBench 문제 모음](https://github.com/gabeorlanski/scb-problems) ### 실험 구성과 엄격 통과 기준 - 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` 최적화기 - ## `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명에게 발송**함 - 벤치마크 정확도와 별개로 실제 에이전트 실행에는 작업 범위와 발송 같은 외부 행동을 통제하는 조향이 여전히 필요함 ## Comments ### Comment 62538 - Author: neo - Created: 2026-07-28T22:37:06+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=49076391) - **SCB**는 과소평가된 벤치마크임. 단일 작업에서 끝나지 않아 실제 소프트웨어 개발과 더 비슷하고, 에이전트가 지속적으로 코드를 깔끔하게 유지해야 한다는 점이 독특함 다만 모든 문제가 신규 프로젝트이고 Git 초기화도 되어 있지 않아 에이전트가 `git diff`를 활용하지 못함. 에이전트 스킬을 평가할 때도 SCB를 사용해 봤음: [https://orcabot.com/labs/do-skills-improve-coding-agent-accu...]() SCB를 논의하는 작은 Discord 커뮤니티도 성장 중임: [https://discord.gg/BrC4BA9sVj]() - Claude가 코딩을 시작하기 전에, 작업 중 발견한 **중복 코드**를 고치겠다는 서약을 낭독하게 함. 중복을 찾기는 하지만 대개 버그를 알려줬을 때만 수정 모드로 들어가 `CLAUDE.md`의 DRY 선호를 실제로 적용함 원 논문도 `plan_first` 프롬프트로 개선 효과를 확인했지만 최종 통과율에는 영향이 없었음. 이 방식은 기능 구현 후 에이전트가 알아서 리팩터링한다고 가정하지만, 실제로는 기능 추가가 아니라 버그 수정을 지시해야 의미 있는 리팩터링을 하는 듯함 벤치마크는 테스트를 숨기고 **실패에서 통과로 바뀌는 피드백**도 주지 않으므로 성능 저하가 단조롭게 이어졌을 수 있음 - 그건 그냥 **미신**임 - 최근 이 논문과 벤치마크를 접했는데, 프로덕션 코드에서 늘 중요했던 **비기능적·장기적 요구사항**을 평가하려는 첫 시도에 가까움. 이제 모델이 단발성 문제 대부분을 풀 만큼 좋아져 특히 시의적절함 결정적인 점수가 나온다는 것도 좋음. ‘유지보수 가능성’은 여러 신호가 구성하는 고차원 공간에 가까우며, 그 공간을 파악하려면 사람의 레이블링이 필요할 가능성이 큼 또 하나의 신호는 시스템의 상태 공간이며, 최근 형식 기법도 자주 등장하고 있음 - **시스템의 상태 공간**뿐 아니라 이를 모델이 접근하고 볼 수 있게 만드는 방법도 중요함. 모델에 적합한 형태로 상태를 ‘보여주면’ 놀라운 성과를 내는 경우가 많음 환경에 CLI 하나를 추가하는 것만으로 큰 돌파구가 생기는 이유도, 복잡한 상태를 구조적으로 관찰하고 조작할 수 있게 해주기 때문임 - ‘유지보수 가능성’을 단일 지표로는 유용하지 않은 **다차원 공간**이라고 표현한 것이 간결하고 정확함 데이터베이스나 제3자 서비스에 의존하는 프로덕션 소프트웨어 전체의 상태 공간은 측정하기 너무 어려울 수 있음. 하지만 시스템 일부를 경계가 명확한 상태 기계로 분리한다면, 깔끔한 인터페이스 뒤에 있는 모듈의 가치 지표로 활용할 수 있을 듯함 **Kubernetes 제어 루프**가 좋은 사례임. 범위가 제한된 구성 요소들이 잘 정의된 상태 기계의 제어 루프를 맡아, 대부분의 네트워크 분할이나 중단에서도 작동하고 복구함. CRDT의 약속을 더 실용적으로 구현한 접근에 가까움 - 대형 연구소들이 이 벤치마크를 **강화학습 파이프라인**에 활용하길 바람. 생성 코드의 복잡도를 줄이는 것이 최우선이어야 하며, 이상적인 모델은 올바른 추상화를 선택해 기능을 구현하면서도 코드 줄 수를 줄여야 함 이 벤치마크로 코드 복잡도를 낮추는 프롬프트와 스킬을 반복 개선할 수 있다는 점도 좋음 - 코드 줄 수를 줄인다는 명목으로 너무 많은 로직을 **한 줄에 몰아넣는 방향**으로 치우치기도 쉬움 - 연구소들은 적어도 공식적으로는 **벤치마크 데이터로 학습하지 않음**. 비슷한 문제로는 학습할 수 있지만, 벤치마크에 포함된 특정 문자열은 학습 말뭉치에서 적극적으로 걸러내야 함 - 좋긴 하지만 **사람의 성능과 비교**해야 훨씬 유용할 것임. 어렵다는 점은 이해하지만, 많은 이가 제목의 수치만 보고 Opus 5가 인간 개발자의 4분의 1 수준이라고 오해할 가능성이 큼 - Opus 5는 Opus 4.8보다 확실히 개선됐지만, Fable에서 느꼈던 것처럼 혁명적이지는 않다는 내 체감과 일치함 이제 Opus 4.8 xhigh 대신 **Opus 5 medium**을 쓰며 토큰도 덜 들고 더 빠름. 문체를 싫어하는 반응은 이해하지만 실제 작업에는 전혀 거슬리지 않아 만족하며 사용 중임 - Fable은 성능이 **의도적으로 약화된 듯함**. 처음 나왔을 때는 정말 혁명적이었지만, 금지 조치 이전과 지금의 모델은 같지 않음 - Fable의 어떤 부분이 **혁명적으로 느껴졌는지** 더 자세히 듣고 싶음 - 왜 medium을 high 대신 선택했는지 궁금함. 본 성능 차트에서는 medium에서 high로 갈 때 향상이 상당했고, high에서 xhigh로 갈 때는 그만큼 크지 않았음 - 지금까지의 해결책은 별도로 **전체 코드베이스 리뷰**를 주기적으로 실행하고, 가능하면 Fable로 검토한 뒤 결과에 따라 여러 차례 리팩터링하는 방식임 - 나도 이 방식을 선호함. 그렇지 않으면 지나치게 깊은 **국소 최적점**에 빠질 위험이 큼 - **원시 테스트 결과**를 보고 싶음. 대부분의 모델이 `database_migration`의 체크포인트 2 테스트에서 `default_value`를 놓칠 것 같음. 이를 JSON 리터럴과 SQL 표현식 중 어느 쪽으로도 해석할 수 있기 때문임 논문에서 든 원인과 무관한 이유로 실패하기 쉬운 테스트가 더 있을 수도 있음. 의존성이 허용하는 범위에서 체크포인트 순서를 3→2→5→4처럼 바꾸면, 각 체크포인트의 난이도 차이를 통제할 수 있어 흥미로운 실험이 될 것임 - **체크포인트 순서를 바꿔 결과를 비교**하는 발상이 마음에 듦. 난이도를 높이거나 낮추는 방법으로도 활용할 수 있겠음 정보를 유출하지 않으면서 결과 일부를 묶어 공개하기가 얼마나 쉬운지 살펴보겠으며, 아마 가능할 듯함 - 한동안 대화에 참여하지 않았지만 이 결과를 만들어낸 것은 반가움. Opus 5는 큰 개선이 아니라고 느끼며, 진정한 **놀라움**을 준 것은 Opus 4, 4.6, 그리고 Trump 행정부의 성능 약화 조치 이전 Fable뿐이었음 - 이번 작업은 새 모델로 가장 빠르고 저렴하게 시도할 수 있는 **출발점**에 불과함 앞으로 sol과 Fable도 포함하고, 더 많은 언어를 탐색하며, 벤치마크를 더 폭넓게 반영하도록 문제 세트를 다듬고 싶음 개인적으로 Opus 4.5가 4.1보다 둔하게 느껴졌음. 4.5가 2.5배 빠르고 2.5배 저렴하다는 점 때문에 더 작은 모델이라고 추측해 편향됐을 수도 있음 - 코드 중복과 전체 코드 줄 수에 벌점을 주는 **적대 모델**을 제공하면 이 벤치마크의 성능을 어느 정도 유도할 수 있을지 궁금함