SwingArena: Competitive Programming Arena for Long-context GitHub Issue Solving

이 논문은 LLM 이 실제 소프트웨어 개발 워크플로우를 모방하여 패치를 생성하고 CI 파이프라인을 통해 검증하는 경쟁적 평가 프레임워크 'SwingArena'를 제안하며, 이를 통해 긴 맥락의 GitHub 이슈 해결 능력을 다양한 프로그래밍 언어로 평가할 수 있음을 보여줍니다.

핵심

SWINGARENA: AI 코딩 대회와 심사위원의 치열한 대결

이 논문은 "SWINGARENA" 라는 새로운 시스템을 소개합니다. 쉽게 말해, 이 시스템은 인공지능 (AI) 이 실제로 소프트웨어를 개발하는 현장처럼, 코드를 짜는 '개발자' 역할과 그 코드를 검증하는 '심사위원' 역할을 서로 경쟁하게 만들어 AI 의 실력을 시험하는 곳입니다.

기존의 AI 평가 방식이 너무 단순했다면, SWINGARENA 는 현실 세계의 복잡한 상황을 그대로 재현합니다.

---

1. 왜 새로운 평가가 필요할까요? (기존 방식의 문제점)

지금까지 AI 코딩 능력을 평가할 때는 주로 "이 짧은 코드가 잘 작동하나요?" 라는 질문만 던졌습니다. 마치 요리 대회에서 "이 소금 한 스푼이 잘 녹았나요?"만 확인하는 것과 비슷합니다.

하지만 현실의 소프트웨어 개발은 훨씬 복잡합니다.

• 긴 문서와 수많은 파일: 프로젝트는 수천 줄의 코드와 수많은 파일로 이루어져 있어, 중요한 정보가 어디에 숨어있는지 찾기 어렵습니다.
• 반복적인 수정: 한 번에 완벽하게 만드는 게 아니라, 버그를 찾고 고치고, 다시 테스트하는 과정이 반복됩니다.
• 심사위원의 눈: 내 코드가 내 생각대로만 작동하는 게 아니라, 다른 사람이 만든 엄격한 테스트를 통과해야 합니다.

기존 평가는 이런 '현실적인 긴장감'과 '협업 과정'을 놓치고 있었습니다.

2. SWINGARENA 는 어떻게 작동할까요? (창의적인 비유)

SWINGARENA 는 마치 **치열한 '코딩 배틀 (Arena)'**을 연상시킵니다.

🥊 역할 1: 제출자 (Submitter) - "공격수"

• 역할: AI 가 개발자가 되어, GitHub(코드 저장소) 에 있는 버그를 고치는 '패치 (수정 코드)'를 만듭니다.
• 미션: "이 버그를 고쳐서 모든 테스트를 통과하게 해!"

🛡️ 역할 2: 심사위원 (Reviewer) - "수비수"

• 역할: 또 다른 AI 가 심사위원이 되어, 제출자가 만든 코드를 꼼꼼히 뜯어봅니다.
• 미션: "이 코드가 정말 완벽할까? 내가 새로운 '함정 테스트'를 만들어서 코드가 깨지는지 확인해 볼까?"
• 전략: 심사위원은 단순히 통과만 확인하는 게 아니라, 코드가 약한 부분을 찾아내서 실패하게 만드는 새로운 테스트 케이스를 만들어냅니다.

🔄 승부 과정: "공과 방의 끝없는 레이스"

1. 제출자가 코드를 고칩니다.
2. 심사위원이 새로운 테스트를 만들어 코드를 공격합니다.
3. **CI(자동화 시스템)**가 두 코드를 실제 환경에서 실행해 봅니다.
   • 코드가 모든 테스트를 통과하면 제출자 승점 +1.
   • 테스트가 코드를 깨뜨리면 심사위원 승점 +1.
4. 이 과정이 여러 번 반복되면서, AI 는 점점 더 튼튼한 코드를 짜고, 심사위원은 더 교묘한 테스트를 만들게 됩니다.

3. 긴 코드를 어떻게 처리할까요? (RACG 기술)

현실의 프로젝트는 코드가 너무 길어서 AI 가 한 번에 다 읽을 수 없습니다. (마치 두꺼운 백과사전 전체를 한 번에 외우라고 하는 것과 같습니다.)

그래서 SWINGARENA 는 RACG(검색 강화 코드 생성) 기술을 사용합니다.

• 비유: 도서관에서 책 전체를 읽는 게 아니라, 질문과 관련된 책장 몇 개만 찾아서 그중 필요한 페이지만 AI 에게 보여주는 시스템입니다.
• 이 기술 덕분에 AI 는 C++, Python, Rust, Go 등 다양한 언어의 거대한 프로젝트에서도 필요한 정보만 정확히 찾아내어 코드를 수정할 수 있습니다.

4. 실험 결과: 어떤 AI 가 이겼을까요?

