RepoGenesis: Benchmarking End-to-End Microservice Generation from Readme to Repository

1. 문제 정의 (Problem Statement)

• 현황의 한계: 기존 대규모 언어 모델 (LLM) 및 에이전트 기반 코드 생성 벤치마크 (예: HumanEval, SWE-Bench, ClassEval 등) 는 주로 고립된 함수/클래스 수준의 생성이나 기존 코드베이스의 수정 (Issue Resolution) 에 집중해 왔습니다.
• 실제 개발 워크플로우와의 괴리: 실제 소프트웨어 개발, 특히 현대적인 마이크로서비스 아키텍처에서는 단일 함수가 아닌 완전한 저장소 (Repository) 전체를 자연어 요구사항 (README) 에서부터 0 에서 1 로 구축하는 과정이 필수적입니다. 이는 아키텍처 설계, 의존성 관리, 파일 간 일관성 유지, 배포 가능성 등을 포함하는 복잡한 작업입니다.
• 평가 부재: 현재까지 자연어 요구사항에서 완전한 웹 마이크로서비스 저장소를 생성하는 능력을 체계적으로 평가할 수 있는 다국어 벤치마크가 존재하지 않았습니다.

2. 방법론 (Methodology)

저자들은 이 격차를 해소하기 위해 RepoGenesis라는 새로운 벤치마크를 제안했습니다.

가. 데이터셋 구성 (Benchmark Construction)

• 규모 및 범위: 총 106 개의 저장소 (훈련용 76 개, 평가용 30 개) 로 구성되며, 18 개의 도메인과 11 개의 프레임워크 (Python: Flask, Django, FastAPI 등 / Java: Spring Boot, Javalin, Quarkus 등) 를 포함합니다.
• 데이터 소스:
  • 실제 GitHub 프로젝트: 배포 가능한 6 개의 오픈소스 프로젝트.
  • 전문가 감독 생성 (Expert-supervised): 24 개의 실제 존재하지 않는 도메인 (게임 백엔드, 파일 관리 등) 에 대한 요구사항을 인간 전문가가 작성하고, LLM 이 구현한 후 인간이 검증한 프로젝트.
• 품질 보증 (QA): "검토 - 반박 (Review-Rebuttal)" 루프를 도입하여 3 개의 LLM 검토자와 1 명의 인간 Area Chair 가 참여합니다. 테스트 케이스의 정확성, 커버리지, 가독성을 평가하며, 불일치가 발생하거나 점수가 낮을 경우 LLM 리파이너를 통해 개선하는 과정을 최대 5 회 반복합니다.
• 평가 지표:
  • Pass@1: 생성된 저장소가 모든 블랙박스 테스트를 통과하는지 여부 (기능적 정확성).
  • API Coverage (AC): 요구사항에 명시된 API 엔드포인트 중 올바르게 구현된 비율 (구현 완성도).
  • Deployment Success Rate (DSR): 생성된 코드가 환경 설정 없이 성공적으로 배포 및 실행되는지 여부 (배포 가능성).

나. 평가 프로세스

• 입력: 서비스 기능, API 스키마, 인증 방식, 운영 제약 조건 등을 포함한 README.md.
• 출력: 소스 코드, 설정 파일, 의존성 정의 (requirements.txt 또는 pom.xml), 배포 스크립트 (start.sh) 를 포함한 완전한 저장소.
• 실행: 샌드박스 환경에서 생성된 저장소를 배포하고, 블랙박스 테스트를 실행하여 위 3 가지 지표를 측정합니다.

3. 주요 기여 (Key Contributions)

1. 최초의 다국어 마이크로서비스 벤치마크: 자연어 요구사항에서 웹 마이크로서비스 저장소 전체를 생성하는 것을 평가하는 최초의 다국어 (Python/Java) 벤치마크인 RepoGenesis 를 공개했습니다.
2. 엄격한 품질 보증 메커니즘: 인간 Area Chair 와 다중 LLM 이 참여하는 '검토 - 반박' 프로세스를 통해 테스트 케이스의 신뢰성과 편향을 최소화했습니다.
3. 다차원 평가 체계: 단순 코드 통과 여부를 넘어, 구현 완성도 (AC) 와 실제 배포 가능성 (DSR) 을 종합적으로 평가하는 새로운 메트릭을 제시했습니다.
4. 모델 개선 실증: RepoGenesis 데이터로 파인튜닝된 GenesisAgent-8B가 GPT-5 mini 와 유사한 성능을 달성함을 보여, 벤치마크가 모델 발전에 유효한 도구임을 입증했습니다.

