AI 워크플로를 위한 Temporal Durable Execution

분류: Layer 12 - AI 시스템 & LLM 애플리케이션 | 선수지식: L6 Queue/Retry, L9 Saga, L12 Agent/State machine

AI 워크플로를 위한 Temporal Durable Execution — Workflow, Activity, Replay, Signal

1. 한 줄 정의

Durable execution은 장기 실행 작업의 진행 상태를 durable store에 남겨 worker crash, 네트워크 장애, human approval 대기, 재시도가 있어도 마지막 안전 지점부터 재개하는 실행 모델이다. Temporal은 이 모델을 workflow history와 activity retry로 구현하는 대표 플랫폼이다.

이 문서의 workflow orchestration은 agent가 “다음 tool을 고르는” 문제가 아니라, 여러 step을 가진 업무 실행을 순서, 재시도, timeout, 보상, 외부 이벤트로 제어하는 일반 실행 계층을 뜻한다. Agent orchestration이 LLM 자율성의 범위를 정한다면, durable workflow orchestration은 그 자율 작업이 실패·중단·재시작을 만나도 운영적으로 이어지게 만드는 층이다.

2. 왜 중요한가

AI workflow는 오래 걸린다: RAG 색인, 다단계 agent, 사람 승인, 외부 API 호출이 섞이면 수 초가 아니라 수 분~수일 작업이 된다.
LLM 호출은 실패한다: rate limit, timeout, provider 장애, tool 실패가 정상 경로처럼 자주 발생한다.
side effect 중복 위험: 결제, 이메일, ticket 생성 같은 tool call을 재시도하면 중복 사고가 난다.
사람 대기: 승인자가 내일 응답해도 workflow가 이어져야 한다.
감사 가능성: 어떤 step에서 어떤 입력으로 어떤 결정을 했는지 history가 필요하다.

2.5 선행 기술의 한계 — Queue + DB Status만으로 부족했던 이유

전통적으로 장기 작업은 queue와 DB status로 구현했다.

jobs(id, status, step, payload, attempts)
worker:
  read job
  if step == "retrieve": ...
  if step == "call_llm": ...
  if step == "send_email": ...

이 방식은 단순하지만 운영에서 네 가지가 어렵다.

중간 step 재실행 판단: worker가 LLM 호출 후 DB 업데이트 전에 죽으면 호출을 다시 해야 하는지 알기 어렵다.
timer와 retry 분산: exponential backoff, timeout, cron, human deadline이 코드 여러 곳에 흩어진다.
상태 migration: workflow 버전이 바뀌면 이미 진행 중인 job이 어느 코드 경로를 따라야 하는지 모호하다.
감사 로그 부족: 상태 row는 최종 상태만 보여주고, 왜 그 상태가 되었는지 history가 약하다.

Temporal은 workflow history를 append-only로 저장하고, workflow code를 replay해 같은 결정을 재현한다. 공식 문서는 crash, network failure, infrastructure outage 후에도 실행을 이어갈 수 있는 durable execution을 핵심 가치로 설명한다. 출처: Temporal Docs. LangGraph도 checkpointer를 통해 유사하게 step state를 저장해 interruption과 human-in-the-loop에서 재개할 수 있다. 출처: LangGraph durable execution.

3. 핵심 개념

3.1 Workflow와 Activity

구성요소	역할	AI 예시
Workflow	deterministic orchestration	전체 agent run, 승인 흐름
Activity	외부 side effect	LLM API 호출, vector search, 이메일 발송
Task Queue	worker가 polling하는 작업 큐	`ai-workflows`
History	event append log	activity scheduled/completed, timer fired

핵심 규칙: workflow는 결정만, side effect는 activity로.

Workflow orchestration의 경계

Temporal의 “workflow”는 L12 Agent 문서의 “LLM workflow pattern”보다 낮은 실행 계층이다.

구분	다루는 질문	Temporal 문맥에서의 대응
일반 workflow engine	어떤 step을 어떤 순서로 실행할까?	workflow code, activity, task queue
Durable execution	장애 후 같은 결정을 어떻게 재현할까?	history, replay, deterministic API
Agent orchestration	LLM에게 다음 행동 결정을 맡길까?	activity 안의 LangGraph/agent run
State machine/graph	가능한 상태와 전이를 어떻게 제한할까?	workflow state, signal guard, timer

