자동화가 시간 초과로 멈췄다면, 다시 실행해도 될까요?

실패한 마케팅 자동화를 복구할 때는 후속 업무나 쿠폰, 고객 메시지가 의도한 만큼만 생성되도록 해야 합니다. 다시 실행한다는 기술적인 선택이 고객에게는 두 번째 연락으로 나타날 수 있기 때문입니다.

따라서 운영 책임자는 구현 담당자와 재시도 횟수부터 정하기보다, 무엇을 같은 업무로 볼지 먼저 합의해야 합니다. 한 번의 업무를 완수하려고 여러 번 시도할 수는 있지만, 그때마다 새로운 업무를 만드는 것은 별개의 결정입니다. 이 구분을 기록과 실행 규칙에 반영해야 복구를 맡길 수 있습니다.

응답이 없다는 사실만으로 실패를 확정할 수는 없습니다

시간 초과는 요청을 보낸 쪽이 응답 대기를 끝냈다는 뜻입니다. 요청을 받은 시스템까지 작업을 중단했다는 증거는 아닙니다. 상태를 작업 시작 전 실패, 완료 확인, 결과 불명으로 나누세요. 첫 번째는 정책에 따라 재시도하고, 두 번째는 기존 결과를 사용하며, 세 번째는 외부 시스템의 실제 결과를 확인한 뒤 다음 행동을 정합니다.

Shopify Flow의 사용자 정의 액션 엔드포인트가 한 가지 예입니다. Flow는 최대 10초 동안 응답을 기다린 다음 연결을 닫고 나중에 다시 전송합니다. 수신 측은 action_run_id로 같은 액션 실행인지 알아볼 수 있지만, 업무의 중복 처리는 직접 방지해야 합니다. 이 10초 규칙이 모든 웹훅이나 CRM, AI에 적용되는 것은 아닙니다.

웹훅은 이벤트가 발생했을 때 시스템 간에 자동으로 전달되는 알림입니다. 알림이 한 번 더 도착했다고 해서 고객이 같은 행동을 한 번 더 했다고 단정해서도 안 됩니다. 재전송된 알림과 새로운 업무 요청을 구분하는 기준이 필요합니다.

같은 업무를 알아볼 수 있는 기록을 남기세요

하나의 업무상 작업에 이름이나 이메일 주소 같은 고객 정보를 담지 않은 고유 작업 ID를 부여합니다. 이 ID는 재시도해도 유지하고, 기술적인 시도마다 별도의 시도 ID를 붙입니다. 운영자가 의도적으로 두 번째 업무나 메시지를 만들려면 새 작업 ID와 승인이 필요합니다. 그래야 중복 방지가 정상적인 별도 작업까지 막지 않습니다.

알림 ID를 곧바로 업무의 ID로 쓰면 문제가 생길 수도 있습니다. Shopify는 동일한 웹훅이 여러 번 전달될 수 있다고 안내합니다. 또 같은 판매자 행동에서 나온 알림이라도 구독이 다르면 웹훅 ID가 서로 다르고 이벤트 ID는 같을 수 있습니다. 구현 담당자는 알림의 식별 정보와 실제 업무의 식별 정보를 어떻게 연결할지 설명해야 합니다.

운영 기록에는 작업 ID, 이벤트와 출처, 수행하려는 행동, 승인된 내용과 버전, 현재 상태, 시도 횟수, 대상 시스템의 결과 참조값, 시간 정보를 저장합니다. 책임자와 다음에 내려야 할 결정도 포함하세요. 이런 기록 양식을 설계하고 설명하는 데 실제 고객의 민감한 정보까지 넣을 필요는 없습니다.

CRM 업무 생성과 메일 발송은 따로 확인해야 합니다

다음은 실행하지 않은 가상 사례입니다. 캠페인 요청이 승인되면 CRM에 후속 업무 한 건을 만들고, 이어서 이메일을 보내는 흐름을 생각해 보겠습니다. CRM은 업무를 저장했지만 응답이 유실됐습니다. 전체 흐름을 처음부터 다시 실행하면 이미 있는 업무와 똑같은 항목이 하나 더 생길 수 있습니다.

이 경우 먼저 확실한 연결 정보로 CRM의 기존 업무를 조회합니다. 생성이 확인되면 CRM에서 부여한 ID를 운영 기록에 저장하고, 아직 해결되지 않은 단계부터 이어 갑니다. 업무 생성 결과와 이메일 전송 결과는 각각 확인해야 합니다. 발송 서비스가 이메일을 접수한 것과 수신자에게 도착한 것도 구분해야 합니다. 전체 흐름의 실패 표시 하나만 보고 두 단계 모두 수행되지 않았다고 판단해서는 안 됩니다.

조회해도 결과를 확정할 수 없고 대상 시스템에 중복 방지 기능도 없다면 보류합니다. 누구에게 넘길지까지 정해 둔 검토 절차를 사용해야 합니다. 결과 불명 상태를 숨긴 채 자동으로 다시 보내는 것은 적절한 복구 규칙이 아닙니다.

중복 방지 기능의 범위와 한계를 구현 담당자에게 물어보세요

멱등성이란 시스템 문서에 정해진 조건 안에서 같은 의도의 작업을 반복해도 효과가 한 번 더 생기지 않는 성질입니다. 모든 연결에 자동으로 적용되는 보장은 아닙니다. 대상 서비스가 지원한다면 활용하되, 지원하는 작업과 보관 기간, 매개변수 비교 방식, 오류 처리까지 확인해야 합니다.

