많은 자동화 흐름은 처음에는 단순합니다. 양식을 받으면 작업을 만들고, 확인 메일을 보내고, 스프레드시트를 업데이트한 뒤 팀에 알립니다. 처음 성공했을 때는 시간이 절약된 것처럼 느껴집니다.

진짜 문제는 열 번째, 백 번째 실행 또는 어느 날 외부 서비스가 우연히 실패했을 때 나타납니다.

이미 고객 정보를 만들고 알림 메일도 보냈는데, 마지막 결제 상태 업데이트에서 실패했다고 가정해 보세요. 이때 “다시 실행하면 된다”고 말할 수 없습니다. 다시 실행하면 두 번째 메일이 나가거나, 두 번째 레코드가 만들어지거나, 반쯤 끝난 상태가 더 복잡해질 수 있습니다.

Cloudflare는 2026-06-25에 Workflows의 saga-style rollbacks를 소개했습니다. Workflows는 여러 단계로 구성되고 일정 시간 지속될 수 있는 애플리케이션 흐름을 실행하는 Cloudflare의 기능입니다. saga-style rollback은 각 step.do()에 대응하는 보상 동작을 붙일 수 있게 합니다. 쉽게 말하면, “이 단계가 무엇을 해야 하는지”만 쓰지 말고, “뒤 단계가 실패하면 이 단계의 영향은 어떻게 수습할지”도 써 두라는 뜻입니다.

이 글에서 배워야 할 것은 Cloudflare 사용법이 아닙니다. 가져가야 할 핵심은 하나입니다. 다단계 자동화는 재시도할 수 있다고 안전한 것이 아니라, 실패 후 어떻게 수습할지도 알아야 합니다.

먼저 재시도와 복구를 구분하세요

“재시도”는 같은 일을 다시 하는 것입니다. 예를 들어 API가 잠시 연결되지 않으면 몇 초 뒤 다시 보내는 식입니다.

“롤백/복구”는 이미 생긴 영향을 처리하는 것입니다. 예약을 취소하고, 주문을 사람의 확인 대상으로 표시하고, 정정 알림을 보내거나, 데이터 상태를 다시 처리 가능한 상태로 바꾸는 일이 여기에 속합니다.

두 가지 모두 오류 처리처럼 들리지만 쓰이는 상황은 다릅니다.

어떤 단계가 데이터를 읽기만 한다면 재시도는 대체로 합리적입니다. 잠깐의 네트워크 불안정, 바쁜 데이터베이스, 외부 서비스의 일시적인 시간 초과는 재시도로 해결될 수 있습니다.

하지만 어떤 단계가 실제로 “무언가를 변경”한다면 재시도는 새 문제를 만들 수 있습니다. 예를 들면 다음과 같습니다.

  • 고객에게 이메일이나 문자 메시지를 보냅니다.
  • 계정, 티켓, 주문, 청구서를 만듭니다.
  • 결제, 환불, 포인트 지급, 재고 조정을 합니다.
  • CRM, 즉 고객 정보와 상호작용 기록을 바꿉니다.
  • 외부 도구를 호출해 다른 시스템이 일을 시작하게 합니다.

이런 단계가 한 번 일어나면 세상은 이미 바뀐 것입니다. 이후 단계가 실패했을 때 필요한 것은 단순한 재실행이 아니라 수습 계획입니다.

보상 동작은 실패 후의 다음 단계이지, 마법 같은 되돌리기가 아닙니다

분산 시스템에서 saga는 여러 로컬 트랜잭션을 다룰 때 자주 사용됩니다. Microservices.io는 중간 트랜잭션이 실패하면 시스템이 보상 트랜잭션을 실행해 이전 영향들을 명시적으로 되돌려야 한다고 설명합니다. Microsoft Azure의 compensating transaction pattern도 많은 복구는 단순히 데이터를 되돌리는 것이 아니라 예약 취소나 부분 환불처럼 업무 규칙에 따라 처리해야 한다고 말합니다.

일반적인 업무 흐름에서도 “보상 동작”을 실패 후 책임 있게 이어지는 다음 단계로 생각할 수 있습니다.

그것이 항상 완전한 복원을 뜻하지는 않습니다. 많은 일은 실제로 되돌릴 수 없습니다. 메일은 이미 발송됐고, 고객은 잘못된 알림을 봤으며, 외부 서비스에는 깔끔하게 삭제할 수 없는 레코드가 생겼을 수 있습니다.

