프로덕션 환경에서 AI 에이전트 평가하기: 라이브 트레이스에서 사용하는 3계층 시스템
프로덕션 환경에서 AI 에이전트를 평가한다는 것은 단순히 최종 답변이 아닌, 라이브 트래픽 상에서 에이전트의 전체 다단계 수행 경로(trajectory)를 점수화하는 것을 의미합니다. 이는 각 추론 단계를 확인하고, 올바른 도구가 올바른 인수로 호출되었는지 검증하며, 출시 후 작업 성공률, 비용, 안전성을 지속적으로 모니터링하는 과정입니다. 에이전트는 조용히 그리고 비결정적으로(non-deterministically) 실패하기 때문입니다.
2026년 6월, 저희 Techsy 콘텐츠 파이프라인을 자체 운영하던 중 한 사건이 있었습니다. 에이전트는 완벽해 보이는 블로그 게시물을 배포했고, 최종 출력 점수는 이를 통과시켰습니다. 깔끔했습니다. 하지만 세 단계 전으로 거슬러 올라가 보니, 브리프 생성기(brief-creator)가 잘못된 내부 링크 조회 도구를 호출했던 것입니다. 그 결과 클러스터 링크의 절반이 어디로도 연결되지 않는 죽은 링크가 되었습니다. 프로덕션 환경에서 AI 에이전트를 평가하는 방법을 안다는 것은 에이전트가 우연히 도달한 답변만이 아니라, 에이전트가 택한 전체 경로를 점수화한다는 뜻입니다.
핵심 요약:
- 최종 답변뿐만 아니라 전체 수행 경로를 점수화하세요: 잘못된 경로로 얻은 정답도 결국 실패입니다.
- 도구 호출을 세 가지 축으로 검증하세요: 올바른 도구, 올바른 인수, 올바른 단계.
- 동일한 지표를 오프라인과 온라인(라이브 프로덕션 트레이스)에서 연속적인 루프 형태로 실행하세요.
- 낮은 정확도 점수뿐만 아니라 보안 취약점(탈옥, 개인정보 유출, 도구 오용)을 기준으로 배포를 차단(gate)하세요.
프로덕션 환경에서 AI 에이전트를 평가하는 것이 LLM 평가와 다른 이유는 무엇인가요?
프로덕션 환경에서 AI 에이전트를 평가하는 것은 모델 평가보다 더 어렵습니다. 에이전트는 여러 단계를 거치고, 외부 도구를 호출하며, 실제 상태(state)를 변경하기 때문입니다. 게다가 이 모든 과정이 비결정적으로 일어납니다. 동일한 입력이라도 실행마다 다른 도구 호출 순서를 만들어낼 수 있으므로, 초기의 작은 실수 하나가 이후의 모든 단계를 오염시킬 수 있습니다.
이 가이드는 일반적인 LLM 평가에 대한 지식이 있다고 가정합니다. 만약 그렇지 않다면, 먼저 저희의 LLM 평가 완전 가이드를 읽고 난 후, 모델이 에이전트가 되었을 때 무엇이 달라지는지 확인하시기 바랍니다. (지금 평가하려는 에이전트를 아직 구축 중인가요? 저희의 최고의 AI 에이전트 프레임워크 요약이 하위 계층에 대해 다루고 있습니다.)
LLM이 스스로 행동을 시작하는 순간, 네 가지 요소가 무너집니다:
- 다단계(Multi-step). 고객 지원 에이전트는 지식 베이스를 검색하고, 주문 API를 호출한 후, 회신 초안을 작성할 수 있습니다. 회신만 점수화하면 그 결정을 내린 앞선 두 단계를 놓치게 됩니다.
- 비결정성(Non-deterministic). 온도(temperature), 모델 가중치 업데이트, 도구 지연 시간 등으로 인해 동일한 요청이라도 실행마다 다른 경로를 택합니다. 평가 시스템은 끊임없이 변하는 표적을 견뎌내야 합니다.
- 상태 유지(Stateful). 에이전트는 데이터베이스에 기록하고, 이메일을 보내며, 주문을 환불합니다. 잘못된 행동은 나쁜 문장이 아니라, 되돌릴 수 없는 부작용(side effect)입니다.
- 오류 누적(Compounding). 12단계 실행 중 2단계에서의 사소한 오류는 하류의 모든 과정을 오염시키며, 최종 답변은 여전히 멀쩡해 보일 수 있습니다.
500명 이상의 실무자를 대상으로 한 Galileo의 2026년 2월 '평가 엔지니어링 현황(State of Eval Engineering)' 보고서에 따르면, 84.9%의 팀이 출시 후 6개월 이내에 AI 사고를 경험했다고 합니다. Anthropic의 엔지니어링 팀은 에이전트 평가에 관한 에세이에서 이렇게 명확히 말합니다: 에이전트는 최종 출력뿐만 아니라 단계, 도구, 의도 전반에서 실패합니다.
잘못된 경로를 통해 정답을 반환한 에이전트는 통과한 것이 아닙니다. 그것은 **조용히 실패(failed quietly)**한 것이며, 다음 번에 운 좋은 회복이 일어나지 않을 때 크게 실패할 것입니다.
프로덕션 환경의 AI 에이전트에게 실제로 중요한 지표는 무엇인가요?
프로덕션 환경의 에이전트에게 가장 중요한 지표는 정확도를 넘어섭니다: 작업 성공률, 성공한 작업당 비용, 지연 시간 백분위수, 도구 호출 정확도, 충실도(faithfulness), 인간 개입률, 드리프트(drift), 그리고 보안 게이트 통과율입니다. 이러한 AI 에이전트 평가 지표들은 단일 출력 점수가 놓치는 조용하고 비결정적인 실패를 포착합니다.
다음은 저희가 자체 실행에서 실제로 모니터링하는 8가지 지표입니다. 최종 답변의 문장이 얼마나 잘 읽히는지에 관심을 두는 지표가 얼마나 적은지 주목하세요:
| 지표 | 측정 대상 | 점수화 방법 | 주의사항 |
|---|---|---|---|
| 작업 성공/완료율 | 에이전트가 사용자의 목표를 달성했는가 | 전체 트레이스에 대한 LLM 심사관(LLM-as-judge) | 심사관이 에이전트의 맹점을 공유할 수 있음 |
| 성공한 작업당 비용 | 실제로 달성한 목표당 소요 금액 | 토큰 + 도구 비용을 성공 횟수로 나눔 | 저렴한 실패가 효율적으로 보일 수 있음 |
| 지연 시간 p50/p90/p99 | 종단 간(end-to-end) 및 단계별 응답 시간 | 트레이스 타임스탬프 | 꼬리 부분(p99)에서 사용자 이탈 발생 |
| 도구 호출 정확도 | 올바른 도구 plus 올바른 인수 | 결정론적 어서션(assertion, 아래 참조) | 도구를 호출했다고 해서 올바르게 호출한 것은 아님 |
| 충실도/근거성 | 검색되거나 관찰된 데이터로 출력이 뒷받침되는가 | 심사관 또는 참조 검사 | 자신감 있는 환각(hallucination) |
| 인간 개입률 | 사람이 개입해야 했던 빈도 | 개입 횟수를 실행 횟수로 나눔 | 폴백(fallback)에 대한silent 과잉 의존 |
| 드리프트 | 시간 경과 또는 모델 업데이트에 따른 지표 감소 | 롤링 온라인 평가 | 출시 당시에는 괜찮았지만 지금은 아닐 수 있음 |
| 보안 게이트 통과율 | 보안 게이트를 통과한 실행 비율 | 적대적/레드팀 평가 | 한 번의 침해는 낮은 점수 하나가 아님 |
이 대부분은 LLM-as-a-judge(한 모델이 다른 모델의 출력을 점수화)에 의존합니다. 이는 표준적인 기술이며 확장성이 좋지만 노이즈가 많습니다. 심사관이 종종 에이전트의 맹점을 공유하기 때문에, 그 점수를 절대적인 진리가 아닌 신호(signal)로 취급해야 합니다. 7절에서 심사관 보정(calibrating)에 대해 다시 다루겠습니다.
하나의 지표는 특별히 언급할 가치가 있습니다. 성공한 작업당 비용은 예산 검토에서 살아남는 숫자입니다. 단순한 작업당 비용은 저렴한 실패를 보상하는데, 빠르게 그리고 잘못하게 포기하는 에이전트가 스프레드시트상에서는 효율적으로 보이기 때문입니다.
최종 답변 대신 에이전트의 수행 경로(trajectory)를 어떻게 점수화하나요?
에이전트의 수행 경로를 점수화하려면 트레이스(trace)를 평가해야 합니다. 트레이스는 에이전트가 생성한 모든 추론 단계, 도구 호출, 중간 출력물의 순서화된 기록입니다. 스팬 수준(span-level) 평가는 각 개별 단계(스팬)를 점수화하여, 전체 실행이 잘못되었다는 사실만 아는 것이 아니라 정확히 어느 단계에서 실패했는지 pinpoint할 수 있게 해줍니다.
트레이스를 추론을 위한 스택 트레이스(stack trace)라고 생각하세요. 각 **스팬(span)**은 하나의 단계입니다: 검색, 도구 호출, 하위 에이전트 핸드오프 등. 관찰 가능성(observability)이 이러한 스팬을 캡처하고, 평가가 이를 점수화합니다. (아직 트레이싱을 도입하지 않았나요? 저희의 AI 관찰 가능성 가이드가 점수화가其上에 얹혀지는 모니터링 계층을 다루며, LangGraph, CrewAI 및 OpenAI Agents SDK 비교는 각 환경에서 트레이스가 어떻게 보이는지 보여줍니다.)
왜 엔드포인트 대신 모든 스팬을 점수화할까요? 오류 누적 때문입니다. 2단계에서 잘못된 문서를 검색하면, 3단계부터 12단계까지는 쓰레기 데이터를 기반으로 구축되며, 운 좋은 최종 문장 구성이 출력 전용 검사를 통과해 버릴 수 있습니다. 스팬 수준 점수화는 실행이 somewhere에서 실패했다는 것이 아니라, 2단계에서 실패했다는 사실을 알려줍니다.
먼저 프레임워크에 구애받지 않는 버전(트레이스 객체에 대한 plain 어서션)을 소개하고, 이어 DeepEval의 트레이스 기반 작업 완료(Task Completion) 지표를 사용한 shortcuts을 소개합니다:
# Framework-agnostic: did the trajectory reach the goal via valid steps?
def score_trace(trace):
assert trace.steps[-1].status == "success", "final step failed"
assert all(s.error is None for s in trace.steps), "a mid-run step errored"
assert "internal_link_lookup" in [s.tool for s in trace.steps], "skipped a required step"
# DeepEval: score the whole multi-step trace for task completion
from deepeval.tracing import observe
from deepeval.metrics import TaskCompletionMetric
@observe(metrics=[TaskCompletionMetric(threshold=0.7, model="gpt-4o")])
def content_pipeline(topic):
... # your researcher -> brief -> writer -> validator run
return final_post프레임워크 독립적 어서션은 하드코딩된 결정론적 검사에 적합합니다. 작업 완료(Task Completion)는 성공 여부가 단순 동일성 검사보다 모호할(fuzzier) 때 사용합니다. 이는 트레이스에서 의도된 작업과 달성된 결과를 추출하여 얼마나 잘 일치하는지 점수화합니다.
에이전트가 올바른 도구를 호출했는지 어떻게 검증하나요?
에이전트의 도구 호출을 검증하려면 세 가지를 별도로 확인해야 합니다: 도구 선택(올바른 도구를 선택했는가), 인수 정확성(올바른 매개변수와 값을 전달했는가), 그리고 실행 경로 유효성(올바른 단계와 순서로 해당 도구를 호출했는가). 잘못된 도구 호출에도 불구하고 최종 답변이 통과했다면, 그것은 아직 표면화되지 않은 버그입니다.
이는 에이전트 특화 평가 중 가장 중요한 항목이며, 거의 아무도 깊이 있게 다루지 않는 부분입니다. 다중 에이전트 도구 사용 평가는 세 가지 질문으로 분해됩니다:
- 선택(Selection). 사용 가능한 도구 중에서 에이전트가 올바른 것을 선택했는가? 어떤 도구를 호출하는 것과 올바른 도구를 호출하는 것은 다릅니다.
- 인수(Arguments). 올바른 매개변수를 전달했는가? 올바른 도구라도 잘못된
slug나 형식이 잘못된 날짜를 전달하면 여전히 실패입니다. - 실행 경로(Execution path). 올바른 단계와 순서로 해당 도구를 호출했는가? 주문 확인 전에 환불하는 것은 올바른 도구를 잘못된 순서로 사용한 경우입니다.
DeepEval의 도구 정확도(Tool Correctness) 지표는 이 세 가지를 모두 처리합니다. 이는 tools_called를 expected_tools와 비교하고, 입력 매개변수를 매칭할 수 있으며, should_consider_ordering=True 설정 시 순서도 평가합니다.
# Framework-agnostic: right tool, right args, right step
call = trace.steps[2].tool_call
assert call.name == "internal_link_lookup", f"wrong tool: {call.name}"
assert call.args == {"slug": "llm-evals-guide"}, f"wrong args: {call.args}"
# DeepEval: score tool selection + arguments, order-aware
from deepeval.test_case import LLMTestCase, ToolCall, ToolCallParams
from deepeval.metrics import ToolCorrectnessMetric
test_case = LLMTestCase(
input="Add an internal link to the LLM evals guide",
actual_output="...",
tools_called=[ToolCall(name="sitemap_search")],
expected_tools=[ToolCall(name="internal_link_lookup")],
)
metric = ToolCorrectnessMetric(
evaluation_params=[ToolCallParams.INPUT_PARAMETERS],
should_consider_ordering=True,
)
metric.measure(test_case)
print(metric.score, metric.reason) # 0.0 "expected tool not called"그 0.0 점수는 저희 파이프라인에서 포착한 정확한 실패 사례입니다. 에이전트는 예상 도구가 internal_link_lookup였음에도 불구하고 sitemap_search를 사용했습니다. 완성된 게시물은 여전히 출력 점수를 통과했습니다. 도구 호출 지표만이 깨진 경로를 flagged한 유일한 요소였습니다.
라이브 프로덕션 트레이스에서 온라인 평가를 어떻게 실행하나요?
온라인 평가는 배포 전 테스트 세트에만 의존하는 것이 아니라, 실시간으로 라이브 프로덕션 트레이스에 대해 지표를 실행합니다. 이는 3계층 시스템의 세 번째 층입니다: 골든 세트(golden set)에 대한 오프라인 테스트, 배포 전 QA 게이트, 그리고 라이브 트래픽에 대한 온라인 평가. 여기서 프로덕션 트레이스는 데이터셋으로 다시 큐레이션되어 루프가 지속적으로 개선되도록 합니다.
오프라인 테스트는 출시 전 회귀(regression)를 포착합니다. 하지만 에이전트는 프로덕션 환경에서 골든 세트가 예상하지 못한 입력을 마주하므로, 출시 후에도 동일한 지표를 계속 실행해야 합니다. 상단 다이어그램이 매핑한 전체 루프는 다음과 같습니다:
- 오프라인. CI에서 골든 데이터셋에 대해 지표를 실행합니다. 회귀 발생 시 빌드를 실패 처리합니다.
- 배포 전 QA 게이트. 인간이 소유한 체크포인트입니다. 이것이 정확도 기준 및 보안 기준(6절 참조)을 충족합니까?
- 온라인. 동일한 지표로 실시간 라이브 프로덕션 트레이스를 점수화합니다.
- 큐레이션(Curate). 실제 트레이스(특히 실패 사례)를 자동으로 수집하여 평가 데이터셋으로 다시 넣습니다.
- 재실행. 골든 세트가 첫날에 손으로 작성한 20개 예제가 아닌, 현실로부터 성장합니다.
온라인 평가를 연결하는 것은 트레이싱과 동일한 계측(instrumentation)에 지표 수집을 추가하는 것입니다. Confident AI는 라이브 트레이스에 대해 DeepEval의 50개 이상 스코어러를 실행하며, OpenTelemetry와 호환되므로 LangGraph, CrewAI, OpenAI 및 Vercel AI SDK는 별도의 어댑터 없이 export할 수 있습니다:
# Same metrics you ran in dev, now scoring live production traffic
from deepeval.tracing import observe, update_current_span
from deepeval.test_case import LLMTestCase
@observe(metric_collection="Production Agent Quality")
def support_agent(query: str) -> str:
answer = run_agent(query) # your live agent
update_current_span(
test_case=LLMTestCase(input=query, actual_output=answer)
)
return answer
# The collection's metrics now run on every trace, in real time.보상은 큐레이션 단계에서 옵니다. 모든 실제 프로덕션 실패가 영구적인 회귀 테스트가 되므로, 스위트(suite)는 정적인 스냅샷이 아니라 에이전트가 실제 현장에서 마주하는 것을 추적하기 시작합니다.
정확도가 아닌 보안을 기준으로 게이트(Gate)를 설정하세요
보안 게이트는 낮은 정확도 점수가 아닌, 취약점을 기준으로 배포를 차단합니다. 에이전트의 경우 이는 탈옥(jailbreak), 도구 오용, 개인정보(PII) 유출을 탐지하는 적대적(adversarial) 및 레드팀(red-team) 평가를 의미하며, 배포 전과 온라인에서 모두 실행됩니다. 탈옥은 평균으로 덮어버릴 수 있는 낮은 점수가 아닙니다. 그것은 **출시 차단(release blocker)**입니다.
모든 경쟁사는 안전성을 여러 지표 중 하나로 취급합니다. 이는 실제 시스템을 대상으로 실제 도구를 호출하도록 설득될 수 있는 에이전트에게는 역방향 접근입니다. 따라서 게이트를 분리하세요: 정확도 게이트는 점수를 평균화하지만, 보안 게이트는 적대적 probing이 하나라도 통과했는지 여부를 기준으로 pass/fail 판정을 내립니다. 먼저 에이전트의 실패 모드를 감사자들이 이미 인식하고 있는 프레임워크에 매핑하여 시작하세요:
| 에이전트 실패 모드 | 프레임워크 참조 |
|---|---|
| 프롬프트 인젝션 / 탈옥 | OWASP LLM01: 프롬프트 인젝션 |
| 민감 데이터 / PII 유출 | OWASP LLM02: 민감 정보 노출 |
| 도구 오용 / 과도한 대리권 | OWASP LLM06: 과도한 대리권 |
| 위험 관리, 매핑, 측정, 관리 | NIST AI RMF 핵심 기능 |
| 적대적 전술 및 기법 | MITRE ATLAS 전술 매트릭스 |
그런 다음 이러한 카테고리에 대해 적대적 평가를 실행하세요. OWASP의 LLM 애플리케이션 Top 10, NIST AI 위험 관리 프레임워크, 그리고 MITRE ATLAS는 공통 어휘를 제공하며, 레드테밍은 테스트를 제공합니다. DeepEval背后 팀에서 만든 오픈소스 레드테밍 프레임워크인 DeepTeam은 OWASP, NIST AI RMF 및 MITRE ATLAS에 매핑된 8개 카테고리, 20개 이상의 공격 벡터에 걸쳐 120개 이상의 취약점을 제공합니다.
도구 측면에서 한 가지 솔직한 뉘앙스가 있습니다. DeepTeam OSS는 무료 경로이며 취약점 세트를 커버합니다. 반면 Confident AI의 관리형(platform-in) 레드테밍 모듈은 Enterprise 티어 기능으로, $9.99 Starter 플랜에 포함되지 않습니다. 어느 쪽이든, 레드테밍을 출시 전 한 번 실행하는 사후 생각이 아닌, 일급 게이트(first-class gate)로 연결하세요.
저희 파이프라인에서 이를 실행하며 포착한 것들
저희는 자체 다중 에이전트 콘텐츠 파이프라인(연구자, 브리프 생성기, 콘텐츠 작성자, 검증자 등 4개의 에이전트가 체인으로 작업을 전달)에서 이 3계층 시스템을 실행합니다. 2026년 6월과 7월 동안 DeepEval v4.0.5를 이 파이프라인에 연결하고 Confident AI 워크스페이스와 연동한 것이 서두의 실패 사례를 포착한 방법입니다. 스코어러 출력은 다음과 같았습니다:
ToolCorrectnessMetric score=0.00 threshold=0.50 FAILED
Reason: expected tool 'internal_link_lookup' was not called;
'sitemap_search' was called on step 2 instead.게시물은 이미 출력 품질 점수를 통과한 상태였습니다. 완성된 기사에서 잘못된 점은 없어 보였습니다. 오직 경로 평가(trajectory eval)만이 깨진 단계를 발견했으며, 이는 출력 전용 검사가 놓치는 전형적인 버그 유형이었습니다.
r/LLMDevs, r/MachineLearning 또는 r/LocalLLaMA에서 실무자들을 팔로우한다면, 같은 불만 사항들이 끊임없이 제기되는 것을 볼 수 있으며, 이는 3계층 시스템이 포착하도록 설계된 내용과 거의 1:1로 일치합니다:
- 월요일에는 작동하는데 수요일에는 실패하는 문제. 비결정성으로 인해 동일한 입력이 실행마다 다른 경로를 택하므로, 팀들은 불안정한(flaky) 평가를 무시하는 법을 배우게 됩니다. 라이브 트레이스의 스팬 수준 점수화는 더 큰 골든 세트보다 효과적입니다.
- 골든 데이터셋 피로감. 단일 추론 변경으로 쓸모없게 되는 스위트를 손으로 라벨링하는 데 몇 주를 소비합니다. 프로덕션 트레이스의 자동 큐레이션은 정적 파일을 손으로 유지하는 것보다 낫습니다.
- LLM 심사관에 대한 불신. 반복되는 불만은 심사관이 에이전트의 맹점을 공유한다는 것이며, 이것이 바로 팀들이 인간을 루프 안에 유지(human-in-the-loop)하는 이유입니다.
마지막 점이 중요합니다. 도메인 전문가들은 심사관이 확신하지 못하는 출력을 주석 처리(annotation)하며, 이러한 라벨은 지표 정렬(metric alignment)로 다시 피드백됩니다. 이는 저희의 Confident AI 리뷰와 에이전트 메모리 처리 방식 근처에서 설명한 것과 동일한 폐쇄 루프입니다. 심사관은 확장성을 제공하고, 인간은 정직함을 유지합니다.
어떤 플랫폼이 귀하의 스택에 적합한가요?
모든 팀에 맞는 단일 도구는 없으므로, 현재 상황에 맞춰 플랫폼을 선택하세요. 다음은 이 가이드가 중점을 둔 다섯 가지 기능과 진입 방법에 따른 주요 옵션 비교입니다:
| 플랫폼 | 트레이스 + 스팬 점수화 | 도구 호출 확인 | 온라인 평가 | 레드테밍 / 보안 | 노코드 팀 접근 | OSS / 진입 가격 |
|---|---|---|---|---|---|---|
| Confident AI | 예 | 예 | 예 | 예 | 예 | $9.99/사용자/월 + 무료 티어 |
| DeepEval | 예 | 예 | 부분적 | 예 (DeepTeam経由) | 아니오 | 오픈소스 |
| Langfuse | 예 | 부분적 | 예 | 아니오 | 부분적 | 오픈소스 |
| LangSmith | 예 | 예 | 예 | 아니오 | 부분적 | 무료 + 유료 |
| Arize Phoenix | 예 | 부분적 | 예 | 아니오 | 아니오 | 오픈소스 |
| Braintrust | 예 | 예 | 예 | 아니오 | 부분적 | 무료 + 유료 |
| Promptfoo | 부분적 | 예 | 부분적 | 예 | 아니오 | 오픈소스 |
| Ragas | 부분적 | 아니오 | 아니오 | 아니오 | 아니오 | 오픈소스 |
| Galileo | 예 | 부분적 | 예 | 부분적 | 예 | 유료 |
| Maxim | 예 | 예 | 예 | 부분적 | 예 | 무료 + 유료 |
| W&B Weave | 예 | 부분적 | 예 | 아니오 | 부분적 | 무료 + 유료 |
엔터프라이즈 및 크로스팀 사용 사례에서 최상위에 위치한 것은 Confident AI입니다. 이는 전체 품질 라이프사이클(개발 시간 평가, 프로덕션 관찰 가능성, DeepTeam을 통한 적대적 보안, 조직 전체 품질 게이트)을 한 곳에서 커버하며, 진정한 차별화 요소는 노코드 팀 접근입니다. 엔지니어가 한 번 연결하면, PM, QA 및 도메인 전문가가 직접 전체 평가 사이클을 실행할 수 있습니다. 진입 가격은 무료 티어가 있는 $9.99/사용자/월입니다. 이는 저희 LLM 평가 도구 요약에서 1위, AI 관찰 가능성 플랫폼 비교에서 2위를 차지했으므로, 저희 목록에서 상위권을 차지한 것이 이번이 처음은 아닙니다.
별도로 위치하는 것은 DeepEval로, 동일한 팀에서 구축한 선도적인 오픈소스 프레임워크이며, 50개 이상의 스코어러와 pytest 네이티브 테스트를 제공합니다. Confident AI는 플랫폼이고, DeepEval은 OSS 라이브러리이며, 그것의 축소판이 아닙니다. 다음과 같은 경우에 선택하세요:
- DeepEval: 오픈소스 표준을 원하며 Python과 pytest 환경에서 작업하는 경우.
- Langfuse: 자체 호스팅 가능한 오픈소스 트레이싱을 원하는 경우.
- LangSmith: 스택이 LangChain과 LangGraph로 끝까지 구성되어 있는 경우.
- Arize Phoenix: 완전히 오픈소스인 OpenTelemetry 네이티브 트레이싱을 원하는 경우.
- Braintrust: 관대한 무료 티어와 함께 all-in-one 평가 및 실험을 원하는 경우.
- Promptfoo: CLI 환경에서 작업하며 동일한 도구에서 레드테밍을 원하는 경우.
- Ragas: 에이전트가 사실상 RAG 파이프라인이며 검색 특화 지표를 원하는 경우.
- Galileo: 관리형 환각 및 품질 인덱스를 박스 그대로(out of the box) 원하는 경우.
- Maxim: 다중 턴(multi-turn) 에이전트를 위한 시뮬레이션 및 평가 워크플로우를 원하는 경우.
- W&B Weave: 이미 Weights & Biases를 사용 중이며 학습 실행(training runs) 옆에 트레이싱을 원하는 경우.
Confident AI의 한 가지 솔직한 제한 사항: 관리형 레드테밍 모듈과 온프레미스(on-prem) 배포는 Enterprise 티어이며, 미국/유럽 데이터 거주(data residency)는 Team/Enterprise 기능으로 가입 시 보편적으로 toggling할 수 있는 기능이 아닙니다. 하나의 에이전트를 출시하는 솔로 개발자는 DeepEval OSS로 무료로 시작하고, 전체 팀이 평가를 실행해야 할 때 플랫폼을 추가할 수 있습니다.
저자 소개
Mert Batur Gurbuz, Techsy.io 공동 창업자 (버밍엄 대학교). Mert Batur Gurbuz는 B2B 고객을 위해 AI 에이전트, 자동화 시스템 및 음성/SDR 파이프라인을 제공하는 Techsy.io의 공동 창업자입니다. 그는 버밍엄 대학교에서 공부하며, Techsy 팀이 프로덕션에서 실제로 사용하는 LLM 툴링 스택에 대해 글을 씁니다. LinkedIn에서 연결하세요.
자주 묻는 질문
AI 에이전트 평가란 무엇인가요?
AI 에이전트 평가는 자율 에이전트의 최종 답변뿐만 아니라 전체 행동을 점수화하는 관행입니다. 이는 다단계 수행 경로, 호출된 도구, 작업 성공률, 비용, 지연 시간 및 안전성을 측정합니다. 에이전트는 비결정적으로 행동하고 실제 상태를 변경하므로, 평가는 개발 단계와 라이브 프로덕션 트래픽에서 지속적으로 실행됩니다.
에이전트의 최종 출력 대신 수행 경로(trajectory)를 어떻게 평가하나요?
최종 출력 평가는 마지막 답변만 점수화합니다. 경로 평가는 전체 트레이스, 즉 모든 추론 단계, 도구 호출 및 중간 결과를 점수화합니다. 스팬 수준 점수화는 각 단계를 등급화하여 실패한 정확한 단계를 찾을 수 있게 해줍니다. 실행은 깨진 경로를 통해 정답을 생성할 수 있으며, 이는 경로 평가가 포착하지만 출력 전용 검사는 놓칩니다.
에이전트가 올바른 도구를 호출했는지 어떻게 검증하나요?
세 가지를 별도로 확인하세요: 도구 선택(작업에 적합한 도구), 인수 정확성(올바른 매개변수와 값), 그리고 실행 경로 유효성(올바른 단계와 순서). DeepEval의 도구 정확도 지표와 같은 프레임워크는 실제로 호출된 도구를 예상 도구와 비교하고, 입력 매개변수를 매칭하며, 활성화 시 호출 순서를 등급화할 수 있습니다.
프로덕션 환경의 AI 에이전트에게 가장 중요한 지표는 무엇인가요?
작업 성공률과 성공한 작업당 비용이 가장 중요하며, 그다음으로 지연 시간 백분위수(p50, p90, p99), 도구 호출 정확도, 충실도, 인간 개입률, 드리프트, 보안 게이트 통과율이 중요합니다. 단순 작업당 비용보다는 성공한 작업당 비용이 더 중요한데, 이는 단순 작업당 비용이 빠르고 저렴하게 실패하는 에이전트를 조용히 보상하기 때문입니다.
오프라인과 온라인 에이전트 평가의 차이점은 무엇인가요?
오프라인 평가는 배포 전, 일반적으로 CI에서 고정된 골든 데이터셋에 대해 지표를 실행하여 회귀를 포착합니다. 온라인 평가는 출시 후 실시간으로 라이브 프로덕션 트레이스에 대해 동일한 지표를 실행합니다. 둘 다 필요합니다: 오프라인은 알려진 실패 모드를 포착하고, 온라인은 골든 세트가 예상하지 못한 입력을 포착하여 데이터셋으로 다시 피드백합니다.
에이전트 평가를 얼마나 자주 재실행해야 하나요?
프롬프트, 모델 또는 도구 변경 시마다 CI에서 게이트된 오프라인 평가를 실행하세요. 드리프트와 모델 가중치 업데이트는 배포 사이에 에이전트를 조용히 저하시키므로, 라이브 트래픽에 대해 온라인 평가를 지속적으로 실행하세요. 프로덕션에서 새로운 실패 모드가 나타날 때마다 골든 데이터셋을 재큐레이션하여, 스위트가 첫날에 작성한 예제가 아닌 현실을 추적하도록 하세요.
출시 전 탈옥(jailbreak)과 PII 유출을 어떻게 포착하나요?
배포 전 게이트로서 적대적 레드팀 평가를 실행하고, 온라인에서도 계속 실행하세요. 실패 모드를 OWASP LLM Top 10, NIST AI RMF 및 MITRE ATLAS에 매핑한 후, DeepTeam과 같은 오픈소스 프레임워크로 각 카테고리에 대해 공격을 시뮬레이션하세요. 낮은 평균 점수가 아닌, 통과한 취약점이 있을 경우 출시를 차단하세요.
AI 에이전트 평가 플랫폼을 직접 구축해야 할까요, 구매해야 할까요?
솔로 개발자이거나 코드에 익숙한 소규모 엔지니어링 팀이라면 오픈소스 도구(지표용 DeepEval, CLI 테스트 및 레드테밍용 Promptfoo)로 구축하세요. 전체 팀이 조직 전체의 노코드 접근, 관리형 보안 테스트 및 프로젝트 전반에 표준화된 프로덕션 관찰 가능성을 필요로 할 때는 Confident AI와 같은 플랫폼을 구매하세요. 대부분의 팀은 OSS로 시작하여 점차 전환합니다.
에이전트 점수화에 LLM-as-a-judge는 신뢰할 수 있나요?
유용하지만 노이즈가 있습니다. LLM 심사관은 수천 개의 트레이스를 저렴하게 확장할 수 있지만, 비결정적이며 종종 에이전트의 맹점을 공유하므로 그럴듯하지만 잘못된 답변에 도장을 찍을(rubber-stamp) 수 있습니다. 샘플에 대해 인간 또는 도메인 전문가 라벨과 비교하여 보정하고, 점수를 방향성 신호로 취급하며, 가능한 경우 결정론적 검사를 통해 고위험 결정을 게이트하세요.
한 마디로 요약한 3계층 시스템
답변뿐만 아니라 경로를 점수화하세요. 도구 호출을 세 가지 축으로 검증하세요: 올바른 도구, 올바른 인수, 올바른 단계. 동일한 지표를 오프라인과 온라인에서 라이브 트레이스로 실행하며, 실제 실패를 데이터셋으로 다시 큐레이션하는 루프를 만드세요. 그리고 정확도가 아닌 보안을 기준으로 배포를 게이트하세요.
가장 고통스러운 계층부터 시작하세요: 맹목적으로 출시하고 있다면 온라인 평가를 먼저 연결하세요; 안전하지 않게 출시하고 있다면 보안 게이트를 먼저 구축하세요. 오픈소스 DeepEval과 Promptfoo로 구축하거나, 전체 팀이 노코드 접근과 관리형 보안을 필요로 할 때 Confident AI와 같은 플랫폼을 구매하세요. 그리고 엔지니어가 전체 루프를 연결해주는 것을 선호한다면, 그것은 저희 팀이 매주 하는 일의 종류입니다.