- SonarSource가 Claude Code로 660회를 시행한 통제 실험. 청결도만 다른 저장소 쌍을 쓰는 미니멀 페어 설계로 여섯 쌍에 33개 작업을 얹어 채점함
- 아키텍처·의존성·외부 동작은 똑같이 맞추고 정적분석 위반과 인지 복잡도만 갈라놓아, 숨은 테스트 채점이 두 저장소에서 같은 문제를 재도록 함
- 청결도는 에이전트의 통과율을 바꾸지 못함. 더러운 코드에서도 작업은 끝나므로 “AI가 지저분한 코드는 못 고친다”는 과장
- 대신 깨끗한 코드에서 토큰이 7~8% 덜 들고 파일 재방문이 34% 줄어, 에이전트 헤맴 비용이 청구서로 드러남
- 쌍의 절반은 Opus 4.6이 청소해 만든 깨끗한 쪽이라 AI 청소본 대표성 시비가 붙고, 에이전트가 기존 무관 테스트를 깼는지는 확인하지 않음
“AI가 다 짜주는데 코드 품질이 아직도 중요한가.” 코딩 에이전트가 실무에 밀려들면서 나온 이 반문에 SonarSource의 Priyansh Trivedi와 Olivier Schmitt가 숫자로 답해봤습니다. Claude Code로 660회를 돌린 결과의 요점은 이런데요. 지저분한 코드에서도 에이전트는 결국 작업을 끝냅니다. 대신 훨씬 비싸게, 훨씬 많이 헤매면서 끝내고요.
논문의 표현을 그대로 옮기면 이렇습니다. “코드 청결도는 에이전트의 통과율을 바꾸지 않는다. 그러나 작업의 흔적(operational footprint)을 상당히 바꾼다”(“code cleanliness does not change the agent’s pass rate. However, it substantially alters the agent’s operational footprint”). 성공하느냐 마느냐가 아니라, 성공하기까지 얼마를 쓰느냐가 갈린다는 말입니다.
미니멀 페어: 아키텍처는 같고 청결도만 다른 저장소 쌍
이 실험의 값어치는 방법에 있습니다. “지저분하면 AI도 헤맨다”는 경험담을 숫자로 만들려면 청결도 말고 다른 변수가 결과에 섞이면 안 되겠죠. 연구진이 쓴 장치가 미니멀 페어(minimal pair)입니다. 쉽게 말해, 아키텍처·의존성·겉으로 드러나는 동작은 완전히 똑같고 정적분석 위반과 인지 복잡도(cognitive complexity)만 다른 저장소 한 쌍을 만듭니다. 외부 동작이 같다는 건 통과해야 할 숨은 테스트(hidden test)가 같다는 뜻이라, 두 저장소에서 에이전트가 푸는 문제 자체는 동일하고요.
쌍은 양방향으로 만들었습니다. 깨끗한 저장소를 일부러 열화(degrade)시키거나, 지저분한 저장소를 청소(clean)하거나. 한 방향으로만 만들면 그쪽 인공성이 편향으로 남으니 둘을 섞은 거예요. 이렇게 여섯 쌍에 33개 작업을 얹고, 애플리케이션이 바깥으로 드러내는 공개 인터페이스에 걸린 숨은 테스트로 채점했습니다.
통과율은 그대로, 토큰과 재방문이 갈렸다
660회 시행에서 세 숫자가 나왔습니다.
- 통과율 — 청결도로 바뀌지 않았습니다. 더러운 코드에서도 에이전트는 작업을 끝냅니다. “AI가 지저분한 코드는 못 고친다”는 과장이었어요.
- 토큰 — 깨끗한 코드에서 7~8% 덜 썼습니다. 완료는 하되, 더러운 코드에선 더 비싸죠. 청결도가 곧 API 청구서입니다.
- 파일 재방문 — 깨끗한 코드에서 34% 줄었습니다. 에이전트도 사람처럼 검색하고 파일을 열어 훑는데, 예상 위치에 예상 이름으로 있으면 한 번에 찾고 아니면 같은 파일을 몇 번씩 되짚거든요. 이 34%가 “헤맴”의 정량화입니다.
논문은 이 결과를 두고 청결도를 새로운 조절 변수 반열에 올립니다. “코드 청결도는 모델 선택·하네스·프롬프팅과 나란히, 에이전트 행동을 실질적으로 좌우하는 요인의 반열에 든다”(“Code cleanliness joins model choice, harness, and prompting as a factor that materially affects agent behaviours”). 프롬프트를 다듬듯 코드도 다듬으면 같은 작업이 싸게 끝난다는 얘기입니다.
깨끗한 쪽 절반이 AI가 청소한 코드였다
HN이 가장 세게 물고 늘어진 지점이 여기입니다. 쌍의 절반은 지저분한 저장소를 AI(Opus 4.6)가 청소해 만든 “깨끗한 쪽”인데, 그 청소본이 사람이 잘 짠 코드베이스를 대표한다고 볼 수 있냐는 거죠. AI가 만든 깨끗함으로 측정한 이득은 AI끼리의 궁합일 뿐, 진짜 좋은 코드의 이득이 아닐 수 있습니다.
논문 스스로도 빈틈을 인정합니다. 채점은 각 작업에 새로 쓴 숨은 테스트로만 하고, 에이전트가 저장소에 원래 있던 무관한 테스트를 깼는지는 확인하지 않았어요. “적당한 만큼만 고치는 게 좋은 소프트웨어”라는 통념에서 보면 이건 놓치기 아까운 신호입니다.
그럼에도 토큰 7~8%와 재방문 34%는 “청소본이 얼마나 훌륭하냐”가 아니라 정적분석 위반 수라는 측정 가능한 축에 걸린 값입니다. 대표성 시비가 통과율 해석을 흔들 수는 있어도, 코드를 헤집는 비용이 청결도 지표를 따라 움직인다는 사실까지 지우진 못하겠죠. 사람 눈에 읽기 좋은 코드가 에이전트에게도 싸게 먹힙니다. 유지보수성은 사람만을 위한 미덕이 아니라 청구서를 줄이는 투자이기도 하고요.
Loading comments...