Opus 5.5는 엉망인 코드를 짜지만, 어쨌든 성공한다. SlopCodeBench에서 영감을 받은 연구 프로젝트
Opus 5.5 writes slop code, but succeeds anyways. A research project inspired by SlopCodeBench
핵심 요약
AI가 작성한 코드가 지저분해져도 성능 저하가 없다는 것을 Opus 5.5 테스트를 통해 확인한 연구 결과입니다.
- 코드 품질과 성능 — 지저분한 코드와 성능 저하 사이의 상관관계가 거의 없음
- 비용 효율성 — 코드베이스 크기가 커질수록 비용은 증가하지만 코드의 복잡성과는 무관함
- 벤치마크 한계 — 기존 SlopCodeBench의 평가 방식이 실제 AI 성능을 과소평가할 가능성
- 인간 중심적 관점 — 코드 가독성은 인간에게 중요하지만 AI 에이전트에게는 큰 문제가 아님
몇 달 전에 SlopCodeBench라는 벤치마크를 제안하는 논문을 하나 봤거든. 아이디어가 뭐냐면, 에이전트한테 문제를 여러 체크포인트로 쪼개서 던져주고, 각 단계마다 기존에 짠 코드 위에 기능을 계속 덧붙이게 시키는 거야. 당연히 기존 기능은 안 깨뜨려야 하고. 이 과정에서 코드가 얼마나 '엉망(sloppy)'이 되는지를 두 가지 지표로 측정하는데, 하나는 구조적 침식(거대하고 분기만 잔뜩 있는 함수가 얼마나 쌓이는지)이고, 다른 하나는 장황함(불필요한 코드가 얼마나 많은지)이야.
논문 결론은 에이전트가 작업을 오래 할수록 코드가 더 개판이 되고, 진행할수록 테스트 통과율도 떨어진다는 거였어. 뻔한 소리지. 에이전트가 스스로 무덤을 파고 있다는 거야. 코드가 더러우면 확장하기 힘드니까 결국 실패한다는 논리거든.
근데 난 에이전트한테도 이게 진짜 적용되는지 의문이 들어서 직접 테스트해 봤어. Opus 5.5를 돌려서 196개 체크포인트를 전부 다 깼거든(API 비용만 266달러 나옴, 아오). 그래서 코드가 더러워지는 게 결과에 악영향을 주는지 확인해 봤지.
요약:
- 논문 말대로 코드는 확실히 더러워지더라. 문제 35개 중 22개에서 침식도랑 장황함 수치가 둘 다 올라갔어.
- 같은 문제 내에서 체크포인트끼리 비교해 보니까, 코드가 더럽다고 다음 체크포인트를 못 맞추는 건 아니었어.
- 기존 기능을 깨뜨리는 일은 거의 없었어. 이전에 통과했던 테스트 중 퇴보한 건 0.3% 정도밖에 안 됐고, 코드가 더럽다고 퇴보가 더 자주 일어나는 것도 아니었거든.
- 코드가 지저분하다고 다음 작업 비용이 늘어나는 것도 아니었어. 대신 코드 크기는 영향이 있더라. 코드베이스가 두 배 커질 때마다 다음 체크포인트 비용이 19% 정도 더 들었거든.
- 리더보드 전체를 봐도, 코드를 깔끔하게 짜는 모델들이 문제를 더 많이 푸는 것도 아니야. 상관관계가 거의 제로에 가까워.
참고로, 헤드라인에 나온 17%라는 엄격한 해결률은 Opus 성능을 너무 저평가한 거야. 각 새로운 스펙에 대한 테스트에서는 84~92%를 통과했거든.
물론 주의할 점은 있어. 이건 꽤 작은 프로그램들을 대상으로 모델 하나를 한 번 돌려본 거고, 비교도 관찰적인 수준이야. 아주 작은 영향력은 숨어 있을지도 모르지. 하지만 설령 존재한다 해도, 이 지표들이 경고하는 수준의 페널티는 절대 아니야.
전체 영상 링크는 여기
