코드 청결도는 코딩 에이전트에 영향을 줄까: 통제된 최소 대조쌍 연구
목차
개요
이 논문은 SonarSource의 Priyansh Trivedi와 Olivier Schmitt가 발표한 연구로, 코드의 구조적, 스타일적 품질 즉 “청결도(cleanliness)”가 코딩 에이전트의 동작에 영향을 주는지를 통제된 실험으로 검증한다.
지금까지 코딩 에이전트 평가는 대상 코드베이스를 고정한 채 태스크 완료율(pass rate)에 초점을 맞춰 왔다. 이 연구는 반대로 에이전트와 태스크를 고정하고 코드베이스를 변화시킨다.
핵심 결론은 이렇다. Claude Code로 660회 시도한 결과, 코드 청결도는 에이전트의 통과율을 바꾸지 않았다. 그러나 운영상 발자국(operational footprint)은 크게 달라졌다. 더 깨끗한 코드에서 에이전트는 토큰을 7~8% 적게 쓰고, 파일 재방문(file revisitation)을 34% 줄였다.
방법론
에이전트 능력과 코드 청결도의 효과를 분리하기 위해, 저자들은 최소 대조쌍(minimal pairs)이라는 평가 프로토콜을 도입한다. 아키텍처, 의존성, 외부 동작은 동일하지만 정적 분석 규칙 위반과 인지 복잡도(cognitive complexity)에서만 차이가 나는 저장소 쌍이다.
청결도는 정적 분석기 SonarQube로 느슨하게 정량화한다. 규칙 위반(이슈)이 적을수록 더 깨끗한 코드로 간주한다. 두 저장소가 같은 입력에 같은 외부 관측 출력을 낼 때 행동적으로 동등(behaviourally equivalent)하다고 본다.
최소 대조쌍 구성
이런 대조쌍은 자연적으로 존재하지 않으므로 에이전트 파이프라인으로 양방향 구성한다.
첫째, Slopify는 깨끗한 저장소를 열화(degrade)시킨다. 코드 리뷰나 린팅 없이 자란 코드처럼 만들되, 의도적으로 파괴하지는 않는다. Build, Explore, Transform 세 단계를 각각 새 에이전트에 맡기며, 큐레이션된 SonarQube 규칙으로 이슈를 주입하고 매 패스마다 테스트를 재실행해 깨진 변경은 거부한다.
둘째, Vibeclean은 지저분한 저장소를 정리(clean)한다. 분석기가 지적한 이슈 목록을 에이전트의 작업 대상으로 삼아, 각 이슈에 앵커된 코드를 수정한다. Build와 Clean 두 단계로 진행하며 모듈 단위로 정리 후 테스트로 동작 동일성을 확인한다.
이렇게 여섯 개의 최소 대조쌍을 조립했다. Java 위주 세 개, Python 위주 세 개이며, 공개 저장소 세 개와 SonarSource 내부의 비공개 저장소 세 개로 나뉜다. 비공개 저장소는 LLM이 학습했을 가능성을 차단해 암기(memorisation) 효과를 방어한다.
| 파이프라인 | 저장소 예시 | 성격 |
|---|---|---|
| Slopify | sonar-sca, sonar-caas-poc, sonarcloud-codedatalake | 깨끗한 코드를 열화 |
| Vibeclean | commons-bcel, genie, ckan | 지저분한 코드를 정리 |
태스크 설계
저장소 쌍만으로는 비교할 계기가 없으므로 33개의 코딩 태스크를 저술했다. 모든 태스크는 세 가지 규칙을 따른다.
첫째, 핫스팟을 경유한다. 두 저장소가 이슈 밀도와 인지 복잡도에서 가장 크게 차이 나는 영역에 태스크를 앵커한다.
둘째, 외부 관측 용어로 기술한다. 태스크 설명은 입력과 출력, 예시 시나리오만 주고 파일이나 함수 이름을 언급하지 않는다. 탐색은 에이전트가 직접 한다.
셋째, 공개 표면(public surface)에서 테스트한다. 숨겨진 테스트는 CLI, HTTP 라우트, 라이브러리 API 등 애플리케이션이 외부에 노출하는 인터페이스를 통해 상호작용한다.
태스크는 세 트랙으로 나뉜다.
| 트랙 | 개수 | 목적 |
|---|---|---|
| Cognitive-hotspot | 13 | 밀집된 단일 메서드, 단일 클래스 복잡도 통과 비용 측정 |
| Multi-module | 14 | 두 개 이상 모듈에 걸친 변경, 경계 넘기 비용 측정 |
| Calibration | 6 | 두 쪽이 동일한 영역의 단순 작업, 중립 대조군 |
실험 셋업
모든 실험은 기본 도구 세트를 갖춘 Claude Code를 에이전트로 사용한다. 논문의 모든 수치는 Claude Sonnet 4.6 시도에서 나왔다. 에이전트는 태스크 설명만 읽으며, 자신이 어느 쪽(깨끗함/지저분함)에서 작업하는지 알지 못한다.
각 태스크는 쌍의 양쪽에서 10회씩 실행되어 총 33 x 2 x 10 = 660회 시도를 만든다. 각 시도는 CPU, 메모리, 저장소, 벽시계 시간 예산이 제한된 컨테이너 샌드박스에서 돌아간다. Claude Haiku 4.5도 같은 태스크로 훑었지만 통과율이 너무 낮아 발자국 분석에서 제외했다.
발자국 변동성이 크기 때문에, 각 (태스크, 쪽) 조합에서 10회 반복의 중앙값 대비 50% 이상 벗어난 시도는 평균 전에 제거하는 중앙값 임계 이상치 필터를 적용한다. 실제로 9.7%의 시도가 제거된다.
주요 결과
집계 결과
청결도는 태스크 완료 여부는 바꾸지 않으면서 발자국과 동작을 바꿨다. 통과율은 깨끗한 쪽 0.913, 지저분한 쪽 0.921로 1퍼센트포인트 미만 차이(-0.9pp)에 그쳤다.
발자국 지표는 깨끗한 쪽에서 완만하지만 일관되게 줄었다.
| 지표 | 변화 (깨끗함 대 지저분함) |
|---|---|
| 입력 토큰 | -7.1% |
| 출력 토큰 | -8.5% |
| 추론 문자 수 | -11.1% |
| 대화 메시지 | -7.0% |
| 파일 재방문 | -34% (최대 효과) |
| 읽은 파일 수 | +3.2% |
가장 큰 단일 효과는 파일 재방문이다. 깨끗한 쪽에서 에이전트는 이미 편집한 파일로 되돌아가는 빈도가 34% 낮았고, 이 방향은 모든 저장소에서 유지되었다(ckan -7%에서 commons-bcel -69%까지). 저자들은 재방문을 이전 편집에 대한 불확실성의 신호로 해석한다.
트랙별 결과
집계 수치는 트랙별로 상반된 동작을 감춘다.
| 트랙 | 입력 토큰 | 파일 재방문 |
|---|---|---|
| Cognitive-hotspot | +1.8% | -20.2% |
| Multi-module | -10.7% | -50.8% |
| Calibration | +3.8% | -75.0% |
Multi-module 트랙이 가장 강한 발자국 대비를 보인다. 깨끗한 변형에서 에이전트는 입력 토큰을 눈에 띄게 적게 쓰고, 파일 재방문은 지저분한 쪽의 약 절반으로 줄었다. 집계 수준 발자국 감소의 대부분이 이 트랙에서 나온다.
반면 Cognitive-hotspot 트랙은 다르게 움직인다. 토큰 발자국은 두 변형 간에 거의 같고, 대신 깨끗한 쪽에서 에이전트가 더 많은 파일을 열되 파일당 편집 줄 수는 줄었다. 정리 파이프라인이 핫스팟을 추출(extraction)로 여러 작은 파일에 복잡도를 재분배하기 때문이다. 두 트랙이 서로 반대 방향으로 당기며, -7.1%라는 집계 입력 토큰 수치는 이 둘을 평균 낸 결과다.
사례 연구
두 사례가 이 긴장을 잘 보여준다.
첫째, commons-bcel의 stack-effect-annotation 태스크는 깨끗한 쪽이 이긴다. 지저분한 변형에서는 옵코드 디스패치가 수백 줄짜리 switch 두 개의 god 메서드에 들어 있었다. 정리 파이프라인이 이를 얇은 디스패처와 명명된 헬퍼로 교체하자, 에이전트는 grep으로 편집 지점을 정확히 조준할 수 있게 되어 입력 토큰 35%, 읽은 파일 25%, 편집 줄 31%, 대화 턴 32%를 절감했다.
둘째, genie의 cluster-active-job-limit 태스크는 지저분한 쪽이 이긴다. 여기서 정리 파이프라인은 핵심 로직을 그대로 둔 채 주변에만 헬퍼를 추출했다. 그 결과 깨끗한 쪽은 표면적만 늘고 내비게이션 이득은 없어 입력 토큰이 8% 증가했다.
주석 볼륨 제거 실험
대조쌍은 코드 외에 주석과 억제 마커(# noqa, // NOSONAR 등)에서도 차이가 난다. “깨끗한 코드가 저렴하다”는 결과가 실은 “주석 줄이 적은 코드가 저렴하다”일 수 있다는 교란 요인을 검증하기 위해, 저자들은 두 쪽의 주석 내용을 동일화하고 억제 마커를 제거한 뒤 재측정했다.
결과적으로 주석과 억제 마커는 발자국 대비의 주된 원인이 아니라고 결론짓는다. 주석 비대칭이 컸던 sonar-caas-poc에서는 정규화 후 깨끗한 쪽의 이점이 오히려 강화되어 +1.2%에서 -18.0%로 이동했다. LOC 차이를 통제한 하한 추정에서도 효과가 지속되었다.
한계와 주의사항
저자들은 여러 한계를 솔직히 밝힌다.
첫째, 저자가 처음부터 끝까지 큐레이션했다. 저장소 선정, 양쪽 구성, 모든 태스크 저술을 연구팀이 직접 했으므로, 태스크 선정의 체계적 편향이 결과에 직접 전파될 수 있다.
둘째, 단일 구성이다. 모든 수치는 Claude Code 안의 Claude Sonnet 4.6, Python과 Java 코드베이스에서 나왔다. GPT 계열이나 Gemini 계열 에이전트, Claude Code 외 하네스는 시험하지 않았다.
셋째, 달러가 아닌 토큰이다. 비용 프록시로 토큰을 사용했으며, 토큰과 달러의 관계는 비선형이라 보고된 감소가 다른 크기의 달러 절감으로 매핑된다.
넷째, 숨겨진 테스트만 본다. 에이전트가 저장소에 이미 존재하던 무관한 테스트를 깨뜨렸는지는 확인하지 않았다.
다섯째, 단기 지평(short-horizon)이다. 태스크당 발자국 감소는 완만하며, 이것이 1년간의 에이전트 작업에 걸쳐 누적되는지 아니면 상쇄되는지는 열린 질문이다.
결론
에이전트 시대에는 유지보수성 원칙이 인간 독자를 위한 것이라 무의미해진다는 주장이 있다. 이 연구는 그 주장에 대한 작은 반증이다.
여섯 개 최소 대조쌍과 33개 태스크에 걸쳐, 더 깨끗한 코드는 에이전트가 태스크를 끝내는지 여부는 바꾸지 않았지만 작업에 남긴 발자국은 줄였다. 가장 뚜렷한 행동 표지는 파일 재방문으로, 깨끗한 쪽에서 약 3분의 1 적게 파일을 다시 열었다. 인간 개발자에게 코드를 유지보수하기 쉽게 만드는 원칙이 에이전트에게도 같은 역할을 한다. 코드 청결도는 모델 선택, 하네스, 프롬프트와 함께 에이전트 동작을 좌우하는 요인으로 합류한다.