에이전트 eval 함수 해부 글 짚어보기 (3) — grader 설계와 에이전트 유형별 전략

들어가며: "어떻게 채점하는가"

eval을 만들기로 결정했다. 태스크를 정의했고, 데이터셋을 구성했다. 그러면 다음에 부딪히는 질문은 정확히 하나다. 에이전트의 출력을 어떻게 채점하는가?

단위 테스트처럼 assert output == expected로 끝나면 좋겠지만, 에이전트의 출력은 코드일 수도, 대화일 수도, 리서치 보고서일 수도, 스크린샷 위의 마우스 클릭일 수도 있다. 채점 방법은 출력의 성격에 따라 달라져야 한다.

이 편에서는 두 가지를 다룬다.

1. grader의 세 가지 유형 — code-based, model-based, human
2. 에이전트 유형별 eval 전략 — 코딩, 대화형, 리서치, 컴퓨터 사용

원문이 제시하는 YAML 예시를 그대로 포함하고, 각 필드가 어떤 역할을 하는지 한국어로 해설한다.

1. 세 가지 grader 유형

원문은 grader를 세 유형으로 분류한다. code-based, model-based, human. 각각의 방법론, 강점, 약점을 테이블로 정리하면 다음과 같다.

1-1. Code-based graders

코드 기반 grader의 핵심 가치는 재현성이다. 같은 입력에 대해 항상 같은 점수가 나온다. 정규표현식으로 특정 패턴이 포함되어 있는지, 테스트 스위트가 통과하는지, 린터가 경고를 뱉지 않는지 — 이런 검증은 모델 호출 없이 밀리초 단위로 끝난다.

하지만 약점도 명확하다. 에이전트가 user_id를 userId로 리턴했을 때, exact match grader는 실패를 선언한다. 정답은 맞는데 형식이 다른 것뿐인 경우에도 brittle하게 깨진다. 이 문제가 반복되면 fuzzy match나 regex로 완화하거나, model-based grader를 병행하게 된다.

1-2. Model-based graders

model-based grader는 LLM에게 "이 출력이 이 루브릭 기준으로 몇 점인가?"를 묻는 방식이다. 코드 기반으로 검증할 수 없는 영역 — 예를 들어 "고객에게 공감을 표현했는가", "보고서가 논리적으로 일관성이 있는가" — 에서 위력을 발휘한다.

대표적인 방법론을 좀 더 풀어보자.

• Rubric-based scoring: 채점 기준을 자연어로 정의하고, LLM에게 그 기준에 따라 점수를 매기게 한다. "1점: 질문에 전혀 답하지 않음, 3점: 부분적으로 답함, 5점: 완전하고 정확하게 답함" 같은 식이다.
• Pairwise comparison: 두 개의 출력을 나란히 놓고 "어느 쪽이 더 나은가?"를 판단한다. 절대 점수보다 상대 비교가 더 안정적인 경우가 많다.
• Multi-judge consensus: 여러 모델(또는 같은 모델의 여러 호출)이 독립적으로 채점한 뒤, 합의를 도출한다. 단일 판사의 편향을 완화한다.

약점은 비결정성이다. 같은 출력을 같은 모델에게 두 번 채점시키면 다른 점수가 나올 수 있다. 이 문제는 다음 편(비결정성 처리)에서 깊이 다룬다.

1-3. Human graders

사람 grader는 가장 신뢰할 수 있지만 가장 확장하기 어려운 방법이다. 실무에서의 역할은 보정 기준이다. model-based grader가 사람과 얼마나 일치하는지 측정하고, 괴리가 크면 루브릭을 수정한다. 모든 케이스에 사람을 투입하는 것이 아니라, spot-check sampling으로 전체의 일부만 검증하고 나머지는 보정된 model-based grader에 맡기는 것이 현실적인 운영 패턴이다.

1-4. 세 유형 한눈에 비교

