AI 에이전트 평가의 오해를 풀기

https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

에이전트를 유용하게 만드는 능력들이 동시에 평가를 어렵게 만듭니다. 다양한 배포 환경에서 효과적인 전략은, 측정하려는 시스템의 복잡도에 맞춘 기법을 결합하는 것입니다.

소개

좋은 평가(evaluation, 이하 ‘eval’)는 팀이 AI 에이전트를 더 자신 있게 출시하도록 돕습니다. 이를 갖추지 않으면, 문제를 프로덕션에서만 발견하고, 한 실패를 고치면 다른 실패를 유발하는 반응적 루프에 갇히기 쉽습니다. Evals는 문제가 사용자에게 영향을 미치기 전에, 그리고 행동 변화가 일어나기 전에 이를 가시화하며, 그 가치는 에이전트의 수명 주기 내내 누적됩니다.

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

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

평가의 구조

평가(“eval”)는 AI 시스템을 위한 테스트입니다: AI에 입력을 제공하고, 그 출력에 채점 로직을 적용하여 성공을 측정합니다. 이 글에서는 실제 사용자를 동원하지 않고 개발 중에 실행할 수 있는 자동화된 evals에 집중합니다.

단일 턴 평가는 간단합니다: 프롬프트, 응답, 그리고 채점 로직. 초기 LLM 시대에는 단일 턴의 비‑에이전트적 평가가 주요 방법이었습니다. AI 능력이 발전함에 따라 멀티 턴 평가가 점점 흔해지고 있습니다.

간단한 eval에서는, 에이전트가 프롬프트를 처리하고, 채점기가 출력이 기대에 부합하는지 확인합니다. 더 복잡한 멀티 턴 eval에서는, 코딩 에이전트가 도구, 작업(여기서는 MCP 서버 구축), 환경을 받고 “에이전트 루프”(도구 호출과 추론)를 실행하며, 구현을 통해 환경을 갱신합니다. 채점은 작동하는 MCP 서버를 단위 테스트로 검증합니다.

에이전트 평가는 더 복잡합니다. 에이전트는 많은 턴에 걸쳐 도구를 사용하고, 환경의 상태를 수정하며, 진행 중에 적응합니다—이는 오류가 전파되고 누적될 수 있음을 의미합니다. 프런티어 모델은 정적 eval의 한계를 넘어서는 창의적 해법을 찾기도 합니다. 예를 들어, Opus 4.5는 항공편 예약에 관한 𝜏2-bench 문제에서 정책의 허점을 발견했습니다. 평가 설계대로라면 “실패”였지만, 실제로는 사용자에게 더 나은 해결책을 제시한 것입니다.

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

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

에이전트 평가의 구성 요소

왜 평가를 구축해야 하나요?

팀이 에이전트를 처음 만들기 시작할 때에는, 수동 테스트, 도그푸딩(dogfooding), 직관의 조합으로 놀랄 만큼 멀리 갈 수 있습니다. 더 엄격한 평가가 오히려 출시를 느리게 하는 오버헤드처럼 보일 수도 있습니다. 하지만 초기 프로토타이핑 단계를 지나, 에이전트가 프로덕션에 들어가 확장되기 시작하면, eval 없이 빌드하는 접근은 곧 한계에 부딪힙니다.

결정적 전환점은 종종, 사용자가 변경 후 에이전트가 더 나빠진 것 같다고 보고하고, 팀이 ‘눈가리고 비행’하며 추측과 확인 외에는 검증할 방법이 없게 될 때 옵니다. Eval이 없으면 디버깅은 반응적입니다: 불만을 기다리고, 수동으로 재현하고, 버그를 고치고, 다른 곳에서 회귀(regression)가 없기를 바라는 식입니다. 팀은 실제 회귀와 노이즈를 구분할 수 없고, 출시 전에 수백 가지 시나리오에 대해 자동 테스트를 할 수 없으며, 개선을 측정할 수 없습니다.

우리는 이러한 전개를 여러 번 목격했습니다. 예를 들어, Claude Code는 처음에는 Anthropic 직원과 외부 사용자 피드백에 기반한 빠른 반복으로 시작했습니다. 이후 우리는 eval을 추가했는데—처음에는 간결성(concision)과 파일 편집 같은 좁은 영역에 대해, 그다음에는 과도한 엔지니어링(over‑engineering) 같은 더 복잡한 행동에 대해—이 eval들은 문제를 식별하고, 개선을 안내하며, 연구‑제품 협업을 집중시키는 데 도움을 주었습니다. 프로덕션 모니터링, A/B 테스트, 사용자 연구 등과 결합하면, eval은 Claude Code가 확장되면서 지속적 개선을 위한 신호를 제공합니다.

