From Agent Traces to Agent Simulations — Rustem Feyzkhanov, Snorkel AI

한 줄 핵심

에이전트 평가는 실제 생산 환경을 최대한 닮은 시뮬레이션 벤치마크로 해야 하며, 생산 트레이스를 반복 가능한 실험으로 바꿔야 모델·프롬프트·툴 전반을 제대로 비교하고 개선할 수 있다.

시간별 요약

1. 0:01
   핵심 주장은 에이전트 평가는 정적인 공용 벤치마크가 아니라 생산 트레이스에서 계속 채워지는 회사별 벤치마크로 해야 한다는 점이다. 이렇게 해야 배포, 개선, 비교를 안정적으로 반복할 수 있다.
2. 2:00
   트레이스는 실패 원인 파악에는 유용하지만, DB 상태나 툴 버전이 달라져 동일 조건 비교가 어렵다. 생산 트레이스를 과제로 바꾼 오프라인 시뮬레이션은 성공률뿐 아니라 cost, latency, retries까지 반복 가능하게 비교하게 해준다.
3. 3:00
   공용 벤치마크는 범용 방향성을 주지만, 실제 배포에는 회사 도메인, 정책, 툴, 전체 생산 환경을 반영한 private benchmark가 필요하다. 따라서 모델 성능만 보지 말고 프롬프트, 추론 수준, 툴 가용성까지 포함한 전체 시스템을 테스트해야 한다.
4. 7:00
   벤치마크 과제는 instruction, environment, Oracle solution, verifiers, metadata로 구성되며, environment는 실제 생산의 축소판처럼 동작해야 한다. 사용자도 LLM으로 시뮬레이션하고, 장기 과제는 단계별 프롬프트와 검증으로 나눠 조기 종료할 수 있어야 한다.
5. 11:02
   검증은 deterministic check, LLM-as-a-judge, 하네스/에이전트 판정, 그리고 필요할 때만 subject matter expert 리뷰를 조합하는 방식이 현실적이다. 벤치마크 자체도 코드처럼 다뤄 CI로 품질을 검증하고, 충돌·과최적화·실패율 변동을 먼저 잡아야 한다.
6. 14:00
   운영 루프는 observability 트레이스로 벤치마크를 확장하고, 시뮬레이션 러너로 새 구성을 시험한 뒤, 통과하면 배포하는 구조여야 한다. 프롬프트에 모든 예외를 몰아넣기보다 문제 원인에 맞게 hardening, skill, structured output으로 분리해 고쳐야 한다.

실무 인사이트

• 에이전트 성능 평가는 단일 pass rate보다 생산 비용, 지연 시간, 재시도 횟수를 함께 보는 다차원 지표로 설계해야 배포 판단이 정확해진다.
• 벤치마크는 한 번 만드는 산출물이 아니라 실패 사례를 계속 흡수하는 운영 자산이므로, observability와 실험 기록을 연결한 파이프라인이 필수다.
• 실제 개선 효과를 높이려면 프롬프트 수정부터 하기보다 문제의 원인이 컨텍스트, 스킬, 출력 스키마, 환경 중 어디에 있는지 먼저 분리해 고쳐야 한다.