중단돼도 이어지는 AI 에이전트: 상태 저장과 재실행 설계

장기 업무에는 대기와 중단이 포함됩니다

LangGraph의 영속성 문서는 한 작업 흐름의 상태를 저장하는 체크포인터와 여러 실행에 걸쳐 정보를 보관하는 스토어를 구분합니다. 이런 상태 저장은 승인 대기나 장애 후 재개에 활용할 수 있습니다. 다만 상태를 저장했다는 사실과 외부 업무를 정확히 한 번 처리했다는 사실은 별개입니다.

가상의 구매 요청 에이전트가 견적 비교를 마친 뒤 팀장 승인을 기다린다고 가정해 보세요. 다음 날 서버가 재시작되어도 어떤 요청을 누구에게 승인받는 중인지 남아 있어야 합니다. 승인 버튼을 두 번 눌렀을 때 발주가 중복 생성되지 않는 처리도 필요합니다.

무엇을 저장하는지 구분합니다

응답이 없으면 실패했다고 단정하지 않습니다

외부 시스템이 발주를 저장한 직후 네트워크가 끊기면 에이전트는 성공 응답을 받지 못합니다. 이때 요청을 새로 만들기보다 같은 업무 ID로 처리 여부를 조회해야 합니다. 상대 API가 중복 방지 키를 지원하면 활용하고, 지원하지 않는다면 내부 처리 장부와 결과 대사 절차를 설계하세요.

대화 체크포인트를 되돌려도 이미 보낸 알림이나 생성된 발주가 자동으로 취소되는 것은 아닙니다. 업무별로 취소 가능한 시점과 보정 방법을 정해야 합니다. 조회는 다시 실행해도 되지만 상태를 바꾸는 단계는 같은 기준으로 다룰 수 없다는 점을 작업 설계에 반영합니다.

재개 전에 승인과 데이터의 유효성을 확인합니다

승인 대기 중 견적 금액이나 수량이 바뀌면 과거 승인을 그대로 사용할 수 없습니다. 승인 대상 데이터의 버전을 기록하고 실행 직전에 비교하세요. 운영에서는 메모리에만 상태를 저장하지 말고 재시작 후에도 남는 저장소를 사용하며, 작업별 접근 권한과 보관 기간도 함께 정합니다.

대기 중인 업무에도 만료 조건이 필요합니다. 예를 들어 견적 유효 기간이 지나면 승인 버튼을 비활성화하고 재조회 단계로 돌릴 수 있습니다. 담당자가 퇴사하거나 요청자가 취소한 경우도 별도 상태로 남겨, 오래된 작업이 뒤늦게 실행되지 않게 하세요.

중단 시나리오로 검수합니다

• 각 단계에서 프로세스를 멈춰도 미완료 업무를 찾을 수 있는가
• 같은 승인 이벤트가 반복돼도 한 번만 처리되는가
• 외부 처리 성공 후 응답만 유실된 경우를 복구할 수 있는가
• 승인 이후 데이터 변경을 감지하는가
• 자동 복구가 끝나지 않으면 담당자가 재처리할 수 있는가