실무에서는 하나만 쓰는 경우가 드물다. 코드 기반으로 "테스트가 통과하는가"를 먼저 거르고, model-based로 "코드 품질이 괜찮은가"를 평가하고, 주기적으로 사람이 spot-check하는 계층형 구조가 일반적이다.

2. Scoring 방식: weighted, binary, hybrid

여러 grader를 조합할 때 최종 점수를 어떻게 결정하는가? 원문은 세 가지 방식을 제시한다.

• Weighted: 각 grader의 점수에 가중치를 곱해서 합산한다. 합산 점수가 임계값을 넘으면 통과. 예를 들어 "테스트 통과 60% + 코드 품질 30% + 도구 사용 적절성 10%"처럼 구성할 수 있다.
• Binary: 모든 grader가 통과해야 최종 통과. 하나라도 실패하면 전체 실패. 보안 검증처럼 타협할 수 없는 조건에 적합하다.
• Hybrid: weighted와 binary를 혼합한다. 예를 들어 "보안 검사는 반드시 통과(binary) + 나머지 기준은 가중 합산(weighted)으로 80점 이상"처럼 구성한다.

실무 팁을 하나 보태자면, 처음에는 binary로 시작하는 것이 디버깅하기 쉽다. "왜 실패했는가?"에 대한 답이 "이 grader가 실패했기 때문"으로 명확하게 떨어진다. weighted는 "73점이 나왔는데 왜 80점이 안 되는가?"를 추적하기가 상대적으로 어렵다. grader가 안정화된 뒤에 weighted로 전환하는 것이 자연스러운 경로다.

3. Capability eval vs Regression eval

grader를 어떻게 구성하느냐 못지않게 중요한 것이 eval을 어떤 목적으로 운영하느냐다. 원문은 eval을 두 가지로 나눈다.

3-1. Capability eval: "이 에이전트가 뭘 잘하는가?"

에이전트가 아직 잘 못하는 태스크를 타겟으로 한다. 처음에는 pass rate가 낮다. 팀에게 올라갈 언덕을 준다.

예를 들어, 코딩 에이전트가 멀티 파일 리팩토링을 10%만 성공한다고 하자. 이 10%짜리 eval이 capability eval이다. 프롬프트를 바꾸고, 도구를 추가하고, 파이프라인을 개선하면서 pass rate가 올라가는 것을 관찰한다.

3-2. Regression eval: "이전에 되던 것이 여전히 되는가?"

거의 100% pass rate를 유지해야 한다. 점수가 떨어지면 무언가가 깨졌다는 신호다.

배포 전 회귀 테스트와 같은 역할이다. "이번 프롬프트 변경이 기존 기능을 망가뜨리지 않았는가?"를 확인한다.

3-3. 졸업(Graduation)

여기서 원문이 제시하는 핵심 개념이 졸업이다.

Capability evals with high pass rates "graduate" to regression suite.

pass rate가 충분히 높아진 capability eval은 regression suite로 이동한다. "이걸 할 수 있는가?(Can we do this at all?)"라는 질문이 "이걸 여전히 안정적으로 할 수 있는가?(Can we still do this reliably?)"로 바뀌는 순간이다.

이 졸업 메커니즘이 왜 중요한가. capability eval만 계속 돌리면 "올라갈 언덕"에만 집중하게 되고, 이미 정복한 영역이 무너지는 것을 놓친다. regression eval만 돌리면 현재 수준을 유지할 뿐 새로운 능력을 개발하는 방향성이 없다. 두 eval을 같이 돌리되, capability에서 regression으로 졸업시키는 흐름이 eval 시스템의 생애주기를 만든다.

4. 코딩 에이전트 eval

여기서부터 에이전트 유형별 eval 전략이다. 첫 번째는 코딩 에이전트.

4-1. 특성

코딩 에이전트는 코드를 작성하고, 테스트하고, 디버깅하고, 코드베이스를 탐색하고, 사람 개발자처럼 명령어를 실행한다. 결정론적 grader가 자연스럽게 들어맞는다 — 코드가 실행되는가? 테스트가 통과하는가?

