4장. 평가와 관측

학습 목표

• 과제·시행·채점기·트랜스크립트·결과를 구분해 에이전트 평가를 설계한다.
• 결과 기반 평가와 궤적 평가를 목적에 맞게 섞고, 코드·모델·사람 채점기를 조합한다.
• pass@k와 pass^k, 역량 평가와 회귀 평가를 운영 조건에 맞게 해석한다.
• 트레이스로 에이전트 실패를 단계별로 분석하고, 처음 잘못된 판단을 찾는다.
• 품질·안전·비용·지연 지표를 묶어 배포 여부를 판단한다.

들어가며

새 버전을 배포하기 전날, 팀의 평가 대시보드는 초록색이었습니다. 응답 품질 점수는 4.1에서 4.5로 올랐고, 에이전트는 "처리가 완료되었습니다"라고 더 자신 있게 말했습니다. 배포 일주일 뒤 고객센터에 "완료됐다더니 아무것도 안 됐다"는 항의가 쌓였습니다. 평가는 에이전트가 무엇을 말했는지를 쟀고, 무엇을 했는지는 재지 않았던 것입니다.

에이전트 평가가 어려운 이유는 세 가지입니다. 같은 입력에도 결과가 매번 다르고, 같은 목표에 이르는 올바른 경로가 여럿이며, 결과가 말이 아니라 세상의 상태 변화로 나타납니다. 이 장은 용어, 결과와 궤적의 채점, 채점기 보정, 반복 실행의 해석을 다룬 뒤 평가 세트 관리, 트레이싱을 이용한 실패 분석, 지표에 따른 배포 판단을 정리합니다.

핵심 개념

평가의 기본 용어

Anthropic의 "Demystifying evals for AI agents"는 다음 용어를 씁니다.

가장 중요한 구분은 트랜스크립트와 결과입니다. 트랜스크립트에 "예약을 완료했습니다"라는 문장이 있어도, 결과에 예약 행이 없으면 실패입니다.

결과 기반 평가

결과 기반 평가는 에이전트가 만들어 낸 최종 상태를 채점합니다. Anthropic은 정해진 단계 순서를 요구하기보다 결과를 채점하는 편이 대개 낫다고 말합니다. 순서를 강제하면 더 효율적이거나 창의적인 올바른 해법까지 벌점을 받기 때문입니다. Anthropic의 리서치 시스템 글도 상태를 바꾸는 에이전트는 턴마다 분석하기보다 최종 상태를 평가하는 데 집중하라고 권합니다.

결과를 정의하는 일은 생각보다 손이 갑니다. 사용자에게 남는 산출물(답변, 보고서 파일)과 시스템 상태(원장의 행, 설정)를 모두 시행 뒤 환경에 남은 결과로 보고 나눠 적고, 반드시 맞아야 하는 조건과 있으면 좋은 조건을 구분하고, 부분 성공·판단 보류·사람 인계를 어떻게 셀지 정합니다. 해서는 안 되는 일이 일어나지 않았는지도 결과의 일부입니다. 같은 글은 부분 점수를 주라고도 권합니다. 네 단계 중 세 단계를 해낸 에이전트와 처음부터 실패한 에이전트를 같은 0점으로 매기면 개선이 보이지 않습니다. 다만 필수 조건 위반은 부분 점수와 별개로 실패로 처리합니다.

궤적 평가

궤적 평가는 에이전트가 거친 경로, 즉 도구 호출의 순서와 인자를 봅니다. 결과만으로 알 수 없는 것이 있을 때 씁니다.

