[Paper] 하나의 도구면 충분합니다: Repository-Level LLM 에이전트를 위한 Reinforcement Learning

발행: (2025년 12월 24일 오후 02:27 GMT+9)
9 min read
원문: arXiv

Source: arXiv - 2512.20957v1

개요

대규모 오픈소스 저장소에는 수백만 개의 파일과 함수가 포함되어 있어 개발자(및 정교한 AI 어시스턴트조차) 버그나 필요한 변경 사항이 정확히 어디에 있는지 파악하기 어렵습니다. 논문 One Tool Is Enough: Reinforcement Learning for Repository‑Level LLM AgentsRepoNavigator라는 LLM‑기반 에이전트를 소개합니다. 이 에이전트는 단 하나의 실행‑인식 도구인 jump‑to‑definition을 사용해 코드를 탐색합니다. 사전 학습된 모델에서 직접 강화 학습(RL)으로 이 에이전트를 훈련함으로써, 저자들은 시스템을 단순하고 확장 가능하게 유지하면서 최첨단 이슈‑로컬라이제이션 성능을 달성했습니다.

핵심 기여

  • Single‑tool design: 실제 코드 실행 흐름을 반영하는 통합된 “jump‑to‑definition” 도구를 도입하여, 임시 검색 또는 검색 유틸리티 모음이 필요 없게 함.
  • End‑to‑end RL fine‑tuning: 사전 학습된 LLM으로부터 강화 학습을 통해 RepoNavigator를 훈련시켜, 폐쇄형 증류나 다단계 파이프라인을 배제함.
  • Scalable performance gains: 7 B 파라미터 모델이 14 B 베이스라인을 능가하고, 14 B 모델이 32 B 경쟁자를 이기며, 32 B 모델이 Claude‑3.7 같은 독점 모델을 앞선다는 것을 입증함.
  • Open‑source friendliness: 이 접근 방식은 공개된 모델 및 도구와 함께 작동하여 연구 및 개발자 커뮤니티가 재현할 수 있게 함.
  • Empirical validation: 실제 OSS 저장소에 대한 광범위한 실험을 제공하여, 다양한 이슈‑수정 작업에서 올바른 파일/함수를 찾는 데 일관된 개선을 보여줌.

방법론

  1. Tool Definition – Jump‑to‑Definition

    • 에이전트는 하나의 도구를 호출할 수 있으며, 이 도구는 심볼(함수, 클래스, 변수)이 주어지면 해당 심볼이 정의된 정확한 위치를 리포지토리에서 반환합니다.
    • 이는 개발자들이 IDE에서 코드를 탐색하는 방식을 그대로 반영하며, 실제 호출 그래프·임포트 계층 구조를 존중합니다.
  2. RL Formulation

    • 문제를 순차적 의사결정 과정으로 모델링합니다: 각 단계에서 LLM은 도구에 질의할지, 어떤 심볼을 질의할지, 혹은 최종 답변(목표 파일/함수)을 출력할지를 결정합니다.
    • 보상은 드물지만 의미 있습니다: 최종 예측이 정답 위치와 일치하면 높은 보상이 주어지고, 중간 보상은 효율적인 도구 사용(예: 점프 횟수 감소)을 장려합니다.
  3. Training Pipeline

    • 사전 학습된 LLM(7 B, 14 B, 또는 32 B)에서 시작합니다.
    • 모델이 도구와 상호작용하도록 하여 이슈 로컬라이제이션 예제들에 대한 트래젝터리를 생성합니다.
    • Proximal Policy Optimization (PPO)을 적용해 모델 정책을 업데이트하고, 언어 생성 능력은 유지하면서 탐색 결정 능력을 향상시킵니다.
  4. Evaluation Setup

    • 벤치마크는 Linux 커널, TensorFlow 등 여러 대형 프로젝트의 실제 GitHub 이슈들로 구성됩니다.
    • 평가 지표는 올바른 파일/함수를 찾는 top‑1 / top‑5 정확도와 질의당 도구 호출 횟수를 포함합니다.

결과 및 발견