연구진은 GPT-4o, Claude, Gemini, DeepSeek 등 최신 AI 들을 이 배틀에 참여시켰습니다. 결과는 흥미로웠습니다.

• 공격적인 AI (GPT-4o): 코드를 빠르게 고치고 공격적으로 패치를 만들지만, 가끔은 테스트를 통과하지 못하는 실수를 하기도 했습니다. (공격은 좋지만 방어는 약함)
• 안정적인 AI (DeepSeek, Gemini): 코드를 고칠 때 실수를 줄이고, 테스트를 통과하는 '안전한' 코드를 만드는 데 강점이 있었습니다. (방어는 좋지만 공격은 다소 느림)
• 심사위원의 중요성: 어떤 AI 가 심사위원이냐에 따라 결과가 달라졌습니다. 어떤 AI 는 너무 엄격해서 코드를 쉽게 떨어뜨렸고, 어떤 AI 는 너그러웠습니다. 이는 AI 의 성향에 따라 평가 결과가 달라질 수 있음을 보여줍니다.

5. 결론: 왜 이것이 중요한가요?

SWINGARENA 는 AI 가 단순히 "코드를 짜는 것"을 넘어, **"현실 세계의 복잡한 소프트웨어 개발 환경에서 버그를 찾고, 테스트를 통과하며, 협업하는 능력"**을 평가할 수 있게 해줍니다.

이 시스템은 AI 개발자들에게 다음과 같은 교훈을 줍니다:

"단순히 코드가 작동하는지 확인하는 것만으로는 부족합니다. AI 는 긴 문맥을 이해하고, 다른 AI(심사위원) 의 공격을 견디며, 실제 프로젝트의 규칙까지 지키는 튼튼한 엔지니어가 되어야 합니다."

이 연구는 앞으로 더 똑똑하고 현실적인 AI 소프트웨어 엔지니어를 만드는 데 중요한 기준이 될 것입니다.

기술 요약

SWINGARENA: 긴 컨텍스트 GitHub 이슈 해결을 위한 적대적 프로그래밍 아레나 (SWINGARENA) 기술 요약

이 논문은 대규모 언어 모델 (LLM) 의 소프트웨어 개발 능력을 평가하기 위해 SWINGARENA라는 새로운 적대적 평가 프레임워크를 제안합니다. 기존의 정적 벤치마크의 한계를 넘어, 실제 소프트웨어 개발 워크플로우 (Continuous Integration, CI) 를 시뮬레이션하여 LLM 의 패치 생성 및 검증 능력을 종합적으로 평가합니다.

1. 문제 제기 (Problem)

기존의 코드 생성 벤치마크 (HumanEval, MBPP 등) 나 최근의 GitHub 이슈 기반 벤치마크 (SWE-Bench 등) 는 다음과 같은 한계를 가집니다:

• 정적 및 단회성 평가: 실제 개발 환경에서 발생하는 반복적인 디버깅, 테스트, 점진적 개선 (Iterative refinement) 과정을 반영하지 못함.
• 단일 에이전트 평가: 제출자 (Submitter) 와 리뷰어 (Reviewer) 가 상호작용하는 협업 프로세스를 무시하고, 단일 에이전트의 성능만 평가함.
• CI 파이프라인 부재: 실제 산업 현장에서는 코드 변경이 빌드, 린팅 (Linting), 보안 검사, 단위 테스트를 포함한 전체 CI 파이프라인을 통과해야 하지만, 기존 벤치마크는 단순한 단위 테스트 통과 여부만 확인함.
• 긴 컨텍스트 처리 부족: 대규모 코드베이스에서 관련 정보를 찾아내는 능력 (Long-context reasoning) 을 평가하기 위한 체계적인 방법이 부족함.

2. 방법론 (Methodology)

2.1 SWINGARENA 프레임워크

SWINGARENA 는 **제출자 (Submitter)**와 리뷰어 (Reviewer) 두 개의 LLM 에이전트가 상호작용하는 적대적 아레나를 구축합니다.

• 제출자 (Submitter): GitHub 이슈를 해결하기 위한 코드 패치 (Patch) 를 생성합니다.
• 리뷰어 (Reviewer): 제출된 패치의 결함을 찾기 위해 새로운 테스트 케이스를 생성하고, 패치가 CI 파이프라인을 통과하는지 검증합니다.
• 적대적 프로세스 (Battle Protocol):
  1. 제출자가 패치를 생성합니다.
  2. 리뷰어가 패치를 공격하기 위한 테스트 케이스를 생성합니다.
  3. 실제 CI 파이프라인 (GitHub Actions 등) 을 통해 패치와 테스트를 실행합니다.
  4. 패치가 모든 테스트 (리뷰어가 생성한 테스트 포함) 를 통과하면 제출자가 점수를 얻고, 테스트가 패치의 결함을 드러내면 리뷰어가 점수를 얻습니다.
  5. 에이전트들은 여러 라운드에 걸쳐 역할을 교체하며 상호작용합니다.

2.2 데이터 구축 (Data Construction)

