6부 27장. Evals: 품질을 어떻게 측정할 것인가

에이전트를 처음 만들 때는 대개 이런 식으로 확인한다. 몇 가지 질문을 던져 보고, 제법 그럴듯한 답이 나오면 고개를 끄덕인다. 데모에서는 멋져 보인다. 회의실에서도 박수가 나온다. 그런데 막상 배포하고 나면 이상한 일이 벌어진다. 어떤 요청은 훌륭하게 처리하는데, 어떤 요청은 엉뚱한 도구를 고르고, 어떤 날은 같은 질문에 전혀 다른 품질을 보인다.

이때 가장 위험한 말은 이것이다.

"느낌상 괜찮은데요?"

좋은 에이전트는 느낌으로 만들지 않는다. 평가 체계로 만든다.

앞 장에서 우리는 trace를 통해 에이전트가 실제로 무엇을 했는지 보는 법을 다뤘다. 이제 한 걸음 더 나아가야 한다. 본다는 것만으로는 충분하지 않다. 그 행동이 좋았는지, 나빴는지, 얼마나 일관적인지, 얼마의 비용으로 그 결과를 냈는지를 숫자와 기준으로 말할 수 있어야 한다.

이번 장에서는 바로 그 체계를 다룬다. 정확도, 성공률, 제약 준수, 인간 선호, 장기 태스크 완수율을 포함해 에이전트 품질을 어떻게 평가할지 차근차근 정리해 보자.

평가는 정답 맞히기가 아니라 시스템을 재는 일이다

에이전트 평가를 단순한 시험 점수처럼 생각하면 금방 막힌다. 일반 LLM 평가는 종종 "이 질문에 이 답이 맞나?" 정도로 끝난다. 하지만 에이전트는 그보다 훨씬 넓은 존재다. 계획을 세우고, 도구를 고르고, 상태를 읽고 쓰고, 여러 단계를 거쳐 목표를 달성한다. 그래서 평가는 최종 문장 하나가 아니라 시스템 전체의 행동을 재는 일에 가깝다.¹

여기서 몇 가지 구분이 중요하다. 하나의 task는 "환불 요청을 처리하라", "출장 일정을 예약하라"처럼 평가하려는 구체적 과제다. 그 과제를 한 번 실행한 것이 trial이다. 에이전트는 비결정적이기 때문에 같은 task라도 trial마다 결과가 달라질 수 있다. 그 결과를 채점하는 규칙이 grader이고, 실행 전체 기록은 transcript 또는 trace, 마지막에 환경에 실제로 남은 결과는 outcome이다.¹

이 구분이 왜 중요할까. 에이전트가 대화에서는 "환불 완료했습니다"라고 말해도, 실제 결제 시스템에는 아무 변화가 없을 수 있다. transcript는 그럴듯했지만 outcome은 실패다. 에이전트 평가는 바로 이런 겉보기 성공과 실제 성공의 차이를 잡아내기 위해 존재한다.¹⁵

왜 에이전트 평가는 더 어려운가

에이전트 평가는 일반 챗봇 평가보다 어렵다. 이유는 간단하다. 실패 방식이 더 많기 때문이다.

에이전트는 정답 문장을 생성하는 데서 끝나지 않는다. 잘못된 도구를 고를 수 있고, 올바른 도구를 골라도 인자를 틀리게 넣을 수 있다. 중간에 루프에 빠질 수도 있고, 실패를 복구하지 못할 수도 있다. 심지어는 아무 일도 하지 않았는데 일을 끝냈다고 말할 수도 있다. 이런 문제는 최종 답변만 봐서는 잘 드러나지 않는다.⁵

또 하나의 어려움은 여러 경로가 모두 정답일 수 있다는 점이다. 같은 목표를 이루더라도 어떤 실행은 두 단계로 끝나고, 어떤 실행은 여섯 단계가 걸릴 수 있다. 둘 다 성공일 수 있지만, 운영 관점에서는 같지 않다. 느리고 비싼 성공은 오래 버티지 못한다.⁵⁶

