AI 워크플로를 위한 Temporal Durable Execution
Temporal Durable Execution은 오래 걸리고 자주 실패하는 AI 워크플로를 history와 replay를 기준으로 재개하게 만드는 실행 모델이다. 핵심은 workflow는 결정을 맡고, LLM 호출과 외부 side effect는 activity로 분리하는 데 있다.
Script Companion
오디오와 함께 스크립트 보기
- 01
AI workflow가 어려워지는 지점은 모델 호출 자체보다 실행 시간이 길어지고 실패가 정상 경로처럼 섞이는 순간이다. RAG 색인, 다단계 agent, 사람 승인, 외부 API 호출이 함께 있으면 작업은 수 초가 아니라 수 분에서 수일까지 이어질 수 있다. 그 사이 rate limit, timeout, provider 장애, tool 실패가 발생하고, 승인자가 다음 날 응답해도 workflow는 이어져야 한다. Temporal Durable Execution은 이런 장기 실행 AI workflow를 마지막 안전 지점에서 다시 이어가기 위한 실행 계층이다.
- 02
Temporal의 기본 단위는 Workflow와 Activity다. Workflow는 전체 agent run이나 승인 흐름처럼 어떤 순서로 무엇을 할지 결정하는 deterministic orchestration을 맡는다. Activity는 LLM API 호출, vector search, 이메일 발송처럼 외부 side effect가 있는 일을 맡는다. Task Queue는 worker가 polling하는 작업 큐이고, History는 activity scheduled, activity completed, timer fired 같은 이벤트가 append되는 로그다. 여기서 핵심 규칙은 단순하다. workflow는 결정만 하고, side effect는 activity로 보낸다.
- 03
Temporal에서 말하는 workflow는 LLM workflow pattern이나 agent orchestration보다 낮은 실행 계층이다. Temporal이 agent의 생각을 대신하거나 다음 행동을 고르는 것이 아니다. Temporal은 agent run을 감싸는 실행 껍질로서 재시도, 대기, 보상, 감사를 책임진다. 반대로 agent framework는 특정 step 내부에서 계획, 도구 선택, 응답 생성을 맡는다. 그래서 Temporal로 agent를 만든다는 표현은, 정확히는 agent를 실행하고 복구하는 durable workflow를 만든다는 뜻에 가깝다.
- 04
Replay와 determinism은 Temporal을 이해하는 핵심이다. Temporal workflow는 장애가 난 뒤 history를 replay해서 이전 결정을 복원한다. 그래서 workflow 안에서 현재 시간, 랜덤, 네트워크 호출 같은 비결정적 작업을 직접 수행하면 안 된다. 비결정적 결과는 activity result로 history에 기록되어야 한다. 이 구조는 항상 한 번만 실행을 마법처럼 보장하는 방식이 아니다. event history를 기준으로 어떤 결정이 이미 커밋되었는지 일관되게 재구성하는 방식이다. 따라서 외부 API 호출은 idempotency key를 가져야 하고, workflow 내부 결정은 replay해도 같은 결과가 나와야 한다.
- 05
AI workflow에서 LLM 호출과 tool call은 activity로 감싸는 것이 기본이다. Temporal은 activity 재시도를 관리하지만, 이메일, 결제, ticket 생성 같은 외부 side effect의 exactly-once를 대신 보장하지는 않는다. 중복되면 안 되는 작업에는 idempotency key, 외부 저장소의 중복 체크, 필요하면 보상 activity가 함께 필요하다. 특히 LLM과 tool 호출은 실패가 정상 경로에 가깝기 때문에 retry policy와 timeout을 설계 안에 넣어야 한다. rate limit은 backoff하고, policy violation은 재시도하지 않는 식으로 오류 종류를 나누어야 한다.
- 06
Signal, Query, Update는 사람과 운영 UI가 workflow에 붙는 경계다. Signal은 사람 승인이나 취소 요청처럼 외부에서 workflow에 이벤트를 전달한다. Query는 UI 진행률처럼 현재 상태를 조회하고, Update는 deadline 변경처럼 검증 가능한 상태 변경 요청을 다룬다. Human-in-the-loop AI workflow는 signal 없이는 결국 polling API가 된다. Timer와 deadline도 중요하다. Temporal은 timer를 workflow history에 넣기 때문에, LLM provider rate limit으로 30분 뒤 재시도해야 하는 상황도 worker process를 붙잡지 않고 표현할 수 있다.
- 07
운영 정책에서는 activity별 max attempts, backoff, non-retryable error, timeout 범위를 먼저 정해야 한다. schedule-to-close와 start-to-close를 분리하면 LLM 호출 2분, 승인 대기 24시간, 전체 run 3일처럼 성격이 다른 시간을 함께 다룰 수 있다. History 크기도 경계 조건이다. 큰 prompt나 tool result를 history에 직접 저장하면 workflow history가 폭증할 수 있으므로, 원문은 blob store에 두고 reference만 history에 저장하는 설계를 검토한다. 반복 agent run은 일정 step마다 continue-as-new도 고려한다.
- 08
AI workflow도 side effect를 만들기 때문에 중간 실패를 되돌리거나 보정하는 흐름이 필요하다. 문서에서는 close_ticket, refund_credit, send_correction_email 같은 보상 activity를 예로 든다. 이는 Saga Pattern을 AI workflow에 적용한 형태다. 실제 사용처도 이런 성격과 맞닿아 있다. 고객 문서 분석 후 사람 승인 받아 발송하는 agent, RAG 색인 pipeline의 crawl, chunk, embed, upsert, validate, AI 코드 리뷰의 plan, patch, test, reviewer approval, 사고 대응 runbook, 장기 onboarding workflow가 대표적이다.
- 09
Temporal과 LangGraph persistence는 대체 관계라기보다 다른 층을 맡는 조합 관계다. Temporal은 범용 durable workflow platform으로 장기 실행, retry, timer, signal, workflow history에 강하다. LangGraph persistence는 agent graph state persistence로 agent state, interrupt, graph 재개에 초점이 있다. 따라서 Temporal workflow 안의 activity로 LangGraph agent run을 실행할 수도 있고, LangGraph의 중요한 side effect를 Temporal activity로 감쌀 수도 있다. 결제, 승인, 배치, 장기 업무 자동화는 Temporal 쪽 성격이 강하고, agent 대화, tool loop, HITL prototype이나 제품은 LangGraph 쪽 성격이 강하다.
- 10
Silent Failure는 설계 경계를 어겼을 때 드러난다. 재시작 후 LLM 호출이 중복된다면 LLM call을 workflow 내부에서 실행한 것이 원인일 수 있고, activity로 이동해 result를 history에 기록해야 한다. 이메일이 두 번 발송된다면 idempotency key가 없었던 것이 핵심 원인이다. replay nondeterminism 에러는 workflow code에서 랜덤이나 시간을 직접 썼을 때 발생할 수 있으므로 deterministic API 또는 activity를 사용해야 한다. 배포 후 진행 중 실행 실패는 기존 history와 새 workflow code 불일치가 원인이 될 수 있어 versioning, patch marker, 호환 worker 배포가 필요하다.
- 11
정리하면 Durable Execution은 장기 AI workflow를 장애 후에도 마지막 안전 지점에서 재개하게 한다. Temporal은 workflow history와 replay로 이 실행 모델을 제공하고, workflow orchestration은 실행과 복구 제어를 맡는다. agent orchestration은 LLM의 행동 선택을 맡는 별도 층이다. human approval, timer, retry, compensation은 예외 처리가 아니라 AI workflow의 정상 경로로 설계해야 한다. 큐와 worker를 이미 알고 있다면 Temporal은 큐, retry, timer, 상태 저장, saga를 하나의 프로그래밍 모델로 묶은 것으로 볼 수 있다.
같은 레이어
L12에서 이어 듣기
- LLM API 기초와 운영 감각 길이 미정
- 운영 자산으로 보는 프롬프트 엔지니어링 길이 미정
- 임베딩과 벡터 운영의 핵심 경로 길이 미정
- RAG 기초: 검색, 주입, 생성의 운영 기준 길이 미정
- LLM 도구 호출의 설계와 운영 길이 미정
- 에이전트 오케스트레이션 운영 기준 길이 미정
- LLM 비용과 지연을 운영 지표로 읽는 법 길이 미정
- LLM 보안과 운영 방어 계층 길이 미정
- LLM 운영을 위한 관측성과 평가 길이 미정
- 에이전틱 LLM의 컨텍스트 파이프라인 길이 미정
- 상태 머신으로 LLM 워크플로를 다루기 길이 미정
- Human-in-the-loop AI 워크플로 설계 길이 미정
- AI 앱의 온톨로지와 역량 모델링 길이 미정
- 심리측정으로 설계하는 SJT와 LLM 평가 길이 미정