SWE-CI: Evaluating Agent Capabilities in Maintaining Codebases via Continuous Integration

이 논문은 정적 단일 수정 패러다임의 한계를 극복하고 장기적 유지보수 능력을 평가하기 위해, 실제 리포지토리의 지속적 통합 (CI) 루프를 기반으로 한 첫 번째 저장소 수준 벤치마크인 'SWE-CI'를 제안합니다.

핵심

1. 기존 방식: "한 번에 완벽하게 짓는 건축가" (SWE-bench 등)

지금까지 AI 코딩 능력을 평가할 때는 주로 **"주어진 설계도대로 집을 한 번에 완벽하게 지을 수 있는가?"**를 봤습니다.

• 상황: 건축주 (테스트) 가 "벽을 3 개 만들고 문은 2 개 달아줘"라고 하면, AI 는 그걸 딱 맞춰서 집을 짓습니다.
• 문제점: AI 가 집을 지을 때, 나중에 고치기 힘든 나쁜 재료를 쓰거나 구조를 엉망으로 지어도, 당장 문을 열고 들어가는 순간만 잘되면 합격으로 쳤습니다.
• 현실: 실제 세상에서는 건물을 지은 후에도 10 년, 20 년을 유지해야 합니다. 그때마다 "창문 하나 더 달아줘", "2 층을 확장해줘" 같은 요청이 들어오는데, 처음에 엉망으로 지은 집은 조금만 건드려도 무너집니다.

2. 새로운 방식 (SWE-CI): "오래가는 집을 짓고 관리하는 건축팀"

이 논문은 SWE-CI라는 새로운 평가 기준을 제안합니다. 이는 **"집을 짓고 나서, 1 년, 2 년, 10 년이 지나도 계속 수리하고 확장할 수 있는가?"**를 봅니다.

• 비유: AI 는 이제 단순히 집을 한 번 짓는 게 아니라, **수십 년 동안 이어지는 '리모델링 프로젝트'**에 참여합니다.
• 과정:
  1. 기초 공사 (Base): 기존에 지어진 집을 봅니다.
  2. 요청 (Requirement): "이제 2 층을 추가해야 해"라고 요청이 옵니다.
  3. 시공 (Code): AI 가 2 층을 추가합니다.
  4. 검사 (Test): 2 층이 잘 붙었는지, 그리고 기존 1 층이 무너지지 않았는지 확인합니다.
  5. 반복: 이 과정을 수십 번 반복합니다. (실제 데이터는 평균 71 번의 수정과 233 일의 시간이 걸리는 프로젝트입니다.)

3. 핵심 메커니즘: "건축가 (Architect)"와 "현장 기술자 (Programmer)"

이 평가는 AI 를 두 명의 역할로 나누어 협업하게 합니다.

• 건축가 (Architect): "무엇을 고쳐야 할지"를 분석합니다. "이게 고장 났네, 왜 고장 났지? 어떻게 고칠지 큰 그림을 그려줘."라고 요구사항을 정리합니다.
• 현장 기술자 (Programmer): 건축가의 지시를 듣고 실제로 코드를 수정합니다.
• 핵심: 이 두 명이 **Continuous Integration (지속적 통합)**이라는 과정을 통해, 마치 실제 소프트웨어 회사처럼 끊임없이 수정하고 테스트하는 사이클을 돌립니다.

4. 점수 매기는 법: "EvoScore (진화 점수)"

단순히 "집이 무너지지 않았나?"만 보는 게 아닙니다.

• 초반 점수: 처음에 집을 잘 고쳤다면 점수를 줍니다.
• 후반 점수: 하지만 나중에 더 많은 수정이 들어왔을 때, 처음에 잘 지어둔 구조 덕분에 쉽게 고쳐졌다면 더 높은 점수를 줍니다.
• 반대 경우: 처음에 급하게 고쳐서 당장은 잘 됐는데, 나중에 고치려고 할 때마다 벽이 무너지거나 (Regression, 회귀) 고치기 힘들다면 점수가 깎입니다.
• 결론: 오래갈 수 있는 튼튼한 구조를 만든 AI 가 진짜 승자입니다.

5. 실험 결과: "아직 갈 길이 멀다"

저자들은 최신 AI 모델 18 개를 이 테스트에 시켰습니다.

