테스트를 통과해도 코드는 조잡해진다 - 중복과 복잡도 지표로 읽는 SlopCodeBench

TL;DR

• 테스트를 통과하는 코드에도 중복과 불필요한 추상화가 쌓일 수 있다. 코드가 늘어날수록 사람이 전체를 이해하고 통제하기 어려워진다. 기능적 정확성과 유지보수 품질은 따로 평가해야 한다.
• SlopCodeBench를 소개한 글에서 에이전트 코드의 중복·장황함과 복잡도 집중 지표는 인간 저장소보다 평균적으로 높았다. 다만 지표에 맞춰 최적화하거나 무관한 코드를 늘리면 점수가 왜곡될 수 있다. 수치는 검토 대상을 찾는 보조 수단이다.
• 반복 개발 평가는 이전 설계가 다음 요구사항을 견디는지 확인한다. 모든 체크포인트를 끝까지 통과한 문제가 없었다는 결과와 개별 체크포인트 성공률은 서로 다르다. 원문도 Fable 5.1과 Astra를 아직 시험하지 않았다고 명시한다.

Source

If coding is solved, what now?: Measuring the sloppiness of code — Sebastian, Earendil, 2026년 9월 10일.

보충 대조: SlopCodeBench 논문 v1, 특히 평가 절차·코드 품질 정의·Table 1. 블로그의 해설과 논문 v1의 실험 범위를 구분했다.

Knowledge

정답인 코드에도 나쁜 설계가 남는다

숨겨진 테스트로 프로그램의 동작을 확인하면 모델에 비교적 명확한 학습 신호를 줄 수 있다. 입력에 맞는 출력이 나오는지, 요구한 기능이 작동하는지를 자동으로 반복 평가하기도 쉽다. 그러나 같은 테스트를 통과한 구현끼리도 중복의 양과 추상화의 적절성, 다음 변경의 난이도는 크게 다를 수 있다. 기능적 정답만 확인해서는 코드의 질을 충분히 설명하지 못한다.

Earendil의 Sebastian은 이 간격을 코드의 조잡함이라는 문제로 다룬다. 기능을 하나 더할 때마다 코드가 급격히 늘어 사람이 전체 구조를 따라가지 못하면 개발자는 실질적인 통제력을 잃는다. 에이전트가 나중에 정리할 것이라고 믿는 것만으로는 해결되지 않는다. 앞서 남긴 좋지 않은 설계가 후속 작업을 어렵게 만들면 에이전트 자신도 그 비용을 치른다.

모델의 채점과 사람의 검토가 각각 놓치는 것

모델에게 코드 품질을 점수로 매기게 하는 방법은 간단하지만 그 점수가 일관되고 의미 있는지부터 확인해야 한다. 두 구현을 비교하게 해도 이름이나 제시 방식에 따라 선호가 바뀌는 문제가 있다. 큰 모델에서는 이런 효과가 약해질 수 있다는 단서가 붙지만 비교 형식을 바꿨다고 평가의 신뢰성이 저절로 확보되지는 않는다. 루브릭을 주거나 모델이 테스트를 쓰게 하는 접근도 독립적인 평가를 대신하기에는 부족하다.

사람이 직접 읽으면 가독성과 설계 의도를 살피는 데 유리하다. 대신 검토자의 숙련과 취향에 따라 판단이 달라지고 대규모 학습이나 여러 모델·하네스를 비교하는 벤치마크에 적용하기에는 비용이 크다. 수백만 줄을 읽어 계속 변하는 순위를 갱신하는 일은 현실적인 해법이 되기 어렵다. 자동 지표가 필요한 이유와 사람의 판단이 남아야 하는 이유가 함께 존재한다.

줄 수에서 중복과 복잡도의 비중으로

가장 단순한 지표는 변경 전후 코드 줄 수인 LOC의 차이다. Sebastian의 조사와 실험에서는 이 값만으로도 조잡함을 예상보다 잘 포착했다. 다만 줄 수 자체를 최적화 목표로 삼는 순간 코드를 압축하거나 읽기 어렵게 만드는 방향으로 대응할 수 있다. 짧아졌다는 사실만으로 설계가 개선되었다고 판단해서는 안 된다.

SlopCodeBench의 Verbosity는 AST-Grep 휴리스틱이 표시한 줄과 복제 코드 줄의 합집합을 전체 LOC로 나눈 비율이다. 같은 줄이 양쪽에 잡혀도 한 번만 센다. 중복과 불필요하게 장황한 표현이 전체에서 차지하는 비중을 측정하므로 단순한 길이와는 구별된다. 무엇을 불필요하다고 표시할지는 사람이 만든 규칙에 의존한다는 한계도 남는다.

Erosion은 크고 복잡한 함수에 코드의 무게가 얼마나 몰리는지 본다. 함수 f의 무게를 CC(f) × √SLOC(f)로 정의하고 순환 복잡도 CC가 10을 넘는 함수들의 무게 합을 모든 함수의 무게 합으로 나눈다. SLOC는 소스 코드 줄 수이며 CC는 분기 구조의 복잡도를 나타낸다. 긴 함수가 존재한다는 사실보다 큰 함수와 높은 복잡도가 함께 집중되는 정도에 초점을 맞춘 지표다.