그래서 에이전트 평가는 한 가지 숫자로 끝내기 어렵다. "맞았다/틀렸다"보다 더 넓은 질문이 필요하다.

이 일을 실제로 끝냈는가?

그 과정은 적절했는가?

규칙과 제약을 지켰는가?

사람이 보기에 좋은 경험이었는가?

지속적으로 운영 가능한 비용과 속도였는가?

이 다섯 질문에 답할 수 있어야 비로소 에이전트를 평가했다고 말할 수 있다.

무엇을 측정해야 하는가: 여섯 개의 렌즈

에이전트 평가는 한 방향에서만 보면 안 된다. 실무에서는 보통 아래 여섯 개 렌즈를 함께 본다.

이 표를 보면 조금 안심이 된다. 에이전트 평가는 막연한 예술이 아니라, 잘 나누면 충분히 관리 가능한 공학 문제라는 뜻이기 때문이다.

이 구분은 다른 표현으로도 이해할 수 있다. 어떤 자료는 reasoning, action, execution의 세 층으로 나눈다. reasoning은 계획이 좋은지, action은 도구를 제대로 썼는지, execution은 전체 목표를 완수했는지를 본다.³ 또 어떤 자료는 outcome, trajectory, system metrics로 정리한다. 결과가 좋았는지, 경로가 좋았는지, 운영 지표가 건강한지를 함께 보자는 뜻이다.⁶

이 책에서는 독자가 실제 설계와 운영에 바로 써먹기 쉽도록, 여섯 개 렌즈로 풀어 설명하겠다.

첫째, 정확도보다 먼저 성공률을 정의하라

많은 팀이 에이전트 품질을 묻는 순간 "정확도 몇 퍼센트죠?"부터 묻는다. 물론 정확도는 중요하다. 하지만 에이전트에서는 그보다 먼저 성공이 무엇인지를 정의해야 한다.

예를 들어 고객지원 에이전트를 만든다고 해 보자. "사용자를 잘 도와준다"는 정의로는 평가할 수 없다. 대신 이렇게 바꿔야 한다.

• 주문 번호가 올바른지 확인했다.

• 환불 가능 정책을 조회했다.

• 실제 환불 API를 호출했다.

• 사용자에게 처리 결과를 정확히 알렸다.

이렇게 되면 성공은 측정 가능해진다. 여기서 가장 기본이 되는 지표가 task completion rate다. 전체 시도 중 실제로 목표 상태에 도달한 비율이다. 중요한 점은 이 성공을 대화 내용이 아니라 환경의 상태 변화로 검증해야 한다는 것이다. 환불이 되었다면 데이터베이스에 환불 기록이 있어야 한다. 일정이 예약되었다면 캘린더에 이벤트가 생겨야 한다.¹⁵

그다음에 보는 것이 정확도다. 성공한 것처럼 보이더라도 세부 내용이 틀릴 수 있기 때문이다. 잘못된 날짜로 예약했거나, 규정과 다른 환불 금액을 계산했다면 성공률만으로는 부족하다. 그래서 실무에서는 goal success와 goal accuracy를 함께 본다. 하나는 일을 끝냈는지, 다른 하나는 제대로 끝냈는지 보는 셈이다.⁴

둘째, 과정의 품질을 보지 않으면 비용 폭탄이 온다

에이전트는 종종 "결과는 맞았는데 과정이 엉망"인 경우가 있다. 예를 들어 날씨를 알려 달라고 했는데 검색 도구를 다섯 번 부르고, 같은 API를 세 번 재시도하고, 마지막에 겨우 맞는 답을 냈다고 해 보자. 사용자는 답을 받았으니 겉보기에는 성공이다. 그러나 운영자는 곧 청구서를 보고 눈이 커진다.

그래서 경로 품질이 필요하다. 대표적으로 다음 세 가지를 본다.

• Tool selection accuracy: 필요한 순간에 올바른 도구를 골랐는가

