Agent 벤치마크 개요

왜 벤치마크가 필요한가

에이전트 시스템의 성능을 주관적으로 평가하면 편향이 생깁니다. “잘 동작하는 것 같다” 는 느낌은 실제 성능 변화를 측정하지 못합니다. 벤치마크는 재현 가능하고 비교 가능한 숫자 를 제공합니다.

그러나 벤치마크를 맹목적으로 따르는 것도 위험합니다. 특정 벤치마크에서 높은 점수를 얻기 위해 해당 데이터셋에만 최적화된 harness를 만들면, 실제 운영 환경에서 기대 이하의 성능이 나올 수 있습니다. 벤치마크는 신호이지 목표가 아닙니다.

주요 벤치마크 비교

| 벤치마크 | 측정 영역 | 형식 | 샘플 수 | 업데이트 | |----------|-----------|------|---------|---------| | SWE-bench Verified | 실제 GitHub 이슈 해결 | 코드 수정 후 테스트 통과 | 500개 (인간 검증) | 정적 | | SWE-bench Pro | 데이터 오염 방지, 다양성 | 더 어려운 실제 이슈 | 미공개 | 정적 | | SWE-bench-Live | 최신 이슈 (오염 없음) | SWE-bench 동일 | 월별 추가 | 월간 | | Terminal-Bench 2.0 | CLI 멀티스텝 워크플로 | 샌드박스 터미널 환경 | 89개 과제 | 버전별 | | AgentBench | 다차원 에이전트 능력 | 웹, DB, OS, 게임 등 | 1,000+ | 버전별 | | GAIA | 일반 AI 어시스턴트 | 멀티모달, 멀티스텝 | 450+ | 정적 |

SWE-bench 시리즈

SWE-bench는 실제 오픈소스 프로젝트의 GitHub 이슈를 에이전트가 해결하는 방식으로 평가합니다. 에이전트가 코드를 수정하면 해당 프로젝트의 테스트 스위트가 자동으로 실행되어 통과 여부를 확인합니다.

SWE-bench Verified (2024): 원래 SWE-bench에서 인간 검증자가 500개 샘플을 선별했습니다. 잘못 라벨링된 이슈, 해결 불가능한 이슈를 제거해 더 신뢰할 수 있는 측정값을 제공합니다.

SWE-bench Pro (2025): 두 가지 문제를 해결합니다. 첫째, 데이터 오염 — 훈련 데이터에 포함된 이슈는 모델이 해결 방법을 암기했을 수 있습니다. 둘째, 단순성 — 원래 SWE-bench 이슈 중 많은 수가 한두 줄 수정으로 해결됩니다. Pro는 더 복잡하고 다양한 이슈를 포함합니다.

SWE-bench-Live (2025~): 매월 새로운 GitHub 이슈를 추가합니다. 2026년 2월에는 Windows 지원도 추가되었습니다. 데이터 오염 문제를 구조적으로 해결합니다.

Terminal-Bench

Stanford와 협력해 개발된 Terminal-Bench는 샌드박스 CLI 환경 에서 멀티스텝 워크플로를 평가합니다. 파일 조작, 패키지 설치, 설정 파일 수정, 서비스 시작/중지 등 실제 개발자 작업을 포함합니다.

Terminal-Bench 2.0은 89개의 어려운 터미널 과제로 구성된 버전입니다. 모델·에이전트·도구 버전과 실행 예산이 달라지면 점수도 달라지므로, 특정 기업의 성능 변화나 순위를 harness 일반론의 증거로 인용하지 않습니다. 대신 같은 과제·환경·예산에서 변경 하나만 적용한 실험으로 harness 효과를 확인합니다.

AgentBench와 GAIA

AgentBench 는 에이전트 능력을 여러 차원에서 측정합니다.

운영체제 조작 (파일 시스템, 프로세스 관리)
데이터베이스 쿼리 및 수정
웹 브라우징 및 정보 추출
코드 실행 환경
게임 환경 (전략적 추론)

GAIA (General AI Assistant) 는 멀티모달, 멀티스텝 질문으로 일반 AI 어시스턴트 능력을 평가합니다. 웹 검색, 파일 분석, 계산, 코드 실행을 조합한 복잡한 작업을 포함합니다.

각 벤치마크의 한계

| 벤치마크 | 측정하지 못하는 것 | |----------|-------------------| | SWE-bench | 장기 프로젝트, 아키텍처 결정, 협업 능력 | | Terminal-Bench | 창의적 코드 설계, 문서화, 코드 리뷰 | | AgentBench | 실제 프로덕션 환경의 복잡성 | | GAIA | 도메인 특화 전문성 | | 모든 벤치마크 | 비용 효율성, 레이턴시, 안전성, 사용자 만족도 |

벤치마크 결과 해석 방법

점수 하나만 보는 것은 충분하지 않습니다. 벤치마크 결과를 올바르게 읽으려면 다음 세 가지를 함께 확인해야 합니다.

절대 점수보다 변화와 조건을 함께 보라. harness를 수정했을 때 점수가 올랐다면, tool 호출 방식·컨텍스트 구성·재시도 로직 중 무엇을 바꿨는지 분리해 기록하세요. 같은 과제 목록, 환경 이미지, 모델 스냅샷, 예산을 고정하지 않은 변화율은 비교 근거가 되기 어렵습니다.

