고객이 양식을 제출하면 자동화가 고객 레코드를 만들고, 지원팀의 작업을 열고, 확인 메일을 보냅니다. 마지막 단계인 결제 또는 CRM 상태 업데이트가 시간 초과로 실패합니다.
대시보드에는 실행 실패가 표시되지만, 현실의 세 작업은 이미 완료되었을 수 있습니다. 워크플로를 처음부터 실행하면 고객이 중복 생성되고, 두 번째 작업이 배정되며, 같은 메일이 다시 발송될 수 있습니다. 따라서 긴급한 질문은 단순히 실행을 다시 시작하는 방법이 아닙니다. 무엇이 일어났는지 확인하고, 반복하면 안 되는 영향을 차단하며, 다음 시도를 누가 승인할 수 있는지 결정해야 합니다.
Cloudflare는 2026년 6월 25일 장시간 실행되는 다단계 애플리케이션 흐름을 위한 플랫폼인 Cloudflare Workflows에 saga-style rollbacks를 도입하며 이 문제를 부각했습니다. step.do()로 수행한 작업에 이후 단계가 실패할 때 실행되는 보상 로직을 연결할 수 있습니다. 이 구현은 새롭지만 운영 원칙은 한 플랫폼에만 적용되지 않습니다. 결과가 중대한 각 워크플로 단계에는 관찰 가능한 증거, 안전한 재시도 또는 보상 방법, 중단 조건, 복구 판단을 책임질 사람이 필요합니다.
재시도는 중단을 해결하지만 그 여파까지 해결하지는 않습니다
외부 효과를 남기지 않은 작업에는 재시도가 유용합니다. 잠깐의 네트워크 문제로 읽기 전용 API 요청이 실패했다면 다시 시도해도 괜찮을 수 있습니다. 이 요청은 메시지를 보내거나, 객체를 만들거나, 잔액이나 공식 기록을 변경하지 않았습니다.
워크플로가 외부에서 작업을 수행했다면 판단이 달라집니다. 성공 응답을 받지 못했더라도 계정, 주문, 청구서, 티켓 또는 내부 작업이 존재할 수 있습니다. 고객이 이미 메일이나 SMS를 읽었을 수 있고, 결제, 환불, 포인트, 재고, CRM 데이터 또는 권한이 변경되었을 수 있습니다. AI 에이전트가 파일을 편집하고, 풀 리퀘스트를 열거나, 다른 도구에 계속 작업하라고 지시했을 수도 있습니다.
무작정 다시 실행하면 작업이 전혀 일어나지 않은 경우와, 성공했지만 확인 응답만 돌아오지 않은 경우를 구분할 수 없습니다. 이 때문에 복구 시도가 주문 중복, 반복 알림, 충돌하는 기록 또는 두 번째 금전 변경을 일으킵니다.
Saga 기반 복구는 뒤 단계의 트랜잭션이 실패했을 때 완료된 작업에 보상 동작을 부여합니다. 보상이 항상 완벽한 되돌리기는 아닙니다. 예전 데이터베이스 값을 복원하면 동시에 이루어진 정당한 작업을 덮어쓸 수 있으며, 고객에게 전달된 메시지를 읽지 않은 상태로 돌릴 수는 없습니다. 적절한 대응은 주문 취소, 레코드 표시, 정정, 불확실한 결과 격리 또는 담당자 인계일 수 있습니다.
각 단계에서 팀이 가장 피하고 싶은 실패부터 살펴봅니다.
| 단계와 외부 효과 | 중단 후 발생할 수 있는 문제 | 사전에 정의할 복구 계약 |
|---|---|---|
| 상태를 변경하지 않고 읽거나 검증함 | 일시적인 서비스 오류로 완료하지 못함 | 명시된 횟수까지만 재시도한 뒤 중단하고 오류를 기록함 |
| 계정, 작업, 티켓, 주문 또는 청구서를 생성함 | 객체는 존재하지만 응답이 유실되어 워크플로가 다시 생성함 | 외부 ID를 저장하고 새 생성 요청 전에 기존 객체를 검색함 |
| 메일, SMS 또는 고객 알림을 보냄 | 이후 실패로 같은 메시지가 다시 발송됨 | 추가 발송을 차단하고 검토 상태로 전환하며 필요한 경우 정정을 준비함 |
| 금전, 포인트, 재고, CRM 데이터 또는 권한을 변경함 | 재시도로 변경이 중복되거나 공식 데이터가 불일치함 | 영향을 받은 레코드를 잠그고 소유자가 증거를 대조할 때까지 다시 변경하지 않음 |
| AI 에이전트 또는 외부 도구를 호출함 | 도구는 작업을 끝냈지만 확인이 유실되고 후속 작업이 계속됨 | 작업 로그를 보존하고, 불확실한 결과를 격리하며, 모든 종속 작업을 사람의 검토까지 보류함 |
이 계약의 목적은 모든 영향을 지울 수 있다고 보장하는 데 있지 않습니다. 실패한 실행이 임의의 전체 재실행이 아니라 알려진 복구 상태로 들어가게 하는 데 있습니다.
증거를 바탕으로 복구를 결정하세요
같은 요청을 반복해도 첫 성공 이후 추가 효과가 발생하지 않는 단계는 멱등성이 있어 복구하기 쉽습니다. 예를 들어 주문 번호에 이미 이행 작업이 연결되어 있다면 같은 주문 번호를 다시 제출해도 두 번째 작업을 만들지 않고 기존 작업을 반환해야 합니다. 중단 후 영구 실행이 단계를 반복할 수 있으므로 Cloudflare의 워크플로 지침도 이 속성을 권장합니다.
많은 외부 서비스는 이런 보장을 자동으로 제공하지 않습니다. 이때 워크플로는 실행을 재구성할 만큼 충분한 증거를 보관해야 합니다. 실행 ID, 각 단계의 시작 및 완료 상태, 외부 객체 ID, 관련 오류 세부 정보, 현재 복구 상태가 필요합니다. 빨간색 ‘실패’ 표시 하나만으로는 운영 담당자가 금전이 이동했는지, 고객에게 연락했는지, 다른 시스템이 명령을 수락했는지 알 수 없습니다.
증거에도 소유자가 필요합니다. 알림은 문서에 이름만 적힌 사람이 아니라 다음 작업을 승인, 정정 또는 중단할 권한과 맥락을 가진 사람에게 전달되어야 합니다. AI 에이전트가 코드를 편집하거나 개발 도구를 호출한다면 AI 에이전트가 코드를 쓰게 하기 전에 작업에 체크포인트를 두세요에서 다음 중대한 작업 전에 검토를 두어 변경 사항을 확인하는 방법을 살펴볼 수 있습니다.
권한 설계도 같은 경계를 강제해야 합니다. 초안을 수정할 수 있다고 해서 고객에게 메일을 보내거나, 결제를 변경하거나, 접근 권한을 수정할 수 있는 것은 아닙니다. 상시 작동하는 AI 도우미에는 권한 경계가 필요합니다는 사고가 난 뒤 추론하는 대신 도구 권한과 인계 조건을 미리 명시해야 하는 이유를 설명합니다.
이 기준은 Cloudflare Workflows, GitHub Actions, Zapier, n8n, 사내 스크립트, 외부 도구에 연결된 AI 에이전트에 모두 적용됩니다. 어떤 영향이 발생했는지 보여 주고, 적절한 보상을 선택하며, 추가 작업을 누가 승인할지 확인할 수 없다면 무인 변경을 수행할 준비가 되지 않은 것입니다. 초안, 보류 또는 검토 작업 상태에서 중단해야 합니다.
현재 사용 중인 자동화 하나를 골라 상태를 변경하는 단계 중 결과가 가장 중대한 단계를 찾으세요. 그 단계가 실행되었는지 증명하는 증거, 그 영향을 차단하거나 바로잡을 작업, 다음 시도를 승인해야 하는 사람이라는 세 가지를 기록하세요. 나중에 모든 오류를 처리하겠다고 약속하는 것보다 오늘 검증 가능한 복구 경로 하나를 정의하는 편이 더 안전합니다.
AI 정리 카드
현재 환경에서 이미 접근할 수 있는 자동화 정의, 저장소 파일, 프로젝트 설정, 실행 로그 또는 운영 기록부터 시작하세요. 먼저 읽기 전용으로 조사하세요. 워크플로를 시작하거나 재시도하고, 파일을 편집하고, 메시지를 보내고, 권한을 바꾸거나 외부 기록을 변경하지 마세요.
객체를 생성하고, 고객에게 연락하고, 금전이나 재고를 변경하고, 공식 데이터를 업데이트하거나 외부 에이전트 또는 도구를 호출할 수 있는 다단계 흐름 하나를 선택하세요. 가장 중대한 복구 취약점을 직접 찾으세요. 파일 경로, 설정 키, 실행 ID, 로그 항목 또는 외부 레코드 식별자처럼 판단의 근거가 되는 직접적인 증거를 인용하고, 관찰한 사실과 추론을 명확하게 구분하세요.
영향을 받은 단계에서 이미 무엇이 일어났을 수 있는지 설명하세요. 반복 요청이 명백히 멱등한지 판단하고, 그렇지 않다면 취소, 검토 표시, 정정, 격리 또는 인계 중 적절한 보상 범주를 선택하세요. 복구에 필요한 증거, 자동 실행을 중단할 조건, 추가 작업을 승인해야 하는 사람의 역할도 확인하세요. 뒷받침할 수 없는 필드에는 ‘확인 필요’라고 쓰세요. 필수 자료에 접근할 수 없다면 입력 자료 묶음을 준비해 달라고 요구하지 말고, 누락된 위치나 접근 권한에 관해 범위를 좁힌 질문을 하나만 하세요.
정확히 하나의 결론으로 마무리하세요. ‘진행’, ‘제한적 시험’ 또는 ‘중단’ 중 하나를 선택하세요. 증거에 기반한 짧은 이유와 즉시 사용할 수 있으며 읽기 전용이고 운영 환경을 변경하지 않는 다음 단계 하나를 제시하세요. 고객 연락, 금전이나 재고 변경, 권한, 공식 기록 및 외부 도구 작업은 반드시 사람이 확인해야 합니다. 명시적 승인과 검증된 복구 경로 없이는 실행하거나 재시도하지 마세요.
생활 4컷 만화

- 자동화가 고객 정보 생성과 알림 발송을 차례로 처리하며 문제없이 끝날 것처럼 보입니다.
- 뒤쪽 단계에서 오류가 발생하자 팀은 처음부터 다시 실행하지 않고 다음 작업을 멈춥니다.
- 실행 기록과 외부 ID를 확인한 팀이 미리 정한 보상 동작으로 앞 단계의 영향을 수습합니다.
- 담당자가 남은 위험을 검토하고 자동 재시도, 보상 후 재개, 수동 처리 가운데 다음 조치를 결정합니다.
참고 자료
- Cloudflare Blog: How we built saga rollbacks for Cloudflare Workflows — https://blog.cloudflare.com/rollbacks-for-workflows/
- Cloudflare Docs: Rules of Workflows — https://developers.cloudflare.com/workflows/build/rules-of-workflows/
- Microservices.io: Pattern: Saga — https://microservices.io/patterns/data/saga.html
- Microsoft Learn: Compensating Transaction pattern — https://learn.microsoft.com/en-us/azure/architecture/patterns/compensating-transaction



