AI Agent 부분 실패, 한 단계만 성공했을 때 복구하는 기준
AI Agent가 이메일·CRM·ERP를 연속 실행하다 일부 단계만 성공했을 때, 단순 재시도 대신 상태 기록·보상 작업·사람 개입으로 복구하는 기준을 정리합니다.
AI Agent가 고객 문의를 읽고 CRM 상태를 바꾼 뒤 안내 메일까지 보내는 흐름을 생각해보세요. CRM 수정은 성공했지만 메일 API가 시간 초과되면 자동화는 실패일까요, 성공일까요? 처음부터 다시 실행하면 CRM이 중복 수정되거나 고객이 같은 안내를 두 번 받을 수 있습니다.
여러 도구를 잇는 자동화는 모든 단계가 함께 성공하거나 함께 취소되는 하나의 트랜잭션이 아닐 때가 많습니다. 그래서 ‘실패하면 재시도’만으로는 부족합니다. 어디까지 끝났는지 기록하고, 이미 일어난 일을 업무 규칙에 맞게 보정하며, 애매한 상태는 사람에게 넘기는 설계가 필요합니다.
핵심 요약
- 워크플로우 전체를 성공·실패 두 값으로만 보지 말고, 각 단계의 성공·실패·처리 중·상태 불명을 따로 기록합니다.
- 하나의 업무 요청에 workflow ID를 부여하고, 외부 도구 호출마다 단계 ID와 실제 결과 식별자를 연결합니다.
- 메일 발송, CRM 수정, 결제 요청처럼 외부에 흔적을 남기는 작업은 되돌릴 수 있는지와 보상 작업을 미리 정합니다.
- 재시도 가능한 오류만 해당 단계부터 다시 실행하고, 같은 요청이 여러 번 와도 결과가 중복되지 않게 설계합니다.
- 보상 작업도 실패할 수 있으므로 진행 상태, 담당자, 알림, 실제 시스템과의 사후 대조까지 운영 흐름에 포함합니다.
부분 실패를 0으로 만드는 것보다, 부분 성공 상태를 찾아 안전한 다음 행동을 정하는 것이 운영 설계의 핵심입니다.
왜 부분 실패는 일반적인 오류보다 다루기 어려울까
AI Agent는 한 번의 요청으로 문서함, CRM, ERP, 이메일, 메신저처럼 서로 다른 시스템을 차례로 호출할 수 있습니다. 앞 단계는 이미 반영됐는데 뒤 단계가 실패하거나, 외부 시스템은 처리했지만 응답만 돌아오지 않는 상태도 생깁니다.
이때 전체를 실패로 표시하면 이미 일어난 변경을 놓치고, 전체를 성공으로 표시하면 남은 업무가 사라집니다. 처음부터 재실행하면 중복 발송·중복 등록이 생길 수 있고, 무조건 되돌리면 정상적으로 완료된 업무까지 훼손할 수 있습니다.
Microsoft Azure Architecture Center는 여러 단계로 이뤄진 작업에서 일부 단계가 실패할 때 보상 트랜잭션을 사용할 수 있다고 설명합니다. AWS의 Saga 오케스트레이션 문서도 보상 작업, 멱등성, 관측성을 함께 고려해야 한다고 안내합니다. NIST AI RMF의 MANAGE 기능처럼 우선순위가 높은 위험 대응은 사전에 계획하고 문서화하는 편이 안전합니다.
먼저 하나의 자동화를 단계로 쪼갭니다
복구 설계는 오류 코드부터 정하는 일이 아닙니다. 현업이 ‘한 건의 업무’라고 부르는 흐름을 실제 부수 효과가 생기는 단계로 나눠야 합니다. 예를 들어 고객 계약서 접수 자동화라면 다음과 같이 볼 수 있습니다.
- 업무 요청을 workflow ID로 접수하고 입력값, 고객, 승인 상태를 고정합니다.
- 문서함에 파일을 저장하고 파일 ID와 체크섬을 기록합니다.
- CRM에 고객 상태와 담당자를 업데이트하고 변경 이력을 남깁니다.
- 고객에게 접수 안내 메일을 보내고 메시지 ID를 저장합니다.
- 운영 메신저에 완료 알림을 보내고 후속 담당자를 지정합니다.
각 단계는 다음 단계로 넘어가기 전에 결과를 남겨야 합니다. 그래야 4번에서 실패해도 1번부터 다시 돌리지 않고, 메일이 실제로 발송됐는지 확인한 뒤 필요한 단계만 이어갈 수 있습니다.
단계별 상태표에 남길 네 가지
상태표는 개발 로그를 그대로 보여주는 화면이 아닙니다. 운영자가 한 건의 업무가 어디까지 진행됐고 무엇을 해야 하는지 판단할 수 있어야 합니다.
- 요청 식별자: workflow ID, 원 업무번호, 고객·문서·주문처럼 중복을 구분할 업무 키
- 단계 상태: 대기, 처리 중, 성공, 실패, 상태 불명과 각 시도 시각·횟수
- 외부 결과: CRM 레코드 ID, 메일 메시지 ID, 결제 요청 ID, 파일 경로처럼 실제 반영을 확인할 참조값
- 다음 행동: 재시도, 보상 작업, 사람 확인, 종료 중 무엇을 할지와 담당자·기한
원문 전체, 비밀키, 개인정보를 상태표에 복사할 필요는 없습니다. 운영 판단에 필요한 최소 식별자와 안전하게 마스킹한 요약만 남기고, 상세 자료는 권한이 분리된 원 시스템에서 확인하도록 설계합니다.
보상 작업은 Ctrl+Z가 아닙니다
보상 작업은 과거를 지우는 기능이 아니라, 이미 일어난 결과를 업무적으로 유효한 상태로 되돌리는 새로운 작업입니다. 예약을 삭제하는 대신 취소 상태와 사유를 남기고, 결제 기록을 없애는 대신 환불 거래를 추가하는 방식이 대표적입니다.
Microsoft 문서도 보상 작업에는 업무 규칙이 필요하며 단순한 데이터 롤백과 다를 수 있다고 설명합니다. 보상 자체가 실패하거나 여러 번 호출될 수도 있으므로 원 작업과 마찬가지로 상태와 식별자를 가져야 합니다.
- CRM 값이 잘못 바뀜: 이전 값을 복원하거나 정정 이력을 추가하고, 변경 사유를 남깁니다.
- 예약이 먼저 생성됨: 예약 취소 API를 호출하고 취소 번호와 수수료 여부를 기록합니다.
- 파일이 잘못 이동됨: 원래 위치로 되돌리되 같은 이름의 파일이 있으면 덮어쓰지 않고 사람에게 넘깁니다.
- 메일이 이미 발송됨: ‘발송 취소’처럼 존재하지 않는 기능을 가정하지 말고 후속 실행을 멈춘 뒤 정정 안내 여부를 검토합니다.
외부 약속, 결제, 계약, 삭제처럼 되돌리기 어려운 행동은 보상 작업에 기대기보다 실행 전 사람 승인과 더 강한 입력 검증을 두는 편이 낫습니다.
부분 실패 복구 흐름을 설계하는 7단계
아래 일곱 가지를 한 장의 워크플로우 정의서에 함께 적으면 개발·현업·운영 담당자가 같은 기준으로 대응하기 쉬워집니다.
- 업무의 시작점과 최종 완료 조건을 정하고, 하나의 workflow ID가 어디까지 이어지는지 경계를 표시합니다.
- 각 단계가 만드는 부수 효과를 적고, 되돌릴 수 있음·조건부 보정·되돌릴 수 없음으로 나눕니다.
- 다음 단계 호출 전에 현재 단계의 성공 여부와 외부 결과 ID를 저장해 재시작 지점을 만듭니다.
- 네트워크 시간 초과처럼 재시도할 오류와 권한·형식 오류처럼 수정 전에는 반복하면 안 되는 오류를 구분합니다.
- 원 작업과 보상 작업 모두 중복 요청을 식별할 키를 사용하고, 같은 요청이 반복돼도 부수 효과가 늘지 않게 합니다.
- 보상 순서는 의존성의 역순을 기본으로 검토하되, 고객·보안·금전 영향이 큰 작업은 위험도에 따라 먼저 멈추거나 확인합니다.
- 자동 복구가 끝난 뒤 원 시스템과 결과를 대조하고, 상태 불명·보상 실패는 담당자와 응답기한이 있는 예외 큐로 보냅니다.
설계가 끝나면 단계마다 한 번씩 의도적으로 실패시켜 보세요. 2번 뒤 중단, 4번 응답 유실, 보상 API 실패처럼 위치를 바꿔 시험해야 ‘어디서든 이어서 복구된다’는 운영 근거가 생깁니다.
실무에서 자주 만나는 부분 실패 시나리오
고객 메일은 발송됐는데 CRM 업데이트가 실패한 경우
메일 발송 성공 후 응답으로 받은 메시지 ID를 저장했다면 메일 단계는 다시 실행하지 않습니다. CRM 오류만 분류해 해당 단계부터 이어갑니다.
- 메일 단계는 성공으로 고정하고 같은 workflow ID의 재실행에서 발송을 건너뜁니다.
- CRM이 일시 오류면 CRM 단계만 제한적으로 재시도하고, 권한 오류면 담당자 확인으로 전환합니다.
- CRM 기록이 고객 대응의 필수 근거라면 자동화를 완료 처리하지 않고 예외 큐에서 후속 정정을 확인합니다.
문서는 이동됐는데 메신저 알림이 실패한 경우
파일 이동과 알림은 영향이 다릅니다. 알림 하나가 실패했다고 정상 이동된 파일을 다시 복사하면 중복 파일이나 버전 충돌이 생길 수 있습니다.
- 파일 경로와 체크섬을 확인해 이동 단계의 실제 성공 여부를 먼저 확정합니다.
- 알림 단계만 재시도하고, 파일 이동 단계는 다시 실행하지 않습니다.
- 알림의 유효 시간이 지났다면 늦은 실시간 알림 대신 운영 요약이나 수동 확인으로 바꿉니다.
환불 요청은 접수됐는데 재고 복구가 실패한 경우
금전·재고처럼 서로 다른 원장을 건드리는 흐름은 상태 불명을 자동 재시도로 덮으면 위험합니다. 외부 결제사의 실제 거래 상태부터 확인해야 합니다.
- 결제 요청 ID로 환불 접수·완료·실패·상태 불명을 조회하고 같은 환불을 새로 만들지 않습니다.
- 주문을 임시 보류하고 재무·운영 담당자에게 현재 상태와 필요한 결정을 알립니다.
- 환불 취소 또는 재고 수동 복구처럼 업무 규칙에 맞는 보상 작업을 승인받아 실행하고 두 원장을 다시 대조합니다.
부분 실패 복구가 작동하지 않는 흔한 이유
외부 API의 성공 응답을 전체 업무 완료로 본다
한 단계의 200 응답은 해당 호출의 결과일 뿐 전체 업무가 끝났다는 뜻이 아닙니다. 외부 결과 ID와 다음 단계 상태를 함께 봐야 합니다.
모든 실패에 전체 롤백을 적용한다
메일, 결제, 외부 승인처럼 이미 일어난 일을 완전히 없앨 수 없는 단계가 있습니다. 단계별 보상 가능성을 구분하지 않으면 복구가 새로운 사고를 만듭니다.
보상 작업은 로그 없이 여러 번 실행해도 된다고 생각한다
보상 작업도 외부 시스템을 변경하는 업무입니다. 누가 왜 실행했는지, 어떤 원 요청과 연결되는지, 성공했는지 기록하고 중복 실행을 막아야 합니다.
AI Agent 부분 실패 복구 체크리스트
- 한 건의 업무를 식별하는 workflow ID와 원 업무 키가 있다.
- 각 단계에 대기·처리 중·성공·실패·상태 불명 상태가 있다.
- 외부 도구가 돌려준 레코드·메시지·거래·파일 식별자를 저장한다.
- 재시도 가능한 오류와 수정 전에는 재시도하면 안 되는 오류를 구분했다.
- 원 작업과 보상 작업에 중복 실행을 막는 요청 키가 있다.
- 각 부수 효과를 되돌릴 수 있음·조건부 보정·되돌릴 수 없음으로 분류했다.
- 보상 작업의 실행 권한, 담당자, 승인 기준, 응답기한이 정해져 있다.
- 자동 복구 불가와 상태 불명을 받을 사람 예외 큐와 알림이 있다.
- 복구 후 CRM·ERP·결제·문서함 같은 원 시스템과 결과를 대조한다.
- 각 단계 중단, 응답 유실, 보상 실패를 포함한 장애 주입 테스트를 해봤다.
자주 묻는 질문
Q. 보상 작업과 롤백은 같은가요?
완전히 같지 않습니다. 롤백은 이전 상태로 되돌린다는 의미가 강하지만, 보상 작업은 이미 일어난 업무 결과를 취소·정정·대체하는 새로운 거래일 수 있습니다. 발송된 메일처럼 되돌릴 수 없는 행동은 후속 중단과 정정 안내가 보상 방식이 됩니다.
Q. 데이터베이스 트랜잭션을 쓰면 부분 실패가 사라지나요?
한 데이터베이스 안의 변경에는 트랜잭션이 유용합니다. 하지만 메일, 결제사, SaaS, 문서함처럼 서로 다른 시스템을 한 번에 묶을 수 없는 경우가 많습니다. 가능한 범위는 원자적으로 처리하고, 시스템 사이에는 단계 상태와 보상 흐름을 둡니다.
Q. AI Agent가 보상 작업까지 자동으로 결정해도 될까요?
영향이 작고 규칙이 분명한 작업은 사전 승인된 범위에서 자동화할 수 있습니다. 금전, 고객 약속, 계약, 삭제, 보안처럼 되돌리기 어렵거나 상태가 애매한 작업은 AI의 자유 판단에 맡기지 말고 사람 승인과 원 시스템 확인을 거치는 편이 안전합니다.
HeyRatty로 끊기지 않는 자동화 운영을 설계하려면
HeyRatty는 여러 도구를 연결하는 것에서 자동화 설계를 끝내지 않습니다. 업무 단계를 나누고 workflow ID, 상태 기록, 재시도, 보상 작업, 예외 큐, 사후 대조까지 한 흐름으로 연결해 일부 단계가 실패해도 운영자가 안전하게 이어받을 수 있게 설계합니다.
처음부터 모든 자동화를 바꿀 필요는 없습니다. 고객 발송, CRM 수정, 결제·환불처럼 부분 실패의 영향이 큰 흐름 하나를 골라 ‘어디까지 성공했는가’와 ‘다음에 무엇을 할 것인가’를 먼저 표로 만들어보세요. 현재 업무 흐름이 복잡하다면 HeyRatty가 작은 파일럿 범위부터 함께 정리할 수 있습니다.
참고 및 이미지 출처
- Microsoft Azure Architecture Center — Compensating Transaction pattern
- AWS Prescriptive Guidance — Saga orchestration pattern
- Amazon Builders’ Library — Making retries safe with idempotent APIs
- NIST AI RMF Playbook — MANAGE
- 이미지 원본: Wikimedia Commons 「Valianttms-final-assembly.jpg」 · 저작자 AliceMaiAnh · CC BY-SA 4.0 · 원본 1920×1080 JPEG를 외부 URL로 직접 사용했습니다. 로컬 생성 이미지 0장.