모델 (크기)Top‑1 정확도Top‑5 정확도평균 도구 호출 수
7 B (RepoNavigator)48.2 %71.5 %2.3
14 B (RepoNavigator)55.9 %78.1 %2.1
32 B (RepoNavigator)62.4 %84.3 %1.9
14 B baseline (multi‑tool)44.7 %68.2 %4.7
32 B baseline (multi‑tool)51.3 %73.9 %4.2
Claude‑3.7 (closed‑source)58.1 %80.0 %
  • 효율성: RepoNavigator는 멀티‑툴 베이스라인에 비해 도구 호출 수가 대략 절반에 불과해 지연 시간과 API 비용을 감소시킵니다.
  • 모델 크기 vs. 성능: 가장 작은 7 B 모델조차도 파인튜닝되지 않은 더 큰 모델들을 능가하여, RL 파인튜닝이 순수 파라미터 수보다 더 큰 영향을 미친다는 것을 확인했습니다.
  • 폐쇄형 소스 격차 해소: 32 B 버전이 Claude‑3.7을 능가함으로써, 적절한 학습 신호만 제공되면 오픈‑소스 파이프라인도 상용 제품에 필적할 수 있음을 보여줍니다.

실용적 시사점

  • Developer Assistants: IDE 플러그인은 RepoNavigator를 내장하여 버그 보고서가 참조하는 파일/함수를 즉시 제안할 수 있어, 분류 시간을 단축합니다.
  • Automated Code Review: 봇은 검토자가 언급한 정확한 코드 영역을 자동으로 찾아내어, 정밀하고 컨텍스트를 고려한 제안을 가능하게 합니다.
  • Continuous Integration (CI) Optimization: CI 파이프라인은 에이전트를 활용해 영향을 받은 모듈에만 대상 테스트를 실행함으로써 피드백 루프를 가속화합니다.
  • Cost‑Effective Scaling: 경량 도구 하나만 필요하므로 클라우드 기반 LLM 서비스는 요청 오버헤드와 토큰 사용량을 줄여 대규모 배포 비용을 낮춥니다.
  • Open‑Source Ecosystem: 팀은 라이선스 제한 없이 RepoNavigator를 도입할 수 있어, 커뮤니티 주도의 개선 및 맞춤 확장(예: 언어별 정의로 이동 백엔드)을 촉진합니다.

제한 사항 및 향후 작업

  • Sparse Reward Signal: RL 훈련은 궤적 끝에서 이진 성공/실패에 의존하므로, 매우 큰 저장소에서는 수렴이 느려질 수 있습니다.
  • Tool Dependency: 이 접근 방식은 신뢰할 수 있는 언어‑인식 jump‑to‑definition 서비스가 있다고 가정합니다; 해당 서비스의 부정확성은 에이전트 성능에 직접적인 영향을 미칩니다.
  • Generalization to Non‑Code Artifacts: 현재 설계는 소스 코드의 심볼에 초점을 맞추고 있어, 구성 파일, 빌드 스크립트 또는 문서로 확장하는 것은 아직 미해결 상태입니다.
  • Multi‑Issue Scenarios: 여러 파일/함수에 걸친 이슈(예: 모듈 간 리팩터링)를 처리하는 부분은 충분히 탐구되지 않았습니다.
  • Future Directions: 저자들은 다단계 추론을 더 잘 다루기 위한 hierarchical RL 탐색, 더 풍부한 보상을 위한 static analysis 통합, 그리고 “find‑usages” 또는 “run‑test”와 같은 프리미티브를 포함하도록 도구 세트를 확장하면서도 single‑tool simplicity ethos를 유지하는 방안을 제안합니다.

저자

  • Zhaoxi Zhang
  • Yitong Duan
  • Yanzhi Zhang
  • Yiming Xu
  • Jiyan He
  • Yunfang Wu

논문 정보

  • arXiv ID: 2512.20957v1
  • 분류: cs.SE, cs.AI
  • 출판일: 2025년 12월 24일
  • PDF: PDF 다운로드
Back to Blog

관련 글

더 보기 »

[Paper] Gemini용 프로덕션 준비 프로브 구축

최첨단 language model 능력이 빠르게 향상되고 있습니다. 따라서 점점 더 강력해지는 시스템을 악용하는 악의적인 행위자들에 대한 보다 강력한 mitigations가 필요합니다. Prior w...