기술 요약: Phoenix – 멀티 에이전트 LLM을 통한 안전한 GitHub 이슈 해결

문제 정의

GitHub의 오픈 소스 저장소에는 수천 개의 미해결 이슈가 쌓여 지속적인 유지보수 병목 현상을 일으키고 있습니다. 대규모 언어 모델(LLM)은 소프트웨어 엔지니어링 작업(예: Devin, SWE-Agent, AutoCodeRover)을 자동화하는 데 잠재력을 보여주었으나, 이슈 해결률만을 최적화하는 것은 종종 안전성을 저해합니다. 일부 이슈를 해결하면서도 다른 이슈에서 회귀(regression)를 유발하는 시스템은 프로덕션 환경에서 불확실한 순가치를 제공합니다. 또한, 기존 벤치마크는 API 게이트웨이 필터링, 토큰 만료, 기존의 깨진 테스트 스위트와 같은 프로덕션 배포의 복잡성을 간과한 채 오프라인 성능에만 집중하는 경향이 있습니다.

방법론

Phoenix는 단순한 해결률보다 정확성 보존을 우선시하며, 이슈 트리aging부터 풀 리퀘스트(PR) 생성까지의 과정을 해결하도록 설계된 멀티 에이전트 LLM 시스템입니다. 이 시스템은 중앙 오케스트레이터(Orchestrator)와 레이블 기반의 GitHub 웹훅 상태 머신에 의해 조정되는 폐쇄 루프 파이프라인을 통해 작동합니다.

시스템 아키텍처

파이프라인은 일반적인 이슈 해결 프로세스의 각 단계에 대응하는 6개의 특화된 에이전트로 워크플로우를 분해합니다:

1. Planner Agent (플래너 에이전트): 정제된 이슈 텍스트, 저장소 파일 트리 및 관련 발췌본을 수신합니다. 접근 방식, 수정할 파일, 구현 단계 및 테스트 전략을 상세히 기술한 구조화된 JSON 계획을 출력합니다. 파일 관련성을 결정하기 위해 키워드 중복 점수를 사용합니다.
2. Reproducer Agent (재현 에이전트 - 선택 사항): 버그를 입증하기 위해 베이스 브랜치에서 실패하는 합성 테스트를 생성하려고 시도합니다. 이 단계의 실패는 비차단(non-blocking) 방식으로, 테스트 하네스를 자동으로 생성할 수 없더라도 파이프라인이 코딩 단계로 진행할 수 있도록 허용합니다.
3. Coder Agent (코더 에이전트): 계획과 이전 실패 피드백을 바탕으로 변경된 파일의 전체 내용을 생성합니다. 자가 검증을 강제하고 기존 코드 스타일을 준수합니다.
4. Tester Agent (테스터 에이전트): 프로젝트의 테스트 스위트를 실행합니다. 결정적으로, 이 에이전트는 베이스라인 인지 테스트 평가 전략을 채택합니다:
   • 수정 사항을 임시 저장(stash)하고 수정되지 않은 베이스 브랜치에서 스위트를 실행하여 베이스라인 실패($B$)를 수집합니다.
   • 변경 사항을 복구하고 다시 실행하여 변경 후 실패($P$)를 수집합니다.
   • $P \setminus B = \emptyset$ (기존에 통과하던 테스트가 이제 실패하지 않음)인 경우 정확성이 보존된 것으로 간가합니다. 이를 통해 깨진 CI 파이프라인이 있는 저장소에서도 평가가 가능합니다.
5. Failure Analyst Agent (실패 분석 에이전트): 새로운 실패가 감지되면, 이 에이전트는 출력을 분석하고 최대 2회의 재시도 사이클 동안 코더에게 구조화된 피드백을 제공합니다.
6. PR Agent (PR 에이전트): 이슈를 참조하여 풀 리퀘스트를 작성하고 열며, 상태를 인간의 검토를 위한 ai:review로 전환합니다.

안전 메커니즘

개발 및 배포 과정에서 관찰된 경험적 실패 모드로부터 7가지 계층적 안전 제어 장치를 도출했습니다:

1. 경로 탐색 방지: 파일 쓰기가 저장소 루트를 벗어나지 않도록 검증합니다.
2. 레이블 상태 배타성: 스태일(stale) 레이블 누적을 방방지하기 위해 원자적 상태 전환을 보장합니다.
3. 워크플로우 파일 가드레일: 권한 오류를 방지하기 위해 .github/workflows/에 대한 쓰기를 조용히 드롭합니다.
4. 콘텐츠 정제: API 게이트웨이(WAF) 403 응답을 피하기 위해 이슈 본문을 절삭하고 스택 트레이스를 제거합니다.
5. 재시도 사이클 제한: 실패 분석 피드백을 2라운드로 제한하며, 변화가 동일한 경우 루프를 종료하는 '진전 없음 감지기'를 가동합니다.
6. 동시성 직렬화: 공유 클론 상에서 한 번에 하나의 이슈만 처리되도록 하는 설치별 잠금(lock)을 보장합니다.
7. 설치 토큰 갱신: 긴 실행 시간 동안 인증 실패를 방지하기 위해 GitHub App 토큰을 만료 전에 선제적으로 갱신합니다.