평균 차이와 낮은 점수의 함정

블로그가 인용한 비교에서 인간이 유지하는 저장소의 Verbosity는 0.15 ± 0.06, 에이전트 코드에서는 0.33 ± 0.10이었다. Erosion은 각각 0.31 ± 0.17과 0.68 ± 0.20이었다. 두 지표 모두 에이전트 쪽이 평균적으로 대략 두 배 높았다. 이 숫자는 비교 대상에서 관찰한 차이이며 모든 AI 코드와 인간 코드에 적용되는 보편적인 비율은 아니다. 블로그가 ±의 통계적 정의를 따로 설명하지 않으므로 이를 신뢰구간으로 해석하지 않는다.

Sebastian이 직접 만든 바이브 코딩 프로젝트에서도 Verbosity가 0.4, Erosion이 0.75에 이르는 사례가 있었다. 반대로 조잡하다고 느낀 공개 프로젝트가 두 지표에서는 높게 나오지 않는 반례도 있었다. 함수 사이의 강한 결합을 놓쳤거나 관계없는 함수가 많이 들어가 평균을 낮췄을 가능성이 있다. 낮은 점수가 좋은 설계를 보증하지는 않으며 지표가 포착하지 못하는 구조를 따로 살펴야 한다.

반복해서 요구를 바꾸면 설계 부채가 드러난다

SlopCodeBench는 처음부터 요구사항 전체를 한꺼번에 주는 방식 대신 지시와 테스트를 여러 체크포인트로 나눈다. 다음 단계에서는 모델의 컨텍스트를 지우고 이전 작업 디렉터리를 이어받는다. 실제 개발에서 새 요구를 받아 기존 코드를 고치는 과정에 더 가까운 조건이다. 처음에는 통했던 편법이 후속 기능과 충돌하는지, 이전 동작을 유지하면서 구조를 확장할 수 있는지가 중요해진다.

여기서 성공률의 분모를 구분해야 한다. 블로그의 0%는 모든 체크포인트의 테스트를 처음부터 끝까지 통과한 문제의 성공률을 가리킨다. 연결된 논문 v1에서도 20개 문제 중 끝까지 완전히 푼 문제는 없었지만 개별 체크포인트의 Strict 성공률은 0이 아니다. Table 1에서 가장 높은 값은 Opus 4.6의 17.2%다. 이 차이를 빼면 어느 단계에서도 아무 테스트도 통과하지 못했다는 잘못된 해석이 생긴다.

모델 세대도 섞어서는 안 된다. 블로그 각주는 GPT 5.6 sol xhigh 등을 언급하면서 Fable 5.1과 Astra는 아직 시험하지 않았다고 선을 긋는다. 연결 논문 v1의 Table 1은 그와 별개의 모델 목록을 갖는다. 이 글만으로 최신 모델 전부의 성능을 판정하거나 Astra의 실패율을 정할 수는 없다. 엄격한 테스트와 다소 모호한 문제 서술이 결과에 영향을 줄 수 있다는 원문의 유보도 함께 남겨야 한다.

측정은 판단을 없애지 않는다

코드 품질을 수치로 나타내도 사람의 판단은 사라지지 않는다. 중복 탐지 규칙과 복잡도 임계값, 어떤 저장소를 비교군으로 택하는지에 이미 품질관이 들어간다. 따라서 하나의 점수로 좋은 코드를 선언하기보다 점수 변화와 실제 수정 내용을 함께 읽는 편이 타당하다. 원문은 앞으로 함수의 결합도와 코드 변경 빈도, 응집도 같은 방향도 탐색할 대상으로 남긴다.

이 관점에서 대량 생성의 성과는 추가된 코드의 양으로 끝나지 않는다. 다음 요구사항을 처리할 때 얼마나 많은 기존 코드를 다시 만져야 하는지, 사람이 변경 이유를 설명할 수 있는지가 함께 중요하다. 자동 지표는 그런 검토를 시작할 위치를 알려줄 수 있다. 최적화 목표로 고정하면 오히려 품질을 가리는 숫자가 될 수 있다는 경계를 유지해야 한다.

더 생각해보기

• LOC 감소가 개선인지 난독화인지 구별하려면 무엇을 함께 측정해야 하는가.
• 평균 지표를 낮추는 무관한 함수가 늘어날 때 어떤 집계 방식이 필요한가.
• 체크포인트 성공률과 문제 전체 성공률을 팀의 평가 화면에서 어떻게 구분할 것인가.
• 사람이 읽을 수 있는 코드를 유지하는 비용을 에이전트의 생산성 계산에 어떻게 포함할 것인가.
• 결합도·응집도·변경 빈도 중 후속 작업 실패를 가장 먼저 경고하는 값은 무엇인가.