• 좋아진 점: AI 가 코드를 짜는 능력은 정말 빨라졌습니다.
• 아쉬운 점: 하지만 오랜 기간 유지보수를 하면서 실수 (Regression) 를 줄이는 능력은 여전히 부족했습니다.
  • 대부분의 AI 는 10 번의 수정 중 7~8 번은 실수를 하거나, 기존 기능을 망가뜨리는 '회귀'를 일으켰습니다.
  • 마치 집을 고치다가 벽을 뚫고 전선을 끊어버리는 상황과 비슷합니다.

요약

이 논문은 **"AI 가 코드를 짤 때, '한 번에 잘 만드는 것'보다 '오래 잘 유지되는 것'이 더 중요하다"**고 말합니다.

지금까지 우리는 AI 가 **"단거리 경주 (한 번의 작업)"**를 얼마나 잘 뛰는지 봤다면, 이제부터는 **"마라톤 (오랜 기간의 유지보수)"**을 얼마나 잘 뛰는지 봐야 한다는 것입니다. 아직 AI 는 마라톤을 뛰다가 자주 넘어지지만, 이 새로운 평가 기준 (SWE-CI) 을 통해 AI 가 진짜로 인간 개발자를 대체할 수 있는 '유능한 엔지니어'로 성장할 수 있을지 지켜볼 수 있게 되었습니다.

기술 요약

1. 문제 제기 (Problem)

대형 언어 모델 (LLM) 기반 에이전트는 정적 버그 수정 (Static Bug Fixing) 과 같은 소프트웨어 엔지니어링 작업에서 뛰어난 능력을 보여주었습니다 (예: SWE-bench 벤치마크). 그러나 실제 소프트웨어 개발은 단순한 일회성 수정이 아니라, 복잡한 요구사항 변경과 장기적인 기능 반복 (Iteration) 을 통해 이루어집니다.

기존 벤치마크의 한계는 다음과 같습니다:

• 스냅샷 기반 평가 (Snapshot-style): 에이전트가 주어진 단일 요구사항에 대해 일회성 솔루션을 생성하는 방식에 집중합니다.
• 유지보수성 측정 부재: brittle(취약한) 수정을 가한 코드와 확장 가능한 깨끗한 코드가 모두 초기 테스트를 통과할 수 있어, 장기적인 코드 유지보수성 (Maintainability) 의 차이를 포착하지 못합니다.
• 실제 개발 환경과의 괴리: 실제 개발에서는 과거의 설계 결정이 누적되어 후속 변경의 난이도에 영향을 미치지만, 기존 평가는 이러한 '진화 (Evolution)' 과정을 고려하지 않습니다.

따라서, 단순한 기능 정확도가 아닌 장기적인 코드 유지보수 능력을 평가할 수 있는 새로운 벤치마크가 시급합니다.

2. 방법론 (Methodology)

2.1 SWE-CI 벤치마크 구축

저자는 SWE-CI (SoftWare Engineering – Continuous Integration) 라는 새로운 리포지토리 수준 (Repository-level) 벤치마크를 제안했습니다.

• 데이터 구성: GitHub 의 Python 리포지토리에서 100 개의 태스크를 선별했습니다.
  • 각 태스크는 실제 리포지토리의 Base Commit(기저) 과 Target Commit(목표) 으로 구성됩니다.
  • 평균 233 일의 시간跨度와 71 개의 연속된 커밋에 걸친 실제 진화 이력을 포함합니다.
  • 최소 500 줄 이상의 소스 코드 변경이 포함된 진화 과정을 다룹니다.
• 데이터 선별 과정: 3 년 이상 유지보수된 리포지토리, 500 스타 이상, 의존성 파일 및 유닛 테스트 존재, 허용 가능한 라이선스 등의 필터링을 거쳐 최종 100 개 샘플을 선정했습니다.

2.2 평가 프로토콜: Architect-Programmer 듀얼 에이전트

기존의 일회성 수정이 아닌, CI(지속적 통합) 루프를 모방한 반복적 평가 방식을 도입했습니다.

1. Architect Agent (아키텍트): 현재 코드와 목표 (Oracle) 코드 간의 테스트 격차를 분석하여 자연어 기반의 고수준 요구사항 문서를 생성합니다. (요약, 위치 파악, 설계 단계 수행)
2. Programmer Agent (프로그래머): 아키텍트가 생성한 요구사항을 바탕으로 소스 코드를 수정합니다. (이해, 계획, 코딩 단계 수행)
3. CI 루프: 위 과정이 테스트를 통과할 때까지 반복됩니다. 에이전트는 수십 번의 분석 및 코딩 반복을 통해 장기적인 진화를 수행해야 합니다.

