Your Agents Need a Save Button - Hamza Tahir, ZenML

한 줄 핵심

에이전트도 문서처럼 실행 상태를 저장·체크포인트·재생할 수 있어야, 실제 프로덕션 실행을 바탕으로 모델 변경·도구 변경의 영향을 검증하고 더 싸고 빠른 선택을 안전하게 만들 수 있다.

시간별 요약

1. 0:00
   에이전트 실행에는 문서의 Ctrl+S 같은 저장 기능이 없어서, 상태·파일·코드 결정이 사라지고 읽기 전용 trace만 남는다. 실행 상태와 trace를 연결해 두어야 왜 그런 동작을 했는지 되짚고 다른 선택이 더 나았는지 검토할 수 있다.
2. 2:00
   저장된 상태가 있으면 replay가 가능해져 모델 교체, tool mocking, 의도적 성능 저하 같은 what-if 실험을 할 수 있다. 핵심 흐름은 production trace와 runtime checkpoint를 결합해 checkpoint replay diff decide로 닫힌 루프를 만드는 것이다.
3. 5:02
   Kitaru는 harness 아래에 durable runtime을 두고, 코드 실행·artifact·환경까지 checkpoint로 남겨 replay와 비교를 가능하게 한다. 같은 실행에서 GPT-5 Nano로 모델을 바꾸거나 lookup policy를 바꾸어도, 이전 checkpoint는 건너뛰고 변경 지점부터 다시 실행할 수 있다.
4. 9:02
   diff 기능으로 baseline과 replay 분기를 나란히 비교하면 같은 상태에서 무엇이 달라졌고 최종 결과가 어떻게 바뀌었는지 바로 볼 수 있다. 단일 사례에서는 더 싸고 비슷해 보일 수 있지만, 실제로는 비용·결과·artifact를 함께 봐야 정책 변경의 영향이 드러난다.
5. 11:04
   한두 건의 replay는 부족하므로 비용이 큰 run이나 긴 run 같은 cohort를 모아 일괄 replay하고, JSON report를 MCP server나 agent로 분석하는 방식이 유효하다. 마지막 결론은 샘플 하나가 아니라 cohort 전체 기준으로 내려야 하며, 이 사례에서는 cheaper model로 바꾸지 않는 쪽이 맞았다.

실무 인사이트

• 에이전트 운영에서는 trace만 남길 것이 아니라 checkpoint 가능한 runtime을 함께 설계해야 재현성 있는 디버깅과 의사결정이 가능하다.
• 모델 교체 최적화는 단일 실행의 비용 절감이 아니라 cohort 단위의 성공률·정확도·처리 시간까지 함께 비교해야 한다.
• 평가 루프를 자동화하려면 replay → diff → 분석 → 배포 판단까지를 하나의 생산 파이프라인으로 묶는 것이 효과적이다.