[Paper] 거절된 제안과 소스 코드 연결을 향하여: Go 저장소에 대한 탐색적 연구

Source: arXiv - 2602.09467v1

개요

이 논문은 크게 간과된 오픈‑소스 개발 영역인 거절된 제안—논의는 되었지만 최종적으로 거부된 GitHub 이슈—을 탐구합니다. 이러한 버려진 논의를 Go 언어 소스 코드의 관련 부분에 자동으로 연결함으로써, 저자들은 숨겨진 설계 이유와 의사결정 기준을 밝혀내어 개발자들이 특정 아이디어가 왜 거부되었는지 이해하는 데 도움을 줍니다.

Key Contributions

• First systematic attempt to create traceability links between declined GitHub issues and source code in a large OSS project.
• LLM‑driven linking pipeline that selects the appropriate code granularity (file, function, or module) and generates candidate links.
• Empirical evaluation on the official Go repository, achieving 83.6 % accuracy in granularity selection and a mean precision of 64.3 % for the generated links.
• Failure analysis that identifies common reasons why linking fails (e.g., vague or redundant discussion threads).
• Open dataset and tooling (issue‑code pairs, pipeline scripts) that other researchers and practitioners can reuse.

방법론

1. Data Collection – The authors harvested all declined proposals (GitHub issues) from the Go repository, focusing on feature or language‑change requests.
2. Pre‑processing – Issue titles, bodies, and comment threads were cleaned and segmented into concise “discussion summaries.”
3. LLM‑based Granularity Prediction – A large language model (LLM) was prompted to decide whether the relevant code lives at the file, package, or function level, based on the textual cues in the issue.
4. Candidate Retrieval – Using the predicted granularity, the pipeline queried the Go codebase (via lexical search, AST analysis, and semantic embeddings) to retrieve the most plausible code elements.
5. Ranking & Filtering – Retrieved candidates were re‑scored with the LLM, which considered contextual similarity and any explicit references (e.g., file names) found in the discussion.
6. Manual Validation – A subset of links was manually inspected by the authors to compute precision, recall, and granularity‑selection accuracy.

The entire workflow is fully automated, requiring only the issue text and the repository’s source tree as inputs.

결과 및 발견

숫자가 의미하는 바

• LLM은 거절된 제안이 코드의 어디에 영향을 미쳤을지를 신뢰할 수 있게 추론할 수 있으며, 해당 이슈가 패치로 구현되지 않았더라도 마찬가지입니다.
• 정밀도 약 64 %는 제안된 링크의 약 3분의 2가 실제로 관련성이 있음을 나타내며, 이는 이전에 시도된 적이 없는 작업에 대한 유망한 기준점입니다.
• 실패 사례는 종종 모호한 논의(예: “We don’t need this feature”) 또는 중복된 댓글 스레드에서 비롯되며, 이들은 구체적인 기술적 세부사항이 거의 제공되지 않습니다.

Practical Implications

• Design Rationale Mining – 팀은 거절된 기능 뒤에 있는 “왜”를 자동으로 찾아낼 수 있어, 새로운 기여자가 프로젝트 표준을 이해하고 반복적인 제안을 피할 수 있습니다.
• Onboarding & Documentation – 거절된 이슈를 코드와 연결하면 검색 가능한 문서로 전환할 수 있어, 개발자가 특정 모듈이나 함수와 연결된 과거 결정을 빠르게 확인할 수 있습니다.
• Tooling Integration – 파이프라인을 GitHub Action이나 IDE 플러그인으로 감싸서, 유지 관리자가 이슈를 declined 상태로 닫을 때 향후 참조용 관련 코드 위치를 제안하도록 할 수 있습니다.
• Risk & Security Audits – 거절된 제안은 때때로 보안 문제를 표시합니다; 이를 영향을 받은 코드와 자동으로 연결하면 감사자가 잠재적인 취약점을 추적하는 데 도움이 됩니다.
• Cross‑Project Knowledge Transfer – 다른 언어나 프레임워크도 동일한 접근 방식을 채택해 자체 이슈 트래커에서 “결정 지식 베이스”를 구축할 수 있습니다.

제한 사항 및 향후 연구

• 도메인 특수성 – 이 연구는 Go 저장소에만 초점을 맞추었으며, 구조가 덜 체계적인 이슈 토론이나 다른 프로그래밍 패러다임을 가진 프로젝트에서는 결과가 다를 수 있습니다.
• LLM 의존성 – 정확도는 기본 LLM이 기술 용어를 이해하는 능력에 달려 있으며, 최신이거나 보다 전문화된 모델이 성능을 향상시킬 수 있습니다.
• 세분화 범위 – 세 가지 세분화 수준만 고려했으며, 더 세밀한 링크(예: 특정 라인이나 AST 노드)는 범위에 포함되지 않았습니다.
• 수동 검증 부담 – 평가를 더 큰 코퍼스로 확장하려면 반자동 또는 크라우드소싱 검증 방법이 필요합니다.
• 향후 방향 – 파이프라인을 수락된 제안으로 확장하여 엔드‑투‑엔드 추적성을 구현하고, 코드 변경 이력을 통합하며, 멀티모달 입력(예: 설계 다이어그램) 탐색이 유망한 다음 단계입니다.

저자

• Sota Nakashima
• Masanari Kondo
• Mahmoud Alfadel
• Aly Ahmad
• Toshihiro Nakae
• Hidenori Matsuzaki

논문 정보

• arXiv ID: 2602.09467v1
• 분류: cs.SE
• 출판일: 2026년 2월 10일
• PDF: Download PDF