AI가 쏟아내는 코드의 '슬롭', 숫자로 잴 수 있을까

LLM이 코드를 '맞게' 작성하는 문제는 거의 해결된 것처럼 보인다. 그러나 형식적으로 올바른 코드가 좋은 코드라는 보장은 없다. 불필요한 추상화가 끼어들고, 같은 로직이 복제되고, 국소적으로는 맞지만 전체적으로는 나쁜 결정이 쌓인다. Earendil에서 코드 품질 측정을 맡은 Sebastian은 이 현상을 '슬롭(slop)'이라는 이름으로 정량화하려는 시도를 공개했다. 문제의식은 분명하다. 기능 하나를 추가할 때마다 코드 줄 수가 폭발하고, 월 단위로 수백만 줄이 쌓이는 프로젝트에서는 사람이 그 속도를 따라가지 못해 코드베이스에 대한 통제권을 잃는다.

업계에서 가장 흔히 쓰이는 품질 평가 방식은 LLM을 심판으로 세우는 것이다. 그런데 저자의 관찰에 따르면 이 방식은 거의 작동하지 않는다. 모델에게 코드 품질을 1~10점으로 매기게 하는 가장 단순한 형태는 사실상 난수 생성기와 다를 바 없고, 두 해법 A와 B를 제시하고 더 나은 쪽을 고르게 하는 방식도 변수 이름만 바꾸면 선호가 뒤집힌다. 루브릭을 주거나 LLM이 직접 테스트를 작성하게 하는 접근도 있지만, 슬롭을 걷어내는 수준에는 한참 못 미친다. 사람이 직접 판정하는 방법은 사람이 읽을 수 있는 코드를 유지하는 데는 최선이지만, 여러 모델과 하네스를 비교하는 대규모 벤치마크나 학습에는 확장할 수 없다.

가장 단순한 지표는 코드 줄 수(LOC)의 변화량이다. 저자의 실험에서 이 값은 의외로 슬롭을 잘 잡아냈다. 다만 이 지표를 최적화 목표로 삼는 순간 의미를 잃는다는 아이러니가 따라붙는다. LOC로 진행 상황을 재는 것이 항공기 건조 진행을 무게로 재는 것과 비슷하다는 오래된 격언이 여기서 다시 소환된다.

더 정교한 두 지표는 SlopCodeBench 논문에서 가져왔다. 첫째는 verbosity로, AST-Grep이 플래그한 줄과 클론으로 판별된 줄의 합집합을 전체 LOC로 나눈 값이다. 중복되고 불필요하게 장황한 코드가 얼마나 많은지를 나타낸다. 둘째는 erosion으로, 함수의 질량을 순환 복잡도(CC)와 소스 줄 수 제곱근의 곱으로 정의한 뒤, 순환 복잡도가 10을 넘는 함수들의 질량 합을 전체 함수 질량 합으로 나눈 비율이다. 코드베이스의 무게가 크고 복잡한 소수 함수에 얼마나 몰려 있는지를 보여준다.

수치가 인상적이다. SlopCodeBench 평가에서 생성된 코드와 기존 저장소를 비교하면, 저장소의 평균 verbosity는 0.15±0.06인데 에이전트 코드는 0.33±0.10이었다. erosion은 저장소가 0.31±0.17, 에이전트가 0.68±0.20이었다. 에이전트가 만든 코드가 사람이 쓴 코드보다 평균적으로 약 2배 장황하고 2배 침식돼 있다는 뜻이다. 저자가 직접 바이브 코딩한 프로젝트들도 verbosity가 최대 0.4, erosion이 0.75까지 나왔기 때문에, 이 결과가 평가 환경의 인공물만은 아닐 가능성이 높다.

왜 이런 일이 벌어지는지는 코드의 검증 가능성에서 설명된다. LLM이 코드를 거의 완벽하게 작성할 수 있는 이유는 숨겨진 테스트로 결과를 채점해 명확한 보상 신호를 만들 수 있기 때문이다. 반면 코드의 '슬롭' 여부를 판정하는 일은 인간의 직관과 취향에 의존하며 일반적으로 매우 어렵다. 그래서 업계의 평가 담론이 '엔드투엔드 코딩 에이전트', '인간 수준 평가를 인간 수준 비용 없이' 같은 구호에 기대는 분위기라는 것이 저자의 지적이다.

SlopCodeBench의 평가 설계도 주목할 만하다. 일반적인 코딩 벤치마크가 처음에 전체 지시를 주고 숨겨진 테스트로 채점하는 것과 달리, 이 벤치마크는 지시와 테스트를 여러 라운드로 반복하고 체크포인트 사이에 모델의 컨텍스트를 지운다. 사람이 코딩 에이전트를 실제로 쓰는 방식에 훨씬 가깝다. 그 결과 나쁜 코딩 결정이 시간에 따라 누적되고, 모든 체크포인트에서 모든 테스트를 통과해야 하는 엄격한 solve rate 기준으로는 최신 모델조차 0%를 기록했다. 테스트가 지나치게 엄격하거나 문제 서술이 모호할 수 있다는 단서는 붙지만, 큰 흐름은 유지된다고 저자는 본다. 이 벤치마크는 GPT 5.6 sol xhigh 등에서 시험됐고 Fable 5.1이나 Astra에서는 아직 검증되지 않았다.

실무적으로 이 글은 하루에 수만에서 수십만 줄을 기쁘게 추가하는 팀에 경고를 던진다. LOC 증가량, verbosity, erosion 같은 값을 CI에 넣어 추세를 추적하면 코드베이스가 어느 방향으로 흐르는지 볼 수 있다. 다만 지표를 목표로 삼는 순간 지표가 무의미해진다는 점, 그리고 LLM을 품질 심판으로 세운 게이트는 신뢰하기 어렵다는 점을 함께 기억해야 한다. 저자는 함수 간 결합도, 코드 churn, 응집도 같은 추가 지표를 탐색 중이라고 밝혔다. 참고로 어떤 유명 오픈 프로젝트는 두 지표 모두 낮게 나왔는데, 함수 결합도가 높거나 무관한 함수가 많아 평균이 희석된 결과일 수 있다고 덧붙였다.