AI 에이전트 평가의 이해

소개

좋은 평가는 팀이 AI 에이전트를 더 자신 있게 배포할 수 있도록 도와줍니다. 평가가 없으면 프로덕션 환경에서만 문제를 발견하고, 하나의 실패를 수정하면 다른 문제가 생기는 반응적인 루프에 빠지기 쉽습니다. 평가는 문제와 동작 변화를 사용자에게 영향을 미치기 전에 가시화하며, 그 가치는 에이전트의 생명주기 전반에 걸쳐 복리로 증가합니다.

효과적인 에이전트 구축하기에서 설명했듯이, 에이전트는 여러 턴에 걸쳐 작동합니다: 도구를 호출하고, 상태를 수정하며, 중간 결과에 따라 적응합니다. AI 에이전트를 유용하게 만드는 바로 이러한 능력들—자율성, 지능, 유연성—이 평가를 더 어렵게 만들기도 합니다.

내부 작업과 에이전트 개발 최전선에 있는 고객들과의 협업을 통해, 우리는 에이전트를 위한 더 엄격하고 유용한 평가를 설계하는 방법을 배웠습니다. 다음은 실제 배포 환경에서 다양한 에이전트 아키텍처와 사용 사례에 걸쳐 효과가 있었던 방법들입니다.

평가의 구조

평가 ("eval")는 AI 시스템을 위한 테스트입니다: AI에게 입력을 주고, 출력에 채점 로직을 적용하여 성공을 측정합니다. 이 글에서는 실제 사용자 없이 개발 중에 실행할 수 있는 자동화된 평가 에 초점을 맞춥니다.

단일 턴 평가 는 간단합니다: 프롬프트, 응답, 그리고 채점 로직. 초기 LLM의 경우, 단일 턴, 비에이전트 평가가 주요 평가 방법이었습니다. AI 능력이 발전함에 따라, 멀티 턴 평가 가 점점 더 일반화되고 있습니다.

에이전트 평가 는 훨씬 더 복잡합니다. 에이전트는 여러 턴에 걸쳐 도구를 사용하고, 환경의 상태를 수정하며, 진행하면서 적응합니다—이는 실수가 전파되고 누적될 수 있음을 의미합니다. 프론티어 모델은 또한 정적 평가의 한계를 뛰어넘는 창의적인 해결책을 찾을 수 있습니다. 예를 들어, Opus 4.5는 항공편 예약에 관한 𝜏2-bench 문제를 정책의 허점을 발견 하여 해결했습니다. 작성된 평가 기준으로는 "실패"했지만, 실제로는 사용자를 위한 더 나은 해결책을 제시한 것입니다.

에이전트 평가를 구축할 때, 우리는 다음과 같은 정의를 사용합니다:

• 태스크 (또는 문제 또는 테스트 케이스)은 정의된 입력과 성공 기준이 있는 단일 테스트입니다.
• 태스크의 각 시도는 trial입니다. 모델 출력은 실행마다 달라지기 때문에, 더 일관된 결과를 얻기 위해 여러 번의 trial을 실행합니다.
• grader 는 에이전트 성능의 특정 측면을 점수화하는 로직입니다. 하나의 태스크는 여러 grader를 가질 수 있으며, 각 grader는 여러 assertion( check라고도 함)을 포함합니다.
• transcript ( trace 또는 trajectory라고도 함)는 출력, 도구 호출, 추론, 중간 결과 및 기타 모든 상호작용을 포함한 trial의 완전한 기록입니다. Anthropic API의 경우, 이는 eval 실행 종료 시점의 전체 messages 배열로, 평가 중 API에 대한 모든 호출과 반환된 모든 응답을 포함합니다.
• outcome 은 trial 종료 시 환경의 최종 상태입니다. 항공권 예약 에이전트가 transcript 끝에서 "항공편이 예약되었습니다"라고 말할 수 있지만, outcome은 환경의 SQL 데이터베이스에 예약이 실제로 존재하는지 여부입니다.
• evaluation harness 는 eval을 처음부터 끝까지 실행하는 인프라입니다. 지시사항과 도구를 제공하고, 태스크를 동시에 실행하며, 모든 단계를 기록하고, 출력을 채점하고, 결과를 집계합니다.
• agent harness (또는 scaffold)는 모델이 에이전트로 작동할 수 있게 하는 시스템입니다: 입력을 처리하고, 도구 호출을 조율하며, 결과를 반환합니다. "에이전트"를 평가할 때, 우리는 harness 와 모델이 함께 작동하는 것을 평가하는 것입니다. 예를 들어, Claude Code 는 유연한 에이전트 하네스이며, 우리는 Agent SDK 를 통해 핵심 프리미티브를 사용하여 장기 실행 에이전트 하네스를 구축했습니다.
• **평가 스위트(evaluation suite)** 는 특정 기능이나 동작을 측정하기 위해 설계된 태스크 모음입니다. 스위트 내의 태스크들은 일반적으로 광범위한 목표를 공유합니다. 예를 들어, 고객 지원 평가 스위트는 환불, 취소, 에스컬레이션을 테스트할 수 있습니다.

평가를 구축해야 하는 이유

팀이 처음 에이전트를 구축하기 시작할 때, 수동 테스트, 독포딩(dogfooding), 그리고 직관의 조합만으로도 놀라울 정도로 멀리 갈 수 있습니다. 더 엄격한 평가는 오히려 배포 속도를 늦추는 오버헤드처럼 보일 수도 있습니다. 하지만 초기 프로토타이핑 단계를 지나 에이전트가 프로덕션에 배포되고 확장되기 시작하면, 평가 없이 구축하는 방식은 한계에 부딪히기 시작합니다.

한계점은 종종 사용자들이 변경 후 에이전트가 더 나빠진 것 같다고 보고할 때 찾아오며, 팀은 추측하고 확인하는 것 외에는 검증할 방법이 없이 '눈을 가린 채 비행하는' 상태가 됩니다. 평가가 없으면 디버깅은 반응적입니다: 불만을 기다리고, 수동으로 재현하고, 버그를 수정하고, 다른 것이 회귀되지 않았기를 바랍니다. 팀은 실제 회귀를 노이즈와 구별하거나, 배포 전에 수백 가지 시나리오에 대해 변경 사항을 자동으로 테스트하거나, 개선 사항을 측정할 수 없습니다.