Google ADK는 두 축을 함께 다룹니다. tool_trajectory_avg_score는 도구 호출 궤적의 정확한 일치를 보며 기본 기준이 1.0이고, response_match_score는 기준 응답과의 ROUGE-1 유사도로 기본 기준이 0.8입니다. ROUGE-1은 두 글이 낱말을 얼마나 겹쳐 쓰는지 재는 지표라 표현만 다른 올바른 답을 낮게 볼 수 있고, 조사와 어미가 붙는 한국어에서는 이 경향이 더 클 수 있으니 기준값은 표본으로 확인하고 쓰세요. ADK는 LLM 판정으로 의미 일치를 보는 기준, 사용자 정의 기준표로 응답 품질과 도구 사용 품질을 보는 기준, 근거 없는 내용(환각)과 안전성을 보는 기준도 제공합니다. 토큰 사용량이나 도구 호출 횟수 같은 효율 지표는 값만 보고되고 통과·실패를 가르지 않습니다.

채점기 세 종류와 조합

실무에서는 섞어 씁니다. 데이터가 바뀌었는지는 코드로, 보고서가 유용한지는 기준표를 쓰는 모델로, 그 모델 채점기가 믿을 만한지는 사람 표본으로 확인합니다. 에이전트 유형마다 무게중심도 다릅니다. Anthropic의 평가 글에 따르면 코딩 에이전트는 테스트가 통과하는지 같은 결정적 채점이 잘 맞고, 조사 에이전트는 근거성·포괄성·출처 품질을 보는 기준표를 전문가 판단으로 보정해 쓰고, 화면을 조작하는 에이전트는 실제나 샌드박스 환경에서 파일·데이터베이스·주문 같은 의도한 결과가 일어났는지 확인합니다.

모델 채점기를 믿을 수 있게 만들기

모델 채점기의 점수도 검증해야 하는 측정값입니다. 다음 절차로 보정합니다.

1. 정확성·근거성·어조처럼 차원을 나누고, 차원마다 관찰 가능한 기준과 감점 사례를 적는다. 여러 차원을 한 점수로 뭉치면 무엇이 문제인지 알 수 없다.
2. 판단할 근거가 없으면 "판단 불가(Unknown)"를 고를 수 있게 한다. Anthropic은 이것이 채점기의 환각을 줄인다고 설명한다.
3. 전문가가 직접 채점한 표본을 만들고 채점기 판정과의 일치도를 잰다. 어긋난 사례를 읽고 기준표를 고친다.
4. 정기적으로 표본을 다시 뽑아 일치도가 유지되는지 본다.

일반적으로 알려진 편향도 점검하세요. 긴 답을 더 좋게 보거나, 비교할 때 먼저 나온 쪽을 선호하거나, 채점 모델과 같은 계열 모델의 답을 후하게 보는 경향입니다. 쌍 비교라면 순서를 바꿔 두 번 채점하고, 길이와 무관하게 기준을 적용하는지 사례로 확인합니다. Anthropic의 리서치 시스템에서는 기준표(사실 정확성, 인용 정확성, 완결성, 출처 품질, 도구 효율)를 담은 프롬프트 하나로 한 번 호출해 0.0~1.0 점수와 통과·실패를 함께 내는 채점이 가장 일관되고 사람 판단에 가까웠습니다. 한 번에 채점하더라도 기준표의 항목은 나뉘어 있었다는 점에 주목하세요.

pass@k와 pass^k

• pass@k: k번 시도 중 적어도 한 번 성공할 가능성. 사람이 여러 후보 중 고르거나 재시도할 수 있을 때 의미가 있다.
• pass^k: k번 시행이 모두 성공할 확률. 매번 한 번에 맞혀야 하는 운영 조건의 일관성을 잰다.

시행당 성공률을 p라 하고 시행이 서로 독립이라고 가정하면 pass@k = 1 − (1 − p)^k, pass^k = p^k입니다. 같은 글의 예로 시행당 75%면 3번 모두 성공할 확률은 0.75³, 약 42%입니다. k가 커질수록 pass@k는 100%에 다가가고 pass^k는 0%로 떨어집니다. 둘이 크게 벌어지면 "할 줄은 알지만 믿을 수는 없는" 상태입니다. 실제 시행은 같은 과제에서 서로 상관되는 경우가 많으므로, 공식은 해석의 길잡이로 쓰고 실제 값은 반복 실행으로 잽니다.

