전체 연구 및 플러그인 → github.com/bcanfield/agentic-tech-debt

이번 주 당신의 코딩 에이전트(coding agent)가 코드베이스(codebase)에 붙여넣은 블록 중, 저장소(repo)에 이미 존재하는 무언가를 복사한 비율이 그 어느 때보다 높습니다. 이는 AI 코드 품질 논쟁에서 가장 자주 인용되는 수치이며, GitClear의 데이터에 따르면 2024년 동안 5줄 이상의 중복 코드 블록이 8배 증가했습니다.

GitClear는 코드 리뷰 분석(code-review analytics) 도구를 구축하는 곳이므로, 이는 그들의 기준에 따른 데이터이며 그 가치가 어느 정도인지에 대해서는 나중에 다시 다루겠습니다. 하지만 그 규모는 무시하기 어렵습니다. Google, Microsoft, Meta를 포함한 저장소들로부터 2020년부터 2024년까지 총 2억 1,100만 줄의 변경된 라인을 분석한 결과입니다. 이는 개발자들이 어떻게 느끼는지에 대한 설문조사도 아니고, 장난감 과제(toy tasks)에 대한 벤치마크도 아니며, 5년간 실제 코드베이스의 실제 라인 단위 차이(diff) 기록입니다.

핵심적인 발견은 교차 지점입니다. 리팩터링(Refactoring)과 클로닝(cloning)은 모두 차이(diff)에서 '추가 및 삭제된 라인'으로 나타나지만, 이는 정반대의 의미를 갖습니다. '이동된(moved)' 라인은 기존 코드가 한 곳으로 재구성된 것이고, 복사-붙여넣기(copy-pasted)된 라인은 대신 수정해서 사용하는 두 번째 복사본입니다. 2024년, 즉 그들의 데이터에서 첫 번째 해에 복사-붙여넣기된 라인이 이동된 라인을 앞질렀습니다.

이제 솔직한 주의 사항을 말씀드리겠습니다. GitClear는 코드 리뷰 분석 도구를 판매하므로, 코드 품질이 하락하고 있다는 이야기는 그들의 비즈니스에 유리합니다. 이를 벤더 연구(vendor research)로 읽으십시오. 시기적으로는 일치하지만, 데이터셋이 인과관계(cause)를 입증할 만큼 상관관계(correlation)를 확정 지을 수는 없습니다. 바로 이 기간 동안 AI 도입이 증가했고 중복도 함께 증가했으며, 데이터가 입증하는 것은 바로 그뿐입니다.

제가 신뢰하는 것은 그 메커니즘입니다. 왜냐하면 그것이 일어나는 과정을 직접 지켜볼 수 있기 때문입니다. 리팩터링 (Refactoring)은 비용이 많이 드는 선택지입니다. 기존 코드를 찾고, 자신의 케이스가 적합한지 알 수 있을 정도로 충분히 이해하며, 다른 세 개의 호출자 (caller)를 망가뜨리지 않고 공유된 장소로 가져와야 합니다. 반면 붙여넣기 (Pasting)는 그 모든 과정을 건너뛰고 지금 당장 작동하는 블록을 제공합니다. 작동하는 코드를 요청받은 에이전트 (Agent)는 작동하는 코드를 가장 빠르게 만들어내는 수단을 찾을 것이며, 그것은 바로 붙여넣기입니다. 이 과정 중 어떤 것도 모델이 나쁘다는 것을 의미하지는 않습니다. 완벽하게 정확한 붙여넣기라 할지라도 그것은 여전히 붙여넣기입니다. 제 개인 저장소 (repo)는 그 그림을 더 복잡하게 만드는데, 저는 이것이 실제 핵심이라고 생각합니다. 제가 이 시리즈를 쓰고 있는 프로젝트를 중복 블록 탐지기 (duplicate-block detector)로 조사하면 경고등이 켜집니다. 저는 플러그인을 Claude Code, Codex, Copilot, 그리고 휴대용 세트 각각을 위한 네 개의 독립된 복사본으로 배포합니다. git 루트를 찾는 함수는 19번 정의되어 있으며, 수동으로 동기화된 바이트 단위로 동일한 복사본들입니다. 4개가 아니라 19개인 이유는 각 어댑터 (adapter)가 해당 기능이 필요한 모든 스크립트마다 헬퍼 (helper)를 반복하기 때문입니다. GitClear의 측정 방식에 따르면, 이것은 보고서가 집계하는 바로 그 중복을 제가 생성하고 있는 셈입니다.