우리는 이러한 진행 과정이 여러 번 펼쳐지는 것을 보았습니다. 예를 들어, Claude Code는 Anthropic 직원들과 외부 사용자들의 피드백을 기반으로 빠른 반복으로 시작했습니다. 나중에 우리는 평가를 추가했습니다—처음에는 간결성과 파일 편집 같은 좁은 영역에 대해, 그 다음에는 과도한 엔지니어링 같은 더 복잡한 동작에 대해. 이러한 평가는 문제를 식별하고, 개선을 안내하며, 연구-제품 협업에 집중하는 데 도움이 되었습니다. 프로덕션 모니터링, A/B 테스트, 사용자 연구 등과 결합하여, 평가는 Claude Code가 확장됨에 따라 계속 개선할 수 있는 신호를 제공합니다.

평가 작성은 에이전트 라이프사이클의 어느 단계에서든 유용합니다. 초기에는 평가가 제품 팀으로 하여금 에이전트의 성공이 무엇을 의미하는지 명시하도록 강제하고, 나중에는 일관된 품질 기준을 유지하는 데 도움이 됩니다.

Descript의 에이전트는 사용자가 비디오를 편집하도록 돕기 때문에, 그들은 성공적인 편집 워크플로우의 세 가지 차원을 중심으로 평가를 구축했습니다: 망가뜨리지 않기, 요청한 대로 하기, 잘 하기. 그들은 수동 채점에서 제품 팀이 정의한 기준과 주기적인 인간 보정을 갖춘 LLM 채점자로 발전했으며, 이제 품질 벤치마킹과 회귀 테스트를 위한 두 개의 별도 스위트를 정기적으로 실행합니다. Bolt AI 팀은 이미 널리 사용되는 에이전트를 보유한 후에 나중에 평가 구축을 시작했습니다. 3개월 만에 그들은 에이전트를 실행하고 정적 분석으로 출력을 채점하며, 브라우저 에이전트를 사용하여 앱을 테스트하고, 지시 따르기 같은 동작에 LLM 심사자를 활용하는 평가 시스템을 구축했습니다.

일부 팀은 개발 시작 시 평가를 만들고, 다른 팀은 평가가 에이전트 개선의 병목이 되는 규모에 도달한 후에 추가합니다. 평가는 예상되는 동작을 명시적으로 인코딩하기 위해 에이전트 개발 시작 시 특히 유용합니다. 같은 초기 명세를 읽는 두 엔지니어가 AI가 엣지 케이스를 어떻게 처리해야 하는지에 대해 다른 해석을 가질 수 있습니다. 평가 스위트는 이러한 모호성을 해결합니다. 언제 만들어지든, 평가는 개발을 가속화하는 데 도움이 됩니다.

평가는 또한 새로운 모델을 얼마나 빨리 채택할 수 있는지에도 영향을 미칩니다. 더 강력한 모델이 출시되면, 평가가 없는 팀은 몇 주간의 테스트에 직면하는 반면, 평가가 있는 경쟁사는 모델의 강점을 빠르게 파악하고, 프롬프트를 조정하며, 며칠 내에 업그레이드할 수 있습니다. 

평가가 존재하면, 기준선과 회귀 테스트를 무료로 얻을 수 있습니다: 지연 시간, 토큰 사용량, 태스크당 비용, 오류율을 정적 태스크 뱅크에서 추적할 수 있습니다. 평가는 또한 제품 팀과 연구 팀 간의 가장 높은 대역폭 커뮤니케이션 채널이 되어, 연구자들이 최적화할 수 있는 메트릭을 정의합니다. 분명히, 평가는 회귀와 개선을 추적하는 것 이상의 광범위한 이점을 가지고 있습니다. 비용은 선불로 보이는 반면 이점은 나중에 축적되기 때문에 그 복리 가치를 놓치기 쉽습니다.

AI 에이전트를 평가하는 방법

오늘날 대규모로 배포되는 몇 가지 일반적인 유형의 에이전트가 있으며, 코딩 에이전트, 리서치 에이전트, 컴퓨터 사용 에이전트, 대화형 에이전트가 포함됩니다. 각

유형은 다양한 산업에 걸쳐 배포될 수 있지만, 유사한 기법을 사용하여 평가할 수 있습니다. 평가를 처음부터 발명할 필요가 없습니다. 아래 섹션에서는 여러 에이전트 유형에 대해 검증된 기법을 설명합니다. 이러한 방법을 기반으로 사용한 다음, 여러분의 도메인에 맞게 확장하세요.

에이전트를 위한 채점자 유형

에이전트 평가는 일반적으로 세 가지 유형의 채점자를 결합합니다: 코드 기반, 모델 기반, 인간. 각 채점자는 트랜스크립트 또는 결과의 일부를 평가합니다. 효과적인 평가 설계의 필수 구성 요소는 작업에 적합한 채점자를 선택하는 것입니다.

각 작업에 대해 점수는 가중치 방식(결합된 평가자 점수가 임계값을 충족해야 함), 이진 방식(모든 평가자가 통과해야 함), 또는 하이브리드 방식으로 적용할 수 있습니다.

역량 평가 vs. 회귀 평가

역량 또는 "품질" 평가는 "이 에이전트가 무엇을 잘할 수 있는가?"를 묻습니다. 에이전트가 어려워하는 작업을 대상으로 낮은 통과율에서 시작하여 팀이 개선해 나갈 목표를 제시해야 합니다.

회귀 평가는 "에이전트가 이전에 처리하던 모든 작업을 여전히 처리할 수 있는가?"를 묻고, 거의 100% 통과율을 가져야 합니다. 이는 성능 저하를 방지하며, 점수 하락은 무언가 문제가 있어 개선이 필요하다는 신호입니다. 팀이 역량 평가에서 개선을 추구할 때, 변경 사항이 다른 곳에서 문제를 일으키지 않는지 확인하기 위해 회귀 평가도 함께 실행하는 것이 중요합니다.