• Argument accuracy: 도구에 넣은 인자가 정확했는가

• Step efficiency: 불필요한 단계나 중복 호출 없이 끝냈는가³⁴

이 세 가지는 에이전트에서 특히 중요하다. 사람이 보기엔 "도구를 썼다" 한 줄로 끝나지만, 실제로는 도구 선택 오류와 인자 오류가 완전히 다른 버그이기 때문이다. 전자는 라우팅 문제고, 후자는 정보 추출이나 스키마 정렬 문제다. 고치는 방법이 다르다.

또한 step efficiency는 단지 성능 취향의 문제가 아니다. 에이전트가 불필요하게 오래 생각하고, 같은 일을 반복하고, 의미 없는 루프를 돌기 시작하면 비용과 지연이 함께 폭증한다. 좋은 성공과 나쁜 성공을 구분하는 지표가 바로 여기 있다.⁵⁶

셋째, 제약 준수는 별도 축으로 측정해야 한다

많은 실패는 "틀린 답"이 아니라 "하면 안 되는 행동"에서 나온다. 권한이 없는 데이터에 접근하거나, 짧게 답하라는 지시를 무시하거나, 승인 없이 외부 시스템에 쓰기를 시도하는 일이 그렇다.

이때 필요한 것이 제약 준수 평가다. 여기에는 여러 종류가 있다. 시스템 프롬프트를 따랐는지 보는 task adherence, 정책과 규정을 지켰는지 보는 policy adherence, 권한 범위를 넘지 않았는지 보는 scope violation rate 같은 것들이다.²⁴

이 축을 따로 떼어 보는 이유는 분명하다. 어떤 에이전트는 성능이 좋아 보일수록 더 위험할 수 있기 때문이다. 예를 들어 지나치게 적극적인 에이전트는 목표 달성률은 높지만 규정 위반이 잦을 수 있다. 반대로 지나치게 소극적인 에이전트는 안전해 보이지만 아무 일도 못 할 수 있다.

재미있고도 무서운 사실이 하나 있다. 최근 안전성 평가 연구에서는 제약을 잘 지키는 것처럼 보이는 모델이 사실은 일을 못 해서 그렇게 보이는 경우가 관찰됐다. 이를 "illusion of compliance", 즉 준수의 환상이라고 부른다. 또 안전 제약을 넣으면 가능한 우회 경로가 있어도 task success가 크게 떨어지는 cost of compliance 현상도 나타났다.⁷

이 말은 곧 이런 뜻이다. 안전성 점수가 높다고 무조건 안심하면 안 된다. 정말로 원칙을 지킨 것인지, 아니면 그냥 능력이 부족해서 아무 것도 못 한 것인지를 함께 봐야 한다.

넷째, 인간 선호는 마지막 장식이 아니라 핵심 지표다

에이전트가 기술적으로 맞는 답을 내놔도 사용자는 불만족할 수 있다. 질문은 짧게 답해 달랬는데 장광설을 늘어놓거나, 필요한 답은 맨 아래 한 줄에 숨어 있고, 톤이 어색하거나, 괜히 자신만만한 태도를 보인다면 사람은 "이 에이전트 별로다"라고 느낀다.

그래서 인간 선호를 별도 지표로 다뤄야 한다. 대표적인 방법은 세 가지다.

• 같은 요청에 대한 두 결과를 비교해 어느 쪽이 더 나은지 고르는 pairwise preference

• 도움됨, 명확함, 간결함, 신뢰감 같은 항목을 루브릭으로 평가하는 human review

• 실제 사용자 행동으로 보는 thumbs up/down, 재질문율, 이탈률, 사람 상담 전환율¹⁵

여기서 중요한 것은 인간 평가가 자동 평가의 대체재가 아니라는 점이다. 사람은 비싸고 느리다. 하지만 사람만이 잡아내는 신호가 있다. 자동 채점은 모두 초록불인데 사용자 반응은 싸늘한, 이른바 "metric green, user red" 상황을 발견해 주는 것이 인간 검토다.⁵