4-2. 벤치마크

SWE-bench Verified: 인기 있는 Python 레포의 GitHub 이슈를 모아놓은 벤치마크다. 테스트 스위트를 실행해서 채점한다. 실패하는 테스트를 고치되 기존 테스트를 깨뜨리지 않아야 한다. 1년 만에 40%에서 80% 이상으로 진척되었다.

Terminal-Bench: 엔드투엔드 기술 태스크를 다룬다. Linux 커널 빌드, ML 모델 훈련 같은 복합적인 작업이다.

4-3. 채점 전략

pass/fail 결과 테스트를 먼저 돌린 뒤, 트랜스크립트도 채점한다. 휴리스틱 기반 코드 품질 규칙과 model-based grader로 도구 호출 행동을 평가한다.

원문은 "실전에서는 보통 unit test + LLM rubric이면 충분하다"고 덧붙인다. 하지만 전체 범위를 보여주기 위해 아래 YAML 예시는 모든 grader 타입을 포함한다.

4-4. 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]

4-5. 필드별 해설

graders 섹션 — 5개의 grader가 등록되어 있다.

tracked_metrics 섹션 — grader가 아니라 관찰용 지표다.

중요한 것은 tracked_metrics가 pass/fail에 영향을 주지 않는다는 점이다. 이 지표들은 "시간이 지남에 따라 에이전트가 더 효율적으로 작업하는가?"를 추적하기 위한 것이다. 오늘 20턴 걸리던 태스크가 다음 주에 12턴으로 줄었다면, 프롬프트 개선이 효과가 있었다는 신호다.

실전에서는 원문이 말하듯 deterministic_tests + llm_rubric 두 가지만으로도 대부분의 코딩 eval을 커버할 수 있다. 나머지 grader는 보안이 중요한 도메인이나 도구 사용 패턴을 추적해야 하는 특수한 경우에 추가한다.

5. 대화형 에이전트 eval

5-1. 특성

대화형 에이전트는 고객 지원, 세일즈, 코칭 등에서 사용자와 상호작용한다. 상태를 유지하고, 도구를 사용하고, 대화 중간에 액션을 수행한다. 상호작용의 품질 자체가 평가 대상이다.

코딩 에이전트와의 결정적 차이가 여기에 있다. 코딩 에이전트는 "코드가 동작하는가?"라는 바이너리 질문으로 상당 부분을 커버할 수 있지만, 대화형 에이전트는 "문제를 해결했는가?" + "얼마나 적은 턴으로?" + "적절한 어조였는가?"를 동시에 봐야 한다. **다차원 성공(multidimensional success)**이다.

원문이 언급하는 또 하나의 특징은 시뮬레이터의 필요성이다. 대화형 에이전트를 평가하려면 사용자 역할을 하는 두 번째 LLM이 필요한 경우가 많다. 이 시뮬레이터 LLM이 다양한 시나리오(화난 고객, 모호한 요청, 다중 이슈)를 재현해서 에이전트를 테스트한다. 정렬(alignment) 감사에서도 같은 기법을 쓴다.

5-2. 벤치마크

tau-Bench(τ-Bench)와 tau2-Bench(τ2-Bench): 리테일, 항공 예약 등 다양한 도메인에서 다중 턴 상호작용을 시뮬레이션하는 벤치마크다. 에이전트가 정책을 따르면서 사용자 요구를 해결하는지 평가한다.

5-3. YAML 예시: 환불 처리

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]

5-4. 필드별 해설

graders 섹션 — 4개의 grader.

assertions 필드를 좀 더 뜯어보자. 세 개의 어서션이 각각 다른 차원을 잡고 있다.