에이전트가 출시되고 최적화된 후, 높은 통과율을 가진 역량 평가는 지속적으로 실행되어 드리프트를 감지하는 회귀 스위트로 "승격"될 수 있습니다. 한때 "이것을 할 수 있는가?"를 측정하던 작업이 이제는 "이것을 여전히 안정적으로 할 수 있는가?"를 측정하게 됩니다.

코딩 에이전트 평가

코딩 에이전트는 인간 개발자처럼 코드를 작성, 테스트, 디버그하고, 코드베이스를 탐색하며, 명령을 실행합니다. 현대 코딩 에이전트를 위한 효과적인 평가는 일반적으로 명확하게 정의된 작업, 안정적인 테스트 환경, 그리고 생성된 코드에 대한 철저한 테스트에 의존합니다.

결정론적 채점기는 코딩 에이전트에 자연스럽게 적합합니다. 소프트웨어는 일반적으로 평가하기 간단하기 때문입니다: 코드가 실행되는가? 테스트가 통과하는가? 널리 사용되는 두 가지 코딩 에이전트 벤치마크인 SWE-bench Verified 와 Terminal-Bench가 이 접근 방식을 따릅니다. SWE-bench Verified는 에이전트에게 인기 있는 Python 저장소의 GitHub 이슈를 제공하고 테스트 스위트를 실행하여 솔루션을 채점합니다. 솔루션은 기존 테스트를 깨뜨리지 않으면서 실패한 테스트를 수정해야만 통과합니다. LLM은 단 1년 만에 이 평가에서 40%에서 80% 이상으로 발전했습니다. Terminal-Bench는 다른 방향을 취합니다: 소스에서 Linux 커널을 빌드하거나 ML 모델을 훈련시키는 것과 같은 엔드투엔드 기술 작업을 테스트합니다.

코딩 작업의 핵심 결과 를 검증하기 위한 통과/실패 테스트 세트가 있으면, 트랜스크립트도 함께 채점하는 것이 유용한 경우가 많습니다. 예를 들어, 휴리스틱 기반 코드 품질 규칙은 테스트 통과 이상의 기준으로 생성된 코드를 평가할 수 있고, 명확한 루브릭을 가진 모델 기반 채점기는 에이전트가 도구를 호출하거나 사용자와 상호작용하는 방식과 같은 행동을 평가할 수 있습니다.

예시: 코딩 에이전트를 위한 이론적 평가

에이전트가 인증 우회 취약점을 수정해야 하는 코딩 작업을 고려해 보세요. 아래의 예시 YAML 파일에서 보여주듯이, 채점기와 메트릭을 모두 사용하여 이 에이전트를 평가할 수 있습니다. 

task:
  id: "fix-auth-bypass_1"
  desc: "Fix authentication bypass when password field is empty and ..."
  graders:
    - type: deterministic_tests
      required: [test_empty_pw_rejected.py, test_null_pw_rejected.py]
    - type: llm_rubric
      rubric: prompts/code_quality.md
    - type: static_analysis
      commands: [ruff, mypy, bandit]
    - type: state_check
      expect:
        security_logs: {event_type: "auth_blocked"}
    - type: tool_calls
      required:
        - {tool: read_file, params: {path: "src/auth/*"}}
        - {tool: edit_file}
        - {tool: run_tests}
  tracked_metrics:
    - type: transcript
      metrics:
        - n_turns
        - n_toolcalls
        - n_total_tokens
    - type: latency
      metrics:
        - time_to_first_token
        - output_tokens_per_sec
        - time_to_last_token

이 예시는 설명을 위해 사용 가능한 모든 범위의 채점기를 보여줍니다. 실제로 코딩 평가는 일반적으로 정확성 검증을 위한 유닛 테스트와 전반적인 코드 품질 평가를 위한 LLM 루브릭에 의존하며, 추가 채점기와 메트릭은 필요한 경우에만 추가됩니다.

대화형 에이전트 평가

대화형 에이전트 는 지원, 영업, 코칭과 같은 도메인에서 사용자와 상호작용합니다. 전통적인 챗봇과 달리, 이들은 상태를 유지하고, 도구를 사용하며, 대화 중에 행동을 취합니다. 코딩 및 연구 에이전트도 사용자와의 여러 턴의 상호작용을 포함할 수 있지만, 대화형 에이전트는 독특한 도전을 제시합니다: 상호작용 자체의 품질이 평가 대상의 일부입니다. 대화형 에이전트를 위한 효과적인 평가는 일반적으로 검증 가능한 최종 상태 결과와 작업 완료 및 상호작용 품질을 모두 포착하는 루브릭에 의존합니다. 대부분의 다른 평가와 달리, 사용자를 시뮬레이션하기 위해 두 번째 LLM이 필요한 경우가 많습니다. 우리는 정렬 감사 에이전트 에서 이 접근 방식을 사용하여 확장된 적대적 대화를 통해 모델을 스트레스 테스트합니다.

대화형 에이전트의 성공은 다차원적일 수 있습니다: 티켓이 해결되었는가(상태 확인), 10턴 미만으로 완료되었는가(트랜스크립트 제약), 톤이 적절했는가(LLM 루브릭)? 다차원성을 통합한 두 가지 벤치마크는 𝜏-Bench 와 그 후속작인 τ2-Bench입니다. 이들은 소매 지원 및 항공권 예약과 같은 도메인에서 다중 턴 상호작용을 시뮬레이션하며, 한 모델이 사용자 페르소나를 연기하는 동안 에이전트가 현실적인 시나리오를 탐색합니다.

예시: 대화형 에이전트를 위한 이론적 평가

에이전트가 불만을 가진 고객의 환불을 처리해야 하는 지원 작업을 고려해 보세요.