현실적인 방법은 이렇다. 전체 트래픽은 자동 평가로 폭넓게 보고, 그중 일부를 사람에게 샘플링해 루브릭으로 검토한다. 그리고 그 결과로 LLM-as-a-judge의 기준을 보정한다. 즉, 사람은 느리지만 여전히 평가 체계의 기준점 역할을 한다.

다섯째, 장기 태스크 완수율은 따로 측정해야 한다

짧은 질의응답에서는 멀쩡한 에이전트가 긴 작업에서는 갑자기 흔들리는 경우가 많다. 이유는 간단하다. 장기 작업에는 더 많은 실패 지점이 숨어 있기 때문이다. 상태가 바뀔 수 있고, API가 중간에 실패할 수 있고, 메모리가 낡을 수 있고, 사람 승인이나 백그라운드 재개가 필요할 수 있다.

그래서 장기 태스크 완수율은 일반 성공률과 따로 보는 편이 좋다. 예를 들어 다음 조건 중 하나라도 만족하면 장기 작업으로 분류할 수 있다.

• 다섯 단계 이상이 필요한 작업

• 여러 턴의 추가 확인이 필요한 작업

• 백그라운드 대기나 재개가 필요한 작업

• 외부 시스템에 여러 번 읽기와 쓰기를 수행하는 작업

이때는 단순히 마지막 답이 그럴듯한지만 보면 안 된다. 처음 의도한 목표가 끝까지 유지되었는지, 중간 실패를 복구했는지, 필요한 상태를 올바르게 기억했는지, 최종적으로 환경이 바뀌었는지를 함께 봐야 한다.⁴⁵

예를 들어 출장 예약 에이전트라면, 출발지와 날짜를 처음엔 제대로 이해했더라도 세 번째 도구 호출에서 잘못된 날짜 형식으로 API가 실패할 수 있다. 이때 좋은 에이전트는 재시도하거나 사용자에게 확인을 요청한다. 나쁜 에이전트는 "예약 완료했습니다"라고 말하고 사라진다. 장기 태스크 완수율은 이런 차이를 잡아낸다.

여섯째, 비용과 속도는 품질의 바깥이 아니라 안쪽이다

정확도 95%짜리 에이전트가 있다고 하자. 그런데 한 건 처리에 40초가 걸리고 비용이 3달러가 든다면 어떨까. 데모는 통과할지 몰라도 제품은 못 된다.

그래서 운영 품질 지표는 부록이 아니라 본문이다. 최소한 다음은 함께 봐야 한다.

• p50, p95 latency

• cost per successful task

• token usage per task

• tool-call count

• retry rate, loop rate²⁵⁶

여기서 핵심은 "성공한 작업당 비용"이다. 그냥 평균 비용이 아니라, 실제로 유효한 결과를 만든 데 얼마가 들었는지를 봐야 한다. 실패가 많은 에이전트는 성공 1건을 만들기 위해 여러 번의 실패 비용을 태우기 때문이다.

이 지표를 보면 구조적 문제가 잘 드러난다. 예를 들어 정확도는 비슷한데 성공당 비용이 두 배인 두 버전이 있다면, 후자는 과도한 검색, 중복 추론, 불필요한 재시도를 하고 있을 가능성이 높다. 결국 좋은 에이전트는 잘 맞히는 에이전트가 아니라, 잘 맞히면서도 감당 가능한 에이전트다.

채점자는 셋이다: 코드, 모델, 사람

에이전트 평가에서 쓰는 채점자는 크게 세 종류다.

좋은 평가 체계는 이 셋을 섞는다.¹⁵

도구 호출 정확도나 최종 환경 상태는 코드 기반으로 보는 것이 가장 낫다. 반면 "설명이 충분히 명확한가", "사용자의 의도에 잘 맞는가" 같은 것은 모델 기반 채점이 유리하다. 그리고 그 모델 채점이 과하게 너그럽거나 엄격하지 않은지, 실제 사용자 감각과 어긋나지 않는지는 인간 평가로 보정해야 한다.

