HAFixAgent: History-Aware Program Repair Agent

1. 문제 정의 (Problem)

자동화된 프로그램 수정 (Automated Program Repair, APR) 기술은 최근 대규모 언어 모델 (LLM) 과 에이전트 기반 시스템으로 진화하고 있습니다. 그러나 기존 시스템들은 주로 **현재 코드 스냅샷 (snapshot)**에만 의존하여 로컬 컨텍스트를 제공하며, 소프트웨어 저장소 (Repository) 의 이력 (History) 정보를 간과하는 경향이 있습니다.

• 한계점: 복잡한 버그 (특히 여러 파일에 걸친 다중 헝크, Multi-hunk bugs) 는 단일 라인 수정보다 훨씬 어렵습니다. 기존 LLM 기반 에이전트들은 코드 변경의 맥락, 개발자의 의도, 그리고 버그를 유발한 이전 커밋에 대한 정보가 부족하여 복잡한 수정 작업을 수행하는 데 한계가 있습니다.
• 가설: 저장소 이력 (특히 git blame을 통해 도출된 정보) 을 에이전트의 수정 루프에 통합하면, 복잡한 다중 헝크 버그를 포함한 APR 성능을 대폭 향상시킬 수 있을 것입니다. 하지만 이 정보가 에이전트를 혼란스럽게 하거나 비용만 증가시킬지에 대한 의문이 존재했습니다.

2. 방법론 (Methodology)

저자들은 HAFixAgent라는 새로운 역사 인식 (History-Aware) 프로그램 수정 에이전트를 설계하고 구현했습니다.

2.1 핵심 아키텍처

HAFixAgent 는 Observe-Act-Feedback 루프를 기반으로 하며, 다음과 같은 세 가지 주요 설계 결정을 따릅니다.

1. 최소한의 에이전트 아키텍처: 복잡한 도구 상호작용 대신 표준 bash 명령어 (grep, sed, find 등) 를 사용하여 코드 탐색, 패치 생성, 테스트 실행을 반복합니다.
2. 역사적 컨텍스트 주입 (History Injection):
   • Blame 기반 히스토리 추출: 버그가 발생한 라인에 대한 git blame을 실행하여 해당 라인을 마지막으로 수정한 커밋 (Blame Commit) 을 찾습니다.
   • 히스토리 휴리스틱: 해당 커밋에서 다음 세 가지 형태의 컨텍스트를 추출하여 에이전트의 프롬프트에 주입합니다.
     • fn_all: 변경된 파일 내 모든 함수 이름 (구조적 맥락).
     • fn_pair: 버그가 포함된 함수의 수정 전/후 코드 스냅샷 (의미론적 진화).
     • fl_diff: 커밋 전체의 diff 패치 (세밀한 편집 패턴).
   • LLM 심판자 (LLM-as-a-Judge): 여러 개의 blame 커밋이 존재하는 경우 (특히 Python 프로젝트), 가장 관련성 높은 커밋을 선택하기 위해 LLM 을 활용합니다.
   • Fallback 전략: 버그가 추가 (Insertion) 만으로 발생하여 git blame이 적용되지 않는 경우, 삽입 위치 근처의 실행 가능한 코드를 대상으로 blame 을 수행하는 대체 전략을 사용합니다.
3. 반복적 수정 루프: 에이전트는 추출된 역사적 컨텍스트와 현재 코드, 테스트 실패 정보를 바탕으로 행동을 결정하고, 결과를 관찰하여 다음 단계를 계획합니다.

2.2 실험 설정

• 데이터셋: Java 의 **Defects4J (854 개 버그)**와 Python 의 BugsInPy (501 개 버그).
• 모델: 모든 실험 (기존 방법론 재현 포함) 에 동일한 LLM (DeepSeek-V3.2-Exp) 을 사용하여 공정한 비교를 보장했습니다.
• 비교 대상:
  • RepairAgent: 최신 에이전트 기반 APR 시스템.
  • BIRCH-feedback: 다중 헝크 버그 수정에 특화된 시스템.
• 연구 질문 (RQ):
  • RQ0: 실제 버그에서 역사적 정보의 가용성은 어느 정도인가?
  • RQ1: HAFixAgent 의 실제 버그 수정 효과는 어떠한가?
  • RQ2: 역사 인식 수정의 효율성과 견고성 (Robustness) 은 어떠한가?

3. 주요 기여 (Key Contributions)