그래서 보상 동작은 보통 이런 형태입니다.

  • 취소: 예약, 작업, 주문, 임시 데이터를 취소합니다.
  • 표시: 상태를 “사람 확인 필요”로 바꿔 뒤 자동화가 계속되지 않게 합니다.
  • 정정: 정정 알림을 보내고, 설명을 추가하거나, 잘못된 데이터를 수정합니다.
  • 격리: 의심스러운 데이터를 공식 보고서나 고객 흐름에 넣지 않습니다.
  • 인계: 완료된 단계, 실패 지점, 선택 가능한 처리 방안을 담당자에게 전달합니다.

여기서 “담당자”는 문서에 이름 하나 적는 것으로 끝나지 않습니다. 누가 알림을 보는지, 누가 계속 진행할지 판단하는지, 누가 고객이나 내부 영향을 처리하는지가 실제로 정해져 있어야 합니다.

광고

표 하나로 각 단계가 자동으로 실행돼도 되는지 확인하세요

자동화를 작성하기 전에 흐름을 단계로 나누고, 각 단계가 실패했을 때 어떻게 수습할지 물어보세요.

흐름 단계실패 시 가장 위험한 점미리 써 둘 보상 동작
내부 작업 만들기작업이 반쯤 만들어졌는데 팀이 없다고 생각해 수동으로 또 만듦외부 ID를 기록합니다. 재시도 전 이미 존재하는지 확인하고, 없을 때만 새 작업을 만듭니다
고객 알림 보내기뒤 데이터가 실패했는데 고객은 이미 불완전한 메시지를 받음후속 자동 발송을 중단합니다. 사람 확인으로 표시합니다. 필요하면 정정 알림을 보냅니다
결제, 포인트, 재고 업데이트돈이나 수량이 잘못 바뀌고, 재실행이 다시 바꿈영향이 큰 단계는 자동 재실행하지 않습니다. 기록을 잠그고 담당자가 차이를 확인하게 합니다
외부 AI나 에이전트 호출AI가 이미 파일을 수정하고 PR을 열거나 메시지를 보내거나 다른 도구를 트리거함모든 동작 기록을 남기게 합니다. 실패 후에는 검토 대기 상태에서 멈추고 다음 도구가 이어서 실행되지 않게 합니다

이 표는 출발점일 뿐입니다. 목적은 흐름을 복잡하게 만드는 것이 아니라 “3단계가 실패하면 1단계와 2단계가 남긴 흔적을 어떻게 처리할까?”를 먼저 답하게 하는 것입니다.

또 하나 기억할 일반 원칙이 있습니다. 실제로 “무언가를 하는” 단계는 가능한 한 idempotent하게 설계해야 합니다. 이 단어는 “같은 일을 여러 번 해도 부작용이 여러 개 생기지 않는다”로 이해하면 됩니다. 예를 들어 같은 주문 번호로 작업을 만들 때 두 번째 호출은 새 작업을 또 만드는 것이 아니라 이미 있는 작업을 반환해야 합니다. Cloudflare를 포함한 대부분의 워크플로 플랫폼 문서도 이 원칙을 강조합니다.

당신의 흐름이 이렇게 설계될 수 없다면, 재시도만을 유일한 보호 장치로 삼아서는 안 됩니다.

어떤 흐름부터 복구 단계를 써야 할까요?

모든 자동화가 완전한 saga, 즉 각 단계마다 실패 후 수습 동작을 미리 써 두는 설계를 필요로 하지는 않습니다. 파일 이름 정리, 고정 형식으로 데이터 변환, 공개 정보 요약 같은 일은 보통 위험이 낮습니다.

하지만 아래 흐름은 일상 업무에 넣기 전에 복구 단계를 먼저 써야 합니다.

  1. 외부로 메시지를 보내는 흐름: 이메일, 문자, 소셜 게시물, 고객지원 답변, 고객 알림.
  2. 공식 데이터를 바꾸는 흐름: CRM, 주문, 결제, 재고, 회원 상태, 권한.
  3. 여러 시스템을 잇는 흐름: 양식, 스프레드시트, 프로젝트 관리 도구, 재무 시스템, 외부 API.
  4. AI가 여러 단계를 연속 실행하는 흐름: 데이터를 읽고, 파일을 수정하고, 도구를 호출하고, PR을 열거나 사람에게 알립니다. 여기서 AI agent는 한 문장 답변만 하는 챗봇이 아니라 여러 행동을 이어서 수행하는 AI를 뜻합니다.

