JetBrains가 실시한 실험에 따르면 AI 에이전트에 Rider의 리팩터링 엔진에 직접 접근할 수 있도록 하면 C# 작업을 수행하는 방식이 근본적으로 달라질 수 있다. 에이전트가 텍스트를 수정한 뒤 컴파일러를 실행해 변경 사항으로 무엇이 망가졌는지 확인하도록 하는 대신, 구조적 엔진을 직접 사용할 수 있기 때문이다. 15개 작업으로 구성된 테스트에서 작업 중간 시간은 157.9초에서 26.6초로 줄어 83% 개선되었으며, 도구 호출 횟수도 작업당 17회에서 6.2회로 감소했다.
이 기능은 refactoring-code라는 내장 기술로 제공되며, Rider 2026.2.1부터 사용할 수 있다. JetBrains에 따르면 사용자가 이를 수동으로 활성화할 필요는 없다. C# 코드 리팩터링을 수행하라는 요청을 받으면 에이전트가 자동으로 호출하기 때문이다. 이 엔진은 ReSharper 기술과 Rider의 분석 아키텍처를 기반으로 프로젝트 내 기호와 참조 사이의 관계를 파악한다.
수정 후 빌드 방식의 문제
이 기술을 제공하기 전에 JetBrains는 동일한 작업을 수행하는 고급 모델을 관찰했다. 2,513회의 도구 호출 동안 에이전트는 전용 도구가 없었기 때문에 구조적 리팩터링을 직접 수행하지 못했다. 대신 텍스트를 입력하는 대화형 명령을 468회 사용했고, git을 422회, sed를 392회 호출했으며, dotnet build를 163회 실행했다.
이는 에이전트가 리팩터링 작업을 피했다는 뜻이 아니라, 검색과 텍스트 수정으로 리팩터링을 근사한 다음 빌드 결과를 사용해 결과를 평가하려 했다는 뜻이다. JetBrains는 예를 들어 기호 이름을 변경하려면 특정 정의에 연결된 참조, 다형성 메서드 호출, 부분 클래스, 명시적 인터페이스 구현, 문서 참조를 구분해야 한다고 설명한다. 이러한 관계는 단순한 정규식으로 일관되게 보장할 수 없다.
반면 Rider 엔진은 각 식별자가 연결된 정의, 각 호출이 호출하는 오버로드, 솔루션 전반의 참조 위치를 식별하는 해석된 구문 트리에서 작동한다. 따라서 작업의 구조적 부분을 엔진에 맡길 수 있으며, 에이전트가 수정과 빌드, 오류 읽기를 반복하면서 이러한 관계를 점진적으로 다시 발견할 필요가 없다.
JetBrains가 측정한 항목
평가는 결과를 명확하게 검증할 수 있는 8가지 작업에 초점을 맞췄다.
- 기호와 해당 기호의 모든 참조 이름 변경.
- 일련의 문을 새 메서드로 추출.
- 기존 형식에서 인터페이스 추출.
- 기본 클래스를 추출하고 멤버를 해당 클래스로 이동.
- API 시그니처를 변경하고 호출 위치 업데이트.
- 형식을 다른 네임스페이스로 이동하고 using 문 수정.
- 폴더 구조에 맞게 네임스페이스 재구성.
- 다른 부분에서 의존하지 않는 기호를 안전하게 삭제.
작업에는 직접적인 사례와 더 복잡한 사례가 모두 포함되었으며, 호출 위치가 더 많거나 서로 얽힌 의존성이 있는 경우도 포함됐다. 양쪽 모두 동일한 모델인 gpt-5.5를 Codex CLI를 통해 작업당 약 10회 실행했다. 유일한 차이는 refactoring-code 기술의 제공 여부였다. 비교는 기록된 결과와 대응 permutation 테스트를 기반으로 했다.
실제 결과와 비용
기술을 활성화하자 dotnet build 작업은 163회에서 단 3회로 줄었고, 평가에서 전체 도구 호출 횟수도 2,513회에서 926회로 감소했다. 텍스트 수정이 사라진 것은 아니다. sed는 여전히 가장 많이 사용된 도구였지만 역할 분담이 달라졌다. 일반적인 수정은 텍스트 편집 도구가 담당하고, 에이전트가 직접 보지 못하는 부분까지 영향을 미칠 수 있는 구조적 변경은 엔진이 담당했다.
95백분위 시간은 346.4초에서 56.9초로 줄었다. 이는 특히 수정, 빌드, 오류 처리 주기에 갇히는 사례가 사라진 것과 관련이 있다. 작업당 중간 비용은 0.33달러에서 0.12달러로, 성공한 작업당 비용은 0.52달러에서 0.19달러로 감소했다. 작업당 입력 토큰 수도 436,745개에서 208,524개로 줄었고, 컨텍스트 읽기는 2,973,158개에서 1,257,600개로, 출력은 32,532개에서 15,538개로 감소했다.
사용자에게 의미하는 것
이 실험은 에이전트 도구의 이점이 모델의 코드 생성 능력뿐 아니라 호출할 수 있는 도구의 종류에도 좌우된다는 점을 보여준다. 15개 작업 중 8개에서 기술을 제공받은 쪽이 더 빠르고 비용도 적게 들었으며 더 많은 도구를 사용하지 않았고, 양쪽 모두 테스트에 성공했다. 기본 설정에서 2분 이상 걸린 6개 작업은 82%에서 94% 범위로 개선됐다.
그러나 결과가 모든 경우에 전면적인 이득을 의미하는 것은 아니다. 두 작업에서는 양쪽 모두 실패했고, 한 작업에서는 기본 설정이 기술을 제공받은 설정보다 성공률이 높았다. 또한 네 작업은 원래부터 충분히 빨라 Rider 엔진을 호출하는 것이 경제적으로 유용하지 않았다. 따라서 수치는 특정 리팩터링 작업 집합에서 기술의 유용성을 보여주는 증거이지, 모든 작업이 같은 정도로 개선된다는 보장은 아니다.
JetBrains는 차이를 보여주기 위해 ReportExporter 형식에서 기본 클래스를 추출하는 작업을 제시했다. 기술 없이 실행했을 때는 24회의 호출과 1.15달러의 비용으로 336.7초가 걸렸으며, 상속, 생성자, 접근 권한 오류를 처리하기 위해 파일 수정과 빌드 실행을 여러 차례 반복했다. 기술을 사용했을 때는 3회의 호출과 0.09달러의 비용으로 19.8초가 걸렸다. 에이전트가 extract_base_class 작업을 실행해 ExporterBase를 생성하고, 4개 파일을 업데이트했으며, 11개 참조를 다시 작성했기 때문이다.
Rider를 2026.2.1 버전으로 업데이트하고 C# 솔루션을 연 다음 에이전트에 요소 이름 변경, 인터페이스 추출 또는 형식 이동을 요청하면 이 기능을 사용할 수 있다. 자료에서는 “이 클래스를 정리해 줘”와 같은 일반적인 표현보다 OrderProcessor에서 인터페이스를 추출해 달라는 요청처럼 작업 이름을 명시하는 구체적인 지시를 권장한다.