• 소스: GitHub 의 2,300 개 이상의 실제 이슈와 PR(풀 리퀘스트) 쌍을 수집했습니다.
• 필터링:
  1. CI 테스트 필터링: 실제 CI 파이프라인을 통과한 데이터만 선별하여 품질을 보장합니다.
  2. LLM 필터링: LLM 을 심사자 (Judge) 로 사용하여 문제의 명확성과 난이도를 1 차 평가합니다.
  3. 전문가 필터링: 인간 전문가가 LLM 의 평가를 최종 검증하고 보정합니다.
• 언어: C++, Python, Rust, Go 등 4 가지 주요 프로그래밍 언어를 지원합니다.

2.3 검색 증강 코드 생성 (RACG, Retrieval-Augmented Code Generation)

긴 컨텍스트 (Large Context) 문제를 해결하기 위해 RACG 모듈을 도입했습니다.

• 파일 검색 (File Retriever): BM25 기반의 희소 검색을 사용하여 문제 설명과 유사한 소스 파일을 먼저 선별합니다.
• 코드 청킹 (CodeChunker): 선택된 파일을 함수, 클래스, 블록 등 의미 있는 단위로 파싱하여 분할합니다.
• 재순위화 (CodeReranker): CodeBERT 를 활용하여 문제와 코드 청크 간의 밀도 벡터 유사도를 계산하여 가장 관련성 높은 청크를 선정합니다.
• 토큰 예산 관리: 모델의 컨텍스트 윈도우 제한 내에서 관련 코드를 효율적으로 포장 (Packing) 합니다.

3. 주요 기여 (Key Contributions)

1. 표준화된 적대적 CI 평가 프로토콜: 제출자와 리뷰어의 역할 전환을 통한 동적 평가 환경 제공.
2. 다언어 긴 컨텍스트 검색 파이프라인 (RACG): C++, Python, Rust, Go 를 지원하는 재현 가능한 베이스라인 시스템.
3. 고품질 데이터셋: 2,300 개의 GitHub 이슈 쌍과 400 개의 평가 인스턴스 (언어별 100 개) 를 공개하며, CI 기반 검증 스크립트도 포함합니다.
4. 실제 워크플로우 시뮬레이션: 단순한 코드 생성이 아닌, CI 파이프라인 통과, 스타일 검사, 보안 검사 등 실제 개발 환경의 제약을 반영한 평가.

4. 실험 결과 (Results)

GPT-4o, Claude-3.5, Gemini-2.0, DeepSeek-V3 등 다양한 최신 LLM 을 평가한 결과:

• 행동 양상의 차이:
  • GPT-4o: 공격적인 패치 생성에 강점이 있어 높은 승률 (Win Rate) 을 보였으나, 전체적인 정확도 (CI 통과율) 는 다소 낮았습니다.
  • DeepSeek & Gemini: 패치 생성보다는 정확성과 CI 안정성을 우선시하여 높은 CI 통과율 (SPR/RPR) 을 기록했습니다.
• 언어별 성능: 모든 모델이 C++ 에서 상대적으로 좋은 성능을 보였으며, Rust 와 Python 에서는 성능이 다소 낮았습니다. DeepSeek 은 언어 간 편차가 가장 적어 균형 잡힌 성능을 보였습니다.
• RACG 의 효과: RACG 를 적용했을 때, BM25 만을 사용하는 경우보다 Best@3 점수와 승률이 유의미하게 향상되었습니다 (예: C++ 에서 승률 0.77 → 0.84).
• 실패 패턴 분석: 주요 실패 원인은 (1) 다중 파일 간의 일관성 부족 (31%), (2) 비결정적 테스트 행동 (19%), (3) 비기능적 요구사항 위반 (24%), (4) 검색된 컨텍스트의 부재 (26%) 로 나타났습니다.

5. 의의 및 결론 (Significance)

SWINGARENA 는 LLM 평가의 패러다임을 **'단일 정적 테스트 통과'**에서 **'실제 CI 기반의 적대적 협업'**으로 전환시켰습니다.

• 실용성: 산업 현장의 소프트웨어 개발 프로세스 (릴레이션, 리뷰, CI/CD) 를 직접 반영하여 모델의 실제 활용 가능성을 더 정확하게 예측합니다.
• 심층적 통찰: 모델이 패치를 생성하는 능력과 테스트를 통해 결함을 찾는 능력 사이의 트레이드오프를 파악할 수 있게 하여, 모델 개발 방향성을 제시합니다.
• 확장성: 다양한 프로그래밍 언어와 대규모 코드베이스를 지원하며, 향후 더 정교한 검색 전략이나 에이전트 협업 방식 연구의 기반이 될 것입니다.

이 연구는 LLM 이 단순한 코드 생성기를 넘어, 실제 소프트웨어 엔지니어링 워크플로우에서 신뢰할 수 있는 파트너가 되기 위해 필요한 평가 기준을 제시했다는 점에서 중요한 의의를 가집니다.