Toward Linking Declined Proposals and Source Code: An Exploratory Study on the Go Repository

1. 연구 배경 및 문제 정의 (Problem)

• 배경: 소프트웨어 추적성 (Traceability) 링크는 이슈 리포트, 설계 문서, 소스 코드 변경 사항 등을 연결하여 버그 위치 파악, 결함 예측, 코드 이해 등을 지원합니다. 기존 연구는 주로 수용된 (Accepted) 제안 (PR, 이슈 등) 과 구현된 소스 코드 간의 연결에 집중했습니다.
• 문제: 거부된 (Declined) 제안은 구현되지 않았기 때문에 코드베이스에 직접적으로 존재하지 않아 추적성 링크를 구축하기 어렵습니다. 그러나 거부된 제안에는 설계 대안, 실패한 결정, 거절된 트레이드오프 등 향후 개발자와 유지보수자에게 귀중한 설계 근거 (Design Rationale) 가 담겨 있습니다.
• 연구 목표: 거부된 제안과 관련된 소스 코드 간의 추적성 링크를 자동으로 확립하는 새로운 작업을 정의하고, 이를 해결하기 위한 LLM(대규모 언어 모델) 기반 파이프라인을 제안 및 평가하는 것입니다.

2. 방법론 (Methodology)

연구팀은 Go 공식 저장소의 거부된 제안 (Proposal) 을 대상으로 LLM 기반 파이프라인을 설계했습니다. 이 파이프라인은 크게 세 단계로 구성됩니다 (그림 2 참조).

A. 파이프라인 구조

1. Phase 0: Granularity Decision (粒度 결정)
   • 각 제안이 소스 코드의 어느 수준 (디렉토리, 파일, 함수) 에 해당하는지 LLM 을 통해 결정합니다.
   • 3 가지 수준 정의:
     • Directory Level: 파일/디렉토리 생성, 이동, 삭제 등 패키지 구조 변경.
     • File Level: 기존 파일 내 함수/상수 추가 등 파일 구조 변경 없음.
     • Function Level: 기존 함수 내부 로직 수정 등.
2. Phase 1: Localization (위치 특정)
   • 결정된粒度에 따라 LLM 이 관련 소스 코드를 찾습니다.
   • Agentless 기법 차용: LLM 의 컨텍스트 윈도우 제한을 극복하기 위해 계층적 접근을 사용합니다.
     • 디렉토리 레벨: 저장소 트리 구조를 입력받아 관련 디렉토리 식별.
     • 파일 레벨: 해당 디렉토리 내 관련 파일 식별.
     • 함수 레벨: 파일 내 함수 시그니처만 압축하여 입력, 관련 함수 식별.
3. Phase 2: Link Decision (링크 결정)
   • LLM 이 식별된 소스 코드 요소가 제안과 관련이 있는지 이진 분류 (Yes/No) 를 수행하여 최종 링크를 생성합니다.

B. 실험 설정

• 데이터셋: Go 공식 저장소의 제안 (337 개 수용, 448 개 거부 중, 최종 평가용 341 개 거부 제안 사용).
• 모델: DeepSeek-V3.1 (Temperature 0.0).
• 평가 지표: 정밀도 (Precision), 재현율 (Recall), F1 점수, 그리고 粒度 정확도 (Granularity Accuracy).
• Ground Truth: 거부된 제안은 구현되지 않았으므로 자동 매칭이 불가능하여, 연구팀이 개발한 '粒度 기준'과 '링크 정확도 기준'에 따라 수동으로 라벨링하여 평가했습니다.

3. 주요 기여 (Key Contributions)

1. 새로운 작업 정의: 수용되지 않은 (거부된) 제안과 소스 코드 간의 추적성 링크를 확립하는 최초의 연구입니다.
2. LLM 기반 파이프라인 설계: RAG(검색 증강 생성) 기반의 기존 방법론을 개선하여,粒度 결정 단계를 추가하고 임베딩 기반 검색 대신 LLM 기반의 문맥 인식 로컬라이제이션을 도입했습니다.
3. 실패 분석 및 통찰: 거부된 제안 링크 생성 실패의 원인을 심층 분석하여, 제안의 '길이'보다는 '구체적인 구현 정보의 유무'가 성능에 더 큰 영향을 미친다는 사실을 규명했습니다.

4. 실험 결과 (Results)

RQ1: 파이프라인의 성공 정도는 어떠한가?

• 粒度 정확도 (Granularity Accuracy): 전체 평균 0.836을 기록했습니다.
  • 파일 레벨: 0.887 (가장 높음)
  • 디렉토리 레벨: 0.696
  • 함수 레벨: 0.407 (가장 낮음, 미세한粒度 식별이 어려움)
• 링크 정밀도 (Precision): 전체 평균 0.643을 기록했습니다.
  • 파일 레벨: 0.688
  • 디렉토리 레벨: 0.529
  • 함수 레벨: 0.253 (粒度를 잘못 선택한 경우 정밀도가 0 이 되므로 전체 성능을 크게 저하시킴)
• 기초 연구 (Preliminary Study): 수용된 제안에 대한 기존 RAG 기반 방법 (LiSSA 등) 과 비교 시, 제안된 LLM 파이프라인이 모든 경우에서 더 높은 F1 점수와 정밀도를 보여 유효성이 입증되었습니다.

RQ2: 왜 파이프라인이 실패하는가?

실패 원인은 크게 두 가지로 분류되었습니다.

1. 구체적 정보 부재 (Insufficient Implementation Guidance): 논의 내용에서 '무엇을' 구현할지는 언급되었으나, '어떻게/어디에' 구현할지에 대한 구체적인 정보가 부족할 때 실패율이 높았습니다 (실패 사례의 42.9%).
2. 정보 왜곡 (Obscured Information): 필요한 정보가 존재하지만 긴 논의나 상충되는 제안, 숨겨진 단서 등으로 인해 LLM 이 핵심 정보를 놓치는 경우입니다.

• 참고: 논의의 길이 (Word count) 와 성능 간에는 유의미한 상관관계가 없었습니다.
• **성공 요인:**粒度가 정확히 결정된 경우, 논의에서 타겟 코드가 **명시적 (Explicit)**으로 언급될수록 정밀도가 높았습니다 (Level-1: 0.841 vs Level-3: 0.408).

5. 의의 및 향후 방향 (Significance & Future Work)

• 의의: 거부된 제안에 담긴 '실패한 지식'을 코드베이스와 연결함으로써 개발자가 과거의 설계 결정과 그 이유를 쉽게 추적할 수 있게 합니다. 이는 소프트웨어 유지보수 비용 절감과 설계 의사결정 지원에 기여합니다.
• 한계 및 향후 연구:
  • 입력 증강 (Augmentation): 논의에 구현 정보가 부족할 경우, 관련 제안이나 주석 등 외부 컨텍스트를 추가로 제공하여 성능을 높여야 함.
  • 요약 (Summarization): 관련 없는 정보로 핵심이 가려진 경우, 링크 생성에 필요한 핵심 정보만 추출한 요약본을 LLM 입력으로 사용하여 성능을 개선해야 함.

이 연구는 소프트웨어 리포지토리 마이닝 (Mining Software Repositories) 분야에서 LLM 의 능력을 활용하여 기존에 간과되었던 '거부된 아티팩트'의 가치를 재발견하고 자동화하는 중요한 첫걸음입니다.