기술 요약: CodeTeam

문제 정의

본 논문은 자연어 요구사항 문서로부터 전체 소프트웨어 저장소(repository)를 구축하는 **자연어 기반 저장소 생성(Natural Language to Repository, NL2Repo)**의 과제를 다룹니다. 함수 단위의 코드 생성(예: HumanEval)과 달리, NL2Repo는 긴 계획 수립 범위(planning horizons), 안정적인 파일 간 인터페이스, 그리고 시스템 수준의 통합 과정에서만 나타나는 불일치를 해결하기 위한 반복적인 디버깅을 필요로 합니다.

기존 방식들은 이 영역에서 세 가지 결정적인 격차에 직면해 있습니다:

1. 기계 검증 가능한 계약(Machine-Checkable Contracts)의 부재: 기존 방법들은 코딩을 시작하기 전 저장소 구조에 대한 공식적이고 기계가 읽을 able한 명세가 부족한 경우가 많습니다.
2. 파일 간 불일치(Cross-File Inconsistency): 에이전트들이 구현 과정에서 여러 파일 간의 인터페이스 일관성을 유지하는 데 어려움을 겪습니다.
3. 조정 결핍(Coordination Deficits): 현재의 워크플로우는 의존성을 인식하는 스케줄링 및 반복적인 수정을 통한 전역 계획(global plan)에 맞춘 경계 컨텍스트(bounded-context) 구현을 조율하는 데 실패하곤 합니다.

RepoBench나 FEA-Bench와 같은 벤치마크들이 기존 코드베이스 내에서의 완성이나 점진적 변경에 집중하는 반면, NL2Repo 설정(무에서 유를 창조하는 생성)은 빈 작업 공간으로부터 아키텍처 설계, 의존성 관리, 패키징을 요구합니다.

방법론: CodeTeam 프레임워크

CodeTeam은 계획, 의사결정, 구현을 별도의 조정된 단계로 분리하는 LLM 기반 멀티 에이전트 프레임워크입니다. 이는 **소프트웨어 디자인 스케치(Software Design Sketch, SDS)**를 중앙의 기계 검증 가능한 계약으로 활용합니다.

1. 계획 단계: 아키텍트 경쟁 및 CTO 선정

• 아키텍트 에이전트(Architect Agents): 다수의 아키텍트 에이전트($N=4$)가 독립적으로 경쟁하는 SDS 초안을 작성합니다. 이 스케치는 기술 스택, 파일 구조, 공개 인터페이스, 그리고 개발자 할당 계획(팀 규모 및 파일 소유권 명시)을 정의합니다.
  • RAG 기반화(RAG Grounding): 아키텍트들은 선택적으로 큐레이션된 공개 저장소 코퍼스에서 디자인 참조를 검색하여 스케치를 구체화함으로써, 디자인의 수렴(convergence)과 모듈 누락을 방지합니다.
  • 다양성 메커니즘: 아키텍트들은 무작위화된 디자인 선호도를 사용하며, 이전 후보자의 고수준 요약만을 전달받음으로써 다양한 솔루션을 보장합니다.
• CTO 에이전트: 최고 기술 책임자(CTO) 에이전트는 구조적 타당성, 인터페이스 일관성, 구현 가능성, 그리고 팀 적합성을 기준으로 후보들을 평가합니다. CTO는 최적의 SDS를 선정하고 이를 단일 진실 공급원(single source of truth) 역할을 하는 정형화된 기계 실행 가능 계약(JSON 형식)으로 정규화합니다.

2. 구현 단계: 의존성 인식 실행

• 개발자 에이전트(Developer Agents): CTO가 선정한 계획에 따라 특정 개발자 에이전트들이 인스턴스화됩니다. 각 에이전트는 특정 파일의 하위 집합을 소유합니다.
• 컨텍스트 및 스케줄링: 개발자들은 의존성 인식 스케줄러(dependency-aware scheduler) 하에서 작동합니다. 이들은 전체 파일 내용 대신, 대상 파일, 관련 SDS 파편, 그리고 의존성에 대한 인터페이스 개요(시그니처, 불변량)를 포함하는 압축된 컨텍스트를 전달받습니다.
• Git 기반 조정: 에이전트들은 격리된 브랜치에서 작업합니다. 파일을 완료하면 구조화된 update_reason 메시지와 함께 변경 사항을 커밋합니다. 이를 통해 다른 에이전트들이 전체 파일 내용에 접근하지 않고도 인터페이스 개요를 업데이트할 수 있어, 파일 간 일관성을 유지할 수 있습니다.

3. 수정 단계: QA 주도 반복

• QA 에이전트: 품질 보증(QA) 에이전트는 완료된 의존성 레이어를 대상으로 경량화된 생성 테스트를 실행합니다.
• 피드백 루프: 실패가 발생하면, QA 에이전트는 근본 원인(예: 인터페이스 불일치, 심볼 누락)을 진단하고 해당 소스 파일의 소유자에게 수정 요청을 라우팅합니다. 의존성 파일은 인터페이스 변경이 전파되는 경우에만 다시 큐에 추가됩니다.
• 종료: 실패가 감지되지 않거나, 한계치에 도달하거나, 자원이 고갈될 때까지 루프가 지속됩니다.

주요 기여

