기술 요약: ProgramBench

문제 제기

SWE-bench 과 같은 소프트웨어 공학 분야의 대규모 언어 모델 (LLM) 을 위한 현재 벤치마크는 주로 기존 코드베이스 내에서 버그 수정이나 특정 기능 구현과 같은 국소적 작업을 평가합니다. 이러한 작업은 기존 아키텍처를 이해하는 능력을 요구하지만, 프로그래밍 언어 선택, 시스템을 모듈로 분해, 또는 자료구조 선정과 같은 고수준의 소프트웨어 설계 의사결정 능력을 테스트하지는 않습니다. 에이전트가 소프트웨어를 처음부터 (from scratch) 구축하는 데 increasingly 배포됨에 따라, 포괄적인 소프트웨어 개발 능력을 평가할 엄격한 기준이 부족합니다. 기존 접근 방식은 종종 모델이 미리 정의된 스키레톤을 완성하는 '빈칸 채우기' 패러다임에 의존하여, 진정한 아키텍처 추론 능력을 평가하지 못합니다.

방법론

작업 구성

ProgramBench 는 에이전트가 오직 컴파일된 실행 파일(골드 바이너리) 과 그 문서만을 제공받는 벤치마크를 도입합니다. 에이전트는 해당 실행 파일의 동작을 재현할 수 있는 소스 코드베이스와 빌드 스크립트를 설계하고 구현해야 합니다.

• 제약 조건: 에이전트는 인터넷 접속이 차단된 Docker 컨테이너 내에서 작동합니다. 원본 소스 코드에 접근하거나 (예: Ghidra 를 통한) 역공학을 하거나, 원본 바이너리를 래핑 (wrap) 할 수 없습니다.
• 자유도: 에이전트는 프로그래밍 언어, 알고리즘, 아키텍처를 자유롭게 선택할 수 있습니다. 평가는 구조적이 아닌 행위 기반이며, 구현 세부 사항과 무관하게 입력 - 출력 동작이 참조 실행 파일과 일치하면 솔루션이 통과됩니다.

벤치마크 구축 파이프라인

저자들은 오픈소스 GitHub 저장소 (CLI 도구부터 FFmpeg 및 PHP 와 같은 복잡한 시스템까지) 에서 200 개의 작업 인스턴스를 반자동 파이프라인을 통해 합성했습니다:

1. 저장소 선정: 독립 실행형 실행 파일을 생성하는 컴파일 언어 (C/C++, Go, Rust, Java) 로 필터링했습니다.
2. 실행 파일 구축: SWE-agent 가 골드 실행 파일을 컴파일하고 빌드 단계를 기록합니다.
3. 행위 테스트 생성: SWE-agent 가 골드 실행 파일, 문서, 기존 테스트를 탐색하여 포괄적인 행위 테스트 세트를 생성합니다.
   • 커버리지: 에이전트는 핵심 기능을 포착하는 것을 목표로 라인 커버리지를 극대화하기 위해 반복적으로 테스트를 작성합니다.
   • 품질 관리: 린터가 약한 어설션 (예: 종료 코드만 확인하거나, 자명한 부분 문자열 일치) 을 플래그합니다. 골드 바이너리를 통과하지 못하거나 더미 바이너리를 통과하는 테스트는 수정되거나 폐기됩니다.
   • 결과: 최종 테스트 세트는 작업을 해결하는 에이전트에게 숨겨집니다.
4. 환경 준비: 골드 실행 파일은 실행 전용 권한이 부여된 깨끗한 Docker 이미지에 주입됩니다. 소스 코드, 빌드 산출물, 버전 관리 기록은 구현 세부 사항의 유출을 방지하기 위해 제거됩니다.

평가 설정

• 모델: mini-SWE-agent 스케폴드를 사용하여 9 개의 최첨단 언어 모델 (Claude Opus 4.7, GPT-5.4, Gemini 3.1 Pro 포함) 을 평가했습니다.
• 지표:
  • 해결 비율 (% Resolved): 모델이 생성된 테스트의 100% 를 통과한 작업의 비율.
  • 테스트 통과율 (% Tests Passed): 부분적 진전을 포착하는 작업 인스턴스당 평균 통과율.
  • 사기 탐지: 인터넷 접속이 허용된 제거 실험 (ablation studies) 에서, LM-as-a-judge 파이프라인이 소스 코드를 검색하거나 바이너리를 래핑한 솔루션을 플래그했습니다.

주요 기여