$ grep -rl "def git_toplevel" --include=*.py . | wc -l
19

하지만 이 중복은 의도적인 것입니다. 저장소 내의 아키텍처 결정 기록 (Architecture Decision Record, ADR)인 ADR 0014에서 이를 옹호합니다. 설치된 플러그인은 격리된 디렉토리이며, 훅 (hooks)은 표준 라이브러리 (standard-library)만 사용해야 하고, 공유 모듈을 사용하면 독립적으로 유지되어야 할 네 가지 요소를 결합 (couple)하게 된다는 논리입니다. 따라서 저는 알려진 세금(동일한 변경 사항이 19개 복사본 모두에 적용되어야 함)을 지불하며, 이를 명시한 서면 규칙을 두고 있습니다. GitClear가 측정하고 있는 중복은 다른 종류, 즉 붙여넣기가 가장 저항이 적은 경로였기 때문에 디프 (diff)에 나타나지만, 두 번째 복사본이 존재한다는 사실을 아무도 기록하지 않은 그런 종류의 중복입니다. grep 결과는 같지만, 상황은 정반대입니다.

그렇기 때문에 제가 실제로 주시할 지표는 중복 (duplication)보다는 이탈률 (churn)입니다. 복사본이 생기는 것이 올바른 결정일 수도 있기 때문에, 단순한 개수만으로는 기술 부채 (debt)와 의도된 결정 (financed decision)을 구분할 수 없습니다. 배포 후 2주 이내에 수정된 코드는 대부분 처음부터 제대로 작성되지 않은 코드이며, 이는 품질을 더 직접적으로 추적합니다. 그래서 이번 주에 여러분의 리포지토리 (repo)에서 확인해 볼 사항을 알려드리겠습니다. 날짜 포맷터 (date formatter), 인증 확인 (auth check), 또는 재시도 래퍼 (retry wrapper)와 같이 존재하는 것이 확실한 헬퍼 (helper) 함수를 하나 골라, 여러분의 에이전트 (agent)가 그와 유사한 복사본을 얼마나 여기저기 흩어놓았는지 grep으로 찾아보세요. 그런 다음, 파일이 추가된 후 몇 주 이내에 다시 작성된 파일들을 git 히스토리 (git history)에서 확인하십시오. 여러분은 GitClear의 12.3%라는 수치와 비교하는 것이 아닙니다. 더 간단한 질문에 답하는 것입니다. 즉, 에이전트가 코드베이스 (codebase)에 이미 존재하는 무언가가 필요했을 때, 그것을 찾아냈는가, 아니면 새로운 것을 붙여넣었는가 하는 점입니다. 그 답은 여러분의 diff 히스토리 (diff history)에 있으며, 이는 여러분의 코드에 대해 맹목적으로 믿을 필요가 없는 유일한 데이터셋입니다.

저는 이러한 결정 지연 (deferred-decision) 버전을 추적하기 위해 debt-ops라는 플러그인을 작성했습니다. 이는 단순 중복과는 다른 측면을 다루며, 제가 이것이 무엇인가를 중복 제거 (dedupe) 한다고 주장하지는 않겠습니다. 만약 여러분도 이 비대칭성 (asymmetry) 문제에 계속 부딪히고 있다면, github.com/bcanfield/agentic-tech-debt에서 확인해 보시기 바랍니다.

커버 사진: Unsplash의 Kristijan Arsov.