계층 1: 핵심 주제 및 전체 요약
이 발표의 핵심 주장은 단순하다. AI 에이전트에는 "저장(save)" 기능이 없다. 문서 편집기는 1980년대부터 Ctrl+S(또는 Cmd+S)로 작업 상태를 영속화해왔고, 자동 저장까지 당연하게 여겨진다. 그런데 에이전트는 지금 이 순간에도 그런 영속 상태 저장 메커니즘 없이 실행되고 있다.
현재 업계가 가진 가장 가까운 대안은 "트레이스(trace)"다. 트레이스는 에이전트가 어떤 툴을 어떤 입출력으로 호출했는지 기록하는 텔레메트리 데이터다. 시작점으로는 나쁘지 않지만, 결정적인 문제는 트레이스가 실제 런타임과 완전히 단절되어 있다는 점이다. 상태 변수, 진행 중이던 파일시스템, 코드가 내부적으로 내린 결정, 코드 자체 — 이 모든 것이 유실되고, 실행이 끝난 뒤 저 멀리 떨어진 별도 도구에 읽기 전용 스냅샷으로만 남는다.
발표자 Hamza Tahir(ZenML 공동창업자)는 이 문제를 "관측성 스팬(OTel)과 실제 코드 실행 사이의 연결 고리가 업계에 빠져 있다"고 정리한다. 그가 제안하는 해법은 하니스(harness)/프레임워크 아래에 상태를 체크포인트하는 영속 런타임을 두고, 트레이스에 코드 실행 정보를 결합해 시스템 상태를 완전히 복원 가능하게 만드는 것이다. 이런 시스템이 프로덕션에 이미 갖춰져 있다면, 별도 작업 없이도 "무엇을 바꿨으면 더 저렴하고 빠르고 정확했을까?"라는 질문에 답할 수 있는 데이터가 이미 쌓여 있는 셈이다.
발표는 크게 세 부분으로 구성된다: (1) 왜 저장/리플레이가 필요한가에 대한 개념 설명, (2) ZenML이 새로 출시한 오픈소스 런타임 도구 Kitaru를 이용한 라이브 데모(단일 리플레이 → 툴 모킹 → diff 비교 → 코호트 분석), (3) "저장 버튼"을 프로덕션 워크플로우에 통합하는 플레이북과 주의사항(나이브한 모델 교체의 함정).
계층 2: 섹션별 상세 내용
2-1. 문제 정의 — 트레이스는 왜 부족한가
- 트레이스는 툴 호출의 입력/출력만 담은 읽기 전용(read-only) 텔레메트리다.
- 상태 변수, 인플라이트 파일시스템, 코드의 내부 분기 로직 등은 트레이스에 전혀 담기지 않는다.
- 트레이스는 실행이 끝난 뒤에야 별도 관측성 도구에 "스탬프"처럼 기록되며, 실제 코드가 실행되는 위치와는 물리적으로 분리되어 있다.
- 결과적으로 "왜 이렇게 행동했는가?", "다르게 했다면 어땠을까?"라는 질문에 답할 수 있는 정보가 남지 않는다.
2-2. 왜 "저장"이 필요한가 — 리플레이가 여는 질문들
저장(체크포인트) 기능이 있으면 과거의 특정 시점으로 돌아가 "만약(what-if)" 시나리오를 실험할 수 있다. 예시로 제시된 질문들:
- 모델을 교체하면 어떻게 될까? (예: 더 저렴한 오픈소스 모델로 스왑)
- 특정 툴의 응답을 모킹(mock)하면 결과가 어떻게 바뀔까?
- 의도적으로 성능을 저하시키면 시스템이 어떻게 반응하는가?
이런 질문들은 오직 **상태(state)**가 보존되어 있을 때만 답할 수 있다. Tahir는 이런 요구를 충족하는 새로운 스택 카테고리가 등장하고 있다고 설명한다 — 하니스/프레임워크 위가 아니라 아래에 위치하는 영속 런타임 계층으로, 트레이스와 실제 코드 실행을 결합해 시스템의 완전한 상태를 재구성한다.
2-3. 실전 예시 — 챠지백 환불 에이전트
고객의 챠지백(chargeback) 분쟁 후 환불을 처리하는 에이전트를 예로 들었다. 런타임이 각 단계를 체크포인트(자동 저장)해두었다면 다음을 사후에 검증할 수 있다:
- 주문 상태가 예상대로 바뀌었는가?
- 요청이 사람에게 에스컬레이션되었어야 했는가?
- 더 작은(저렴한) 모델로도 같은 결정을 내렸을 것인가?
2-4. 방법론 — Checkpoint → Replay → Diff → Decide
"체크포인트 → 리플레이 → 디프 → 결정(ship/route/hold)"이 핵심 루프다. 이는 결국 **프로덕션 트레이스/체크포인트를 활용한 평가(eval)**로, 별도의 합성 테스트셋이 아니라 실제 프로덕션에서 일어난 실행을 기반으로 한다는 점이 중요하다.
DoorDash 사례: 2026년 6월 1일 블로그 포스트에서 DoorDash는 고객 봇을 리플레이하는 시뮬레이션 환경을 구축했다고 밝혔다. 기존에 몇 시간씩 걸리던 what-if 분석 작업이 5분으로 단축되었고, 수백 건의 시뮬레이션을 통해 환각(hallucination)을 90% 줄였으며, 그 결과가 실제 프로덕션에서 관측된 값과 2%p 이내로 근접했다. 시뮬레이션이 실제 발생한 일에 기반(grounded)하고 있기 때문에 신뢰도가 높다는 것이 요지다.
2-5. 라이브 데모 — Kitaru
발표자는 ZenML이 최근 출시한 오픈소스 도구 Kitaru(자막 인식상 발음 표기, ZenML 팀이 만든 런타임 레이어)로 실제 데모를 진행했다. Kitaru는 하니스 아래에 위치하는 런타임 계층으로, 트레이스와 연결되어 체크포인트/리플레이를 수행한다.
데모 1 — 단일 체크포인트 리플레이 (모델 교체)
- 고객 요청을 보고 필요시 사람에게 에스컬레이션하는 지원(support) 에이전트를 시연.
- UI에서 각 툴 호출을 타임라인으로 볼 수 있고, 특정 체크포인트(툴 호출)를 클릭하면 설정, 실행 위치, 코드, 입출력 아티팩트를 확인 가능.
- 코드·아티팩트·실행 환경(Docker 이미지 또는 샌드박스)이 체크포인트 사이사이 전부 스냅샷되어 있음.
- 특정 체크포인트(71번) 이후부터 모델을 더 저렴한 GPT-5 Nano로 바꿔 터미널에서 리플레이 명령을 실행.
- 결과: 이전 체크포인트 3개는 이미 상태가 저장되어 있으므로 건너뛰고(skip), 변경된 지점부터만 재실행됨 — 전체를 처음부터 다시 돌릴 필요가 없음.
데모 2 — 툴 모킹 (정책 변경)
- 이번엔 모델은 그대로 두고,
lookup policy툴을 다른 함수로 모킹해서 다른 정책 값을 반환하도록 변경. - 정책이 바뀌면 이후 결정이 어떻게 달라지는지 실험.
- 결과적으로 로그와 아티팩트가 원본과 달라짐을 확인.
데모 3 — Diff 비교
- Kitaru의
diff명령으로 원본 실행 ID와 두 리플레이를 나란히 비교하는 URL을 생성. - 비교 뷰에서 확인된 내용: 처음 부분(공유되는 체크포인트)은 완전히 동일(스킵됨). 세 번째 리플레이(정책 변경)에서만 툴 호출 시점부터 상태가 갈라짐.
- 최종 아티팩트를 비교하면: 원본과 두 번째 리플레이(모델만 교체)는 둘 다 "검토 필요(needs review)"로 판단했지만, 세 번째 리플레이(정책 변경)는 "안전하게 답변 가능(safe to answer)"으로 결론이 달라짐.
- 비용 측면에서는 모델을 바꾼 리플레이들이 입출력 토큰 수 기준으로 더 저렴했음.
데모 4 — 코호트(cohort) 단위 분석
- 단일 리플레이만으로는 부족하다는 문제의식에서, 비용 기준으로 정렬한 여러 실행(예: 가장 비쌌던 것들)을 묶어 코호트를 구성.
replay mini같은 명령으로 특정 체크포인트 지점부터 코호트 전체에 동일한 변경(모델 교체 등)을 일괄 적용해 리플레이.- 결과를 JSON으로 출력 — 실행 건수가 많아지면 UI로 일일이 비교하기 어렵기 때문.
- Kitaru MCP 서버를 통해 LLM(에이전트)에게 이 JSON 리포트를 읽고 분석/이상 징후 플래깅을 맡김. 수십 건이면 사람이 볼 수 있지만 수천 건이 되면 에이전트·MCP 조합이 필수라는 게 발표자의 관점.
2-6. 경고 — 나이브한 모델 교체의 함정
- BrainTrust의 연구: 단순히 더 저렴한 모델로 교체하고 비용 한 축만 보면, 겉보기엔 빠르고 싸 보이지만 실제로 지원 요청 해결률이 떨어지는 "가짜 경제성(false economy)"이 발생할 수 있다. 비용과 가치(결과) 사이의 트레이드오프를 함께 봐야 한다.
- tau-bench 기준: 60%의 성공률을 보이는 모델도 자기 일관성(self-consistency)은 약 25%(4번 중 1번)에 불과하다. 즉 리플레이 한 번은 일화(anecdote)일 뿐이며, 개별 사례가 아니라 모집단·스케일 단위로 봐야 실제 경향을 파악할 수 있다.
2-7. 라이브 코호트 분석 결과 (발표 중 실시간 진행)
발표 중간에 실행해둔 코호트 리플레이(비용 기준 상위 케이스들에 대해 모델을 저렴한 것으로 교체) 분석 결과가 발표 말미에 공개되었다. 결론은 "배포하지 말 것(don't ship)". 단일 리플레이에서는 결과가 동일하면서 더 저렴해 보였지만, 다수의 지원 케이스 전체 코호트로 보면 저렴한 모델로 바꿨을 때 품질이 충분히 담보되지 않는다는 결론이 나왔다. 발표자는 이것이 특정 사례에 국한된 것일 수 있고 각자의 데이터셋에 따라 다를 수 있다는 점도 함께 언급했다.
계층 3: 핵심 발언 및 개념 정리
"Have you ever looked at your agent execution and asked yourself the question, why did it do that? ... Well, you can do all these things if your agents have a save button." — 발표를 여는 핵심 문제 제기.
"The only thing we have which is closest is a trace. ... it is actually very disconnected from the runtime in which these agents actually execute." — 트레이스의 근본적 한계.
"Save allows you to replay. You can go back in history and ask the what if question." — 저장 기능의 효용을 한 문장으로 요약.
"Checkpoint. Replay. Diff. Decide." (발표자가 반복 강조한 방법론 4단계)
"One replay is just an anecdote and having a cohort analysis is way way way better." — 단일 리플레이의 한계와 코호트 분석의 필요성.
"The verdict is don't ship." — 실시간 코호트 분석 데모의 최종 결론.
핵심 개념 정리
| 개념 | 설명 |
|---|---|
| 트레이스(Trace) | 툴 호출의 입출력을 기록한 읽기 전용 텔레메트리. 상태·코드·파일시스템은 미포함 |
| 체크포인트(Checkpoint) | 상태(코드, 아티팩트, 실행 환경)를 스냅샷으로 저장하는 지점. 문서의 "저장"에 해당 |
| 리플레이(Replay) | 특정 체크포인트부터 조건을 바꿔(모델 교체, 툴 모킹 등) 재실행하는 것. 이전 체크포인트는 재사용(skip)됨 |
| 코호트 분석(Cohort analysis) | 단일 실행이 아니라 여러 실행(예: 비용 상위 케이스)을 묶어 동일한 변경을 일괄 적용해 통계적으로 판단하는 것 |
| Kitaru | ZenML이 출시한 오픈소스 런타임 도구. 하니스 아래 계층에서 체크포인트/리플레이/diff/MCP 분석을 제공 |
| 가짜 경제성(False economy) | 비용만 보고 모델을 교체했을 때 실제로는 품질 저하로 손해를 보는 현상 (BrainTrust 연구) |
계층 4: 실행 포인트 및 시사점
- 트레이스만으로는 부족하다는 점을 인지할 것: 현재 프로덕션 관측성 스택이 OTel 트레이스만 남기고 있다면, 실제 재현·리플레이가 불가능한 "박제된 로그"에 불과하다. 상태를 체크포인트하는 런타임 계층 도입을 검토할 가치가 있다.
- 모델/툴 교체는 반드시 코호트 단위로 검증할 것: 한두 건의 리플레이에서 결과가 좋아 보인다고 바로 배포하지 말 것. tau-bench 사례처럼 성공률이 높아 보이는 모델도 자기 일관성이 낮을 수 있다.
- 비용 최적화(모델 다운그레이드)를 검토할 때 품질 지표를 반드시 함께 볼 것: BrainTrust의 "가짜 경제성" 경고처럼, 토큰 비용만 보고 판단하면 실제 해결률·정확도 저하를 놓칠 수 있다.
- 프로덕션 실행을 그대로 실험 자산으로 활용할 것: 합성 테스트셋을 새로 만들기보다, 실제 프로덕션에서 발생한 비싸거나 길거나 위험했던(risky) 실행들을 코호트로 뽑아 리플레이하는 것이 훨씬 근거 있는 개선 방법이다.
- LLM/에이전트를 분석 자동화에 활용할 것: 리플레이 건수가 수백~수천 건으로 늘어나면 사람이 UI로 일일이 비교하기 어렵다. MCP 서버 등을 통해 LLM에게 JSON 리포트 분석과 이상 징후 플래깅을 맡기는 워크플로우를 고려할 수 있다.
- 최종 결정은 사람이 내리도록(human-in-the-loop) 루프를 설계할 것: 자동화를 최대한 밀어붙이더라도, ship/route/hold의 최종 판단 지점에는 사람이 남아있어야 한다는 것이 발표자의 권고다.
- 참고 도구: ZenML의 오픈소스 런타임 Kitaru가 이 워크플로우(체크포인트/리플레이/diff/MCP 분석)를 무료로 제공한다 — 유사 니즈가 있다면 벤치마킹 대상으로 검토할 만하다.