We Trust AI Agents That Break Every Day - Shy Ruparel, Temporal

한 줄 핵심

금융과 같은 장기 업무에서 AI 에이전트가 매일 깨지더라도, Temporal 같은 durable execution으로 상태와 진행을 보존하면 재실행·복구 비용 없이 프로덕션에 올릴 수 있다.

시간별 요약

1. 0:00
   소개 Temporal의 developer advocate가 AI 에이전트가 이미 널리 쓰이고 있지만, 실제 프로덕션에서는 안정성과 복구가 핵심이라는 문제의식을 꺼낸다.
2. 0:34
   금융은 장기 실행 워크플로에 달려 있다 금융 서비스는 개별 모델보다 여러 날과 여러 시스템, 여러 사람이 엮인 긴 업무 흐름으로 돌아가며, 실제 돈이 걸려 있어 작은 오류도 허용하기 어렵다. 그래서 AI를 도입하는 것과 실제로 안정적으로 배포하는 것 사이에는 큰 간극이 생긴다.
3. 2:05
   개발 현황 조사 554명의 엔지니어와 리더를 대상으로 한 조사를 통해, 실제 AI 에이전트를 쓰는 전문 조직에서 어떤 문제가 반복되는지 파악했다. 조사 결과는 네 가지 큰 간극으로 정리되며, 이번 발표의 핵심 축이 된다.
4. 3:16
   사용과 배포의 간극 에이전트를 매일 사용하는 비율은 80.8%까지 늘었지만, 실제로 프로덕션에 올려 핵심 시스템으로 쓰는 비율은 49.1%에 그친다. 즉, 많은 팀이 시험해 보지만 배포 단계에서 막히고 있다.
5. 4:33
   신뢰와 현실의 간극 에이전트 출력에 대한 신뢰는 85.5%로 높지만, 동시에 41.1%는 매일 또는 그 이상 장애를 겪는다. 실패를 없애는 것이 목표가 아니라, 실패가 나도 비용이 들지 않게 설계하는 것이 목표여야 한다.
6. 7:18
   프로토타입과 엔터프라이즈의 간극 작은 팀은 몇 시간 만에 AI 프로토타입을 배포할 수 있지만, 5,000명 이상 대기업에서는 배포까지 몇 달이 걸리기도 한다. 특히 은행·보험·결제사처럼 규제가 많은 조직은 승인, 감사 추적, 결제 무결성을 보장하는 구조가 필요하다.
7. 8:55
   보이는 것과 복구하는 것의 간극 팀의 생산성을 가장 많이 막는 요소는 모델 성능이 아니라 상태 추적과 디버깅이다. 관측성 도구가 실패를 보여주더라도, 실제 복구를 사람이 새벽에 수동으로 해야 하는 구조라면 운영 가능하다고 보기 어렵다.
8. 10:53
   크래시를 견디는 지급 데모 9단계 지급 워크플로에서 에이전트가 사기 조사와 브리프 작성, 인간 승인까지 맡는 동안 워커를 강제로 종료해도 흐름이 끊기지 않는 모습을 보여준다. 상태가 프로세스 메모리가 아니라 외부 히스토리에 남아 있어, 재시작 후 이어서 진행되고 토큰도 다시 쓰지 않는다.
9. 13:06
   Durable execution 설명 durable execution은 프로세스가 죽어도 코드가 끝까지 이어지도록 만드는 방식이며, 각 단계의 결과를 이벤트 히스토리로 기록한다. 결정적 로직은 워크플로 안에 두고, 비결정적이거나 외부 효과가 있는 LLM 호출·API 호출·인간 승인은 activity나 signal로 분리해 재실행을 안전하게 만든다.
10. 18:12
    데모가 해결한 것 이 한 워크플로로 상태 관리, 재시도, 승인 대기, 장기 실행, 크래시 복구, 비용 절감, 디버깅의 문제를 함께 해결했다. 특히 모델이 실패해도 지급 자체는 계속 진행되고, 복구용 코드를 따로 작성하지 않아도 된다는 점이 핵심이다.
11. 20:10
    프로덕션에서 누가 쓰는가 OpenAI의 Codex와 Replit의 에이전트가 실제로 Temporal 위에서 운영되고 있다. 에이전트가 깊게 진행한 뒤 치명적 오류로 무너지는 최악의 사용자 경험을 피하기 위해, 프로덕션에서는 이런 지속성 계층이 이미 쓰이고 있다.
12. 20:50
    마무리 발표의 결론은 네 가지 간극을 하나의 기록과 실행 모델로 닫을 수 있다는 점이다. 신뢰와 관측성, 복구와 상태 유지가 분리된 문제가 아니라 하나의 durable workflow로 통합될 수 있음을 강조하며 마친다.

실무 인사이트

• AI 에이전트를 프로덕션에 넣는 핵심은 모델 성능보다 상태 보존과 복구 설계에 있으므로, 먼저 실패해도 값이 남는 실행 모델부터 잡아야 한다.
• 비결정적 작업과 결정적 워크플로를 분리하면, LLM 호출을 반복하지 않고도 크래시 이후 같은 결과를 재현할 수 있어 비용과 안정성을 동시에 줄일 수 있다.
• 규제 산업에서는 자동화 자체보다 감사 가능성, 승인 흐름, 재개 가능성이 더 중요하므로, 데모 성공 기준을 '돌아간다'가 아니라 '깨져도 이어진다'로 바꿔야 한다.