graders:
  - type: llm_rubric
    rubric: prompts/support_quality.md
    assertions:
      - "Agent showed empathy for customer's frustration"
      - "Resolution was clearly explained"
      - "Agent's response grounded in fetch_policy tool results"
  - type: state_check
    expect:
      tickets: {status: resolved}
      refunds: {status: processed}
  - type: tool_calls
    required:
      - {tool: verify_identity}
      - {tool: process_refund, params: {amount: "<=100"}}
      - {tool: send_confirmation}
  - type: transcript
    max_turns: 10
tracked_metrics:
  - type: transcript
    metrics:
      - n_turns
      - n_toolcalls
      - n_total_tokens
  - type: latency
    metrics:
      - time_to_first_token
      - output_tokens_per_sec
      - time_to_last_token

코딩 에이전트 예시에서와 마찬가지로, 이 작업은 설명을 위해 여러 채점기 유형을 보여줍니다. 실제로 대화형 에이전트 평가는 일반적으로 모델 기반 채점기를 사용하여 커뮤니케이션 품질과 목표 완료를 모두 평가합니다. 질문에 답하는 것과 같은 많은 작업에는 여러 "정답" 솔루션이 있을 수 있기 때문입니다.

연구 에이전트 평가

연구 에이전트 gather, synthesize, and analyze information, then produce output like an answer or report. Unlike coding agents where unit tests provide binary pass/fail signals, research quality can only be judged relative to the task. What counts as "comprehensive," "well-sourced," or even "correct" depends on context: a market scan, due diligence for an acquisition, and a scientific report each require different standards.

리서치 평가는 고유한 도전 과제에 직면합니다: 전문가들이 종합 분석이 포괄적인지에 대해 의견이 다를 수 있고, 참조 콘텐츠가 끊임없이 변화하면서 정답 기준도 바뀌며, 더 길고 개방형인 출력은 실수의 여지를 더 많이 만듭니다. BrowseComp와 같은 벤치마크는 AI 에이전트가 오픈 웹 전체에서 건초더미 속 바늘을 찾을 수 있는지 테스트합니다—검증하기는 쉽지만 해결하기는 어렵게 설계된 질문들입니다.

리서치 에이전트 평가를 구축하는 한 가지 전략은 여러 유형의 채점기를 결합하는 것입니다. 근거 확인(Groundedness checks)은 주장이 검색된 출처에 의해 뒷받침되는지 검증하고, 커버리지 확인(coverage checks)은 좋은 답변이 반드시 포함해야 할 핵심 사실을 정의하며, 출처 품질 확인(source quality checks)은 참조한 출처가 단순히 처음 검색된 것이 아니라 권위 있는 것인지 확인합니다. 객관적으로 정답이 있는 작업("X 회사의 3분기 매출은 얼마였나요?")의 경우 정확 일치(exact match)가 효과적입니다. LLM은 뒷받침되지 않는 주장과 커버리지 공백을 표시할 수 있을 뿐만 아니라, 개방형 종합 분석의 일관성과 완전성도 검증할 수 있습니다.

리서치 품질의 주관적 특성을 고려할 때, LLM 기반 루브릭은 이러한 에이전트를 효과적으로 채점하기 위해 전문가의 인간 판단과 자주 보정되어야 합니다.

Computer use 에이전트

Computer use 에이전트 는 API나 코드 실행이 아닌 인간과 동일한 인터페이스—스크린샷, 마우스 클릭, 키보드 입력, 스크롤—를 통해 소프트웨어와 상호작용합니다. 디자인 도구부터 레거시 엔터프라이즈 소프트웨어까지 그래픽 사용자 인터페이스(GUI)가 있는 모든 애플리케이션을 사용할 수 있습니다. 평가를 위해서는 에이전트가 소프트웨어 애플리케이션을 사용할 수 있는 실제 또는 샌드박스 환경에서 실행하고, 의도한 결과를 달성했는지 확인해야 합니다. 예를 들어, WebArena 는 브라우저 기반 작업을 테스트하며, URL과 페이지 상태 확인을 통해 에이전트가 올바르게 탐색했는지 검증하고, 데이터를 수정하는 작업에 대해서는 백엔드 상태 검증(주문이 실제로 완료되었는지, 단순히 확인 페이지가 표시된 것이 아닌지 확인)을 수행합니다. OSWorld 는 이를 전체 운영 체제 제어로 확장하며, 작업 완료 후 다양한 아티팩트를 검사하는 평가 스크립트를 제공합니다: 파일 시스템 상태, 애플리케이션 설정, 데이터베이스 내용, UI 요소 속성 등.

브라우저 사용 에이전트는 토큰 효율성과 지연 시간 사이의 균형이 필요합니다. DOM 기반 상호작용은 빠르게 실행되지만 많은 토큰을 소비하는 반면, 스크린샷 기반 상호작용은 더 느리지만 토큰 효율적입니다. 예를 들어, Claude에게 Wikipedia를 요약하도록 요청할 때는 DOM에서 텍스트를 추출하는 것이 더 효율적입니다. Amazon에서 새 노트북 케이스를 찾을 때는 스크린샷을 찍는 것이 더 효율적입니다(전체 DOM을 추출하면 토큰 집약적이기 때문). Chrome용 Claude 제품에서 우리는 에이전트가 각 컨텍스트에 맞는 올바른 도구를 선택하고 있는지 확인하는 평가를 개발했습니다. 이를 통해 브라우저 기반 작업을 더 빠르고 정확하게 완료할 수 있었습니다.

에이전트 평가에서 비결정성에 대해 생각하는 방법

에이전트 유형에 관계없이 에이전트 동작은 실행마다 달라지므로, 평가 결과는 처음 보이는 것보다 해석하기 어렵습니다. 각 작업은 고유한 성공률을 가집니다—어떤 작업은 90%, 다른 작업은 50%일 수 있으며—한 평가 실행에서 통과한 작업이 다음 실행에서는 실패할 수 있습니다. 때로는 우리가 측정하고 싶은 것이 에이전트가 작업에서 얼마나 자주 (시도 중 몇 퍼센트가) 성공하는지입니다.

