TICoder: A Repository-Level Code Generation Framework with Test-Driven Planning and Implementation-Aware Reuse

기술 요약: TICoder

문제 정의

대규모 언어 모델(LLM)을 이용한 저장소 수준(Repository-level)의 코드 생성은 복잡한 코드 의존성과 제한된 컨텍스트 창(Context window)으로 인해 상당한 어려움에 직면해 있습니다. 기존의 접근 방식들은 함수를 재사용하기 위해 검색 증강 생성(RAG)과 계획(Planning) 메커니를 활용하지만, 저자들은 현재의 최첨단(SOTA) 방법론에서 두 가지 결정적인 한계를 식별했습니다:

1. 계획 단계에서의 테스트 기반 행동 가이드 부재: 기존의 계획 기반 방식은 자연어(NL) 요구사항으로부터 직접 구현 단계를 도출합니다. 그러나 자연어 요구사항은 종종 모호하거나 불완전하여 신뢰할 수 없는 계획으로 이어질 수 있습니다. 현재의 테스트 기반 생성 방식은 주로 코드 생성 또는 생성 후 단계에서 테스트 케이스를 적용하며, 계획 과정을 가이드하는 데 있어 테스트의 잠재력을 탐구하지 못하고 있습니다.
2. 재사용 시 코드 수준의 구현 인지 능력 부족: 기존의 검색 전략은 구현 단계와 함수 설명 사이의 의미적 유사성에 크게 의존합니다. 이들은 실제 코드에 내재된 구현 로직을 간과하는 경우가 많습니다. 또한, 검색된 함수들이 저장소 내에서 실제로 어떻게 사용되는지(사용 패턴)에 대한 이해 없이 프롬프트에 삽requently 삽입되어 비효적인 재사용을 초래합니다.

방법론: TICoder 프레임워크

저자들은 저장소 수준의 코드 생성의 계획 및 재사용 단계를 개선하기 위해 설계된 TICoder 프레임워크를 제안합니다. 이 프레임워크는 세 가지 주요 단계로 구성됩니다:

1. 테스트 기반 반복 계획 (Test-Driven Iterative Planning)

자연어 요구사항만으로 계획을 생성하는 대신, TICoder는 테스트 케이스를 행동 명세(Behavioral specification)로 활용하여 구현 단계를 정교화합니다. 이 단계는 두 가지 LLM 역할이 포함된 "판사 및 성찰(Judge-and-reflection)" 메커니즘을 채택합니다:

• LLM-as-a-Planner (플래너로서의 LLM): 명확성, 경계 조건 인식, 명시적 의존성 등의 원칙에 따라 요구사항과 테스트 케이스를 바탕으로 초기 구현 단계 시퀀스를 생성합니다.
• LLM-as-a-Judge (판사로서의 LLM): 생성된 단계들을 기능적 커버리지/일관성, 독립성, 세분화 정도라는 세 가지 차원에서 평가합니다.
• 반복적 정교화: 단계가 품질 임계치를 충족하지 못하면, 판사가 피드백을 제공하고 플래너는 단계를 수정합니다. 이 루프는 계획이 만족스럽거나 최대 반복 횟수에 도달할 때까지 지속됩니다.

2. 구현 인지형 코드 재사용 (Implementation-Aware Code Reuse)

이 단계는 관련 호출 대상 함수(Callee functions)를 검색하고 이를 효과적으로 사용하는 방법을 식별하는 데 중점을 둡니다.

• 이중 관점 호출 함수 검색 (Dual-View Callee Function Retrieval): 함수를 검색하기 위해 TICoder는 다음을 결합한 결합 유사도 점수를 계산합니다:
  • 기능적 유사도 ($Sim_F$): 구현 단계와 함수 설명 사이의 의미적 유사도.
  • 구현 유사도 ($Sim_I$): (LLM에 의해 생성된) 구현 단계의 코드 표현과 실제 함수 구현 코드 사이의 유사도.
  • 최종 점수는 가중 합계($Sim = \alpha \cdot Sim_F + \beta \cdot Sim_I$)입니다.
