에이전트 평가는 왜 문제지가 아니라 실행 환경일까

• 카테고리: ai_dev
• 예상 읽기 시간: 10분
• 오늘의 질문: 에이전트 벤치마크 점수를 볼 때, 왜 문제와 정답보다 harness와 예산을 먼저 확인해야 할까?
• 핵심 출처:
  • A shared playbook for trustworthy third-party evaluations - 2026-05-29, 확인일 2026-07-28
  • How evals drive the next chapter in AI for businesses - 2025-11-19, 확인일 2026-07-28
  • Introducing Claude Sonnet 5 - 2026-06-30, 확인일 2026-07-28
  • New Gemini API updates for Gemini 3 - 2025-11-25, 확인일 2026-07-28

1. 왜 지금 봐야 하나

요즘 AI 개발자가 보는 모델 평가는 예전처럼 “문제 100개를 풀렸더니 몇 점”으로 끝나지 않는다. 특히 브라우저, 터미널, 파일 검색, 코드 실행, 함수 호출을 쓰는 에이전트형 시스템에서는 모델만 평가한 것인지, 모델+도구+상태관리+재시도 정책을 평가한 것인지가 점수에 섞인다.

OpenAI는 2026년 5월 third-party evaluation playbook에서 frontier model 평가 보고서가 결과뿐 아니라 “어떤 claim을 테스트했는지”와 “그 결과가 유효하다는 증거”를 명시해야 한다고 썼다. 핵심은 harness다. 여기서 harness는 프롬프트, 도구, 인터페이스, 상태 관리, retry, scorer, budget처럼 모델 주변에서 실행을 가능하게 만드는 전체 장치다. OpenAI는 avoidable under-elicitation, 즉 충분히 이끌어낼 수 있는 능력을 harness나 budget 때문에 못 보게 만드는 것도 측정 실패라고 말한다.

Anthropic의 Claude Sonnet 5 발표도 같은 방향을 보여준다. 2026년 6월 30일 수정 공지에서 Anthropic은 BrowseComp 차트가 더 단순한 방법론 데이터를 썼고, 표준 방법론은 10M token budget, compaction, programmatic tool calling을 포함한다고 설명하며 차트를 업데이트했다. 이 사례는 “같은 모델, 같은 이름의 평가”라도 context compaction과 tool calling을 허용하는지에 따라 결과 해석이 달라진다는 점을 잘 보여준다.

그래서 오늘의 원리는 단순하다. 에이전트 평가는 문제지가 아니라 실행 환경의 측정이다. 점수만 복사하면 제품 판단을 잘못할 수 있고, harness를 기록하면 우리 팀의 eval도 재현 가능한 운영 자산이 된다.

2. 핵심 개념

에이전트 eval을 볼 때 최소 네 가지를 분리해야 한다.

첫째, claim이다. 이 평가는 무엇을 주장하려는가? “모델 A가 모델 B보다 낫다”는 비교 claim인지, “이 시스템이 특정 종류의 업무를 수행할 수 있다”는 capability claim인지, “위험한 행동을 guardrail이 막는다”는 safeguard claim인지가 다르다. claim이 다르면 좋은 harness도 다르다. 비교를 하려면 같은 조건이 중요하고, capability를 보려면 충분히 강한 elicitation이 중요하다.

둘째, harness다. 같은 모델이라도 다음 설정이 바뀌면 다른 시스템이 된다.

- 도구: browser, terminal, file search, code execution 허용 여부
- 상태: 대화 기록 유지, memory, checkpoint, context compaction
- 제어: planning prompt, subagent, retry, timeout, cancel 정책
- 예산: token budget, wall-clock time, attempt 수, inference cost
- 채점: deterministic checker, LLM grader, human review, rubric

셋째, budget이다. 에이전트 과제는 한 번에 맞히는 시험보다 “얼마나 오래 탐색하고 검증할 수 있나”에 민감하다. OpenAI playbook은 capability가 고정된 숫자가 아니라 resource-dependent일 수 있다고 설명한다. 토큰, 시간, 재시도, 도구 호출 예산이 늘면 성공률이 달라질 수 있다. 그러면 점수는 “능력의 천장”이 아니라 “이 harness와 이 예산에서 관측된 성능”이다.

