프로덕션에서 AI 에이전트를 평가하는 방법: 실시간 트레이스에서 사용하는 3계층 시스템
2026년 6월 Techsy 콘텐츠 파이프라인의 한 실행에서 에이전트가 완벽해 보이는 블로그 포스트를 생성했고, 최종 출력 스코어도 이를 통과시켰습니다. 깨끗해 보였습니다. 그런데 3단계 앞에서 brief-creator가 잘못된 내부 링크 조회 도구를 호출했기 때문에 클러스터 링크의 절반이 아무것도 가리키지 않았습니다. 프로덕션에서 AI 에이전트를 평가하는 방법을 안다는 것은 에이전트가 도달한 최종 답변만 점수 매기는 것이 아니라 에이전트가 취한 전체 경로를 점수 매기는 것입니다.
주요 요점:
- 최종 답변만이 아니라 전체 궤적을 점수 매기기: 잘못된 경로를 통한 올바른 답변도 실패입니다.
- 도구 호출을 세 축에서 검증하기: 올바른 도구, 올바른 인수, 올바른 단계.
- 오프라인과 온라인에서 동일한 메트릭을 실행하며, 실시간 프로덕션 트레이스에서 지속적인 루프로 실행.
- 정확도 점수만이 아니라 보안 취약점(탈옥, PII, 도구 오용)에 따라 배포 게이팅하기.
AI 에이전트 프로덕션 평가가 LLM 평가와 다른 이유는?
프로덕션에서 AI 에이전트를 평가하는 것이 모델 평가보다 어려운 이유는 에이전트가 여러 단계를 거치고, 외부 도구를 호출하며, 실제 상태를 변경하고, 모든 것을 비결정적으로 수행하기 때문입니다. 동일한 입력도 실행할 때마다 다른 도구 호출 시퀀스를 생성할 수 있으므로, 초기의 한 번의 잘못된 단계가 이후의 모든 단계를 손상시킬 수 있습니다.
이 가이드는 당신이 이미 일반적인 LLM 평가를 알고 있다고 가정합니다. 모르신다면 우리의 완전한 LLM 평가 가이드에서 시작한 다음, 모델이 에이전트가 되면 무엇이 변하는지 알기 위해 돌아오세요. (평가하려는 에이전트를 여전히 구축 중이신가요? 최고의 AI 에이전트 프레임워크에 대한 우리의 개요는 그 아래의 계층을 다룹니다.)
LLM이 스스로 행동하기 시작하는 순간 네 가지가 깨집니다:
- 다중 단계. 지원 에이전트는 지식 기반을 검색하고, 주문 API를 호출한 다음, 회신을 작성할 수 있습니다. 회신만 점수를 매기면 그것을 결정한 두 단계에는 맹목입니다.
- 비결정적. 온도, 모델 가중치 업데이트, 도구 지연은 동일한 요청이 각 실행마다 다른 경로를 취하도록 합니다. 당신의 평가는 움직이는 목표를 견뎌야 합니다.
- 상태 저장. 에이전트는 데이터베이스에 쓰고, 이메일을 보내고, 주문을 환불합니다. 잘못된 작업은 나쁜 문장이 아니라 되돌릴 수 없는 부작용입니다.
- 복합. 12단계 실행에서 온화하게 잘못된 2단계가 모든 하류를 오염시키고, 최종 답변도 여전히 좋아 보일 수 있습니다.
Galileo의 2026년 2월 평가 엔지니어링 현황 보고서는 500명 이상의 실무자를 조사했으며, 84.9%의 팀이 배포 후 6개월 이내에 AI 인시던트를 겪었다는 것을 발견했습니다. Anthropic의 엔지니어링 팀은 에이전트 평가에 대한 그들의 에세이에서 명확히 말합니다: 에이전트는 최종 출력만이 아니라 단계, 도구, 의도에서 실패합니다.
잘못된 궤적을 통해 올바른 답변을 반환하는 에이전트는 통과하지 못했습니다. 조용히 실패했으며, 행운의 복구가 다음에 일어나지 않을 때 시끄럽게 실패할 것입니다.
프로덕션 AI 에이전트에 실제로 중요한 메트릭은 무엇인가?
프로덕션 에이전트에 가장 중요한 메트릭은 정확도를 초과합니다: 작업 성공률, 성공적인 작업당 비용, 지연 백분위수, 도구 호출 정확도, 성실성, 인간 개입률, 드리프트, 안전 게이트 통과율. 이들을 함께 사용하면 단일 출력 점수가 놓치는 자동적이고 비결정적인 실패를 포착할 수 있습니다.
이것들은 우리가 실제로 우리 실행에서 보는 8가지 메트릭입니다. 이들이 최종 답변이 얼마나 잘 읽히는지에 관심이 얼마나 적은지 주목하세요:
이들 중 대부분은 LLM-as-a-judge (한 모델이 다른 모델의 출력을 점수 매기는)를 기댑니다. 이것은 표준 트릭이고 확장하지만, 노이즈가 있습니다: 판사는 종종 에이전트의 맹점을 공유하므로 그 점수를 신호로 취급하되 절대적 진리로 여기지 마세요. 우리는 섹션 7에서 판사를 보정하는 것으로 돌아갑니다.
한 메트릭이 특별한 언급을 받습니다. 성공적인 작업당 비용은 예산 검토를 견디는 숫자입니다. 순수 작업당 비용은 저렴한 실패를 보상하며, 에이전트가 빠르고 잘못 포기한다면 스프레드시트에서 효율적으로 보입니다.
최종 답변 대신 에이전트의 궤적을 점수 매기는 방법은?
에이전트의 궤적을 점수 매기려면 트레이스를 평가합니다: 에이전트가 생성한 모든 추론 단계, 도구 호출, 중간 출력의 정렬된 기록입니다. Span 수준 평가는 각 개별 단계(span)를 점수 매기므로 전체 실행이 실패했다는 것만 알아내는 대신 정확히 어느 단계에서 실패했는지 지적할 수 있습니다.
트레이스를 추론을 위한 스택 트레이스처럼 생각하세요. 각 span은 한 단계입니다: 검색, 도구 호출, 하위 에이전트 인계. 관찰성이 이러한 span을 캡처합니다; 평가가 그들을 점수 매깁니다. (아직 트레이싱 없나요? 우리의 AI 관찰성 가이드는 점수 매기기가 위에 앉아있는 보기 계층을 다루며, LangGraph, CrewAI, OpenAI Agents SDK의 우리의 비교는 각각에서 트레이스가 무엇처럼 보이는지를 보여줍니다.)
엔드포인트 대신 모든 span을 점수 매기는 이유는? 복합 오류입니다. 2단계가 잘못된 문서를 검색하면, 3단계부터 12단계까지 쓰레기를 기반으로 구축되며, 행운의 최종 표현도 여전히 출력만 확인하는 것을 통과할 수 있습니다. Span 수준 평가는 실행이 어딘가 실패했다는 것뿐만 아니라 2단계에서 실패했다고 말해줍니다.
다음은 프레임워크 불가지론적 버전 (트레이스 객체에 대한 순수 어설션), 그 다음 DeepEval 바로가기 (트레이스 기반 Task Completion 메트릭):
프레임워크 불가지론적 어설션은 어렵고 결정적인 검사에 좋습니다. Task Completion은 성공이 동등성 검사보다 퍼지할 때 도달하는 것입니다: 의도한 작업과 달성한 결과를 트레이스에서 추출하고 그들이 얼마나 잘 정렬되는지를 점수 매깁니다.
에이전트가 올바른 도구를 호출했는지 검증하는 방법은?
에이전트의 도구 호출을 검증하려면 세 가지를 별도로 확인하세요: 도구 선택 (올바른 도구를 선택했는가), 인수 정확도 (올바른 매개변수와 값을 전달했는가), 실행 경로 유효성 (올바른 단계에서 올바른 순서로 그 도구를 호출했는가). 올바른 최종 답변과 잘못된 도구 호출은 아직 표면화되지 않은 버그입니다.
이것은 단일 가장 에이전트 특정 평가이며, 거의 아무도 깊이 있게 다루지 않는 평가입니다. 다중 에이전트 도구 사용 평가는 세 가지 질문으로 나뉩니다:
- 선택. 사용 가능한 도구 중에서 에이전트가 올바른 도구를 선택했는가? 도구를 호출하는 것은 올바른 도구를 호출하는 것과 같지 않습니다.
- 인수. 올바른 매개변수를 전달했는가? 올바른 도구이지만 잘못된 슬러그 또는 형식이 잘못된 날짜는 여전히 실패입니다.
- 실행 경로. 올바른 단계에서 올바른 순서로 그 도구를 호출했는가? 주문을 확인하기 전에 환불하는 것은 올바른 도구이지만 잘못된 순서입니다.
DeepEval의 Tool Correctness 메트릭은 세 가지를 모두 처리합니다: tools_called를 expected_tools와 비교하고, 입력 매개변수를 일치시킬 수 있으며, should_consider_ordering=True를 사용하면 시퀀스도 등급을 매깁니다.
그 0.0은 우리가 우리 파이프라인에서 포착한 정확한 실패입니다: 에이전트는 sitemap_search에 도달했는데 예상 도구는 internal_link_lookup이었습니다. 완성된 포스트는 여전히 출력 점수를 통과했습니다. 도구 호출 메트릭이 손상된 경로를 플래그 지은 유일한 것이었습니다.
실시간 프로덕션 트레이스에서 평가를 온라인으로 실행하는 방법은?
온라인 평가는 배포 전 테스트 세트에서만 평가하는 대신 실시간으로 실시간 프로덕션 트레이스에 대해 메트릭을 실행합니다. 이것은 3계층 시스템의 세 번째 계층입니다: 황금 세트에서 오프라인 테스트, 배포 전 QA 게이트, 그 다음 라이브 트래픽에서 온라인 평가, 루프가 계속 개선되도록 프로덕션 트레이스는 데이터 세트로 다시 큐레이팅됩니다.
오프라인 테스트는 회귀를 배포 전에 포착합니다. 하지만 에이전트는 프로덕션에서 입력을 만나며 어떤 황금 세트도 예상하지 못했으므로, 동일한 메트릭은 출시 후 계속 실행되어야 합니다. 다이어그램 위쪽이 매핑하는 전체 루프는 다음과 같습니다:
- 오프라인. 황금 데이터 세트에서 CI의 메트릭을 실행합니다. 회귀에서 빌드에 실패합니다.
- 배포 전 QA 게이트. 인간이 소유한 체크포인트: 이것이 정확도 기준과 안전 기준을 통과하는가 (섹션 6)?
- 온라인. 동일한 메트릭을 사용하여 실시간으로 라이브 프로덕션 트레이스를 점수 매깁니다.
...