당신이 보고 있는 LLM 벤치마크 점수는 아마 당신이 생각하는 것과 다를 것입니다

지난달 저는 에이전트 파이프라인(agentic pipeline) — 코드 생성(code generation), 도구 호출(tool calling), 다단계 추론(multi-step reasoning) — 을 위한 모델들을 평가하고 있었습니다. 저는 인기 있는 리더보드(leaderboard)에서 가장 높은 순위를 차지한 모델을 선택하여 배포했지만, 그 모델이 기본적인 도구 사용(tool-use) 작업에서 막히는 것을 목격했습니다.

리더보드 점수는 실제였습니다. 하지만 그 점수는 제 사용 사례(use case)와는 무관했습니다.

그 이유는 다음과 같습니다: 대부분의 공개 벤치마크(benchmark)는 모델을 고립된 상태에서 테스트합니다. 하지만 2026년의 프로덕션(production) 환경에서는 아마도 에이전트(agent)를 실행하고 있을 것입니다 — 즉, 도구를 호출하고, 웹을 검색하며, 코드를 실행하고, 파일을 읽는 모델 말입니다. 벤치마크 점수는 그것을 측정하지 않습니다.

도구 사용 격차는 거대하며 점점 벌어지고 있습니다

LXT의 2026년 벤치마크 보고서는 우리 중 많은 이들이 경험적으로 눈치챘던 부분에 수치를 부여했습니다. 2026년 2월, 도구 액세스(tool access)가 활성화된 상태에서:

• Claude Opus 4.6이 **53.1%**로 선두를 달렸습니다.
• GPT-5.3 Codex는 **36%**를 기록했습니다.
• GLM-5는 **32%**를 기록했습니다.

도구 액세스 없이 동일한 모델들은 동일한 작업에서 훨씬 더 낮은 점수를 기록합니다. 도구 지원(tool-assisted) 점수와 비지원 점수 사이의 격차는 이제 에이전트 시스템(agentic systems)을 구축하는 모든 이들에게 가장 중요한 차별화 요소이며, 이는 대부분의 리더보드가 보여주지 않는 숫자입니다.

BenchLM.ai는 247개의 벤치마크에 걸쳐 258개 이상의 모델을 추적합니다. 그들의 데이터는 이 패턴을 확인해 줍니다: 정적 벤치마크(static benchmarks) (MMLU, GSM8K)를 지배하는 모델이 도구 사용 벤치마크를 지배하는 모델과 같지 않다는 것입니다. 상식 퀴즈(trivia)에 경이적인 능력을 가진 모델이 단 하나의 함수 호출(function call)을 작성하는 데는 평범할 수 있습니다.

이것이 실무에서 의미하는 바

만약 당신이 단일 프롬프트(single-prompt) 작업 — 이메일 작성, 문서 요약, 코드 설명 — 을 위해 모델을 선택하고 있다면, 표준 벤치마크 점수는 방향성 측면에서 유용합니다.

하지만 에이전트를 구축하고 있다면, 실제로 중요한 것은 다음과 같습니다:

1. 도구 호출 신뢰성(Tool call reliability). 모델이 주의 분산(distraction) 상황에서도 도구 호출을 올바르게 형식화(format)할 수 있는가? 도구가 에러를 반환할 때 복구할 수 있는가? 이것들은 HumanEval이나 MMLU에 의해 측정되지 않습니다.

2. 컨텍스트 윈도우 경제성 (Context window economics). MCP 서버는 직접적인 API 호출보다 호출당 10~32배 더 많은 토큰을 소모할 수 있습니다. 큰 컨텍스트 윈도우 (context window)를 가진 모델은 도구 호출 (tool invocation)마다 토큰을 낭비하지 않을 때에만 이점이 됩니다.