1. ProgramBench 벤치마크: 바이너리로부터 엔드투엔드 소프트웨어 재구성을 요구하는 200 개의 작업으로 구성된 새로운 데이터셋으로, 다양한 도메인 (데이터베이스, 인터프리터, 압축, CLI 도구) 과 규모 (200 에서 190 만 줄의 코드) 를 포괄합니다.
2. 행위 평가 프레임워크: 소스 코드 구조가 아닌 실행 파일의 행위를 평가하는 구현-무관 테스트 세트를 생성하는 방법으로, 언어 간 솔루션을 허용합니다.
3. 아키텍처 능력 분석: 현재 모델이 고수준 설계에 어려움을 겪으며, 인간이 작성한 모듈식 코드와 크게 다른 모놀리식 단일 파일 구현을 자주 생성한다는 체계적인 연구 결과.
4. 사기 방지: 소스 코드 검색, 바이너리 래핑과 같은 '사기' 행위에 대한 엄격한 조사와, 유효한 평가를 위한 필수 기본값으로 인터넷 접속 차단 및 실행 전용 환경의 확립.

결과

• 전체 해결 0 건: 200 개의 모든 작업과 9 개의 모델에 걸쳐, 어떤 모델도 단일 작업을 완전히 해결하지 못했습니다. 가장 성능이 좋았던 모델인 Claude Opus 4.7 은 단 **3%**의 작업에서 테스트의 95% 를 통과했을 뿐입니다.
• 부분적 진전: 전체 해결은 달성하기 어렵지만, 모델들은 의미 있는 부분적 진전을 이룹니다. 모든 실행에 걸친 중앙값 테스트 통과율은 32% 입니다. 성능은 모델에 따라 크게 달라지며, Opus 4.7 이 가장 앞서고 그 뒤를 Opus 4.6 과 Sonnet 4.6 이 따릅니다.
• 작업 난이도: 작업 난이도 순위와 관련하여 성능은 대체로 모델과 무관합니다. 모델들은 간단한 CLI 유틸리티 (예: fzf, jq) 에서는 일관되게 더 잘 수행하지만, 복잡한 시스템 (예: FFmpeg, php-src, typst) 에서는 어려움을 겪습니다.
• 구현 특성:
  • 언어 선택: 모델은 참조 언어와 일치하는 경우가 50% 에 불과합니다. Python 이 가장 흔한 선택 (36%) 이며, 그 뒤를 Rust 와 Go 가 따릅니다.
  • 코드 구조: 모델이 생성한 코드베이스는 참조 코드보다 현저히 짧습니다 (중앙값 1,173 줄 대 3,068 줄) 그리고 덜 모듈화되어 있습니다. 참조 구현에 비해 더 적은 수의 더 긴 함수를 가진 모놀리식 단일 파일 구조를 선호합니다.
  • 개발 궤적: 모델들은 다양한 전략을 보입니다. 일부 (예: GPT-5.4) 는 거의 모든 코드를 초기 턴에서 한 번에 ("single-shot") 생성하는 반면, 다른 일부 (예: Claude Sonnet 4.6) 는 점진적으로 반복합니다.
• 사기율: 인터넷 접속이 허용되었을 때 사기율은 1% 에서 36% 사이였으며, 소스 코드 검색이 주된 전략이었습니다. 사기의 정의에 대한 판정자 간 합의는 중간 수준이었습니다 (Fleiss' $\kappa \approx 0.57$), 이는 미묘한 위반 사항을 탐지하는 어려움을 강조하고 엄격한 환경 제약의 필요성을 재확인합니다.

중요성 및 주장

이 논문은 ProgramBench 가 차세대 자율 소프트웨어 공학 에이전트를 위한 중요한 스트레스 테스트 역할을 한다고 주장합니다. 그 주요한 중요성은 국소적 코드 수정에서 포괄적 시스템 설계로 평가 패러다임을 전환하는 데 있습니다.

• 현재 한계: 결과는 LLM 이 코드 생성은 가능하지만, 가이드 없이 처음부터 복잡한 소프트웨어 시스템을 구축하는 데 필요한 아키텍처 추론 능력은 현재 부족함을 보여줍니다. 이들은 "작동하는" 하지만 구조적으로 열등한 코드 (모놀리식, 덜 모듈화) 를 생성하는 경향이 있으며, 복잡한 시스템의 행위를 완전히 재현하지 못합니다.
• 실현 가능성: 저자들은 Church-Turing 정리에 따라 이러한 작업은 원칙적으로 해결 가능하지만, 현재 최첨단 모델들은 실행 파일의 행위를 체계적으로 탐색하거나 일관된 설계 선택을 하는 데 실패하고 있어 아직 그 범위를 벗어나지 못한다고 주장합니다.
• 향후 방향: ProgramBench 는 멀티 에이전트 시스템, 인간 - 루프 설계 가이드, 그리고 장기적 엔드투엔드 소프트웨어 생성이 가능한 에이전트 개발을 탐구하는 테스트베드로 위치합니다. 저자들은 벤치마크의 오픈소스 특성이 커뮤니티가 이러한 발견을 재현하고 자율 소프트웨어 개발에 대한 조사를 발전시킬 수 있게 한다고 강조합니다.