2.3 평가 지표: EvoScore (Evolution Score)

단순한 통과/실패가 아닌, 코드 유지보수성을 정량화하기 위해 새로운 지표를 제안했습니다.

• Normalized Change (정규화된 변화): 현재 코드가 베이스 코드 대비 얼마나 개선되었는지, 혹은 회귀 (Regression) 가 발생했는지를 $[-1, 1]$ 범위로 정규화합니다.
• EvoScore 계산: $N$번의 반복에서 얻은 코드베이스 시퀀스에 대해 미래 가중 평균 (Future-weighted mean) 을 적용합니다.
  • 공식: $e = \frac{\sum \gamma_i a(c_i)}{\sum \gamma_i}$
  • $\gamma$ (감마) 파라미터: $\gamma > 1$로 설정하여 후반부 반복 (장기적 안정성) 에 더 높은 가중치를 둡니다. 즉, 초기 테스트는 통과하더라도 이후 수정을 어렵게 만드는 기술 부채 (Technical Debt) 를 쌓는 에이전트는 낮은 점수를 받습니다.

3. 주요 기여 (Key Contributions)

1. 최초의 CI 기반 벤치마크: 정적/단기적 기능 정확도 평가에서 벗어나, 동적이고 장기적인 코드 유지보수성을 평가하는 첫 번째 벤치마크 (SWE-CI) 를 제안했습니다.
2. 새로운 평가 패러다임: "스냅샷" 방식에서 "진화 기반 (Evolution-based)" 방식으로의 전환을 주도하며, 에이전트의 장기적 의사결정 품질을 관찰할 수 있는 프레임워크를 제시했습니다.
3. EvoScore 지표: 단기적 성과와 장기적 유지보수성 사이의 균형을 측정할 수 있는 새로운 메트릭을 도입했습니다.
4. 실증 데이터: 100 개의 실제 진화 이력을 가진 고품질 데이터셋과 100 억 토큰 이상의 실험 데이터를 공개했습니다.

4. 실험 결과 (Results)

18 개 제공업체의 18 개 모델을 대상으로 한 실험 결과는 다음과 같습니다:

• 지속적인 발전: LLM 의 코드 유지보수 능력은 가속화되고 있으며, 2026 년 이후 출시된 모델들이 기존 모델보다 월등히 높은 점수를 기록했습니다. (Claude Opus 시리즈가 가장 우수함)
• 공급업체별 차이: 모델마다 코드 유지보수에 대한 우선순위가 다릅니다.
  • 장기적 관점 선호: MiniMax, DeepSeek, GPT (장기적 개선에 가중치).
  • 단기적 관점 선호: Kimi, GLM (즉각적인 수정에 집중).
  • 안정적: Qwen, Doubao, Claude.
• 회귀 (Regression) 문제: 장기적인 유지보수 과정에서 회귀 (기존 테스트가 실패하는 현상) 를 방지하는 능력은 여전히 부족합니다.
  • 대부분의 모델이 Zero-Regression Rate(회귀 없음 비율) 에서 0.25 미만을 기록했습니다.
  • 이는 LLM 이 단기 수정에는 능숙하지만, 완전 자동화된 장기 다중 라운드 개발 환경에서는 안정적인 코드 품질을 유지하는 데 어려움을 겪고 있음을 시사합니다.

5. 의의 (Significance)

• 소프트웨어 공학의 새로운 기준: 기존 벤치마크가 놓치고 있던 '유지보수성'이라는 핵심 요소를 평가 체계에 포함시킴으로써, 실제 산업 현장에 더 부합하는 AI 에이전트 평가 기준을 마련했습니다.
• 기술 부채 감지: 단기적인 테스트 통과만으로는 보이지 않는 '나쁜 설계'가 장기적으로 어떻게 기술 부채로 이어지는지를 드러내어, 모델의 설계 능력을 진단하는 데 유용합니다.
• 향후 연구 방향: LLM 에이전트가 단순한 코드 생성을 넘어, 실제 소프트웨어 생명주기 (SDLC) 전반을 책임질 수 있도록 훈련 및 평가 방향을 전환하는 계기를 마련했습니다.

이 논문은 AI 에이전트가 "코드를 작성하는 것"을 넘어 "코드를 유지하고 진화시키는 것"에 얼마나 적합한지를 평가하는 중요한 이정표가 될 것입니다.