1. "Agent showed empathy for customer's frustration" — 감정적 차원. 고객이 화가 났을 때 "불편을 드려 죄송합니다" 같은 공감 표현이 있었는지.
2. "Resolution was clearly explained" — 명확성 차원. 해결 방안을 고객이 이해할 수 있게 설명했는지.
3. "Agent's response grounded in fetch_policy tool results" — 근거 차원. 에이전트가 정책 도구를 호출한 결과에 기반해서 답했는지, 아니면 환각(hallucination)으로 정책을 지어냈는지.

이 세 어서션의 조합이 대화형 에이전트 eval의 전형적인 패턴이다. 감정 + 명확성 + 근거. 이것을 코드로 검증하는 것은 사실상 불가능하다. model-based grader의 존재 이유가 여기에 있다.

원문은 "실전에서 대화형 에이전트 eval은 커뮤니케이션 품질과 목표 달성 모두에 model-based grader를 사용하는 것이 일반적"이라고 정리한다.

6. 리서치 에이전트 eval

6-1. 특성

리서치 에이전트는 정보를 수집하고, 종합하고, 분석해서 답변이나 보고서를 생산한다. 품질 판단이 태스크에 따라 달라진다는 점이 고유한 도전이다 — "포괄적인가", "출처가 있는가", "정확한가"의 의미가 맥락마다 다르다.

원문이 짚는 고유한 어려움들:

• 전문가끼리도 의견이 갈릴 수 있다
• ground truth가 시간에 따라 변한다
• 출력이 길어질수록 실수가 끼어들 여지가 많다

6-2. 벤치마크

BrowseComp: 개방 웹에서 바늘 찾기(needle in a haystack) 능력을 테스트한다. 에이전트가 방대한 웹에서 특정 정보를 찾아낼 수 있는지 평가한다.

6-3. 채점 전략: 세 가지 체크의 조합

리서치 에이전트의 eval은 여러 grader 유형을 조합하는 것이 핵심이다. 원문은 세 가지 체크를 제시한다.

1. Groundedness check (근거 확인)

주장이 출처에 의해 뒷받침되는지 확인한다. "우리나라 AI 시장 규모는 10조원이다"라는 주장이 있다면, 에이전트가 인용한 출처에 실제로 그 수치가 있는지 검증한다. LLM grader가 출력과 인용 출처를 비교해서 미뒷받침(unsupported) 주장을 탐지한다.

2. Coverage check (커버리지 확인)

핵심 사실이 포함되어 있는지 확인한다. 예를 들어 "2024년 AI 트렌드를 요약하라"는 태스크에서 LLM, 에이전트, 규제 세 가지 주제 중 규제를 빠뜨렸다면 커버리지가 불충분하다. exact match로 특정 키워드 존재 여부를 확인하거나, LLM이 "핵심 주제를 빠뜨리지 않았는가?"를 평가한다.

3. Source quality check (출처 품질 확인)

인용한 출처가 권위 있는 것인지 확인한다. 공식 문서를 인용했는가, 검증되지 않은 블로그를 인용했는가. 이것은 코드 기반으로 도메인 허용 목록을 만들어 검증할 수도 있고, LLM에게 판단을 맡길 수도 있다.

정답이 객관적으로 존재하는 경우에는 exact match를 먼저 돌린다. "프랑스의 수도는?"에 대한 답은 코드 기반으로 검증할 수 있다. 그 뒤에 LLM으로 미뒷받침 주장, 빈틈, 일관성, 완결성을 평가한다.

6-4. LLM 보정의 중요성

원문이 강조하는 실무 포인트가 있다.

LLM rubrics should be frequently calibrated against human judgment.

리서치 eval에서 LLM 루브릭은 자주 사람 판단과 보정해야 한다. 이유는 명확하다. 리서치 출력은 길고 복잡하며, LLM이 "포괄적이다"라고 판단한 것과 도메인 전문가가 "포괄적이다"라고 판단한 것이 다를 수 있다. 보정 주기를 정해서 사람 grader와 LLM grader의 일치도를 측정하고, 괴리가 벌어지면 루브릭을 갱신하는 루프가 필요하다.