에이전트의 수명 주기 어느 단계에서든 eval 작성은 유용합니다. 초기에는 eval이 제품 팀이 에이전트의 성공이 무엇을 의미하는지 명확히 정의하도록 강제하고, 이후에는 일관된 품질 기준을 유지하도록 돕습니다.

Descript의 에이전트는 사용자가 영상을 편집하도록 돕습니다. 그래서 그들은 성공적인 편집 워크플로의 세 차원—망가뜨리지 말 것, 내가 요청한 대로 할 것, 그리고 잘할 것—에 기반해 eval을 구축했습니다. 그들은 수동 채점에서 제품 팀이 정의한 기준과 주기적 인간 보정을 갖춘 LLM 채점기로 발전했고, 지금은 품질 벤치마킹과 회귀 테스트를 위해 두 개의 별도 스위트를 정기적으로 실행합니다. Bolt AI 팀은 이미 널리 사용되는 에이전트를 가진 뒤 비교적 늦게 eval을 구축하기 시작했습니다. 3개월 만에 그들은 에이전트를 실행하고 출력을 정적 분석으로 채점하며, 앱을 테스트하기 위해 브라우저 에이전트를 사용하고, 지침 준수 같은 행동을 위해 LLM 판정을 사용하는 eval 시스템을 구축했습니다.

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

Evals는 또한 새로운 모델을 얼마나 빨리 채택할 수 있는지에 영향을 줍니다. 더 강력한 모델이 출시되면, eval이 없는 팀은 수주 동안 테스트해야 하지만, eval이 있는 팀은 모델의 강점을 빠르게 파악하고 프롬프트를 조정하며 며칠 내에 업그레이드할 수 있습니다.

일단 eval이 존재하면, 기준선과 회귀 테스트를 ‘공짜로’ 얻게 됩니다: 지연(latency), 토큰 사용량, 작업당 비용, 오류율을 정적 작업 집합에서 추적할 수 있습니다. Eval은 제품과 연구 팀 간의 최고 대역폭 커뮤니케이션 채널이 될 수도 있습니다. 연구자가 최적화할 수 있는 지표를 정의합니다. 분명히 eval은 회귀와 개선 추적을 넘어, 광범위한 이점을 가집니다. 초기 비용은 눈에 보이지만, 이익은 나중에 누적되기 때문에 그 가치를 놓치기 쉽습니다.

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

오늘날 규모로 배포되는 여러 유형의 에이전트를 보게 됩니다. 코딩 에이전트, 리서치 에이전트, 컴퓨터 사용 에이전트, 대화형 에이전트 등입니다.

각 유형은 매우 다양한 산업에 배포될 수 있지만, 유사한 기법으로 평가할 수 있습니다. 평가를 처음부터 새로 발명할 필요는 없습니다. 아래 섹션들은 여러 에이전트 유형에 대해 검증된 기법을 설명합니다. 이러한 방법들을 토대로 삼고, 도메인에 맞게 확장하십시오.

에이전트용 채점기 유형

에이전트 평가에는 일반적으로 세 가지 유형의 채점기가 결합됩니다: 코드 기반, 모델 기반, 인간. 각 채점기는 전사 또는 결과의 일부를 평가합니다. 효과적인 평가 설계의 핵심 요소는 작업에 적합한 채점기를 선택하는 것입니다.

코드 기반 채점기

모델 기반 채점기

인간 채점기

각 작업에서 채점은 가중 합(결합된 채점기 점수가 임계값을 넘어야 함), 이진(모든 채점기가 통과해야 함), 또는 하이브리드일 수 있습니다.

능력 평가 vs. 회귀 평가

능력(capability) 또는 “품질” eval은 “이 에이전트가 잘할 수 있는 것은 무엇인가?”를 묻습니다. 이는 낮은 합격률로 시작해야 하며, 에이전트가 어려워하는 작업을 목표로 삼아 팀에게 오를 언덕을 제공합니다.

회귀(regression) eval은 “에이전트가 이전에 처리하던 모든 작업을 여전히 처리하는가?”를 묻고, 거의 100%의 합격률을 가져야 합니다. 이는 후퇴를 방지하며, 점수 하락은 무언가가 망가졌고 개선이 필요함을 신호합니다. 팀이 능력 eval에서 언덕을 오를 때, 다른 곳에서 문제가 생기지 않도록 회귀 eval도 함께 실행하는 것이 중요합니다.