실패 케이스를 샘플링하라. 점수가 60%라면 나머지 40%가 왜 실패했는지 무작위로 10~20개를 수동으로 확인하세요. 실패 패턴이 “컨텍스트 부족”, “tool 오사용”, “잘못된 파일 탐색” 처럼 범주화된다면 harness 개선 포인트가 명확해집니다. 실패 로그를 저장해 두면 이후 재실행 시 같은 케이스가 해결됐는지 빠르게 확인할 수 있습니다.

재현성을 확인하라. 같은 조건으로 3회 실행했을 때 점수 분산이 크다면 (±5% 이상), 벤치마크 자체의 노이즈가 있거나 에이전트의 행동이 불안정한 것입니다. 작은 harness 변경이 실제로 효과가 있는지 판단하려면 분산이 낮아야 합니다.

카테고리별로 분해하라. 전체 점수가 같아도 어느 카테고리에서 점수가 올랐고 어디서 내렸는지가 중요합니다. 예를 들어 SWE-bench에서 Python 이슈 성공률이 올랐지만 JavaScript 이슈 성공률이 내렸다면, harness 변경이 특정 언어에 편향된 것일 수 있습니다.

비용 대비 성능

벤치마크 점수만으로는 운영 가능한 에이전트인지 판단할 수 없습니다. 비용 효율성 은 별도로 추적해야 합니다.

토큰 비용 per task. SWE-bench 이슈 하나를 해결하는 데 평균 몇 토큰이 소모되는지 측정하세요. 점수가 5% 높아도 토큰 비용이 3배라면 프로덕션에서 쓰기 어렵습니다.

성공당 비용 (Cost per Resolved). 전체 비용을 성공한 태스크 수로 나누면 실제 가치를 더 잘 비교할 수 있습니다. 점수 70%에 태스크당 $0.50 에이전트와 점수 60%에 태스크당 $0.10 에이전트 중 어느 쪽이 나은지는 사용 규모에 따라 다릅니다.

레이턴시. 오프라인 벤치마크에서는 레이턴시가 보이지 않습니다. 실시간 사용자 대면 에이전트라면 평균 응답 시간을 별도로 측정해야 합니다. 스트리밍 응답 방식과 배치 처리 방식 중 어느 것이 적합한지도 이 시점에 결정하세요.

| 지표 | 측정 방법 | 목표 기준 | |------|----------|----------| | 토큰 비용 / task | 로그에서 input+output 토큰 합산 | 사용 사례별 상한선 정의 | | 성공당 비용 | 총 비용 ÷ 성공 태스크 수 | 경쟁 에이전트 대비 비교 | | 평균 스텝 수 | tool 호출 횟수 평균 | 낮을수록 효율적 | | P95 레이턴시 | 95번째 백분위 응답 시간 | 실시간 요구사항에 맞게 |

자체 벤치마크 구축

공개 벤치마크가 자신의 도메인을 정확히 반영하지 않는다면, 프로젝트 특화 벤치마크 를 만드는 것이 더 유용합니다.

1단계: 실제 태스크 수집. 팀이 실제로 반복적으로 수행하는 작업 50~100개를 수집하세요. 고객 지원 로그, 이슈 트래커, 개발 요청 채널이 좋은 소스입니다.

2단계: 정답 정의. 각 태스크에 대해 “성공” 기준을 명확히 정의하세요. 코드 수정이라면 테스트 통과 여부, 정보 검색이라면 핵심 정보 포함 여부를 기준으로 삼습니다. 모호한 기준은 벤치마크를 무의미하게 만듭니다.

3단계: 자동 평가 구현. 사람이 매번 결과를 확인하면 반복 실행이 불가능합니다. LLM-as-judge, 정규식 매칭, 테스트 실행 등을 활용해 자동화하세요.

4단계: 버전 관리. 벤치마크 데이터셋 자체를 git으로 관리하세요. 나중에 새로운 태스크가 추가되거나 기준이 변경될 때, 이전 결과와 공정하게 비교할 수 있습니다.

5단계: 정기적으로 갱신. 에이전트가 성숙해지면 초기 태스크는 너무 쉬워집니다. 6개월마다 태스크 난이도를 재검토하고, 현재 에이전트가 0~30% 실패하는 난이도 구간을 유지하는 것이 개선 신호를 포착하기 좋습니다.

자체 벤치마크는 시간이 지날수록 가치가 커집니다. 초기에는 작게 시작하고, 에이전트가 성장하면서 함께 확장하세요.

실습: 벤치마크 선택

사용 사례에 맞는 벤치마크를 선택하는 것은 생각보다 중요합니다. 아래 기준을 따라 결정하세요.

코드 수정 에이전트를 만든다면 → SWE-bench Verified를 기본으로 삼고, 도메인이 특화되어 있다면 자체 벤치마크를 추가하세요.

CLI 자동화 에이전트를 만든다면 → Terminal-Bench가 가장 직접적입니다. 특히 DevOps, 인프라 자동화 시나리오와 잘 맞습니다.

범용 어시스턴트를 만든다면 → GAIA는 멀티모달, 멀티스텝 추론을 평가하므로 복잡한 사용자 요청 처리 능력을 확인하기에 좋습니다.

내부 도구 에이전트를 만든다면 → 공개 벤치마크는 참고용으로만 사용하고, 자체 벤치마크를 우선 구축하세요. 사내 API 호출, 특정 데이터 형식 처리 같은 도메인 특화 태스크는 어떤 공개 벤치마크도 반영하지 못합니다.

선택한 벤치마크에서 baseline을 먼저 측정 하세요. 변경 전 점수를 기록하지 않으면, 이후 개선이 있었는지 알 수 없습니다.