IDE 스타일 코드 탐색 및 리팩토링이 코딩 에이전트를 자동으로 개선하지는 않는다

코딩 에이전트의 드롭인(drop-in) 업그레이드는 이해하기 쉽습니다. 도구를 설치하고, 에이전트에게 IDE 스타일의 코드 탐색 및 리팩토링 기능을 제공하면 더 나은 결과를 기대할 수 있습니다. 저는 이것이 실제로 동일한 에이전트가 작업을 더 빠르게 완료하거나, 오류를 줄이거나, 토큰 사용량을 줄이는 데 도움이 되는지 알고 싶었습니다.

저는 HTTPX에서 10가지 리팩토링에 대해 하나의 권장 사항을 테스트했습니다. 각 작업은 에이전트의 일반 도구를 사용한 두 번의 시도와 추가된 탐색 및 리팩토링 도구를 사용한 두 번의 시도로 총 40회의 실행으로 구성되었습니다.

두 워크플로우 모두 모든 수용 검사(acceptance check)를 통과했습니다. 추가된 도구와 명시적인 사용 지침 덕분에, 평균 에이전트 시간은 89.8초에서 111.4초로 증가했으며, 이는 약 24% 더 긴 시간이었습니다. 평균 총 보고 토큰 수는 약 40% 증가했습니다.

새로운 세션에서 이 규정된 워크플로우를 사용했을 때, 추가된 도구는 수용도를 개선하지 않으면서 시간과 토큰 사용량을 늘렸습니다. 이것이 제가 추가적인 도구를 드롭인 개선으로 취급하기 전에 재현 가능한 증거와 테스트된 모범 사례를 원하는 이유입니다.

권장 사항의 배경 아이디어

'정의로 이동(go to definition)'과 '참조 찾기(find references)'는 생소한 코드를 다룰 때 도움이 되므로, 이 아이디어는 타당했습니다. 메서드 이름을 검색하면 같은 이름의 관련 없는 메서드가 반환될 수 있지만, 특정 심볼에 대한 참조를 찾는 것은 더 정확한 답변을 제공할 수 있습니다.

권장된 도구는 Serena였으며, 이는 MCP(AI 클라이언트와 도구를 연결하는 프로토콜)를 통해 이러한 기능을 에이전트에게 노출합니다. 에이전트는 함수를 검색하거나, 그 참조를 검사하거나, 특정 심볼을 편집할 수 있습니다.

한 가지 경로는 Language Server Protocol (LSP)을 통해 편집기 기능에 대한 코드 분석을 제공하는 언어 서버입니다. 또 다른 네이티브 IDE 통합 방식은 JetBrains backend를 사용하는 것입니다. 이는 IDE 자체의 분석 및 리팩토링 기능을 활용합니다.

이번 실험에서는 Python 분석 도구인 Pyright와 언어 서버 백엔드를 사용했습니다.

실질적인 질문은 그러한 기능들을 추가하는 것이 사용에 드는 노력을 고려했을 때 에이전트가 완성하는 작업의 결과물을 실제로 개선했는지 여부였습니다.

전체 워크플로우를 테스트한 이유

성공적인 탐색(navigation)과 리팩토링은 능력을 보여줍니다. 생산성 주장은 또한 완료된 작업에 대한 증거가 필요합니다. 예를 들어, Serena의 에이전트 작성 평가는 JetBrains 백엔드에서 동작 체인(operation chains), 호출 횟수(call counts), 페이로드 크기(payload sizes)를 비교합니다. 하지만 해당 보고서들은 독립적인 수용 검사(acceptance checks)가 필요한 반복적인 개발 작업 전반에 걸친 향상을 입증하지 못합니다.