에이전트가 출시되고 최적화된 후에는, 높은 합격률의 능력 eval이 졸업하여 드리프트를 포착하기 위해 지속적으로 실행되는 회귀 스위트가 될 수 있습니다. 한때 “이걸 할 수 있는가?”를 측정하던 작업이, 그 후에는 “이걸 신뢰성 있게 계속 할 수 있는가?”를 측정합니다.

코딩 에이전트 평가하기

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

결정적(Deterministic) 채점기는 소프트웨어가 일반적으로 평가가 간단하다는 점에서 코딩 에이전트에 적합합니다: 코드가 실행되는가, 테스트를 통과하는가? 널리 사용되는 두 코딩 에이전트 벤치마크, SWE-bench Verified와 Terminal-Bench는 이 접근을 따릅니다. SWE‑bench Verified는 인기 있는 Python 리포지토리의 GitHub 이슈를 에이전트에 제공하고, 테스트 스위트를 실행하여 해결책을 채점합니다; 해결책은 기존 테스트를 깨뜨리지 않고 실패하는 테스트를 고칠 때에만 통과합니다. LLM은 단 1년 만에 이 eval에서 40%에서 80% 이하로 발전했습니다. Terminal‑Bench는 다른 경로를 택합니다: Linux 커널을 소스에서 빌드하거나 ML 모델을 훈련하는 등 end‑to‑end 기술 작업을 테스트합니다.

코딩 작업의 핵심 결과를 검증하는 합격/불합격 테스트 집합을 갖춘 뒤에는, 전사(transcript)도 함께 채점하는 것이 종종 유용합니다. 예를 들어, 휴리스틱 기반 코드 품질 규칙은 테스트 통과 이상의 기준으로 생성된 코드를 평가할 수 있으며, 명확한 루브릭을 갖춘 모델 기반 채점기는 에이전트가 도구를 어떻게 호출하고 사용자와 어떻게 상호작용하는지 같은 행동을 평가할 수 있습니다.

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

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

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 루브릭에 주로 의존하며, 필요할 때만 추가 채점기와 메트릭을 보강합니다.

대화형 에이전트 평가하기

대화형 에이전트는 지원, 영업, 코칭 등 도메인에서 사용자와 상호작용합니다. 전통적인 챗봇과 달리, 상태를 유지하고, 도구를 사용하며, 대화 도중에 행동을 수행합니다. 코딩 및 리서치 에이전트도 사용자와의 다수 턴 상호작용을 포함할 수 있지만, 대화형 에이전트는 상호작용 자체의 품질이 평가 대상이라는 점이 뚜렷한 과제입니다. 대화형 에이전트에 대한 효과적인 eval은 일반적으로 검증 가능한 최종 상태 결과와, 작업 완료와 상호작용 품질을 모두 포착하는 루브릭에 의존합니다. 대부분의 다른 eval과 달리, 사용자 역할을 시뮬레이트하기 위해 두 번째 LLM이 필요합니다. 우리는 alignment auditing agents에서 이 접근을 사용하여, 확장된 적대적 대화를 통해 모델을 스트레스 테스트합니다.

