AI Agent 상태 머신 설계: 복잡한 워크플로를 Prompt 에만 맡기면 안 되는 이유

보고서 Agent 가 5 단계에서 이메일을 보내기 직전에 실패했습니다. 운영 담당자가 작업을 다시 실행하자 Agent 는 1 단계부터 다시 시작했고, 새 보고서를 생성해 이전에 승인된 버전을 덮어썼습니다. 승인 상태는 사라졌고, 승인자의 서명 기록은 새 결과로 대체되었습니다. 첫 번째 보고서가 승인되었다는 사실을 증명할 로그도 남지 않았습니다.

이 문제는 데이터베이스 트랜잭션 rollback 도 아니고 메시지 큐 retry 도 아닙니다. Prompt 에는 “계속 처리”라는 한 문장만 남아 있었고, 모델은 전체 흐름을 다시 추론했습니다. 1~4 단계에서 이미 승인 API 호출, 보고서 생성, 임시 파일 쓰기 같은 부작용이 발생했다는 사실을 알지 못했습니다. 실패 지점은 5 단계였지만 부작용은 2 단계부터 시작되었습니다.

진짜 문제는 모델 능력이 충분한지 여부가 아니었습니다. 작업 진행 상태가 prompt 의 자연어 안에 숨겨져 있었고, 복구 가능한 상태 snapshot 이 없었습니다. Prompt 가 담고 있는 messages 는 모델 컨텍스트이지 실행 사실이 아닙니다.

이런 사고를 고치려면 prompt 에 “계속하기 전에 진행 상태를 확인하라”는 문장을 하나 더 넣는 것만으로는 부족합니다. 현재 노드, 이미 발생한 부작용, 다음 action, 실패 보상을 복구 가능한 상태표에 기록하는 편이 훨씬 안정적입니다.

사고의 핵심 지점

보고서 Agent 실행 흐름:

단계	작업	부작용	idempotency
1 단계	데이터 조회	데이터베이스를 호출해 사용자 데이터를 조회	idempotent (읽기 작업)
2 단계	보고서 생성	보고서 생성 도구를 호출해 PDF 생성	idempotent 하지 않음 (파일 덮어쓰기)
3 단계	승인 대기	승인 요청을 보내고 사람의 승인을 기다림	idempotent (API 지원)
4 단계	승인 완료	approve event 수신	idempotent (상태 조회)
5 단계	이메일 발송	이메일 API 를 호출해 보고서 발송	실패 (timeout)

실패 원인: 5 단계 이메일 발송이 외부 API rate limit 으로 timeout 되었고, 작업은 FAILED 로 표시되었습니다.

재실행 로직: prompt 에서 “현재 진행 상태”를 읽습니다. Prompt 에는 “승인됨, 계속 처리”라는 문장만 있습니다. 실제 실행: 1 단계부터 다시 시작 -> 2 단계에서 보고서 재생성(승인된 버전 덮어쓰기) -> 3 단계에서 다시 승인 요청 -> 5 단계 발송 성공.

비즈니스 영향: 승인된 보고서가 교체되고 승인 기록과 최종 전달된 보고서가 불일치했습니다. 사용자는 승인한 보고서와 받은 보고서 내용이 다르다고 항의했습니다. 승인 프로세스는 두 버전을 승인했지만 실제로 전송된 것은 하나뿐이었습니다.

안티패턴 식별표

당신의 Agent 가 아래 안티패턴에 해당하는지 확인해 보세요:

안티패턴	모습	숨은 위험	수정 방법
진행 상태를 Prompt 에 씀	”현재 3 단계” 같은 자연어 요약	재시작 후 사라지고 복구 불가	현재 노드를 State 필드에 기록
Trace 를 State 로 착각	Trace 가 완전하면 상태도 있다고 생각	Trace 는 다음 결정을 기록하지 않음	State 가 다음에 할 일을 기록
idempotency 검사 없는 Retry	실패하면 처음부터 재실행	부작용이 중복 실행됨	idempotency key + 이미 실행됨 검사
approval 후 Resume 검증 없음	바로 계속 실행	올바른 실행 지점으로 돌아가지 못함	checkpoint + thread_id

