SlopCodeBench: 코딩 에이전트가 반복 작업에서 코드를 망가뜨리는 과정을 측정하는 벤치마크

핵심 메시지

• 기존 코딩 벤치마크는 한 시점의 정답 여부만 본다. 제출한 코드가 이후 어떤 부담으로 남는지는 아무도 측정하지 않았다.
• SlopCodeBench는 체크포인트마다 새 기능을 덧붙이게 하고, 그 과정에서 복잡도가 어디로 쏠리는지를 '침식'으로 측정한다.
• 문제는 손으로 직접 작성했다. 공개 저장소의 변경 내역에는 핵심 기능과 무관한 변화가 너무 많이 섞여 있어 자동 수집이 어렵다는 판단이다.
• 모델은 앞서 스스로 정의한 로직을 무시하고 다시 구현하는 실수를 반복했고, 이런 현상은 오래 생각하도록 설정했을 때 오히려 더 잦았다.
• 제작자는 모델이 기존 코드와 라이브러리를 재사용하고 필요하면 삭제하도록 유도하는 것이 다음 과제라고 본다.

쉽게 이해하기

코딩 에이전트 평가에서 지금까지 기준이 되어 온 방식은 하나의 이슈나 변경 요청을 얼마나 해결하는지 보는 것이었다. 이 영상에 출연한 SlopCodeBench 제작자는 이런 단일 시점 평가에 남은 여지가 거의 없다고 진단한다. 문제를 풀면 그것으로 끝이고, 그 해결책이 코드베이스에 무엇을 남기는지는 점수에 반영되지 않기 때문이다.

그가 문제로 지목한 것은 실제 개발과의 간극이다. 소프트웨어는 한 번의 제출로 끝나지 않고 기능이 계속 붙는다. 모델이 저항이 가장 적은 방식으로 계속 덧붙이기만 하면, 각 단계에서는 통과하더라도 복잡도가 눈에 띄는 속도로 쌓인다. 그는 나중에 사람이 개입해야 하는 순간 코드가 이미 손대기 어려운 상태라면, 처음부터 다시 쓰는 편이 낫다는 결론에 이르게 된다고 지적한다.

그래서 벤치마크는 체크포인트 구조를 택했다. 첫 체크포인트에서 기본 문제를 풀고, 이후 체크포인트마다 새 기능을 하나씩 요구한다. 침식은 복잡도가 어디로 모이는지로 측정하는데, 조건 분기와 제어 구조가 하나의 거대한 함수로 몰리고 있다면 그 자체가 나중에 누군가 반드시 손대야 할 부담이라는 판단이다.

문제를 손으로 쓴 이유도 분명하다. 공개 저장소의 변경 내역을 긁어모으면 핵심 기능과 무관한 변화가 함께 섞여 신호가 흐려지고, 원하는 규모로 수집하려면 비용도 감당하기 어렵다. 그는 이 벤치마크의 핵심이 '설계와 구조에 관한 판단이 이후 단계에 영향을 남기게 만드는 것'이라고 설명하며, 그런 문제는 처음부터 직접 설계해야 나온다고 말한다.

평가 환경에 대한 관점도 뚜렷하다. 그는 모든 모델을 최소한의 공통 실행 환경에서 비교해야 한다는 생각에 반대하며, 사람들이 실제로 쓰는 도구를 버전만 명시해 그대로 사용하는 편이 개발자에게 훨씬 유용하다고 본다. 벤치마크 점수만 잘 나오도록 최적화된 모델은 조금만 벗어난 상황에서 곧바로 드러난다는 것이다.

주요 인사이트

• 단일 시점 평가로는 '패치를 덧붙이는 습성'을 측정할 수 없다. 어디로 향해야 했는지가 아니라 어떻게 도달했는지를 보려면 여러 단계가 필요하다는 것이 이 벤치마크의 출발점이다.
• 제작자가 관찰한 실패는 어려운 문제를 못 푸는 것이 아니라 세부에 대한 주의력 부족이었다. 규격의 일부만 구현하고 나머지를 건너뛰거나, 테스트를 아예 작성하지 않는 식이다.
• 앞선 체크포인트에서 스스로 만든 계산 로직을 무시하고 다시 구현하는 사례가 반복됐다. 흥미로운 점은 이 현상이 오래 생각하도록 설정했을 때 더 잦았다는 관찰이다. 과도한 추론이 이미 존재하는 답을 밀어낸 셈이다.
• 모델은 라이브러리를 꺼리고 직접 구현하려 하며, 다른 선택지가 없을 때가 아니면 코드를 지우지 않는다. 삭제하지 않는 성향은 그대로 코드베이스의 군살로 남는다.
• 평가 신호가 없으면 모델은 그 항목을 배우지 않는다. 코드 품질이 지금까지 방치된 이유를 제작자는 이 문제를 다루는 벤치마크가 없었기 때문이라고 본다.

자주 묻는 질문

관련 AI 소식