SWEeper-Bench, 대화형 소프트웨어의 버그 발견 능력을 평가하다

들어가며

코드 에이전트는 단순히 프롬프트에 맞는 코드를 작성하는 도구에서, 사용자가 실제로 이용할 수 있는 대화형 소프트웨어를 만드는 시스템으로 발전하고 있습니다. 그러나 웹 애플리케이션에서는 코드가 겉보기에 타당하다고 해서 기능이 정상적으로 작동하는 것은 아닙니다. 특정 권한을 바꾸거나 상태를 저장하고, 다른 화면으로 이동하는 등 여러 행동을 순서대로 수행한 뒤에야 드러나는 버그도 많기 때문입니다.

기존 소프트웨어 엔지니어링 벤치마크는 대체로 어떤 버그를 고쳐야 하는지 이미 알려줍니다. 따라서 버그를 발견하는 과정은 평가에서 빠지는 경우가 많았습니다. SWEeper-Bench는 이 지점을 겨냥해, 에이전트가 문제를 스스로 탐색하고 수정하는 전체 과정을 측정합니다.

주요 특징

• 실제 사례 기반 200개 과제: 널리 사용되는 오픈소스 웹 애플리케이션 200개에서 실제 버그 수정 기록을 바탕으로 과제를 만들었습니다.
• 구체적인 오류 설명이 없음: 에이전트는 코드베이스와 “Focalboard의 보드 공유 및 멤버십 기능에서 문제를 찾아 수정하라”와 같은 포괄적인 요청만 받습니다.
• 상호작용 테스트가 필수: 코드를 읽는 것만으로는 부족하므로 애플리케이션을 실행하고, 사용자처럼 여러 조작을 조합해 결함을 유발해야 합니다.
• 브라우저에서 사용자 관점으로 검증: 에이전트형 검증기가 브라우저에서 수정 결과를 확인하고 사용자가 실제로 관찰할 수 있는 동작을 기준으로 판정합니다.
• 여전히 낮은 성공률: 15개 최첨단 에이전트 가운데 가장 뛰어난 시스템도 과제의 59.0%만 통과했습니다.

핵심 병목은 ‘발견’

에이전트의 실행 궤적을 분석한 결과, 가장 어려운 단계는 버그가 발생하는 행동을 찾아내는 일이었습니다. 에이전트는 관련 페이지나 컴포넌트까지 도달한 뒤에도 화면이 열리는지, 버튼이 반응하는지 정도만 확인하고 탐색을 끝내는 경우가 많았습니다. 실제 오류를 일으키는 다음 단계까지 진행하지 않거나, 이상한 결과를 보더라도 그것이 기능의 의도와 어긋난다는 사실을 알아차리지 못하기도 했습니다.

대화형 버그는 하나의 함수나 정적인 코드 패턴에만 나타나지 않습니다. 애플리케이션 상태, 이동 순서, 권한 설정, 여러 UI 조작의 조합이 함께 작용할 수 있습니다. 따라서 효과적인 디버깅에는 코드 검색과 패치 생성뿐 아니라 가설 수립, 실험 설계, 상태 추적, 관찰 결과 해석이 필요합니다.

의미와 영향

SWEeper-Bench는 코드 에이전트 평가를 실제 개발 환경에 한층 가깝게 가져갑니다. 명확한 오류 보고서를 받아 수정하는 능력과, 보고되지 않은 문제를 스스로 찾아 검증하는 능력은 다릅니다. 후자를 위해서는 브라우저 조작 계획, 탐색적 테스트 생성, 이상 징후 인식, 상태 관리, 회귀 검증이 모두 필요합니다.

사용자가 먼저 숨은 결함을 발견하고 개발자가 나중에 수정하는 흐름을 줄이려면, 에이전트가 소프트웨어를 직접 사용하면서 품질을 점검해야 합니다. 59.0%라는 결과는 이런 자율적 품질 보증이 아직 해결되지 않았음을 보여줍니다. 앞으로 대화형 애플리케이션을 만드는 에이전트의 경쟁력은 초기 코드 생성뿐 아니라, 자신이 만든 소프트웨어를 얼마나 철저히 시험하는지에 의해 좌우될 가능성이 큽니다.

출처: Hugging Face Daily Papers