1. 상태 머신 기초: State, Event, Transition, Guard, Action

상태 머신은 모든 Agent 에 필요한 아키텍처가 아닙니다. 단순 고객 지원 Q&A 는 messages 배열만으로 충분합니다. 하지만 여러 단계, 승인, 외부 시스템 호출, 실패 후 복구가 있는 복잡한 작업은 진행 상태를 명시해야 합니다.

1.1 핵심 용어 정의표

상태 머신의 기본 용어는 Stately 공식 문서를 따릅니다:

용어	정의	Agent 예시	출처
State	머신이 놓인 모드이며 하나의 의미적 의도에 대응	INIT, PLAN_READY, TOOL_RUNNING, APPROVAL_PENDING, FAILED, COMPLETED	Stately state machines
Event	상태 변화를 트리거하는 외부 신호	timeout, approve, reject, retry, resume, task_received	Stately state machines
Transition	상태 사이의 허용 경로이며 결정적 매핑	INIT -> PLAN_READY (event: task_received)	Stately state machines
Guard/Condition	어떤 상태에 들어가기 전 조건 검사	예산이 충분해야 TOOL_RUNNING 진입	Stately state machines
Action	transition 중 실행되는 작업	TOOL_RUNNING 진입 시 도구 호출	Stately state machines
Checkpoint	복구에 쓰이는 상태 snapshot	LangGraph checkpointer 가 graph state 저장	LangGraph Persistence

결정성 원칙: 같은 State + Event 조합은 모호성을 피하기 위해 하나의 next state 만 가리켜야 합니다. 유한 상태 집합: 상태 머신은 무한한 흐름도가 아니라 유한한 도달 가능 상태와 명확한 transition 규칙입니다.

1.2 Trace vs State vs Audit 비교표

Trace, Audit Log, State Snapshot 은 서로 다른 문제를 해결합니다:

개념	해결하는 문제	비즈니스 상태인가	다음 단계를 결정하는가	Agent 예시
Trace	관측과 진단의 골격	아니요	아니요	OpenAI Agents SDK trace (workflow_name, trace_id)
Audit Log	컴플라이언스 기록과 감사 추적	아니요	아니요	권한 모델 감사 필드 (actor, traceId, action, result)
State Snapshot	다음 단계를 결정하는 현재 상태	예	예	LangGraph checkpoint (현재 노드, 완료된 단계, 다음에 할 일)

핵심 차이는 분명합니다. Trace 는 “무슨 일이 있었는지” 관측하는 데 도움을 주지만 비즈니스 상태 자체는 아닙니다. Audit Log 는 감사와 추적을 위한 이력을 남깁니다. State Snapshot 은 “다음에 무엇을 해야 하는지”를 결정하며 복구의 핵심입니다. 셋은 서로 대체할 수 없습니다. Trace 가 있다고 State 가 있는 것은 아니고, Audit 이 있다고 복구 가능한 것도 아닙니다.

2. LangGraph 는 상태 지속성을 어떻게 다루는가

Checkpoint 는 prompt 안의 자연어 요약이 아닙니다. 복구 가능하고, 검사 가능하며, replay 가능한 상태 snapshot 입니다. LangGraph persistence 문서는 checkpoint 를 graph state snapshot 으로 정의하며, 전체 상태와 다음 실행 노드를 포함한다고 설명합니다.

2.1 Checkpointer 와 Thread State

핵심 메커니즘(LangGraph Persistence 공식 문서 기준):

• Checkpointer: thread-scoped 상태 snapshot (graph state snapshot) 저장
• Store: thread 를 넘는 장기 데이터(application-defined store) 저장
• Thread_id: 특정 thread state 를 복구하는 유일한 진입점
• 네 가지 용도: conversation continuity, human-in-the-loop, time travel, fault tolerance