또한, 방법론은 확증 편향(confirmation-bias)의 우려를 제기합니다. 에이전트가 예시를 선택하고 자신의 작업을 스스로 평가하기 때문입니다. 부정적인 결과도 요청했지만, 방법론을 검토하는 데 사용된 프롬프트는 유능한 에이전트들이 도구를 올바르게 사용한다고 가정하며, 오용(misuse)과 실패 모드(failure modes)는 제외하고 있으며, 명시적으로 “이 가설의 타당성에 의문을 제기하지 마십시오”라고 지시합니다.

저는 이러한 보호된 가정에 기반한 보고서를 즉각적인 개선의 증거로 간주하지 않을 것입니다. 모든 도구에 대해 저는 반복적이고 완전한 작업 비교, 독립적인 검사, 그리고 실제 워크플로우를 위한 테스트된 가이드를 원합니다.

HTTPX에서 진행한 10가지 리팩토링

저는 GitHub에서 기존의 중규모 Python 프로젝트를 찾고 있었습니다. 파일 전반에 걸쳐 실질적인 코드가 존재하고, 10가지의 개별적인 리팩토링을 수행할 만큼 충분한 다양성을 가지며, 해당 동작이 온전하게 유지되었는지 확인할 수 있는 상당한 테스트 스위트(test suite)가 필요했습니다. 또한 반복 실행하기에도 관리 가능한 프로젝트여야 했습니다.

Python HTTP 클라이언트인 HTTPX는 이러한 요구 사항에 맞는 임의의 선택이었습니다. 선택된 스냅샷은 약 8,800줄의 프로덕션 Python 코드를 포함하고 있었습니다. 모든 시도는 동일한 고정 커밋(fixed commit)을 사용했습니다.

10가지 작업에는 클래스 및 메서드 이름 변경, 기존 임포트를 유지하며 함수 이동, 공유 구현 및 모듈 추출, private 헬퍼 인라인화, 제어 흐름 단순화가 포함되었습니다.

한 가지 작업은 Headers.get_list의 이름을 변경했지만 QueryParams.get_list는 그대로 두었습니다. 또한 기존 메서드를 호환성 별칭(compatibility alias)으로 유지할 것을 요구했습니다. 또 다른 작업은 파일 길이 헬퍼를 새 모듈로 이동시키면서 스트림 위치를 보존하고 기존 임포트를 같은 함수에 바인딩하는 것이었습니다. 이러한 요소들은 코드 실행 여부보다 검사 항목들에게 더 구체적으로 확인할 수 있는 내용을 제공했습니다.

모든 작업은 동일한 소스코드의 새로운 Docker 복사본을 사용하여 조건별로 두 번 시도되었습니다. 실행은 순차적이었으며, 두 번째 반복에서는 순서가 역전되었습니다. 구성은 다음과 같았습니다:

이는 추가된 도구를 사용하는 규정된 워크플로우와 에이전트의 일반적인 워크플로우를 비교하는 것입니다. 지침은 개입(intervention)의 일부입니다. 이는 LSP 자체의 효과를 분리하거나 에이전트가 선택적 도구 중에서 어떻게 선택하는지 측정하지 않습니다.

승인은 변경 범위, 요청된 구조, 동작, 테스트, 타입 검사 및 린팅을 확인하는 별도의 오프라인 검증기(offline verifier)로부터 받았습니다. 실행 전에 이 검증기는 알려진 좋은 패치 10개를 수용하고 의도적으로 결함이 있는 패치 10개를 거부했습니다. 인간은 측정된 패치를 수정하지 않았습니다.

전체 재현 번들(reproduction bundle)은 아직 공개되지 않아, 독립적인 재현은 이 보고서의 한계로 남아 있습니다.

40회의 실행이 보여준 것

40회 실행이 보여준 것

추가된 도구가 포함된 20가지 시도 모두 요구되는 워크플로우를 따랐습니다. 239개의 서버 호출 중 5개가 실패했습니다.

토큰 수치는 모델 호출 전반의 누적 사용량을 포함하며 캐시된 컨텍스트(cached context)가 포함됩니다. 청구 금액은 측정되지 않았습니다.