역량 평가와 회귀 평가

역량 평가는 "이 에이전트가 무엇을 잘하는가"를 묻고 낮은 통과율에서 출발해야 합니다. 회귀 평가는 "예전에 되던 것을 여전히 하는가"를 묻고 거의 100% 통과를 유지해야 합니다. 역량 평가에서 높은 통과율로 안정된 과제는 회귀 세트로 졸업시켜 계속 돌립니다.

역량 평가가 해결 가능한 과제를 모두 통과하게 되면 포화(saturation)입니다. 포화된 세트로는 개선을 볼 수 없어, 실제로는 좋아졌는데 점수가 그대로인 착시가 생깁니다. 포화되면 더 어려운 과제를 새로 만들어 역량 세트를 갱신하고, 기존 과제는 회귀 세트로 옮겨 퇴행 감시에 씁니다. 회귀 세트의 판정도 확률적 변동을 감안해야 합니다. 한 번의 실패로 바로 경보를 울리기보다 반복 실행과 실패의 심각도로 판정합니다.

평가 세트 만들기

처음부터 수백 건을 모을 필요는 없습니다. Anthropic은 실제 실패에서 뽑은 과제 20~50건이면 시작하기에 충분하다고 하고, 리서치 시스템도 실제 사용 패턴을 대표하는 질의 20건 정도로 시작했습니다. 초기에는 변경의 효과가 커서 작은 세트로도 차이가 보입니다. 다만 작은 차이로 배포를 가를 때는 과제와 시행을 늘립니다(깊이 읽기). 좋은 과제의 조건은 다음과 같습니다.

1. 모호하지 않다: 해당 분야 전문가 두 사람이 같은 통과·실패 판정을 내릴 수 있다.
2. 기준 해답이 있다: 모든 채점기를 통과한다고 확인된 해답이 있어 과제와 채점기 자체가 성립함을 보여 준다.
3. 균형이 있다: 행동이 일어나야 할 경우와 일어나면 안 될 경우를 함께 넣는다. 그렇지 않으면 무엇이든 검색하는 식의 한쪽으로 치우친 최적화가 생긴다.
4. 실제 운영에서 왔다: 사용자 신고와 운영 실패를 과제로 바꿔 세트를 현실에 묶어 둔다.

여러 번 시행해도 통과율이 0%인 과제는 에이전트의 무능보다 과제나 채점기의 결함을 먼저 의심하라고 같은 글은 말합니다. 평가 세트에 맞춰 프롬프트와 도구를 고치다 보면 세트에만 맞춰질 수 있으니, 개발용과 검증용을 나눠 검증용은 판단할 때만 씁니다.

평가 환경의 격리와 재현

시행마다 깨끗한 환경에서 시작해야 합니다. 이전 시행이 남긴 파일, 데이터, 기록이 다음 시행을 쉽게 만들면 점수가 부풀려집니다. Anthropic은 에이전트가 이전 시행의 Git 기록을 읽어 답을 찾은 사례를 경고로 듭니다. 반대로 공유 자원이 모자라 시행이 실패한다면 점수가 낮게 나옵니다.

재현하려면 시행 조건을 기록해야 합니다. 모델과 버전, 프롬프트와 도구 정의의 버전, 시각과 검색 결과 같은 외부 입력, 모의 도구인지 실제 연결인지를 남깁니다. 모의 도구 평가는 빠르고 안전하지만 실제 API의 지연, 오류, 데이터 변화를 반영하지 못하므로, 배포 전에는 실제에 가까운 환경에서 한 번 더 확인합니다.

트레이싱

트레이스는 워크플로 하나의 처음부터 끝까지를 나타내고, 시작과 끝 시각이 있는 작업 단위인 스팬들로 이루어집니다. 스팬은 부모-자식 관계로 이어져, 에이전트 실행 아래 모델 생성과 도구 호출이 매달리는 나무 모양이 됩니다.