LangGraph persistence 는 짧은 thread-scoped state 를 checkpointers 에 맡기고, thread 를 넘는 장기 데이터는 stores 에 맡깁니다. Checkpoint 는 state snapshot 과 application-defined store 를 포함합니다. Thread_id 는 복구 진입점이며, 같은 thread_id 를 사용하면 일시 중지 지점에서 이어갈 수 있습니다.

LangGraph checkpoint 에는 graph state, 다음 실행 노드 목록, checkpoint_id, timestamp, version 이 포함됩니다. 민감한 데이터는 checkpoint 에 무작정 넣으면 안 됩니다. 일부 graph state 필드에 민감 정보가 있을 수 있으므로 저장하지 않도록 명시적으로 설정해야 합니다.

2.2 Interrupts 와 복구 메커니즘

핵심 메커니즘(LangGraph Interrupts 공식 문서 기준):

• interrupt(): graph node 내부에서 실행을 동적으로 일시 중지하고 graph state 를 저장한 뒤 외부 입력을 기다림
• 복구 방법: 같은 thread_id 와 Command(resume=…) 사용
• 일반 패턴: approval, review/edit, tool call review, human input validation
• idempotent 부작용 경고: interrupt 이전 부작용은 idempotent 해야 함. 복구 시 interrupt 를 호출한 node 의 처음부터 다시 실행되기 때문

승인 대기는 모델이 “승인을 기다려야 한다”고 기억하기를 바라는 것이 아니라 상태 머신의 일시 중지 상태여야 합니다. 복구에는 같은 thread cursor 가 필요합니다.

복구 시 같은 thread_id 와 Command(resume=…) 를 사용합니다. idempotent 부작용은 안전한 복구의 전제 조건입니다. 승인 전에 외부 API 호출 같은 부작용이 있다면 반드시 idempotent 해야 합니다. 그렇지 않으면 복구된 node 가 API 를 다시 호출합니다.

3. 엔지니어링 비유: Temporal Durable Execution

긴 작업의 신뢰성은 새로운 문제가 아닙니다. Temporal durable execution 은 성숙한 비교 대상을 제공합니다.

3.1 Durable Execution 정의

핵심 개념(Temporal Durable Execution 공식 문서 기준):

• Durable Execution 정의: workflow execution 이 실패, crash, 서비스 중단에도 state/progress 를 보존
• Event History: 각 단계의 상태를 기록하고 실패 후 마지막 기록 event 에서 복구
• 세 가지 특성: Resumable, Recoverable, Reactive

긴 작업의 신뢰성은 event history 와 복구 가능한 실행에서 나옵니다. 단일 프로세스 메모리나 prompt 컨텍스트에서 나오지 않습니다. Agent 상태 머신도 비슷한 메커니즘이 필요합니다. checkpoint/event log + 비즈니스 상태이지, 모델이 다시 추론하는 것만으로는 부족합니다.

Temporal 의 Event History 와 LangGraph 의 checkpoint 는 개념적으로 비슷합니다. 둘 다 실행 이력을 기록하고 실패 지점에서 복구할 수 있게 합니다. 차이는 Temporal 이 완전한 workflow 엔진이고, LangGraph 는 Agent 상태 관리 프레임워크라는 점입니다. Agent 개발자가 배울 점은 분명합니다. durable execution 은 구조화된 상태 이력이 필요하며, 프로세스 메모리나 모델 컨텍스트에 의존해서는 안 됩니다.

4. 상태표 설계 템플릿: 복사해 쓸 수 있는 Agent State Table

상태 머신 개념은 추상적입니다. 실제 적용에는 구체적인 상태 모델이 필요합니다. 아래에는 상태표, 이벤트표, 사고 기반 상태표 예시를 제공합니다.

4.1 상태표 템플릿(실행 가능한 단계 블록)