따라서 “Temporal로 agent를 만든다”는 표현은 정확히는 Temporal이 agent의 생각을 대신한다는 뜻이 아니다. Temporal은 agent run을 감싸는 실행 껍질로서 재시도·대기·보상·감사를 책임지고, agent framework는 특정 step 내부에서 계획·도구 선택·응답 생성을 맡는다.

3.2 Replay와 Determinism

Temporal workflow는 장애 후 history를 replay해 이전 결정을 복원한다. 그래서 workflow 안에서 현재 시간, 랜덤, 네트워크 호출 같은 비결정적 작업을 직접 수행하면 안 된다.

안전:
  workflow.executeActivity(callLLM)
  workflow.sleep("1 hour")

위험:
  fetch("https://api.openai.com") inside workflow
  Math.random()로 분기

비결정적 결과는 activity result로 history에 기록되어야 한다.

이 규칙은 L9 분산 시스템 기초의 CAP·일관성 문제와 연결된다. worker process는 언제든 죽을 수 있고, activity 완료 이벤트와 외부 side effect 사이에는 네트워크 지연·중복 전달·부분 실패가 끼어든다. Durable execution은 “항상 한 번만 실행”을 마법처럼 보장하는 것이 아니라, event history를 기준으로 어떤 결정이 이미 커밋되었는지를 일관되게 재구성한다. 그래서 외부 API 호출은 idempotency key를 가져야 하고, workflow 내부 결정은 replay해도 같은 결과가 나와야 한다.

3.3 AI Workflow Activity 설계

LLM과 tool call은 activity로 감싼다.

Workflow:
  plan = executeActivity(makePlan, input)
  docs = executeActivity(retrieveDocs, plan.query)
  draft = executeActivity(callLLM, { input, docs })
  approval = waitForSignal("approval")
  executeActivity(sendResult, draft)

activity는 idempotency key를 받아야 한다. 예: email:{workflowId}:{stepId}.

Temporal은 activity 재시도를 관리하지만 외부 side effect의 exactly-once를 대신 보장하지 않는다. 이메일·결제·ticket 생성처럼 중복되면 안 되는 작업은 idempotency key, 외부 저장소의 중복 체크, 필요 시 보상 activity를 함께 둔다.

3.4 Signal, Query, Update

Signal: 외부에서 workflow에 이벤트 전달. 예: 사람 승인, 취소 요청
Query: workflow 현재 상태 조회. 예: UI 진행률
Update: 검증 가능한 상태 변경 요청. 예: deadline 변경

Human-in-the-loop AI workflow는 signal 없이는 결국 polling API가 된다.

3.5 Timer와 Deadline

Temporal은 timer를 workflow history에 넣는다.

wait approval up to 24h
  -> approved: continue
  -> timeout: escalate or cancel

LLM provider rate limit으로 30분 뒤 재시도해야 하는 상황도 worker process를 붙잡지 않고 표현할 수 있다.

운영 정책 표

Temporal SDK 예제보다 먼저 정해야 할 것은 activity별 운영 정책이다. 특히 LLM·tool 호출은 실패가 정상 경로에 가깝기 때문에 retry와 timeout을 workflow 설계에 포함한다.

항목	권장 설계	AI workflow 예시
Retry policy	activity별 max attempts, backoff, non-retryable error 구분	rate limit은 backoff, policy violation은 재시도 금지
Timeout	schedule-to-close와 start-to-close를 분리	LLM 호출 2분, 승인 대기 24시간, 전체 run 3일
History size / continue-as-new	큰 prompt·결과는 blob store에 두고 reference만 history에 저장	반복 agent run은 N step마다 continue-as-new 검토

3.6 Compensation과 Saga

AI workflow도 side effect를 만든다.

create_ticket
charge_credit
send_email

중간 실패 시 close_ticket, refund_credit, send_correction_email 같은 보상 activity를 둔다. 이는 L9 Saga Pattern의 AI workflow 적용이다.

3.7 Temporal vs LangGraph Durable Execution

축	Temporal	LangGraph persistence
주 목적	범용 durable workflow platform	agent graph state persistence
강점	장기 실행, retry/timer/signal, workflow history	agent state, interrupt, graph 재개
제약	deterministic workflow 규칙 필요	runtime/framework 생태계 의존
적합	결제·승인·배치·장기 업무 자동화	agent 대화·tool loop·HITL prototype/제품

