Zapier 실패 재실행 오류 단계와 전체 Replay 범위 확인

자동화가 중간에 실패했을 때 다시 실행 버튼부터 누르면, 이미 추가한 행이나 보낸 메시지가 반복될 수 있어요. 실패한 단계만 다시 시도하는 경우와 Entire Zap을 실행하는 경우를 먼저 구분하세요. 실행 전체가 오류여도 앞 단계는 성공했을 수 있으므로 개별 단계 기록과 실제 목적지를 함께 봐야 해요.

이 글의 가상 요청 R-01과 실행 흐름은 재실행 범위를 설명하는 예제예요. 실제 Zap을 만들거나 메시지를 보내고 Replay를 시험한 기록은 아니에요. 그림은 공식 동작과 확인할 자료를 대응시킨 자체 도해예요.

실행 전체와 개별 단계 구분

Zapier 실행 세부 정보에는 실행 상태뿐 아니라 단계별 상태가 있어요. 실행 날짜, 사용한 Zap 버전, 실행 ID도 확인할 수 있어요. 서로 비슷한 요청이 여러 건이면 요청 이름만 읽지 말고 어떤 실행을 복구하려는지 고유 ID로 정하세요.

가상 흐름은 요청 수신 → 검수표 행 추가 → 담당자 알림이에요. 행 추가는 성공하고 마지막 알림에서 오류가 났다고 가정했어요. 전체 오류 표시 하나만 보고 표에도 아무것도 생기지 않았다고 판단하면, 복구할 때 앞 단계의 결과를 놓칠 수 있어요.

R-01의 행 추가 성공·알림 실패를 구분한 가상 실행 · 실제 기록 화면 아님

단계를 선택하면 Data In에서 연결 앱으로 보낸 자료, Data Out에서 받은 자료를 확인할 수 있어요. 수신처의 행 ID나 자료 이름이 있다면 실제 목적지에서 같은 결과를 찾아보세요. 성공 상태는 특정 단계의 처리 기록이며, 최종 보고서가 누락 없이 맞는지까지 대신 확인하지 않아요.

반대로 오류 상태가 목적지에 아무 효과도 없었다는 보장도 아니에요. 응답을 받는 과정이 어긋났다면 목적지에서 실제로 무엇이 남았는지 확인할 이유가 있어요. 오류 메시지와 요청 식별자, 연결 앱의 실제 결과를 같이 대조하고 확인되지 않은 부분은 미확인으로 적어 두세요.

오류 단계 재실행의 범위

공식 안내는 오류 때문에 멈춘 단계를 수동으로 다시 시도하는 방식과 자동 재실행을 구분해요. 이미 성공한 앞 단계를 전부 다시 돌리는 방식과 달라요. 같은 오류 상태라도 어떤 재실행 선택지를 사용하는지 확인해야 해요.

Zap 편집기에서 왼쪽 Zap runs를 열고 실행을 선택한 뒤 Replay X runs 메뉴의 Errored steps를 확인할 수 있어요. 이 경로는 실패 단계 재실행의 선택지예요. 메뉴를 누르기 전 선택된 실행 수와 고유 ID가 복구 대상과 맞는지 다시 읽으세요.

가상 R-01에서 표의 행 추가가 성공하고 알림 단계만 오류라면, 오류 단계 재실행은 이미 성공한 행 추가를 되풀이하는 선택과 구분돼요. 다만 알림 수신처에 실제 메시지가 없는지까지 확인하고 다시 시도할 범위를 정해야 해요. 표에 행이 있다는 사실과 알림이 전달됐다는 사실은 별도예요.

Free 플랜은 오류 상태 실행의 수동 재실행이 제공되지만, on hold 같은 다른 상태의 수동 재실행은 유료 플랜 조건이 있어요. 오류·보류·예약 상태를 같은 실패 목록으로 묶지 말고 현재 실행 상태와 계정에서 제공되는 선택지를 확인하세요.

Entire Zap은 새 실행이에요

Entire Zap은 트리거와 이전 성공 단계를 포함한 모든 단계를 다시 실행하는 방식이에요. 원래 실행을 취소하거나 앞 단계 결과를 되돌리는 버튼이 아니에요. 기존 자료를 사용해 새로운 실행이 만들어지고 실행 기록에서도 별도로 나타나요.

오류 단계 재시도와 전체 새 실행의 범위 비교 · 자체 설명 도해

