💻 computer science

ChainSWE: Benchmarking Coding Agents on Multi-Bug Software Maintenance

이 논문은 공유 코드베이스 내에서 순차적이고 의존적인 버그 수정을 수행하는 코딩 에이전트를 평가하기 위해 설계된 최초의 벤치마크인 ChainSWE를 소개하며, 이는 기존의 고립된 버그 수정 평가와 비교했을 때 체인 길이가 길어질수록 에이전트의 성능이 크게 저하된다는 점을 밝혀낸다.

원저자: Qirui Jin, Lingching Tung, Kenan Li, Qiyang Shi, Yushi She, Huanzhong Jia, Harrison Zhao, Kejing Xia, Zhenbang Du, Yikai Zhang, Jiaxin Pei, Zhenyu Zhang, Zhen Qi, Yuyan Duan, Wenke Lee, Zijian Jin

게시일 2026-07-07

📖 4 분 읽기☕ 가벼운 읽기

CC BY 4.0

원저자: Qirui Jin, Lingching Tung, Kenan Li, Qiyang Shi, Yushi She, Huanzhong Jia, Harrison Zhao, Kejing Xia, Zhenbang Du, Yikai Zhang, Jiaxin Pei, Zhenyu Zhang, Zhen Qi, Yuyan Duan, Wenke Lee, Zijian Jin

원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. ✨ 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기

핵심 아이디어: "한 번 하고 끝내기"에서 "장기적인 여정"으로

당신이 자동차 한 대가 아니라 자동차 부대를 수리하기 위해 아주 똑똑한 로봇 정비사 팀을 고용했다고 상상해 보세요.

기존 방식 (현재의 벤치마크):
정비사에게 문제를 줄 때마다, 당신은 매번 새롭고 깨끗한 자동차를 건네줍니다. 정비사가 타이어 펑크를 고치면, 당신은 그 작업을 확인한 뒤 정비사를 집으로 돌려보냅니다. 다음 날, 당신은 그에게 다른 문제가 있는 다른 자동차를 줍니다.

문제점: 이 방식은 정비사가 시간이 흐름에 따라 자동차를 유지보수하는 능력이 있는지 테스트하지 못합니다. 현실 세계에서 정비사는 매일 새로운 차를 받는 것이 아닙니다. 그들은 같은 자동차를 대상으로 작업하며, 타이어 펑크를 고치고, 그다음엔 끼익 소리가 나는 브레이크를 고치고, 그다음엔 엔진의 이상 소음을 고치는 식으로 하나의 차량을 계속 다룹니다.

새로운 방식 (CHAINSWE):
연구진은 CHAINSWE라는 새로운 테스트를 구축했습니다. 정비사들에게 매번 새 차를 주는 대신, 단 한 대의 자동차와 수년간 발생한 304개의 문제 목록을 제공합니다.

정비사는 첫 번째 문제를 해결합니다.
그다음, 자동차를 초기화하지 않은 상태에서, 첫 번째 수리 이후의 자동차 상태를 바탕으로 두 번째 문제를 해결해야 합니다.
그다음 세 번째, 이런 식으로 계속됩니다.

로봇이 실패하는 두 가지 주요 방식

연구진은 로봇이 동일한 코드(즉, "자동차")에 대해 긴 문제 목록을 해결하려고 할 때, 단일 문제를 해결할 때는 나타나지 않는 두 가지 특정한 실수를 한다는 것을 발견했습니다.

1. "과잉 장식" 실수 (Overshoot - 과잉 수행)

시나리오: 로봇에게 수도꼭지 누수를 고치라고 요청합니다. 로봇은 수도꼭지를 완벽하게 고칩니다. 하지만 의욕이 앞선 나머지, 아무도 요청하지 않았는데 주방 캐비닛을 새로 칠하고 바닥 타일까지 바꿔버립니다.
결과: 나중에 사람이 전등 스위치를 고치러 들어옵니다. 그런데 로봇이 이전에 바닥 타일과 캐비닛을 바꿔버렸기 때문에, 전등 스위치에 대한 지침이 더 이상 맞지 않게 됩니다. 로봇의 "추가적인" 작업이 다음 작업을 망쳐놓은 것입니다.
논문에서의 의미: 로봇이 건드리지 말아야 할 파일들을 수정하여, 향후 발생할 버그에 대한 테스트를 실패하게 만듭니다.

2. "미완성" 실수 (Undershoot - 미달 수행)

