현장에서 에이전트 PoC가 흔히 막히는 지점은 모델 성능이 아니다. 데모에서는 잘 움직였는데, 운영 설계 회의에 들어가면 질문이 바뀐다. “왜 저 tool을 호출했나”, “중간 API가 실패하면 무엇을 하나”, “모델을 바꾸면 같은 업무가 깨지나”. 이 질문에 답하지 못하면 에이전트는 업무 시스템이 아니라 시연 자산으로 남는다.
에이전트 테스트는 최종 응답 채점으로 끝나지 않는다. 실행 경로를 남기고, 다시 돌리고, 실패 조건을 주입해야 한다. 이것이 replay·simulation 테스트 설계의 출발점이다.
trace 없이는 테스트가 아니라 감상이다
LLM 에이전트는 여러 번 판단한다. 사용자 입력을 해석하고, memory를 읽고, tool을 고르고, 외부 시스템 응답을 받아 다음 행동을 정한다. 그래서 “정답 문장” 하나만 비교하면 핵심 결함이 가려진다.
trace는 에이전트 실행의 거래명세서다. 최소한 다음 항목을 남겨야 한다.
- 입력 context, system/developer instruction, 선택된 skill 또는 subagent
- tool 호출 순서, 파라미터, 응답, 실패 코드
- memory read/write, retrieval 결과, 권한 승인 여부
- 최종 출력과 사람이 개입한 지점
OpenAI의 trace grading 문서는 trace를 agent 결정, tool call, reasoning step에 대한 구조화된 score와 label의 대상으로 다룬다. Anthropic도 2026년 agent eval 글에서 multi-turn agent는 환경, tool, grading logic까지 포함해 평가해야 한다고 설명한다. 방향은 같다. 관찰 가능한 경로가 있어야 고칠 수 있다.
에이전트 품질은 답변이 아니라 실행 경로에서 무너진다.
replay는 회귀 테스트의 중심이다
Replay 테스트는 이미 발생한 실행을 다시 돌려 변경의 영향을 보는 방식이다. prompt를 고쳤는지, tool schema를 바꿨는지, 모델을 교체했는지는 중요하지 않다. 같은 업무 조건에서 행동이 어떻게 달라졌는지를 비교해야 한다.
| 테스트 층위 | 목적 | 고정할 것 | 비교할 것 |
|---|---|---|---|
| Output replay | 답변 품질 회귀 확인 | 사용자 입력, 참조 정답 | 최종 응답, 형식, 금칙 위반 |
| Trajectory replay | 실행 경로 회귀 확인 | tool 목록, mock 응답 | tool 순서, 파라미터, 중단 조건 |
| State replay | 장기 업무 안정성 확인 | memory, 파일, 세션 상태 | 상태 변경, 재시도, handoff |
| Fork replay | 특정 분기 원인 분석 | 상위 trace | 중간 observation 교체 후 하위 행동 |
핵심은 “다시 실행”과 “다시 평가”를 분리하는 것이다. 모든 replay가 실제 tool을 때릴 필요는 없다. 외부 시스템은 mock으로 고정하고, 모델 호출만 후보 설정으로 바꿔도 많은 회귀가 드러난다. 반대로 tool schema 변경 검증에서는 모델을 고정하고 tool 응답 변형을 넣어야 한다.
2025년 AgentRR 논문은 agent의 환경 상호작용 trace와 내부 decision process를 기록한 뒤 replay하는 방향을 제안했다. OpenAI는 2026년 Agents SDK 업데이트에서 controlled sandbox, snapshotting, rehydration을 강조했다. 운영 테스트 설계도 같은 방향으로 간다. 실행 상태를 저장하지 못하는 에이전트는 안정적으로 검증되지 않는다.
simulation은 실패를 미리 발생시킨다
Replay가 과거 실행을 다시 보는 일이라면, simulation은 아직 일어나지 않은 조건을 만든다. 운영에서는 정상 입력보다 경계 조건이 더 비싸다. API 지연, 권한 거절, 검색 결과 오염, memory 충돌, 사용자의 중간 취소가 에이전트를 흔든다.
Simulation 세트는 세 가지로 시작한다.
- 환경 실패: tool timeout, 429, 500, 빈 응답, 부분 응답
- context 실패: 오래된 문서, 상충 지시, prompt injection 포함 retrieval
- 상태 실패: memory 중복, 이전 세션 잔존, subagent handoff 누락
여기서 합격 기준은 “끝까지 답했다”가 아니다. 위험 tool을 멈췄는지, 사람 승인으로 넘겼는지, 사용자에게 불확실성을 명시했는지, 상태를 오염시키지 않았는지가 기준이다.
OpenTelemetry의 GenAI agent span convention은 agent 호출과 tool 실행을 span 단위로 표현하는 방향을 제시한다. 표준이 아직 development 상태라는 점도 중요하다. 그래서 AX Ops에서는 특정 vendor 화면에 테스트 정의를 가두지 않는다. trace id, span id, tool event, state diff를 내부 표준으로 먼저 잡고 도구를 붙인다.
참고: 테스트 자산이 운영 자산이다
Replay·simulation 테스트는 QA 막판에 붙이는 절차가 아니다. 에이전트 설계 초기에 success criteria, trace schema, mock policy, human escalation rule을 같이 정해야 한다. 그래야 PoC가 끝난 뒤 운영팀이 다시 테스트 체계를 만드는 낭비가 없다.
참고 자료:
- OpenAI, “The next evolution of the Agents SDK”, 2026-04-15: https://openai.com/index/the-next-evolution-of-the-agents-sdk
- OpenAI API Docs, “Trace grading”, 2026 확인: https://platform.openai.com/docs/guides/trace-grading
- Anthropic, “Demystifying evals for AI agents”, 2026-01-09: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
- LangChain, “The agent improvement loop starts with a trace”, 2026-03-31: https://www.langchain.com/blog/traces-start-agent-improvement-loop
- OpenTelemetry, “Semantic Conventions for GenAI agent and framework spans”, 2025-05-01 표기: https://opentelemetry.io/docs/specs/semconv/gen-ai/gen-ai-agent-spans/
- arXiv, “Get Experience from Practice: LLM Agents with Record & Replay”, 2025-05-23: https://arxiv.org/abs/2505.17716
AX Ops에서 에이전트 테스트는 배포 승인 문서가 아니라 운영 학습 루프의 골격이다. replay로 회귀를 잡고, simulation으로 장애를 앞당기고, trace로 개선 대상을 남긴다. 이 구조부터 잡아야 에이전트가 업무 안에서 오래 버틴다. 실행 가능한 테스트 체계부터 설계하려면 AX Ops 방법론 →