LLM은 이제 형식적으로 올바른 코드를 거의 완벽하게 쓴다. 그런데 테스트를 전부 통과한 코드가 왜 한 달 뒤에는 아무도 손댈 수 없는 덩어리가 되는가. Earendil의 세바스티안이 던진 이 질문이 해커뉴스를 뜨겁게 달궜다. 이 글은 그 질문의 뿌리를 1976년 맥케이브의 순환 복잡도까지 거슬러 올라가 추적하고, 그 답으로 등장한 벤치마크 SlopCodeBench의 아키텍처를 수식과 코드 수준에서 뜯어본다. 침식(erosion)과 군더더기(verbosity)라는 두 지표가 어떻게 계산되는지, 왜 프롬프트로는 고쳐지지 않는지, 그리고 2026년 9월 현재 프론티어 모델들이 이 벤치마크 앞에서 어디까지 왔는지를 인터랙티브 도구 여섯 개와 함께 짚는다.
지난 1년 사이 많은 개발팀이 같은 장면을 겪었다. 처음 두 주는 마법 같다. 기능이 하루에 하나씩 붙고, 테스트는 초록불이고, 커밋 그래프는 아름답다. 그러다 6주쯤 지나면 이상한 일이 벌어진다. 새 기능 하나를 붙이는 데 갑자기 이틀이 걸린다. 에이전트에게 시켜도 자꾸 엉뚱한 곳을 고친다. 파일을 열어 보면 1,000줄짜리 main() 함수가 있고, 그 안에 아홉 개의 elif 가지가 거의 똑같은 인자 파싱 코드를 아홉 번 반복하고 있다.
그런데 테스트는 전부 통과한다.
이 불일치가 2026년 소프트웨어 공학의 가장 불편한 빈칸이다. 우리는 "코드가 맞는가"를 재는 도구는 아주 잘 갖췄지만, "이 코드를 다음 달에도 고칠 수 있는가"를 재는 도구는 사실상 갖추지 못했다. 2026년 9월 10일, Earendil의 세바스티안이 「코드의 슬롭을 측정하기」라는 짧은 글로 이 빈칸을 정면으로 겨눴고, 해커뉴스에서 266점과 200개가 넘는 댓글이 달리며 격렬한 논쟁이 붙었다.
글의 도입부 문장이 논쟁의 핵심을 요약한다.
이 글은 그 짧은 글을 출발점으로 삼되, 거기서 멈추지 않는다. 왜 이런 개념이 나와야 했는지를 1976년까지 거슬러 올라가 추적하고, 그 답으로 제시된 벤치마크 SlopCodeBench의 아키텍처를 수식과 실제 코드 수준에서 해부하며, 2026년 9월 현재 프론티어 모델들이 그 앞에서 어디까지 왔는지까지 본다. 용어가 생소해도 괜찮다. 하나씩 풀어 간다.
소프트웨어를 숫자로 재려는 시도의 첫 단추는 LOC(lines of code, 코드 줄 수) 였다. 1970~80년대 대형 조직은 프로그래머 생산성을 "월 몇 줄"로 관리했고, 품질은 "KLOC당 결함 수"로 관리했다. 문제가 뭔지는 모두가 알았다. 빌 게이츠가 남긴 것으로 널리 인용되는 문장이 그 정서를 그대로 담는다.
그럼에도 LOC는 죽지 않았다. 놀랍도록 잘 작동했기 때문이다. 뒤에서 다시 보겠지만, 세바스티안은 "내 연구와 테스트에서 단순히 LOC 변화량을 보는 것이 슬롭 지표로 놀라울 만큼 효과적이었다"고 썼다. 다만 거기엔 아이러니한 단서가 붙는다. 그것을 최적화하기 시작하는 순간, 의미 있는 측정이기를 그만둔다. 굿하트의 법칙이다.
LOC의 대안으로 지금까지 살아남은 거의 유일한 지표가 1976년 토머스 맥케이브(Thomas McCabe)의 순환 복잡도(cyclomatic complexity, CC)다. 이 글 전체에서 계속 나올 개념이니 여기서 확실히 해두자.
아이디어는 간단하다. 프로그램을 제어 흐름 그래프로 그린다. 실행 경로가 갈라지는 지점(if, while, for, and, or, case…)마다 그래프에 가지가 하나씩 생긴다. 맥케이브는 이 그래프의 독립적인 경로 개수를 세는 공식을 제안했다.
여기서 는 그래프의 간선 수, 은 노드 수, 는 연결 성분 수다. 실무에서는 훨씬 단순한 등가 공식을 쓴다 — 분기점의 개수 + 1.
def classify(x): # CC = 1 (기본 경로)
if x < 0: # +1 → 2
return "neg"
elif x == 0: # +1 → 3
return "zero"
for d in digits(x): # +1 → 4
if d == 7: # +1 → 5
return "lucky"
return "pos"
# 최종 CC = 5맥케이브는 10을 상한선으로 권고했다. CC가 10을 넘는 함수는 테스트로 모든 경로를 덮기 어렵고, 사람이 머리에 담기 어렵다는 경험칙이었다. 이 숫자 10은 50년이 지난 지금도 살아 있다. 파이썬 정적 분석 도구 Radon이 복잡도 등급을 매기는 기준도 10이고, SlopCodeBench의 침식 지표가 "고복잡도 함수"를 정의하는 기준도 정확히 10이다. 50년 된 경험칙 하나가 2026년 AI 벤치마크의 한가운데 박혀 있다.
CC 이후, 소프트웨어가 시간에 따라 나빠진다는 현상 자체에 이름을 붙이려는 시도가 이어졌다. 이 계보를 알면 SlopCodeBench가 왜 한 시점의 스냅샷이 아니라 궤적을 재는지가 단번에 이해된다.
여기까지의 요점 하나. 이 모든 도구는 "사람이 수십 년에 걸쳐 천천히 쌓는 부채"를 재려고 만들어졌다. 레만은 릴리스 단위로, 커닝햄은 분기 단위로, 파나스는 제품 수명 단위로 생각했다. 2026년의 문제는 그 시간 축이 하루 단위로 압축되었다는 것이다.
세바스티안의 진단은 명쾌하다. 코드는 확장 가능하고(scalable) 검증 가능하기(verifiable) 때문이다.
이 고리가 있었기에 코딩 능력은 다른 어떤 영역보다 빠르게 올라갔다. 그런데 슬롭에는 이 고리가 없다. "이 코드가 지저분한가"를 판정하려면 사람의 직관과 취향이 필요하고, 그것을 자동 채점기로 바꾸는 것은 일반적으로 대단히 어려운 일이다.
세바스티안이 업계를 돌아본 소감은 신랄하다. "몇몇 통찰력 있는 논문을 빼면, 지금 업계가 얼마나 '느낌 기반(vibes based)' 인지에 실망했다." X와 마케팅 문구는 "엔드투엔드 코딩 에이전트", "제안하는 게 아니라 배포까지 하는 AI", "사람 수준의 평가를 사람 수준 비용 없이"로 도배되어 있었다고 그는 쓴다.
이 현상이 정말 있는지 의심할 수 있다. 그래서 서로 다른 방법론의 관측 세 개를 먼저 놓는다.
① GitClear — 6억 2,300만 건의 코드 변경
깃 히스토리 분석 회사 GitClear가 2023~2026년의 코드 변경 6억 2,300만 건을 분석한 2026년 보고서는 지금까지 나온 것 중 가장 큰 규모의 현장 관측이다. 2026년 상반기 커밋의 약 25%에서 AI 사용 흔적이 감지되었다.
"파일 간 함수 호출 −35%"가 특히 의미심장하다. 재사용 대신 복제를 택하고 있다는 뜻이다. 그리고 "리팩터링 −70%"는 레만 제2법칙의 유일한 해독제 — 복잡도를 줄이는 별도의 작업 — 가 말라붙고 있다는 신호다.
② METR — 통제된 무작위 실험
2025년 7월 METR이 발표한 무작위 대조 시험은 다른 각도에서 찌른다. 평균 5년간 자기 저장소에 기여해 온 숙련 개발자 16명에게 246개의 실제 과제를 주고, 과제별로 AI 사용 허용/금지를 무작위 배정했다. 결과는 AI를 쓸 때 19% 더 느렸다. 정작 참가자들은 실험 후에도 자신이 20% 빨라졌다고 추정했다.
이 39퍼센트포인트의 간극이 왜 이 문제가 자율 교정되지 않는지를 설명한다. 체감으로는 나아지고 있으므로, 아무도 멈춰 서지 않는다.
③ 인지 부채
2026년 2월 사이먼 윌리슨이 정리한 인지 부채(cognitive debt) 개념은 세 번째 차원을 더한다. 기술 부채가 코드에 쌓인다면, 인지 부채는 사람의 머릿속에 쌓인다. 구현을 직접 읽지 않으면 자기 프로젝트의 심상 모델을 잃고, 다음 기능마다 추론이 더 어려워지며, 판단의 확신이 줄어든다. 한 학생 팀 사례에서 진짜 장애물은 지저분한 코드가 아니라 아무도 설계 결정을 설명할 수 없게 된 상태였다.
여기서부터가 Earendil 글의 뼈대다. 세바스티안은 측정 방법을 네 가지로 나눠 하나씩 검토한다.
업계에서 가장 흔한 방법이다. 그리고 세바스티안의 관찰로는 거의 작동하지 않는다.
가장 순진한 형태 — "이 코드 1~10점 중 몇 점?" — 은 "사실상 난수 생성기와 같다." 좀 더 정교한 형태인 A/B 쌍대 비교는 낫지만, 해답의 이름을 바꾸는 것만으로 모델의 선호가 뒤집히는 문제가 있다.
여기 인용된 논문 「Bias in the Loop: Auditing LLM-as-a-Judge for Software Engineering」(2026년 4월)은 이 현상을 체계적으로 감사했다. 코드 생성·수정·테스트 생성 세 과제에서 제시 단서를 하나씩만 바꾸는 통제 실험을 돌린 결과는 이렇다.
| 관측 | 의미 |
|---|---|
| 같은 사례를 반복 평가하면 판정이 엇갈린다 | 재현성 자체가 흔들린다 |
| 작은 프롬프트 수정이 결과를 뒤집는다 | 측정이 아니라 유도에 가깝다 |
| 의미를 보존하는 변형에도 판정이 갈린다 | 코드가 아니라 표현을 보고 있다 |
| 효과가 모델 순위 자체를 바꿀 만큼 클 때가 있다 | 벤치마크 결론이 프롬프트의 인공물일 수 있다 |
세바스티안은 공정하게 덧붙인다. "조금 과장해서 말하고 있고, 큰 모델일수록 효과는 덜 두드러진다. 하지만 요점은 그대로다. LLM에게 자기가 쓴 코드를 심사하게 하는 것은 제대로 된 평가의 대체물이 아니다."
직접 만져 보자. 아래에서 코드는 한 글자도 바꾸지 않고 보여 주는 방식만 바꿔 보면 된다.
소프트웨어 엔지니어의 실력 편차를 잠시 무시한다면, 이것이 코드가 사람이 읽을 수 있는 상태로 남도록 보장하는 최선의 방법이다. 문제는 확장성이다. AI를 학습시키거나, 여러 모델 제공사와 하네스를 아우르는 큰 벤치마크를 만드는 데는 쓸 수 없다.
세바스티안의 각주가 이 답답함을 잘 표현한다. "모델 제공사 순위가 계속 바뀌는 걸 보자고 누구에게 수백만 줄을 리뷰하라고 강요하고 싶지는 않다."
여기서 반전이 있다. 그냥 코드 줄 수의 변화를 보는 것이 슬롭 지표로 놀라울 만큼 잘 작동했다는 것이다. 이는 SlopCodeBench 논문의 부록 G에서도 확인된다. 다음 체크포인트의 비용을 예측하는 능력에서 LOC는 다른 어떤 지표보다 강했다(상관계수 0.534).
다만 굿하트의 법칙이라는 치명적 단서가 붙는다. 이것을 목표로 최적화하기 시작하면 의미 있는 측정이기를 그만둔다. 해커뉴스에서도 이 지점에서 가장 날카로운 대립이 있었다.
이 긴장은 해소되지 않았다. 다만 한 댓글이 유용한 절충안을 제시했다. "그 지표가 우리가 진짜 원하는 것이라면, 그것에 최적화되는 것은 괜찮다." 문제는 대리 지표(proxy)일 때다.
세바스티안이 "유망해 보였다"며 소개하는 나머지 둘이 이 글의 본론이다. 이 두 지표는 논문 SlopCodeBench에서 왔고, 그가 주목한 이유는 하나다 — 레거시 코드베이스와 LLM 슬롭을 꽤 잘 분리해 냈기 때문이다.
그러면 그 논문부터 제대로 뜯어보자.
SlopCodeBench: Benchmarking How Coding Agents Degrade Over Long-Horizon Iterative Tasks Gabriel Orlanski, Devjeet Roy, Alexander Yun, Changho Shin, Alex Gu, Albert Ge, Dyah Adila, Frederic Sala, Aws Albarghouthi 위스콘신-매디슨 대학 외 · arXiv:2603.24755 (2026년 3월 25일) · scbench.ai
논문의 첫 문장이 전체를 규정한다.
기존 벤치마크는 이 실패 모드를 체계적으로 과소 측정한다. 완성된 명세를 한 번에 주고 한 번만 채점하기 때문이다. 그것은 "지금 명세에 맞는 올바른 코드를 만들 수 있는가"를 재는 것이지, "그 코드가 미래의 변화를 견디는가"를 재는 것이 아니다.
최근 나온 반복형 벤치마크들도 저마다 다른 이유로 이 신호를 잃는다.
| 기존 접근 | 방식 | 왜 이걸로는 못 재는가 |
|---|---|---|
| SWE-bench 계열 | 실제 깃허브 이슈 + 실패→통과 테스트 제공 | 단발성. 에이전트가 자기 설계의 결과를 만날 일이 없다 |
| CodeFlowBench | 턴마다 반복 과제를 준다 | 이전 턴의 정답 코드를 대신 넣어 준다. 매 턴이 깨끗한 상태에서 시작 — 인과 사슬이 끊긴다 |
| MaintainCoder | 수정을 한 번 시킨다 | 궤적이 형성되지 않는다 |
| EvoClaw | 7개 저장소·98개 마일스톤, 에이전트 코드를 보존 | 통과/실패만 잰다. 품질 저하는 관측되지 않는다 |
| 커밋 히스토리 기반 | 성숙한 오픈소스의 실제 진화 경로를 사용 | 오염 위험. 프론티어 모델의 학습 데이터에 그 저장소와 커밋 히스토리가 이미 들어 있을 가능성이 높다 |
특히 CodeFlowBench 방식의 함정이 결정적이다. 매 턴 정답 코드로 교체해 주면, 초기 결정에서 후기 열화로 이어지는 인과 사슬 자체가 제거된다. 그러면 측정하려던 바로 그것이 사라진다.
그래서 저자들은 네 가지를 못 박았다. 이것이 SlopCodeBench의 뼈대다.
각 문제 는 순서가 있는 체크포인트 목록 이다. 체크포인트 는 명세 와 테스트 스위트 의 짝이다. 에이전트 는 현재 명세와 자신의 이전 작업 공간을 받아 갱신된 작업 공간 를 만든다.
에서는 빈 작업 공간 에서 시작한다. 수식은 단순하지만 여기 담긴 두 가지 선택이 이 벤치마크의 전부다.
*.py를 하드코딩한 해답은 모든 테스트를 통과한다. 하지만 가 오면 파일 탐색 헬퍼를 뜯어내고 main을 재구조화해야 다국어 지원을 넣을 수 있다.논문 Figure 1. 명세가 갱신될 때마다 에이전트는 자기 이전 해답을 확장한다. 파일 단위 diff가 체크포인트마다 커진다 — main.py +100, 그다음 +260.
논문은 code_search 문제를 계속 예로 든다. ast-grep에서 영감을 받은, 소스 파일을 의미 기반으로 검색하는 CLI 도구를 다섯 체크포인트에 걸쳐 짓는다.
아래 위젯으로 직접 걸어 보자. 각 체크포인트에서 에이전트가 무엇을 받고, 무엇을 이어받고, 무엇을 잃는지를 보면 이 벤치마크의 설계 의도가 한눈에 들어온다.
핵심은 이것이다. 에서 언어별 로직을 하드코딩한 에이전트는 와 에서 연쇄적인 재작성에 직면한다. 확장 가능한 파서 인터페이스를 지은 에이전트는 그렇지 않다. 첫 체크포인트의 이 구조적 선택이, 슬롭이 쌓이느냐 갇히느냐를 결정한다.
각 체크포인트의 테스트는 서브프로세스나 서비스 중인 API를 통해서만 해답과 상호작용한다. 테스트는 네 종류로 분류된다.
| 테스트 종류 | 내용 |
|---|---|
| Core | 명세에 명시적으로 언급되거나 예시로 제시된 기능 |
| Error | 실패 모드에서의 동작 |
| Functionality | 정확성을 빠짐없이 검사하는 숨은 테스트 |
| Regression | 이전 체크포인트의 모든 테스트. 에는 없다 |
여기서 파생되는 네 가지 점수가 결과표를 읽는 열쇠다.
에이전트가 중간에 실패하거나 크래시하면 남은 체크포인트는 0점 처리된다. 침식과 군더더기는 작업 공간을 실제로 만들어 낸 체크포인트에서만 계산하고, 빠진 체크포인트는 보간하지 않고 제외한다.
하네스 선택은 의도적이다. 논문의 설명은 이렇다. "프론티어 모델은 범용 에이전트 루프가 아니라 자기 제공사의 하네스에 맞춰 학습된다. 그리고 압도적 다수의 개발자가 이 CLI 도구를 통해 에이전트와 상호작용한다." MiniSWEAgent 같은 프레임워크는 순수한 모델 능력을 재기엔 유용하지만, 실제 개발자의 작업 방식을 반영하지 않는다는 것이다.
프롬프트도 최소한으로 고정했다. 요구사항은 딱 둘 — requirements.txt를 갱신할 것, 이름 붙은 엔트리포인트 스크립트를 쓸 것. 좋은 코딩 전략의 부담을 전적으로 에이전트와 하네스에 지운다.
이제 세바스티안이 "유망해 보였다"고 한 그 두 지표를 정확히 뜯어보자.
무엇을 잡으려는 지표인가. 반복 작업 상황에서 에이전트는 새 로직을 집중된 작은 함수들로 나누는 대신 기존 함수 안에 덧대는 경향이 있다. 논문의 표현으로는 "기능을 땜질하는 되는대로의 수정(haphazard edits)"이다. 이 수정들은 천천히 쌓이다가 결국 손대기 어려운 거대 함수가 된다.
논문 Listing 1. code_search의 시점 find_matches_in_file() — 총 117줄. exact / regex / pattern 분기가 차례로 덧대어지고, 거의 모든 결정점 질량이 이 함수 하나에 모인다.
어떻게 계산하는가. 먼저 각 호출 가능 객체(callable)에 복잡도 질량을 부여한다.
는 순환 복잡도, 는 소스 줄 수다. 여기서 제곱근이 왜 있는지가 이 지표 설계의 핵심이다. 논문의 설명은 이렇다 — "제곱근은 크기 요소를 압축해서, 순수한 줄 수가 아니라 복잡도가 지배하게 만든다."
무슨 뜻인가. 줄 수를 그대로 곱하면 "길지만 단순한 함수"(예: 200줄짜리 설정 딕셔너리)가 과대 평가된다. 반대로 크기를 아예 빼면 "짧지만 분기가 촘촘한 함수"만 잡힌다. 제곱근은 그 사이의 절충이다. 길이는 인정하되, 가중치는 분기에 둔다.
그다음 침식은 고복잡도 함수가 차지하는 질량의 비율이다.
는 모든 호출 가능 객체의 집합이고, 임계값 10은 앞서 본 Radon의 관례를 따른 것이다(그리고 그 뿌리는 1976년 맥케이브).
이 정의의 영리한 점은, 주변에 함수를 더 만들어도 점수가 좋아지지 않는다는 데 있다. 논문의 표현대로 "나중 체크포인트가 분기를 더한다는 것이 문제가 아니라, 결정점 부하가 점점 더 find_matches_in_file() 안으로 무너져 들어간다는 것이 문제다." 주변에 함수를 백 개 만들어도 그 함수의 질량 비중은 계속 올라간다.
직접 계산해 보자. 아래에서 임계값과 크기 항을 바꿔 가며 같은 코드베이스가 어떻게 다르게 보이는지 확인할 수 있다.
민감도는 어떤가. 부록 G가 이 질문에 답한다. 임계값(8, 10, 12)과 크기 항(없음, , 선형 SLOC)을 조합한 아홉 가지 변형을 전부 돌려도 결론은 안정적이었다.
| 지표 | 다음 체크포인트 통과율과의 상관 | 다음 체크포인트 비용과의 상관 |
|---|---|---|
| 침식 (논문 정의) | −0.003 | +0.127 |
| 최적 변형 (CC>8 + 선형 SLOC) | −0.003 | +0.129 |
| LOC | −0.199 | +0.534 |
| 평균 CC | −0.064 | +0.179 |
| 최대 CC | −0.056 | +0.323 |
| 클론 비율 | +0.071 | +0.216 |
| AST-grep 적발 / LOC | −0.094 | +0.084 |
이 표를 어떻게 읽어야 하는가. 침식은 다음 체크포인트의 통과 여부를 거의 예측하지 못한다(−0.003). 대신 비용을 예측한다. 그리고 이것이야말로 침식이 재려던 것이다 — 침식은 "깨졌는가"의 지표가 아니라 "고치기 비싼가"의 지표다. 기술 부채라는 커닝햄의 은유가 34년 만에 숫자를 얻은 셈이다. (참고로 순수 LOC가 비용 예측에서는 여전히 가장 강하다는 사실도 정직하게 보고되어 있다.)
슬롭의 다른 축은 너무 장황한 코드 — 복붙되었거나, 전체에 아무것도 더하지 않는 불필요한 줄이다.
논문 Listing 2. filter 대신 항등 리스트 컴프리헨션, 반복 구조를 짜는 대신 빈 값 체크, 한 번만 쓰이는 변수들. 논문의 지적대로 국소 문법만의 문제가 아니라, 정보를 거의 담지 않는 중간 구조를 만들어 낸다는 점이 핵심이다.
계산은 두 부분의 합집합이다.
scb-check)에는 197개의 AST-Grep 규칙이 들어 있다. "의미를 보존한 채 응축할 수 있는 코드"의 전형적 패턴들이다.두 지표를 나눠 재는 이유는 서로 다른 실패 모드이기 때문이다. 코드가 짧고 깨끗한데 한 함수에 모든 분기가 몰릴 수도 있고(높은 침식 / 낮은 군더더기), 함수는 잘게 쪼갰는데 같은 코드가 스무 번 복사되어 있을 수도 있다(낮은 침식 / 높은 군더더기). 둘 다 봐야 슬롭의 온전한 그림이 나온다.
그 규칙들이 실제로 어떻게 생겼는지 보자. 이걸 보면 "슬롭"이라는 모호한 단어가 놀랍도록 구체적으로 조작 가능한 것이라는 점이 실감 난다.
논문 Table 1. 25개 설정, 11개 모델. 단일 하네스 버전, high thinking, just-solve 프롬프트 기준.
Earendil 글이 인용한 "최첨단 모델조차 strict 통과율 0%" 는 정확히는 문제 단위 엔드투엔드 0% 를 말한다. 체크포인트 단위로 보면 Opus 4.6이 17.2%로 최고였다. 어느 쪽이든 요점은 같다. 하나의 문제를 처음부터 끝까지 결함 없이 관통한 모델이 없다.
논문 Figure 2. 왼쪽: 체크포인트가 진행될수록 Core와 Iso의 격차가 1.4배에서 13.3배로 벌어지고, 회귀를 포함한 Strict는 마지막에 0.5%로 무너진다. 오른쪽: 체크포인트당 평균 비용은 $1.46에서 $4.17로 2.9배 늘어난다.
비용은 2.9배 늘어나는데 정확도는 개선되지 않는다. 돈을 더 쓰는 것이 답이 아니라는 뜻이다. 그리고 감소분의 대부분은 에러 처리 테스트에서 나온다 — 코어와 기능 테스트 통과율은 상대적으로 안정적이다.
논문 Figure 3. 제공사별 대표 모델 6개. 두 지표 모두 단조 증가한다.
| 궤적 통계 | 값 |
|---|---|
| 침식이 상승한 궤적의 비율 | 80% |
| 군더더기가 상승한 궤적의 비율 | 89.8% |
| 고복잡도(CC>10) 함수 개수 평균 | 4.1개 → 37.0개 |
| 최대 CC 평균 | 27.1 → 68.2 |
| 구조적 중복 증가폭 | +66% (궤적의 72.1%에서) |
| AST-grep 위반 밀도 증가폭 | +15.6% |
논문의 진단이 정확하다. "동인은 단순히 코드가 많아진 것이 아니다. 점점 늘어나는 고복잡도 함수 집합으로 결정점 부하가 집중되는 것이다."
circuit_eval의 main()이 논문에서 딱 하나만 기억해야 한다면 이것이다.
논문 Listing 3. Opus 4.6이 circuit_eval의 에서 만든 main(). 1,099줄짜리 디스패처 안에서 아홉 개의 명령 분기가 같은 파싱 로직을 반복한다. opt 분기 하나만 312줄이고 플래그가 13개다.
CC 285짜리 함수가 어떤 물건인지 감이 안 온다면 이렇게 생각하면 된다. 맥케이브의 권고 상한이 10이다. 285는 그 28배다. 이 함수의 모든 경로를 테스트로 덮으려면 최소 285개의 독립 경로를 커버해야 한다. 사람이 이 함수를 머릿속에 담는 것은 불가능하다.
그런데 각 체크포인트에서 이 함수는 테스트를 통과했다. 통과율 벤치마크는 이 사태를 전혀 보지 못한다.
저자들은 파이썬 저장소 48개를 기준선으로 삼았다. 깃허브 스타 수로 세 등급으로 나눴고, flask·django·fastapi 같은 웹 프레임워크, scikit-learn·scipy·statsmodels 같은 과학 계산, airflow·celery·ansible 같은 인프라 도구, tqdm·structlog·click 같은 작은 유틸리티까지 걸쳐 있다. 규모는 634줄부터 114만 줄까지.
에이전트 코드는 평균적으로 사람 코드보다 대략 두 배 장황하고 두 배 침식되어 있다. 세바스티안은 여기에 자기 검증을 덧붙였다. "내가 직접 바이브 코딩한 프로젝트들을 조사해 보니 상당수가 군더더기 0.4, 침식 0.75에 달했다. 그러니 이 결과가 단지 평가 환경의 인공물은 아닐 것이다."
몇 가지 세부가 이 비교를 더 단단하게 만든다.
그리고 더 중요한 것은 시간에 따른 변화다. 저자들은 그중 20개 저장소의 깃 히스토리에서 커밋을 최대 30개씩 뽑아 568개의 시간축 체크포인트를 만들었다.
| 사람 저장소 | 에이전트 궤적 | |
|---|---|---|
| 군더더기가 증가한 비율 | 67% | 89.8% |
| 처음→마지막 증가폭 중앙값 | 25% | 43% |
| 침식이 증가한 비율 | 55% | 79% |
| 궤적의 모양 | 평평하다 (plateau) | 단조 증가한다 |
논문의 한 줄 요약. "관리되는 소프트웨어도 나빠질 수 있다. 하지만 에이전트 궤적은 더 자주, 더 큰 폭으로 나빠진다."
여기에 저자들이 스스로 던진 반론과 그 답이 있다. 시간축 패널은 2005년부터 2026년까지 걸쳐 있으니, ChatGPT 이후 커밋에는 LLM이 도운 기여가 섞여 있을 수 있다. 확인해 보니 ChatGPT 이전 체크포인트(n=414)의 군더더기 중앙값은 0.134, 이후(n=154)는 0.148로 거의 차이가 없었다. 오염의 증거는 없다는 것이다.
논문 v1은 20문제·93체크포인트·11모델이었다. 공개 리더보드는 그 뒤로 계속 커져서 36문제·196체크포인트·19모델 규모가 되었다(v1.0, 2026년 4월 24일 갱신본 기준). 정렬 기준을 바꿔 보면 재미있는 것이 보인다 — 잘 푸는 모델과 깨끗하게 쓰는 모델은 같지 않다.
가장 현실적인 질문이다. "안 지저분하게 짜라고 시키면 되지 않나?"
저자들도 그걸 물었다. 두 가지 품질 프롬프트를 만들어 GPT 5.4와 GPT 5.3 Codex에 붙였다.
결과는 이렇다.
직접 확인해 보자.
이 결과를 어떻게 읽어야 하는가. 두 가지 함의가 있다.
첫째, 품질 프롬프트는 무용하지 않다. 침식을 절반으로 줄이는 것은 실제 효과이고, 오래 가는 코드베이스에서는 그 절반이 곧 몇 달치 차이다. 무료가 아닐 뿐이다.
둘째, 그리고 더 중요하게 — "깨끗하게 짜라"고 말하는 것으로는 열화의 동역학을 멈출 수 없다. 논문 결론부의 문장이 이 지점을 정확히 짚는다. "당장의 다음 질문은 이 열화를 늦추는 것이 아니라 멈출 수 있는가이다. 프롬프트 압력은 출발점을 바꾸지만 속도는 바꾸지 못한다. 체크포인트를 가로질러 구조적 규율을 강제하는 개입 — 학습 시점이든 도구를 통해서든 — 은 아직 시험되지 않았다."
그리고 여기에 아주 불편한 관측 하나가 붙는다. 침식을 반으로 줄이고 군더더기를 3분의 1 깎아도, 모든 통과율 하위 지표는 그대로였다. 즉 이 지표들은 정확성과 직교한다. 이것은 약점이 아니라 오히려 존재 이유다 — 통과율이 이미 재고 있는 것을 또 재는 지표라면 만들 이유가 없다.
논문은 3월 것이다. 그 사이 프론티어 모델 세대가 두 번 바뀌었다. 그래서 흥미로운 것은 논문 이후의 독립 재현들이다.
HumanLayer의 덱스 호시(dex horthy)가 이 벤치마크를 직접 돌린 두 편의 보고가 해커뉴스에서 405점을 받으며 널리 읽혔다. 그의 출발점이 재미있다.
1차 실행 (Opus 5 / Opus 4.8 / Sonnet 5, 3문제 17체크포인트)
| 모델 | Strict 통과 | 슬롭 규칙에 걸린 줄 비율 |
|---|---|---|
| Opus 5 | 4/17 (24%) | 93% |
| Opus 4.8 | 1/17 (6%) | 98% |
| Sonnet 5 | 1/17 (6%) | 89% |
2차 실행 (Fable 5 / GPT-5.6 Sol / Kimi K3, 6문제 30체크포인트)
Fable 5와 Sol이 33.3%(10/30) 로 동률, Kimi K3가 26.7%와 23.3%로 뒤따랐다. 세 모델 다 마지막 체크포인트까지 무결점으로 도달한 문제는 하나도 없었다.
그의 총평이 정확하다. "이건 어려운 벤치마크다. 갓 나온 모델도 35%를 못 넘는다 — 2024년 SWE-Bench 수준, 소넷 3.5 시절이다."
몇 가지 관측이 특히 흥미롭다.
circuit_eval에서 중복 비율이 4.6%에서 16.8%로 올랐다. 변곡점은 ck3 — 새 요구사항이 초기 설계와 싸우기 시작하는 지점이었다. Opus 5는 2.41%에서 2.64%로 사실상 평평했다.덱스가 제안한 아이디어가 이 논의에서 가장 실용적인 다음 걸음일지 모른다. 정적 지표를 더 정교하게 만드는 대신, 품질을 행동으로 정의하자는 것이다.
이 설계의 아름다움은 정의가 순환하지 않는다는 데 있다. "좋은 코드"를 규칙 목록으로 정의하는 대신 "다음 사람(또는 더 약한 모델)이 이어받을 수 있는 코드" 로 정의한다. 그리고 그것은 결정적으로 검증 가능하다.
덱스의 지적도 날카롭다. "Fable이나 Sol 같은 프론티어 모델은 아마 가장 끔찍한 코드베이스에서도 일을 해낼 것이다. 하지만 잘 정돈된 코드베이스는 더 짧고 토큰 효율적인 해결로 이어질 것이다." 즉 프론티어 모델의 압도적 능력이 오히려 품질 신호를 가린다. 약한 모델에게 넘겨야 신호가 증폭된다.
이 주제는 감정을 건드린다. 200개가 넘는 댓글에서 반복된 반론 네 가지를 정리한다.
가장 많이 나온 반론이다. "특히 엔터프라이즈 레벨에서, 사람이 쓴 코드 상당수는 AI가 자동화하기 한참 전부터 저품질이었다." 다른 이는 비교 자체가 불공정하다고 했다 — "이 작은 원샷 클로드 취미 프로젝트의 품질을 보라, 세계 최고 개발자들이 쓴 거대 오픈소스보다 못하다"는 식이라는 것이다.
이에 대한 가장 설득력 있는 반박은 시간 축을 지적한다.
또 다른 관점도 유효하다. "이제는 같은 사람들이 AI로 무장해서 저품질 코드를 20배 더 많이 배포한다." 문제가 새로 생긴 게 아니라 속도가 바뀐 것이라는 진단이다.
로봇이 코드를 쓴다면 조합 가능성이나 단위 테스트 용이성은 무의미해지고, 코드 품질은 결과(outcome)로 판정될 것이라는 주장이다. 이에 대한 반박이 즉각 달렸다.
"그건 LLM의 관심사이기도 하다. LLM은 잘 정리된 코드베이스에서 더 잘한다. 그들이 학습한 인간들과 똑같이."
그리고 더 근본적인 반박도 있었다. "사람들이 코드 품질에서 신경 쓰는 것들은, 정말로 생각해 보면 모델이 사전학습에서 흉내 내도록 훈련된 바로 그 지표 — 압축과 모듈성 — 과 놀랍도록 잘 들어맞는다. 그 둘은 지능 시스템 일반에 보편적인 개념으로 보인다." 이것은 실제로 SlopCodeBench의 결과와 일치한다. 열화된 코드베이스는 다음 체크포인트에서 더 비싸다.
굿하트 문제다. 이에 대한 벤치마크 측의 대응은 꽤 정교하다.
원문 제목의 전제 자체를 공격한 댓글이 여럿이었다. 가장 잘 정리된 것은 이것이다.
"코딩은 풀리지 않았다. 정확성은 기능(feature)이 아니라 최소한의 조건(bare minimum)이다. 코드가 해야 할 일을 못 하면 코드가 없는 것과 같다. 효율성, 보안, 유지보수성, 신뢰성, 가독성, 이해 가능성, 확장성, 관측 가능성, 이식성 — 고품질 코딩이란 이런 것들이고, 작동한다는 것은 주어진 전제다. 내 경험상 현재 모델들은 이 부분에서 꽤 나쁘다."
또 하나가 이 논쟁 전체를 한 줄로 요약했다. "코딩은 풀렸지만 소프트웨어 공학은 안 풀렸다."
연구를 읽는 것과 월요일 아침에 뭔가를 바꾸는 것은 다르다. 이 논문과 논쟁에서 실무로 가져갈 수 있는 것들을 정리한다.
eve_industry에서 Opus 4.6은 의 정확한 분수 연산에 다른 설정의 두 배 이상을 썼고, 그 뒤 세 체크포인트 연속 100%를 기록하며 에서 1위를 했다. dag_execution에서는 의 모듈화된 패키지가 이후 네 체크포인트를 재작업 없이 수용해 2위를 12점 차로 따돌렸다. 초기 투자는 회수된다.세바스티안의 글은 결론을 내리지 않는다. 대신 이렇게 끝난다.
이 결론이 처음에는 맥 빠지게 들린다. 그렇게 정교한 수식과 197개의 규칙과 990개의 체크포인트를 거쳐 도착한 곳이 "사람의 취향은 여전히 필요하다"라니.
하지만 다시 보면 이것은 패배 선언이 아니라 정확한 지도다. 침식 공식의 임계값 10은 1976년 사람이 정한 것이다. 크기 항의 제곱근도 사람이 고른 것이다. 197개의 AST 규칙은 하나하나 사람이 "이건 지저분하다"고 판단해서 넣은 것이다. 자동화된 지표의 모든 층위에 사람의 판단이 결정화되어 있다. 차이는, 이제 그 판단이 한 번만 내려지면 990개의 체크포인트에 자동으로 적용된다는 것이다.
그리고 그것이 이 논문이 실제로 이룬 일이다. "이 코드 좀 지저분하지 않아?"라는 느낌을, 재현 가능하고 모델 간 비교 가능하며 시간에 따라 추적 가능한 숫자로 바꿨다. 완벽하지 않다. 코드 줄의 90%를 잡아내는 규칙 집합은 분명 과하다. 임계값 10은 자의적이다. 굿하트가 문 앞에 서 있다.
그럼에도 이것은 느낌에서 측정으로 가는 첫 걸음이고, 2026년 우리가 하루에 수만 줄씩 쌓고 있는 것을 생각하면, 그 걸음은 늦어도 한참 늦었다.