시나리오: 로봇에게 수도꼭지 누수를 고치라고 요청합니다. 로봇은 수도꼭지를 고치려면 새 파이프와 새 밸브가 모두 필요하다는 것을 깨닫습니다. 하지만 로봇은 (요청서에 적힌 대로) 수도꼭지 손잡이만 교체하고, 고장 난 파이프와 밸브는 그대로 둡니다.
결과: 수도꼭지는 고쳐진 것처럼 보이지만 여전히 물이 샙니다. 나중에 사람이 수압을 조절하려 할 때, 로봇이 이전에 파이프를 고치지 않았기 때문에 수압 조절 작업이 완전히 실패하게 됩니다.
논문에서의 의미: 로봇이 버그 리포트에 명시된 특정 파일만 수정하고, 버그 리포트에서 명시적으로 언급하지 않은 지원 파일들을 업데이트하는 것을 잊어버려 코드를 여전히 고장 난 상태로 남겨둡니다.

로봇을 테스트했을 때 어떤 일이 일었나요?

연구진은 이 새로운 "장기 여정(Long Haul)" 테스트를 사용하여 7가지의 서로 다른 "AI 정비사"(언어 모델)를 테스트했습니다.

결과: 로봇이 단일 버그를 작업할 때(기존 방식)는 꽤 괜찮은 성적(약 60% 성공률)을 보였습니다. 하지만 버그의 사슬(chain of bugs)을 작업해야 할 때(새로운 방식)는 성능이 최대 70%까지 급락했습니다.
"연쇄 반응": 버그 목록의 깊은 단계로 들어갈수록 성적이 악화되었습니다. 연속된 3번째 또는 4번째 버그에 도달했을 때, 그들은 거의 계속해서 실패했습니다.
이유는? 로봇들이 자신들의 이전 작업물 때문에 혼란을 겪었기 때문입니다. 로봇들은 자신이 어떤 파일을 수정했는지 기억하지 못하거나, 초기에 했던 "빠른 수정"이 다음 작업을 위한 기초를 어떻게 망가뜨렸는지 잊어버렸습니다.

"기억력"이 도움이 되었나요?

연구진은 로봇들이 자신이 한 일을 기억할 수 있도록 몇 가지 방법을 시도했습니다:

전체 기억 (Full Memory): 지금까지 말한 모든 것의 전체 기록을 읽게 함.
요약된 기억 (Summarized Memory): 로봇에게 이전에 했던 일을 짧게 요약하도록 요청함.
조수 로봇 (Helper Robots): 메인 로봇은 지시만 내리고, 작은 로봇이 실제 파일 편집을 수행하게 함.

놀라운 사실: 이러한 기술들은 별로 도움이 되지 않았습니다. 사실, 로봇에게 자신의 작업을 요약하게 하거나 조수를 사용하는 것은 오히려 상황을 더 악화시키는 경우가 많았습니다. 로봇들은 아무리 기억하려고 노력해도 자신이 코드에 만들어 놓은 "엉망진창인 상태"를 감당하지 못했습니다.

결론

이 논문은 우리가 현재 AI 코더들을 "한 번의 히트(one-hit wonders)"(하나를 고치고 떠나는 것)처럼 테스트하고 있다고 결론짓습니다. 하지만 현실 세계에서 소프트웨어 유지보수는 단거리 경주가 아니라 마라톤입니다.

실제로 소프트웨어를 유지보수할 수 있는 AI를 만들기 위해서는, 단순히 격리된 작업을 테스트하는 것을 넘어, 자신이 만든 불완전하고 엉망인 코드를 직접 다뤄야 하는 **연쇄적인 작업(chains of tasks)**을 통해 테스트해야 합니다. 현재로서는 가장 똑똑한 AI 모델들조차 버그를 연달아 해결해야 할 때 코드베이스를 깨끗하게 유지하는 데 큰 어려움을 겪고 있습니다.

기술 요약: CHAINSWE – 다중 버그 소프트웨어 유지보수에서의 코딩 에이전트 벤치마킹

문제 정의

현재의 대규모 언어 모델(LM) 에이전트는 코드 수정 및 저장소 유지보수를 포함한 소프트웨어 엔지니어링(SWE) 작업을 위해 점점 더 많이 배치되고 있습니다. 그러나 기존 벤치마크(예: SWE-bench, SWE-bench Live, SWE-rebench)는 고립된 단일 이슈 작업을 대상으로 에이전트를 평가합니다. 이러한 프로토콜에서 저장소는 매 평가 시마다 깨끗한 베이스 커밋으로 초기화되며, 에이전트는 신선한 컨테이너 내에서 하나의 독립적인 버그를 해결합니다.