넷째, validity check다. 에이전트가 진짜 문제를 풀었는지, 평가 구멍을 이용했는지 확인해야 한다. reward hacking, contamination, broken task, refusal, sandbagging은 모두 점수를 왜곡한다. 특히 LLM grader를 쓰면 그 grader 자체도 오판할 수 있다. OpenAI의 business eval 글도 LLM grader를 확장 도구로 쓸 수 있지만, domain expert가 정기적으로 감사하고 실제 로그를 봐야 한다고 강조한다.

3. 최신 이슈와 연결

최근 API 기능들은 eval harness가 더 중요해지는 방향으로 움직이고 있다. Gemini 3 API 업데이트는 agentic workflow에서 function calling과 image generation의 thought signatures를 보존해야 하며, 누락되면 400 에러가 나거나 품질이 떨어질 수 있다고 설명한다. 또 grounding, URL context, structured outputs를 함께 쓸 수 있게 하면서 웹 정보를 가져와 JSON으로 추출하는 agent pipeline을 쉽게 만든다.

이런 기능은 제품에는 좋지만 평가에는 질문을 만든다.

이 평가에서 모델은 웹 검색을 썼나?
URL context가 허용됐나?
structured output 실패는 모델 실패인가, schema 설계 실패인가?
thought signature나 state를 보존하지 않은 harness 때문에 multi-step 품질이 낮아진 것은 아닌가?

Anthropic의 Sonnet 5 사례도 비슷하다. BrowseComp 같은 agentic search 평가는 단순 질의응답이 아니다. compaction을 언제 발동하는지, programmatic tool calling이 가능한지, token budget이 얼마인지가 결과에 영향을 준다. 그래서 “모델이 검색을 잘한다”는 문장보다 “어떤 도구와 compaction, 어떤 예산에서 검색 과제를 수행했다”는 문장이 더 운영적으로 정확하다.

OpenAI의 third-party playbook은 이 문제를 표준화된 언어로 정리한다. 보고서가 harness, 도구, budget, validity check를 빼면 능력을 과소평가하거나 안전성을 과신할 수 있다. 이 말은 연구기관만의 문제가 아니다. 우리 팀이 고객지원 에이전트, 코드 리뷰 에이전트, 리서치 에이전트를 만들 때도 똑같이 적용된다.

4. 개발자 관점 해석

개발자가 흔히 하는 실수는 eval dataset만 열심히 만들고 harness를 “테스트 코드 구현 디테일”로 취급하는 것이다. 하지만 에이전트에서는 그 구현 디테일이 곧 제품 동작이다.

예를 들어 코드 수정 에이전트를 평가한다고 하자. 문제는 “버그를 고치라” 하나뿐이어도 harness에 따라 완전히 다른 평가가 된다.

A: 파일 읽기만 가능, 테스트 실행 불가, 1회 응답
B: 파일 읽기/수정 가능, 테스트 실행 가능, 실패 시 3회 retry
C: B + context compaction + 60분 wall-clock + human approval gate

A의 낮은 점수는 모델 능력 부족일 수도 있지만, 실제 개발 워크플로와 다르게 손발을 묶은 결과일 수도 있다. C의 높은 점수는 모델이 뛰어난 것일 수도 있지만, retry와 테스트 피드백이 많은 오류를 흡수한 결과일 수도 있다. 둘 다 유용한 정보지만 claim이 다르다.

제품 eval에서는 그래서 다음 질문이 먼저다.

1. 우리는 모델 단품을 고르려는가, 아니면 제품 workflow를 검증하려는가?
2. 사용자에게 실제로 허용할 도구와 예산은 무엇인가?
3. 실패를 한 번으로 셀 것인가, retry 후 최종 실패로 셀 것인가?
4. 중간에 tool error가 나면 모델 실패인가, 플랫폼 실패인가?
5. 성공 점수와 함께 평균 비용, 평균 시간, escalation 비율을 볼 것인가?

