슬롭코드벤치가 드러낸 것: AI는 아직 '무인 운전'으로 코드를 못 지킨다

코딩 벤치마크의 오랜 약점 하나는 문제 전체를 처음부터 다 보여준다는 점이다. 실제 소프트웨어 개발은 요구사항이 시간을 두고 조금씩 드러나고, 그때마다 기존 코드를 고쳐 나가는 일에 가깝다. UW 매디슨의 GOrlanski 연구실이 2026년 3월 내놓은 SlopCodeBench(SCB)는 바로 이 지점을 겨냥한다. 각 과제를 여러 개의 '체크포인트'로 쪼개, 모델이 전체 그림을 모른 채 새 요구사항이 공개될 때마다 코드베이스를 진화시켜야 하도록 만든 것이다. 벤치마크가 측정하려는 것은 한 번의 정답이 아니라 '시간에 걸친 유지보수 능력'이다.

이 벤치마크가 흥미로운 이유는 아직 포화되지 않았다는 데 있다. 원 논문 기준으로 당시 최상위 모델인 GPT-5.4와 Opus 4.6이 각각 11%, 17%의 엄격 통과율(strict pass)에 그쳤다. 엄격 통과란 새로 추가된 테스트가 모두 통과하는 것은 물론, 이전 체크포인트에서 물려받은 회귀 테스트까지 전부 초록불이어야 인정되는 기준이다. 4번 체크포인트에서 무언가를 망가뜨리면 그 결함이 이후 체크포인트로 그대로 넘어가 연쇄적으로 실패하게 된다. 결함은 모델의 산출물(CLI나 API 서버 같은 진입점)에 대해 별도로 감춰 둔 블랙박스 테스트를 돌려 판정한다.

파란불은 세 개, 그마저도 한 문제의 도입부

필자는 지난 금요일 세 개의 클로드 모델(Opus 4.8, Sonnet 5, Opus 5)을 벤치마크의 일부에 6시간 동안 돌리며 지켜봤다. 클로드가 골라낸 세 문제, 총 17개 체크포인트를 난이도별로 섞어 구성하고, 모든 모델에 같은 프롬프트를 주되 체크포인트마다 새 컨텍스트 창으로 병렬 실행했다. 결과의 핵심은 이렇다. Opus 5가 24%(17개 중 4개)로 승리했지만 원 논문의 Opus 4.6 성적(17%)보다 크게 나아지지 않았고, 세 모델 중 어느 것도 단 하나의 과제조차 끝까지 무결점으로 완주하지 못했다. '쉬움'으로 분류된 문제에서도 마찬가지였다.

승자의 성적표를 뜯어보면 더 냉정하다. Opus 5가 얻은 엄격 통과 4개 중 3개는 circuit_eval 과제의 첫 세 체크포인트, 즉 도입부에 몰려 있었다. 처음 세 개를 연달아 통과한 뒤에는 이후 모든 솔루션에 최소 하나씩 결함이 붙었다. Opus 4.8과 Sonnet 5는 각각 1개(6%)에 그쳤는데, 그마저도 세 모델이 공통으로 통과한 database_migration의 첫 체크포인트였다. 초반의 기본 골격을 세우는 일은 그럭저럭 해내지만, 요구사항이 초기 설계와 충돌하기 시작하는 중반부터 무너진다는 얘기다.

코드는 늘어나는데 통과율은 그대로

모든 모델이 과제를 진행할수록 장황함과 복잡도, 각종 코드 스멜 지표가 뚜렷하게 나빠졌다. SCB는 체크포인트마다 41개 품질 지표를 결정론적으로, 즉 판정에 별도의 모델을 쓰지 않고 계산해 준다. 지나치게 장황하다고 표시된 코드 라인 비율은 첫 체크포인트의 약 65%에서 여덟 번째에는 80%까지 올랐고, 이는 Opus 5도 예외가 아니었다. 눈에 띄는 점은 Opus 5가 Opus 4.8보다 함수를 다섯 배나 많이 찍어냈다는 것이다. 다만 실제 프로덕션 코드 증가량은 1.8배 수준으로, 늘어난 양의 상당수는 테스트였다. 결국 비싼 장황함이 더 나은 결과로 곧장 이어지지는 않았다는 인상이 남는다.

모델별로 복잡도에 대응하는 방식도 갈렸다. Opus 5는 평균 복잡도가 가장 낮았지만 그 대가로 약 2,000개의 함수를 썼다. 반대로 Opus 4.8과 Sonnet 5는 함수를 이리저리 재배치하기보다 개별 함수를 키우는 쪽을 택했고, Opus 4.8은 여덟 체크포인트에 걸쳐 복잡도가 70% 늘며 최악의 함수는 순환 복잡도 93에 이르렀다. 중복 코드에서도 Opus 4.8은 4.6%에서 16.8%로 치솟아 세 번째 체크포인트 부근에서 급변한 반면, Opus 5는 2.41에서 2.64로 거의 평평했다. 작은 함수가 많은 것 자체가 나쁘다고 볼 수는 없지만, 어느 지표 하나도 '이 코드가 바꾸기 쉬운가'를 단독으로 말해 주지는 못한다.

지표의 한계는 필자도 인정한다. 어떤 정량 지표든 모델이 손쉽게 보상 해킹할 수 있고, 유지보수성과의 인과를 아직 확립하지 못했다. 참고로 SCB의 탐지기는 파이썬 전용(200개 이상)이라, 필자는 자사 타입스크립트 모노레포에 적용하려고 별도로 76개짜리 축소 규칙을 만들어 봤다. 규칙 수가 적고 검증도 부족하다는 단서를 잔뜩 달아야 하지만, Opus 5가 '무인'으로 생성한 솔루션은 사람이 꼼꼼히 리뷰한 그 모노레포보다 kLOC당 슬롭 트리거가 11배 이상 많았다.

실무자가 가져갈 신호

필자의 결론은 명료하다. SCB는 그가 그동안 경험과 직관으로만 주장해 온 것에 처음으로 데이터를 붙여 준다. 이슈를 하나씩 쌓아 올리는 현실 형태의 개발에서, 오늘날의 모델은 사람의 조타 없이 '불 끄고' 맡겨 둘 대상이 아니라는 것이다. 흥미로운 후속 아이디어도 있다. 똑똑한 모델에게 앞의 N개 체크포인트를 맡긴 뒤, 더 저렴한 모델이 N+1을 구현할 수 있는지 보는 방식이다. 잘 정돈된 코드를 남겼다면 작은 모델도 이어받을 수 있어야 하니, 이는 상위 모델의 유지보수 품질을 역으로 검증하는 신호가 된다. 필자는 언제가 될지는 못 박지 않되, SwE-bench류가 '한 번의 문제 해결'을 잘 재현했듯 '점진적으로 공개되는 명세를 모두 통과하기'는 '코드베이스를 오래 유지하기'를 현실적으로 재는 척도라고 본다. 잘 격리된 SCB에서 80% 이상이 나오는 날이 오면, 그제야 자동 실행을 한결 마음 편히 신뢰하겠다는 것이다.