두 가지 지표가 이러한 뉘앙스를 포착하는 데 도움이 됩니다:

pass@k 는 에이전트가 k 번의 시도에서 최소 하나의 올바른 솔루션을 얻을 확률을 측정합니다. k가 증가하면 pass@k 점수가 올라갑니다 - '골대를 향한 슛'이 많을수록 최소 1번 성공할 확률이 높아집니다. 50% pass@1 점수는 모델이 첫 번째 시도에서 평가의 절반 작업에 성공한다는 의미입니다. 코딩에서는 에이전트가 첫 번째 시도에서 솔루션을 찾는 것—pass@1—에 가장 관심이 있는 경우가 많습니다. 다른 경우에는 하나만 작동하면 되므로 많은 솔루션을 제안하는 것이 유효합니다.

pass^k 는 모든 k 번의 시도가 성공할 확률을 측정합니다. k 가 증가하면 pass^k는 떨어집니다. 더 많은 시도에서 일관성을 요구하는 것이 더 높은 기준이기 때문입니다. 에이전트의 시도당 성공률이 75%이고 3번의 시도를 실행하면, 세 번 모두 통과할 확률은 (0.75)³ ≈ 42%입니다. 이 지표는 사용자가 매번 신뢰할 수 있는 동작을 기대하는 고객 대면 에이전트에서 특히 중요합니다.

두 지표 모두 유용하며, 어떤 것을 사용할지는 제품 요구사항에 따라 달라집니다: 한 번의 성공이 중요한 도구에는 pass@k를, 일관성이 필수적인 에이전트에는 pass^k를 사용합니다.

제로에서 원으로: 에이전트를 위한 훌륭한 평가 로드맵

이 섹션에서는 평가가 없는 상태에서 신뢰할 수 있는 평가를 구축하기까지의 실용적이고 현장에서 검증된 조언을 제시합니다. 이것을 평가 기반 에이전트 개발을 위한 로드맵으로 생각하세요: 성공을 일찍 정의하고, 명확하게 측정하며, 지속적으로 반복합니다.

초기 평가 데이터셋을 위한 태스크 수집

Step 0. 일찍 시작하세요

팀들이 수백 개의 태스크가 필요하다고 생각해서 평가 구축을 미루는 것을 봅니다. 실제로는 실제 실패 사례에서 가져온 20-50개의 간단한 태스크로 시작하는 것이 훌륭한 출발점입니다. 결국 초기 에이전트 개발에서는 시스템의 각 변경이 종종 명확하고 눈에 띄는 영향을 미치며, 이러한 큰 효과 크기는 작은 샘플 크기로도 충분하다는 것을 의미합니다. 더 성숙한 에이전트는 더 작은 효과를 감지하기 위해 더 크고 어려운 평가가 필요할 수 있지만, 처음에는 80/20 접근법을 취하는 것이 가장 좋습니다. 평가는 오래 기다릴수록 구축하기 어려워집니다. 초기에는 제품 요구사항이 자연스럽게 테스트 케이스로 변환됩니다. 너무 오래 기다리면 라이브 시스템에서 성공 기준을 역설계해야 합니다.

Step 1. 이미 수동으로 테스트하는 것부터 시작하세요

개발 중에 실행하는 수동 검사부터 시작하세요—각 릴리스 전에 확인하는 동작과 최종 사용자가 시도하는 일반적인 태스크입니다. 이미 프로덕션에 있다면 버그 트래커와 지원 대기열을 살펴보세요. 사용자가 보고한 실패를 테스트 케이스로 변환하면 테스트 스위트가 실제 사용을 반영하게 됩니다; 사용자 영향도에 따라 우선순위를 정하면 중요한 곳에 노력을 투자할 수 있습니다.

Step 2: 참조 솔루션과 함께 명확한 태스크 작성하기

태스크 품질을 올바르게 맞추는 것은 보이는 것보다 어렵습니다. 좋은 태스크는 두 명의 도메인 전문가가 독립적으로 동일한 통과/실패 판정에 도달할 수 있는 것입니다. 그들이 직접 태스크를 통과할 수 있을까요? 그렇지 않다면 태스크를 다듬어야 합니다. 태스크 명세의 모호함은 지표의 노이즈가 됩니다. 모델 기반 grader의 기준에도 동일하게 적용됩니다: 모호한 루브릭은 일관성 없는 판정을 만들어냅니다.

각 태스크는 지시를 올바르게 따르는 에이전트가 통과할 수 있어야 합니다. 이것은 미묘할 수 있습니다. 예를 들어, Terminal-Bench를 감사한 결과, 태스크가 에이전트에게 스크립트를 작성하라고 요청하지만 파일 경로를 지정하지 않고, 테스트가 스크립트의 특정 파일 경로를 가정하면, 에이전트는 자신의 잘못 없이 실패할 수 있습니다. grader가 확인하는 모든 것은 태스크 설명에서 명확해야 합니다; 에이전트가 모호한 명세 때문에 실패해서는 안 됩니다. 프론티어 모델의 경우, 여러 시도에 걸쳐 0% 통과율(즉, 0% pass@100)은 대부분 무능한 에이전트가 아니라 깨진 태스크의 신호이며, 태스크 명세와 grader를 다시 확인해야 한다는 표시입니다. 각 태스크에 대해 참조 솔루션을 만드는 것이 유용합니다: 모든 grader를 통과하는 것으로 알려진 작동하는 출력입니다. 이것은 태스크가 해결 가능함을 증명하고 grader가 올바르게 구성되었는지 확인합니다.

Step 3: 균형 잡힌 문제 세트 구축하기