둘은 대체라기보다 조합 가능하다. Temporal workflow 안 activity로 LangGraph agent run을 실행하거나, LangGraph의 중요한 side effect를 Temporal activity로 감쌀 수 있다.

3.8 Silent Failure

증상	원인	복구
재시작 후 LLM 호출 중복	LLM call을 workflow 내부에서 실행	activity로 이동, result history 기록
이메일 두 번 발송	idempotency key 없음	외부 side effect activity에 idempotency 적용
replay nondeterminism 에러	workflow code에서 랜덤/시간 사용	deterministic API 또는 activity 사용
배포 후 진행 중 실행 실패	기존 history와 새 workflow code 불일치	versioning/patch marker, 호환 worker 배포
승인 후 엉뚱한 단계 재개	human signal과 state 검증 부재	signal handler에서 현재 state guard
workflow history 폭증	큰 prompt/tool result를 history에 직접 저장	blob store에 원문 저장, reference만 history

4. 실무에서 어디에 쓰이나

고객 문서 분석 후 사람 승인 받아 발송하는 agent
RAG 색인 pipeline의 crawl → chunk → embed → upsert → validate
AI 코드 리뷰의 plan → patch → test → reviewer approval
사고 대응 runbook의 자동 진단 → 제안 → 승인 → 조치
여러 외부 SaaS를 호출하는 장기 onboarding workflow

5. 현재 내 업무와 연결점

큐/워커를 배웠다면 Temporal은 “큐 + retry + timer + 상태 저장 + saga”를 프로그래밍 모델로 묶은 것으로 볼 수 있다. AI agent에서는 이 묶음이 더 중요하다. LLM 호출 자체보다 “중간에 멈췄을 때 어디서 어떻게 이어갈 것인가”가 production 안정성을 가른다.

6. 자주 헷갈리는 개념 비교

개념 A	개념 B	차이점
Queue worker	Durable workflow	queue는 작업 전달, durable workflow는 실행 history와 재개 의미론 제공
Retry	Replay	retry는 실패 작업 재시도, replay는 workflow 결정을 history로 복원
Activity	Workflow	activity는 side effect, workflow는 deterministic orchestration
Signal	API polling	signal은 실행 중 workflow에 이벤트 전달, polling은 외부 조회
Checkpoint	History	checkpoint는 상태 snapshot, history는 이벤트 로그
Agent orchestration	Workflow orchestration	agent orchestration은 모델의 행동 선택, workflow orchestration은 실행·복구 제어

7. 체크리스트

workflow 안에서 직접 실행하면 안 되는 비결정적 작업을 구분할 수 있다.
LLM call과 tool call을 activity로 감싸야 하는 이유를 설명할 수 있다.
workflow orchestration, durable execution, agent orchestration의 경계를 설명할 수 있다.
human approval을 signal + state guard로 설계할 수 있다.
외부 side effect activity에 idempotency key를 설계할 수 있다.
Temporal과 LangGraph durable execution의 역할 차이를 설명할 수 있다.

8. 추가 학습 키워드

Temporal workflow, durable execution, workflow replay, deterministic orchestration, Temporal activity, signal query update, LangGraph durable execution, idempotency key, saga compensation

9. 내가 직접 확인해볼 것

“문서 요약 → 사람 승인 → 이메일 발송” workflow를 상태도로 그리기
LLM 호출이 timeout될 때 activity retry policy를 어떻게 둘지 설계
이메일 발송 activity의 idempotency key 형식 정하기
human approval timeout 시 escalate/cancel 상태 설계

10. 5줄 요약

Durable execution은 장기 AI workflow를 장애 후에도 마지막 안전 지점에서 재개하게 한다.
Temporal은 workflow history와 replay로 durable execution을 제공한다.
workflow orchestration은 실행·복구 제어, agent orchestration은 LLM의 행동 선택을 담당한다.
human approval, timer, retry, compensation은 AI workflow의 정상 경로로 설계해야 한다.
LangGraph persistence와 Temporal은 agent state와 범용 workflow durability라는 서로 다른 층을 담당한다.

11. 출처

최종 수정: 2026-05-21