코딩이 해결됐다면, 코드의 조잡함은 어떻게 측정할까?

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