4. 실험 결과 (Results)

가. 에이전트 및 IDE 성능

• 성능 격차: 오픈소스 에이전트 (DeepCode, MetaGPT 등) 보다 상업용 IDE (Copilot, Cursor 등) 의 성능이 압도적으로 높았습니다.
  • 최고 성능: Copilot (Claude 기반) 이 Python 에서 23.67%, Java 에서 21.45% 의 Pass@1 을 기록했습니다. 이는 최상의 시스템조차 100% 에 훨씬 미치지 못함을 의미합니다.
  • 오픈소스 에이전트: 대부분의 오픈소스 에이전트는 Pass@1 에서 10% 미만의 성능을 보였습니다.
• 언어별 차이: Python 이 Java 보다 일반적으로 성능이 좋았으나, Java 의 경우 표준화된 빌드 시스템 (Maven/Gradle) 으로 인해 배포 성공률 (DSR) 이 Python 보다 높게 나타나는 경향이 있었습니다.

나. 주요 발견 (Key Insights)

1. AC-DSR 간극 (The AC-DSR Gap): 많은 에이전트가 API 스키마는 잘 구현하여 높은 AC(최대 73.91%) 를 보이지만, 실제 배포 (DSR) 에 실패하는 경우가 많았습니다. 이는 인프라 구성 (배포 스크립트, 환경 설정) 과 로직 생성 간의 불일치를 시사합니다.
2. 실패 원인 분석: 실패의 주요 원인은 다음과 같습니다.
   • 파일 간 일관성 부족 (50.2%): API, 데이터 모델, 에러 처리가 여러 파일 간에 일관되지 않음.
   • 아키텍처 일관성 문제 (26.0%): 전체적인 시스템 구조 설계 실패.
   • 의존성 관리 오류 (23.8%): 라이브러리 버전 충돌 또는 잘못된 의존성 설정.
3. 난이도 민감도: 저장소의 복잡도가 증가할수록 (Easy → Hard) 모든 시스템의 성능이 급격히 저하되었습니다. 특히 Hard 난이도에서는 소형 모델의 성능이 거의 0 에 수렴했습니다.

다. 파인튜닝 효과

• RepoGenesis(Train) 데이터로 파인튜닝된 GenesisAgent-8B는 GPT-5 mini 와 유사한 수준의 성능을 달성하여, 고품질 벤치마크 데이터가 모델 능력 향상에 결정적인 역할을 함을 증명했습니다.

5. 의의 및 결론 (Significance)

• 소프트웨어 공학의 패러다임 전환: 코드 생성이 단순한 함수 단위를 넘어, 실제 배포 가능한 전체 시스템 (Microservice Repository) 생성 단계로 확장되어야 함을 강조합니다.
• 현실적 장벽 제시: 현재 LLM 기반 코딩 에이전트들이 "코드 작성"은 잘하지만, "시스템 구축 및 배포"라는 엔지니어링 관점에서는 여전히 큰 한계가 있음을 명확히 보여줍니다.
• 향후 연구 방향:
  • 아키텍처 설계 및 인프라 관리 능력 강화.
  • AC-DSR 간극을 해소하기 위한 에이전트 아키텍처 개선.
  • 더 다양한 언어 (Go 등) 와 아키텍처 패턴 (이벤트 기반 등) 으로 벤치마크 확장.

결론적으로, RepoGenesis 는 LLM 기반 코딩 에이전트의 진정한 능력을 평가하고, 실제 소프트웨어 개발 워크플로우에 적용 가능한 차세대 에이전트 개발을 위한 필수적인 기준점 (Benchmark) 을 제공합니다.