같은 R-01로 전체를 다시 실행하면 앞의 행 추가도 다시 처리 대상이 돼요. 목적지 앱이나 흐름에 중복 방지 조건이 있는지에 따라 실제 결과는 달라져요. 이 그림은 중복 행이 반드시 생긴다는 시험 결과가 아니라, 다시 처리할 범위에 기존 성공 단계가 포함된다는 설명이에요.

요청 ID는 재실행 ID와 구분해서 남겨 두세요. R-01은 업무 요청을 식별하는 가상 값이고 Zap run ID는 실행을 식별해요. 같은 요청에 원래 실행과 재실행이 각각 있다면 둘의 실행 ID가 다를 수 있어요. 실행 수와 업무 건수를 같은 숫자로 세면 안 돼요.

편집 후 다시 게시한 Zap은 이전 실행의 트리거 자료로 현재 게시된 흐름을 실행할 수 있어요. 예전 실행을 선택했다고 예전 버전의 모든 조건이 그대로 복원되는 것은 아니에요. 원래 실행 버전과 지금 게시한 버전, 그 사이 바꾼 단계와 목적지를 함께 확인하세요.

수정한 흐름의 제약 확인

오류 발생 뒤 단계 수·순서·사용 앱을 크게 바꾸면 실패 단계를 재실행할 때 Zap has diverged too much 오류가 날 수 있어요. Zapier는 이 경우 전체 실행을 다시 돌리는 방법을 안내하지만, 실제 목적지 중복 확인까지 생략해도 된다는 뜻은 아니에요.

해당 오류 안내는 이전 버전으로 되돌려도 오류 단계 재실행을 할 수 없다고 설명해요. 같은 단계를 다시 배치하면 무조건 복구된다고 가정하지 마세요. 어떤 버전에서 시작했고 무엇이 바뀌었는지를 먼저 남겨야 지원 요청과 전체 실행 판단이 쉬워요.

전체 Replay도 트리거 앱이나 이벤트를 바꿨다면 실행할 수 없다는 제약이 있어요. 실행하려는 Zap이 켜져 있는지, 초기 트리거 이벤트로부터 60일 이내인지, 필요한 task가 남아 있는지도 공식 안내의 확인 조건이에요. 플랜을 바꾸는 것을 첫 해결책으로 제시할 필요는 없어요.

오류 단계 재실행에서는 Filter와 Paths가 다시 실행되지 않는다는 안내도 있어요. 실패 단계의 자료를 고치면 이전 분기도 자동으로 다시 판단될 것이라고 가정하지 않아요. 반면 전체 실행은 현재 게시된 흐름의 분기까지 포함하므로 두 선택의 조건 판단 범위가 달라요.

자동 재실행 예약을 함께 보기

Autoreplay가 켜져 있으면 오류 실행을 자동으로 다시 시도할 수 있어요. 계정 전체 설정과 Zap별 설정이 있으며, 개별 Zap의 설정은 전체 설정을 덮어쓸 수 있어요. 자신의 흐름이 어떤 설정을 따르는지와 다음 시도가 예약됐는지를 기록에서 확인하세요.

공식 안내에는 자동 시도 중 scheduled 상태로 표시될 수 있고, 예약된 시도가 있어도 수동 재실행이 가능하다고 나와요. 가능한 조작이라는 설명과 지금 수동으로 겹쳐 실행할 필요가 있다는 판단은 달라요. 누가 어떤 실패를 수동 복구하는지 공유해야 중복 시도를 줄이기 쉬워요.

자동 재실행은 최대 다섯 번 시도하며 간격이 늘어나는 방식으로 안내돼요. 실패 알림은 마지막 자동 시도가 실패한 뒤 보내질 수 있어요. 당장 알림 메일이 없다는 이유로 모든 단계가 성공했다고 판단하지 말고 실행 상태와 목적지 결과를 읽으세요.

on hold 실행은 자동 재실행 대상이 아니고 Human in the Loop 등 일부 구성에는 별도 제약이 있어요. 계정 전체 Autoreplay를 바꿀 권한도 역할에 따라 달라요. 원하는 실행 한 건을 확인하려고 조직 전체의 재실행 설정부터 변경하지 않아요.

목적지와 사용량을 검수

