자동화가 반쯤 끝난 뒤 멈췄다면, 다시 돌려도 될까요?

Larry

신청서 한 건이 들어오면 고객 계정을 만들고, 안내 메일을 보낸 뒤, 결제 정보와 CRM 상태까지 갱신하는 자동화가 있다고 가정해 보겠습니다. 계정 생성과 메일 발송은 끝났지만 마지막 갱신 단계에서 오류가 났습니다. 이때 처음부터 다시 실행하면 문제가 해결될까요?

오히려 새 계정이나 주문이 하나 더 만들어지고, 고객에게 같은 안내가 두 번 갈 수 있습니다. 결제 금액, 포인트, 재고, 권한처럼 실제 업무 상태를 바꾸는 단계였다면 피해는 더 커집니다. 자동화 화면에는 단순히 ‘실패’라고 표시돼도 현실에서는 이미 여러 변화가 일어난 뒤일 수 있습니다.

Cloudflare는 2026년 6월 25일 Workflows에 saga-style rollbacks를 도입했다고 발표했습니다. Cloudflare Workflows는 여러 작업을 순서대로 수행하면서 단계별 상태를 유지하는 기능이며, 새 방식은 step.do()로 수행한 작업에 이후 단계가 실패했을 때 실행할 보상 로직을 연결합니다.

이 기능을 사용하지 않는 팀에도 판단 기준은 같습니다. 다단계 자동화의 안전성은 다시 실행할 수 있느냐가 아니라, 이미 일어난 영향을 증거로 확인하고 수습할 수 있느냐에 달려 있습니다. 운영에 투입할 흐름이라면 영향이 큰 단계마다 관찰 가능한 기록, 중복 방지 조건이나 보상 동작, 멈춰야 할 조건, 최종 결정을 맡을 사람이 필요합니다.

오류를 재시도하기 전에 이미 일어난 일을 확인하세요

재시도는 같은 작업을 한 번 더 수행하는 대응입니다. 데이터를 읽는 도중 연결이 잠깐 끊겼거나, 외부 API가 일시적으로 응답하지 않은 경우에는 효과가 있을 수 있습니다. 그러나 앞선 단계가 외부 상태를 바꿨다면 재시도 자체가 새로운 사고 원인이 됩니다.

예를 들어 고객 레코드, 작업, 주문, 청구서를 만들었거나 이메일·문자·고객 알림을 보냈다면 그 결과는 자동화 실행 바깥에 남습니다. 결제, 환불, 포인트, 재고, CRM 상태, 회원 권한을 변경한 경우도 마찬가지입니다. AI 에이전트가 파일을 고치고 메시지를 보내거나 다른 외부 도구를 호출했다면, 실행 프로세스가 멈춘 뒤에도 그 영향은 사라지지 않습니다.

분산 시스템에서 saga는 여러 로컬 트랜잭션을 순서대로 진행하고, 뒤쪽 트랜잭션이 실패하면 앞서 완료된 작업에 대응하는 보상 트랜잭션을 수행하는 방식입니다. 여기서 보상은 시간을 되돌리는 기능이 아닙니다. 이미 읽은 고객 메시지를 없던 일로 만들 수는 없고, 다른 시스템에서 처리된 기록을 무조건 이전 상태로 덮어쓰는 것도 안전하지 않습니다. Microsoft의 Compensating Transaction 패턴 역시 보상 절차는 동시 작업과 업무 규칙을 고려해야 하므로 애플리케이션별로 달라진다고 설명합니다.

따라서 실패를 발견하면 다음 호출부터 먼저 차단하고, 현재 기록을 보존해야 합니다. 그다음 어떤 단계가 실제로 끝났는지 확인하고, 취소·정정·격리·상태 표시·담당자 인계 가운데 적절한 수습 방법을 선택합니다. 실행 여부를 확인하지 못한 상태에서 전체 흐름부터 다시 돌려서는 안 됩니다.

영향이 큰 단계마다 복구 계약을 붙이세요

자동화 설계 문서에는 성공 경로뿐 아니라 실패 뒤의 처리 약속도 있어야 합니다. 아래 표는 각 단계에 어떤 내용을 미리 정해야 하는지 보여 줍니다.

단계가 남기는 외부 영향	재실행할 때 생길 수 있는 문제	실행 전에 정할 복구 계약
고객 레코드·작업·주문·청구서 생성	같은 업무가 중복 생성됨	업무 ID와 외부 시스템이 반환한 ID를 기록하고, 기존 항목이 있으면 새로 만들지 않음
이메일·문자·고객 알림 발송	고객이 미완료 작업을 완료된 것으로 오해함	후속 발송을 차단하고 검토 상태로 전환한 뒤, 필요하면 정정 알림을 보냄
결제·환불·포인트·재고 변경	금액이나 수량이 두 번 반영됨	자동 재실행을 금지하고 거래 기록을 보존한 채 담당자에게 차이를 넘김
CRM·회원 상태·권한 갱신	일부 시스템에만 새 상태가 남음	변경 대상을 표시하고 흐름을 중단한 뒤 승인된 절차로 상태를 맞춤
AI 에이전트·외부 도구 호출	파일 수정, 메시지 발송, 연속 도구 실행이 계속됨	다음 호출을 막고 실행 기록과 결과물을 보존한 뒤 사람이 영향 범위를 확인함

