Agent를 운영한다는 것: trace, evaluation, optimization

Agent가 답변을 만들고 tool을 호출할 수 있다는 것은 시작점입니다. 운영에서는 왜 실패했는지 설명하고, 같은 조건을 재현하고, 수정이 다른 기능을 망가뜨리지 않았는지 검증하고, 실제 traffic에서도 개선이 유지되는지 확인해야 합니다.

It runs
→ It works correctly
→ It works efficiently
→ It improves continuously

“Agent가 틀렸다”는 final score 하나로는 고칠 위치를 알 수 없습니다. Tool 선택이 틀렸는지, argument가 틀렸는지, 404 result를 성공으로 해석했는지, 올바른 result를 final synthesis에서 왜곡했는지를 trajectory로 분해해야 합니다.

Raw prompt와 tool result를 무조건 저장하면 개인정보와 secret이 trace backend에 쌓입니다. 기본 span은 metadata와 redacted summary를 사용하고, 제한된 표본에서만 payload를 보관하는 정책이 필요합니다.

JSON 형식과 tool argument, file 생성, DB state diff, citation id처럼 deterministic하게 확인할 수 있는 것은 code로 먼저 검사합니다. 의미 품질만 rubric, LLM judge, 표본 human review를 조합합니다.

Token이 줄었다는 사실만으로 성공한 최적화가 아닙니다. Evaluation baseline을 통과하면서 latency와 cost, step 수를 줄여야 합니다. Trace에서 hotspot을 찾고 한 component만 바꾼 뒤 regression eval을 통과해야 배포합니다.

1. Filter: Error, user correction, low score, high cost trace를 후보로 모읍니다.
2. Label: Failure component와 expected behavior, privacy-safe input을 기록합니다.
3. Dataset: 중복을 제거하고 대표 case를 versioned regression set에 넣습니다.
4. Patch: Prompt, tool, retrieval, policy 중 원인 component만 수정합니다.
5. Experiment: Baseline과 candidate를 offline replay와 shadow traffic으로 비교합니다.
6. Canary: 작은 traffic에서 quality, latency, cost, safety를 관찰한 뒤 확대합니다.

trace → agent_version + prompt_version + model_config
      + tool_schema_version + index_version + policy_version
      → reproducible regression case

Version이 없으면 같은 input을 재현해도 다른 system을 테스트하게 됩니다. Agent, prompt, model, tool schema, retrieval index, memory policy, evaluator version을 trace와 dataset에 함께 남겨야 원인과 개선을 설명할 수 있습니다.

• Run과 child operation을 연결하는 trace id와 stable span taxonomy가 있습니다.
• Prompt, model, tool, index, policy version을 재현할 수 있습니다.
• Payload 저장과 redaction, retention, 접근 권한 정책이 있습니다.
• Critical behavior는 deterministic checker와 regression set으로 보호됩니다.
• Quality와 latency, cost, safety를 같은 experiment에서 비교합니다.
• Canary, rollback, post-deploy monitoring이 자동화돼 있습니다.