• 이중 단계 사용 패턴 선택 (Dual-Stage Usage Pattern Selection): 함수가 올바르게 사용되도록 하기 위해, TICoder는 저장소에서 대표적인 사용 패턴을 선택합니다:
  • 그래프 기반 식별: 저장소 호출 그래프(RCG)를 구축하여 검색된 호출 대상 함수의 모든 호출자(Caller) 함수를 식별합니다.
  • 구조 기반 클러스터링: 호출하는 함수의 집합(구조적 동등성)을 기준으로 호출자 함수들을 그룹화합니다.
  • 퍼플렉서티 기반 필터링: 각 클러스터 내에서 가장 관련성이 높은 호출자(가장 낮은 퍼플렉서티)를 중심점으로 선택합니다. 이후 글로벌 필터를 통해 이 중심들을 퍼플렉서티에 따라 순위 매겨 상위 $n_p$개의 패턴을 선택함으로써, 컨텍스트의 풍부함과 토큰 효율성 사이의 균형을 맞춥니다.

3. 향상된 코드 생성 (Enhanced Code Generation)

최종 코드 생성 단계는 정교화된 구현 단계, 검색된 호출 함수, 선택된 사용 패턴, 테스트 케이스 및 원래의 요구사항을 하나의 프롬프트로 통합하여 LLM이 최종 코드를 생성하도록 합니다.

주요 기여

본 논문은 세 가지 주요 기여를 주장합니다:

1. TICoder 프레임워크: 테스트 기반 반복 계획과 구현 인지형 코드 재사용을 통합한 새로운 저장소 수준 코드 생성 프레임워크입니다.
2. 구현 인지형 재사용 전략: (기능적 + 구현 유사도)의 이중 관점 검색 메커니즘과 (클러스터링 + 퍼플렉서티 필터링)의 이중 단계 선택 전략을 통해 저장소 함수를 정밀하게 식별하고 재사용합니다.
3. 광범적인 실증적 평가: 다양한 LLM과 벤치마크에서 TICoder가 SOTA 베이스라인보다 우수함을 입증하는 종합적인 실험을 수행했습니다.

실험 결과

저자들은 세 가지 백본 LLM(GPT-4o-mini, DeepSeek-V3, Qwen2.5-Coder-7B)을 사용하여 두 가지 널리 사용되는 벤치마크인 CoderEval(Python 및 Java)과 DevEval(Python)에서 TICoder를 평가했습니다.

• 전반적인 성능: TICoder는 모든 베이스라인(SimpleRAG, RepoCoder, AllianceCoder, RepoScope 포함)을 일관되게 능가했습니다. 최고 성능을 보인 베이스라인 대비 평균 **11.52%**의 향상을 달이트했습니다.
• 통계적 유의성: 양측 검정 t-검정을 통해 성능 향상이 통계적으로 유의미함($p < 0.05$)을 확인했습니다.
• 절제 연구 (Ablation Study): 핵심 구성 요소(계획, 테스트 케이스, 반복 정교화, 이중 관점 검색, 사용 패턴) 중 하나라도 제거하면 성능 저하가 발생하여 각 모듈의 필요성을 입증했습니다.
  • 특히, 계획 모듈을 제거했을 때 Pass@1이 6.87% 하락했습니다.
  • 생성 단계에서 테스트 케이스를 제거했을 때 10.42%의 상당한 하락이 발생했습니다.
• 하이퍼파라미터 민감도:
  • 반복 횟수: 성능은 일반적으로 반복에 따라 향상되었으나 비단조적(non-monotonic)이었습니다. 과도한 반복은 노이즈를 유발할 수 있습니다.
  • 유사도 가중치: 기능적 유사도가 일반적으로 더 중요했으나, 구현 유사도 또한 특히 Java에서 상당한 이득을 제공했습니다.
  • 사용 패턴: 적절한 수의 패턴(예: 2개)이 최상의 결과를 냈습니다. 너무 적으면 컨텍스트가 제한되고, 너무 많으면 노이즈가 도입됩니다.

의의 및 주장

본 논문은 테스트 케이스를 계획 단계에 명시적으로 포함시키고 구현 로직에 기반하여 검색을 수행함으로써, TICoder가 기존의 계획 기반 RACG 방식의 특정 한계를 해결한다고 주장합니다. 저자들은 행동 명세(테스트)와 구조적 컨텍스트(사용 패턴)를 통해 자연어 요구사항과 실행 가능한 코드 사이의 간극을 메움으로써, TICoder가 복잡한 저장소 환경에서 LLM이 더 정확하고 문맥에 적합한 코드를 생성할 수 있게 한다고 주장합니다. 이 연구는 성공적인 저장소 수준의 생성을 위해서는 단순히 유사한 코드를 찾는 것을 넘어, 그 코드가 어떻게 행동적으로 명세되고 구조적으로 통합되어 있는지를 이해하는 것이 필요함을 강조합니다.