템플릿 구조:

State	Event	Guard	필수 Action	Next
INIT	task_received	없음	컨텍스트 초기화, 시작 시간 기록	PLAN_READY
PLAN_READY	plan_generated	plan_valid	실행 계획 생성, 도구 순서 기록	TOOL_RUNNING
TOOL_RUNNING	tool_completed	budget_sufficient	도구 호출, 결과 기록, 예산 업데이트	APPROVAL_PENDING 또는 COMPLETED
APPROVAL_PENDING	approve	approval_required	승인 요청 전송, 승인자 기록	COMPLETED
APPROVAL_PENDING	reject	없음	거절 사유 기록, 사용자 알림	FAILED
FAILED	retry	retry_count < max	idempotency 검사, 이전 checkpoint 로 되돌림	TOOL_RUNNING 또는 APPROVAL_PENDING
COMPLETED	없음	없음	완료 시간 기록, 리소스 정리	Terminal

템플릿 설명: State 열은 도달 가능한 모든 상태(INIT, PLAN_READY, TOOL_RUNNING, APPROVAL_PENDING, FAILED, COMPLETED)를 정의합니다. Event 열은 transition 을 트리거하는 event(task_received, approve, reject, retry)를 정의합니다. Guard 열은 상태 진입 전 조건(budget_sufficient, retry_count < max)을 정의합니다. Action 열은 transition 중 필수 동작을 정의합니다. Next 열은 결정적 다음 상태를 정의합니다.

4.2 이벤트표 템플릿(상태표 보완)

템플릿 구조:

Event	트리거 조건	필요한 이전 상태	이후 상태	부작용 발생 여부
task_received	사용자가 작업 제출	INIT	PLAN_READY	없음
plan_generated	LLM 이 실행 계획 생성	PLAN_READY	TOOL_RUNNING	없음
tool_completed	도구 실행 완료	TOOL_RUNNING	APPROVAL_PENDING 또는 COMPLETED	있음(외부 API 호출)
approve	승인자가 승인	APPROVAL_PENDING	COMPLETED	있음(이메일 발송, 예산 차감)
reject	승인자가 거절	APPROVAL_PENDING	FAILED	없음
retry	실패 후 retry 요청	FAILED	TOOL_RUNNING 또는 APPROVAL_PENDING	idempotency 검사 필요
timeout	실행 timeout	TOOL_RUNNING	FAILED	없음

이벤트표 설명: 필요한 이전 상태는 어떤 상태에서 어떤 event 를 받을 수 있는지 명확히 합니다. 부작용 여부는 어떤 event 에 idempotency 또는 compensation 이 필요한지 표시합니다.

4.3 사고 기반 상태표 예시(보고서 덮어쓰기 사고에서 도출)

전체 예시: 보고서 Agent 상태표(도입 사고에서 도출)

State	Event	Guard	Action	Next	idempotency/compensation 검사
INIT	task_received	없음	thread_id 초기화, 시작 시간 기록	QUERY_RUNNING	불필요
QUERY_RUNNING	query_completed	없음	데이터 조회, 결과를 state 에 저장	REPORT_GENERATING	불필요
REPORT_GENERATING	report_generated	없음	보고서 생성, report ID 를 state 에 저장	APPROVAL_PENDING	idempotency 검사: 보고서가 이미 있으면 생성 건너뜀
APPROVAL_PENDING	approve	없음	승인자와 승인 시간 기록	EMAIL_SENDING	불필요
APPROVAL_PENDING	reject	없음	거절 사유 기록	FAILED	불필요
EMAIL_SENDING	email_sent	없음	이메일 발송, email ID 기록	COMPLETED	idempotency 검사: 이미 발송되었으면 건너뜀
EMAIL_SENDING	timeout	retry_count < 3	실패 기록, idempotency 검사	EMAIL_SENDING (retry) 또는 FAILED	idempotency key: email_id + thread_id
FAILED	retry	retry_count < max	idempotency 검사, 이전 checkpoint 에서 복구	QUERY_RUNNING 또는 REPORT_GENERATING 또는 EMAIL_SENDING	checkpoint 에 따라 복구 지점 결정
COMPLETED	없음	없음	완료 시간 기록, 리소스 정리	Terminal	불필요