주요 기여

1. 아키텍처: 재현 에이전트가 포함된 6개 에이전트 파이프라인, 레이블 기반 상태 머신, 그리고 분해를 통한 격리된 테스트 및 실패 귀속을 가능하게 하는 명시적 설계 근거를 제공합니다.
2. 베이스라인 인지 평가: 기존의 실패와 Phoenix가 도입한 회귀를 구분하는 테스트 전략을 통해, 깨진 CI를 가진 저장소에서도 평가를 가능하게 합니다.
3. 배포 교훈: 실제적인 위험 요소(WAF 필터링, 토큰 만료, 권ian 경계)를 규명하고 이를 해결하기 위해 개발된 특정 메커니즘을 제시합니다.

결과

논문은 두 가지 평가 환경에 대한 결과를 제시합니다:

1. SWE-bench Lite (24개 인스턴스)

12개 저장소(각 3개씩)에서 선별된 24개 인스턴스에 대해 평가되었습니다.

• 오라클 해결(Oracle Resolution): Phoenix는 75%의 오라클 해결률(24개 중 18개)을 달럽했습니다.
• 회귀 안전성: 모든 오라클 통과 실행에서, 통과-통과(pass-to-pass) 회귀는 발생하지 않았습니다.
• 실패 모드: 실패는 주로 터미널 ai:failed 상태 또는 평가기 타임아웃에 의한 것이었으며, 안전성 위반 때문이 아니었습니다.
• 참고: 저자들은 프로덕션 웹훅 경로 사용으로 인해 이 선별된 슬라이스가 전체 분할 리더보드 결과와 직접 비교될 수 없음을 명시했습니다.

2. 42개 실제 이슈에 대한 파일럿 테스트 (14개 저장소)

Easy, Medium, Hard 난이도 티어를 아우르는 14개 저장소에서 평가되었습니다.

• 정확성 보존 (CP): Phoenix는 100% CP(42/42 이슈)를 달성했습니다. 베이스라인 대비 새로운 테스트 실패를 도입하지 않았습니다.
• 해결 시간: "Hard" 티어 저장소에서 평균 엔드 투 엔드 해결 시간은 122초였습니다.
• 질적 검사: 수동 검토 결과 출력 품질의 이분법적 차이가 드러났습니다:
  • 약 50%의 PR은 기존 모듈을 수정하는 잘 타겟팅된 수정 사항이었습니다.
  • 약 50%의 PR은 잘못된, 혹은 만들어진 경로(예: src/core/config.py)에 코드를 배치했습니다. 이들은 CP를 통과했으나(회귀를 유발하지 않았으므로), 보고된 버그를 수정하지는 못했습니다. 이러한 한계는 코드 합성 능력보다는 플래너의 어휘적 파일 랭킹(lexical file ranking) 때문인 것으로 분석됩니다.

의의 및 주장

본 논문은 Phoenix를 단순히 해결된 이슈의 수를 극대화하는 시스템이 아니라, 프로덕션 환경에서 정확성 보존과 안전성을 우선시하는 시스템으로 포지셔닝합니다.

• 최우선 요구사항으로서의 안전성: 저자들은 신뢰할 수 있는 자율 코드 수정에는 안전성을 추측된 설계가 아닌, 경험적 실패 모드에서 도출된 엔지니어링 요구사항으로 취급하는 것이 필요하다고 주장합니다.
• 완곡한 해결 주장: 논문은 100% 정확성 보존이 100% 이슈 해결을 의미하는 것은 아님을 인정합니다. 그 간극은 코드 생성 능력이 아닌 로컬라이제이션(localization)의 한계(의미론적 검색 없이 이슈 어휘를 파일 경로로 매핑하는 플래너의 능력 부족)에서 기인합니다.
• 프로덕션 준비성: 오프라인 벤치마크에 집중하는 이전 연구들과 달리, Phoenix는 실제 웹훅, 실제 브랜치, 실제 PR을 위해 설계되었으며, 프로덕션 배포의 마찰(예: 토큰 만료, API 게이트웨이)을 처리하도록 특별히 튜닝된 메커니즘을 갖추고 있습니다.

저자들은 의미론적 검색이 로컬라이제이션 실패를 해결하기 위한 차세대 필수 단계이지만, 현재의 멀티 에이전트 아키텍처는 엄격한 안전 제어와 베이스라인 인지 테스트를 통해 안전한 엔드 투 엔드 이슈 해결이 가능하다는 것을 성공적으로 입증했다고 결론짓습니다.