동작이 발생해야 하는 경우와 발생하지 않아야 하는경우 모두를 테스트하세요. 한쪽으로 치우친 평가는 한쪽으로 치우친 최적화를 만듭니다. 예를 들어, 에이전트가 검색해야 할 때만 테스트하면, 거의 모든 것에 대해 검색하는 에이전트가 될 수 있습니다. 클래스 불균형 평가를 피하도록 노력하세요. Claude.ai에서 웹 검색을 위한 평가를 구축할 때 이것을 직접 배웠습니다. 도전 과제는 모델이 검색하지 않아야 할 때 검색하는 것을 방지하면서, 적절할 때 광범위한 조사를 수행하는 능력을 보존하는 것이었습니다. 팀은 양방향을 모두 다루는 평가를 구축했습니다: 모델이 검색해야 하는 쿼리(날씨 찾기 같은)와 기존 지식으로 답해야 하는 쿼리("Apple을 누가 설립했나요?" 같은). 과소 트리거링(검색해야 할 때 검색하지 않음)과 과다 트리거링(검색하지 않아야 할 때 검색함) 사이의 적절한 균형을 맞추는 것은 어려웠고, 프롬프트와 평가 모두에 여러 차례의 개선이 필요했습니다. 더 많은 예제 문제가 나타나면서, 커버리지를 개선하기 위해 계속해서 평가에 추가하고 있습니다.

평가 하네스와 grader 설계하기

Step 4: 안정적인 환경으로 견고한 평가 하네스 구축하기

평가에서 에이전트가 프로덕션에서 사용되는 에이전트와 거의 동일하게 기능하고, 환경 자체가 추가적인 노이즈를 도입하지 않는 것이 필수적입니다. 각 시도는 깨끗한 환경에서 시작하여 "격리"되어야 합니다. 실행 간의 불필요한 공유 상태(남은 파일, 캐시된 데이터, 리소스 고갈)는 에이전트 성능이 아닌 인프라 불안정성으로 인한 상관된 실패를 유발할 수 있습니다. 공유 상태는 또한 성능을 인위적으로 부풀릴 수 있습니다. 예를 들어, 일부 내부 평가에서 Claude가 이전 시도의 git 히스토리를 검사하여 일부 태스크에서 불공정한 이점을 얻는 것을 관찰했습니다. 여러 개의 별개 시도가 환경의 동일한 제한(제한된 CPU 메모리 같은) 때문에 실패하면, 이 시도들은 동일한 요인에 영향을 받기 때문에 독립적이지 않으며, 평가 결과는 에이전트 성능을 측정하는 데 신뢰할 수 없게 됩니다.

Step 5: 신중하게 grader 설계하기

위에서 논의한 바와 같이, 훌륭한 평가 설계는 에이전트와 태스크에 가장 적합한 grader를 선택하는 것을 포함합니다. 가능한 경우 결정론적 grader를, 필요하거나 추가적인 유연성을 위해 LLM grader를, 그리고 추가 검증을 위해 인간 grader를 신중하게 사용하는 것을 권장합니다.

에이전트가 올바른 순서의 도구 호출 시퀀스와 같은 매우 구체적인 단계를 따랐는지 확인하려는 일반적인 본능이 있습니다. 우리는 이 접근법이 너무 경직되어 있고 지나치게 취약한 테스트를 만든다는 것을 발견했습니다. 에이전트는 평가 설계자가 예상하지 못한 유효한 접근법을 정기적으로 찾기 때문입니다. 창의성을 불필요하게 벌하지 않기 위해, 에이전트가 취한 경로가 아니라 에이전트가 생산한 것을 평가하는 것이 종종 더 좋습니다.

여러 구성 요소가 있는 태스크의 경우, 부분 점수를 포함하세요. 문제를 올바르게 식별하고 고객을 확인했지만 환불 처리에 실패한 지원 에이전트는 즉시 실패하는 것보다 의미 있게 더 낫습니다. 이러한 성공의 연속체를 결과에 표현하는 것이 중요합니다.

모델 채점은 정확도를 검증하기 위해 신중한 반복 작업이 필요한 경우가 많습니다. LLM-as-judge 채점기는 인간 채점과 모델 채점 간의 차이가 거의 없다는 확신을 얻기 위해 인간 전문가와 면밀하게 보정되어야 합니다. 환각(hallucination)을 방지하려면 충분한 정보가 없을 때 "Unknown"을 반환하라는 지시와 같이 LLM에게 탈출구를 제공하세요. 또한 작업의 각 차원을 채점하기 위한 명확하고 구조화된 루브릭을 만들고, 하나의 LLM으로 모든 차원을 채점하는 대신 각 차원을 개별 LLM-as-judge로 채점하는 것이 도움이 될 수 있습니다. 시스템이 견고해지면 인간 검토는 가끔씩만 사용해도 충분합니다.

일부 평가에는 에이전트 성능이 좋음에도 낮은 점수를 초래하는 미묘한 실패 모드가 있습니다. 에이전트가 채점 버그, 에이전트 하네스 제약, 또는 모호성으로 인해 작업을 해결하지 못하기 때문입니다. 정교한 팀조차도 이러한 문제를 놓칠 수 있습니다. 예를 들어, Opus 4.5는 처음에 CORE-Bench에서 42%를 기록했습니다. 그러나 Anthropic 연구원이 여러 문제를 발견했습니다: "96.124991…"을 기대할 때 "96.12"에 페널티를 주는 엄격한 채점, 모호한 작업 명세, 그리고 정확히 재현이 불가능한 확률적 작업들이었습니다. 버그를 수정하고 덜 제한적인 스캐폴드를 사용한 후, Opus 4.5의 점수는 95%로 급상승했습니다. 마찬가지로, METR은 발견했습니다 시간 범위 벤치마크에서 여러 잘못 구성된 작업들을. 이 작업들은 에이전트에게 명시된 점수 임계값으로 최적화하라고 요청했지만, 채점은 그 임계값을 초과할 것을 요구했습니다. 이로 인해 지시를 따르는 Claude 같은 모델은 페널티를 받았고, 명시된 목표를 무시한 모델은 더 좋은 점수를 받았습니다. 작업과 채점기를 신중하게 재확인하면 이러한 문제를 피하는 데 도움이 됩니다.

채점기를 우회나 해킹에 강하게 만드세요. 에이전트가 평가를 쉽게 "속일" 수 없어야 합니다. 작업과 채점기는 의도하지 않은 허점을 악용하는 것이 아니라 실제로 문제를 해결해야만 통과할 수 있도록 설계되어야 합니다.