Stripe의 지원 대상 POST 요청을 예로 들면, 같은 멱등성 키로 요청할 때 처음 저장한 상태와 응답을 오류까지 포함해 돌려줍니다. 같은 키에 다른 매개변수를 보내면 오류가 납니다. 키는 최소 24시간이 지난 뒤 삭제될 수 있고, 삭제 후 다시 쓰면 새 요청이 됩니다. 결과는 엔드포인트에서 실행이 시작된 뒤 저장되므로 입력 검증 실패나 동시 실행 충돌에는 다른 규칙이 적용됩니다. 결제 자동화를 제안하는 것이 아니라, 인터페이스별 조건을 확인해야 하는 이유를 보여 주는 예입니다. 다른 서비스도 24시간 보호된다고 가정할 수는 없습니다. 문서에서 허용한다면 유효한 보관 기간 안에 같은 키와 매개변수로 재시도하여, 대상 시스템의 멱등성 기능으로 기존 결과를 확인할 수도 있습니다. 반드시 별도의 수동 조회가 필요한 것은 아닙니다.

내부 기록에서 “이미 처리했는가?”만 확인하는 방식도 충분하지 않습니다. 두 실행 프로세스가 동시에 확인하면 둘 다 미처리로 읽고 진행할 수 있습니다. 외부 작업은 끝났지만 내부 성공 기록을 저장하기 전에 자동화가 멈출 수도 있습니다.

구현 담당자에게 내부 기록의 원자적 선점이나 고유성 제약을 요구하세요. 원자적 선점은 쪼갤 수 없는 단일 처리로 실행 권한을 확보하여, 같은 작업을 두 프로세스가 동시에 맡지 못하게 하는 방식입니다. 여기에 대상 시스템의 중복 방지 또는 실제 결과 대조가 함께 필요합니다. 작업 ID를 적어 두거나 완료 후 로그를 남기는 것만으로는 시스템 사이의 빈틈이 사라지지 않습니다.

승인된 내용은 재시도에서도 그대로 사용하세요

AI가 문안을 다시 생성하면 이전과 다른 내용이 나올 수 있습니다. 이미 승인된 전송 작업을 재시도할 때는 당시 승인된 내용을 그대로 사용해야 합니다. 내용을 바꾸려면 다시 검토받아야 합니다. 대체 작업을 새로 승인하기 전에는 원래 작업의 불분명한 결과부터 해결해야 합니다. AI는 초안을 만들거나 오류를 분류할 수 있지만, 실제 영향을 주는 작업은 명확한 실행 규칙과 지정된 책임자가 관리해야 합니다. 프롬프트 개선만으로 외부 작업의 중복을 막을 수는 없습니다.

사람의 승인 단계를 넣었다고 재개 과정이 자동으로 안전해지는 것도 아닙니다. LangGraph에서는 interrupt()로 일시 중지한 뒤 재개하면 해당 노드, 즉 처리 단계가 처음부터 다시 실행됩니다. 중단 전에 외부 시스템에 반영한 변경이 반복될 수 있다는 뜻입니다. 외부 작업을 분리하거나 위치를 옮기고, 멱등성을 갖추는 방법을 검토해야 합니다. 다만 단계를 분리하는 것만으로 이후의 모든 장애까지 해결되는 것은 아닙니다.

복구가 제대로 되는지 확인할 인수 기준을 만드세요

아래 목록은 구현 담당자와 합의할 수 있는 시험 사례와 기대 동작입니다. 실제 수행한 시험 결과나 모든 시스템에서 중복이 전혀 없다는 보증은 아닙니다. 각 사례에서 결과의 근거, 남은 상태, 다음 담당자를 확인할 수 있어야 합니다.

1. 일반적인 성공: 의도한 외부 작업이 수행되고 대상 시스템의 결과 참조값이 저장된다.
2. 같은 이벤트의 중복 전달: 합의된 보호 조건에서 외부 효과는 한 번만 발생하고, 뒤의 시도는 기존 근거를 사용한다.
3. 대상 시스템 성공 후 시간 초과: 기존 결과를 확인하고, 확정할 수 없으면 검토 대기 상태로 둔다.
4. 두 시도의 동시 실행: 내부 선점과 대상 시스템의 보호가 함께 작동해 보호 대상 사례에서 두 번째 효과를 막는다.
5. 승인 후 재개: 완료된 단계와 승인된 내용을 유지하고 미해결 단계만 처리한다.
6. 대상 시스템의 보관 기간이 지난 뒤 재실행: 이전 키가 계속 보호한다고 가정하지 않고 결과를 대조하거나 검토를 요청한다.

재시도 횟수의 상한과 점차 늘리는 대기 간격은 대상 시스템의 문서화된 정책을 기준으로 정하세요. 무한 재시도나 모든 서비스에 공통으로 적용할 횟수를 정하는 방식은 피해야 합니다. 운영에서는 이벤트 수, 시도 횟수, 확인된 외부 효과, 미해결 항목, 담당자가 복구에 쓴 시간을 구분해 측정합니다. 성공한 실행 수만으로는 고객에게 중복 메시지가 갔는지 알 수 없습니다.

작은 파일럿에서도 책임과 범위는 구체적이어야 합니다

MindVerve의 자동화 서비스는 트리거, 입력, 출력, 책임자를 정리하고 누락 데이터와 실패 처리 규칙, 시험 사례, 운영 지침을 마련합니다. AI Workflow Launch는 합의한 워크플로 하나를 대상으로 도구 선정, 대표 사례 및 실패 상황 시험, 재사용 가능한 요구사항 문서와 프롬프트, 문서화, 교육, 인수인계를 포함합니다. 라이선스, API 사용료, 추가 연동은 포함하지 않으며 지속적인 유지보수는 별도로 다룹니다.