Byam: Fixing Breaking Dependency Updates with Large Language Models

1. 문제 정의 (Problem)

현대 소프트웨어 개발은 타사 라이브러리 (의존성) 에 크게 의존하고 있으며, 이러한 라이브러리의 API 는 새로운 기능 추가, 버그 수정, 보안 취약점 해결 등을 위해 지속적으로 진화합니다. 그러나 이러한 진화는 종종 Breaking Dependency Updates(파괴적인 의존성 업데이트) 를 초래합니다.

• 발생 원인: API 의 삭제, 파라미터 이름/타입 변경, 메서드 시그니처 변경 등.
• 영향: 클라이언트 애플리케이션의 컴파일 실패 또는 런타임 오류 발생.
• 현황: 개발자는 이러한 파괴적인 변경 사항을 식별하고 코드를 수동으로 수정하는 데 많은 시간과 노력이 소요됩니다. 기존 규칙 기반 (Rule-based) 자동화 도구는 다양한 실제 사례와 프로젝트별 컨텍스트를 처리하는 데 한계가 있습니다.

2. 제안된 방법론: Byam (Methodology)

저자들은 대규모 언어 모델 (LLM) 을 활용하여 파괴적인 의존성 업데이트로 인한 클라이언트 코드의 컴파일 오류를 자동으로 수정하는 새로운 파이프라인 Byam을 제안합니다. Byam 은 다음 3 단계로 구성됩니다.

A. 파이프라인 단계

1. 실패한 빌드 정보 추출 (Step 1):
   • 의존성 업데이트 후 생성된 빌드 로그를 분석하여 컴파일 오류가 발생한 파일, 오류 메시지, 오류 위치 (라인 번호) 를 식별합니다.
   • API 차이점 (APIDiff) 추출: japicmp 도구를 사용하여 업데이트 전후의 의존성 버전 간 API 변경 사항 (메서드 삭제, 시그니처 변경 등) 을 구조적으로 분석합니다.
2. LLM 을 통한 수정 생성 (Step 2):
   • 추출된 정보를 바탕으로 LLM 에게 프롬프트를 구성하여 수정된 코드를 생성합니다.
   • 프롬프트 설계 전략: 단순한 오류 메시지뿐만 아니라 다음 요소들을 포함하는 8 가지 프롬프트 변형 (P1~P8) 을 실험했습니다.
     • Erroneous Line: 오류가 발생한 구체적인 코드 라인 포함.
     • APIDiff: 의존성 버전 간의 API 변경 사항 명시.
     • Chain of Thought (CoT): LLM 이 단계별 추론 (오류 분석, 원인 파악, 수정 계획 수립) 을 하도록 유도하는 지시문 포함.
3. 코드 업데이트 및 검증 (Step 3):
   • 생성된 패치를 클라이언트 프로젝트에 적용하고 빌드를 재실행하여 수정 성공 여부를 확인합니다.

B. 실험 설정

• 데이터셋: Java 프로젝트의 파괴적인 의존성 업데이트를 포함하는 BUMP 벤치마크 데이터셋 사용 (103 개의 파괴적인 업데이트 사례).
• 평가 대상 LLM 5 개: Google Gemini-2.0 Flash, OpenAI GPT-4o-mini, OpenAI o3-mini, Alibaba Qwen2.5-32b-instruct, DeepSeek V3.
• 평가 지표:
  • 빌드 성공률 (BSR): 전체 빌드가 성공한 비율.
  • 파일 수정 성공률 (FFSR): 오류가 있던 파일 중 수정된 파일 비율.
  • 컴파일 오류 수정률 (CEFR): 개별 컴파일 오류 중 해결된 비율.
  • 상대적 오류 수정 비율 (REF): 수정된 오류 대비 새로 발생한 오류를 고려한 순 효과.

3. 주요 기여 (Key Contributions)

1. Byam 프레임워크 제안: 파괴적인 의존성 업데이트에 특화된 컨텍스트 (APIDiff, 오류 라인, CoT) 를 활용한 LLM 기반 자동 수정 접근법 제시.
2. 대규모 실험 및 분석: 5 가지 LLM 과 8 가지 프롬프트 전략을 103 개의 실제 사례에 적용하여 체계적으로 평가.
3. 재현성 보장: 연구의 재현성을 위한 전체 복제 패키지 (Replication Package) 를 공개하여 향후 연구를 촉진.

4. 실험 결과 (Results)

• 최고 성능 모델: OpenAI o3-mini가 모든 모델 중 가장 우수한 성능을 보였습니다.
  • 빌드 성공률 (BSR): 최적의 프롬프트 (P8: CoT + 오류 라인 + APIDiff) 사용 시 27% (103 개 중 28 개) 의 빌드를 완전히 성공시켰습니다.
  • 파일 수정률: 실패한 빌드 내에서 41% 의 오류 파일을 수정했습니다.
  • 개별 오류 수정률: 개별 컴파일 오류의 78% 를 해결했습니다.
• 프롬프트의 중요성:
  • APIDiff와 오류 라인 정보를 포함하는 것이 모델 성능 향상에 결정적이었습니다.
  • CoT(Chain of Thought) 는 o3-mini 와 같은 추론 능력이 뛰어난 모델에서는 성능을 높였으나, Gemini-2.0 Flash 와 같은 모델에서는 오히려 성능을 저하시켰습니다.
  • 오픈소스 모델인 Qwen2.5-32b-instruct 는 성능이 상대적으로 낮았으며, 복잡한 프롬프트 구성 시 오히려 성능이 하락하는 경향을 보였습니다.
• 새로운 오류 발생 (RQ3): o3-mini 는 기존 오류를 수정하면서도 새로운 오류를 도입하는 비율이 가장 낮아 안정성이 높았습니다. 반면, 일부 모델은 수정 과정에서 새로운 오류를 더 많이 발생시키기도 했습니다.

5. 의의 및 결론 (Significance)

• 개발자 부담 경감: LLM 을 활용하면 파괴적인 의존성 업데이트로 인한 수동 수정 작업을 상당 부분 자동화할 수 있으며, 특히 개별 오류의 78% 를 해결한다는 점은 개발자가 남은 오류에 집중할 수 있게 하여 효율성을 극대화합니다.
• 컨텍스트의 중요성: 단순한 코드 수정을 넘어, API 변경 사항 (APIDiff) 과 오류 발생 위치를 명시적으로 제공하고 단계별 추론 (CoT) 을 유도하는 프롬프트 설계가 자동 수정 성공의 핵심 요소임을 입증했습니다.
• 미래 전망: 본 연구는 LLM 기반 자동화 도구가 소프트웨어 유지보수, 특히 의존성 관리 분야에서 실용적으로 적용될 수 있음을 보여주며, 향후 더 강력한 추론 모델과 통합된 CI/CD 파이프라인 (예: Pull Request 봇) 에의 적용 가능성을 제시합니다.

요약하자면, Byam은 LLM 의 추론 능력과 정밀한 컨텍스트 정보를 결합하여 파괴적인 의존성 업데이트로 인한 컴파일 오류를 효과적으로 해결하는 새로운 패러다임을 제시한 연구입니다.