7. 컴퓨터 사용 에이전트 eval

7-1. 특성

컴퓨터 사용 에이전트는 스크린샷을 보고, 마우스를 클릭하고, 키보드를 입력하고, 스크롤한다. API가 아니라 GUI를 통해 작업한다. 실제 또는 샌드박스 환경이 필요하다.

이 유형의 eval이 특수한 이유는 관찰 공간이 시각적이라는 점이다. 에이전트가 올바른 버튼을 클릭했는지, 올바른 폼에 올바른 값을 입력했는지를 검증하려면 GUI 상태를 프로그래밍적으로 확인할 수 있어야 한다.

7-2. 벤치마크

WebArena: 브라우저 기반 태스크를 다룬다. URL/페이지 상태 검사 + 백엔드 상태 검증으로 채점한다. 에이전트가 올바른 페이지에 도달했는지(프론트엔드), 그리고 의도한 변경이 실제로 반영되었는지(백엔드)를 이중으로 확인한다.

OSWorld: 전체 OS 제어를 다룬다. 평가 스크립트가 파일 시스템, 앱 설정, DB 내용, UI 속성을 검사한다. 웹 브라우저에 국한되지 않고, 데스크톱 앱, 터미널, 파일 매니저 등 OS 전체를 무대로 한다.

7-3. DOM vs Screenshot 트레이드오프

브라우저 사용 에이전트의 경우, 두 가지 접근이 있다.

이 트레이드오프는 eval 설계에도 영향을 준다. DOM-based 에이전트는 DOM 상태로 중간 결과를 검증할 수 있지만, screenshot-based 에이전트는 최종 상태(URL, 백엔드 DB)로만 검증해야 하는 경우가 많다.

7-4. Claude for Chrome eval

원문은 Claude for Chrome 개발 시 에이전트가 각 맥락에서 올바른 도구를 선택하는지 확인하는 eval을 만들었다고 언급한다. 브라우저 환경에서의 도구 선택 — 언제 클릭하고, 언제 스크롤하고, 언제 텍스트를 입력하는가 — 자체가 eval의 대상이 된다.

이것은 코딩 에이전트의 tool_calls grader와 유사하지만, 검증 공간이 GUI라는 점이 다르다. 코딩 에이전트가 read_file → edit_file → run_tests 순서를 따르는지 확인하듯, 컴퓨터 사용 에이전트가 navigate → click → type → submit 순서를 따르는지 확인한다.

8. 유형별 전략 한눈에 비교

마무리: 결과를 채점하되, 경로는 열어두라

네 가지 에이전트 유형의 eval 전략은 표면적으로 다르다. 코딩 에이전트는 테스트 통과를 보고, 대화형 에이전트는 공감과 해결을 보고, 리서치 에이전트는 근거와 커버리지를 보고, 컴퓨터 사용 에이전트는 GUI 상태를 본다.

하지만 공통 원칙이 하나 관통한다. 결과를 채점하되, 경로는 열어두라(grade what the agent produced, not the path it took). 에이전트가 파일을 어떤 순서로 읽었는지, 몇 번의 시행착오를 거쳤는지, 어떤 도구를 먼저 호출했는지는 — tool_calls grader처럼 명시적으로 검증하기로 한 경우가 아니라면 — 채점 대상이 아니다. 에이전트의 강점은 사람이 예상하지 못한 경로로 같은 결과에 도달할 수 있다는 점이다. 경로를 과도하게 제약하면 그 강점을 잃는다.

이 원칙은 grader 설계의 나침반이다. 새로운 grader를 추가하려 할 때 스스로 물어보라 — "이것은 결과를 검증하는 것인가, 아니면 경로를 강제하는 것인가?"

다음 편에서는 이 grader들을 실제로 운영할 때 마주치는 가장 성가신 문제, **비결정성(non-determinism)**을 다룬다. 같은 입력에 대해 다른 출력이 나오는 에이전트를 어떻게 안정적으로 평가하는가?