1. CodeTeam 프레框架: SDS 경쟁, 선택적 RAG 기반화, CTO 가이드 기반 계약 정규화, 프로젝트별 개발자 할당, 의존성 인식 실행, Git 기반 조정, 그리고 QA 주도 수정을 통합한 NL2Repo를 위한 새로운 멀티 에이전트 시스템입니다.
2. 포괄적 평가: SketchEval 벤치마크(프롬프트 엔지니어링 및 지도 학습 미세 조정 변형을 CodeS 및 기타 베이스라인과 비교)와 NL2Repo-Bench(실행 기반 테스트)에 대한 외부 검증 프로토콜을 통한 엄격한 평가를 수행했습니다.
3. 절제 연구(Ablation) 통찰: 검색 증강 계획(RAG)과 동적 개발자 할당이 성능의 주요 동력이며, Git 기반 조정이 보완적인 안정성을 제공한다는 것을 입증하는 체계적인 분석을 제공합니다.

실험 결과

SketchEval 성능 (구조적 유사도)

• 프롬프트 엔지니어링 (PE): CodeTeam은 전체 **SketchBLEU 51.7%**를 달성하여, 가장 강력한 베이스라인인 CodeS (PE)보다 4.1 포인트(8.6% 상대적 향상) 앞섰습니다.
• 지도 학습 미세 조정 (SFT): CodeTeam은 **60.9%**를 달성하여 CodeS (SFT)를 2.9 포인트 차이로 넘어섰습니다.
• 하위 점수 분석: 개선은 **구조적 매칭(Structural Matching)**과 **데이터 흐름 매칭(Dataflow Matching)**에서 가장 두드러졌으며, 이는 표면적인 토큰 중첩보다 저장소 수준의 무결성과 파일 간 일관성이 더 우수함을 나타냅니다.
• 난이도 확장성: 성능 격차는 의존성이 밀집된 Hard 저장소에서 크게 벌어졌으며, 여기서 CodeTeam은 CodeS (PE) 대비 4.7 포인트를 개선했습니다.

NL2Repo-Bench 성능 (실행 기반)

• 통과율(Pass Rate): CodeTeam은 두 설정 모두에서 가장 높은 평균 테스트 통과율을 기록했습니다: 34.6% (PE) 및 42.3% (SFT).
• 오류 분석: CodeTeam은 CodeS와 비교했을 때 패키징 오류(34.2%에서 22.1%로)와 임포트 오류(28.7%에서 19.4%로)를 유의미하게 줄였습니다. 이는 SDS 계약이 구조적 누락(예: __init__.py 누락 또는 잘못된 패키지 이름)을 효과적으로 방지함을 확인시켜 줍니다.
• 실패 모드의 변화: 구조적 오류가 감소함에 따라 로직 오류의 비중이 증가했습니다. 이는 CodeTeam이 조직적 실패를 성공적으로 해결하여, 병목 현상을 의미적 정확성(semantic correctness) 단계로 이동시켰음을 시사합니다.

절제 연구 결과

• RAG (검색 증강 생성): RAG를 제거하면 SketchBLEU가 8.1% 상대적으로 하락했습니다. RAG는 주로 계획 단계(SDS 파싱 성공률 및 구조적 타당성)와 계획의 다양성을 개선했습니다.
• 동적 개발자 할당: 이 메커니즘을 제거했을 때 가장 큰 하락(9.9% 상대적)이 발생했습니다. 이는 팀 규모와 파일 소유권을 저장소의 모듈 구조와 일치시키는 데 매우 중요하며, QA 라운드와 인터페이스 불일치를 줄여줍니다.
• Git 조정: 이를 제거하면 작은 폭이지만 일관된 하락(2.9% 상대적)이 발생했으며, 이는 수정 과정 중 인터페이스 드리프트를 안정화하는 반응형 메커리즘 역할을 함을 보여줍니다.

의의 및 주장

본 논문은 NL2Repo가 단순히 긴 컨텍스트의 코드 생성 작업이 아니라, 조정된 소프트웨어 엔지니어링 프로세스라고 주장합니다.

• 모델 용량보다 워크플로우: 결과는 구조화된 멀티 에이전트 워크플로우(계획, 역할 전문화, 반복적 수정)가 백본 모델이 미세 조정된 경우에도 측정 가능한 이점을 제공한다는 것을 시사합니다. 즉, 워크플로우는 순수 프롬프팅이나 SFT가 완전히 해결할 수 없는 파일 간 일관성 제한을 보완합니다.
• 명시적 계약: SDS는 파일 경계와 의존성을 묶는 기계 검증 가능한 계약 역할을 하며, 이를 통해 정밀한 수정 라우팅을 가능하게 하고 단일 에이전트 또는 느슨하게 조정된 시스템에서 흔히 발생하는 "연쇄적 재작업(cascading rework)"을 방지합니다.
• 실제 배포: 본 연구는 사전 아키텍처 계획(SDS 생성)과 동적 할당에 토큰을 투자하는 것이 다운스트림의 재작업을 줄인다는 것을 입증합니다. 또한, 제한된 횟수의 QA 반복(2~3 라운드)이 대부분의 품질 개선을 포착한다는 점을 시사하여, 본 프레임워크가 자원 제약이 있는 시나리오에서도 실행 가능함을 보여줍니다.

저자들은 Code-Team이 LLM 기반 저장소 생성을 단순한 코드 생성기가 아닌 조정된 개발 팀으로 취급함으로써, 어떻게 더 구조적이고, 검사 가능하며, 확장 가능하게 만들 수 있는지 보여준다고 결론짓습니다.