3. 다단계 계획 충실도 (Multi-step planning fidelity). 어떤 모델들은 5단계 계획을 유지하며 정확하게 실행할 수 있습니다. 반면 다른 모델들은 3단계쯤에서 맥락을 놓쳐버립니다. 이는 측정 가능하지만, 공개 리더보드 (public leaderboards)가 아닌 커스텀 평가 (custom evals)를 통해서만 가능합니다.

# 투박하지만 유용한 대리 지표: 합성 벤치마크가 아닌
# 실제 도구 스키마 (tool schema)에서 모델의 도구 호출 정확도를 측정하세요

...

핵심은 벤치마크가 쓸모없다는 것이 아닙니다. 리더보드에서 보이는 벤치마크 수치는 '대리 지표의 대리 지표'라는 점입니다. 여러분이 실제로 관심을 갖는 것, 즉 '이 모델이 내 파이프라인에서 도구를 얼마나 잘 사용하는가'에 대한 공개 점수판은 존재하지 않습니다.

에이전트적 작업 (Agentic Work)을 위한 모델 평가 방법

제가 모델을 확정하기 전에 현재 수행하는 방법은 다음과 같습니다:

1. 자체 도구 스키마 (tool schema)로 미니 벤치마크 실행. 실제 운영 로그에서 20~50개의 실제 도구 호출을 가져옵니다. 모델에 각각의 호출을 프롬프트로 입력합니다. 파싱 비율 (parse rate)과 정확도를 측정합니다. 이는 오후 시간 정도면 충분하며, 그 어떤 공개 벤치마크보다 효과적입니다.

2. 에러 조건 하에서 테스트. 도구가 빈 값을 반환할 때 모델의 복구 동작은 어떠한가? 에러를 반환할 때는? 예상치 못한 값을 반환할 때는? 많은 모델이 이 지점에서 소리 없이 무너집니다.

3. 성공적인 작업당 토큰 비용 측정. 점수는 5% 더 높지만 도구 호출당 비용이 3배 더 높은 모델은 대량의 에이전트 워크로드 (agentic workloads)에 잘못된 선택일 수 있습니다.

4. 도구 사용 (tool-use) 리더보드를 구체적으로 확인. LLM-stats.com과 BenchLM.ai 모두 도구/코딩 에이전트 점수를 제공합니다. 전체 순위가 아닌 해당 항목으로 필터링하여 확인하세요.

불편한 진실

벤치마크는 객관적인 진실처럼 판매됩니다. 하지만 그렇지 않습니다. 벤치마크는 특정 조건에 맞춰 설계된 지표이며, 그 조건들은 AI가 실제로 배포되는 방식과 점점 더 일치하지 않고 있습니다.

인기 있는 리더보드(Leaderboard)에서 3위를 차지한 모델이 당신의 단일 프롬프트(Single-prompt) 사용 사례에는 적합한 선택일 수 있습니다. 하지만 당신이 실행하는 모든 에이전트적 작업(Agentic task)에는 잘못된 선택일 수 있습니다.

도구 사용(Tool-use) 벤치마크의 선두주자들인 Claude Opus 4.6, GPT-5.3 Codex, 그리고 몇몇 다른 모델들은 실제 프로덕션 에이전트(Production agents)가 수행하는 작업과 유사한 것을 수행하도록 평가받았기 때문에 그 위치를 차지했습니다. 이것은 우연이 아닙니다. 하나의 신호(Signal)입니다.

직감과 리더보드만으로 모델을 선택하는 것을 멈추세요. 아주 작은 규모라도 당신만의 평가(Eval)를 실행하십시오. 테스트를 위해 보내는 오후 시간은, 서류상으로만 훌륭해 보였던 모델을 디버깅(Debugging)하기 위해 보낼 일주일과 비교하면 아무것도 아닙니다.

만약 당신이 에이전트적 워크로드(Agentic workloads)를 실행하고 있으며 모델을 어떻게 평가하고 있는지 공유하고 싶다면, 저는 모든 답글을 읽을 것입니다.