ComBench: A Repo-level Real-world Benchmark for Compilation Error Repair

1. 문제 정의 (Problem)

소프트웨어 개발 과정에서 컴파일 오류는 생산성을 저해하는 주요 장애물입니다. 기존에 제안된 자동화된 컴파일 오류 수정 (ACER, Automated Compilation Error Repair) 기술들의 성능을 평가하는 데에는 다음과 같은 한계가 있었습니다.

• 문맥의 부재 (Decontextualized Data): 기존 벤치마크 (DeepFix, TRACER 등) 는 단일 파일의 짧은 코드 조각 (평균 20 줄 이하) 만을 제공하여, 실제 프로젝트의 파일 간 의존성, 모듈 간 링크, 빌드 시스템 설정 등 레포지토리 수준의 복잡성을 반영하지 못합니다.
• 데이터의 비현실성 (Lack of Authenticity): 기존 데이터는 주로 초보 학생들의 과제에서 추출되어 오류 유형이 단순하고 다양성이 부족합니다. 실제 대규모 오픈소스 프로젝트에서 발생하는 복잡한 오류를 대표하지 못합니다.
• 편향된 태스크 모델링: 기존 연구는 오류 수정을 단순한 '시퀀스 - 투 - 시퀀스' (로컬) 문제로 가정하여, 대규모 레포지토리 내에서의 전역적 오류 위치 파악 (Global Fault Localization) 과 문맥 수집의 중요성을 간과했습니다.
• 재현성 부족: 실제 CI(지속적 통합) 환경의 빌드 실패를 로컬에서 재현하기 어렵고, 개발자가 수정한 정답 패치 (Ground-truth) 를 정확히 식별하기 어렵습니다.

2. 방법론 (Methodology)

저자들은 이러한 한계를 극복하기 위해 ComBench를 구축했습니다. 이는 GitHub CI 히스토리에서 대규모 오픈소스 프로젝트의 실제 컴파일 오류를 채굴하여 만든 레포지토리 수준의 재현 가능한 벤치마크입니다.

A. 벤치마크 구축 프레임워크

ComBench 는 3 단계 프로세스로 구성됩니다 (그림 1 참조):

1. 오류 수집 (Error Collection):

   • GitHub Actions 의 CI 로그에서 빌드 실패를 식별합니다.
   • 이중 필터링 (Dual-filtering) 알고리즘을 사용하여 로그의 노이즈 (테스트 결과, 경고 등) 를 제거하고 실제 컴파일 오류 행을 식별합니다.
   • 양방향 문맥 수집기를 통해 오류 메시지 앞뒤의 #include 스택 및 주석 등을 포함하여 구조화된 오류 정보를 추출합니다.

2. 수정 패치 식별 (Repair Patch Identification):

   • 다중 소스 검색 알고리즘을 사용하여 오류 발생 커밋 ($c_f$) 이후의 수정 커밋 ($c_r$) 을 탐색합니다 (동일 브랜치, 의존 브랜치, 메인 브랜치 등).
   • 의존성 기반 최소화 (Dependency-based Minimization): 수정 커밋이 포함된 파일 중 오류 발생 파일과 직접적인 의존 관계 (include 등) 가 있는 파일만 추출하여 최소 수정 패치 ($\Delta_r$) 를 생성합니다. 이는 불필요한 기능 추가나 리팩토링 코드를 제거하여 정답의 순도를 높입니다.

3. 자동화된 재현 환경 구축 (Automated Reproduction Environment):

   • Docker 기반 에뮬레이션: 비공개 CI 러너 이미지를 대체할 수 있는 범용 Docker 이미지를 매핑하고, 프로젝트별 빌드 전 명령어 (PRE_BUILD_COMMAND) 를 적용하여 환경을 복제합니다.
   • 작업 구성 추론: CI 로그의 인간 가독성 있는 작업 이름 (예: build (gcc, 13, mold)) 을 분석하여 YAML 의 매트릭스 파라미터를 추론하고, act 도구를 통해 실제 CI 환경을 재현합니다.
   • 종단 간 검증 (Fail-Fix-Pass): 추출된 오류가 재현되고, 개발자 패치를 적용했을 때 빌드가 성공하는지 자동으로 검증합니다.

B. 데이터 구성