이 흐름들의 공통점은 실패가 한 화면에만 머물지 않는다는 점입니다. 외부 흔적, 잘못된 데이터, 뒤따르는 연쇄 동작이 남을 수 있습니다.

아직 수습 방식을 설명할 수 없다면, 흐름은 “초안 만들기”나 “검토 작업 만들기”에서 멈추고 공식 동작까지 자동으로 진행하지 않는 편이 낫습니다.

작은 팀이 먼저 할 수 있는 세 가지 수정

첫째, 각 자동화 흐름에 “이미 무엇을 했는지” 기록을 추가하세요. 최소한 흐름 ID, 각 단계의 시작·완료 시간, 외부 시스템이 돌려준 ID, 오류 메시지, 다음 상태를 남기세요. 기록이 없으면 복구는 추측이 됩니다.

둘째, 영향이 큰 단계는 사람의 승인 관문 뒤에 두세요. 고객에게 보내거나, 돈을 바꾸거나, 권한을 바꾸거나, 공식 데이터를 수정하는 동작은 AI나 자동화 스크립트 혼자 결정하게 두지 마세요.

셋째, 영향이 큰 단계마다 보상 규칙 한 문장을 쓰세요. 예를 들어 “작업 생성 후 메일 발송이 실패하면 작업을 다시 만들지 않고 담당자에게 재발송을 알린다”처럼요. 이 작은 문장은 “오류가 나면 그때 생각하자”를 “오류에도 다음 단계가 있다”로 바꿉니다.

이 미니 강의의 결론

자동화의 성숙도는 평소 얼마나 매끄럽게 돌아가느냐가 아니라, 실패했을 때 이해하고 멈추고 수습할 수 있느냐로 판단됩니다.

Cloudflare Workflows의 saga-style rollbacks는 이 생각을 다시 떠올리게 하는 하나의 새로운 계기일 뿐입니다. Cloudflare, GitHub Actions, Zapier, n8n, 내부 스크립트, 여러 도구를 연결하는 AI agent 중 무엇을 쓰든 질문은 같습니다.

  • 어떤 단계는 재시도만으로 충분한가요?
  • 어떤 단계는 한 번 실행되면 보상 동작이 필요한가요?
  • 어떤 실패는 자동 처리하지 말고 담당자 확인으로 멈춰야 하나요?
  • 복구할 때 이미 무엇이 일어났는지 보려면 어떤 기록이 필요한가요?

이 답을 먼저 써 두면 자동화는 빠르지만 고장 나면 아무도 만지기 싫어하는 블랙박스가 아닙니다. 앞으로 나아가는 방법뿐 아니라 멈춰서 수습하는 방법도 아는 업무 흐름이 됩니다.

생활 4컷 만화

4컷 만화: 자동화 흐름이 먼저 순조롭게 실행되고, 중간 단계가 실패한 뒤, 팀이 미리 준비한 보상 동작을 사용하고, 마지막에 담당자가 안전하게 인계받는다.

  1. 다단계 자동화 흐름이 순조롭게 진행되며 각 단계가 스스로 완료될 수 있어 보입니다.
  2. 중간 단계가 실패하고, 팀은 전체 흐름을 즉시 다시 실행하지 않고 먼저 멈춥니다.
  3. 팀은 미리 써 둔 보상 동작으로 앞 단계가 남긴 영향을 정리합니다.
  4. 담당자가 기록을 확인하고, 무엇을 재시도할 수 있으며 무엇을 수동 처리해야 하는지 판단합니다.

AI 정리 카드

이 글의 상황에 맞춰 AI에게 정리하게 하기

자신의 AI 채팅 도구에 붙여 넣으면 이 미니 클래스를 개인용 체크리스트로 바꿀 수 있습니다. BMC는 사용자가 AI에 붙여 넣은 내용을 볼 수 없습니다.

광고

Share

이 미니 클래스 공유

이 글이 업무 병목을 푸는 데 도움이 되었다면, AI를 어떻게 쓸지 고민하는 사람에게도 공유해 주세요.

참고 자료