원논문: Eta Given Delta: Defining LLM Tool Efficiency With Marginal Tool Utility (arXiv:2607.14108)
핵심 요약
LLM 에이전트가 도구를 호출할 때, 그 호출이 실제로 유용했는지를 판단하는 정량적 메트릭이 지금까지는 없었다. 정확도(accuracy)라는 간접 지표만으로는 “도구를 잘 썼는가”와 “운이 좋았는가”를 구분할 수 없다. 이 논문은 **한계 도구 효용(marginal tool utility, Δ_α)**과 **도구 효율성(tool efficiency, η_α)**이라는 두 가지 메트릭을 처음으로 수학적으로 정의하고, LLM-as-a-Judge 방식으로 각 도구 호출의 유용성을 판정한 뒤, APEX-SWE Observability 벤치마크에서 도구 제거 실험(tool ablation)을 통해 정의의 타당성을 검증한다.
문제의식: 정확도만으로는 부족하다
기존 LLM 에이전트 평가는 거의 예외 없이 정확도를 핵심 메트릭으로 삼는다. SWE-bench, Terminal-Bench, BrowseComp, OSWorld-Verified 등 유명 벤치마크가 모두 그렇다. 도구 사용 품질을 평가하겠다고 만든 WTU-EVAL조차도 정확도를 대리 지표(proxy)로 사용한다.
하지만 정확도에는 근본적인 맹점이 있다:
- 도구를 10번 호출해서 성공한 것과, 3번만에 성공한 것이 같은 점수를 받는다.
- 도구 호출이 해결에 기여했는지, 오히려 방해했는지 알 수 없다.
- “필요 없는 도구”를 툴킷에서 제거하면 정확도가 어떻게 되는지 직접 측정하지 않는다.
이 논문은 이 간극을 메운다. “효율성(efficiency)“이라는 단어를 물리학에서 쓰는 의미(유용한 에너지 / 전체 입력 에너지) 그대로 가져와, LLM 에이전트의 도구 사용에 적용한다.
메트릭 정의: 한계 도구 효용과 도구 효율성
1. 한계 도구 효용 (Marginal Tool Utility, Δ_α)
트라젝토리 τ 안에서 i번째 도구 호출 α_i의 한계 효용은 다음과 같이 정의된다:
α_i를 포함했을 때의 정답 확률 − α_i를 제외했을 때의 정답 확률
즉, **그 도구 호출 하나가 정답 가능성을 높였는지(Δ_α > 0), 낮췄거나 무의미했는지(Δ_α ≤ 0)**를 판정한다.
실제 구현에서는 반복 롤아웃 대신 LLM-as-a-Judge(판정 모델로 GPT-5.4 사용)가 before/after 트라젝토리를 비교하여 부호(sgn)를 결정한다. 정확한 확률 차이값이 아닌 부호만 알아도 충분하다는 것이 저자의 주장이다.
2. 도구 효율성 (Tool Efficiency, η_α)
전체 N번의 도구 호출 중 유용한 호출(Δ_α > 0)의 비율:
이는 물리학의 효율성 정의(유용 출력 / 전체 입력)와 정확히 대응된다.
**도구별 집계 효용(aggregate tool utility)**은 한 도구의 모든 호출에 대한 Δ_α의 합으로, 이 값이 양수면 “유용한 도구”, 음수나 0이면 “불필요한 도구”로 판정한다.
실험 설계: APEX-SWE Observability
검증에는 APEX-SWE Observability 벤치마크를 사용했다. 이 벤치마크는 소프트웨어 관측가능성(observability) 과제로, 에이전트가 프로덕션 버그의 원인을 찾고 코드 패치를 생성하는 과제를 수행한다. 현재 최고 수준의 모델도 40% 정확도를 넘기 어려운 난이도다.
기본 하네스에는 3개의 MCP 도구가 포함되어 있다:
| 도구 | 용도 | 가설 |
|---|---|---|
| Grafana/Loki | 로그 조회 | 유용 (primary source) |
| Mattermost | 개발자 채팅 | 불필요 (noisy secondary source) |
| Plane | 이슈/티켓 | 불필요 (outdated specs) |
이 가설을 검증하기 위해 3가지 변형으로 도구 제거 실험을 수행했다:
- default: 3개 MCP 도구 모두 포함
- grafana: Grafana/Loki만 포함
- no-mcp: MCP 도구 전혀 없음
사용 모델은 GPT-5.3-Codex와 Gemini 3.1 Pro. 총 150개(25 과제 × 3 변형 × 2 모델)의 트라젝토리를 생성했다.
핵심 결과
정확도: 도구 제거가 예상대로 작동한다
| 변형 | GPT-5.3-Codex 정확도 | Gemini 3.1 Pro 정확도 |
|---|---|---|
| default (전체) | 0.32 | 0.28 |
| grafana (Grafana만) | 0.36 | 0.28 |
| no-mcp (MCP 없음) | 0.24 | 0.16 |
Mattermost와 Plane을 제거해도(default → grafana) 정확도는 오히려 약간 상승한다. 반면 Grafana/Loki까지 제거하면(grafana → no-mcp) 정확도가 뚜렷하게 하락한다. 가설이 맞았다.
한계 도구 효용: 판정 모델과 제거 실험이 일치한다
default 변형에서 MCP 도구별 집계 효용을 계산한 결과:
| 도구 | GPT-5.3-Codex | Gemini 3.1 Pro |
|---|---|---|
| Grafana/Loki | +25 | +5 |
| Mattermost | −35 | −17 |
| Plane | −30 | −28 |
Grafana/Loki는 양수, 나머지 둘은 음수. 이는 정확도 변화와 완벽히 일치한다.
아래 그림은 Gemini 3.1 Pro의 default 트라젝토리 전체에서 각 도구 호출의 한계 효용 부호를 시각화한 것이다:
Figure 2: Gemini 3.1 Pro default 트라젝토리의 한계 도구 효용 부호 분포. 초록은 유용(Δ>0), 빨강은 무의미(Δ≤0) 호출.
핵심 인사이트: 유용한 도구 호출은 트라젝토리 초반에 집중되고, 중반의 호출은 무의미한 경우가 많다. 초반에는 로그에서 구체적 에러를 찾고, 중반에는 노이즈가 많은 채팅·스펙을 뒤지며 시간을 낭비하는 패턴이다.
도구 효율성: 불필요한 도구를 빼면 효율이 오른다
| 변형 | GPT-5.3-Codex η_α | Gemini 3.1 Pro η_α |
|---|---|---|
| default | 0.359 | 0.367 |
| grafana | 0.720 | 0.593 |
Mattermost와 Plane을 제거하자 도구 효율성이 약 2배 가까이 상승했다. 정확도는 유지하면서 말이다.
아래는 과제별 전체 스코어 분포다:
Figure 3: 과제별 스코어 분포. 1은 통과, 0은 실패.
왜 중요한가
이 논문의 의의는 세 가지 차원에서 이해할 수 있다.
1. 평가 메트릭의 패러다임 전환. 정확도만으로는 에이전트의 “도구 사용 건강도”를 측정할 수 없다. 한계 도구 효용은 개별 도구 호출이 실제로 정답 가능성을 높였는지를 직접 측정하며, 도구 효율성은 전체 트라젝토리에서 유용한 호출의 비율을 계산한다. 이 두 메트릭은 정확도를 대체하는 것이 아니라 보완한다.
2. 실용적 적용 가치. 에이전트 하네스를 설계하는 엔지니어에게 이 메트릭은 즉시 활용 가능하다. 운영 중인 에이전트의 트라젝토리 로그를 수집하고, LLM-as-a-Judge로 각 도구 호출의 유용성을 판정한 뒤, 집계 효용이 0 이하인 도구를 툴킷에서 제거하면 된다. 파인튜닝도, 새로운 모델도 필요 없다.
3. 미래 연구 방향. 저자는 이 메트릭이 (a) 도구 호출 품질을 보상에 반영하는 RL 훈련, (b) 자동 하네스 최적화, (c) 자기 개선 에이전트의 온라인 피드백 신호로 활용될 수 있다고 제안한다. 특히 “중반의 무의미한 호출이 많다”는 발견은, 에이전트가 스스로 백트랙을 수행하는 메커니즘의 필요성을 시사한다.
한계
- 판정 모델의 신뢰성. LLM-as-a-Judge의 부호 판정이 항상 완벽하지 않다. 저자는 판정 모델이 부정(Δ ≤ 0) 분류에 더 확신을 보인다고 기술하지만, 왜 그런지는 조사하지 않았다.
- 읽기 전용 도구만 실험. apply_patch 같은 쓰기 도구는 제거하면 과제 자체가 불가능해지므로, 한계 효용을 직접 측정하지 못했다.
- 과제 범위. APEX-SWE Observability라는 단일 벤치마크(25 public 과제)로 검증했다. 다른 도메인에서도 집계 효용과 정확도가 일치하는지는 추가 검증이 필요하다.
더 실습해보고 싶은 분들께
이 논문은 에이전트의 하네스 설계와 도구 오케스트레이션을 다루고 있다. 직접 에이전트를 만들어보면서 도구 사용 패턴과 하네스 구조를 실험해보고 싶다면 다음 두 자료를 추천한다:
- 『이게 되네? 오픈클로 미친 활용법 50제』 — 실제 에이전트 활용 패턴 50가지를 코드와 함께 소개한다. 도구 호출, 루프 설계, 컨텍스트 관리의 실전 감각을 익히기 좋다.
- 「모두를 위한 루프 엔지니어링」 — 에이전트 루프 설계를 체계적으로 배울 수 있는 강의. 하네스 진화, 메모리 시스템, 도구 사용 최적화까지 폭넓게 다룬다.
정리
“Eta Given Delta”는 LLM 에이전트 평가에 오랫동안 빠져 있던 차원을 채운 논문이다. 정확도가 같아도 도구 사용 방식은 다를 수 있으며, 그 차이가 실서비스에서는 비용과 지연 시간으로 이어진다. 한계 도구 효용이라는 개념적으로 깔끔한 정의와 LLM-as-a-Judge라는 실용적인 구현 방법을 결합해, 에이전트 평가 메트릭 연구의 출발점이 될 만한 작업이다.
본 글은 원논문 arXiv:2607.14108을 기반으로 작성되었습니다. Figure는 원논문에서 발췌했습니다.