실무에서는 보통 이렇게 조합한다. 할 수 있는 것은 최대한 deterministic하게, 그래도 남는 부분만 judge 모델로, 그리고 중요한 샘플은 사람으로 재검토한다. 이 순서가 비용도 아끼고 디버깅도 쉽다.

LLM-as-a-judge는 강력하지만 길들이기가 필요하다

최근 에이전트 평가에서 가장 많이 쓰는 방식이 LLM-as-a-judge다. 더 강한 모델이나 별도의 평가 모델에게 실행 결과를 보여 주고, 루브릭에 따라 점수나 pass/fail을 매기게 하는 방식이다. Microsoft Foundry 같은 도구는 Task Adherence, Coherence, Safety 같은 내장 evaluator를 제공하고, 임계값도 정해 둘 수 있다.²

하지만 judge 모델은 판사가 아니라 판정기다. 판정기는 길들여야 한다.

좋은 judge 프롬프트는 추상적 칭찬이 아니라 구체적인 기준을 갖는다. "좋은 답변인가?"보다 "사용자 요청을 충족했는가, 필요한 도구를 올바르게 사용했는가, 정책을 위반하지 않았는가"처럼 쪼개야 한다. 또한 가능하면 생성 모델과 평가 모델을 분리하는 편이 낫다. 같은 모델을 프롬프트만 바꿔 평가자로 쓰면 비슷한 맹점을 공유할 가능성이 있기 때문이다.¹⁵

또 하나 중요한 점은 점수 자체보다 이유를 남기는 것이다. 집계 점수는 대시보드에 좋지만, 실제 개선은 row-level 판정 이유에서 나온다. 어떤 케이스가 왜 fail이 났는지, 어떤 도구 인자가 왜 틀렸는지, 어떤 제약을 어디서 어겼는지 남겨야 다음 수정이 가능하다.²

데이터셋이 품질의 절반이다

평가 지표를 잘 설계해도, 평가 데이터셋이 부실하면 결과는 믿을 수 없다. 에이전트의 품질은 결국 무엇으로 시험하느냐에 크게 좌우된다.

시작은 작아도 된다. 처음에는 20개만 있어도 괜찮다. 하지만 그 20개는 대표성이 있어야 한다. 그리고 점점 50개, 100개, 200개로 늘려야 한다. 실무에서는 보통 다음 다섯 부류를 고르게 넣는 편이 좋다.⁶

• 정상 경로: 가장 흔한 요청을 안정적으로 처리하는가

• 경계 사례: 입력이 모호하거나 일부 정보가 빠졌을 때 어떻게 행동하는가

• 적대 사례: 프롬프트 인젝션, 정책 위반 요청, 권한 외 요청을 어떻게 거절하는가

• 실패 복구 사례: 도구 오류, 타임아웃, 형식 오류가 났을 때 회복하는가

• 장기 작업 사례: 여러 턴과 여러 상태 변경을 끝까지 일관되게 이어 가는가

좋은 데이터셋은 상상으로만 만들지 않는다. 실제 실패 trace에서 자란다. 프로덕션에서 문제가 된 사례를 모으고, 비슷한 패턴을 묶고, 그중 대표 사례를 golden set에 편입해야 한다. replay 테스트가 강력한 이유도 여기에 있다. 이미 실제 사용자에게서 일어난 실패를 다시 돌려 보게 해 주기 때문이다.⁶

공개 벤치마크는 어디까지나 참고용이다. GAIA, WebArena, AgentBench 같은 벤치마크는 외부 비교 기준으로는 쓸모가 있다. 하지만 당신의 서비스가 세금 신고 도우미인지, 사내 구매 자동화인지, 코드 리뷰 보조인지에 따라 진짜 중요한 태스크는 완전히 달라진다. 최종 기준은 공개 리더보드가 아니라 자기 서비스의 private eval set이어야 한다.⁶