OpenAI Agents SDK는 트레이싱이 기본으로 켜져 있고 에이전트 실행, LLM 생성, 함수 도구 호출, 가드레일, handoff를 각각 스팬으로 기록합니다.

문서는 OpenAI API를 무보존(ZDR) 정책으로 쓰는 조직에서는 이 트레이싱을 쓸 수 없다고 적습니다. 민감 데이터를 다룬다면 구조는 남기고 입출력은 빼거나 가린 뒤 내보내도록 처리기를 구성하세요.

MCP는 요청의 _meta에 traceparent, tracestate, baggage 키를 OpenTelemetry 추적 문맥 전달용으로 예약해 두었고, traceparent와 tracestate는 W3C Trace Context, baggage는 W3C Baggage 형식을 따릅니다. 이를 쓰면 에이전트와 MCP 서버를 하나의 분산 트레이스로 이을 수 있습니다.

무엇을 기록할지는 답하고 싶은 질문에서 출발합니다. 작업·실행·단계·도구 호출 식별자, 병렬 분기와 인계의 연결, 재시도와 승인 대기, 모델·프롬프트·도구·정책 버전을 남기면 "이 실패는 언제, 어느 버전, 어느 단계에서 시작됐는가"에 답할 수 있습니다. Anthropic은 운영 환경에 전체 트레이싱을 붙이되 개별 대화 내용이 아니라 에이전트의 결정 패턴과 상호작용 구조를 관찰했다고 적습니다. 관측 데이터의 수집 범위와 보존 기간도 정해 두세요.

실패를 단계별로 분석한다

에이전트 실패는 대개 마지막 단계에서 드러나지만 그보다 앞에서 시작됩니다. 날짜를 잘못 해석한 첫 판단이, 세 단계 뒤 엉뚱한 예약으로 드러나는 식입니다. 마지막 증상만 고치면 원인이 남아 다른 모양으로 재발합니다. 분석은 다음 순서로 합니다.

1. 실패 트랜스크립트를 모아 결과(무엇이 틀렸나)로 분류한다.
2. 각 트랜스크립트를 앞에서부터 읽으며 처음 잘못된 판단을 찾는다.
3. 그 판단을 단계로 분류한다: 목표 해석, 계획, 검색·도구 선택, 인자 생성, 도구 결과 해석, 검증, 응답.
4. 원인을 모델·프롬프트·도구 설계·외부 환경·정책 중 하나로 가정한다.
5. 한 번에 한 요소만 바꿔 같은 과제로 다시 돌리고, 가정이 맞는지 확인한다.

평가 지표로 배포를 판단한다

평균 점수 하나로 배포를 정하면 중요한 퇴보가 가려집니다. 배포 판단표는 다음 층으로 짭니다.

자동 평가는 한 겹의 방어일 뿐입니다. Anthropic은 이를 스위스 치즈 모델에 빗댑니다. 자동 평가는 실제 사용과 어긋나면 거짓 확신을 주고, 운영 모니터링은 일이 터진 뒤에 알려 주며, 사용자 피드백은 드물고 치우쳐 있고, 사람의 트랜스크립트 검토는 시간이 많이 듭니다. 어느 층도 완벽하지 않으므로 여러 층을 겹쳐 서로의 빈틈을 메우게 하세요.

깊이 읽기

점수가 움직였을 때 먼저 의심할 것

점수가 갑자기 떨어지거나 오르면 에이전트보다 측정을 먼저 의심합니다. 점수가 떨어졌다면 경직된 채점기가 올바른 다른 답을 실패로 본 것은 아닌지, 외부 환경(API 응답, 검색 결과)이 바뀐 것은 아닌지 봅니다. 점수가 이상하게 올랐다면 시행 사이에 흔적이 새지 않았는지, 평가 세트가 학습이나 프롬프트 수정 과정에 노출되지 않았는지 봅니다. 점수가 변하지 않았다면 포화를 의심합니다. 점수가 어느 쪽으로 움직였든 트랜스크립트를 직접 읽습니다. Anthropic은 많은 시행의 트랜스크립트와 채점을 읽는 것이 채점기가 제대로 작동하고 실패가 공정하게 판정되는지 확인하는 방법이라고 강조합니다. 리서치 시스템을 시험한 사람들은 초기 에이전트가 권위 있는 출처보다 검색 상위의 콘텐츠 농장을 고르는 경향을 찾아냈는데, 이런 문제는 자동 채점만으로는 잘 보이지 않습니다.