평가를 장기적으로 유지하고 사용하기

6단계: 트랜스크립트 확인하기

많은 시행의 트랜스크립트와 점수를 읽지 않으면 채점기가 잘 작동하는지 알 수 없습니다. Anthropic에서는 평가 트랜스크립트를 보기 위한 도구에 투자했고 정기적으로 시간을 내어 읽습니다. 작업이 실패하면 트랜스크립트는 에이전트가 진짜 실수를 했는지 아니면 채점기가 유효한 솔루션을 거부했는지 알려줍니다. 또한 에이전트와 평가 동작에 대한 핵심 세부 사항을 자주 드러냅니다.

실패는 공정해 보여야 합니다: 에이전트가 무엇을 잘못했고 왜 그런지가 명확해야 합니다. 점수가 오르지 않을 때, 그것이 평가 때문이 아니라 에이전트 성능 때문이라는 확신이 필요합니다. 트랜스크립트를 읽는 것은 평가가 실제로 중요한 것을 측정하고 있는지 검증하는 방법이며, 에이전트 개발에 필수적인 기술입니다.

7단계: 역량 평가 포화 모니터링하기

100%인 평가는 회귀를 추적하지만 개선을 위한 신호는 제공하지 않습니다. 평가 포화(Eval saturation) 는 에이전트가 해결 가능한 모든 작업을 통과하여 개선의 여지가 없을 때 발생합니다. 예를 들어, SWE-Bench Verified 점수는 올해 30%에서 시작했고, 프론티어 모델들은 현재 80% 이상에서 포화에 근접하고 있습니다. 평가가 포화에 가까워지면 가장 어려운 작업만 남기 때문에 진전도 느려집니다. 이로 인해 결과가 기만적일 수 있는데, 큰 역량 향상이 점수에서는 작은 증가로 나타나기 때문입니다. 예를 들어, 코드 리뷰 스타트업 Qodo 는 처음에 Opus 4.5에 감명받지 못했는데, 그들의 원샷 코딩 평가가 더 길고 복잡한 작업에서의 향상을 포착하지 못했기 때문입니다. 이에 대응하여 그들은 새로운 에이전틱 평가 프레임워크를 개발했고, 진전에 대한 훨씬 더 명확한 그림을 제공했습니다.

원칙적으로, 누군가가 평가의 세부 사항을 파고들어 일부 트랜스크립트를 읽기 전까지는 평가 점수를 액면 그대로 받아들이지 않습니다. 채점이 불공정하거나, 작업이 모호하거나, 유효한 솔루션이 페널티를 받거나, 하네스가 모델을 제약한다면 평가를 수정해야 합니다. 

8단계: 오픈 기여와 유지보수를 통해 평가 스위트를 장기적으로 건강하게 유지하기

평가 스위트는 유용하게 유지되기 위해 지속적인 관심과 명확한 소유권이 필요한 살아있는 산출물입니다.

Anthropic에서는 평가 유지보수에 대한 다양한 접근 방식을 실험했습니다. 가장 효과적인 것으로 입증된 것은 핵심 인프라를 소유하는 전담 평가 팀을 구성하고, 도메인 전문가와 제품 팀이 대부분의 평가 작업을 기여하며 평가를 직접 실행하는 것이었습니다.

AI 제품 팀에게 평가를 소유하고 반복하는 것은 유닛 테스트를 유지하는 것만큼 일상적이어야 합니다. 팀은 초기 테스트에서는 "작동하는" AI 기능에 몇 주를 낭비할 수 있지만, 잘 설계된 평가가 일찍 드러냈을 명시되지 않은 기대를 충족하지 못합니다. 평가 작업을 정의하는 것은 제품 요구사항이 구축을 시작할 만큼 충분히 구체적인지 스트레스 테스트하는 가장 좋은 방법 중 하나입니다.

평가 주도 개발(eval-driven development)을 실천하는 것을 권장합니다: 에이전트가 수행할 수 있기 전에 계획된 역량을 정의하는 평가를 구축한 다음, 에이전트가 잘 수행할 때까지 반복합니다. 내부적으로, 우리는 종종 오늘 "충분히 잘" 작동하지만 몇 달 후 모델이 할 수 있는 것에 대한 베팅인 기능을 구축합니다. 낮은 통과율로 시작하는 역량 평가는 이를 가시화합니다. 새 모델이 출시되면 스위트를 실행하면 어떤 베팅이 성과를 거뒀는지 빠르게 드러납니다.

제품 요구사항과 사용자에게 가장 가까운 사람들이 성공을 정의하기에 가장 좋은 위치에 있습니다. 현재 모델 역량으로, 제품 관리자, 고객 성공 관리자, 또는 영업 담당자가 Claude Code를 사용하여 PR로 평가 작업을 기여할 수 있습니다 - 그렇게 하도록 하세요! 또는 더 좋게는, 적극적으로 그들을 지원하세요.

에이전트에 대한 전체적인 이해를 위해 평가가 다른 방법들과 어떻게 맞물리는가

자동화된 평가는 프로덕션에 배포하거나 실제 사용자에게 영향을 주지 않고 수천 개의 작업에 대해 에이전트를 대상으로 실행할 수 있습니다. 하지만 이것은 에이전트 성능을 이해하는 많은 방법 중 하나일 뿐입니다. 완전한 그림에는 프로덕션 모니터링, 사용자 피드백, A/B 테스트, 수동 트랜스크립트 검토, 그리고 체계적인 인간 평가가 포함됩니다.