한 번 돌려 보고 끝내지 마라

에이전트는 비결정적이기 때문에, 중요한 케이스를 한 번만 돌리고 pass/fail을 결정하면 운에 속기 쉽다. 우연히 잘 나온 한 번의 성공을 실력으로 착각할 수 있다. 그래서 핵심 시나리오일수록 여러 trial을 돌려 안정성을 봐야 한다.¹⁵

예를 들어 같은 30개 태스크를 세 번씩 돌렸다고 해 보자. 평균 성공률은 88%인데 표준편차가 크고, 특정 태스크는 한 번은 성공하고 두 번은 실패한다면 이 에이전트는 아직 불안정하다. 반면 평균이 85%여도 거의 같은 결과를 반복한다면, 적어도 어디를 고쳐야 할지는 더 명확하다.

이런 이유로 실무에서는 "한 번 잘 됨"보다 반복 가능한 품질을 더 높게 친다. 사용자는 매번 같은 수준의 도움을 기대하지, 오늘은 기분이 좋아서 잘 나온 에이전트를 원하지 않기 때문이다.

통과 기준이 있어야 평가가 된다

평가를 한다는 것은 단순히 숫자를 수집한다는 뜻이 아니다. 어디까지가 합격인지 미리 정한다는 뜻이다. Microsoft의 가이드가 평가를 개발 단계에서 돌리며 예를 들어 85% task adherence 같은 통과 기준을 세우라고 권하는 이유도 바로 여기에 있다.²

좋은 팀은 배포 전에 최소한의 품질 문턱을 명시한다. 예를 들면 이렇다.

물론 숫자는 서비스마다 다르다. 중요한 것은 숫자 그 자체보다, 배포 여부를 결정하는 문턱이 존재해야 한다는 사실이다. 문턱이 없으면 평가는 보고서가 되고, 문턱이 있으면 평가가 운영 규칙이 된다.

또한 결과는 두 층으로 봐야 한다. 집계 결과는 배포 여부를 판단하는 데 쓰고, 개별 행 결과는 왜 실패했는지 파악하는 데 쓴다. 전체 성공률이 88%라는 숫자만으로는 아무것도 고칠 수 없다. 어떤 12%가 실패했는지 알아야 수정이 가능하다.²

오프라인 평가, CI, 온라인 평가를 연결하라

평가는 한 번의 이벤트가 아니라 루프다. 가장 안정적인 구조는 세 층으로 이루어진다.

첫째는 오프라인 평가다. 개발 중인 프롬프트, 모델, 도구 스키마, 라우팅 규칙을 고정된 데이터셋에 반복 실행해 비교한다. 새로운 변경이 진짜 개선인지, 단순한 착시인지 여기서 먼저 걸러낸다.

둘째는 CI 평가다. 중요한 변경마다 자동으로 평가를 돌려 품질 게이트로 삼는다. 프롬프트 한 줄을 바꿔도, 모델 버전을 올려도, 도구 인자 스키마를 수정해도 회귀가 없는지 본다.²

셋째는 온라인 평가다. 실제 운영 트래픽에서 샘플을 뽑아 계속 평가하고, 사용자 피드백과 사람 검토 결과를 수집한다. 오프라인 데이터셋에 없는 새로운 실패는 대부분 여기서 발견된다.²⁶

앞 장의 tracing이 중요한 이유도 여기 있다. trace가 있어야 production failure를 replay할 수 있고, failure cluster를 만들 수 있고, 어떤 변경이 어느 단계의 개선으로 이어졌는지 확인할 수 있다. trace가 사실을 제공하고, eval이 점수를 붙이고, 운영 메트릭이 그 점수가 실제 제품 경험으로 이어졌는지 검증하는 구조다.⁵

흔한 착각 다섯 가지

에이전트 평가를 하다 보면 거의 꼭 만나는 착각들이 있다.

