코드 난잡함 측정하기: 지표, 발견 결과, 커뮤니티 인사이트
TL;DR
LLM에 의해 생성된 코드는 형식적으로는 올바르지만 인간이 작성한 코드보다 훨씬 더 난잡할 수 있다. LOC 변화, 어휘량, 침식도와 같은 간단한 지표들은 에이전트가 기존 저장소의 두 배 정도의 어휘량과 침식도를 생성함을 드러내며, 기존 평가 방법은 이러한 품질 저하를 포착하지 못한다.
난잡함 측정의 중요성
숨겨진 테스트를 통과하는 코드에도 불필요한 추상화, 중복된 로직, 나쁜 아키텍처 결정이 포함될 수 있다. 월간 수백만 줄의 코드를 추가하는 대규모 프로젝트에서는 이러한 '난잡함'이 개발자가 숨겨진 기술적 부채를 따라가지 못하게 하여 인간의 주도성을 약화시킨다. 저자는 에이전트가 난잡함을 자율적으로 해결할 수 없다고 주장하며, 정량적 평가가 필수적임을 강조한다.
단순한 평가 접근법은 실패한다
AI가 심판이 되는 것은 신뢰할 수 없다
- LLM에 자신의 코드를 1~10점으로 평가하도록 요청하는 것은 무작위 수 생성기와 같다.
- 쌍별 비교("A vs B")는 불안정하다: 솔루션의 이름만 바꿔도 모델의 선호도가 뒤바뀔 수 있으며, arXiv:2604.16790에서 이를 확인할 수 있다.
- 심지어 정교한 평가 기준이나 LLM이 생성한 테스트도 난잡함을 완전히 제거하지 못한다.
"LLM이 자신이 작성한 코드를 평가하게 하는 것은 적절한 평가의 대안이 아니다." – 저자
인간이 개입하는 방식은 확장성이 없다
- 인간 검토는 가독성을 보장하지만, 훈련 또는 벤치마크 세트에 필요한 양으로 확장할 수 없다.
- 수백만 줄의 코드 검토 비용은 모델 제공업체의 지속적인 순위 매기기 이점보다 크다.
간단한 지표: LOC 변화
코드 수정 후의 순 LOC 변화를 세는 것은 난잡함을 탐지하는 데 놀랍도록 효과적이다. 그러나 저자는 이 지표를 최적화하려는 시도가 굿하트의 법칙을 유발할 수 있다고 경고한다—지표가 목표가 되면, 그 지표는 더 이상 좋은 측정 도구가 되지 않는다.
SlopCodeBench에서 제안하는 연구 기반 지표
논문 SlopCodeBench (arXiv:2603.24755v1)는 기존 코드베이스와 LLM에 의해 생성된 난잡함을 구분하는 두 가지 지표를 도입한다.
어휘량 (Verbosity)
중복되거나 불필요한 어휘적인 줄을 측정한다:
$$ \text{Verbosity} = \frac{|\text{AST‑Grep로 표시된 줄} \cup \text{클론된 줄}|}{\text{LOC}} $$
- AST‑Grep을 통해 수작업 히ュ리스틱으로 구현됨.
침식도 (Erosion)
몇몇 큰 복잡한 함수에 코드 질량이 얼마나 집중되어 있는지를 수치화한다:
$$ \text{mass}(f) = \text{CC}(f) \sqrt{\text{SLOC}(f)} $$ $$ \text{Erosion} = \frac{\sum_{f:,\text{CC}(f)>10}\text{mass}(f)}{\sum_{f}\text{mass}(f)} $$
- CC(f)는 순환 복잡도; SLOC(f)는 소스 줄 수.
실증적 발견
| 데이터셋 | 어휘량 (평균 ± 표준편차) | 침식도 (평균 ± 표준편차) |
|---|---|---|
| 기존 인간 저장소 | 0.15 ± 0.06 | 0.31 ± 0.17 |
| 에이전트가 생성한 코드 (SlopCodeBench) | 0.33 ± 0.10 | 0.68 ± 0.20 |
- 에이전트는 인간 코드보다 어휘량과 침식도를 약 두 배 생성한다.
저자가 직접 작성한 "감성 코드" 프로젝트에 대한 사례 검토에서도 어휘량이 최대 0.4, 침식도가 최대 0.75까지 나타나, 이 효과가 벤치마크에 국한되지 않음을 확인했다.
에이전트가 자가 수정할 수 없는 이유
- SlopCodeBench는 반복적 설정에서 에이전트를 평가한다: 각 지시-테스트 라운드 후 모델의 컨텍스트가 지워지며, 실제 세계에서 코드가 여러 단계를 거쳐 진화하는 상황을 모방한다.
- 나쁜 결정이 누적되어 최신 모델이라도 **엄격한 해결률 0 %**를 기록한다—즉, 모든 체크포인트에서 모든 숨겨진 테스트를 통과하는 모델이 존재하지 않는다.
- 이 극단적인 실패는 AI에 의한 무제한 LOC 증가를 경계해야 함을 경고한다.
커뮤니티 반응과 확장
"난잡함에 대한 가장 중요한 문제는 국소적인 것이 아니라 전역적인 성질이다. 관심의 분리와 같은 아키텍처적 측정이 필요하다." – dherman
"최소 LOC를 최적화하는 것은 실제로 코드 골프를 유도하고, 유지보수가 어려운 일줄 코드를 만들어낼 수 있다." – cjalmeida
"순환 복잡도, 변경 빈도, 작성자 정보와 같은 지표는 이미 내부 대시보드에서 유용하다. 이를 결합하면 난잡함에 대한 더 풍부한 그림을 얻을 수 있다." – pbjerkeseth
"굿하트의 법칙이 논의 없이 언급되었지만, LOC를 최소화하는 것이 실제로 난잡함을 증가시킬지 검토해야 한다." – drsopp
"현재 논의에는 전역적인 아키텍처 지표(예: 결합도, 응집도)가 누락되어 있으며, 대규모 코드베이스에서는 필수적일 수 있다." – dherman
"에이전트가 있더라도 인간의 설계 작업은 여전히 필요하다. 그렇지 않으면 코드베이스는 즉흥적인 기능들의 스파게티가 될 것이다." – cheney_2004
이러한 의견들은 세 가지 반복되는 주제를 강조한다:
- 전역적인 아키텍처 지표 필요 (결합도, 응집도, 계층화).
- 지표 게이밍의 위험 (굿하트의 법칙)과 다중 지표 세트의 중요성.
- 인간의 감독이 여전히 필수적이며, 특히 설계와 유지보수 측면에서.
열린 연구 방향
저자는 미래 연구를 위한 유망한 방향을 제시한다:
- 함수 간 결합도 – 함수들이 얼마나 밀접하게 의존하는지 측정.
- 코드 변경 빈도 (Churn) – 빠른 추가/삭제를 불안정성의 지표로 추적.
- 응집도 – 모듈의 책임이 잘 집중되어 있는지 평가.
- 피드백 루프 – 어휘량/침식도 점수를 LLM 훈련에 다시 피드백하여 더 깨끗한 코드 생성을 유도 (굿하트 효과 모니터링 포함).
실무자들을 위한 실질적 통찰
- LOC 변화를 빠른 검증 도구로 사용하되, 하드 타겟이 아니라 히ュ리스틱으로 간주하라.
- AST‑Grep 또는 유사한 정적 분석 파이프라인을 활용해 어휘량과 침식도를 구현하여 중복되거나 과도하게 복잡한 코드를 탐지하라.
- 다양한 지표(복잡도, 변경 빈도, 결합도)를 결합하여, 단일 지표가 게이밍되는 위험을 완화하라.
- 아키텍처 결정에 대해 인간 검토 주기를 유지하라. 자동화된 지표는 문제를 드러낼 수 있지만, 설계 판단을 대체할 수는 없다.
- 반복적 개발을 모방하는 벤치마크(SlopCodeBench처럼)를 설계하라. 많은 개선 단계를 거친 후에야 나타나는 난잡함을 드러내기 위해.
결론
LOC 변화, 어휘량, 침식도와 같은 정량적 지표는 코드 난잡함에 대한 구체적인 시각을 제공하며, 현재 LLM 에이전트가 인간 코드보다 약 두 배 더 어휘적이고 침식된 코드를 생성함을 드러낸다. 이러한 지표는 유용하지만, 굿하트의 법칙을 피하고 유지보수가 가능한 소프트웨어를 보장하기 위해 전역적인 아키텍처적 성질과 인간 감독을 포함하는 보다 포괄적인 다차원 평가 전략의 일부여야 한다.
Sources
관련
- Dispatch
- Dispatch
- Dispatch
- Dispatch
- Dispatch