지속 실행 런타임이 필요한 이유
장기 실행 에이전트는 수 분에서 며칠씩 도구 호출과 모델 추론을 반복하며, 프로세스 재시작·타임아웃·배포 교체가 나면 진행 중이던 리서치 루프가 유실됩니다. 지속 실행(Durable Execution) 런타임은 워크플로 상태를 런타임 밖에 지속화해 장애 뒤 마지막 지점부터 실행을 이어갑니다. 2026년 Replay 컨퍼런스에서 Temporal은 Serverless Workers·Standalone Activities·Workflow Streams와 OpenAI Agents SDK·Google ADK 연동을 발표했고, OpenAI는 거대 에이전틱 워크플로에서 Temporal의 지속 오케스트레이션이 핵심이라고 밝혔습니다. 2025년 12월 AWS Lambda Durable Functions, 2026년 4월 Microsoft Durable Task가 가세했습니다.
체크포인트·리플레이 복구와 멱등성
Temporal의 복구는 스냅샷이 아니라 이벤트 이력 리플레이로 동작합니다. 실행한 결정과 액티비티 결과를 이력에 기록하고, 워커가 죽으면 다른 워커가 이력을 재생해 상태를 복원합니다. 워크플로 코드는 결정적이어야 하고, 모델 호출·검색·파일 쓰기처럼 부수효과가 있는 작업은 액티비티로 분리합니다. 재생 시 액티비티는 기록된 결과를 재사용하므로 같은 LLM 호출을 중복 과금 없이 복구하며, 안전한 복구를 위해 각 액티비티는 멱등해야 합니다.
A4 분량 상세 가이드: 기획부터 운영까지
기획 단계에서는 복구 성공을 수치로 정의합니다. auto research 루프는 단일 실행 완주율 99% 이상, 워커 장애 후 재개 성공률 99.5% 이상, 리플레이 LLM 중복 호출 0건, 복구 재개 p95 지연 30초 이내를 목표로 잡습니다. 하나의 질의를 하나의 워크플로로 두고 검색·요약·검증을 액티비티로 분해하며, 액티비티마다 타임아웃(모델 호출 120초, 외부 검색 30초)과 재시도 상한을 명시합니다.
실패는 유형별로 분기를 다르게 둡니다. 일시적 장애는 지수 백오프로 최대 5회 재시도합니다. 결정성 위반은 재시도로 풀리지 않아 워크플로 버전 관리로 코드 경로를 분기합니다. 근거 없는 답이 반복되거나 검증 통과율이 기준 미만이면 사람 확인으로 에스컬레이션하고, 예산·시간 한도를 넘으면 결과를 안전하게 축약하며, 한 도구가 연속 3회 동일 오류를 내면 해당 분기를 중단합니다.
운영에서는 표준 로그 스키마를 고정합니다. 워크플로·실행 ID, 액티비티 이름, 시도 횟수, 재시도 사유, 복구 여부를 구조화된 필드로 남깁니다. 사용자 입력이 이력에 그대로 흐르지 않도록 이메일·전화·식별자에 PII 마스킹을 액티비티 경계에서 적용합니다. 배포 전에는 코드 변경이 결정성을 깨지 않는지 리플레이 테스트로 검증합니다.
지속 개선 루프는 주간 단위로 복구 지표를 리뷰합니다. 재시도가 잦은 액티비티, 사람 확인 비율, 중단 발동 빈도를 집계해 반복 실패를 타임아웃·백오프·멱등 키 설계로 되먹입니다. 중복 호출이 0건이 아니면 부수효과가 액티비티 밖으로 샌 신호이므로 즉시 교정합니다.
실행 요약
장기 실행 에이전트에는 상태를 런타임 밖에 지속화하는 실행 모델이 필요합니다. Temporal은 이력 리플레이로 마지막 지점부터 복구하며, 안전하게 쓰려면 결정성과 멱등성을 지켜야 합니다. 실패를 재시도·사람 확인·안전 축약·중단으로 분기하고 완주율 99%·중복 호출 0건 지표를 주간으로 되먹이면 며칠짜리 리서치 루프도 완주시킵니다.