Your Agents Need a Save Button - Hamza Tahir, ZenML
📺 원본 영상: Your Agents Need a Save Button - Hamza Tahir, ZenML
🎙️ 채널: AI Engineer
📅 정리 일자: 2026-07-18
⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료, 코드, UI, 슬라이드 등은 포함되지 않을 수 있습니다.
개요
Hamza Tahir는 이 강연에서 AI 에이전트 운영의 핵심 결핍을 “저장 버튼”이라는 익숙한 비유로 설명한다. 문서 편집기에는 수십 년 전부터 Ctrl+S, Command+S, 자동 저장이 있었지만, 에이전트 실행에는 아직 런타임 상태를 저장하고 되돌아가 실험할 수 있는 표준적인 방식이 부족하다는 문제의식이다.
강연의 핵심은 단순한 관측 가능성(Observability)을 넘어선다. Trace는 에이전트가 어떤 도구를 호출했고 어떤 입력과 출력을 만들었는지 보여주지만, 실제 실행 중 존재했던 변수, 파일 시스템 상태, 코드, 산출물, 환경까지 함께 보존하지는 못한다. Hamza는 이 간극을 메우기 위해 체크포인트, 재생, 차이 비교, 의사결정으로 이어지는 운영 루프가 필요하다고 주장한다.
Trace만으로는 부족한 이유
Hamza가 먼저 지적하는 문제는 오늘날 많은 에이전트 시스템이 실행 결과를 사후적으로만 이해한다는 점이다. OpenTelemetry(OTEL) 기반의 span이나 trace는 에이전트가 어떤 순서로 도구를 호출했는지, LLM에 어떤 입력을 보냈고 어떤 출력을 받았는지를 보여주는 데 유용하다. 그러나 그것은 대부분 읽기 전용 기록으로 남으며, 실제 코드가 실행된 런타임과 분리된 관측 데이터로 존재한다.
이 분리는 운영 단계에서 곧 한계가 된다. 에이전트가 특정 결정을 내렸을 때, 개발자나 운영자는 “왜 그렇게 했는가”뿐 아니라 “다르게 했으면 어떻게 되었는가”를 알고 싶어진다. 예를 들어 더 저렴한 모델을 썼다면 같은 결론에 도달했을지, 특정 도구 호출 결과가 달랐다면 판단이 바뀌었을지, 오류가 있는 외부 API 응답에도 시스템이 견딜 수 있었을지를 확인하고 싶어진다. 하지만 런타임 상태가 저장되어 있지 않다면 이런 질문은 실제 실행을 다시 만들거나, 근사적인 테스트 환경을 구성해야만 답할 수 있다.
강연자는 그래서 에이전트에게 필요한 것은 단순한 로그가 아니라 실행 가능한 기억이라고 본다. 저장된 상태가 있어야 과거의 특정 지점으로 돌아가고, 하나의 조건만 바꾼 뒤, 이후 실행이 어떻게 달라지는지를 비교할 수 있다. 이때 “save button”은 단순한 UI 기능이 아니라 에이전트 운영 체계의 근본적인 능력을 뜻한다.
체크포인트가 열어주는 What-if 분석
Hamza는 저장의 실질적 가치를 replay, 즉 재생 가능성에서 찾는다. 에이전트 실행이 체크포인트로 보존되어 있다면 운영자는 과거의 특정 지점으로 돌아가 “만약 이 모델을 썼다면”, “만약 이 도구 응답이 달랐다면”, “만약 정책 데이터가 변경되었다면”이라는 질문을 실험할 수 있다. 이는 단순한 디버깅을 넘어 비용 최적화, 안정성 검증, 정책 변경 시뮬레이션까지 이어진다.
강연에서 제시된 방법론은 “checkpoint, replay, diff, decide”로 요약된다. 먼저 실제 프로덕션 실행을 체크포인트로 저장하고, 그 실행을 특정 조건 아래 재생한 뒤, 원래 실행과 재생 실행의 차이를 비교한다. 마지막으로 그 결과를 바탕으로 모델 교체, 라우팅 변경, 배포 보류 같은 의사결정을 내린다. 중요한 점은 이 과정이 합성 데이터나 임의의 테스트 케이스가 아니라 실제 프로덕션 실행을 기반으로 한다는 것이다.
이 접근법은 에이전트 평가(Evaluation)의 성격도 바꾼다. 기존의 eval은 별도로 만든 테스트셋 위에서 모델이나 프롬프트의 성능을 측정하는 경우가 많았지만, Hamza가 말하는 방식은 실제 운영 trace와 runtime checkpoint를 평가 데이터로 삼는다. 따라서 운영 중 발생한 고비용 실행, 긴 지연 시간이 발생한 실행, 위험한 판단을 한 실행을 cohort로 묶고, 그 집단 전체에 대해 변경안을 재생할 수 있다. 이렇게 하면 단일 사례의 인상에 의존하지 않고, 실제 사용자 흐름에서 변경이 어떤 영향을 미치는지 더 넓게 관찰할 수 있다.
DoorDash 사례가 보여주는 운영형 시뮬레이션
Hamza는 DoorDash 사례를 언급하며 이 방법론이 이미 실무적으로 의미 있는 성과를 내고 있다고 설명한다. 강연에 따르면 DoorDash는 replayed customer bot을 활용한 simulated environment를 만들었고, 과거에는 수 시간 걸리던 what-if 시나리오 검증을 약 5분 수준으로 줄였다고 한다. 또한 수백 개의 시뮬레이션을 통해 hallucination을 90% 줄였으며, 프로덕션에서 관찰한 결과와도 큰 차이가 나지 않았다고 소개한다.
이 사례의 핵심은 시뮬레이션이 허공에서 만들어진 것이 아니라는 점이다. 실제 프로덕션에서 발생한 고객 상호작용과 실행 기록을 기반으로 하기 때문에, 테스트가 현실의 분포에서 크게 벗어나지 않는다. 에이전트 시스템에서 가장 위험한 착각은 데모나 소수의 테스트 케이스에서는 잘 작동하지만 실제 운영에서는 엣지 케이스, 도구 오류, 사용자 언어 변화, 정책 충돌에 취약한 상태다. DoorDash 사례는 replay 기반 시뮬레이션이 이 간극을 줄일 수 있음을 보여주는 사례로 제시된다.
다만 강연자는 이 사례를 만능 해법처럼 다루지는 않는다. replay가 유용하려면 실행 상태가 충분히 보존되어야 하고, 비교할 수 있는 기준선이 있어야 하며, 실험이 단일 사례에 머물러서는 안 된다. 즉 replay는 기술 기능이면서 동시에 운영 방법론이다. 저장된 실행을 어떤 cohort로 묶고, 어떤 변경을 적용하고, 어떤 기준으로 ship 또는 hold를 결정할 것인지가 함께 설계되어야 한다.
Kitaru 데모: 런타임 상태를 저장하고 다시 실행하기
강연의 데모에서는 ZenML 팀이 만든 Kitaru가 소개된다. Hamza는 Kitaru를 harness layer 아래에 위치하는 runtime layer로 설명하며, 기존 에이전트 프레임워크와 trace를 연결하고 실행 중간 상태를 checkpoint로 저장하는 역할을 한다고 말한다.
데모의 예시는 고객 지원 에이전트다. 이 에이전트는 고객 요청을 보고 필요하면 사람에게 escalate하며, chargeback dispute 이후 환불이나 계정 제한 같은 결정을 내리는 것으로 설명된다. Kitaru UI에서는 각 tool call, timeline view, checkpoint별 configuration, 실행된 code, 입력과 출력 artifact, Docker image 또는 sandbox 같은 실행 환경까지 확인할 수 있다. 단순히 “도구를 호출했다”는 기록이 아니라, 그 도구 호출이 어떤 코드와 환경, 어떤 산출물 속에서 이루어졌는지 함께 묶이는 점이 핵심이다.
💡 [영상 참조] 강연자는 이 구간에서 Kitaru UI의 실행 타임라인, tool call, checkpoint, artifact 정보를 화면으로 보여주며 설명합니다. 상세한 UI 구성은 원본 영상을 확인하세요.
이 구조가 있으면 특정 checkpoint 이전의 실행은 그대로 재사용하고, 이후 부분만 새 조건으로 다시 실행할 수 있다. Hamza는 모델을 GPT-5 nano로 바꾸는 예시를 보여주며, 앞선 세 개의 checkpoint가 skip되는 이유를 설명한다. Kitaru가 이미 그 상태를 저장하고 있으므로 처음부터 모든 실행을 반복할 필요가 없고, 바뀐 지점 이후만 다시 실행하면 된다. 이 방식은 비용과 시간을 줄일 뿐 아니라, 어떤 변경이 실제로 결과를 바꾸었는지를 더 명확하게 분리해준다.
모델 교체와 도구 Mocking이 주는 실험 능력
첫 번째 실험은 모델 교체다. Hamza는 특정 tool call 이후 모델을 더 저렴한 GPT-5 nano로 바꾸면 이후 실행이 어떻게 달라지는지 확인한다. 이때 핵심은 운영 환경을 건드리지 않고, 저장된 실행 위에서 하나의 조건만 바꾸어 실험한다는 점이다. 만약 최종 결정이 같고 비용만 줄어든다면 모델 교체는 매력적인 후보가 될 수 있지만, 단일 replay 결과만으로는 충분하지 않다는 점이 뒤에서 다시 강조된다.
두 번째 실험은 tool call의 mock이다. 강연자는 lookup policy tool을 다른 함수로 대체해 정책 조회 결과가 달라졌을 때 에이전트가 어떤 판단을 내리는지 보여준다. 이 방식은 단순히 LLM만 바꾸는 실험보다 더 현실적인 운영 리스크를 검증할 수 있게 한다. 실제 서비스에서는 정책 문서가 업데이트되거나, 외부 시스템 응답이 지연되거나, 특정 API가 오래된 값을 반환하는 일이 생기기 때문이다.
이런 실험이 가능한 이유는 코드베이스와 실행 기록이 분리되어 있지 않기 때문이다. Hamza는 코드가 함께 있으므로 두 개의 호출을 바꾸거나 특정 함수를 mock하는 일이 상대적으로 쉽다고 설명한다. 관측 도구가 코드와 단절되어 있으면 이런 실험은 별도 재현 환경을 만들어야 하지만, runtime checkpoint가 코드와 artifact를 함께 담고 있으면 실험은 훨씬 직접적이고 반복 가능해진다.
Diff View: 결과가 같아 보여도 판단 근거는 달라질 수 있다
Kitaru의 diff 기능은 원본 실행과 여러 replay fork를 나란히 비교하는 장면에서 중요하게 등장한다. Hamza는 원본 실행과 두 개의 replay를 비교하며, 앞부분의 baseline은 동일하게 유지되고 이후 변경 지점부터 실행 흐름이 달라지는 모습을 설명한다. 이처럼 어느 checkpoint까지 동일했고, 어느 지점부터 divergence가 발생했는지를 볼 수 있으면 변경의 영향 범위를 훨씬 정확히 이해할 수 있다.
데모에서는 최종 artifact를 side by side로 비교하며 에이전트가 어떤 결정을 내렸는지도 확인한다. 세 실행 모두 계정 제한 쪽으로 결론을 냈지만, 첫 두 실행은 review가 필요하다고 판단했고, 정책을 바꾼 세 번째 실행은 safe to answer로 판단했다고 설명된다. 겉으로는 비슷한 결과처럼 보이더라도 내부 의사결정의 confidence, escalation 여부, human review 필요성은 달라질 수 있다는 점이 드러난다.
이 대목은 비용 최적화 논의에서 특히 중요하다. 토큰 사용량 기준으로 더 저렴한 실행이 있다고 해서 곧바로 좋은 변경이라고 판단할 수는 없다. 고객 지원 에이전트가 같은 결론을 내렸더라도 review 필요 여부가 바뀌거나, 위험한 케이스를 자동 응답으로 처리한다면 비용 절감은 품질 저하나 운영 리스크로 돌아올 수 있다. 그래서 diff는 단순히 문자열 출력이 같은지 보는 기능이 아니라, 운영상 중요한 의미 차이를 드러내는 도구가 된다.
단일 Replay의 함정과 Cohort 분석의 필요성
강연 후반부에서 Hamza는 단일 replay의 한계를 분명히 짚는다. 하나의 실행에서 더 저렴한 모델이 같은 결과를 냈다고 해서 전체 시스템에 그 모델을 적용해도 된다는 뜻은 아니다. 그는 Braintrust의 연구를 인용하며 naive model swap이 false economy가 될 수 있다고 설명한다. 겉으로는 더 빠르고 저렴해 보이지만, 실제로는 지원 요청을 제대로 해결하지 못해 더 큰 비용을 만들 수 있다는 뜻이다.
또한 Tau-bench와 관련해, 어떤 모델이 60%의 성공률을 보인다고 해도 self-consistency는 약 4분의 1 수준일 수 있다고 언급한다. 이 발언의 취지는 에이전트 평가가 확률적 시스템의 변동성을 고려해야 한다는 데 있다. LLM 기반 에이전트는 같은 입력에서도 조건, 도구 응답, 모델 샘플링, 컨텍스트 변화에 따라 다른 행동을 보일 수 있으므로, 하나의 replay는 사례일 뿐 통계적 근거가 되기 어렵다.
따라서 Hamza는 cohort 분석을 강조한다. 비용이 큰 실행, 지연 시간이 긴 실행, 위험도가 높은 실행처럼 의미 있는 집단을 구성하고, 그 전체에 대해 동일한 변경을 적용해야 더 신뢰할 수 있는 판단이 가능하다. 이 과정은 당연히 비용이 들 수 있으므로 무엇을 replay할지 똑똑하게 고르는 도구와 운영 기준이 필요하다. 결국 replay의 목표는 가능한 모든 조합을 실험하는 것이 아니라, 의사결정에 필요한 충분한 증거를 효율적으로 확보하는 것이다.
MCP와 에이전트 기반 분석의 역할
cohort 크기가 커지면 사람이 UI에서 모든 diff를 눈으로 비교하는 방식은 한계에 부딪힌다. Hamza는 10개 정도는 사람이 볼 수 있지만, 수천 개의 실행을 비교해야 한다면 LLM과 agent를 활용해 분석해야 한다고 말한다. 이때 Kitaru MCP server가 등장한다. replay 결과를 JSON으로 내보내고, MCP를 통해 에이전트가 실행 결과와 artifact를 질의하며 red flag를 찾아내는 방식이다.
이 관점에서 MCP(Model Context Protocol)는 단순한 플러그인 연결 수단이 아니라, runtime을 queryable하게 만드는 인터페이스가 된다. 에이전트가 자신의 실행 기록, artifact, 비용, 판단 결과, divergence 지점을 읽을 수 있다면 운영 분석 자체도 자동화될 수 있다. Hamza는 인간이 마지막 의사결정 루프에 남아 있되, 반복적인 분석과 후보 탐색은 에이전트가 수행하는 방향을 제안한다.
데모의 cohort 분석 결과는 흥미롭게도 “don’t ship”이다. 단일 replay에서는 더 저렴한 모델이 같은 결과를 내는 것처럼 보였지만, 여러 support case를 묶어 분석하자 해당 데이터에서는 저렴한 모델로 바꾸면 안 된다는 결론이 나온다. 이는 강연 전체의 메시지를 압축한다. 저장과 replay의 목적은 변경을 빨리 밀어붙이는 것이 아니라, 실제 운영 데이터 위에서 변경의 비용과 위험을 함께 판단하는 것이다.
운영 Playbook: 실제 실행에서 시작해 루프를 닫기
Hamza가 제안하는 playbook은 실제 production run에서 시작한다. synthetic test가 아니라 실제 고객 요청, 실제 도구 호출, 실제 모델 응답, 실제 artifact가 저장된 checkpoint를 기반으로 한다. 그다음 비용이 많이 든 실행, 오래 걸린 실행, 위험도가 높은 실행처럼 개선 가치가 있는 cohort를 만든다. 이렇게 해야 평가가 추상적인 벤치마크가 아니라 운영상 중요한 문제와 연결된다.
이후에는 하나의 변경을 적용해 replay하고, baseline과 candidate를 비교하며, 결과를 보고 route, ship, hold를 결정한다. 모델을 더 저렴한 것으로 바꾸는 경우에도 단순히 token cost만 보지 않고, 해결률, escalation, review 필요성, 정책 준수 여부를 함께 봐야 한다. tool mocking을 하는 경우에도 변경된 도구 응답이 downstream decision에 어떤 영향을 주는지 확인해야 한다. 이 루프가 반복될수록 에이전트 운영은 감에 의존하는 튜닝에서 증거 기반 개선으로 이동한다.
강연자는 마지막에 이 루프를 가능한 한 자동화하되, 끝에는 human-in-the-loop를 두는 것이 바람직하다고 말한다. 이는 에이전트 운영의 현실적인 균형점이다. 모든 판단을 사람이 수동으로 검토하면 확장성이 없고, 모든 변경을 자동 배포하면 품질과 책임 문제가 생긴다. checkpoint와 replay는 이 중간에서 에이전트가 분석하고 사람이 승인하는 운영 모델을 가능하게 만든다.
마무리 / 핵심 정리
이 강연의 핵심 메시지는 AI 에이전트가 더 복잡해질수록 trace만으로는 충분하지 않다는 것이다. trace는 무슨 일이 일어났는지 보여주지만, 저장된 runtime state는 그 지점으로 돌아가 다른 선택지를 실험할 수 있게 한다. Hamza가 말하는 “save button”은 에이전트 실행을 문서처럼 저장하자는 단순한 비유가 아니라, 운영 중인 에이전트를 검증하고 개선하기 위한 기반 인프라를 뜻한다.
Kitaru 데모는 이 아이디어를 구체적인 workflow로 보여준다. 특정 checkpoint에서 모델을 바꾸고, 도구 응답을 mock하고, 원본 실행과 replay fork를 diff하며, cohort 전체에 변경을 적용해 ship 여부를 판단한다. 특히 단일 replay가 아니라 production checkpoint 기반 cohort 분석을 강조한 점이 중요하다. 에이전트 운영의 성숙도는 결국 “왜 그렇게 했는가”를 보는 데서 “다르게 했으면 어땠는가”를 검증하는 단계로 이동하고 있다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | Your Agents Need a Save Button - Hamza Tahir, ZenML |
| 채널 | AI Engineer |
| 리포트 작성 | 2026-07-18 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
| 참고 자료 | Kitaru 제품 페이지, ZenML Blog - Your Agents Need More Than Just Traces |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.