이러한 방법들은 에이전트 개발의 각기 다른 단계에 매핑됩니다. 자동화된 평가는 특히 출시 전과 CI/CD에서 유용하며, 각 에이전트 변경과 모델 업그레이드마다 실행되어 품질 문제에 대한 첫 번째 방어선 역할을 합니다. 프로덕션 모니터링은 출시 후에 작동하여 분포 드리프트와 예상치 못한 실제 장애를 감지합니다. A/B 테스트는 충분한 트래픽이 확보되면 중요한 변경 사항을 검증합니다. 사용자 피드백과 트랜스크립트 검토는 빈틈을 메우기 위한 지속적인 실천입니다 - 피드백을 지속적으로 분류하고, 매주 트랜스크립트 샘플을 읽고, 필요에 따라 더 깊이 파고드세요. 체계적인 인간 연구는 LLM 채점기를 보정하거나 인간 합의가 참조 표준 역할을 하는 주관적 출력을 평가할 때를 위해 남겨두세요.

가장 효과적인 팀들은 이러한 방법들을 결합합니다 - 빠른 반복을 위한 자동화된 평가, 실제 데이터를 위한 프로덕션 모니터링, 그리고 보정을 위한 주기적인 인간 검토.

결론

평가가 없는 팀들은 반응적인 루프에 빠지게 됩니다 - 하나의 실패를 고치면 다른 것이 생기고, 실제 회귀와 노이즈를 구분하지 못합니다. 일찍 투자하는 팀들은 그 반대를 경험합니다: 실패가 테스트 케이스가 되고, 테스트 케이스가 회귀를 방지하며, 지표가 추측을 대체하면서 개발이 가속화됩니다. 평가는 전체 팀에게 명확한 목표를 제시하여, "에이전트가 더 나빠진 것 같다"를 실행 가능한 것으로 바꿔줍니다. 가치는 복리로 쌓이지만, 평가를 나중에 생각할 것이 아니라 핵심 구성 요소로 다룰 때만 그렇습니다.

패턴은 에이전트 유형에 따라 다르지만, 여기서 설명한 기본 원칙은 일정합니다. 일찍 시작하고 완벽한 스위트를 기다리지 마세요. 발견한 실패에서 현실적인 태스크를 소싱하세요. 모호하지 않고 견고한 성공 기준을 정의하세요. 채점기를 신중하게 설계하고 여러 유형을 결합하세요. 문제가 모델에게 충분히 어려운지 확인하세요. 신호 대 잡음 비율을 개선하기 위해 평가를 반복하세요. 트랜스크립트를 읽으세요!

AI 에이전트 평가는 아직 초기 단계이며 빠르게 진화하는 분야입니다. 에이전트가 더 긴 태스크를 수행하고, 멀티 에이전트 시스템에서 협업하며, 점점 더 주관적인 작업을 처리함에 따라, 우리는 기법을 적응시켜야 할 것입니다. 더 많이 배우면서 모범 사례를 계속 공유하겠습니다.

감사의 글

Mikaela Grace, Jeremy Hadfield, Rodrigo Olivares, Jiri De Jonghe가 작성했습니다. David Hershey, Gian Segato, Mike Merrill, Alex Shaw, Nicholas Carlini, Ethan Dixon, Pedram Navid, Jake Eaton, Alyssa Baum, Lina Tawfik, Karen Zhou, Alexander Bricken, Sam Kennedy, Robert Ying 및 기타 분들의 기여에도 감사드립니다. 평가 협업을 통해 배움을 얻은 고객 및 파트너들, iGent, Cognition, Bolt, Sierra, Vals.ai, Macroscope, PromptLayer, Stripe, Shopify, Terminal Bench 팀 등에게 특별히 감사드립니다. 이 작업은 Anthropic에서 평가 실천을 개발하는 데 도움을 준 여러 팀의 공동 노력을 반영합니다.

부록: 평가 프레임워크

여러 오픈소스 및 상용 프레임워크가 팀들이 인프라를 처음부터 구축하지 않고도 에이전트 평가를 구현하는 데 도움을 줄 수 있습니다. 올바른 선택은 에이전트 유형, 기존 스택, 그리고 오프라인 평가, 프로덕션 관찰 가능성, 또는 둘 다 필요한지에 따라 달라집니다.

Harbor 는 컨테이너화된 환경에서 에이전트를 실행하도록 설계되었으며, 클라우드 제공업체 전반에 걸쳐 대규모로 시험을 실행하기 위한 인프라와 태스크 및 채점기를 정의하기 위한 표준화된 형식을 갖추고 있습니다. Terminal-Bench 2.0과 같은 인기 벤치마크가 Harbor 레지스트리를 통해 제공되어, 커스텀 평가 스위트와 함께 확립된 벤치마크를 쉽게 실행할 수 있습니다.

Promptfoo 는 가볍고 유연한 오픈소스 프레임워크로, 문자열 매칭부터 LLM-as-judge 루브릭까지 다양한 어설션 유형과 함께 프롬프트 테스트를 위한 선언적 YAML 구성에 중점을 둡니다. 우리는 많은 제품 평가에 Promptfoo 버전을 사용합니다.

Braintrust 는 오프라인 평가와 프로덕션 관찰 가능성 및 실험 추적을 결합한 플랫폼으로, 개발 중 반복과 프로덕션에서의 품질 모니터링이 모두 필요한 팀에게 유용합니다. `autoevals` 라이브러리에는 사실성, 관련성 및 기타 일반적인 차원에 대한 사전 구축된 스코어러가 포함되어 있습니다.

LangSmith 는 LangChain 생태계와 긴밀하게 통합된 트레이싱, 오프라인 및 온라인 평가, 데이터셋 관리를 제공합니다. Langfuse 는 데이터 상주 요구 사항이 있는 팀을 위한 자체 호스팅 오픈소스 대안으로 유사한 기능을 제공합니다.

많은 팀들이 여러 도구를 결합하거나, 자체 평가 프레임워크를 만들거나, 단순한 평가 스크립트를 시작점으로 사용합니다. 프레임워크가 진행을 가속화하고 표준화하는 데 가치 있는 방법이 될 수 있지만, 그것을 통해 실행하는 평가 태스크만큼만 좋다는 것을 알게 됩니다. 워크플로우에 맞는 프레임워크를 빠르게 선택한 다음, 고품질 테스트 케이스와 채점기를 반복하여 평가 자체에 에너지를 투자하는 것이 종종 가장 좋습니다.