표본 크기도 함께 봅니다. 과제 25건에서 4%포인트 차이는 과제 한 건의 우연일 수 있습니다. 같은 과제를 여러 번 시행하고, 버전 사이에 같은 과제 세트를 쓰고, 차이가 반복 실행의 변동 폭보다 큰지 확인한 뒤에 결론을 냅니다.

대화형 에이전트의 평가

상담 에이전트처럼 여러 턴에 걸쳐 일하는 에이전트는 단일 턴 평가로 잡히지 않는 실패가 많습니다. 사용자가 중간에 요청을 바꾸거나, 앞에서 한 말을 뒤에서 뒤집는 경우입니다. Anthropic은 이런 에이전트의 성공을 상태 검사, 턴 수 제한, 어조와 품질의 기준표 채점을 묶은 다차원으로 보고, 다른 LLM이 사용자를 흉내 내게 하는 방법을 소개합니다. Google ADK도 AI 모델이 사용자 발화를 동적으로 만들어 대화 시나리오를 시험하는 사용자 시뮬레이션과 다중 턴 평가 기준을 제공하며, 대화가 매번 달라지므로 시뮬레이션에서는 기준 궤적과의 정확 일치나 기준 응답 비교는 지원하지 않고, 다중 턴 과제 성공과 궤적 품질 같은 기준은 지원한다고 적습니다. 시뮬레이션 사용자의 품질도 재야 합니다. 시뮬레이터가 너무 협조적이면 실제보다 쉬운 시험이 됩니다.

운영에서 회귀 사례를 만든다

평가 세트가 고정되면 실제 사용과 점점 멀어집니다. 운영에서 실패, 사람 인계, 재작업이 일어난 사례를 정기적으로 뽑아 개인정보를 지우고 재구성한 뒤, 기준 해답과 채점기를 붙여 회귀 세트에 넣으세요. 이때 입력 분포가 바뀐 것(새 유형의 요청 증가)과 성능이 떨어진 것(같은 유형의 실패 증가)을 구분합니다. 앞의 것은 역량 세트를 넓힐 신호이고, 뒤의 것은 회귀를 고칠 신호입니다.

실무 장면

단풍렌탈: '완료'라고 말하는 에이전트

가전 렌탈 업체 '단풍렌탈'의 해지 상담 에이전트는 해지 접수와 제품 반납 방문 일정을 예약한다. 새 버전은 LLM 채점 기준 응대 품질이 5점 만점에 4.1에서 4.5로 올랐다. 그런데 배포 전 표본 점검에서, 상담 기록 200건을 예약 원장과 대조하자 에이전트가 "반납 예약이 완료되었습니다"라고 말한 대화의 6%에 실제 예약이 없었고, 2%는 같은 날짜에 예약이 두 건 잡혀 있었다.

트레이스를 앞에서부터 읽자 처음 잘못된 판단이 보였다. 예약 없음 사례는 "다음 주 화요일" 같은 상대 날짜를 예약 도구가 거부해 도구 실행 오류(isError, 2장)를 돌려줬는데, 에이전트가 이를 무시하고 완료를 말했다. 중복 사례는 예약 도구가 타임아웃된 뒤 에이전트가 같은 요청을 다시 보낸 경우였다.