사고 복구 수정: 5 단계 실패(EMAIL_SENDING -> timeout) 후에는 QUERY_RUNNING 이 아니라 EMAIL_SENDING 에서 복구해야 합니다. checkpoint 는 현재 노드(EMAIL_SENDING), 완료된 단계(QUERY, REPORT_GENERATED, APPROVAL_APPROVED), 다음에 해야 할 일(EMAIL_SENDING)을 기록해야 합니다. 보고서 생성과 이메일 발송에는 idempotency key 가 필요합니다.

5. idempotency 와 compensation: 복구는 checkpoint 만으로 끝나지 않는다

checkpoint 가 있다고 모든 부작용을 안전하게 복구할 수 있는 것은 아닙니다. 복구에는 idempotency, 트랜잭션, compensation, 외부 시스템 상태 확인이 함께 필요합니다.

5.1 idempotency 와 compensation 개념

정의:

• Idempotent: 여러 번 실행해도 결과가 같고 중복 부작용을 만들지 않음
• Compensation: 이미 발생한 부작용을 되돌려 일관성을 회복
• 트랜잭션 rollback: 원자적 작업이 실패 시 자동으로 되돌아감
• 외부 시스템 상태 확인: 복구 전 외부 시스템 상태를 확인해 중복 작업을 방지

상태 일관성의 세 기둥: idempotency 식별자(action_id + schema_hash), state snapshot 체인(snapshot + prev_hash + delta), compensation action 등록(undo_op).

5.2 idempotency 와 compensation 판단 체크리스트

어떤 작업에 idempotency 와 compensation 이 필요한지 판단합니다:

작업 유형	idempotency 필요 여부	compensation 필요 여부	idempotency key 설계	compensation 방안
데이터 조회(부작용 없음)	불필요	불필요	-	-
보고서 생성(파일 덮어쓰기)	필요	필요	report_id + thread_id	새 보고서 삭제, 승인 버전 복원
이메일 발송(외부 API)	필요	어려움	email_id + thread_id	일부 상황에서 정정 또는 취소 이메일 발송
재고 차감(데이터베이스)	필요	필요	inventory_id + order_id	재고 복구
티켓 생성(외부 시스템)	필요	필요	ticket_id + thread_id	티켓 종료
예산 차감(내부 상태)	필요	필요	budget_id + thread_id	예산 복구
승인 요청 발송(지속 부작용 없음)	불필요	불필요	-	-

판단 로직: 외부 부작용을 만드는지 여부가 idempotency 필요성을 결정합니다. 되돌릴 수 있는 작업에는 compensation 이 필요합니다. 시스템 간 호출에서는 idempotency key 에 외부 시스템 식별자를 포함해야 합니다. 원자적 작업은 트랜잭션 rollback 을 사용할 수 있습니다.

복구는 checkpoint 만이 아닙니다. idempotency, 트랜잭션, compensation, 외부 상태 확인이 필요합니다. checkpoint 만 있으면 모든 부작용을 안전하게 복구할 수 있다는 말은 정확하지 않습니다.

6. Agent 작업 상태 체크리스트: 복구 가능 vs 복구 불가

모든 checkpoint 가 복구 가능한 것은 아닙니다. Terminal state 는 workflow execution 의 종료 상태입니다. 완료, 실패, timeout, cancelled 등이 해당합니다. Terminal state 는 이어갈 수 없고, 재실행하거나 보상해야 합니다.

6.1 상태 분류표

