코드의 조잡함 측정하기

LLM이 거의 완벽하게 올바른 코드를 생성하더라도 불필요한 추상화와 중복까지 피하지는 못하며, 기능 추가마다 코드가 급증하면 사람이 프로젝트를 파악하고 통제하기 어려워짐 기능적 정확성은 숨겨진 테스트로 검증해 명확한 보상 신호를 만들 수 있지만, 조잡함 평가에는 여전히 인간의 직관과 취향이 필요하며 AI 심사와 사람의 검토 모두 한계가 있음 SlopCodeBench의 장황성·침식도는 각각 중복·불필요한 코드와 크고 복잡한 함수에 집중된 코드 비중을 측정하며, 에이전트 코드는 기존 저장소보다 평균적으로 약 두 배 높은 값을 기록함 지시와 테스트를 반복하고 체크포인트 사이에 모델 문맥을 지우는 평가에서는 잘못된 설계 결정이 누적됐으며, 모든 체크포인트의 테스트를 통과해야 하는 엄격한 해결률은 최첨단 모델도 0% 였음 코드 줄 수 변화는 조잡함을 가늠하는 데 유용했지만 최적화 목표로 삼으면 의미를 잃을 수 있으며, 함수 간 결합도·코드 변경량·응집도 등으로 측정 범위를 넓힐 필요가 있음 올바른 코드와 조잡하지 않은 코드는 다름 기능적 정확성만으로 불필요한 추상화, 중복, 잘못된 설계 결정을 막을 수는 없음 바이브 코딩에서는 기능 하나를 추가할 때마다 코드 줄 수(LOC)가 폭증하기도 함 매달 수백만 줄이 추가되는 프로젝트는 사람이 따라가기 어려워 인간의 통제력이 줄어듦 코드 줄 수로 개발 진척을 측정하는 일은 무게로 항공기 제작 진척을 측정하는 것에 비유할 수 있음 관리를 맡긴다고 문제가 사라지지는 않으며, 에이전트도 조잡한 코드를 제대로 다루지 못함 Earendil에서 코드 조잡함 측정을 위해 문헌과 업계 사례를 조사한 결과, 일부 통찰력 있는 연구를 제외하면 업계의 평가는 정량적 근거보다 인상에 크게 의존했음 “종단 간 코딩 에이전트”, “코드를 제안하는 데 그치지 않고 출시하는 AI”, “사람 수준의 비용 없이 사람 수준의 평가” 같은 홍보에는 일부 진실이 있지만 한계도 있음 코드 정확성은 생성 결과를 숨겨진 테스트로 검사해 명확한 보상 신호를 얻을 수 있고, 평가 규모를 확대하기도 쉬움 반면 조잡함은 인간의 직관과 취향을 요구하는 경우가 많아 평가 자체가 매우 어려움 AI 심사, 사람 검토, 코드 줄 수의 한계 AI를 심사자로 쓰는 방식은 흔하지만, 관찰상 제대로 작동하는 경우가 드물었음 코드 품질을 1~10점으로 평가하게 하는 단순한 방식은 사실상 난수 생성기에 가까운 수준임 두 해법 A와 B를 비교하게 해...