팀이 처음 떠올린 대안은 채점 프롬프트에 "근거 없는 완료 선언에 감점"을 넣는 것이었지만 기각했다. 채점기는 여전히 대화만 보므로 상태를 재지 못한다. 대신 결과 채점기를 코드로 만들었다. 예약이 존재하는가, 날짜가 고객이 말한 날과 같은가, 중복이 없는가를 원장에서 확인하고, 상태와 맞지 않는 완료 선언은 다른 점수와 관계없이 치명 실패로 처리했다. 어조는 기존 모델 채점기로 계속 보되 결과 채점과 분리했다. 예약 도구는 날짜를 ISO 형식으로만 받게 바꾸고, 타임아웃 뒤에는 예약 조회를 먼저 하도록 오류 메시지를 고쳤다. 재구성한 실패 사례 30건은 회귀 세트에 넣었다.

다음 버전은 응대 품질 4.4에 결과 기준 성공률 99%로 배포되었다. 팀은 "완료 선언"과 "원장의 상태"를 따로 재는 것을 평가 원칙 첫 줄에 적었다.

물푸레리서치: 잘 쓴 보고서와 약한 근거

산업 조사 기업 '물푸레리서치'의 보고서 에이전트 새 버전은 분량이 늘고 문장이 매끄러워져 모델 채점기 점수가 크게 올랐다. 그러나 사내 연구원 두 명이 표본 20편을 읽자, 인용한 출처가 주장을 뒷받침하지 않는 문장이 구버전보다 많았다.

팀은 하나의 점수를 버리고 차원을 나눴다. 주장 단위 근거성(문장마다 인용 출처의 해당 부분이 그 주장을 지지하는가), 포괄성, 출처 품질, 문장 품질이다. 근거성 채점기에는 "근거 부족으로 판단 불가"를 고를 수 있게 했다. 이어서 표본을 40편으로 늘려 두 연구원이 직접 채점하고 채점기와의 일치도를 쟀으며, 일치도가 낮던 근거성 기준은 감점 사례를 보태 두 번 고쳤다.

배포 판단표는 반드시 통과(근거 없는 주장 비율 2% 이하, 금지 출처 인용 0건), 비교 지표(과제별 성공률, pass^3), 운영 제약(보고서당 비용이 구버전의 1.3배 이하)으로 짰다. 새 버전은 문장 품질에서 앞섰지만 근거성에서 걸려 배포되지 못했다. 원인 분석에서 처음 잘못된 단계는 '출처 요약을 주장과 대조하지 않고 쓰기 단계로 넘어감'이었다. 쓰기 전에 주장과 근거 문장을 짝지어 두는 단계를 넣은 다음 버전은 모든 층을 통과했다.

기각한 대안은 "네 차원 점수를 평균해 기존보다 높으면 배포"였다. 평균은 문장 품질의 큰 개선이 근거성의 퇴보를 덮게 만든다.

자주 틀리는 지점

1. "에이전트가 완료라고 했으니 성공이다." 대화만 보면 확실해 보이지만, 트랜스크립트는 과정을, 결과는 끝난 뒤의 상태를 기록합니다. 상태를 바꾸는 에이전트는 결과를 검사합니다.
2. "평가 점수가 떨어졌으니 새 모델이 나쁘다." 숫자가 명확해 결론을 내고 싶지만, 경직된 채점기가 올바른 다른 경로를 실패로 처리했을 수 있습니다. 트랜스크립트를 읽기 전에는 결론 내리지 않습니다.
3. "pass@k가 높으면 운영에 충분하다." 높은 숫자가 보기 좋지만, 재시도나 후보 선택이 없는 운영에서는 pass^k가 실제 경험에 가깝습니다.
4. "평가 세트는 수백 건 이상이어야 의미가 있다." 클수록 믿을 만해 보여 시작을 미루게 되지만, 초기에는 실제 실패 20~50건으로도 큰 변화가 보입니다. 대표성, 균형, 모호하지 않음을 먼저 봅니다.
5. "모델 채점기 점수는 객관적인 숫자다." 자동으로 나오니 객관적으로 보이지만, 채점기도 보정이 필요한 측정 도구입니다. 사람 표본과의 일치도로 검증합니다.
6. "여러 지표는 평균해 하나로 보면 된다." 보고하기 편하지만 평균은 치명적 퇴보를 가립니다. 반드시 통과 조건은 평균과 분리합니다.
7. "민감 정보가 있으면 트레이싱을 쓸 수 없다." 위험해 보여 통째로 끄고 싶지만, 구조는 남기고 입출력 수집을 끄거나 가린 뒤 내보낼 수 있습니다.
8. "통과율 0%인 과제는 에이전트가 못하는 일이다." 가장 쉬운 해석이지만, 과제나 채점기가 깨졌을 가능성을 먼저 봅니다. 기준 해답으로 확인합니다.