에이전트 시간에는 MCP 시작, 도구 사용 및 에이전트에 의해 실행된 테스트가 포함됩니다. 이는 컨테이너 및 에이전트 설정, 그리고 독립적인 검증기(independent verifier)는 제외합니다. 각 시도는 새로운 도구 서버와 언어 서버 프로세스를 시작했으므로, 이 결과들은 작업일 내내 실행되는 서버보다는 신선한 세션에 대한 결과입니다.

제가 동일한 작업을 수행하는 일치하는 시도들을 비교했을 때, 가이드된 워크플로우가 20개 중 5개 비교에서 더 빨랐습니다. 아래 표는 각 작업의 두 가지 시도를 워크플로우별로 평균낸 것입니다:

작업당 두 번 반복하는 것은 실행 간 변동성(run-to-run variation)에 대한 제한적인 시각을 제공합니다. 이 수치들은 열 가지 선별된 작업에 대해 하나의 에이전트와 모델로 얻은 설명적 결과입니다. 다른 코딩 에이전트, 모델, 그리고 Python 프로젝트는 다르게 작동할 수 있습니다.

무엇이 저를 설득시킬까요?

코딩 에이전트 업그레이드로 제시되는 모든 도구에 대해, 저는 저자들이

• 도구 사용 유무에 따른 동일한 작업 및 시작 코드 기록 (에이전트, 모델, 백엔드, 버전 포함).
• 반복 시도 횟수, 결과 코드를 독립적으로 확인하는 과정, 그리고 실패 사례를 명확하게 다루는 방식.
• 도구 사용까지 포함한 전체 작업 시간과 토큰 사용량.
• 다른 사람이 비교를 반복하고 어떤 부분에서 이득이 발생했는지 검사할 수 있도록 실행 기록 및 실행 가능한 스크립트 제공.
• 테스트된 모범 사례: 어떤 작업에 이득이 되는지, 일반 도구가 언제 더 잘 작동하는지, 그리고 측정된 이득을 가져온 에이전트 지침(instructions), 백엔드, 설정은 무엇인지.

도구는 특정 작업에는 도움이 될 수 있지만 다른 작업에서는 오버헤드를 추가할 수도 있습니다. 따라서 두 가지 결과와 그 배경 조건(리포지토리 크기, 모델, 백엔드, 서버 수명 주기, 지침)을 모두 발표해야 합니다. 만약 선택적 사용이 권장된다면, 그러한 정책 또한 테스트해야 합니다.

이러한 증거가 검사 가능하고 재현 가능하기 전까지는, 저는 광범위한 생산성 주장에 제 워크플로우를 기반으로 삼을 만큼 신뢰할 수 없다고 생각합니다.

실제로 개선을 보여줄 수 있을까요?

이번 실험은 새로운 도구 서버로 10가지 작업에 대한 유도된 사용(guided use)을 측정했습니다. 더 큰 리포지토리, 다른 언어, 계속 실행되는 서버, 또는 네이티브 IDE 백엔드는 다른 결과를 가져올 수 있으며, 이러한 가능성들은 여기서 테스트되지 않았습니다. 두 워크플로우 모두 모든 검사를 통과했기 때문에, 이 비교만으로는 테스트된 사례 외의 유지보수성이나 결함에 차이가 있다고 확정할 수 없습니다.

이 워크플로우의 경우, 추가적인 기능은 더 느린 결과와 더 많은 토큰 사용량을 초래했습니다. 이것이 새로운 도구링을 자동 업그레이드로 취급하는 위험입니다. 재현 가능한 증거와 테스트된 모범 사례가 없다면, 같은 에이전트의 워크플로우를 오히려 악화시킬 수 있습니다.

코딩 에이전트 도구 개발자들에게 제 질문은 간단합니다: 완전한 작업에서 개선을 입증하고, 다른 사람이 검증할 만큼 충분한 실험 결과를 발표하며, 사용자에게 언제 그리고 어떻게 그 이점을 얻을 수 있는지 보여줄 수 있습니까?