코드의 느슨함 측정: 장황함과 침식 지표

LLM은 테스트를 통과하는 코드를 생성하는 데 매우 능숙해졌습니다. 하지만 정확한 코드도 여전히 엉성할 수 있습니다: 중복된 줄, 불필요한 추상화, 형편없는 설계 선택으로 가득할 수 있죠. 저자가 지적했듯이, "코드가 형식적으로 정확하다고 해서 불필요한 추상화를 도입하거나 중복을 만들거나 전반적으로 나쁜 결정을 내리지 않는다는 의미는 아닙니다." 그 결과 코드 줄 수(LOC)이 폭발적으로 늘어나 인간이 따라가기 어려워지고, 일부 주장과 달리 에이전트도 이 엉성함을 관리하지 못합니다.

LLM을 심판으로 쓰는 것이 왜 효과가 없는가

이 글은 AI를 사용해 코드 품질을 판단하는 일반적인 업계 접근법을 일축합니다. 모델에게 코드를 1~10점으로 평가하도록 요청하는 것은 "기본적으로 난수 생성기와 같습니다." 쌍별 비교(A 대 B)는 불안정합니다: 단순히 솔루션 이름만 바꿔도 모델의 선호도가 뒤집힐 수 있습니다. 루브릭과 LLM이 작성한 테스트는 도움이 되지만 "실제로 엉성함을 제거하는 것과는 거리가 멉니다."

가장 간단한 지표: LOC 변화

놀랍게도 효과적입니다: 단순히 코드 줄 수의 변화를 추적하는 것입니다. 저자는 아이러니를 지적합니다: "우리가 이것을 최적화하기 시작하면 의미 있는 측정이 아니게 될 것입니다."

장황함(Verbosity)

중복되고 불필요하게 장황한 줄을 측정합니다. AST-Grep으로 표시되거나 클론으로 표시된 줄의 비율을 총 LOC로 나눈 값입니다:

장황함 = |AST-Grep 표시 줄 ∪ 클론 줄| / LOC

침식(Erosion)

코드베이스의 질량이 얼마나 몇 개의 크고 복잡한 함수에 집중되어 있는지를 측정합니다. 먼저 함수의 질량을 정의합니다:

질량(f) = CC(f) * sqrt(SLOC(f))

여기서 CC(f)는 순환 복잡도이고 SLOC(f)는 소스 코드 줄 수입니다. 그러면 침식은 순환 복잡도가 10보다 큰 함수가 보유한 총 질량의 비율입니다:

침식 = ∑_{f: CC(f) > 10} 질량(f) / ∑_f 질량(f)

논문 SlopCodeBench에서 소개된 이 두 가지 측정은 저자의 테스트에서 레거시 코드베이스와 LLM이 생성한 엉성함을 꽤 잘 구분했습니다.

핵심 요약

• LLM 심판은 코드 품질에 신뢰할 수 없으며, 이름을 바꾸면 선호도가 뒤집힙니다.
• LOC 변화는 놀랍도록 강력한 엉성함 신호이지만, 직접 최적화하면 깨집니다.
• 장황함은 AST-Grep 표시와 클론 감지를 LOC에 대해 결합합니다.
• 침식은 CC > 10인 함수의 복잡도 질량을 포착합니다.

대규모로 LLM 생성 코드를 배포하는 팀에게 이 지표들은 분위기 기반 평가에 대한 정량적 대안을 제공합니다.