이 질문을 적지 않으면 eval은 금방 “프롬프트 바꾸니 3점 올랐다” 게임이 된다. 반대로 claim과 harness를 함께 저장하면, 모델 교체나 도구 추가 때 무엇이 좋아졌는지 설명할 수 있다.

5. 내 프로젝트에 적용할 체크포인트

에이전트 eval을 만들거나 벤치마크 결과를 읽을 때 아래 체크리스트를 붙여보자.

• Claim 카드: 이 eval이 비교, capability elicitation, safeguard 검증 중 무엇인지 한 문장으로 썼는가?
• Harness 버전: prompt, tools, tool permissions, state policy, retry policy, scorer를 버전으로 남겼는가?
• Budget 로그: max tokens, 실제 input/output tokens, tool call 수, wall-clock time, attempt 수, 비용을 기록했는가?
• State 정책: memory, compaction, thought signature, checkpoint, session resume을 어떻게 보존하거나 버리는지 명시했는가?
• Scorer 감사: LLM grader가 있다면 사람 라벨 샘플과 disagreement rate를 보고 있는가?
• 오류 분류: 모델 추론 실패, 도구 실패, 권한 실패, schema 실패, 데이터 freshness 실패를 나눠 세는가?
• 재현성: 같은 commit, 같은 eval set, 같은 harness로 다시 돌릴 수 있는가?

중요한 것은 모든 eval을 거창하게 만들라는 뜻이 아니다. 작은 팀이라면 20개 케이스로 시작해도 된다. 다만 “케이스 목록”만 저장하지 말고, 그 케이스가 어떤 실행 환경에서 풀렸는지 같이 저장해야 한다.

6. 오늘 10분 액션

지금 운영 중이거나 만들고 싶은 AI 기능 하나를 고른다. 그리고 아래 7줄짜리 eval harness 카드를 작성한다.

1. Claim: 이 eval이 증명하려는 한 문장
2. User task: 사용자가 실제로 요청하는 일
3. Tools: 허용 도구와 금지 도구
4. State: 대화 기록, memory, compaction, checkpoint 정책
5. Budget: token/time/retry/tool-call 한도
6. Scoring: 성공 조건, 실패 조건, 사람 검토 기준
7. Validity checks: reward hacking, contamination, broken task 확인법

시간이 남으면 기존 테스트 하나에 harness_version 필드를 붙인다. 나중에 모델을 바꾸거나 도구를 추가했을 때, 점수 변화가 모델 때문인지 실행 환경 때문인지 구분할 수 있는 최소 장치가 된다.

7. 더 볼 자료

• OpenAI의 third-party evaluation playbook은 agentic capability 평가에서 harness와 budget을 어떻게 보고서에 남겨야 하는지 설명한다.
• OpenAI의 business eval 글은 조직 내부 workflow에 맞춘 contextual eval, golden set, error taxonomy를 만드는 흐름을 설명한다.
• Anthropic의 Claude Sonnet 5 발표와 수정 메모는 agentic benchmark에서 compaction, programmatic tool calling, token budget 같은 방법론이 결과 해석에 영향을 준다는 사례로 볼 수 있다.
• Gemini 3 API 업데이트는 agentic workflow에서 state 보존, function calling, grounding, structured output 같은 API 기능이 eval harness의 일부가 되고 있음을 보여준다.

중복 회피 메모

로컬 content/generated와 Supabase 최근 ai_dev 글을 확인했다. 최근 글은 LLM-as-a-judge를 측정기로 보는 관점, 에이전트 trace를 실행 그래프로 보는 관점, 멀티 에이전트 실행 트리, tool calling 왕복 프로토콜, prompt caching, token counting, context/memory 관리를 다뤘다. 이번 글은 특정 scorer, trace, tool protocol 반복이 아니라 에이전트 평가 점수 자체가 harness·도구·상태·예산·validity check와 분리될 수 없다는 평가 실행 환경 설계에 집중한다.