AI가 요청을 정리하고 예약을 만들었는데 마지막 안내 전송이 실패했다. 전체 업무를 다시 실행할까, 이미 만든 예약을 취소할까? 먼저 단계별 실제 상태를 맞춘 뒤, 성공을 보존해 남은 일을 이어갈지, 업무를 중단하고 보상할지 결정해야 한다. 마지막 단계의 실패는 앞 단계가 모두 없던 일이 됐다는 뜻이 아니다.
이 글은 여러 서비스에 걸친 AI 업무 자동화에서 부분 성공을 처리하는 방법을 다룬다. 재시도 간격이나 횟수보다, 이미 끝난 업무를 어떻게 취급할지가 중심이다. 아래 사례는 설명용 가상 상황이며 실제 예약·전송·취소를 실행한 결과가 아니다.
재개와 보상은 서로 다른 목표를 가진다
재개는 원래 목표가 여전히 유효할 때 끝나지 않은 일을 이어가는 것이다. 보상은 이미 반영한 업무의 효과를 규칙에 맞춰 상쇄하는 별도 행동이다. 예약 취소, 재고 배정 해제, 정정 안내 등이 예가 될 수 있지만, 서비스마다 가능한 동작과 권한이 다르다.
Azure의 보상 트랜잭션 문서는 과거 데이터를 그대로 복원하면 그동안 다른 사용자가 한 변경을 덮어쓸 수 있다고 설명한다. 보상은 업무 규칙과 동시 변경을 고려해야 하며, 항상 최초 상태로 돌아가거나 실행의 정확한 역순으로 진행되는 것도 아니다.
따라서 “실패하면 롤백”이라는 문장만으로 복구 설계를 끝낼 수 없다. 이미 발송된 안내를 상대가 읽은 사실은 데이터 필드를 예전 값으로 돌려도 사라지지 않는다. 새 정정 안내가 필요할 수 있으며 그것도 새로운 외부 행동이다. 무엇을 취소할 수 있고 어떤 영향이 남는지 먼저 구별한다.
가상 사례: 장비 예약은 끝났고 안내만 불명확하다
AI가 교육 신청을 읽고 장비를 예약한 뒤 참석자에게 안내를 보내는 가상 흐름을 생각해 보자. 신청 등록과 장비 예약에는 ID가 반환됐다. 안내 전송에서는 응답이 끊겼다. 자동화 화면에는 전체 실패가 표시되지만, 그것만으로 예약을 다시 만들거나 취소하지 않는다.
| 단계 | 지금 가진 근거 | 상태 확인 후 가능한 다음 행동 |
|---|---|---|
| 신청 등록 | 신청 ID가 있고 현재 조회에서도 존재 | 기존 신청을 유지하고 새 신청을 만들지 않음 |
| 장비 예약 | 예약 ID로 시간·대상 장비·유효 상태 확인 | 원래 교육이 진행되면 예약을 보존 |
| 안내 전송 | 응답 유실로 발송 여부 미확인 | 발송 기록과 요청 식별자로 확인; 미발송이 확인되고 허용되면 남은 전송만 수행 |
| 전체 업무 판단 | 예약은 유효하지만 안내 결과가 아직 미정 | 전체 완료를 선언하지 않고 남은 확인과 담당을 기록 |
발송 상태를 조회할 방법이 없고 중복 방지도 보장되지 않는다면 안내 재전송은 보류할 수 있다. 그렇다고 예약 성공을 실패로 고치거나 예약을 다시 만드는 것은 해결이 아니다. 근거가 있는 성공과 확인하지 못한 효과를 함께 유지해야 한다.
교육 자체가 취소됐다면 판단이 달라진다. 기존 예약 ID에 대해 취소가 가능한지, 취소 권한과 조건이 맞는지 확인한 뒤 예약 취소를 별도 동작으로 진행한다. 안내가 이미 발송됐다면 취소 안내도 필요할 수 있다. 이 선택은 “원래 업무를 끝낸다”에서 “업무를 중단하고 영향을 정리한다”로 목표가 바뀌는 것이므로, 자동화에 미리 맡긴 판단 범위를 확인해야 한다.
같은 단계 목록으로 기대 결과와 실제 결과를 맞춘다
작성자가 제안하는 실무 기록은 거대한 상태 체계보다 실제 다음 행동을 고를 수 있는 표에 가깝다. 각 단계의 요청 식별자, 반환된 대상 ID, 현재 확인한 값, 미확인 효과, 남은 행동을 연결한다. 보상이 필요하다면 취소 대상과 조건, 보상 결과도 원래 단계에 붙인다.
예를 들어 예약 생성 요청의 내부 상태는 실패여도 예약 ID가 실제로 존재하면 “예약 생성 확인”으로 구분한다. 반대로 전송 API가 접수 ID를 반환했더라도 그것이 수신 완료를 뜻하는지는 해당 API의 계약을 읽어야 한다. 근거가 접수까지만 있으면 전달 완료로 적지 않는다.
자동화가 남긴 전체 성공·실패 표시와 외부 상태가 다를 때는 그 차이를 남긴다. 과거 실패 로그를 지우는 대신, 어떤 조회로 실제 결과를 정정했는지 덧붙이면 다음 담당자가 같은 성공을 다시 실행하지 않을 수 있다.
보상도 실패할 수 있으므로 끝난 지점을 보존한다
Azure 문서는 보상 작업 자체도 실패할 수 있어 진행 상태를 남기고 실패 지점부터 이어갈 수 있어야 한다고 설명한다. 반복 가능한 보상 단계에는 멱등성을 고려하며, 자동 복구가 어려운 경우 수동 판단에 필요한 정보를 제공한다. 취소 요청을 보냈다는 기록만으로 취소가 끝났다고 볼 수 없는 이유다.
AWS의 saga orchestration 설명도 여러 로컬 작업과 보상으로 구성된 흐름에서 멱등성과 관측이 필요하고, 트랜잭션 격리가 없어 동시 실행으로 오래된 데이터를 볼 수 있다고 설명한다. 이런 패턴 이름을 붙였다는 이유로 전체 업무가 한 번에 원자적으로 성공·취소되는 것은 아니다.
| 현재 확인한 조건 | 복구 방향 | 피해야 할 처리 |
|---|---|---|
| 원래 목표가 유효하고 성공 단계가 확인됨 | 성공을 보존해 미완료 단계부터 재개 | 전체를 처음부터 돌려 성공 결과를 복제 |
| 외부 반영 여부가 불명확함 | 기존 ID·요청 기록으로 상태를 확인 | 확인 없이 재실행이나 취소를 먼저 발행 |
| 목표가 취소됐고 보상이 허용됨 | 현재 상태를 고려해 필요한 효과를 상쇄 | 오래된 전체 스냅샷을 덮어써 타인의 변경까지 제거 |
| 보상 일부만 끝남 | 끝난 취소와 남은 취소를 나눠 이어 처리 | 보상 시작을 전체 원상복구 완료로 보고 |
이 표는 모든 업무에 새 coordinator를 도입하라는 제안이 아니다. 기존 실행 기록과 서비스의 조회·취소 기능으로 다음 판단을 할 수 있다면 그것을 먼저 쓴다. 필요한 것은 실패 표시를 감추는 장치가 아니라 완료된 외부 효과와 남은 책임을 잃지 않는 처리다.
자주 묻는 질문
마지막 단계만 실패했으면 그 단계만 바로 재시도하면 되나요?
그 단계가 실제 미실행인지, 이미 반영됐지만 응답만 유실됐는지 먼저 구별한다. 같은 요청을 식별하거나 결과를 조회할 수 있는지 등 재실행 조건은 AI 자동화 재시도 정책을 함께 참고할 수 있다.
보상은 항상 생성한 순서의 반대로 하면 되나요?
업무 의존성과 남은 영향에 따라 달라진다. 안내를 정정하기 전에 예약 상태를 확정해야 하는 경우도 있다. 가능하다는 이유만으로 병렬 취소하지 말고 어떤 결과가 다음 단계의 전제인지 확인한다.
취소 API가 없으면 복구할 수 없는 건가요?
원상복구와 영향 완화는 다르다. 정정 안내나 별도 조치로 피해를 줄일 수 있어도 이미 발생한 효과를 없앴다고 보고할 수는 없다. 가능한 조치와 필요한 권한, 남은 영향을 명시해 판단한다.
복구 중 다른 사람이 기록을 바꿨다면 오래된 승인과 조건부 갱신의 확인도 필요하다. 처음 실행할 때 어떤 검사와 미확인 단계가 있었는지는 dry-run과 변경 미리보기의 한계에서 구별할 수 있다.