# 코드 청결도는 코딩 에이전트에 영향을 미치는가? 통제된 최소쌍 연구 > Clean Markdown view of GeekNews topic #31186. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=31186](https://news.hada.io/topic?id=31186) - GeekNews Markdown: [https://news.hada.io/topic/31186.md](https://news.hada.io/topic/31186.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-07-07T07:35:20+09:00 - Updated: 2026-07-07T07:35:20+09:00 - Original source: [arxiv.org](https://arxiv.org/abs/2605.20049) - Points: 1 - Comments: 1 ## Topic Body - 자율 **코딩 에이전트** 평가는 주로 고정된 코드베이스에서의 작업 성공률을 봐 왔지만, 이 연구는 코드 자체의 **청결도**가 탐색·수정 비용을 바꾸는지 분리해 측정함 - 아키텍처, 의존성, 외부 동작은 같고 SonarQube 규칙 위반과 인지 복잡도만 다른 **최소쌍 저장소** 6개와 숨겨진 테스트 기반 작업 33개를 구성함 - Claude Code와 Claude Sonnet 4.6으로 각 작업을 저장소 쌍의 양쪽에서 10회씩 실행해 총 **660회 실험**을 수행했으며, 에이전트는 어느 쪽 코드인지 알지 못함 - 코드 청결도는 **통과율**을 바꾸지 않았지만, 더 깨끗한 코드에서 토큰 등가 지표는 7~8% 줄고 파일 재방문은 34% 감소함 - 모델이나 프롬프트만이 아니라 **코드베이스 상태**도 에이전트의 계산 비용과 탐색 효율을 좌우하는 실무 변수로 남아 있음 --- ### 연구 질문과 문제 설정 - 자율 코딩 에이전트는 빠르게 확산 중임 - 2026년 128,018개 GitHub 프로젝트 조사에서 첫 실용 에이전트 출시 후 1년이 되지 않은 시점에 **22~29%의 프로젝트**에서 에이전트 활동 흔적이 발견됨 - 에이전트 실행 비용도 작지 않음 - SWE-bench Verified에서 단일 작업은 프런티어 LLM 기준 평균 약 **400만 토큰**을 사용함 - 전체 사용량에서는 입력 토큰이 대부분을 차지함 - 기존 평가는 SWE-bench 같은 벤치마크에서 **작업을 해결했는지**에 집중해 왔고, 최근 연구들은 통과율과 함께 자원 사용량도 측정하기 시작함 - 일반적인 비교는 코드베이스를 고정한 뒤 에이전트나 스캐폴딩을 바꾸는 방식이었음 - 이 연구는 반대로 에이전트와 작업을 고정하고 **코드베이스의 청결도**만 바꿔 비교함 ### 코드 청결도와 최소쌍 구성 - 코드 청결도는 유지보수 가능한 코드와 연결되는 특성들의 묶음으로 다뤄짐 - 읽기 쉬움 - 낮은 인지 복잡도 - 잘 분리된 헬퍼 - 명확한 이름 - 적은 죽은 코드, 중복 로직, 우발적 결합 - 연구는 코드 청결도를 엄밀한 형식 정의로 고정하지 않고, **SonarQube** 정적 분석 규칙 위반 수를 느슨한 대리 지표로 사용함 - 사용 도구는 SonarQube Cloud Enterprise Edition - 규칙 세트는 “default quality gate” - 최소쌍 저장소는 내부 청결도만 다르고 다음 조건은 맞추도록 구성됨 - 같은 언어와 프레임워크 - 같은 의존성 - 같은 테스트 또는 동등한 테스트 커버리지 - 같은 외부 동작 - 동작 동등성은 같은 입력에서 외부적으로 관찰 가능한 출력과 상태 전이가 같은 경우로 봄 - 실제 검증은 같은 테스트 스위트를 같은 커버리지로 통과하거나, 리팩터링처럼 관찰 불가능한 변경을 보정한 테스트 쌍을 통과하는 방식으로 이뤄짐 ### 최소쌍 생성 파이프라인: Slopify와 Vibeclean - 최소쌍은 양방향으로 만들어짐 - 깨끗한 저장소를 더 지저분하게 만드는 **Slopify** - 지저분한 저장소를 정리하는 **Vibeclean** - ## Slopify - 깨끗한 코드베이스를 코드 리뷰나 린팅 없이 성장한 듯한 버전으로 바꿈 - 의도적으로 망가뜨린 코드가 아니라, 정적 분석이 없었을 때의 대체 역사 버전을 목표로 함 - 세 단계가 각각 새로운 에이전트에 의해 수행됨 - Build: 저장소를 빌드하고 테스트가 통과되게 한 뒤 `build instructions.md`에 명령을 고정 - Explore: 저장소를 훑고 정리 대상 디렉터리마다 `summary.md` 작성 - Transform: 지정된 디렉터리에 SonarQube 규칙 위반을 도입하고, 각 패스 뒤 테스트를 다시 실행해 깨진 변경은 거부 - 헬퍼 인라인화, 경로별 로직 중복, 죽은 코드 추가, 일부 모듈의 단일 파일 병합 등으로 인지 복잡도를 늘림 - ## Vibeclean - 자연적으로 규칙 위반이 많은 코드베이스를 외부 동작을 유지한 채 정리함 - 에이전트의 작업 목록은 분석기가 잡아낸 이슈 목록이며, 각 이슈는 코드 범위에 연결됨 - 수정 범위는 분석기가 표시한 문제로 제한되고, 전체 재설계는 목표가 아님 - 두 단계로 동작함 - Build: 빌드와 테스트 명령을 확인하고 `build instructions.md`에 고정 - Clean: 모듈별로 분석기 규칙 위반을 기계적으로 정리하고, 모듈 처리 뒤 테스트로 동작 동등성을 확인 - 문자열 리터럴 중복 제거, 주석 처리된 코드 삭제, 레거시 컬렉션 관용구 교체, 죽은 분기 제거 등을 수행함 - 분석기가 실제 거대 구조를 지적한 경우 200줄 이상 dispatch switch를 이름 있는 헬퍼로 바꾸거나, 2,800줄 클래스에서 영속성 헬퍼를 추출함 - 다만 추출이 복잡도를 제거하기보다 더 많은 메서드로 재분배할 수 있고, 일부 가장 큰 거대 구조는 `wontfix`로 남음 ### 벤치마크 저장소와 작업 설계 - 벤치마크는 **Harbor framework v0.4.0** 위에 구축됨 - 총 6개의 최소쌍 저장소가 사용됨 - Java 중심 3개, Python 중심 3개 - 일부 저장소는 다른 언어 코드를 소량 포함함 - 공개 오픈소스 저장소 3개와 비공개 SonarSource 코드베이스 3개로 구성됨 - 비공개 쌍은 평가 대상 LLM이 공개 저장소로 학습했을 가능성에 대비한 **암기 방지** 역할을 함 - 저장소별 청결한 쪽과 지저분한 쪽의 주요 수치는 다음과 같음 - `sonar-sca*`: 이슈 94 / 2,825, 이슈 밀도 0.73 / 20.66, 인지복잡도 밀도 30.6 / 56.5 - `sonar-caas-poc*`: 이슈 16 / 855, 이슈 밀도 0.61 / 27.16, 인지복잡도 밀도 179.8 / 218.9 - `sonarcloud-codedatalake*`: 이슈 199 / 1,319, 이슈 밀도 4.36 / 34.39, 인지복잡도 밀도 34.0 / 216.5 - `commons-bcel`: 이슈 694 / 2,711, 이슈 밀도 12.60 / 49.46, 인지복잡도 밀도 102.8 / 108.3 - `genie`: 이슈 152 / 1,262, 이슈 밀도 1.28 / 10.81, 인지복잡도 밀도 22.2 / 23.5 - `ckan`: 이슈 1,006 / 3,632, 이슈 밀도 7.54 / 27.50, 인지복잡도 밀도 69.3 / 76.5 - 작업 설계는 세 가지 규칙을 따름 - **핫스팟 경유**: 쌍의 양쪽에서 이슈 밀도와 인지 복잡도 차이가 큰 코드 영역을 지나가도록 작업을 배치 - **외부 관찰 가능 설명**: 입력·출력과 예시 시나리오만 제공하고, 파일·함수·내부 구조 이름은 제공하지 않음 - **공개 표면 테스트**: CLI, HTTP 라우트, 라이브러리/API 등 애플리케이션이 호출자에게 제공하는 인터페이스를 통해 숨겨진 테스트를 실행 - 작업 생성은 에이전트와 사람이 나눠 맡음 - 에이전트가 깨끗한 변형과 지저분한 변형을 비교해 차이 지도를 만듦 - 다른 에이전트가 작업 개요와 테스트 가능성을 작성함 - 사람이 그중 그럴듯하고 흥미로운 개요를 선택·편집·큐레이션함 - 세 번째 에이전트가 실제 지시문, 숨겨진 공개 표면 테스트, 내부용 참조 구현을 만듦 - 참조 구현은 양쪽 저장소에서 숨겨진 테스트를 통과해야 함 - 수정 전 저장소는 숨겨진 테스트를 통과하면 안 됨 - 두 번의 반복 뒤에도 조건을 만족하지 못한 작업은 사람이 다시 쓰거나 제거함 - 최종 작업 수는 **33개**이며 세 트랙으로 나뉨 - 13개 인지 핫스팟 작업: 단일 메서드나 단일 클래스의 고밀도 복잡 영역을 통과 - 14개 다중 모듈 작업: 둘 이상의 모듈을 가로지르는 변경 필요 - 6개 보정 작업: 양쪽이 동일한 영역에서 단순한 작업을 수행해 청결도와 무관한 변화가 있는지 확인 ### 실험 설정과 측정 지표 - 모든 실험은 기본 도구 세트를 사용하는 **Claude Code**로 수행됨 - 보고된 수치는 Claude Sonnet 4.6 실행에서 나옴 - Claude Haiku 4.5도 같은 작업 세트에서 훑었지만, 통과율이 너무 낮아 footprint 차이를 명확히 읽기 어려워 본 결과에서 제외됨 - 에이전트는 작업 설명만 읽음 - 코드 청결도에 대한 추가 프라이밍을 받지 않음 - 자신이 최소쌍의 어느 쪽에서 작업하는지 모름 - 각 작업은 쌍의 양쪽에서 10회씩 실행됨 - 총 실험 수는 **33 × 2 × 10 = 660회** - 각 실행은 컨테이너화된 샌드박스에서 수행됨 - CPU, 메모리, 저장소, 벽시계 시간이 제한됨 - 공개 패키지 레지스트리에 접근 가능함 - 기본 이미지는 저장소별 툴체인, 빌드 캐시, 서비스를 포함함 - 쌍 내부에서는 `/app`에 마운트되는 소스 트리만 다름 - 기록 지표는 10개임 - **통과율**: 최종 상태에서 숨겨진 테스트가 통과한 비율 - 입력 토큰: 모든 턴에서 모델이 읽은 토큰 수이며 파일 내용과 이전 대화 재전송이 대부분을 차지함 - 출력 토큰: 모델과 하위 에이전트가 낸 산출물 전체로, 산문·코드·추론 흔적·도구 호출을 포함함 - 추론 문자 수: Anthropic API가 추론 토큰을 별도로 노출하지 않아 추론 콘텐츠 블록의 평문 문자 수를 셈 - 대화 턴 수: 에이전트-도구 교환 총수 - 첫 편집 전 턴 수: 첫 파일 수정 전까지 걸린 턴 - 첫 편집 전 문자 수: 같은 구간의 대화 문자 수 - 읽은 파일 수: 실행 중 열어본 고유 파일 수 - 파일 재방문: 이미 읽고 수정한 파일을 다시 읽은 횟수 - 수정한 줄 수: 최종 패치가 바꾼 소스 줄 수 - 파일 재방문은 `읽기 → 편집 → 다른 작업 가능 → 다시 읽기` 같은 흐름으로 나타남 - 연구에서는 폭넓은 탐색보다 이전 편집에 대한 **불확실성** 신호로 해석함 - 에이전트 footprint 지표는 같은 작업을 고정 온도에서 반복해도 크게 달라질 수 있어 이상치 필터를 적용함 - 각 `(작업, 쪽)` 조합 안에서 10회 반복의 중앙값보다 50% 이상 벗어난 실행을 평균 전 제거함 - 실제로는 전체 실행의 **9.7%** 가 제거됨 - 데이터셋 수준 수치는 33개 작업에 대해 마이크로 평균됨 - 각 지표별로 작업별 청결한 쪽 평균과 지저분한 쪽 평균을 합산한 뒤 비율 차이를 계산함 - 통과율은 예외적으로 청결한 쪽과 지저분한 쪽의 절대 퍼센트포인트 차이로 보고됨 ### 결과: 성공률보다 탐색 비용에 영향 - 코드 청결도는 에이전트의 **통과율**에는 유의미한 변화를 만들지 않음 - 더 깨끗한 코드에서는 토큰 등가 지표가 **7~8% 감소**함 - 파일 재방문은 **34% 감소**해, 깨끗한 코드가 같은 작업에서도 되짚어 읽는 비용을 줄일 수 있음을 보임 - 따라서 코드 청결도는 모델 선택, 하네스, 프롬프트와 함께 에이전트 실행 비용을 좌우하는 별도 축으로 볼 수 있음 ## Comments ### Comment 61344 - Author: neo - Created: 2026-07-07T07:35:22+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48798815) - 연구할 만한 흥미로운 질문이지만, **실험 설계**에는 매우 회의적임 실험에서 Opus 4.6으로 “품질 저하” 또는 “정리된” 코드베이스를 합성해 상대 비교에 사용했음 더 나쁘게는 애플리케이션의 테스트를 망가뜨렸는지 통제하지 않았다는 점임 “통과율은 각 작업에 대해 우리가 작성한 숨겨진 테스트 기준으로 에이전트의 최종 상태를 채점한다. 저장소에 이미 있던 관련 없는 테스트를 에이전트가 망가뜨렸는지는 확인하지 않으며, 깨끗한 쪽과 지저분한 쪽의 해법이 둘 다 숨겨진 테스트를 통과하더라도 채점되지 않은 테스트에서는 차이가 날 수 있다” 최종 산출물의 품질을 통제하지 않는다면 **토큰 소비량**에 관한 결론은 거의 의미가 없어 보임 - 지저분한 프로젝트와 잘 구조화된 프로젝트를 실패 테스트 수로 비교하면, 애초에 **테스트 커버리지**와 견고성이 낮을 가능성이 큰 지저분한 코드베이스 쪽으로 성공률이 치우칠 수 있음 공정하게 비교하려면 각 쌍의 두 프로젝트 모두에서 동작하는 단일 테스트 묶음을 작성해야 할 것임 연구가 좋다는 뜻은 아니지만, 테스트 통과가 에이전트의 효과성과 꼭 상관있지는 않으므로 그런 결정을 이해할 수는 있음 - 결론이 성립하더라도, 기껏해야 **품질 저하 코드**에 대한 최선의 경우일 뿐임 기능적으로는 괜찮아 보이지만 작업을 끝내는 데 더 많은 토큰 비용이 드는 상황을 보여주는 정도임 - 애플리케이션의 테스트 파손을 통제하지 않는다면 사실상 **가치 없는 연구**임 AI 피로감은 오래전에 지루해졌고, 이제는 그냥 고통스러울 정도임 - 내 경험상 코드베이스에 **죽은 코드**, 중복 코드, 도달 불가능한 대체 경로, 새는 추상화, 덜 익은 설계 패턴이 널려 있을 때와, 데이터 흐름이 명확하고 캡슐화와 구조가 깨끗할 때의 에이전트 성능 차이는 상당히 큼 나쁜 코드에서는 모든 최전선 모델이 여러 차례 코드 리뷰와 품질 확인, 수정 라운드를 거쳐야 했고, 좋은 코드에서는 1~2번째 시도에 바로 맞는 경우를 봤음 - 위에서 언급한 죽은 코드 제거, 코드 중복, 도달 불가능 코드 같은 문제는 대부분의 언어 생태계에서 이미 오래전부터 **결정적 린터**로 해결돼 왔음 LLM에게 이런 항목을 확인하는 스크립트를 실행하게 하고, 같은 스크립트를 pre-commit 훅으로 강제할 수도 있음 내가 작업하는 모든 코드베이스에 이런 설정을 철저히 넣은 것이 에이전트식 코딩에서 가장 큰 효과를 줬음 내가 쓰는 여러 린터를 더 자세히 정리한 글은 여기 있음: [https://www.balajeerc.info/Use-Deterministic-Guardrails-for-...]() - 이런 도구들을 꽤 오래 다뤄왔는데, 매번 **사람을 대하듯** 다루면 성능이 더 좋아지는 것처럼 보였음 에이전트도 거대한 엉망진창 코드베이스보다 깨끗한 코드베이스에서 더 잘할 수밖에 없다고 봄 잘 만들어진 명세와 문서 접근권이 있을 때 더 잘하는 것과 같음 - 지저분한 코드베이스에서 작업할 때 나도 비슷하게 느낌 어느 순간 끔찍한 패턴들이 나에게도 묻기 시작함 - 동의하면서 읽었지만 왜 나쁜 댓글처럼 느껴지는지 생각해 보니, 이런 **일화적 진술**은 과학적 논의의 반대편에 있음 여기에는 질문에 답하려는 논문이 있고, 일화적 증언은 독자에게 편향을 줄 뿐 문제에 대해 객관적으로 결론 내릴 가치를 더하지 못함 모두가 논문을 읽고 방법론이나 결과를 비판하는 쪽이 가장 유용한 논의일 것임 - 이것도 느낌에 가깝긴 한데, 나는 너무 걱정이 많아서 리팩터링과 코드 정리 패스를 자주 하고 절대 빼먹지 않기 때문에 실제로 성능 차이가 있는지는 확실히 말하기 어려움 다만 LLM이 그다지 좋지 않다고 불평하는 사람들은 대체로 **지저분한 코드베이스**를 가진 유형처럼 보임 - 내가 잘 먹힌다고 본 요령은 Python이라면 다음처럼 **리팩터링**을 지시하는 것임 “Python 코드를 더 Python답게 리팩터링하라. 예를 들어 클래스와 싱글턴을 줄이고, 특히 속도 향상이 있다면 그렇게 하라. Python 코드는 벤치마크 성능 회귀 없이 인기 있는 오픈소스 Python 패키지 코드에서 기대되는 코드 구성 기준을 반드시 따라야 한다” Rust 코드에는 이런 변형을 써봤음 “`/src`의 Rust 코드베이스가 여러 개의 1천 줄 초과 파일로 비대해졌다. 벤치마크 성능 회귀 없이 인기 있는 오픈소스 Rust 코드에서 기대되는 코드 구성 기준에 맞게 Rust 코드베이스를 리팩터링하라” 이런 프롬프트는 a) 코드를 논리적으로 재구성하고 b) 파일명이 관련 코드 위치에 대한 의미적 힌트를 주기 때문에 에이전트 성능도 좋아지는 듯함 5천 줄짜리 비대한 파일에서는 에이전트가 관련 코드를 찾으려고 여러 덩어리를 읽어야 해서 비효율적임 벤치마크 성능도 보통 리팩터링 뒤에 좋아지는데, 특히 컴파일되는 Rust에서는 우연일 것 같지만 불평할 일은 아님 - 맞음. 에이전트식 코딩 도구에 코드베이스 정리, 표적 리팩터링, **SOLID 원칙**과 좋은 관행 적용을 요청하는 것만으로도 쉬운 개선이 많이 나옴 기본적으로 에이전트식 코딩 도구는 코드를 지우는 데 꺼리는 경향이 있음. 지우라고 해도 그렇고, 예전 코드를 남겨두거나 그 코드가 계속 호출될 수 있게 복잡도를 추가하려고 온갖 노력을 함 단순히 프로토타이핑 중이라면 정말 성가신데, 결국 죽은 코드가 많이 쌓이고 나중에 기능을 더하려 할 때 혼란을 일으킴 이걸 알고 나면 그냥 레거시를 없애라고 요청하면 됨 코드베이스를 깨끗하게 유지하면 AI가 올바른 일을 하도록 자극함. 테스트가 많으면 새 기능을 만들 때 더 추가하고, 문서가 있으면 따로 말하지 않아도 업데이트함 코드 하네스가 개선되면서 이런 것들이 점점 내장될 테고, 프롬프트 경험이 적은 사람도 괜찮은 결과를 얻기 쉬워질 것임 - **YAGNI 원칙**을 적용하라고 요청하는 것도 코드베이스를 줄이는 데 잘 먹히는 듯함 보통 먼저 검토해서 검토 항목 목록을 만들게 한 뒤, 각 항목을 함께 보면서 내가 예/아니오로 결정하거나 추가 수정을 제안함 - 점진적으로 하는 건 충분히 이해되지만, 운영 중인 어떤 코드베이스든 전체를 한 번에 이렇게 하는 건 **극도로 위험**해 보임 특히 전체 시스템에 대한 신중한 종단 간 테스트가 없다면 더 그렇다 - 그냥 “코드베이스를 리팩터링해”라고 해도 꽤 잘 작동함 어차피 코드 스타일 규칙은 이미 CLAUDE.md에 넣어두었음 - 찾고 있는 단어는 **관용적**임 - “지저분한 저장소를 정리하는 에이전트 파이프라인”이라는 접근은 끔찍해 보이고, 그 자체로 연구 전체를 부정하기에 충분함 이 작업에서 **최소 쌍**의 절반이 그런 방식으로 만들어진 듯함 AI가 “정리한” 저장소가 실제로 좋은 코드베이스를 대표한다고 가정해야 하는 결론은 전혀 신뢰하지 않겠음 - 제1저자임. 한 가지 명확히 하고 싶음 여기서 “깨끗함”은 에이전트에게 그냥 더 좋은 코드를 쓰라고 요청한 것이 아님 50~100개의 **정적 분석기 규칙 위반** 목록과 코드 줄 수를 주고, 이를 제거하라고 요청함 그런 다음 규칙 위반이 해결됐는지 확인함 LLM으로 코드를 다시 작성해 이런 위반을 제거하는 것은 꽤 받아들여진 관행임 Sonar의 기존 원샷 LLM 기반 접근 [1]은 1년 넘게 운영 중이고, 최근의 에이전트식 접근 [2]도 같은 작업을 꽤 잘 수행함 [1] [https://www.sonarsource.com/solutions/ai/ai-codefix/]() [2] [https://www.sonarsource.com/products/sonarqube/remediation-a...]() - AI가 어질러놓은 깨끗한 저장소라면 신뢰하겠음? - 당연히 영향을 줄 수밖에 없다고 봄 어떤 모델도 실제 코드베이스 전체를 문맥에 담을 수 없고, 사람처럼 코드를 훑어야 함 검색하고 파일을 읽는 방식임 파일이 예상되는 위치에 있고, 모델이나 사람이 처음 검색할 법한 이름으로 불린다면 첫 시도에 찾지만, 그렇지 않으면 깊은 검색과 여러 번의 시도가 필요해짐 - LLM이 **전체 코드베이스**를 문맥에 들고 있을 필요는 없음 모든 경로를 보고, 이미 다룬 구역은 무시하면서 다음 경로로 넘어가면 됨 개발자가 하는 방식과 꽤 비슷함 - NJIT에서 진행 중인 비슷한 작업에서도 유사한 결과를 봤음. 우리는 이를 **맥락적 품질 전염**이라고 부름 여기서 흥미로운 부분은 업계에서 흔한 실제 상황들임. 품질이 섞인 코드베이스, 레거시 코드 패턴과 더 새로운 “좋은” 패턴이 섞여 에이전트가 관례를 혼동하는 코드베이스 같은 것들임 최소 쌍 설계는 사실 강점 중 하나임. 저장소끼리 비교하는 것보다 구조, 의존성, 테스트 같은 다른 요인에서 **깔끔함**을 분리하려 하기 때문임 다만 LLM이 생성한 “엉망화된” 코드를 쓰는 것은, 기계적이거나 사람이 안내한 방식이 아니라는 점에서 다소 의문임 가장 큰 비판은 다른 사람들이 올바르게 짚었듯 전체 테스트 묶음을 확인하지 않았다는 선택임. “행동 동등성” 주장은 테스트와 커버리지만큼만 유효함 이 가설이 설득력 있는 이유는 두 가지임. 1) LLM은 코드베이스에서 보는 것을 모방하므로 쓰레기가 들어가면 쓰레기가 나온다는 점에서 말이 됨 2) 지난 1~2년간 많은 엔지니어가 이 모델들을 쓰며 직관적으로 느낀 것과 맞아떨어짐 그린필드는 거의 항상 바쁜 코드베이스에 합류하는 것보다 쉽고, 엉망은 복잡한 통합과 레거시 목적의 시스템 유지 등에서 생김 - 에이전트가 자기가 남긴 스텁과 **WET 코드**를 헤쳐 나가는 법을 배운다 해도, 사람이 실제로 무슨 일이 벌어지는지 따라갈 수 없는 코드베이스를 정말 원하나? - 에이전트가 모든 것을 처리하더라도, 영어는 코드가 하는 일을 부정확하게 설명함 그래서 개인적으로는 최소한 코드가 무엇을 하는지 **코드로 이야기**하고 싶음 - 오히려 DRY를 너무 밀어붙이는 경우를 봤음 작은 함수 두 개에 공유 헬퍼로 뺄 수 있는 로직이 있더라도, 인간 프로그래머라면 그 추상화가 지저분하고 둘 중 하나를 조금만 바꾸려 해도 깨질 걸 알기 때문에 그렇게 하지 않을 때가 있음 - 이걸 수치화해서 보는 건 흥미로움 **깨끗한 구조**는 사람과 에이전트 모두의 인지 부하를 낮추는 듯하고, 그래서 이름 짓기와 모듈화가 생각보다 더 중요하다는 설명이 됨 - 코드 품질은 결국 코드를 얼마나 쉽게 **올바르게 변경**할 수 있는지로 정의해야 한다고 봄 정량화하기 어렵지만, 모든 코드 품질 지표가 결국 포착하려는 것도 그것임 그 기준에서 보면 사용하는 코드 품질 지표가 합리적이기만 하다면 꽤 놀랍지 않은 결론임 품질 지표가 코딩 에이전트 맥락에서 좋다면, 기대할 결과가 바로 이것임 - 많은 토큰은 코드 탐색에 쓰임. 코드를 찾거나 호출 지점을 따라가며, 작업을 수행할 만큼 충분한 문맥을 만드는 과정임 에이전트에게 어떤 형태의 **LSP** 접근권을 주고, 모노레포라면 AGENTS.md 같은 파일로 계층적 안내를 제공하면 탐색에 드는 토큰 사용량을 크게 줄일 수 있음 하지만 흩어진 코드베이스는 각 작업을 풀기 위해 결국 어떤 형태로든 탐색이 필요함 그리고 이 탐색은 단순한 토큰 사용만이 아님. 각 단계마다 LLM의 대기 시간, 프리필, 디코딩, 출력에서 에이전트의 파싱, 도구 호출, 도구 응답을 거쳐 다시 LLM으로 돌아가는 왕복 지연이 반복됨 일부는 병렬로 가능하지만 실제로는 대부분 순차적이라 작업이 상당히 느려짐 에이전트를 효율적으로 쓰려면 **지역성과 구조**가 핵심임. 문맥 창은 항상 제한돼 있고, 그 안에서의 주의도 일관적이지 않음 - 내 경험상 엔지니어에게 영향을 주는 모든 것은 에이전트에도 영향을 줌 좋은 추상화, 적당한 크기의 메서드, 좋은 이름, 원칙 있는 서비스 내부·서비스 간 구조, 단위 테스트 등이 모두 해당함 이런 것들은 역사적으로 엔지니어의 일이었고, 다른 사람이 코드에 기여하기 쉽게 만들기 위한 것이었음 이제는 다른 사람뿐 아니라 **다른 에이전트**도 코드에 기여하기 쉽게 만들어 줌