첫째, 최종 답변만 보면 된다는 착각이다. 아니다. 에이전트는 과정이 시스템의 일부다. 잘못된 경로로 겨우 맞힌 답은 운영에서 결국 문제를 만든다.

둘째, 한 번 통과하면 괜찮다는 착각이다. 아니다. 에이전트는 비결정적이다. 중요한 태스크일수록 반복 실행으로 안정성을 확인해야 한다.

셋째, 공개 벤치마크 점수가 높으면 제품도 좋다는 착각이다. 아니다. 공개 벤치마크는 체력장이고, 제품 품질은 실전 경기다. private golden set이 더 중요하다.⁶

넷째, LLM judge가 객관적이라는 착각이다. 아니다. judge도 모델이다. 편향과 흔들림이 있다. 반드시 인간 평가로 주기적으로 보정해야 한다.⁵

다섯째, 제약 준수 점수가 높으면 안전하다는 착각이다. 아니다. 앞서 본 것처럼 준수의 환상이 있을 수 있다. 아무것도 못 해서 규칙을 안 어긴 것처럼 보이는 경우를 경계해야 한다.⁷

이 다섯 가지만 피해도 평가 체계는 훨씬 현실에 가까워진다.

실전에서 바로 쓰는 최소 평가 프레임

처음부터 거대한 평가 플랫폼을 만들 필요는 없다. 대신 아래 순서로 시작하면 된다.

먼저, 서비스의 대표 작업 20개를 고른다. 그다음 각 작업마다 성공 기준을 환경 상태 기준으로 적는다. 이어서 도구 호출 정확도, 제약 준수, 비용, 지연 시간을 함께 수집한다. 개방형 품질은 LLM-as-a-judge로 채점하되, 중요한 샘플은 사람이 다시 본다. 마지막으로 이 세트를 모든 변경마다 자동으로 돌린다.

이렇게만 해도 이미 대부분의 팀보다 훨씬 앞서 있다.

조금 더 성숙해지면 다음이 붙는다. 프로덕션 실패를 golden set에 계속 추가하고, 장기 태스크 세트를 따로 만들고, judge 기준을 더 세밀하게 쪼개고, 배포 게이트를 더 엄격하게 가져간다. 결국 평가 체계는 한 번 만드는 문서가 아니라 제품이 커질수록 함께 자라는 운영 자산이다.

이번 장의 결론

좋은 에이전트는 우연히 탄생하지 않는다. 데모에서 반짝이는 순간이 아니라, 수십 번의 반복 실행과 수백 개의 평가 케이스를 통과하면서 만들어진다.

정확도는 중요하다. 하지만 그것만으로는 부족하다. 성공률을 봐야 하고, 제약 준수를 봐야 하고, 인간 선호를 봐야 하고, 장기 태스크 완수율을 봐야 하고, 비용과 속도까지 함께 봐야 한다. 결과뿐 아니라 경로도 봐야 하고, 자동 채점뿐 아니라 인간 판단도 섞어야 한다.

결국 에이전트 품질은 감상이 아니라 체계다.

좋은 에이전트는 "똑똑해 보이는 에이전트"가 아니라, 반복 가능한 평가 체계 안에서 계속 합격하는 에이전트다.

그때부터 팀은 더 이상 감으로 고치지 않는다. 실패를 데이터로 보고, 개선을 비교하고, 품질을 운영할 수 있게 된다. 그리고 바로 그 지점에서 에이전트는 데모를 넘어 제품이 된다.

참고

¹Demystifying evals for AI agents

²Evaluate your AI agents - Microsoft Foundry  Microsoft Learn

³AI Agent Evaluation Metrics  DeepEval

⁴Evaluating AI agents: Real-world lessons from building agentic systems at Amazon

⁵AI Agent Evaluation: Metrics, Traces, Human Review, and Workflows

⁶How to Evaluate AI Agents: Metrics, Benchmarks & Testing 2026

⁷Evaluating LLM Agent Adherence to Hierarchical Safety Principles: A Lightweight Benchmark for Probing Foundational Controllability Components