이러한 평가 체계는 엔지니어가 방금 수정한 코드베이스 상에서 연관된 결함들의 흐름을 수정하는 실제 지속적 소프트웨어 유지보수의 현실을 포착하지 못합니다. 논문은 버그가 순차적으로 평가되고 저장소 상태가 세션 간에 유지될 때만 나타나는 두 가지 결정적인 실패 모드를 식별했습니다:

오버슈트(Overshoot): 이전 버그를 수정하는 에이전트가 의도된 범위를 넘어 파일을 수정하는 경우입니다. 이후의 버그가 동일한 파일들을 대상으로 할 때, 에이전트의 편집 사항이 "오염된" 베이스라인에 적용되어 올바른 변경 사항이 실패하게 됩니다.
언더슈트(Undershoot): 에이전트가 이전 버그에 필요한 필수적인 다중 파일 리팩토링을 적용하지 못하는 경우(이슈 제목에 언급된 부분집합만 배포함)입니다. 이 경우 다운스트림 테스트가 실패하는 이유는 현재의 버그를 잘못 다루었기 때문이 아니라, 누락된 리팩토링에 의해 설정되어야 할 전제 조건이 부재하기 때문입니다.

핵심 문제는 현재의 벤치마크가 누적된 의존성과 **상태 드리프트(state drift)**를 무시하고 있으며, 이는 실제 환경의 장기적 유지보수 시나리오에서 에이전트의 능력을 과대평가하게 만든다는 점입니다.

방법론

이러한 격차를 해소하기 위해 저자들은 공유된 코드베이스 내에서 순차적이고 의존적인 버그 수정을 평가하도록 설계된 최초의 벤치마크인 CHAIMSWE를 도입합니다.

데이터 구축 파이프라인

데이터셋은 6개의 기존 SWE-bench 계열 데이터셋(SWE-bench, SWE-bench Live, SWE-rebench, SWE-rebench-v2, SWE-Gym, SWE-bench Pro)으로부터 마이닝 및 검증된 체인을 통해 구축됩니다.

마이닝(Mining): 인스턴스들을 커밋 날짜 순으로 정렬합니다. 슬라이딩 윈도우를 사용하여 다음 조건을 만족할 경우 연속된 인스턴스들을 체인으로 그룹화합니다:
- 후자의 베이스 커밋이 전자의 즉각적인 후속 커밋이거나,
- 후자의 골드(gold)/테스트 패치가 전자의 해결된 상태 위에 깔끔하게 적용되는 경우.
필터링(Filtering):
- 코드 중복 휴리스틱: 버그들이 수정된 파일, 함수 또는 클래스를 공유하지 않는 윈도우를 제외합니다.
- 테스트 재실행: 컨테이너화된 필터를 통해 골드 패치를 순서대로 적용하여 모든 FAIL_TO_PASS 테스트가 통과하고 PASS_TO_PASS 테스트가 퇴보하지 않음을 검증합니다.
- 난이도 선택: 단일 버그 자체가 너무 어려워 ("오라클" 모드에서도 50% 이상의 버그를 해결하지 못하는) 체인은 제거하여, 벤치마크가 순수 버그 해결 능력이 아닌 상태 관리를 테스트하도록 합니다.
최종 데이터셋: 결과적으로 54개의 Python 저장소에 걸쳐 304개의 인스턴스를 포함하는 100개의 버그 체인이 생성되었으며, 평균 체인 길이는 3.04입니다.

평가 프로토콜

저자들은 7개의 최첨단 언어 모델(GPT-5.5, Claude-Opus-4.7, DeepSeek-V4-Pro 포함)을 고정된 에이전트 스캐폴드(SWE-EDIT)를 사용하여 세 가지 컨텍스트 관리 구성 하에 평가합니다:

BASELINE: 전체 상호작용 이력을 유지합니다.
SUMMARIZE: 컨텍스트가 50k 토큰을 초과하면 오래된 이력을 구조화된 요약본으로 대체합니다.
SUB-AGENT: 메인 컨텍스트 윈도우를 깨끗하게 유지하기 위해 파일 보기/편집 작업을 특화된 서브 에이전트에게 위임합니다.

평가는 특정 실패 차원을 격리하기 위해 세 가지 모드에서 수행됩니다:

ORACLE: 컨테이너를 베이스 커밋으로 리셋하고, 에이전트가 시작하기 전에 이전 버그들에 대한 모든 골드 패치를 적용합니다. 이는 상태 드리프트 없이 버그당 능력을 측정합니다.
SEQ (Sequential): 에이전트는 리셋 없이 단일 컨테이너 내에서 버그 1부터 $n$ 까지 작업합니다. 저장소는 에이전트가 생성한 자체 패치를 유지합니다. 에이전트 하네스는 재시작되지만, 코드베이스 상태는 지속됩니다.
SEQ+MEM: SEQ와 동일하지만, 에이전트의 대화 이력 또한 버그 간에 보존됩니다.

주요 결과

평가는 고립된 평가에서 순차적 평가로 이동할 때 일관되고 심각한 성능 저하가 발생함을 보여줍니다:

성능 저하: 모든 모델과 구성에서, ORACLE에서 SEQ로 이동할 때(약 59%에서 36.5%로) 버그당 정확도가 약 38% 감소합니다. 체인의 가장 깊은 위치에서는 성능이 최대 **70%**까지 떨어집니다.
체인 에러: 순차 모드(위치 2 및 3)에서의 실패 중 **48%**는 "체인 에러"입니다. 이는 현재 버그의 본질적인 난이도가 아니라 에이전트가 축적한 자체 상태에 의해 유발된 실패입니다.
- 오버슈트 (작동하는 코드를 깨뜨림)는 이러한 에러의 약 40%를 차지합니다.
- 언더슈트 (버그를 해결하지 못하거나 전제 조건이 충족되지 않음)는 약 25%를 차지합니다.
컨텍스트 관리 전략:
- 요약 및 서브 에이전트는 성능을 저하시킵니다: 긴 컨텍스트를 관리하기 위해 설계된 전략들(SUMMARIZE 및 SUB-AGENT)이 오히려 로우 히스토리 베이스라인(BASELINE)보다 성능이 낮게 나타납니다. ORACLE에서 SEQ로의 상대적 하락폭은 BASELINE의 33%에서 SUMMARIZE/SUB-AGENT의 40-41%로 증가하며, 이는 컨텍스트를 재작성할 때 발생하는 정보 손실이나 불일치가 원본 이력을 유지하는 것보다 더 해롭다는 것을 시사합니다.
- 메모리의 이점은 제한적입니다: 대화 이력을 보존하는 것(SEQ+MEM)은 대부분의 모델에서 미미한 이득만을 제공합니다. 오직 GPT-5.5만이 특정 구성에서 완만한 개선(+7 ~ +8 포인트)을 보였는데, 이는 해당 모델이 긴 이력을 효과적으로 추론할 수 있기 때문으로 보입니다. 다른 모델들의 경우, 추가된 토큰이 더 나은 상태 추적으로 이어지지 않았습니다.
위치 분석: ORACLE 모드에서는 나중에 나오는 버그가 본질적으로 더 어렵지 않습니다. 성공률은 종종 위치에 따라 상승하기도 합니다. 반면 SEQ 모드에서는 체인이 깊어질수록 성공률이 급락하며, 이는 난이도가 작업 복잡성이 아닌 축적된 상태 드리프트에 의해 결정됨을 확인시켜 줍니다.

의의 및 기여

이 논문은 세 가지 주요 기여를 합니다:

CHAINSWE 벤치마크: 실제 저장소에 대해 순차적인 다중 버그 롤아웃을 명시적으로 평가하는 최초의 오픈 소스 벤치마크를 제공하여, 단일 이슈 벤치마크에서는 보이지 않는 실패 모드를 노출합니다.
확장 가능한 파이프라인: 연속적인 버그 수정 시퀀스에 대해 지속적인 평가를 가능하게 하는, 체인화된 SWE 작업을 구축하고 검증하는 파이프라인을 도입합니다.
경험적 통찰: 현재의 SWE 에이전트가 견고한 의존성 추적 및 장기적 추론 능력이 부족함을 입증합니다. 결과는 향ual 발전이 단순히 고립된 이슈 해결 능력을 개선하는 것이 아니라, 저장소 상태 관리와 교차 작업 의존성을 이해하는 데 달려 있음을 시사합니다.

저자들은 현재의 "리셋 후 해결(reset-and-solve)" 패러다임이 중요한 실패 모드를 은폐하고 있다고 결론짓습니다. 실제 소프트웨어 유지보수는 현재의 이슈뿐만 아니라 미래의 작업을 위한 시작점으로도 사용 가능한 상태로 코드베이스를 남겨둘 수 있는 에이전트를 필요로 합니다. CHAINSWE에서 관찰된 상당한 성능 저하는 현재의 에이전트들이 아직 지속적인 자율 소프트웨어 유지보수를 수행할 준비가 되지 않았음을 나타냅니다.