AI의 실행에는 승인한 대상과 확인된 결과가 필요합니다

담당자가 AI의 발주 변경안을 승인했습니다. 그런데 실행 전에 구매 수량이 바뀌었고, 공급자 API는 응답을 보내지 않았습니다. 화면에 “완료”를 표시해도 되는지는 답변 문장만으로 판단할 수 없습니다.

실행을 맡기려면 무엇을 승인했고, 실제로 무엇이 적용됐는지 연결해야 합니다. 아래는 발주 변경을 예로 든 설계 검토입니다.

승인은 특정 변경안에 연결합니다

검토자는 발주번호, 변경 전·후 수량, 납기, 비용 영향과 적용 대상을 봅니다. 승인 기록은 이 내용과 대상 버전에 연결합니다. 이후 다른 담당자가 수량을 바꿨다면 원래 승인을 그대로 적용하지 않고 현재 상태에서 다시 검토합니다.

“구매 업무를 처리해도 좋다”는 넓은 지시와 “이 발주의 수량을 100개에서 120개로 바꾼다”는 승인은 범위가 다릅니다. 업무 정책이 허용하는 범위를 실행 시점에 확인할 수 있어야 합니다.

같은 요청이 다시 왔을 때의 의미를 정합니다

네트워크 응답이 없으면 클라이언트는 재전송할 수 있습니다. 이때 같은 업무 요청인지 식별하고 이미 처리한 결과를 조회할 수 있어야 합니다. 같은 식별자로 다른 수량을 보내면 별도 변경으로 판단해야 합니다.

이런 재시도 설계를 다루는 기본 개념이 멱등성입니다. AWS Builders' Library는 호출자의 요청 식별자를 이용해 반복 요청의 의도를 구분하는 방법을 설명합니다. Making retries safe with idempotent APIs

외부 시스템이 중복 방지나 결과 조회를 지원하는지도 확인합니다. 로컬 기록에 키가 있다는 사실만으로 외부 효과가 한 번만 발생했다고 증명할 수는 없습니다.

완료·불명·중단을 다르게 표시합니다

중단 버튼은 이미 발송된 발주를 되돌리는 버튼이 아닙니다. 취소나 원상 복구가 필요하면 별도의 권한과 대상 확인을 가진 업무로 다룹니다.

도입 검토에서 한 번씩 실행해 볼 상황

권한 없는 사용자, 승인 후 수정, 중복 전송, 응답 유실, 중간 중단을 같은 사례로 시험합니다. 요청 식별자, 승인한 내용, 호출한 동작, 확인된 결과와 담당자가 한 흐름으로 남는지 보세요. 상세한 내부 추론 대신 업무를 재구성할 수 있는 사실 기록이 필요합니다.

Agents의 적용 범위 살펴보기