한눈에 정리

• 트랜스크립트는 과정의 기록, 결과는 끝난 뒤의 상태. 상태를 바꾸는 에이전트는 결과로 채점한다.
• 궤적 검사는 필수·금지 규칙과 효율에만. 모든 과제에 정확 일치를 걸지 않는다.
• 코드는 상태, 모델은 뉘앙스, 사람은 모델 채점기의 기준점.
• 모델 채점기: 차원 분리, 판단 불가 선택지, 전문가 표본 일치도.
• pass@k는 한 번이라도, pass^k는 매번. 독립 가정 공식은 길잡이일 뿐.
• 역량 세트는 낮게 시작, 회귀 세트는 거의 100%. 안정되면 졸업, 포화되면 갱신.
• 평가 세트는 실제 실패 20~50건, 기준 해답, 균형, 개발용·검증용 분리.
• 시행마다 깨끗한 환경, 조건과 버전 기록.
• 실패 분석은 처음 잘못된 판단을 찾고, 한 번에 한 요소만 바꾼다.
• 배포는 반드시 통과 → 비교 지표 → 운영 제약 → 판단 유보의 층으로.

공식 문서로 확인하기

• Anthropic: Demystifying evals for AI agents — 용어, 채점기 종류, pass@k·pass^k, 역량·회귀 평가, 시작하는 법
• Anthropic: How we built our multi-agent research system — 작은 평가 세트, LLM 채점, 사람 평가, 운영 트레이싱
• Google ADK: Why evaluate agents — 궤적·응답 기준과 기본값, 테스트 파일과 평가 세트, 사용자 시뮬레이션
• OpenAI Agents SDK: Tracing — 기본 스팬, 끄는 방법, 묶기와 그룹, 민감 데이터, 처리기
• MCP 2026-07-28: Base protocol — _meta의 추적 문맥 키
• Anthropic: Writing effective tools for agents — 도구 평가 지표와 검증 세트

셀프 체크

4-1. 예약을 대신 잡아 주는 에이전트를 예로 들어, 트랜스크립트와 결과(outcome)가 각각 무엇을 기록하는지 설명하라.

4-2. 궤적 검사를 걸어야 하는 경우와 걸지 말아야 하는 경우를 하나씩 들고, 그렇게 판단한 이유를 적어라.

4-3. 시행당 성공률이 0.9이고 시행이 서로 독립이라고 하자. pass@3과 pass^3을 계산하고, 두 값의 차이가 무엇을 말해 주는지 설명하라.

4-4. 모델 채점기를 사람 판단에 맞춰 보정하는 절차를 세 단계로 적어라.

4-5. 트레이스와 스팬의 관계를 설명하고, 에이전트 실행 하나에서 생길 수 있는 스팬 종류를 셋 이상 들어라.

4-6. 실패한 트랜스크립트에서 처음 잘못된 판단과 드러난 증상을 구분해야 하는 이유는 무엇인가?

4-7. 운영 중인 에이전트의 새 버전에 쓸 배포 판단표를 설계하라. 반드시 통과 조건, 비교 지표, 운영 제약, 판단 유보 조건을 각각 하나 이상 적는다.

실습 과제