현장에서 에이전트 품질 논의는 자주 한 문장으로 끝난다. “새 프롬프트가 더 낫다.” 문제는 그 다음이다. 더 낫다는 판단이 데모 화면 몇 개에서 나왔는지, 실제 업무 입력 묶음에서 나왔는지, 도구 호출 실패와 지연 비용까지 포함했는지 확인되지 않는다.
에이전트는 챗봇보다 비교가 어렵다. 답변만 바뀌는 것이 아니라 계획, 검색, tool call, memory 사용, 에스컬레이션 판단이 함께 바뀐다. 그래서 에이전트 A/B 테스트는 마케팅 실험이 아니라 릴리스 통제다.
A/B 테스트는 트래픽 분할 전에 끝나야 한다
에이전트 변경을 곧바로 사용자 트래픽에 태우면 운영이 실험장이 된다. AX Ops에서는 A/B를 세 단계로 나눈다.
| 단계 | 목적 | 비교 대상 | 통과 기준 |
|---|---|---|---|
| Offline eval | 회귀 차단 | golden dataset, 과거 trace | 기존 정답 업무를 깨지 않는다 |
| Shadow run | 운영 조건 검증 | 실제 입력 복제, 사용자 미노출 | tool path와 지연이 허용 범위 안에 있다 |
| Controlled rollout | 제한 배포 | 일부 업무·사용자·채널 | 장애 시 즉시 되돌린다 |
OpenAI의 최신 evaluation 가이드도 생성형 AI의 변동성 때문에 전통적 테스트만으로는 부족하며, production 환경에서 품질과 신뢰성을 측정하는 eval이 필요하다고 정리한다. LangChain의 Agent Evals 문서도 prompt, tool, model 변경 시 회귀를 잡기 위해 trajectory를 평가 대상으로 둔다.
에이전트 A/B의 단위는 “답변”이 아니라 “업무 수행 궤적”이다.
비교 항목을 프롬프트 하나로 좁혀야 한다
실패한 A/B의 공통점은 여러 변수를 한 번에 바꾸는 것이다. 프롬프트를 고치면서 모델을 바꾸고, 검색 top-k를 바꾸고, tool schema까지 고친다. 결과가 좋아져도 무엇이 좋아졌는지 모른다. 나빠지면 더 모른다.
실험 티켓에는 최소 네 가지를 고정한다.
- 변경 변수: system prompt, model, tool description, memory policy 중 하나
- 고정 변수: temperature, retrieval 설정, tool 권한, fallback 정책
- 평가 데이터: 대표 업무 입력, 경계 사례, 과거 실패 trace
- 판정 기준: 품질, 안전, 지연, 비용, 에스컬레이션 정확도
Braintrust는 2025년 11월 글에서 prompt A/B를 prompt variant, model, parameter를 나란히 실행하고 quality score, latency, cost, token usage를 함께 추적하는 방식으로 설명한다. 이 관점은 현장에도 그대로 맞다. “응답이 좋아 보인다”는 판정은 배포 기준이 아니다.
LLM judge만으로 결재선을 넘기지 않는다
LLM-as-a-judge는 필요하다. 하지만 단독 결재권자는 아니다. 특히 사내 규정, 계약 문구, 고객 커뮤니케이션, 정산 업무처럼 오류 비용이 큰 영역에서는 사람이 만든 rubric과 샘플 리뷰가 함께 있어야 한다.
평가자는 세 겹으로 둔다. 첫째, 코드 평가자는 형식·금칙어·필수 필드 누락을 잡는다. 둘째, LLM judge는 관련성·충실성·요약 품질 같은 반복 판정을 맡는다. 셋째, 업무 전문가는 경계 사례와 고위험 trace를 확인한다.
Arize AX 문서는 offline eval을 배포 전 CI/CD 회귀 체크로, online eval을 production trace 위의 지속 평가로 분리한다. 이 분리가 중요하다. 사전 평가는 배포를 막는 문이고, 온라인 평가는 운영 중 품질 저하를 빨리 발견하는 레이더다.
안전한 비교는 AX Ops 절차로 남아야 한다
에이전트 A/B 테스트의 산출물은 승자 프롬프트가 아니다. 산출물은 재사용 가능한 평가 데이터셋, 버전이 남은 실험 기록, 실패 유형 taxonomy, rollback 조건이다. 그래야 다음 모델 교체와 다음 프롬프트 수정이 다시 감이 아니라 절차가 된다.
AX Ops에서 에이전트 변경은 다음 순서로 묶는다. 변경 가설을 쓰고, trace 기반 데이터셋을 만들고, offline eval을 통과시키고, shadow run으로 tool trajectory를 확인하고, 제한 배포 후 online eval로 감시한다. 이 순서를 건너뛰면 빠른 배포가 아니라 느린 장애 대응이 된다.
참고와 실행 기준
- OpenAI, Evaluation best practices, 2026년 확인: https://platform.openai.com/docs/guides/evaluation-best-practices
- OpenAI, Agent evals, 2026년 확인: https://platform.openai.com/docs/guides/agent-evals
- OpenAI, How evals drive the next chapter in AI for businesses, 2025: https://openai.com/index/evals-drive-next-chapter-of-ai/
- LangChain, Agent Evals, 2026년 확인: https://docs.langchain.com/oss/python/langchain/evals
- Arize AX, Run offline evals on experiments, 2026년 확인: https://arize.com/docs/ax/evaluate/run-evals-on-experiments
- Braintrust, A/B testing for LLM prompts, 2025: https://www.braintrust.dev/articles/ab-testing-llm-prompts
프롬프트와 모델 변경을 운영 절차로 관리하려면 실험 설계부터 trace, eval, rollout까지 한 사이클로 묶어야 한다. AX Ops 방법론 →