원문 정보
Koutian Wu, Junjie Zhou, Ergan Shang, Jiayu Wang, Pengqian Han, Junkai Wang, Wanghan Xu, "Benchmark Radar: A Living Database and Search Engine for AI Benchmarks and Evaluation", arXiv:2609.11115 [cs.AI, cs.IR], 2026-09-10 제출, DOI 10.48550/arXiv.2609.11115. 교신저자 Koutian Wu는 Earth-Space-AI 소속과 함께 Tacite AI 소속을 표기했다(연락처 [email protected]). 원문 전문은 2026-09-11T23:22:12Z 기준 스냅숏(전날 자 1차 출처 사본)으로 대조했다.
동료심사를 거치지 않은 arXiv 프리프린트입니다. 논문이 소개하는 시스템 Benchmark Radar는 소스코드 저장소 소유자 계정과 교신저자의 이메일 도메인이 일치해, 저자 소속 회사가 만든 도구를 저자 스스로 감사·소개하는 구조로 읽힙니다. 별도의 자금 출처·이해상충 고지 문단은 본문에서 확인되지 않았습니다.
연구 개요
연구 질문은 두 가지입니다. ① 여러 벤치마크 카탈로그(LLM Stats, OpenCompass Hub, Artificial Analysis, 모델 리포트)에 흩어진 레코드를 하나의 검색 가능한 데이터베이스로 합쳤을 때, 실제로 몇 개가 모이고 그중 몇 개가 서로 비교 가능한가. ② 그렇게 만든 데이터베이스를 실무 조사에 쓰면 무엇이 달라지는가.
방법론은 4개 출처의 레코드를 공통 스키마로 정규화하되 출처 표시는 그대로 남기고, 날짜·점수 필터 없이 전수를 훑는 "센서스" 스크립트로 레코드·모델·문서·점수 개수를 센 것입니다. 점수·날짜·인용이 없는 레코드도 지우지 않고 남긴다는 원칙을 세웠습니다. 5절에서는 저자 중 한 명이 자체 CLI 클라이언트로 2026년 8월 크레딧 할당 연구의 선행연구 조사를 수행한 사례(Table 4)를 곁들여, 카탈로그가 실제 조사에 쓰이는 과정을 보여줍니다.
핵심 결과
2026-09-07 수집 시점 기준 v0.11.0 릴리스는 4개 출처에서 1,283개 레코드를 모았습니다. 출처별 합계는 아래처럼 원문 표와 정확히 일치합니다(레코드·채점·미채점·수치점수 네 열 모두 검산됨).
| 출처 | 레코드 | 채점됨 | 미채점 | 수치 점수 |
|---|---|---|---|---|
| LLM Stats | 687 | 679 | 8 | 5,544 |
| OpenCompass Hub | 461 | 0 | 461 | 0 |
| Artificial Analysis | 25 | 25 | 0 | 7,050 |
| 모델 리포트 | 110 | 86 | 24 | 322 |
| 합계 | 1,283 | 790 | 493 | 12,916 |
여기서 가장 중요한 숫자는 이 표에 없습니다. 채점된 790개 레코드 중 "퍼센트 단위 선언 + 방향 확정 + 값이 0~100 범위"라는 세 조건을 모두 만족해 직접 비교(예: 헤드룸 = 100 − 최고점) 계산이 가능한 레코드는 82개(10.4%)뿐이었습니다. 나머지 708개는 척도가 다르거나 검증되지 않았고, 저자들은 "100점 만점을 가정하지 말라"고 명시했습니다.
| 측정 상태 | 레코드 |
|---|---|
| 퍼센트 척도 선언 + 방향 확정 + 0~100 범위 | 82 |
| 기타·미검증 척도 | 708 |
| 수치 점수 없음 | 493 |
| 전체 | 1,283 |
분류 체계에도 균열이 있습니다. 논문은 "에이전틱" 성격을 가진 345개 레코드 중 128개만 최상위 라벨 '에이전틱·도구사용'을 받았고, 117개는 '코딩·소프트웨어공학' 라벨 아래 묶였다고 밝혔습니다 — 저장소 이슈를 푸는 벤치마크는 에이전트로 실행돼도 도메인 분류는 코딩이 된다는 논리입니다. 문서화 측면에서는 인용 문서 1,208개 중 1,171개(97%)에 소속 기관 표기가 없고, 발행일이 있는 레코드는 1,283개 중 615개(48%)에 그쳤습니다(668개·52%는 발행일 없음). 개별 사례로, GPQA Diamond는 Artificial Analysis 출처 인용 1건으로 586개 모델 점수를 담지만, 모델 리포트 출처는 인용 27건으로 19개 모델·21개 점수만 담습니다 — 인용 건수와 커버리지가 비례하지 않는다는 뜻입니다.
신뢰도 평가
믿을 근거는 방법론의 꼼꼼함에 있습니다. 레코드·모델·문서·점수를 서로 다른 카운트 단위로 명확히 구분해 혼동을 막았고, 재현을 위한 체크섬·검증 스크립트(`--check` 모드)까지 공개했습니다. 원문 표 6개(카탈로그 구성·점수 커버리지·척도 적격성·문서화·점수 분포·날짜 근거)의 하위 합계를 모두 검산한 결과 전부 총계(1,283 / 790 / 493 / 12,916)와 일치했습니다.
감안할 점도 뚜렷합니다. 이 논문은 자사 제품(Benchmark Radar)의 커버리지를 저자 스스로 감사한 구조라, "카탈로그가 얼마나 크고 정교한가"라는 결론 자체가 홍보성일 위험을 안고 있습니다. 저자들 스스로도 검색 정확도·과제 적합성·시간 절감 효과는 아직 측정하지 않았고, 5절의 사용 사례는 통제군 없는 단일 시연이라고 인정합니다. 아카이브 발견 경로가 수집 창구 이전 첫 게재분을 소급하지 않아 관련 연구 2건을 놓쳤다가 공저자가 뒤늦게 찾아냈다는 한계도 스스로 공개했습니다.
리뷰어 판단
이 논문에서 가장 실무적으로 중요한 숫자는 저자들이 헤드라인으로 내세우지 않은 82/790이라고 판단합니다. 벤치마크 리더보드나 "SOTA 대비 몇 점" 식의 비교 글을 볼 때, 그 점수가 애초에 0~100 퍼센트 척도·방향까지 확정돼 정의됐는지부터 확인해야 한다는 뜻입니다. 집계 점수 하나를 믿고 의사결정을 내리는 습관은, 척도 불일치라는 훨씬 기초적인 함정 위에 서 있을 수 있습니다.
둘째, 128 대 117이라는 분류 격차는 "에이전트 벤치마크가 몇 개나 있는가"를 셀 때 반드시 다축(facet) 질의를 써야 한다는 실무 신호로 읽습니다. 최상위 라벨 하나로 필터링하면 실제로 에이전트 실행 방식을 쓰는 평가의 약 3분의 1을 놓칩니다. 경쟁 지형이나 자사 평가 커버리지를 비교하는 보고서에서 이 함정에 걸리면 과소 추정된 숫자로 의사결정을 내리게 됩니다.
실무 적용
- 척도 확인을 인용의 전제조건으로 — 벤치마크 점수를 인용하기 전에 퍼센트 단위·방향·0~100 범위가 명시됐는지부터 확인합니다. 이 감사에서는 채점된 레코드의 약 90%가 이 조건을 충족하지 못했습니다.
- 다축 질의로 커버리지 세기 — 자사 평가 스위트가 다루는 "에이전트 벤치마크 개수"를 셀 때 최상위 도메인 라벨 하나가 아니라 상호작용 방식·입력 양식 같은 별도 축(facet)까지 함께 필터링합니다.
- 문서 수와 모델 수를 분리 집계 — 내부 평가 대시보드 설계 시 "인용 문서 수"와 "채점된 모델 수"를 같은 지표로 섞지 않습니다. GPQA Diamond 사례처럼 인용 1건이 수백 개 모델 점수를 담을 수 있습니다.
- 미채점 레코드도 보존 — 점수가 없는 레코드(전체의 약 38%)라도 논문·저장소·데이터셋 링크가 있으면 폐기하지 않고 참고 자료로 남깁니다.
- 자체 감사 결과는 별도로 검증 — 도구·카탈로그 제공자가 스스로 발표한 "커버리지 수치"는 채택 전에 표본 확인이나 제3자 인용 대조로 한 번 더 검증합니다.
결론
Benchmark Radar 논문의 핵심 기여는 새 리더보드가 아니라, 기존 벤치마크 데이터의 상태를 있는 그대로 드러낸 감사 결과에 있습니다. 채점된 790개 중 82개만 정직하게 비교 가능했다는 사실은, 집계 점수 하나로 모델이나 정책을 비교하는 관행이 얼마나 취약한 바닥 위에 있는지를 보여줍니다. 다만 이 감사가 저자 자신의 제품을 대상으로 한다는 점은 반드시 감안하고 읽어야 하며, 절대 수치보다는 "척도 확인 → 다축 질의 → 문서·모델 분리"라는 점검 방식을 자체 평가 파이프라인에 옮겨 오는 편이 더 유용합니다. 집계 점수의 함정은 에이전트 평가셋 설계 체크리스트에서 다른 각도로도 다뤘습니다.