상태 머신으로 LLM 워크플로를 다루기
상태 머신과 워크플로 그래프가 agent 실행 경로를 제한하고, 디버깅과 테스트, 재시작 복구를 가능하게 만드는 방식을 설명한다. 특히 guard, action, effect 분리와 checkpoint, replay, versioning이 운영 가능한 workflow의 핵심임을 짚는다.
Script Companion
오디오와 함께 스크립트 보기
- 01
상태 머신과 워크플로 그래프를 설계하는 이유는 agent를 무한 루프에서 꺼내기 위해서다. 다음에 무엇을 할지를 모델에만 맡기면 가능한 경로가 넓어지고, 실패했을 때 어디서 잘못됐는지 추적하기 어렵다. 상태와 이벤트, 전이를 명시하면 현재 상태와 직전 이벤트만 보아도 실패 위치를 좁힐 수 있고, 승인 대기나 수정 요청, 재시도처럼 사람이 끼어드는 block 상태도 자연스럽게 표현할 수 있다.
- 02
먼저 state machine과 stateful system을 구분해야 한다. State machine은 가능한 상태와 전이를 정의하는 모델이고, stateful system은 그 모델을 실제 운영 환경에서 저장하고, 복원하고, 관측하고, 마이그레이션하는 시스템이다. 예를 들어 waiting_for_human에서 approved를 거쳐 acting으로 가는 전이를 정의하는 것은 state machine 설계다. 서버가 재시작되어도 같은 run을 복원하고, 승인 이벤트가 두 번 와도 한 번만 처리하며, workflow 코드 v2 배포 후에도 v1 run을 깨뜨리지 않는 것은 stateful system 설계다.
- 03
FSM의 기본 장점은 현재 상태에서 받을 수 없는 이벤트를 명확히 거부할 수 있다는 점이다. 작은 승인 workflow라도 transition table을 먼저 적어보면 누락된 전이가 보인다. planning 상태에서 START가 들어와 acting으로 갈 수 있는지, acting 상태에서 TOOL_ERROR가 반복될 때 failed_transient로 갈지, done 상태에서 APPROVE가 들어오면 거부해야 하는지가 표로 드러난다. 전이 테스트는 invalid transition 거부, TOOL_ERROR 반복 후 fallback 진입, APPROVE 중복 수신 시 상태가 한 번만 바뀌는지를 확인해야 한다.
- 04
Statechart는 FSM에 계층, 병렬, history, guard 개념을 더한다. running.searching과 running.calling_tool처럼 큰 상태 안에 세부 상태를 둘 수 있고, drafting과 compliance_check를 동시에 진행하는 병렬 상태도 표현할 수 있다. 특히 모델이 참여하는 LLM workflow에서는 human review 후 어디로 돌아갈지가 중요하므로 history state가 의미를 갖는다. confidence가 0.8 이상일 때만 자동 진행하는 것처럼, guard는 전이가 가능한 조건을 코드와 테스트의 대상으로 만든다.
- 05
Workflow graph는 상태보다 실행 step을 중심으로 흐름을 표현한다. FSM이 상태 중심이라면 graph는 node와 edge 중심이며, LangGraph 같은 agent framework는 state를 공유 객체로 두고 node가 state를 갱신한다. 이때 guard, action, effect를 분리해야 한다. Guard는 risk가 threshold보다 작은지처럼 전이 가능 여부를 판단하고, action은 attempt를 늘리는 내부 state 갱신을 맡는다. Effect는 이메일 발송이나 DB 업데이트 같은 외부 side effect다. Durable execution에서는 effect를 재실행하면 안 되므로 이 분리가 필수다.
- 06
LLM node를 graph 안에 넣을 때는 출력 계약이 필요하다. 자유 텍스트 답변을 바로 edge condition에 쓰면 parsing 실패가 workflow 실패로 번질 수 있다. LLM node가 참고할 입력은 L12-100 Context Engineering의 context bundle로 관리하고, graph state에는 다음 전이를 결정하는 데 필요한 최소 상태만 남기는 편이 안전하다. 검색 결과 원문이나 긴 tool 로그를 graph state에 계속 누적하면 persistence 비용과 replay 노이즈가 함께 커진다.
- 07
재시도는 단순한 edge가 아니라 상태로 모델링하는 편이 안전하다. 실패 후 다시 시도하는 흐름에는 attempt, max_attempts, fallback 같은 판단 기준이 필요하고, 이것이 숨겨지면 unbounded loop가 되기 쉽다. 외부 side effect가 이미 일어났다면 L9 Saga처럼 보상 action을 별도 node로 둔다. 조건 판단 중 외부 API를 호출하는 side effect in guard도 피해야 한다. Guard는 순수 함수로 남겨야 같은 입력에서 같은 판단을 재현할 수 있다.
- 08
운영 가능한 workflow graph는 현재 node가 어디인지만 저장하지 않는다. Checkpoint에는 현재 state, context summary, attempts, timers를 담아 crash 후 마지막 안전 지점에서 재개한다. Persistence는 checkpoint를 durable store에 기록해 worker 교체, 배포, 장기 대기에도 상태를 보존한다. Replay는 event log나 history로 같은 결정을 재현해 사고 분석, regression test, human approval 재개에 쓴다. Versioning은 state schema와 transition graph 버전을 분리해 진행 중 run을 새 코드 배포와 충돌하지 않게 한다.
- 09
Checkpoint는 snapshot이고 replay는 history다. Snapshot만 있으면 왜 이 상태가 되었는지가 약하고, history만 있으면 긴 workflow 재구성이 비싸다. 그래서 production에서는 보통 event history와 최신 checkpoint를 함께 둔다. LLM 입력 원문은 재현성에는 좋지만 PII, secret, 비용 문제가 있으므로 redaction과 reference 저장을 우선한다. Tool side effect 결과는 idempotency key와 함께 저장하고, context summary는 다음 step 판단에 필요한 사실만 구조화하며, 원문 근거는 문서 ID와 span ID로 참조한다.
- 10
Agent graph의 흔한 안티패턴은 실행 경계를 흐리는 데서 나온다. Everything node는 한 node가 분류, 검색, 도구, 응답을 모두 수행해 디버깅 단위를 잃게 만든다. Hidden state는 상태가 prompt 문자열 안에만 존재하게 만들므로 typed state schema가 필요하다. UI state와 실행 state를 섞으면 화면 표시 변경이 workflow 의미를 바꿀 수 있어 UI projection을 분리해야 한다. Unversioned transition은 배포 후 진행 중 run이 새 graph와 충돌하게 만들므로 graph와 schema version을 고정해야 한다.
- 11
이 설계는 상담 봇의 draft, review, send 승인 플로우나 코드 agent의 plan, edit, test, fix, summarize 루프에서 바로 드러난다. RAG pipeline의 retrieve, rerank, answer, judge, fallback 흐름과 결제나 주문처럼 보상이 필요한 AI-assisted workflow, batch 평가 시스템의 queue 상태 관리에도 같은 원리가 적용된다. 프론트엔드에서 복잡한 모달과 폼 상태를 boolean 여러 개로 관리하면 불가능한 조합이 생기듯, AI workflow도 실행 상태를 명시적으로 모델링해야 운영이 된다. 핵심은 모델의 자율성을 없애는 것이 아니라 위험한 경로를 좁히는 것이다.
같은 레이어
L12에서 이어 듣기
- LLM API 기초와 운영 감각 길이 미정
- 운영 자산으로 보는 프롬프트 엔지니어링 길이 미정
- 임베딩과 벡터 운영의 핵심 경로 길이 미정
- RAG 기초: 검색, 주입, 생성의 운영 기준 길이 미정
- LLM 도구 호출의 설계와 운영 길이 미정
- 에이전트 오케스트레이션 운영 기준 길이 미정
- LLM 비용과 지연을 운영 지표로 읽는 법 길이 미정
- LLM 보안과 운영 방어 계층 길이 미정
- LLM 운영을 위한 관측성과 평가 길이 미정
- 에이전틱 LLM의 컨텍스트 파이프라인 길이 미정
- AI 워크플로를 위한 Temporal Durable Execution 길이 미정
- Human-in-the-loop AI 워크플로 설계 길이 미정
- AI 앱의 온톨로지와 역량 모델링 길이 미정
- 심리측정으로 설계하는 SJT와 LLM 평가 길이 미정