Automated Root-Cause Subclassification and No-Code Fix Generation for Invalid Bug Reports

기술 요약: 잘못된 버그 보고서에 대한 자동화된 근본 원인 하위 분류 및 코드 없는 수정 방안 생성

문제 제기
소프트웨어 유지보수에는 막대한 비용이 소요되며, 버그 보고서의 상당 부분이 "잘못된 (invalid)" 것으로 판명되어 소스 코드 수정이 필요하지 않습니다. 이러한 보고서들은 종종 사용자의 오해, 구성 오류, 외부 의존성, 또는 기능 요청에서 비롯됩니다. 현재 고객 지원 팀은 이러한 보고서들을 수동으로 분류하여 근본 원인을 식별하고 "코드 없는 수정 방안 (source code 변경 없이 실행 가능한 지침)"을 제공합니다. 이 수동 프로세스는 리소스를 많이 소모하고 해결을 지연시키며, 사용자들이 자신의 문제를 어떻게 해결해야 할지 불확실하게 만듭니다. 기존 연구에서는 잘못된 버그 탐지나 근본 원인 분석을 다루었지만, 잘못된 보고서의 근본 원인 하위 분류 자동화와 실행 가능한 코드 없는 수정 방안 생성을 동시에 자동화한 연구는 없습니다.

방법론
저자들은 잘못된 버그 보고서를 근본 원인에 따라 하위 분류하고 이에 상응하는 코드 없는 수정 방안을 생성하도록 설계된 자동화 프레임워크인 IssueSupport를 제안합니다. 본 연구는 Brave Browser GitHub 저장소에서 파생된 독창적이고 수동으로 큐레이션된 벤치마크를 활용하며, 여기에는 302 개의 고품질 주석 달린 잘못된 버그 보고서와 실제 정답인 하위 분류 및 성공/실패한 코드 없는 수정 방안이 포함되어 있습니다.

프레임워크는 특정 연구 질문에 대응하기 위해 네 가지 다른 실험 구성을 평가합니다:

1. Vanilla LLM 파이프라인: 독점 (Gemini 3.1 Pro, GPT-5.4, Claude Opus 4.6) 및 오픈 소스 (GLM-5, MiniMax M2.7, Kimi 2.5) LLM 을 제로샷 프롬프트로 사용하여 분류하고 수정 방안을 생성합니다.
2. 사전 정보 부재 (Ablation): 잘못된 하위 분류의 특정 분류 체계나 수정 가이드라인 없이 LLM 에 프롬프트를 입력하여 사전 지식의 영향을 측정하는 설정입니다.
3. 검색 증강 생성 (RAG): 역사적 버그 보고서와 공식 프로젝트 위키 문서를 사용하여 밀도 벡터 검색 followed by 크로스 인코더 재순위화를 수행하는 2 단계 검색 과정으로 LLM 을 증강합니다.
4. 에이전트 웹 검색: WebThinker 에서 영감을 받은 에이전트 기반 파이프라인으로, 응답을 생성하기 전에 업스트림 변경 로그, 서드파티 트래커와 같은 동적 외부 증거를 수집하기 위해 제한된 다단계 웹 검색을 수행합니다.

주요 기여

1. 분류 체계 및 방법론: 잘못된 버그 보고서를 위한 포괄적인 근본 원인 기반 분류 체계 (외부 시스템 및 의존성, 잘못된 구성, 기능 요청, 재현 불가, 질문, 의도된 동작, 잘못된 버전 등 7 가지 하위 분류 포함) 와 자동화된 하위 분류 방법론.
2. 코드 없는 수정 방안 생성: 잘못된 보고서에 대한 실행 가능하고 비침습적인 해결책을 자동으로 생성하는 독창적인 접근 방식.
3. 포괄적 평가: 사전 정보 (하위 분류) 와 컨텍스트 엔지니어링 (RAG, 웹 검색) 이 분류 정확도와 수정 방안 생성 품질에 미치는 영향을 엄격하게 평가.
4. 새로운 벤치마크: 명시적인 하위 분류 라벨링과 수정 방안 품질 평가가 부족한 기존 데이터셋의 공백을 메우는, 잘못된 버그 보고서, 그 근본 원인 하위 분류, 검증된 코드 없는 수정 방안을 포함한 골드 스탠다드 벤치마크 도입.