첫 번째 조건은 관찰 가능성입니다. 흐름 ID, 단계 이름, 시작·완료 시각, 업무 ID, 외부 ID, 오류 내용, 마지막으로 확인된 상태가 남아 있어야 합니다. 이런 기록이 없으면 담당자는 복구 여부를 증거가 아니라 추측으로 판단하게 됩니다.

두 번째는 멱등성입니다. 멱등성이란 같은 요청을 여러 번 수행해도 첫 실행 이후 추가 부작용이 생기지 않는 성질입니다. 같은 주문 번호로 작업을 생성하라는 요청이 반복됐을 때 새 작업을 계속 만드는 대신 기존 작업을 반환하는 방식이 한 예입니다. Cloudflare Workflows 문서도 단계가 여러 번 재시도될 수 있으므로 가능하면 멱등성 있게 설계해야 한다고 안내합니다.

하지만 멱등성만으로는 충분하지 않습니다. 고객이 이미 본 잘못된 안내, 외부 시스템에서 시작된 작업, 변경된 권한처럼 취소하기 어려운 영향은 여전히 남습니다. 이런 단계에는 실패 뒤 실행할 보상 동작과 더 이상 자동으로 진행하지 않을 중단 조건이 함께 필요합니다.

금전, 개인정보, 권한, 공식 데이터, 고객 발송을 건드리는 복구는 자동화가 단독으로 결정하지 않게 해야 합니다. AI가 코드를 수정하거나 도구를 연이어 실행하는 흐름이라면 작업 안에 사람의 확인 지점을 넣는 방법을 참고해 승인 전 조사와 승인 후 실행을 분리할 수 있습니다. 상시 실행되는 에이전트에는 허용된 권한과 중단 경계를 먼저 정하는 원칙을 적용해 어떤 상황에서 담당자에게 넘길지도 명확히 해야 합니다.

GitHub Actions, Zapier, n8n, 사내 스크립트 가운데 어떤 도구를 사용하더라도 운영 전에는 네 가지 질문에 답할 수 있어야 합니다. 완료된 단계를 기록으로 확인할 수 있는가? 같은 요청이 반복돼도 중복 영향을 막을 수 있는가? 실패 뒤 수행할 보상 동작과 중단 조건이 있는가? 다시 진행해도 되는지 결정할 담당자가 정해져 있는가?

하나라도 답할 수 없다면 공식 데이터를 변경하거나 외부 메시지를 보내는 단계까지 자동화하지 않는 편이 안전합니다. 먼저 초안이나 검토 요청만 만들도록 범위를 줄이면 실제 영향을 남기기 전에 사람이 판단할 수 있습니다.

오늘은 운영 중인 자동화 하나만 골라 가장 영향이 큰 단계 옆에 복구 계약 한 문장을 적어 보세요. “결제 반영 뒤 CRM 갱신이 실패하면 추가 결제를 요청하지 않는다. 다음 호출을 중단하고 거래 ID와 오류 기록을 보존한 뒤 담당자의 승인을 기다린다”처럼 증거, 금지할 행동, 인계 대상을 한 문장에 담으면 됩니다.

AI 정리 카드

현재 접근할 수 있는 작업 공간이나 저장소, 프로젝트 설정, 실행 기록부터 읽기 전용으로 조사해 다단계 자동화 하나를 찾아 줘. 파일·설정·운영 데이터를 변경하지 말고 흐름 정의와 로그, 외부 호출 기록, 업무 ID를 확인한 다음, 외부 상태를 바꾸는 단계 중 가장 구체적인 문제 또는 개선 기회 하나를 직접 선택해 줘. 선택 근거로 파일 경로, 설정 키, 로그 문구, 실행 시각, 외부 ID 가운데 실제로 발견한 증거를 인용하고, 관찰된 사실과 추론을 구분해 표시해. 값이 없거나 검증할 수 없으면 ‘확인 필요’라고 적어 줘. 필수 위치나 권한에 접근할 수 없다면 자료를 따로 정리해 달라고 요구하지 말고, 접근에 필요한 위치 또는 권한을 묻는 질문을 한 가지만 해 줘.

선택한 단계에 대해 이미 발생할 수 있는 영향, 재실행 중복을 막을 업무 ID나 멱등성 조건, 적합한 보상 동작, 필요한 기록, 자동 처리를 멈출 조건, 결정을 맡을 사람을 설명해 줘. 결론은 ‘자동 재시도 가능’, ‘보상 후 재개’, ‘사람 확인에서 중단’ 중 하나만 사용해. 이어서 오늘 적용할 수 있는 가장 작은 조치 한 가지를 제안해 줘. 금전, 개인정보, 권한, 고객 발송, 운영 데이터 변경 또는 외부 도구 실행이 관련되면 실제 변경·재실행·복구를 수행하지 말고, 현재 상태와 증거를 보존한 채 담당자의 명시적 승인 단계에서 멈춰.