SWE-CI: AI 코딩 에이전트의 진짜 실력을 묻다 — 단발성 버그 수정이 아닌 8개월간의 코드 유지보수 능력 평가
논문 정보: SWE-CI: Evaluating Agent Capabilities in Maintaining Codebases via Continuous Integration
저자: Jialong Chen (중산대학교), Xander Xu, Hu Wei, Bing Zhao (알리바바 그룹)
발표일: 2026년 3월 4일 (arXiv:2603.03823v1)
데이터셋: https://huggingface.co/datasets/skylenage/SWE-CI
코드: https://github.com/SKYLENAGE-AI/SWE-CI
1. 왜 이 논문이 중요한가: AI 코딩 평가의 근본적 맹점
지금까지 AI 코딩 에이전트의 실력을 평가하는 방식에는 보이지 않는 전제가 하나 깔려 있었다. “지금 이 순간 코드가 동작하는가”라는 질문이 그것이다. HumanEval, MBPP, 그리고 SWE-bench로 대표되는 기존 벤치마크들은 모두 동일한 구조를 공유한다. 에이전트에게 하나의 완결된 요구사항을 주고, 단 한 번의 시도로 해결책을 만들어내도록 요구한다. 이른바 스냅샷 기반 평가(snapshot-based evaluation) 방식이다.
이 방식의 근본적인 한계는 유지보수 가능성(maintainability)을 전혀 측정하지 못한다는 데 있다. 동일한 테스트를 통과하더라도, 하드코딩으로 취약하게 때운 코드와 깔끔하고 확장 가능하게 설계된 코드는 겉으로는 구별되지 않는다. 그 차이는 오직 코드베이스가 계속 진화할 때에만 드러난다. 새로운 요구사항이 들어오고, 인터페이스가 변경되고, 모듈이 확장될 때, 과거의 설계 결정들이 빚으로 돌아온다. 성급하게 테스트를 통과시키기 위해 쌓아 올린 기술 부채(technical debt)는 이후 수정을 기하급수적으로 어렵게 만들고, 결국 코드는 돌이킬 수 없는 엔트로피 증가 상태에 빠진다.
소프트웨어 공학의 고전 연구들은 이미 오래전부터 이 사실을 경고했다. 레만(Lehman)의 법칙은 유지보수가 진행될수록 소프트웨어 품질이 내재적으로 저하된다고 말한다. 프레더릭 브룩스(Frederick Brooks)의 『맨먼스 미신』은 유지보수 활동이 소프트웨어 전체 수명주기 비용의 60~80%를 차지한다고 지적했다. 그럼에도 불구하고, 기존의 AI 코딩 벤치마크들은 이 결정적인 차원을 거의 완전히 무시해 왔다. SWE-CI는 바로 이 공백을 메우기 위해 탄생했다.
2. SWE-CI란 무엇인가: 벤치마크의 설계 철학
SWE-CI(SoftWare Engineering – Continuous Integration)는 지속적 통합(Continuous Integration) 루프를 기반으로 구축된 최초의 리포지토리 수준 벤치마크다. 중산대학교와 알리바바 그룹의 연구진이 공동으로 개발한 이 벤치마크는, 코드 생성 평가의 패러다임을 정적이고 단기적인 기능적 정확성(functional correctness)에서 동적이고 장기적인 유지보수성(maintainability)으로 이동시키는 것을 목표로 한다.
벤치마크의 핵심 구조는 다음과 같다. 100개의 태스크가 있으며, 각 태스크는 실제 오픈소스 코드 리포지토리에서 두 개의 특정 커밋 — 시작 커밋(base commit)과 목표 커밋(oracle commit) — 쌍으로 정의된다. 이 두 커밋 사이의 간격은 평균 233일, 71개의 연속된 커밋에 해당하는 실제 개발 역사다. AI 에이전트의 임무는 시작 커밋 상태의 코드베이스를 목표 커밋 상태로 진화시키는 것인데, 단번에 완성하는 것이 아니라 수십 번의 분석과 코딩 이터레이션을 통해 단계적으로 도달해야 한다.
이처럼 SWE-CI는 “순간의 정확성”이 아닌 “시간에 걸친 진화 능력”을 측정한다. 이전 이터레이션의 결정이 다음 이터레이션에 축적되는 구조이기 때문에, 초반에 설계를 희생하고 테스트 통과만을 추구한 에이전트는 시간이 지날수록 스스로 뚫어낸 구덩이에 빠지게 된다.
3. 데이터 구축 과정: 4단계 엄격한 큐레이션
SWE-CI의 데이터 구축은 단순하지 않다. 연구진은 4단계의 엄밀한 필터링 과정을 거쳐 최종 벤치마크를 완성했다.
1단계: 리포지토리 수집. SWE-bench가 소수의 유명 오픈소스 프로젝트에만 의존했던 것과 달리, 연구진은 GitHub의 전체 Python 리포지토리를 대상으로 광범위한 검색을 시작했다. 여기에 엄격한 기준을 적용했다. 3년 이상 활발히 유지되고 있어야 하고, 500개 이상의 스타를 받아야 하며, pyproject.toml과 락파일 같은 의존성 관리 파일과 유닛 테스트 스위트를 보유해야 하고, MIT 또는 Apache-2.0 같은 허용적 라이선스 하에 공개되어야 했다. 이 조건을 모두 충족하는 리포지토리는 4,923개였다.
2단계: 커밋 스팬 추출. 각 리포지토리의 메인 브랜치만 남겨 선형적인 커밋 시퀀스를 만든 뒤, 연속된 커밋 사이의 의존성 변화를 비교했다. 의존성이 변하지 않는 최대 구간의 양 끝점이 자연스럽게 base/oracle 쌍이 된다. 수정된 코드 라인이 1,000줄 미만인 쌍은 진화 거리가 충분하지 않다고 판단해 제외했다. 이 과정에서 8,311개의 후보 쌍이 도출됐다.
3단계: 환경 구성. 각 후보 쌍에 대해 Dockerfile을 자동 생성하고 런타임 환경을 스냅샷으로 저장했다. 그리고 이 환경 안에서 oracle 코드베이스의 유닛 테스트가 실제로 올바르게 작동하는지 검증했다. 의존성 누락으로 테스트 실행이 실패하는 경우를 위해 자가 복구 메커니즘을 도입, 필요한 의존성을 동적으로 Dockerfile에 주입하는 방식으로 유효한 후보를 최대한 확보했다. 최종적으로 1,458개의 후보 쌍이 남았다.
4단계: 케이스 필터링. 마지막으로 세 차례의 추가 필터링을 적용했다. base 코드베이스를 oracle의 테스트 환경에서 실행했을 때 테스트가 아예 기동되지 않는 케이스를 제거하고, base와 oracle 간의 통과 테스트 수 차이가 5개 미만인 케이스도 제거했다. 이후 137개가 남은 후보들 중, 시간 스팬과 커밋 수를 기준으로 상위 100개를 선정해 최종 SWE-CI 벤치마크를 완성했다. 100개의 태스크는 68개의 서로 다른 리포지토리에서 나왔으며, 각 쌍에서 base에서 oracle로의 전환에는 테스트 파일을 제외하고 최소 500줄의 소스 코드 변경이 포함된다.
이 엄밀한 구성 과정은 SWE-CI가 단순한 점진적 변화가 아닌 실질적이고 장기적인 진화 에피소드를 포착하고 있음을 보장한다.
4. 평가 방법론: 아키텍트-프로그래머 이중 에이전트 프로토콜
SWE-CI의 평가는 현실 세계의 소프트웨어 개발 방식을 모방한 이중 에이전트 프로토콜(Dual-Agent Protocol) 을 사용한다. 두 역할이 존재한다: 아키텍트(Architect)와 프로그래머(Programmer).
아키텍트 에이전트는 현재 코드와 oracle 코드 사이의 테스트 격차를 분석해 자연어로 된 고수준 요구사항 문서를 작성한다. 아키텍트는 세 단계로 작업한다: 먼저 실패한 테스트들을 검토하고 근본 원인을 파악하며(요약), 소스 코드를 검토해 구체적인 구현상의 결함을 찾아내고(위치 파악), 이를 바탕으로 개선 계획을 수립해 최종 요구사항 문서를 작성한다(설계). 여기서 중요한 제약이 두 가지 있다. 요구사항 문서는 가장 시급한 항목 5개 이하로 제한하고(점진성), 구체적인 구현 방법이 아닌 예상되는 동작을 서술하는 방식으로 작성해야 한다(고수준성).
프로그래머 에이전트는 요구사항 문서를 바탕으로 코드를 수정한다. 직접 테스트 격차를 보는 것이 아니라 아키텍트가 작성한 요구사항 문서를 통해서만 작업하는 것이 핵심 설계 원칙이다. 이는 지속적 통합의 빠른 이터레이션 철학과 일치하며, 프로그래머가 전체 변경 범위에 압도되지 않고 집중적인 개발에 임할 수 있도록 한다. 프로그래머 역시 세 단계를 따른다: 요구사항을 이해해 코드 명세로 번역하고(이해), 구현에 필요한 작업을 계획하고(계획), 계획을 실제 코드로 구현한다(코딩).
이 CI-루프는 목표 커밋의 모든 테스트를 통과하거나 최대 20회 이터레이션 한도에 도달할 때까지 반복된다. 전체 실험에 소비된 토큰은 100억 개 이상이며, 사용된 에이전트 프레임워크는 알리바바의 iFlow CLI다.
5. 측정 지표의 혁신: Normalized Change와 EvoScore
기존 벤치마크의 이진법적 통과/실패 판정은 소프트웨어의 복잡한 현실을 담지 못한다. SWE-CI는 두 가지 새로운 지표를 도입했다.
Normalized Change(정규화 변화량) 는 현재 코드베이스 상태를 [-1, 1] 범위의 스칼라 값으로 나타낸다. 에이전트가 base보다 더 많은 테스트를 통과시키면 양수가 되고(최대 1.0은 oracle과 동일한 수준 달성), base보다 적은 테스트를 통과시키면 음수가 된다(최소 -1.0은 기존에 통과하던 모든 테스트를 깨뜨림). 개선과 회귀를 동일한 척도로 비교할 수 있도록 비대칭적으로 정규화된 설계가 특징이다.
EvoScore(진화 점수) 는 N번의 이터레이션에 걸쳐 생성된 코드베이스 시퀀스를 단일 스칼라로 집약하는 지표다. 핵심은 후기 이터레이션에 더 높은 가중치를 부여한다는 점이다. ISO/IEC 25010 표준에 따르면 유지보수성은 단일 스냅샷에서는 관측할 수 없고 연속적인 수정을 통해서만 드러난다. EvoScore는 이 원칙을 수식으로 구현한 것이다. 초반에 빠르게 테스트를 통과시키더라도 후반 이터레이션에서 품질이 무너진다면 낮은 점수를 받는다. 반대로 초반에는 느리더라도 설계가 견고해 후반으로 갈수록 안정적으로 진화하는 에이전트는 높은 점수를 받는다. 기술 부채를 숨겨서 초반 점수를 올리는 전략이 통하지 않는 구조다.
6. 실험 결과: 세 가지 결정적 발견
연구진은 8개 제공사의 18개 모델을 테스트했다. 결과는 세 가지 핵심 관측으로 정리된다.
관측 1: LLM의 코드 유지보수 능력은 빠르게 향상 중이다
동일한 제공사 패밀리 내에서 신모델은 항상 구모델보다 높은 점수를 기록했으며, 2026년 이후 출시된 모델들은 이전 세대 대비 훨씬 큰 폭의 향상을 보였다. 이는 현재 LLM의 코딩 능력이 정적인 버그 수정을 넘어 지속적이고 장기적인 코드 유지보수를 향해 빠르게 진화하고 있음을 시사한다. 평가된 모든 모델 중 Claude Opus 시리즈가 전체 관측 기간에 걸쳐 압도적인 우위를 유지했으며, 중국 기업인 Zhipu AI의 GLM-5도 강력한 성과를 보인 주목할 만한 모델이었다.
관측 2: 제공사마다 코드 유지보수성에 대한 강조점이 다르다
EvoScore에서 γ 파라미터(후기 이터레이션 가중치)를 변화시키며 모델 랭킹이 어떻게 바뀌는지 분석했다. γ < 1로 설정하면 초기 코드 수정 효과를 중시하는 모델이 유리하고, γ > 1로 설정하면 장기적 개선을 최적화하는 모델이 유리하다. 흥미롭게도 MiniMax, DeepSeek, GPT는 장기적 이득을 선호하는 반면, Kimi와 GLM은 단기적 성과 쪽으로 기우는 경향이 있었다. 한편 Qwen, Doubao, Claude는 γ 설정값이 달라져도 랭킹이 비교적 안정적으로 유지되는 균형 잡힌 특성을 보였다.
관측 3: 현재 LLM은 장기 코드 유지보수 중 리그레션 통제에 심각하게 취약하다
이것이 가장 충격적인 발견이다. 대부분의 모델에서 zero-regression rate(기존에 통과하던 테스트를 단 한 건도 깨뜨리지 않은 태스크의 비율)가 0.25 미만이었다. 즉, 테스트된 모델의 75% 이상이 유지보수 과정에서 이미 동작하던 코드를 깨뜨렸다는 의미다.
이 참혹한 성적표 속에서 Claude Opus 시리즈만이 50% 이상의 zero-regression rate를 달성한 유일한 모델 패밀리였다. Claude Opus 4.5와 4.6이 이 기준을 넘긴 반면, 다른 모든 제공사의 모델들은 이 문턱에 미치지 못했다. 일부 경우에는 현저히 낮은 수치를 기록했다.
리그레션 비율이 이토록 높은 이유는 구조적인 문제에서 기인할 가능성이 높다. 에이전트들은 기본적으로 지역 최적화기(local optimizer) 다. 현재 실패하고 있는 테스트를 보고, 그것을 수정하고, 다음 단계로 넘어간다. 자신의 변경 사항이 현재 통과하고 있는 테스트들과 어떻게 상호작용하는지, 특히 200일치 개발 역사가 쌓인 복잡한 로직 속에서 무엇이 의존 관계를 가지는지를 모델링하지 못한다. 패턴 매칭으로 파일 diff를 흉내 낼 수 있는 수준이 아닌 진짜 이해를 요구하는 작업이기 때문에, 실력이 그대로 드러난다.
7. SWE-bench와의 결정적 차이: “지금 동작하는가” vs “8개월 후에도 동작하는가”
이 논문이 던지는 메시지는 기존 AI 코딩 평가 생태계에 대한 근본적인 문제 제기다.
HumanEval, MBPP, SWE-bench가 묻는 질문은 결국 “지금 이 코드가 동작하는가”다. 단일 요구사항을 받아 단일 해결책을 만드는 스냅샷 평가다. 이 체계에서는 하드코딩으로 취약하게 때운 코드와 설계가 견고한 코드가 동일한 점수를 받는다.
SWE-CI가 묻는 질문은 “8개월에 걸쳐 71번의 커밋이 이어진 후에도 이 코드가 동작하는가”다. 과거의 결정이 미래에 쌓여 돌아온다. 스냅샷 테스트에 최적화된 에이전트는 오늘 테스트를 통과하는 취약한 코드를 작성하지만, 이는 내일이 되면 유지보수 불가능한 상태로 돌변한다.
현재 2026년 3월 기준으로, SWE-bench Verified에서 상위권 모델들의 점수는 80% 내외로 수렴하고 있다. Claude Opus 4.5가 80.9%, Claude Opus 4.6가 80.8%, Gemini 3.1 Pro가 80.6%로 상위권 모델들 간의 격차가 1.3%포인트 이내로 줄었다. SWE-bench는 사실상 포화 상태에 이르고 있다. SWE-CI는 이 포화된 벤치마크가 보여주지 못하는 실력의 차이를 드러내는 새로운 측정 기준을 제시한다.
8. EvoScore가 기술 부채를 처벌하는 메커니즘
EvoScore의 설계에는 하나의 냉정한 공정성이 담겨 있다. 초반에 빠르게 점수를 올리기 위해 설계를 희생하는 전략은 결국 자기 발등을 찍는 결과로 이어진다. 에이전트가 이터레이션 초반에 테스트를 통과시키기 위해 임시방편적인 코드를 작성하면, 그 결정은 이후 이터레이션에서 수정해야 할 새로운 장애물이 된다. EvoScore는 이 누적된 부채가 점수에 그대로 반영되도록 설계되어 있기 때문에, “빨리 통과시키고 나중에 고치자”는 전략은 통하지 않는다.
이것은 개발자들이 이미 잘 알고 있는 소프트웨어 공학의 진리를 수치로 측정할 수 있게 만든 것이다. 테스트 주도 개발(TDD)의 리팩터링 원칙, 켄트 벡(Kent Beck)의 구조적 변경과 행동적 변경을 분리하는 규율, “처음부터 올바르게 만드는 것이 나중에 고치는 것보다 싸다”는 법칙 — 이것들이 이제 AI 모델을 평가하는 기준이 된 것이다.
9. Claude Opus 시리즈가 유독 강한 이유에 대한 해석
SWE-bench에서 Claude Opus 4.5와 Opus 4.6는 각각 80.9%와 80.8%로 최상위권을 차지하고 있다. 그러나 SWE-CI에서의 유독한 강세는 단순한 코드 생성 능력 이상의 무언가를 시사한다.
한 가지 해석은 Claude 시리즈의 훈련 방향이 즉각적인 테스트 통과보다 코드의 구조적 품질과 장기적 일관성을 더 중시하는 방향으로 이루어져 왔을 가능성이다. Claude Opus 4.6의 경우 Terminal-Bench에서의 높은 성과와 OpenRCA(근본 원인 분석) 벤치마크에서의 개선이 함께 나타나는데, 이는 단순히 코드 문법을 잘 쓰는 모델이 아니라 소프트웨어 시스템과 그 실패 상태에 대한 더 정확한 내적 모델을 보유하고 있음을 시사한다. 즉, “코드를 쓰는” 것이 아니라 “시스템을 이해하고 조작하는” 방향으로의 역량 성장이 SWE-CI에서의 강세로 이어지는 것으로 볼 수 있다.
EvoScore의 γ 민감도 분석에서 Claude가 단기와 장기 모두에서 안정적인 성과를 보인 것도 주목할 만하다. 이는 Claude가 빠른 해결책과 견고한 설계 사이에서 다른 모델들보다 일관된 균형점을 찾고 있음을 의미한다.
10. AI 코딩 내러티브의 재정의
SWE-CI가 드러낸 불편한 진실은 간단하다. 대부분의 AI 모델은 코드를 쓸 수 있지만, 거의 아무도 코드를 유지보수하지 못한다.
이것은 단순한 기술적 한계의 문제가 아니다. AI 코딩 에이전트를 이용한 자동화에 대한 업계 전체의 담론을 재검토해야 할 필요성을 제기한다. 2025년부터 “바이브 코딩(vibe coding)”이 유행하고, AI 코딩 도구의 생산성 향상이 수치로 제시되고, “AI가 주니어 개발자를 대체할 것”이라는 이야기가 떠도는 동안 — 이 모든 평가들은 단발성 코드 생성 능력에만 근거하고 있었다.
현실 세계의 소프트웨어 개발에서 코드 작성은 전체 작업의 일부에 불과하다. 대부분의 시간은 기존 코드를 이해하고, 변경 사항이 시스템 전체에 미치는 영향을 파악하고, 새로운 기능을 추가하면서도 기존 기능이 깨지지 않도록 보장하는 데 쓰인다. SWE-CI는 바로 이 부분, 즉 시간의 무게를 견디는 능력을 측정하는 첫 번째 공식적인 도전장이다.
최고의 모델조차 제어된 벤치마크에서 절반의 시간에만 리그레션을 피할 수 있다면, 실제 프로덕션 환경에서 AI 에이전트가 완전한 자율성으로 코드를 유지보수하도록 맡기는 것이 얼마나 위험한 가정인지가 명확해진다. “코드를 쓸 수 있다”는 것과 “코드를 책임질 수 있다”는 것 사이의 간극 — SWE-CI는 그 간극의 크기를 처음으로 측정해 냈다.
참고 자료
- SWE-CI 논문 원문: https://arxiv.org/abs/2603.03823
- 데이터셋: https://huggingface.co/datasets/skylenage/SWE-CI
- GitHub: https://github.com/SKYLENAGE-AI/SWE-CI
- Engineer’s Codex 분석: https://www.engineerscodex.com/swe-ci-coding-agent-benchmark
- SWE-bench 리더보드 (2026년 3월): https://www.marc0.dev/en/leaderboard
작성일: 2026-03-11