실험 결과
본 연구는 하위 분류에는 **가중 F1 점수 (Weighted F1-Score)**를, 코드 없는 수정 방안 생성에는 BERTScore와 Judge LLM 성공률의 조합을 사용하여 성능을 평가했습니다.

• 하위 분류 (RQ1):

  • RAG가 0.66 의 가중 F1으로 전체적인 최고 성과를 달성하여 Vanilla LLM(0.65) 과 에이전트 웹 검색 (0.64) 을 약간 앞섰습니다.
  • RAG 는 **재현 불가 (0.85 F1)**와 **외부 시스템 및 의존성 문제 (0.67 F1)**에서 탁월한 성능을 보였습니다.
  • 잘못된 버전은 모든 방법에서 가장 어려운 하위 분류로 남았으며, 점수는 0.00 에서 0.29 사이였습니다.
  • 에이전트 웹 검색은 외부 버전 데이터에 접근함으로써 잘못된 버전 카테고리에서 Gemini 의 점수를 0.00 에서 0.20 으로 향상시키는 등 구체적인 유용성을 보여주었습니다.

• 코드 없는 수정 방안 생성 (RQ2):

  • 에이전트 웹 검색이 (Gemini 3.1 Pro 사용 시) **68.9%**의 전체 Judge LLM 성공률을 기록하여 RAG(64.4%) 와 Vanilla LLM(64.9%) 을 앞섰습니다.
  • 에이전트 검색은 외부 컨텍스트가 중요한 **질문 (72.2%)**과 잘못된 버전 (41.7%) 카테고리에서 특히 효과적이었습니다.
  • RAG는 역사적 프로젝트 논의를 활용하여 의도된 동작 카테고리에서 가장 좋은 성능 (88.2% 성공률) 을 보였습니다.
  • "사전 정보 부재" Ablation 연구는 하위 분류 정보를 제공하는 것이 일반적으로 성능을 향상시킨다는 것을 밝혔으나, 특정 사례 (예: 잘못된 구성) 에서는 사전 정보를 제거함으로써 모델이 경직된 분류에 방해받지 않고 수정 방안을 더 직접적으로 추론할 수 있게 했음을 보여주었습니다.

의의 및 주장
본 논문은 서로 다른 구성 요소가 서로 다른 작업에 효과적이라고 주장합니다: RAG는 역사적 컨텍스트와 프로젝트 특정 지식이 필요한 하위 분류 작업에 우수하며, 에이전트 웹 검색은 버전 릴리스, 서드파티 의존성 등 최신 외부 정보가 필요한 코드 없는 수정 방안 생성에 더 유익합니다.

본 연구는 이 워크플로우를 자동화함으로써 다음과 같은 잠재력을 가지고 있다고 결론지었습니다:

• 고객 지원 및 개발자의 수동 분류 노력 감소.
• 버그 추적 시스템 내에서 사용자에게 즉각적이고 실행 가능한 지침 제공.
• 인간의 개입 없이 잘못된 보고서를 해결함으로써 사용자 경험 향상.

저자들은 BERTScore 가 높은 텍스트 유사성을 나타내지만, Judge LLM 지표가 기능적 정확성을 평가하는 데 더 중요하다고 강조합니다. 또한 프레임워크의 효과성은 RAG 를 위한 풍부한 프로젝트 데이터의 가용성과 에이전트 검색을 위한 환각 없이 외부 검색을 탐색하는 모델의 능력에 의존한다고 지적합니다. 본 논문은 모든 잘못된 버그 보고서를 해결한다고 주장하지 않으며, "잘못된 버전"과 "잘못된 구성"과 같은 하위 분류는 여전히 어렵다는 점을 인정합니다.