#코드 품질
2개의 포스트
코딩이 풀렸다면, 그다음은? — 코드의 '슬롭'을 측정하는 법
LLM은 이제 형식적으로 올바른 코드를 거의 완벽하게 쓴다. 그런데 테스트를 전부 통과한 코드가 왜 한 달 뒤에는 아무도 손댈 수 없는 덩어리가 되는가. Earendil의 세바스티안이 던진 이 질문이 해커뉴스를 뜨겁게 달궜다. 이 글은 그 질문의 뿌리를 1976년 맥케이브의 순환 복잡도까지 거슬러 올라가 추적하고, 그 답으로 등장한 벤치마크 SlopCodeBench의 아키텍처를 수식과 코드 수준에서 뜯어본다. 침식(erosion)과 군더더기(verbosity)라는 두 지표가 어떻게 계산되는지, 왜 프롬프트로는 고쳐지지 않는지, 그리고 2026년 9월 현재 프론티어 모델들이 이 벤치마크 앞에서 어디까지 왔는지를 인터랙티브 도구 여섯 개와 함께 짚는다.
AI가 빨라졌다는 착각을 어떻게 재나 — 89%가 '빨라졌다'는데 6%만 증명하는 생산성의 역설, 그리고 DX Core 4
경영진의 89%가 'AI 덕분에 일이 빨라졌다'고 말한다. 그런데 그 성과를 조직 차원에서 실제로 짚어낼 수 있다고 답한 사람은 단 6%였다. AI는 분명 무언가를 빠르게 만들었는데, 그 무언가가 '가치'인지 '착각'인지 아무도 확신하지 못한다. 이 글은 앞선 n00b 편에서 흘깃 본 SPACE 프레임워크를 정면으로 끌어와, METR의 39%p 인식격차, GitClear가 잰 코드 품질의 숨은 청구서(리뷰 대기 4.6배·재작업 급증·보안 취약점 2.74배), DORA 2025의 'AI는 증폭기'라는 거울 효과, 그리고 이 혼란을 정리하려 나온 DX Core 4(속도·효과·품질·임팩트)까지 — '측정할 수 없으면 관리할 수 없다'는 오래된 진실을 AI 시대의 데이터로 다시 증명한다.