에이전트 평가 준비 체크리스트

LangChain의 Deployed Engineer, Victor Moreira 작성

이 체크리스트는 에이전트 평가가 전통적인 소프트웨어 테스트와 왜 다른지 다루고, 핵심 관측성 프리미티브(observability primitives: runs, traces, threads)를 소개하며, 이것들이 어떻게 평가 단계로 매핑되는지 설명하는 "에이전트 관측성이 에이전트 평가를 강화한다(Agent Observability Powers Agent Evaluation)"의 실무적인 동반자입니다. 에이전트 평가가 처음이라면 해당 포스트를 먼저 읽으세요.

이 포스트는 에이전트 평가(evals)를 구축, 실행 및 배포하기 위한 단계별 체크리스트인 **방법(how)**에 초점을 맞춥니다.

신호를 줄 수 있는 가장 단순한 평가부터 시작하세요. 아키텍처가 여전히 변경 중이더라도, 에이전트가 핵심 작업을 완료하는지 테스트하는 몇 가지 엔드투엔드(end-to-end) 평가를 통해 즉시 기준점(baseline)을 확보할 수 있습니다. 더 단순한 접근 방식이 실제 실패를 놓치고 있다는 증거가 있을 때만 복잡성을 추가하세요.

평가를 구축하기 전에

0:00 /0:421×

LangSmith를 사용하여 트레이스(traces)에서 어노테이션 큐(annotation queue)를 거쳐 데이터셋(datasets) 및 실험(experiments)으로 이동하세요.

☑️ 평가 인프라를 구축하기 전에 20~50개의 실제 에이전트 트레이스(traces)를 수동으로 검토할 것

☑️ 단일 작업에 대해 모호하지 않은 성공 기준을 정의할 것

☑️ 역량 평가(capability evals)와 회귀 평가(regression evals)를 분리할 것

☑️ 각 실패가 왜 발생하는지 식별하고 설명할 수 있는지 확인할 것

☑️ 평가 책임(ownership)을 단일 도메인 전문가에게 할당할 것

☑️ 에이전트를 탓하기 전에 인프라 및 데이터 파이프라인 문제를 배제할 것

심층 분석

평가 인프라를 구축하기 전에 20~50개의 실제 에이전트 트레이스(traces)를 수동으로 검토할 것

LangSmith를 사용하여 트레이스(traces)에서 어노테이션 큐(annotation queue)를 거쳐 데이터셋(datasets) 및 실험(experiments)으로 이동하세요.

어떤 인프라를 구축하기 전에, 실제 에이전트 트레이스(traces)를 읽는 데 30분을 할애하세요. 자동화된 시스템보다 이를 통해 실패 패턴에 대해 더 많은 것을 배울 수 있습니다. LangSmith의 트레이스(traces)와 어노테이션 큐(annotation queues)는 이를 위해 매우 훌륭합니다.

단일 작업에 대해 모호하지 않은 성공 기준을 정의할 것

두 명의 전문가가 합격/불합격 여부에 동의할 수 없다면, 해당 작업은 개선이 필요합니다.

불명확한 성공 기준: “이 문서를 잘 요약해줘.”
명확한 성공 기준: “이 회의록에서 3가지 주요 실행 항목(action items)을 추출해줘. 각 항목은 20단어 미만이어야 하며, 언급된 경우 담당자(owner)를 포함해야 함.”

능력 평가(Capability evals)와 회귀 평가(Regression evals)를 분리할 것

두 평가는 목적이 다르기 때문에 모두 필요합니다. 능력 평가(Capability evals)는 어려운 작업에서의 진전을 측정함으로써 에이전트를 앞으로 나아가게 하는 반면, 회귀 평가(Regression evals)는 이미 잘 작동하고 있는 기능을 보호합니다. 이 둘을 분리하지 않으면, 기존 동작을 방어하는 데만 급급하여 개선이 멈추거나, 새로운 능력만을 쫓다가 기존 기능이 퇴보하는 회귀(regression) 현상을 일으키며 배포하게 될 것입니다.

*능력 평가 (Capability evals)*는 “무엇을 할 수 있는가?”에 답합니다.

• 낮은 통과율(pass rate)에서 시작하여, 극복해야 할 목표를 제시합니다.

*회귀 평가 (Regression evals)*는 “여전히 잘 작동하는가?”에 답합니다.

• 약 100%의 통과율을 유지해야 하며, 성능 저하를 포착해야 합니다.

각 실패가 발생하는 이유를 식별하고 설명할 수 있어야 함