대화형 에이전트의 성공은 다차원적일 수 있습니다: 티켓이 해결되었는가(상태 점검), 10턴 이내에 끝냈는가(transcript 제약), 어조가 적절했는가(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

코딩 에이전트 예시와 마찬가지로, 이 작업은 예시 목적상 여러 채점기 유형을 보여줍니다. 실무에서는, 대화형 에이전트 평가가 대개 모델 기반 채점기를 사용해, 커뮤니케이션 품질과 목표 달성을 모두 평가합니다. 많은 작업—질문에 답하기 같은—은 “정답”이 여러 개일 수 있기 때문입니다.

리서치 에이전트 평가하기

리서치 에이전트는 정보를 수집, 종합, 분석하고, 답변이나 보고서 같은 출력을 생성합니다. 단위 테스트가 이진 합격/불합격 신호를 제공하는 코딩과 달리, 리서치 품질은 작업에 상대적일 수밖에 없습니다. “포괄적”, “출처가 잘 마련됨”, “정확함”이 무엇을 의미하는지는 맥락에 따라 달라집니다: 시장 조사, 인수 실사, 과학 보고서 등은 각각 다른 기준을 요구합니다.

리서치 eval은 고유한 도전을 마주합니다: 전문가들도 종합이 포괄적인지 여부에 이견을 보일 수 있고, 참조 콘텐츠가 지속적으로 변함에 따라 그라운드 트루스가 이동하며, 더 길고 개방형 출력은 오류 여지가 더 큽니다. 예를 들어 BrowseComp 같은 벤치마크는, AI 에이전트가 열린 웹의 건초더미 속 바늘을 찾을 수 있는지 테스트합니다—검증은 쉽지만, 해결은 어렵도록 설계된 질문입니다.

리서치 에이전트 eval을 구축하는 한 전략은 채점기 유형을 결합하는 것입니다. 근거성(groundedness) 체크는 주장들이 검색된 출처로 뒷받침되는지 검증하고, 커버리지(coverage) 체크는 좋은 답변이 반드시 포함해야 하는 핵심 사실을 정의하며, 출처 품질 체크는 참조된 출처가 권위 있는지(단지 처음 검색된 것이 아닌지)를 확인합니다. “기업 X의 Q3 매출은 얼마였는가?” 같은 객관적 정답이 있는 작업에서는 exact match가 작동합니다. LLM은 근거 없는 주장과 커버리지의 간극을 표시할 수 있을 뿐 아니라, 개방형 종합의 응집성과 완결성을 검증할 수 있습니다.

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

컴퓨터 사용 에이전트

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

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

에이전트 평가에서 비결정성을 고려하는 방법

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

두 메트릭이 이러한 뉘앙스를 포착하는 데 도움이 됩니다:

pass@k는 k번의 시도에서 에이전트가 최소 한 번은 올바른 해결책을 얻을 가능성을 측정합니다. k가 증가하면, pass@k 점수는 상승합니다—‘골문 앞 기회’가 많을수록 최소 1회 성공할 확률이 높아지기 때문입니다. pass@1이 50%라는 것은 모델이 첫 시도에서 eval의 절반 작업에 성공한다는 뜻입니다. 코딩에서는, 우리는 종종 에이전트가 첫 시도에 해결책을 찾는지—pass@1—에 가장 관심이 있습니다. 다른 경우에는, 여러 해결책을 제안하는 일이 유효하며 그중 하나가 작동하면 됩니다.

pass^k는 k번의 모든 트라이얼이 성공할 확률을 측정합니다. k가 증가하면, pass^k는 하락합니다. 더 많은 트라이얼 모두에서 일관된 성공을 요구하는 것은 더 어려운 기준이기 때문입니다. 에이전트의 트라이얼당 성공률이 75%이고 3번의 트라이얼을 실행한다면, 세 번 모두 통과할 확률은 (0.75)³ ≈ 42%입니다. 이 메트릭은 특히 사용자 대면 에이전트에서 중요하며, 사용자들은 매번 신뢰할 수 있는 행동을 기대합니다.

시도 횟수가 증가할수록 pass@k와 pass^k는 서로 달라집니다. k=1에서는 둘이 동일하며(둘 다 트라이얼당 성공률과 같습니다), k=10이 되면 상반된 양상을 보입니다: pass@k는 100%에 가까워지는 반면 pass^k는 0%로 떨어집니다.

두 메트릭은 모두 유용하며, 어떤 것을 사용할지는 제품 요구사항에 달려 있습니다. 한 번의 성공이 중요할 때에는 pass@k를, 일관성이 필수인 에이전트에는 pass^k를 사용합니다.

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

zero에서 one으로: 훌륭한 에이전트 eval을 위한 로드맵

이 섹션은 신뢰할 수 있는 eval이 전혀 없는 상태에서 시작해 구축하는 데 필요한 실무적이고 현장에서 검증된 조언을 제시합니다. 이를 eval 주도 에이전트 개발을 위한 로드맵으로 생각해 주십시오: 성공을 일찍 정의하고, 명확하게 측정하며, 지속적으로 반복합니다.

초기 eval 데이터셋을 위한 작업 수집

Step 0. 일찍 시작하기

팀들이 수백 개의 작업이 필요하다고 생각해 eval 구축을 미루는 경우를 봅니다. 실제로는, 실제 실패 사례에서 뽑은 20–50개의 간단한 작업으로 훌륭한 출발을 할 수 있습니다. 초기 에이전트 개발 단계에서는 시스템에 대한 각 변경이 대개 명확하고 눈에 띄는 영향을 주며, 이러한 큰 효과 크기 때문에 작은 표본 크기로도 충분합니다. 더 성숙한 에이전트는 더 작은 효과를 탐지하기 위해 더 크고 어려운 eval이 필요할 수 있지만, 초반에는 80/20 접근이 최선입니다. 기다릴수록 eval 구축은 더 어려워집니다. 초기에는 제품 요구사항이 자연스럽게 테스트 케이스로 번역됩니다. 너무 늦게 시작하면, 운영 중인 시스템에서 성공 기준을 역으로 추출해야 합니다.

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

개발 중에 수행하는 수동 점검—각 릴리스 전에 확인하는 행동과 최종 사용자가 자주 시도하는 일반 작업—부터 시작하십시오. 이미 프로덕션이라면 버그 트래커와 지원 큐를 확인하세요. 사용자 보고 실패를 테스트 케이스로 변환하면 스위트가 실제 사용을 반영하게 되며, 사용자 영향도에 따라 우선순위를 매기면 중요한 곳에 노력을 투자할 수 있습니다.

Step 2. 기준 해법이 있는 명확한(비모호한) 작업 작성

작업 품질을 제대로 잡는 일은 생각보다 어렵습니다. 좋은 작업이란 두 명의 도메인 전문가가 독립적으로 동일한 합격/불합격 판정을 내릴 수 있는 작업입니다. 그들이 직접 작업을 통과할 수 있습니까? 아니라면 작업을 다듬어야 합니다. 작업 명세의 모호함은 메트릭의 노이즈가 됩니다. 모델 기반 채점기의 기준에도 동일하게 적용됩니다: 모호한 루브릭은 일관성 없는 판단을 낳습니다.

각 작업은 지시를 올바르게 따르는 에이전트가 통과할 수 있어야 합니다. 이는 미묘할 수 있습니다. 예를 들어, Terminal‑Bench를 감사한 결과, 작업이 에이전트에게 스크립트를 작성하라고 요청하지만 파일 경로를 지정하지 않고, 테스트는 해당 스크립트의 특정 파일 경로를 가정하는 경우, 에이전트는 잘못이 없음에도 실패할 수 있음이 드러났습니다. 채점기가 확인하는 모든 사항은 작업 설명에서 명확해야 하며, 에이전트는 모호한 명세 때문에 실패해서는 안 됩니다. 프런티어 모델에서 다수의 트라이얼에 걸친 0% 합격률(즉, 0% pass@100)은 대개 에이전트가 무능해서가 아니라 작업이 잘못되었음을 알리는 신호이며, 작업 명세와 채점기를 재확인해야 함을 뜻합니다. 각 작업에 대해 기준 해법(reference solution)—모든 채점기를 통과하는, 작동이 확인된 출력—을 만들어 두는 것이 유용합니다. 이는 작업이 해결 가능함을 입증하고 채점기가 올바르게 구성되었음을 검증합니다.

Step 3. 균형 잡힌 문제 집합 구축

어떤 행동이 일어나야 하는 경우와 일어나지 말아야 하는 경우를 모두 테스트하십시오. 한쪽으로 치우친 eval은 한쪽으로 치우친 최적화를 만듭니다. 예를 들어, 에이전트가 검색해야 할 때만 검색하는지를 테스트하기만 하면, 거의 모든 것을 검색하는 에이전트로 귀결될 수 있습니다. 클래스 불균형 eval을 피하려고 노력하십시오. 우리는 Claude.ai의 웹 검색 eval을 만들면서 이를 직접 배웠습니다. 도전 과제는, 모델이 검색하면 안 되는 상황에서는 검색을 막으면서, 적절할 때 광범위한 리서치를 수행할 수 있는 능력을 보존하는 것이었습니다. 팀은 양 방향을 모두 포괄하는 eval을 구축했습니다: 모델이 검색해야 하는 질의(날씨 찾기처럼)와 모델이 기존 지식으로 답해야 하는 질의(“애플을 누가 창업했나요?”처럼). 해야 할 때 검색하지 않는 언더트리거링과, 하지 말아야 할 때 검색하는 오버트리거링 사이의 올바른 균형을 맞추는 일은 어려웠고, 프롬프트와 eval 모두에 대한 여러 차례의 개선이 필요했습니다. 더 많은 예시 문제가 생길수록, 커버리지를 개선하기 위해 eval을 계속 추가했습니다.

eval 하니스와 채점기 설계

Step 4. 안정적인 환경을 갖춘 견고한 eval 하니스 구축

eval의 에이전트가 프로덕션에서 사용하는 에이전트와 대략 동일하게 작동하고, 환경 자체가 추가적인 노이즈를 유발하지 않도록 하는 것이 필수입니다. 각 트라이얼은 청정 환경에서 시작해 “격리”되어야 합니다. 실행 간에 불필요한 공유 상태(남은 파일, 캐시된 데이터, 리소스 고갈)는 인프라 불안정으로 인한 상관 실패를 일으켜, 에이전트 성능이 아닌 환경 탓으로 실패하게 만듭니다. 공유 상태는 성능을 인위적으로 부풀리기도 합니다. 예를 들어, 일부 내부 eval에서 Claude가 이전 트라이얼의 git 히스토리를 살펴봄으로써 몇몇 작업에서 부당한 이점을 얻는 것을 관찰했습니다. 동일한 환경 제한(예: 제한된 CPU 메모리) 때문에 여러 개별 트라이얼이 실패한다면, 이 트라이얼들은 동일한 요인에 영향을 받으므로 독립적이지 않으며, eval 결과는 에이전트 성능을 측정하는 데 신뢰할 수 없게 됩니다.

Step 5. 채점기를 신중하게 설계

앞서 논의했듯, 훌륭한 eval 설계는 에이전트와 작업에 가장 적합한 채점기를 선택하는 일을 포함합니다. 가능한 곳에서는 결정적 채점기를, 필요하거나 추가 유연성이 요구되는 곳에서는 LLM 채점기를 선택하고, 추가 검증을 위해 인간 채점기를 신중하게 사용하길 권합니다.

도구 호출 순서 같은 매우 구체적인 절차를 에이전트가 따랐는지 확인하고 싶은 본능이 흔합니다. 우리는 이 접근이 지나치게 경직되어 테스트를 과도하게 취약하게 만든다는 것을 발견했습니다. 에이전트가 eval 설계자가 예상하지 못한 유효한 접근법을 자주 찾기 때문입니다. 창의성을 불필요하게 처벌하지 않기 위해, 에이전트가 생성한 산출물을 평가하고 그가 걸어간 경로는 평가하지 않는 편이 좋습니다.

구성 요소가 여러 개인 작업에는 부분 점수를 도입하십시오. 문제를 올바르게 식별하고 고객을 검증했지만 환불 처리를 실패한 지원 에이전트는, 즉시 실패한 에이전트보다 의미 있게 더 낫습니다. 결과에 이러한 성공의 연속체를 반영하는 것이 중요합니다.

모델 채점은 정확성을 검증하기 위해 세심한 반복을 필요로 하는 경우가 많습니다. LLM‑as‑judge 채점기는 인간 전문가와 긴밀히 보정하여, 인간 채점과 모델 채점 간의 편차가 거의 없다는 확신을 얻어야 합니다. 환각을 피하기 위해, LLM에게 “정보가 충분하지 않을 때 Unknown을 반환하라”는 탈출로를 제공하는 지침을 부여하세요. 또한 과업의 각 차원을 채점하기 위한 명확하고 구조화된 루브릭을 만들고, 모든 차원을 하나의 LLM‑as‑judge가 채점하게 하기보다 각 차원을 분리된 LLM‑as‑judge로 채점하도록 하는 것이 도움이 될 수 있습니다. 시스템이 견고해지면, 인간 검토는 가끔만으로도 충분합니다.

일부 평가에는 미묘한 실패 모드가 있어, 에이전트 성능이 좋아도 낮은 점수를 야기합니다. 채점 버그, 에이전트 하니스 제약, 모호함 때문에 에이전트가 작업을 해결하지 못하는 경우입니다. 세련된 팀도 이러한 문제를 놓칠 수 있습니다. 예를 들어, Opus 4.5는 처음에 CORE‑Bench에서 42%를 기록했는데, 한 Anthropic 연구자가 여러 문제를 발견했습니다: “96.124991…”을 기대하면서 “96.12”를 벌점 처리하는 경직된 채점, 모호한 작업 명세, 정확히 재현할 수 없는 확률적 작업 등입니다. 버그를 고치고 덜 제약적인 스캐폴드를 사용한 후, Opus 4.5의 점수는 95%로 뛰었습니다. 유사하게, METR는 그들의 타임 호라이즌 벤치마크에서 여러 오구성된 작업을 발견했는데, 에이전트에게 명시된 점수 임계값에 맞추어 최적화하라고 요청하면서, 채점은 그 임계값을 초과할 것을 요구했습니다. 이는 지시를 따른 Claude 같은 모델을 벌점하고, 명시된 목표를 무시한 모델이 더 좋은 점수를 받게 만들었습니다. 작업과 채점기를 면밀히 재확인하면 이러한 문제를 피할 수 있습니다.

채점기가 우회나 해킹에 강하도록 만드십시오. 에이전트가 eval을 쉽게 “속일” 수 있어서는 안 됩니다. 작업과 채점기는, 통과하려면 의도치 않은 허점을 악용하는 것이 아니라 실제로 문제를 해결해야 하도록 설계되어야 합니다.

장기적으로 eval을 유지하고 활용하기

Step 6. 전사(transcript)를 확인하기

여러 트라이얼의 전사와 채점 결과를 읽지 않으면 채점기가 잘 작동하는지 알 수 없습니다. Anthropic에서는 eval 전사를 열람하는 도구에 투자했고, 정기적으로 시간을 들여 이를 읽습니다. 작업이 실패할 때, 전사는 에이전트가 실제로 실수를 했는지, 아니면 채점기가 유효한 해결책을 거부했는지를 알려줍니다. 또한 에이전트와 eval의 행동에 대한 핵심 세부 사항을 자주 드러냅니다.

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

Step 7. 능력 eval 포화(saturation) 모니터링

합격률 100%의 eval은 회귀를 추적하지만 개선 신호는 제공하지 않습니다. 능력 eval 포화는 에이전트가 해결 가능한 모든 작업을 통과해 더 이상 개선 여지가 없을 때 발생합니다. 예를 들어, SWE‑Bench Verified 점수는 올해 30%에서 시작했고, 현재 프런티어 모델은 80% 이상으로 포화에 근접하고 있습니다. Eval이 포화에 접근할수록, 가장 어려운 작업만 남으므로 진전은 느려집니다. 이는 큰 능력 향상이 점수의 작은 증가로 보이게 만들어 결과를 기만적으로 만들 수 있습니다. 예컨대 코드 리뷰 스타트업 Qodo는 그들의 원샷 코딩 eval이 더 길고 복잡한 작업에서의 향상을 포착하지 못했기 때문에, 처음에는 Opus 4.5에 감명받지 못했습니다. 이에 대응하여 그들은 새로운 에이전틱 eval 프레임워크를 개발해, 진전을 훨씬 더 명확하게 보여주었습니다.

원칙적으로, 누군가 eval의 세부 사항을 파고들고 몇 개의 전사를 읽기 전까지는 eval 점수를 그대로 받아들이지 않습니다. 채점이 불공정하거나, 작업이 모호하거나, 유효한 해결책이 벌점을 받거나, 하니스가 모델을 제약한다면, eval을 수정해야 합니다.

Step 8. 개방적 기여와 유지보수를 통해 평가 스위트를 장기적으로 건강하게 유지

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

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

AI 제품 팀에게, 평가를 소유하고 반복하는 일은 단위 테스트를 유지관리하는 것만큼 일상적이어야 합니다. 팀은 초기 테스트에서는 “작동”하지만, 잘 설계된 eval이라면 초기에 드러났을 불명확한 기대를 만족하지 못하는 AI 기능에 수주를 낭비할 수 있습니다. Eval 작업을 정의하는 것은 제품 요구사항이 충분히 구체적인지 스트레스 테스트하는 가장 좋은 방법 중 하나입니다.

우리는 eval‑주도 개발을 권장합니다: 에이전트가 기능을 수행하기 전에 계획된 능력을 정의하는 eval을 만들고, 에이전트가 잘 수행할 때까지 반복하십시오. 내부적으로 우리는 종종 오늘 “충분히 잘” 작동하는 기능을 구축하지만, 몇 달 후 모델이 할 수 있는 것에 대한 베팅이기도 합니다. 낮은 합격률에서 시작하는 능력 eval은 이를 가시화합니다. 새 모델이 출시되면, 스위트를 실행해 어떤 베팅이 성공했는지 빠르게 드러냅니다.

제품 요구사항과 사용자에 가장 가까운 사람들일수록 성공을 정의하기에 가장 적합합니다. 현재 모델 능력으로, 제품 관리자, 고객 성공 매니저, 영업 담당자도 Claude Code를 사용해 PR로 eval 작업을 기여할 수 있습니다—그렇게 하도록 하십시오! 더 좋게는 적극적으로 가능하게 하십시오.

에이전트를 총체적으로 이해하기 위한 다른 방법과의 결합

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

AI 에이전트 성능을 이해하는 접근법 개요

이러한 방법들은 에이전트 개발의 서로 다른 단계에 대응합니다. 자동화된 evals는 출시 전과 CI/CD에서 특히 유용하며, 각 에이전트 변경과 모델 업그레이드 시 품질 문제에 대한 1차 방어선으로 작동합니다. 프로덕션 모니터링은 출시 후 분포 드리프트와 예상치 못한 실제 실패를 탐지합니다. A/B 테스트는 충분한 트래픽이 생기면 중요한 변경을 검증합니다. 사용자 피드백과 전사 검토는 지속적으로 격차를 메우는 관행입니다—피드백을 지속적으로 분류하고, 매주 샘플 전사를 읽으며, 필요에 따라 더 깊게 파고듭니다. 체계적 인간 연구는 LLM 채점기 보정이나 인간 합의가 기준이 되는 주관적 출력 평가에 한정하십시오.

안전 공학의 Swiss Cheese Model처럼, 단일 평가 층은 모든 문제를 잡지 못합니다. 여러 방법을 결합하면, 한 층을 통과한 실패가 다른 층에서 걸러집니다. 가장 효과적인 팀은 이러한 방법들을 결합합니다—빠른 반복을 위한 자동화된 evals, 그라운드 트루스를 위한 프로덕션 모니터링, 보정을 위한 주기적 인간 검토.

결론

eval 없이 일하는 팀은 반응적 루프에 빠집니다—하나의 실패를 고치다 다른 실패를 만들고, 실제 회귀와 노이즈를 구분하지 못합니다. 일찍 투자한 팀은 반대의 결과를 봅니다: 실패가 테스트 케이스가 되고, 테스트 케이스가 회귀를 방지하며, 메트릭이 추측을 대체해 개발이 가속됩니다. Eval은 팀 전체에게 올라야 할 명확한 언덕을 제시하여 “에이전트가 나빠진 것 같다”를 실천 가능한 것으로 바꿉니다. 가치는 누적되지만, eval을 부차적 요소가 아니라 핵심 구성 요소로 대할 때에만 누적됩니다.

패턴은 에이전트 유형에 따라 달라지지만, 여기서 설명한 기본 원칙은 일정합니다. 일찍 시작하고 완벽한 스위트를 기다리지 마십시오. 실제 실패에서 현실적인 작업을 수집하십시오. 비모호하고 견고한 성공 기준을 정의하십시오. 채점기를 신중하게 설계하고 여러 유형을 결합하십시오. 문제가 모델에게 충분히 어려운지 확인하십시오. 신호‑대‑노이즈 비율을 높이도록 평가를 반복하십시오. 전사를 읽으십시오!

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

Appendix: Eval frameworks

여러 오픈 소스 및 상용 프레임워크가, 인프라를 처음부터 구축하지 않고도 에이전트 평가를 구현하도록 팀을 도울 수 있습니다. 올바른 선택은 에이전트 유형, 기존 스택, 오프라인 평가와 프로덕션 가시성 중 어느 것을(또는 둘 다를) 필요로 하는지에 따라 달라집니다.

Harbor는 컨테이너화된 환경에서 에이전트를 실행하도록 설계되었으며, 클라우드 제공업체 전반에서 규모 있게 트라이얼을 실행하는 인프라와, 작업 및 채점기를 정의하는 표준화된 포맷을 제공합니다. Terminal‑Bench 2.0 같은 인기 벤치마크는 Harbor 레지스트리를 통해 제공되어, 맞춤 eval 스위트와 함께 기성 벤치마크를 손쉽게 실행할 수 있습니다.

Promptfoo는 선언적 YAML 구성에 기반한 프롬프트 테스트에 초점을 맞춘, 가볍고 유연한 오픈 소스 프레임워크이며, 문자열 일치에서 LLM‑as‑judge 루브릭에 이르는 다양한 단언 유형을 지원합니다. 우리의 많은 제품 eval에서 Promptfoo의 변형을 사용합니다.

Braintrust는 오프라인 평가와 프로덕션 가시성, 실험 추적을 결합한 플랫폼으로, 개발 중 반복과 프로덕션에서 품질 모니터링이 모두 필요한 팀에 유용합니다. 해당 autoevals⁠ 라이브러리는 사실성, 적합성 등 일반적인 차원을 위한 사전 구축 채점기를 포함합니다.

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

많은 팀이 여러 도구를 결합하거나, 자체 eval 프레임워크를 만들거나, 출발점으로 단순한 평가 스크립트만 사용합니다. 프레임워크는 진행을 가속하고 표준화하는 데 가치 있을 수 있지만, 결국 프레임워크의 효용은 그 위에서 실행하는 eval 작업의 질에 달려 있음을 확인했습니다. 워크플로에 맞는 프레임워크를 재빨리 선택하고, 고품질 테스트 케이스와 채점기를 반복해 다듬는 데 에너지를 투자하는 것이 대개 최선입니다.