Cloudflare Workflows 사가 롤백: 자동화 실패를 되돌리는 운영 설계

Cloudflare는 2026년 6월 25일 Workflows에 사가(saga) 롤백을 추가했다고 발표했다. 여러 외부 시스템을 잇는 자동화가 중간에 실패했을 때, 이미 끝난 단계를 단순히 없던 일로 만들 수는 없다. 재고 예약을 해제하거나 결제를 환불하는 별도 보상 작업이 필요하다. 새 기능은 각 step.do() 옆에 rollback을 선언하고, 워크플로가 최종 실패할 때 등록된 보상을 실행하도록 한다. 작은 팀이 주목할 점은 코드가 짧아진다는 사실보다 복구 규칙이 정상 처리와 같은 위치에서 검토 가능해졌다는 것이다.

6월 25일 발표에서 확인된 동작

공식 발표와 문서에 따르면 롤백 핸들러는 워크플로가 최종 실패할 때 역순으로 실행된다. 기준은 완료 순서가 아니라 step-start의 역순이다. 실패한 단계도 롤백을 등록했다면 보상 대상이 될 수 있으며, 외부 시스템에 일부 반영된 뒤 결과를 저장하지 못한 경우 output이 undefined일 수 있다.

롤백에는 rollbackConfig로 재시도, 지연, 백오프, 타임아웃을 따로 지정할 수 있다. 보상 실행에는 생명주기 이벤트와 로그가 남고, 원래 실패와 롤백 결과는 분리된다. 롤백 중 엔진이 재시작돼도 저장된 단계 이력과 재생을 이용해 필요한 핸들러를 복구하는 설계가 설명돼 있다.

확인된 사실: 롤백은 잡힌 오류마다 즉시 시작되는 것이 아니라 워크플로 자체가 실패 상태로 끝나려 할 때 시작한다.

POEMORA 해석: 업무 담당자가 기대하는 “한 단계 실패하면 모두 취소”와 실제 실행 조건이 다를 수 있으므로, 실패 분류와 종료 조건을 운영 문서에 적어야 한다.

재시도와 롤백을 같은 것으로 보지 말아야 한다

재시도는 같은 의도를 다시 수행하는 것이고, 롤백은 이미 발생한 효과를 반대 의미의 새 작업으로 보상하는 것이다. 네트워크 시간 초과에는 재시도가 맞을 수 있지만, 결제 거절처럼 영구 오류에는 반복 호출이 도움이 되지 않는다. Cloudflare 문서는 NonRetryableError로 즉시 실패시키는 방법과 단계별 재시도 설정을 제공한다.

중요한 전제는 멱등성이다. 정상 단계와 보상 단계 모두 같은 요청이 여러 번 도착해도 효과가 중복되지 않아야 한다. 결제사나 주문 시스템이 멱등성 키를 지원하면 워크플로 인스턴스와 단계 이름을 결합한 키를 설계할 수 있다. 지원하지 않으면 자체 처리 원장과 상태 확인 API가 필요하다.

중소팀용 보상 설계 체크리스트

첫 도입에서는 모든 자동화를 사가로 바꾸기보다 돈, 재고, 권한, 고객 알림처럼 외부 효과가 남는 흐름부터 고른다.

1. 각 단계의 외부 효과와 성공 판정 기준을 한 줄로 적는다.
2. “삭제”가 아니라 업무적으로 반대가 되는 보상 명령을 정한다.
3. 정상·보상 요청에 각각 독립적인 멱등성 키를 붙인다.
4. 결과가 저장되지 않은 부분 성공을 가정해 output 부재 경로를 처리한다.
5. 보상 실패 시 남길 사건 번호, 담당자, 수동 복구 절차를 정한다.
6. 병렬 단계가 있다면 시작 순서의 역순이 업무 제약과 맞는지 테스트한다.

예를 들어 주문 자동화에서 쿠폰 복구, 재고 해제, 결제 환불의 법적·회계적 의미는 서로 다르다. 기술팀 혼자 “되돌리기”를 정의하면 장부와 고객 화면이 어긋날 수 있다. 운영 담당자와 함께 보상 완료의 증거를 정해야 한다.

롤백도 실패할 때의 운영 절차

공식 설명상 한 롤백 핸들러가 설정된 재시도를 모두 소진하면 결과는 실패로 기록되고, 남은 롤백 핸들러 실행도 중단될 수 있다. 따라서 “롤백 기능을 켰다”는 이유만으로 자동 복구가 보장된다고 표현해서는 안 된다.

운영 화면에는 최소한 원래 오류, 시작·완료된 단계, 실행된 보상, 실패한 보상, 외부 시스템의 최종 상태를 함께 보여줘야 한다. 경보에는 고객 식별정보나 결제정보 전체를 넣지 말고 사건 ID와 조회 링크만 포함한다. 담당자는 원래 작업을 재실행할지, 남은 보상만 수동 실행할지 선택할 수 있어야 한다.

분기별로 장애 주입 테스트도 권한다. 결제 성공 뒤 재고 단계 실패, 외부 API 성공 뒤 응답 유실, 롤백 API의 일시 장애를 각각 재현해 중복 효과가 없는지 확인한다. 테스트 환경에서만 검증하고 실제 고객 데이터에는 적용하지 않는다.

지금 도입할 팀과 기다릴 팀

외부 API 두 개 이상을 순차 호출하고, 부분 완료가 금전·재고·권한 상태를 남긴다면 도입 가치가 높다. 반대로 읽기 전용 수집이나 단순 알림처럼 재실행 비용이 낮은 흐름에는 일반 재시도와 실패 큐가 더 단순할 수 있다. Python Workflows의 롤백과 waitForEvent 롤백은 발표 시점의 향후 검토 항목이므로, 현재 제공 범위로 가정하면 안 된다.

POEMORA의 판단 기준은 기능 유무보다 수동 복구 시간을 줄이면서 감사 가능한 상태를 남기는가이다. POEMORA 자동화 서비스를 통해 현재 자동화의 부분 실패 지점을 그리면, 사가가 필요한 흐름과 단순 재시도로 충분한 흐름을 분리할 수 있다. 첫 적용은 환불 같은 고위험 전체 흐름보다 취소 가능한 내부 예약 과정에서 검증하는 편이 현실적이다.

자동 복구의 책임 경계를 명확히 하라

사가 롤백은 분산 시스템의 원자적 취소를 만들어 주는 마법이 아니다. 외부 시스템이 받아들일 수 있는 보상 명령을 팀이 정의하고, 중복 호출을 견디게 만들며, 보상마저 실패할 때 사람이 이어받는 구조다. 기능 도입 문서에는 자동 처리 범위, 수동 승인 조건, 최종 책임자를 함께 적어야 한다.

작은 팀일수록 코드보다 운영 합의가 먼저다. 세 개 단계만 있는 실제 흐름 하나를 골라 정상, 부분 성공, 영구 실패, 보상 실패 네 경로를 표로 만들고 테스트하라. 그 표를 설명할 수 있을 때 새 롤백 API가 비로소 복구 체계가 된다.