1. HAFixAgent 설계 및 구현: 저장소 컨텍스트를 심층적으로 통합하여 의사결정 루프를 강화한 새로운 APR 에이전트.
2. 자동화된 역사적 컨텍스트 구축 방법: 3 가지 다른 blame 기반 휴리스틱과 견고한 Fallback 전략을 포함한 자동화 프레임워크 제공.
3. 대규모 실증 평가: 1,355 개의 버그 (Java, Python) 에 대한 광범위한 평가와 동일 LLM 기반의 베이스라인 재현을 통해 역사적 정보의 가치를 입증.

4. 실험 결과 (Results)

4.1 예비 연구 (RQ0): 역사적 정보의 가용성

• 광범위한 가용성: Defects4J 의 71.1%, BugsInPy 의 87.4% 버그가 git blame 정보를 가질 수 있었습니다.
• 커밋 집중도: Java (Defects4J) 는 99.5% 의 경우 단일 커밋으로 집중되어 있었으나, Python (BugsInPy) 은 58.4% 만 단일 커밋이었고 나머지는 여러 커밋에 분산되어 있었습니다. 이는 언어별 개발 관행의 차이를 반영합니다.

4.2 효과성 (RQ1)

• 베이스라인 대비 우월성: HAFixAgent 는 동일한 LLM 을 사용한 RepairAgent 보다 Defects4J 에서 +56.6%, BIRCH-feedback 보다 +47.1% 더 많은 버그를 수정했습니다.
• 역사적 컨텍스트의 기여:
  • Defects4J: 역사적 컨텍스트를 추가하면 수정률이 +4.4% 증가했습니다.
  • BugsInPy: 역사적 컨텍스트가 특히 효과적이어서 수정률이 +38.6% 급증했습니다.
  • 복잡한 버그 (SFMH): 단일 파일 내 다중 헝크 (SFMH) 버그에서 역사적 컨텍스트의 효과가 가장 컸으며, BugsInPy 의 SFMH 버그 수정률은 190.7% 증가했습니다.
• 상호 보완성: 세 가지 휴리스틱 (fn_all, fn_pair, fl_diff) 은 서로 다른 버그 집합을 해결하여 상호 보완적인 역할을 했습니다.

4.3 효율성 및 견고성 (RQ2)

• 비용 효율성: 역사적 컨텍스트 추가는 에이전트의 단계 수 (Steps) 나 토큰 비용 (Cost) 을 유의미하게 증가시키지 않았습니다. 오히려 복잡한 버그 (SFMH) 의 경우 역사적 정보가 에이전트의 수렴 속도를 높여 비용을 절감하는 경우도 있었습니다.
• 오류 위치 추정 (Fault Localization) 노이즈 내성:
  • 실제 환경에서 오류 위치가 정확하지 않을 수 있음을 가정하여 라인 시프트 (+1, +3, +5) 노이즈를 주입했습니다.
  • 결과: 역사적 정보가 없는 에이전트는 노이즈가 커질수록 성능이 급격히 떨어졌으나 (SFMH 에서 +5 시 0% 로 붕괴), 역사적 정보를 가진 에이전트는 40~56% 의 성공률을 유지했습니다. 이는 역사적 컨텍스트가 부정확한 위치 정보에 대한 안전망 (Safety Net) 역할을 함을 보여줍니다.

5. 의의 및 결론 (Significance)

이 논문은 다음과 같은 중요한 시사점을 제공합니다:

1. 역사적 정보의 중요성: 단순한 코드 스냅샷만으로는 해결하기 어려운 복잡한 다중 헝크 버그를 수정할 때, 저장소 이력 (Commit History) 은 필수적인 컨텍스트임을 입증했습니다.
2. 에이전트 설계의 방향성: 복잡한 도구 상호작용보다는 **고품질의 컨텍스트 (역사적 정보)**를 에이전트의 루프에 통합하는 것이 성능 향상에 더 효과적일 수 있음을 보였습니다.
3. 실용성: 역사적 정보의 활용은 추가적인 비용 부담 없이, 특히 오류 위치 추정이 불완전한 실제 환경에서 APR 시스템의 견고성을 크게 향상시킵니다.
4. 미래 작업: 여러 커밋이 관련된 경우 (Python 등) 여러 커밋의 컨텍스트를 통합하거나, 다중 에이전트 아키텍처를 통해 더 복잡한 수정 작업을 수행하는 방향으로 발전할 수 있습니다.

요약하자면, HAFixAgent는 소프트웨어 저장소의 과거 이력을 적극적으로 활용함으로써, 기존 LLM 기반 프로그램 수정 기술의 한계를 극복하고 복잡한 버그 수정의 성공률과 견고성을 획기적으로 개선한 획기적인 접근법입니다.