상태 유형	복구 가능 여부	복구 조건	복구 방법	예시
Failed	가능	retry_count < max	이전 checkpoint 에서 복구	도구 호출 timeout
Retry	가능	idempotency 검사 통과	실패 노드에서 재실행	이메일 발송 실패
Compensation	부분 가능	compensation 방안 존재	undo_op 실행	재고 차감 실패
Approval Pause	가능	approve/reject event	Command(resume=…)	승인 대기
Terminal	불가	없음	복구 경로 없음	COMPLETED, FAILED (retry_count = max)

상태 체크리스트 설명: Failed 상태는 retry_count < max 이면 retry 로 복구할 수 있습니다. Retry 상태는 idempotency 검사가 필요하며 실패 노드부터 재실행합니다. Compensation 상태는 보상 방안이 있으면 부분적으로 복구 가능합니다. Approval Pause 상태는 approve/reject event 로 복구합니다. Terminal State 는 복구 불가능하며, COMPLETED 또는 최대 retry 횟수에 도달한 FAILED 가 해당합니다.

7. 다음 읽을거리

상태 머신 설계는 출발점일 뿐입니다. 상태 모델링은 구체적인 비즈니스 시나리오와 맞아야 하며, 작업마다 상태 입도와 복구 전략이 달라집니다.

시리즈 내비게이션

글	관계	링크
Human-in-the-loop Agent 설계: 어떤 단계에 사람 승인이 필요한가	승인 일시 중지 세부 사항	/blog/ko/posts/ai/20260707-human-in-the-loop-agent-approval-design/
Agent 비용 제어: model routing, 도구 예산, 실패 retry 설계	예산과 retry 전략	/blog/ko/posts/ai/20260707-agent-cost-control-model-routing-tool-budget-cache-retry/
LangGraph 상태 관리 실전: 2026 Agent 아키텍처 모범 사례	LangGraph 상태 관리	/blog/ko/posts/ai/20260424-langgraph-agent-architecture/
AI Agent 모니터링, 알림, 실패 복구: 로그에서 상태 머신까지	모니터링과 복구	/blog/ko/posts/ai/20260527-ai-agent-monitoring-recovery/
LangGraph vs AutoGen 상태 추적	프레임워크 비교	/blog/ko/posts/ai/20260526-langgraph-autogen-state-tracking/
Agent 평가 데이터셋과 회귀 테스트: 한 곳을 바꿨더니 전체가 망가지는 일을 피하는 법	평가와 회귀 테스트	예고, 시리즈 다음 글

외부 참고 자료

신뢰도 높은 출처:

출처	신뢰도	주제	링크
LangGraph Persistence 공식 문서	high	Checkpointer, Store, Thread State, Checkpoint	https://docs.langchain.com/oss/python/langgraph/persistence
LangGraph Interrupts 공식 문서	high	interrupt(), Command(resume=…), thread_id	https://docs.langchain.com/oss/python/langgraph/interrupts
Temporal Durable Execution 공식 문서	high	Event History, Durable Execution, Resumable/Recoverable	https://docs.temporal.io/temporal
OpenAI Agents SDK Tracing 공식 문서	high	Trace, Span, workflow_name, trace_id	https://openai.github.io/openai-agents-python/tracing/
AWS Step Functions State Machines 공식 문서	high	State Machine, Flow State, Task State, StartAt, Next	https://docs.aws.amazon.com/step-functions/latest/dg/concepts-statemachines.html
Stately: State machines and statecharts	medium	State, Event, Transition, Guard, Action, Hierarchy	https://stately.ai/docs/state-machines-and-statecharts

상태 머신은 모든 Agent 에 필요한 구조는 아닙니다. 하지만 복잡한 작업은 진행 상태를 명시해야 합니다. 다음 단계는 더 많은 프레임워크를 들이는 것이 아닙니다. 비즈니스 시나리오에 맞는 State, Event, Transition, Guard, Action 을 설계하고, 작업 진행 상태를 prompt 의 자연어에서 구조화된 상태로 옮기는 것입니다.