재실행 전에 목적지에서 R-01을 찾아 행 개수·해당 자료 내용·알림 유무를 확인하는 검수표를 만들 수 있어요. 실행 상태만 적는 칸과 목적지에서 실제로 확인한 결과를 적는 칸을 나누세요. 확인하지 못한 수신처는 추정으로 성공이나 중복 없음이라고 채우지 않아요.

요청 ID·원래 실행·재실행·목적지 반영을 대응시키는 검수표 · 실제 결과 아님

같은 요청의 행이 두 개 발견됐다면 이름이 같다는 이유만으로 하나를 바로 삭제하지 마세요. 행 ID, 생성 시점, 내용과 실행 ID를 대조해 별도 요청인지 재실행 결과인지 확인해야 해요. 이미 다른 업무가 참조하는 자료라면 복구 담당자와 정리 범위를 정해요.

성공한 액션은 task 사용량에 포함되고, 전체 재실행에서 이전 성공 단계를 다시 성공시킨 경우도 포함돼요. 트리거·Filter·Paths는 일반 액션과 다르게 안내돼요. 실제 비용을 예상하려면 현재 흐름의 단계 종류와 계정 사용량을 확인하고 단순히 단계 개수를 곱해 확정하지 않아요.

사용량 증가가 업무 요청 증가인지 같은 요청의 재실행인지 구분하려면 실행 ID를 요청 ID에 연결해 보세요. 비용 숫자만 낮추려고 실제로 필요한 복구를 생략하거나, 성공 횟수만 맞추려고 전체 실행을 반복하는 방식은 목적지 확인을 대신하지 못해요.

한 건에서 확인한 뒤 범위 결정

일괄 재실행 전에 영향이 제한된 테스트 목적지와 가상 요청 한 건으로 확인할 조건을 정하세요. 실제 메일·결제·고객 자료를 설명용 시험에 쓰지 않아요. 이 글의 예제는 확인 설계이며 실제로 그런 시험을 완료했다는 결과를 제공하지 않아요.

복구를 마치면 원래 실패 실행과 새 재실행 기록, 목적지의 행이나 메시지를 함께 남겨 두세요. 재실행 완료 표시와 의도한 내용이 한 번 반영됐다는 확인은 달라요. 요청 식별자와 실제 결과를 따라가야 앞 단계 반복이나 마지막 단계 누락을 찾기 쉬워요.

해결되지 않았다면 실행 ID·버전·오류 단계·변경한 흐름·예약된 자동 시도·목적지 확인 범위를 지원 담당자에게 전달하세요. 연결 인증이나 task 부족은 해당 오류를 확인한 뒤 조치해야 해요. 다시 실행 버튼 하나로 모든 오류와 이미 생긴 결과가 정리된다고 가정하지 않아요.

단계의 Logs가 제공되는 경우에는 상세 HTTP 자료를 확인할 수 있지만 공식 안내는 읽을 수 있는 기간을 실행 후 최대 7일로 설명해요. 로딩에 최대 3분 걸릴 수도 있어요. 로그가 바로 안 보인다는 사실과 요청이 전송되지 않았다는 판단을 구분하고, 필요한 지원 자료는 확인 가능한 기간 안에 정리하세요.

Data Out에 목적지의 식별자가 있으면 재실행 전후의 식별자를 비교하는 기준으로 사용할 수 있어요. 다만 연결 앱마다 반환하는 자료가 다르므로 모든 단계가 같은 행 ID를 제공한다고 가정하지 않아요. 식별자가 없으면 실제 확인한 이름·내용·시각과 그 한계를 남겨 두는 것이 추정한 ID를 만드는 것보다 정확해요.

선택한 실행이 여러 건이면 한 건의 복구 결과를 나머지 전체에 적용하기 전에 오류 상태와 버전이 같은지 보세요. 어떤 요청은 첫 액션에서 멈췄고 다른 요청은 마지막 액션에서 멈췄을 수 있어요. 같은 날짜의 실행을 한꺼번에 선택했다는 사실은 이전에 성공한 단계가 같다는 보장이 아니에요.

작업 기록에는 재실행을 시도한 결과가 실패한 경우도 남기세요. 오류가 바뀌었다면 이전 연결 문제와 새 자료 형식 문제가 다른 단계인지 읽어야 해요. 이 글은 새 오류를 만날 때마다 전체 흐름을 반복 실행하라고 권하지 않으며, 실제 목적지 반영을 확인한 범위에서 다음 복구를 정하도록 설명해요.