무엇이 실패했는지 설명할 수 없다면, 자동화된 평가(automated evals)를 구축하기 전에 더 많은 오류 분석(error analysis)이 필요합니다. 이 단계에 평가 노력의 60~80%를 할애해야 합니다. 다음 프로세스를 따르십시오.

트레이스(Traces) 수집: 운영 환경(production) 또는 테스트에서 대표적인 실패 사례를 수집합니다.
개방 코딩(Open coding): 도메인 전문가와 함께 트레이스를 검토하며, 미리 분류하지 않고 보이는 모든 문제를 기록합니다 (또는 당사의 어노테이션 큐(annotation queue)를 사용하여 주제 전문가가 직접 트레이스를 검토하게 할 수 있습니다).
범주화(Categorize): 문제들을 실패 분류 체계(failure taxonomy)(프롬프트 문제, 도구 설계 문제, 모델의 한계, 도구 오류, 데이터 공백 등)로 그룹화합니다.
반복(Iterate): 새로운 실패 범주가 더 이상 발견되지 않을 때까지 검토를 지속합니다.

범주화가 완료되면, 해결 방법은 근본 원인(root cause)에 따라 달라집니다:

프롬프트 문제 (Prompt problem): 지침이 불분명하여 에이전트가 오해함 → 프롬프트 수정
도구 설계 문제 (Tool design problem): 도구 인터페이스로 인해 에이전트가 실수하기 쉬운 구조임 → 파라미터 재설계, 예시 추가, 경계 명확화
모델 한계 (Model limitation): 지침은 명확했으나 LLM이 엣지 케이스 (edge cases)에 대해 일반화하지 못함 → 예시 추가, 다른 아키텍처 시도 또는 다른 모델 사용
아직 모름 (Don't know yet): 패턴을 파악할 만큼 충분한 실패 사례를 검토하지 않음 → 먼저 더 많은 에러 분석 (error analysis) 수행

평가 소유권을 단일 도메인 전문가에게 할당하십시오

데이터셋 유지 관리, 판정관 (judges) 재보정, 새로운 실패 모드 분류, 그리고 무엇이 "충분히 좋은지"를 결정하는 등 평가 프로세스를 책임질 누군가가 필요합니다. 이상적으로는 위원회를 구성하여 설계하기보다, 한 명의 도메인 전문가가 모호한 사례에 대한 품질 중재자 (quality arbiter) 역할을 수행하는 것이 좋습니다.

에이전트를 탓하기 전에 인프라 및 데이터 파이프라인 문제를 배제하십시오

Witan Labs 팀은 단 하나의 추출 버그가 벤치마크 점수를 50%에서 73%로 끌어올렸다는 것을 발견했습니다. 인프라 문제(타임아웃, 잘못된 형식의 API 응답, 오래된 캐시)는 빈번하게 추론 실패 (reasoning failures)로 위장하곤 합니다. 데이터 파이프라인을 먼저 확인하십시오.

평가 수준을 선택하십시오

모든 평가가 동일한 것을 테스트하는 것은 아닙니다. 에이전트 행동의 적절한 수준에 맞춰 평가를 매칭하십시오. 각 수준에 대한 심층 분석은 "Agent Observability Powers Agent Evaluation"을 참조하십시오.

단일 단계(Single-step) vs. 전체 턴(Full-turn) vs. 다중 턴(Multi-turn) 평가

☑️ 세 가지 평가 수준인 단일 단계 (single-step, run), 전체 턴 (full-turn, trace), 다중 턴 (multi-turn, thread)을 이해하십시오.

☑️ 트레이스 수준 (trace-level, full-turn) 평가로 시작한 다음, 필요에 따라 실행 수준 (run-level) 및 스레드 수준 (thread-level)을 계층적으로 추가하십시오.

심층 분석

단일 단계 (Single-step) 평가

이 단계는 다음 질문에 답합니다: "에이전트가 올바른 도구를 선택했는가?", "유효한 API 호출을 생성했는가?". 자동화하기 가장 쉽지만 안정적인 에이전트 아키텍처가 필요합니다. 만약 도구 정의를 여전히 변경 중이라면, 실행 수준 (run-level) 평가가 깨질 수 있습니다.

전체 턴 (Full-turn) 평가

이것이 대부분의 팀이 시작해야 할 지점입니다. 세 가지 차원에 걸쳐 전체 트레이스 (full trace)를 평가하세요:

최종 응답 (Final response): 출력이 정확하고 유용한가?
경로 (Trajectory): 에이전트가 합리적인 경로를 거쳤는가? (반드시 당신이 예상한 정확한 경로일 필요는 없으며, 유효한 경로이기만 하면 됩니다)
상태 변화 (State changes): 에이전트가 올바른 아티팩트 (artifacts)를 생성했는가? (파일 작성, 데이터베이스 업데이트, 회의 예약 등)

상태 변화 평가는 종종 간과되지만, 단순히 말하는 것이 아니라 무언가를 수행하는 에이전트에게는 매우 중요합니다. 예를 들어, 에이전트가 회의를 예약한다면 단순히

☑️ 지속적인 개선을 위한 trace-to-dataset 플라이휠 (flywheel) 구축

심층 분석 (Deep dive)

모든 태스크가 모호하지 않도록 보장하고, 해결 가능하다는 것을 증명할 참조 솔루션 (reference solution)을 포함할 것

모호한 예: “뉴욕행 괜찮은 항공편 찾아줘.”
명확한 예: “12월 15~17일 출발, 12월 22일 도착, SFO에서 JFK로 가는 왕복 항공편을 이코노미석 기준 400달러 미만으로 찾아줘.”

만약 에이전트가 성공할 가능성이 없다면 (정보 누락, 불가능한 제약 조건 등), 그것은 에이전트의 문제가 아니라 태스크(task)의 문제입니다. 모든 태스크에 대해 참조 솔루션 (reference solution)을 포함하여, 해당 태스크가 해결 가능하다는 것을 증명하고 평가를 위한 기준점 (baseline)을 확보하세요.

긍정 사례 (positive cases, 동작이 일어나야 하는 경우)와 부정 사례 (negative cases, 동작이 일어나지 않아야 하는 경우)를 모두 테스트할 것

단순히 “해야 할 때 검색을 했는가?”만을 테스트한다면, 모든 것을 검색해 버리는 에이전트로 최적화될 것입니다. 부정 사례도 함께 테스트하세요. 단순히 예상된 동작을 확인하는 것이 아니라, 당신의 가설이 틀렸음을 입증하도록 설계된 예시들을 포함해야 합니다.

데이터셋 구조가 선택한 평가 수준 (evaluation level)과 일치하는지 확인할 것

• 실행 수준 (Run-level, 단일 단계) 평가: 참조 도구 호출 (tool calls) 또는 결정 사항이 필요함
• 트레이스 수준 (Trace-level, 전체 턴) 평가: 예상되는 최종 출력값 및/또는 상태 변화 (state changes)가 필요함
• 스레드 수준 (Thread-level, 멀티 턴) 평가: 예상되는 문맥 유지 (context retention)를 포함한 멀티 턴 대화 시퀀스가 필요함

에이전트 유형 (코딩, 대화, 리서치)에 맞춰 데이터셋을 맞춤화할 것

코딩 에이전트 (Coding agents): 품질 루브릭 (quality rubrics)과 함께 결정론적 테스트 스위트 (deterministic test suites, 통과/실패가 명확한 유닛 테스트)를 포함하세요.
대화형 에이전트 (Conversational agents): 다차원적 기준, 즉 태스크 완료 여부 및 상호작용 품질 (공감, 명확성)을 포함하세요.
리서치 에이전트 (Research agents): 근거 확인 (groundedness checks, 주장이 출처에 의해 뒷받침되는가?) 및 커버리지 확인 (coverage checks, 핵심 사실이 포함되었는가?)을 포함하세요.

프로덕션 데이터가 부족하다면 시드 예시 (seed examples)를 생성할 것

태스크의 주요 변동 차원 (질의 복잡도, 주제, 에지 케이스 유형)을 정의하세요. 해당 차원들을 포괄하는 약 20개의 예시 입력을 수동으로 생성하여 기존 에이전트에 실행한 뒤, 이를 검토 및 수정하여 신뢰할 수 있는 정답 (ground truths)으로 저장하세요.

💡

실질적인 팁 (Practical tip): 여러분이 확신을 가지고 수동으로 검토한 20~50개의 예시가 검증되지 않은 수백 개의 합성 데이터 (synthetic examples)보다 더 뛰어난 성능을 발휘할 것입니다. 여기서는 품질이 양보다 중요합니다!

내부 테스트 (dogfooding) 오류, 변형된 외부 벤치마크, 그리고 수동 작성된 행동 테스트 활용하기

콜드 스타트 (cold start) 단계를 지나면, 새로운 평가 항목 (evals)을 발견하기 위한 지속적인 파이프라인이 필요합니다. 다음 세 가지 전략을 병행하면 효과적입니다:

• 매일 에이전트를 직접 사용하며 (dogfooding) 모든 오류를 평가 항목으로 전환하세요. 이는 프로덕션 모니터링 (production monitoring)과는 다릅니다. 여러분의 팀이 실제 워크플로우 전반에서 에이전트를 의도적으로 스트레스 테스트 (stress-testing)하는 과정입니다.
• Terminal Bench 또는 BFCL과 같은 외부 벤치마크 (benchmarks)에서 태스크를 가져와 변형하세요. 전체 벤치마크를 통째로 실행하지 마세요. 여러분이 중요하게 생각하는 역량을 테스트할 수 있는 태스크를 선별 (cherry-pick)하여 에이전트에 맞게 조정하세요.
• “에이전트가 도구 호출 (tool calls)을 병렬화하는가?” 또는 “모호한 요청에 대해 명확한 질문을 던지는가?”와 같이 중요하다고 생각되는 특정 행동에 대해 수동으로 집중적인 테스트를 작성하세요.

이 접근 방식에 대한 구체적인 사례는 “Deep Agents를 위한 평가 항목 구축 방법”을 참조하세요.

채점자 (Grader) 설계

☑️ 평가 차원 (evaluation dimension)별로 특화된 채점자를 선택하세요: 객관적인 확인에는 코드 기반 (code-based) 방식을 기본으로 하고, 주관적인 평가에는 LLM-as-judge를, 모호한 경우에는 인간을, 버전 비교에는 쌍체 비교 (pairwise) 방식을 사용하세요.

☑️ 가드레일 (guardrails, 인라인 및 런타임)과 평가자 (evaluators, 비동기 및 품질 평가)를 구분하세요.

☑️ 수치 척도보다는 이진 통과/실패 (binary pass/fail) 방식을 선호하세요.

☑️ LLM-as-a-Judge 채점자를 인간의 선호도에 맞게 교정 (calibrate)하세요.

☑️ 정확한 경로가 아닌 결과를 채점하고, 점진적인 진전에 대해서는 부분 점수 (partial credit)를 부여하도록 설계하세요.

☑️ 일반적인 기성 지표 (off-the-shelf metrics)가 아닌, 오류 분석에서 도출된 맞춤형 평가자 (custom evaluators)를 사용하세요.

심층 분석 (Deep dive)

평가 차원별 특화된 채점자 선택하기

객관적으로 정답이 존재하는 경우에는 코드 기반 평가자 (code-based evaluators)를 기본으로 사용하세요. 객관적인 작업에 대해 LLM-as-judge 채점을 사용하는 것은 신뢰할 수 없을 수 있으며, 일관되지 않은 판단은 실제 성능 저하 (regressions)를 가릴 수 있습니다. 결정론적 비교 (deterministic comparison)로 전환하면 일관성을 제거하고 더 나은 신호 (signal)를 제공할 수 있는 경우가 많습니다. LLM-as-judge는 진정으로 주관적인 평가를 위해서만 남겨두세요.

💡

실무 팁 (Practical Tip): 하나의 거대한 채점자 (monolithic grader)를 만들기보다는, 평가를 차원별로 특화된 채점자들로 분해하세요. 예를 들어, Witan Labs 팀은 각 차원에 적합한 임계값 (thresholds)을 가진 5개의 특화된 평가자 (콘텐츠 정확성, 구조, 시각적 포맷팅, 공식 시나리오, 텍스트 품질)를 구축했습니다. 이렇게 하면 무엇이 실제로 실패하고 있는지에 대해 더 명확한 신호를 얻을 수 있습니다!

가드레일 (guardrails)과 평가자 (evaluators) 구분하기

• 채점 (judge scoring), 궤적 분석 (trajectory analysis)

안전 점검 (Safety checks) 및 형식 검증 (format validation)은 가드레일이며, 이는 인라인 (inline)으로 실행되어야 합니다. 품질 평가 (Quality assessment) 및 회귀 테스트 (regression testing)는 평가자이며, 비동기 (async)로 실행됩니다. 이 둘을 혼동하지 마세요.

숫자 척도보다 이진 통과/실패 (binary pass/fail) 선호하기

1-5점 척도는 인접한 점수 사이에 주관적인 차이를 유발하며, 통계적 유의성을 확보하기 위해 더 큰 표본 크기를 요구합니다. 이진 방식 (Binary)은 더 명확한 사고를 강제합니다. 즉, 에이전트가 성공했거나 혹은 실패했거나 둘 중 하나입니다. 복잡한 작업은 언제든지 여러 개의 이진 체크로 분해할 수 있습니다.