상태 관리 — 10단계 워크플로우가 3단계에서 멈췄을 때
한줄 요약
상태(State)는 워크플로우의 작업 기억이다 — 어느 단계에서 멈춰도 그 단계부터 재개할 수 있게 해준다.
본문
10단계 수술 전 체크리스트를 상상해보자
10개 항목의 수술 전 체크리스트가 있다. 8번째 항목을 확인하다가 담당 간호사가 교대했다면, 처음부터 다시 시작하지 않는다. 8번째부터 이어간다. 체크리스트 자체가 어디까지 완료했는지 기록하고 있기 때문이다.
AI 오케스트레이션의 상태 관리가 정확히 이 역할이다.
10단계 AI 워크플로우에서 7단계가 끝난 뒤 외부 API 오류가 났다. 상태 관리가 없으면 1단계부터 다시 실행해야 한다. 이미 완료된 6단계 분의 시간과 비용이 낭비된다. 상태 관리가 있으면 7단계부터 재시도한다.
의료 AI에서는 더 중요한 케이스가 있다. 의사의 확인을 기다리는 동안 워크플로우가 중단된다. 승인이 오면 그 다음 단계부터 이어가야 한다.
상태에 무엇을 담아야 하는가
3가지로 구분한다.
① 입력 상태 — 처음 주어진 데이터
워크플로우 시작 시 들어온 정보. 절대 변경하지 않는다.
환자 ID: P-20234
요청한 의사: 김민준
요청 내용: 치료 계획 수립
요청 시각: 2026-04-02 09:00② 작업 상태 — 각 단계가 쌓아가는 결과
각 에이전트가 처리하면서 추가하는 데이터. 이전 결과를 덮어쓰지 않고 새 필드로 추가한다.
수집 단계 완료:
→ emr_summary: "입원 3일차, 당뇨 + CKD 기저질환..."
→ lab_results: {HbA1c: 9.2, eGFR: 38, K+: 4.9}
→ current_meds: ["메트포르민 500mg", "리시노프릴 5mg"]
분석 단계 완료:
→ diagnosis: "메트포르민 금기 (eGFR<45)"
→ risk_flags: ["고칼륨혈증 주의"]
계획 단계 완료:
→ treatment_options: [...]
→ recommended_plan: "GLP-1 RA로 전환 권고"이전 단계 결과가 모두 남아있어서 “왜 이런 결론이 나왔는가”를 역추적할 수 있다.
③ 메타 상태 — 워크플로우 실행 현황
어느 단계까지 완료했는지, 오류가 있었는지, 재시도 횟수.
현재 단계: 의사 승인 대기
완료 단계: [수집, 분석, 계획 생성]
실패 단계: []
재시도 횟수: {lab_fetch: 1}
대기 시작: 2026-04-02 09:15병렬 실행과 상태 충돌 문제
여러 에이전트가 동시에 실행될 때 같은 상태 필드를 수정하려 하면 충돌이 생긴다.
안전한 방법: 각 에이전트가 자신의 전용 필드만 쓴다.
Lab 에이전트 → lab_results 필드만 씀
영상 에이전트 → imaging_findings 필드만 씀
약물 에이전트 → medication_review 필드만 씀
요약 에이전트 → 위 세 필드를 읽어서 summary 필드에 씀각 에이전트의 담당 필드가 겹치지 않으면 동시에 실행해도 충돌이 없다.
체크포인트: 언제 저장하는가
모든 상태 변화를 저장하면 비용이 크다. 중요한 지점만 저장한다.
의료 AI 워크플로우의 권장 체크포인트:
| 체크포인트 | 이유 |
|---|---|
| 데이터 수집 완료 후 | 가장 비용이 큰 단계. 재실행하면 낭비가 크다 |
| 의사 승인 요청 전 | 승인/거부 결정이 이 상태에 연결됨 |
| 의사 승인 후 | 무엇이 승인됐는지 기록 |
| 워크플로우 완료 | 전체 감사 기록 |
장기 실행 워크플로우
의료 워크플로우는 분에서 시간, 경우에 따라 며칠이 걸릴 수 있다. AI가 오전 7시에 회진 준비를 하고, 의사가 오전 10시에 검토하고 승인하는 것처럼.
이 경우 상태를 서버 메모리가 아닌 영속적 DB에 저장해야 한다. 서버가 재시작되거나 시간이 지나도 정확히 멈춘 지점부터 재개할 수 있다.
저장해야 할 내용:
- 현재 상태 전체 (JSON 형태)
- 어느 단계에서 대기 중인지
- 대기를 해제할 조건 (의사 승인 ID, 만료 시각)
상태 설계 원칙 요약
원본은 건드리지 않는다. 각 단계는 이전 상태를 덮어쓰지 않고 새 필드를 추가한다. 나중에 “왜 이 결정이 나왔나”를 추적할 수 있어야 한다.
필드 소유권을 명확히 한다. 어떤 에이전트가 어떤 필드를 쓰는지 설계 단계에서 정한다. 충돌 방지.
중요한 지점만 체크포인트. 모든 변화를 저장하면 오버헤드가 크다.
사람 개입 전후는 반드시 저장. 의사 승인 요청 전과 승인 후는 별도 체크포인트로 저장한다.
더 알고 싶다면
🔗 관련 글
- 병렬 실행 — 병렬 실행 시 상태 충돌이 발생하는 이유
- Human-in-the-Loop — 사람 개입 전후를 체크포인트로 저장하는 방법
- 컨텍스트 윈도우 관리 — 상태 저장과 컨텍스트 전달의 차이
- LangGraph 입문 — 상태 머신을 그래프로 구현하는 방법