에이전트 평가와 벤치마크: SWE-bench

SWE-bench란 무엇인가

SWE-bench는 실제 GitHub 저장소에서 수집한 이슈와 그 이슈를 해결한 커밋 쌍으로 구성된 벤치마크다. 과거 인기 있는 Python 프로젝트에 실제로 제출된 버그 리포트나 기능 요청을 이슈로 사용하고, 그 이슈를 해결한 Pull Request의 diff를 정답으로 사용한다.

에이전트의 점수는 단순하다. 에이전트가 생성한 코드 변경을 적용했을 때, 해당 이슈와 연관된 테스트 스위트가 모두 통과하면 그 이슈를 해결한 것으로 인정한다. “그럴듯한 설명”이나 “비슷한 코드”는 통과가 아니다. 실제 테스트가 실행되고 통과해야 한다.

이 설계가 중요한 이유가 있다. 이전의 많은 NLP 벤치마크는 텍스트 유사도나 다지선다 정답률을 측정했다. SWE-bench는 실제 행동의 결과물을 측정한다. 에이전트가 파일을 읽고, 코드를 수정하고, 그 수정이 실제로 동작하는지를 테스트로 검증한다.

┌──────────────────────────────────────────────────────────────┐
│                    SWE-bench 평가 흐름                        │
├──────────────────────────────────────────────────────────────┤
│  1. 입력: GitHub 이슈 텍스트 + 저장소 코드베이스 스냅샷        │
│  2. 에이전트: 루프 실행 (파일 탐색 → 수정 → 테스트 실행)       │
│  3. 출력: 코드 변경 diff                                      │
│  4. 평가: diff 적용 → 연관 테스트 실행 → pass/fail           │
│                                                              │
│  ※ 평가 환경은 에이전트 실행 환경과 격리된 별도 컨테이너        │
└──────────────────────────────────────────────────────────────┘

SWE-bench의 변형

SWE-bench는 몇 가지 공식 변형이 있다.

변형	이슈 수	특징
SWE-bench (full)	2,294개	원본 전체
SWE-bench Lite	300개	자기완결적 이슈, 빠른 평가용
SWE-bench Verified	500개	인간 검증으로 평가 품질 보장

SWE-bench Verified는 인간 주석자가 직접 검토해 문제 설명이 명확하고 해결책이 합리적임을 확인한 500개의 이슈로 구성된다. 리더보드 수치는 모델 스냅샷, 평가 하니스, 시도 횟수, 시간·비용 예산에 따라 달라지므로 일반 능력의 단일 척도로 인용하지 않는다.

SWE-agent와 ACI의 등장

SWE-agent 논문에서 가장 중요한 기여는 점수 자체가 아니라 ACI(에이전트-컴퓨터 인터페이스, Agent-Computer Interface) 개념의 도입이다. SWE-agent 초기 버전은 12.5%를 달성했는데, 이는 당시 기준으로 의미 있는 성과였다. 더 중요한 것은 이 성과를 가능하게 한 설계 원칙이다.

기존 접근법들은 에이전트에게 일반적인 bash 셸 접근권을 그대로 줬다. 파일 읽기, 수정, 실행 — 무엇이든 가능했다. SWE-agent 연구진은 이것이 오히려 에이전트를 혼란스럽게 만든다고 주장했다. 대신 에이전트가 코드 편집 작업에 특화된 좁고 명확한 인터페이스를 제공했다.

ACI 설계 원칙은 다음과 같다.

경계된 명령어 집합: 에이전트에게 수백 개의 bash 명령 대신, 구체적인 목적을 가진 소수의 도구만 제공한다. view_file, edit_file, search_code, run_tests 등이 그 예다. 이렇게 하면 에이전트가 어떤 도구를 써야 할지 명확히 알고, 도구 파라미터 환각도 줄어든다.

행동 가능한 에러 메시지: 도구가 실패할 때 “Error: permission denied” 같은 시스템 메시지 대신, “편집한 라인 번호가 파일 길이를 초과합니다. 파일은 총 45줄입니다”처럼 에이전트가 바로 다음 행동을 결정할 수 있는 맥락 있는 에러를 제공한다.

컨텍스트 윈도우 관리: 파일 전체를 한 번에 컨텍스트에 올리지 않고, 현재 편집 중인 주변 50-100줄만 표시한다. 이를 통해 컨텍스트 낭비를 줄이고 에이전트의 집중도를 높인다.

평가 하니스와 격리

평가 하니스는 데이터셋·저장소 스냅샷·컨테이너 이미지·테스트 명령·시간 제한·재시도 정책을 함께 고정한다. 에이전트의 실행 환경과 최종 평가 환경을 분리하고, 패치·도구 출력·trace를 보관해야 실패 원인을 재현할 수 있다. ACI 기반의 좁은 인터페이스와 테스트 실행 루프는 유용한 설계 선택이지만, 효과는 같은 평가 계약 아래에서만 비교할 수 있다.

벤치마크 점수를 해석할 때 주의사항

SWE-bench 점수는 중요한 지표지만 과신해서는 안 된다. 몇 가지 주의할 점이 있다.

학습 데이터 오염(data contamination)의 위험이 있다. 2024년 이후 개발된 이슈는 비교적 안전하지만, 오래된 이슈는 모델 학습 데이터에 포함됐을 수 있다. SWE-bench Verified의 인간 검증이 이를 어느 정도 완화하지만 완전히 제거하지는 못한다.

비용과 시간이 숨겨진 변수다. 이슈당 100번의 API 호출을 허용하는 시스템과 10번만 허용하는 시스템의 비교는 공정하지 않다. 벤치마크 보고서에서 이터레이션 수, 총 토큰 수, 실행 시간을 함께 확인해야 한다.

SWE-bench는 Python에 특화돼 있다. TypeScript, Rust, Go 등의 에이전트 성능은 이 점수로 예측하기 어렵다.

다음 챕터에서는 평가 정확도에서 벗어나 루프 실행의 경제성, 즉 이터레이션마다 발생하는 비용 구조를 살펴본다.