• 소스: OpenSSL, Bitcoin, RocksDB, LLVM 등 4 개의 대규모 C/C++ 오픈소스 프로젝트.
• 규모: 총 200 개의 검증된 컴파일 오류 인스턴스.
• 범주: 선언 (Declaration), 타입 (Type), 멤버 (Member), 문법 (Syntax), 함수 (Function), 템플릿 (Template), 시맨틱 (Semantic) 등 7 가지 주요 오류 유형.
• 특징: 각 오류는 전체 프로젝트 문맥, 상세한 컴파일러 진단 정보, 개발자 정답 패치를 포함합니다.

3. 주요 기여 (Key Contributions)

1. ComBench 벤치마크 도입: 기존 단일 파일 벤치마크의 한계를 극복한, 최초의 레포지토리 수준 (Repository-level) 의 재현 가능한 실세계 컴파일 오류 수정 벤치마크를 제시했습니다.
2. 강건한 구축 프레임워크 개발: 노이즈가 많은 CI 로그에서 오류를 정밀하게 추출하고, 복잡한 Git 히스토리에서 인과 관계가 명확한 최소 수정 패치를 식별하며, 역사적 빌드 환경을 정확하게 재현하는 기술을 개발했습니다.
3. 포괄적인 LLM 평가: 12 개의 최신 대형 언어 모델 (LLM) 을 대상으로 직접 수정 (Direct Repair) 과 에이전트 기반 수정 (Agent-based Repair) 두 가지 설정에서 평가했습니다.

4. 실험 결과 (Results)

12 개의 LLM (GPT-5, Claude, Gemini, Qwen, DeepSeek 등) 을 ComBench 에서 평가한 주요 결과는 다음과 같습니다.

• 구문적 정확성 vs 시맨틱 정확성 간극 (The "Compile-but-Incorrect" Gap):
  • 최상위 모델 (GPT-5) 은 **73%**의 높은 컴파일 성공률 (Compile Success, CS) 을 보였으나, 시맨틱 정확성 (Semantic Correctness, SC) 은 **41%**에 불과했습니다.
  • 모델은 컴파일러 오류를 해결하여 빌드를 통과하게 할 수는 있지만, 개발자의 의도나 프로젝트 아키텍처 (예: 커스텀 헤더 사용, 프로토콜 준수) 를 위반하는 "얕은 수정 (Shallow Fixes)"을 자주 생성했습니다.
• 모델 크기와 성능:
  • 모델 크기가 커질수록 성능이 향상되는 경향이 있으나, 중간 크기 모델들 사이에서는 성능이 정체되는 현상이 관찰되었습니다.
  • 에이전트 기반 접근 (OpenHands 프레임워크): 반복적인 탐색과 문맥 수집을 통해 강력한 모델 (Claude-Sonnet-4 등) 은 성능이 향상되었으나, 작은 모델은 에이전트 오버헤드로 인해 성능이 저하되기도 했습니다.
• 오류 유형별 민감도:
  • 모델마다 특정 오류 유형에 강점이 다릅니다 (예: Gemini-2.5-Pro 는 타입 오류에 강함, Claude-Sonnet-4 는 멤버 오류에 강함).
• 해결되지 않는 난제:
  • 최상위 모델조차 해결하지 못한 34 개의 "하드 케이스"가 존재했습니다. 이는 주로 API 표면의 진화, 접근 제어 제약, 템플릿 인스턴스화 복잡성, 연쇄적 오류 등 교차 파일 (Cross-file) 및 전역적 일관성이 필요한 문제들이었습니다.

5. 의의 및 결론 (Significance)

• 학문과 산업의 간극 해소: ComBench 는 실제 산업 환경의 복잡성을 반영하여, ACER 연구가 단순한 문법 수정을 넘어 전역적 문맥 이해와 프로젝트 규칙 준수 능력을 갖추도록 유도합니다.
• 향후 연구 방향 제시: 현재 LLM 기반 ACER 기술이 시맨틱 정확성과 프로젝트 아키텍처 이해에서 여전히 부족함을 보여주었으며, 에이전트 기반 접근법의 잠재력과 한계를 명확히 했습니다.
• 지속 가능한 플랫폼: 재현 가능한 Docker 환경과 자동화된 데이터 수집 파이프라인을 제공하여, 새로운 오류와 개발 관행이 추가될 수 있는 진화하는 벤치마크로 기능합니다.

이 논문은 컴파일 오류 수정 기술의 발전에 있어 실제성 (Authenticity), 전역 문맥 (Global Context), 재현성 (Reproducibility) 이 얼마나 중요한지를 입증하고, 이를 위한 새로운 표준을 제시했다는 점에서 의의가 큽니다.