AI 에이전트 업무를 대화가 아닌 상태 기계로 관리해야 하는 이유

에이전트가 '해 두었습니다'라고 말했지만 실제 외부 시스템에는 반영되지 않은 경험이 생기면 운영자는 대화를 믿기 어렵습니다. 여러 API를 거치는 업무는 채팅 기록보다 명시적인 작업 상태와 재시도 규칙으로 관리해야 합니다.

대화와 작업은 다른 저장 대상이다

대화에는 사용자의 의도와 설명이 남지만 결제·등록·승인 같은 작업의 현재 상태를 보장하지 못합니다. 작업마다 고유 ID, 요청자, 입력 버전, 상태, 결과를 별도 저장합니다. 화면을 닫거나 모델이 바뀌어도 같은 작업을 추적할 수 있어야 합니다.

예를 들어 초안, 승인 대기, 실행 중, 완료, 실패, 취소처럼 서로 겹치지 않는 상태를 둡니다. 어떤 상태에서 어떤 상태로 이동할 수 있는지 서버가 정합니다. 모델의 자연어 설명이 상태를 바꾸는 권한이 되어서는 안 됩니다.

검색이나 계산은 반복해도 비교적 안전하지만 고객에게 알림을 보내는 단계는 중복 실행 비용이 큽니다. 각 단계에 멱등 키와 재시도 한도를 두고, 이미 성공한 외부 호출을 다시 하지 않게 결과를 기록합니다. 실패를 '처음부터 다시'로 처리하면 중복이 생깁니다.

사람 승인을 기다리거나 외부 시스템이 지연될 수 있습니다. 시간 초과와 취소 요청을 상태로 표현하고, 취소 가능한 단계와 이미 되돌릴 수 없는 단계를 구분합니다. 사용자에게는 현재 단계와 다음 조치를 보여 줍니다.

서버가 실행 중 재시작되거나 네트워크가 끊긴 상황을 시험합니다. 작업 ID로 이어서 처리되는지, 동일 단계가 중복 실행되지 않는지 확인합니다. 성공 경로만 동작하는 에이전트보다 실패 뒤 상태를 설명할 수 있는 에이전트가 운영에 유용합니다.

주의할 실패: 대화 기록만 믿으면 실행 완료 여부와 재시도 중복을 구분할 수 없다.

관찰할 지표: 미완료 작업 수, 재시도 횟수, 중복 차단 건수를 본다.

AWS Step Functions error handling. AWS 문서는 상태별 오류 처리와 재시도·재구동을 설명합니다. 에이전트 작업에 적용하는 상태 설계는 본문의 실무 제안입니다.

이미지와 도식은 이해를 돕기 위한 개념 시각화입니다. 특정 고객의 실제 설비·데이터·화면을 재현한 것이 아닙니다.

#AI에이전트 #상태기계 #업무자동화 #멱등성 #워크플로 #재시도 #사람승인 #에이전트운영 #장애복구 #기업AI