마케팅 운영·마테크 가이드
자동화가 두 번 실행될 때 원인 찾기
AI 보조 조사·작성 · 공식 자료 기반 · 실사용 시험이나 이용 후기가 아닙니다.
자동화가 두 번 실행됐다는 화면만으로 중복 트리거와 재시도를 구분할 수 없습니다. 이벤트 식별자, 실행 시각, 응답 코드, 결과 객체를 함께 보세요.
고객 한 명에게 알림이 두 번 가거나 CRM에 같은 리드가 두 건 생겼나요? 자동화 실행 기록이 두 줄이라고 해서 트리거가 두 번 발생했다고 바로 결론 내리면, 실패 후 정상 재시도나 수동 재실행을 놓칠 수 있습니다.
원본 이벤트 ID, 자동화 실행 ID, 대상 시스템의 생성 ID를 한 줄로 연결하세요. Stripe는 웹훅 이벤트가 한 번 이상 전달될 수 있으므로 처리한 이벤트 ID를 기록하라고 안내하고, API 재시도에는 같은 작업을 반복하지 않도록 멱등키를 쓰는 방법을 제공합니다. 웹훅 재시도·중복 문서와 Zapier 중복 제거 기준을 근거로 진단 순서를 설명합니다.
자동화 도구 후보를 검토해야 한다면 요즘뭐써 카탈로그에서 실행 로그, 재시도, 중복 제거 지원을 확인해 보세요.
이 가이드의 설명을 위해 직접 제작했습니다. 제3자 사진·제품 화면을 사용하지 않았습니다.
두 실행이 같은 이벤트인지 어떻게 확인하나요?
실행 시각이 가깝다는 이유만으로 같은 이벤트라고 보지 마세요. 원본 서비스의 이벤트 ID, 이벤트 유형, 대상 객체 ID, 생성 시각, payload의 변경 가능한 필드를 비교합니다. 이벤트 ID가 같으면 중복 전달이나 재처리일 가능성이 있고, ID가 다르면 원본에서 별도 이벤트가 만들어졌을 수 있습니다.
세 종류의 식별자를 연결하세요
원본 이벤트 ID는 웹훅 발신 서비스가 부여합니다. 자동화 실행 ID는 Zapier, Make, n8n 같은 도구가 각 실행에 부여합니다. 결과 객체 ID는 CRM 연락처, 메시지, 주문처럼 최종 시스템에 생성된 값입니다. 세 값을 표에 적으면 같은 입력이 두 번 처리됐는지, 서로 다른 입력이 같은 결과처럼 보이는지 구분할 수 있습니다.
- 원본 이벤트 ID와 이벤트 유형
- 자동화 실행 ID, 시작·종료 시각, 재시도 표시
- 각 단계의 입력값과 응답 상태 코드
- 최종 시스템의 생성·갱신 객체 ID
개인정보가 포함된 payload 원문을 그대로 공유하지 말고 진단에 필요한 식별자와 상태만 추출하세요. 로그가 없다면 원인을 단정하지 않고 다음 발생부터 기록할 필드를 먼저 정합니다.
트리거·재시도·동시 실행은 어떻게 구분하나요?
| 관찰 패턴 | 가능한 구분 | 확인 로그 | 미확인 원인 |
|---|---|---|---|
| 같은 이벤트 ID, 실행 두 건 | 중복 전달 또는 재처리 | 웹훅 전달 시도와 응답 코드 | 왜 첫 응답이 실패했는지 |
| 다른 이벤트 ID, 객체 동일 | 원본에서 별도 이벤트 생성 | event.type과 data.object ID | 업무상 정상 이벤트인지 |
| 수동 실행과 자동 실행 겹침 | 운영자 재실행 | 실행 주체와 시작 시각 | 수동 절차 승인 여부 |
| 같은 입력으로 객체 두 건 생성 | 대상 API 중복 처리 | 요청 ID와 멱등키 | 대상 시스템의 중복 규칙 |
| 동시에 두 분기 실행 | 경쟁 상태 가능성 | 잠금·처리중 상태 기록 | 분기 조건과 저장 순서 |
Stripe는 실서비스 웹훅 전달을 일정 기간 자동 재시도하며 같은 이벤트가 여러 번 전달될 수 있다고 설명합니다. 처리한 event ID를 기록하고 이미 처리한 이벤트는 다시 실행하지 않는 방식을 권합니다. 서로 다른 이벤트 객체가 같은 대상 객체를 가리킬 수도 있으므로 event.type과 data.object ID를 함께 보라고 안내합니다. Handle duplicate events와 Automatic retries 절을 확인하세요.
Zapier의 폴링 트리거는 결과의 고유 id를 기준으로 이미 본 항목을 제외합니다. id가 없거나 매번 바뀌면 같은 항목이 새 데이터로 인식될 수 있습니다. 공식 deduplication 문서처럼 기본키가 안정적이고 결과에서 유일한지 확인하세요.
식별키와 중복 방지 로직은 어떻게 설계하나요?
중복 방지는 실행 기록을 지우는 기능이 아니라 같은 업무 효과를 한 번만 적용하는 규칙입니다. "고객 생성"이라면 원본 고객 ID나 폼 제출 ID처럼 업무상 같은 요청을 식별할 키를 정합니다. 현재 시각이나 자동화 실행 ID는 재시도마다 달라질 수 있어 업무 식별키로 적합하지 않을 수 있습니다.
처리 전 상태를 먼저 기록하세요
이벤트를 받은 뒤 처리 완료 시점에만 기록하면 동시에 들어온 두 실행이 모두 미처리로 판단할 수 있습니다. 가능한 환경에서는 처리중 상태를 원자적으로 저장하고, 완료 또는 실패로 바꾸는 방식을 검토하세요. 노코드 도구만 쓴다면 데이터 저장소의 고유키, 검색 후 생성, upsert 지원 여부를 확인합니다.
- 이벤트 ID 또는 업무 객체 ID를 중복키로 정합니다.
- 처리중·완료·실패 상태와 갱신 시각을 남깁니다.
- 같은 키가 다시 오면 기존 결과를 반환하거나 건너뜁니다.
- 알림처럼 되돌리기 어려운 단계는 마지막에 실행합니다.
Stripe API 멱등 요청 문서는 생성·수정 요청에 멱등키를 쓰면 연결 오류 후 같은 요청을 다시 보내도 작업이 중복 수행되지 않도록 지원한다고 설명합니다. 다만 각 플랫폼의 보관 기간과 파라미터 비교 규칙이 다르므로 제품 문서를 확인해야 합니다. 웹훅 수신 이벤트 ID와 대상 API 멱등키도 같은 개념으로 뭉뚱그리지 마세요.
이 가이드의 설명을 위해 직접 제작했습니다. 제3자 사진·제품 화면을 사용하지 않았습니다.
수정 후에는 어떤 실패 상황을 시험하나요?
정상 실행 한 번만 성공하는지 보는 것으로는 부족합니다. 웹훅 수신 직후 시간초과, 대상 API 성공 뒤 응답 유실, 수동 재전송, 같은 이벤트의 병렬 도착을 시험하세요. 실제 고객 알림이나 결제가 발생하지 않도록 샌드박스와 테스트 데이터를 사용합니다.
성공 응답 시점도 확인하세요
웹훅 발신자는 정해진 시간 안에 성공 응답을 받지 못하면 실패로 보고 재시도할 수 있습니다. Stripe는 복잡한 후속 작업 전에 빠르게 2xx를 반환하도록 안내합니다. 웹훅 처리 권고를 참고해 수신 확인과 긴 작업을 분리할 수 있는지 개발 담당자와 검토하세요.
노코드 도구에서는 자동 재시도 횟수와 조건, 수동 재실행이 자동 재시도를 취소하는지 확인합니다. 로그가 요약 상태만 제공한다면 원본 요청 ID를 별도 저장하는 단계가 필요할 수 있습니다. 후보별 기능은 자동화 도구 카탈로그에서 공식 문서로 확인하세요.
이미 생긴 중복 결과는 어떻게 복구하나요?
먼저 자동화를 멈출지 판단하고 새 중복이 생기지 않도록 합니다. 영향을 받은 기간과 이벤트 ID를 기준으로 결과 객체를 추출한 뒤, 삭제보다 취소·비활성·병합처럼 이력을 남기는 방법이 있는지 확인하세요. 고객 알림은 발송 취소가 불가능할 수 있으므로 추가 안내 여부를 담당자와 결정합니다.
복구 스크립트나 수동 재처리도 여러 번 실행될 수 있습니다. 복구 대상 목록에 처리 상태를 남기고 같은 이벤트를 다시 처리하지 않도록 해야 합니다. Stripe 공식 문서도 수동 복구와 자동 재시도가 겹칠 수 있어 이미 처리한 이벤트를 건너뛰라고 설명합니다.
마지막으로 원인, 수정한 규칙, 시험한 실패 상황, 남은 미확인 항목을 기록하세요. 새 도구를 도입하더라도 같은 식별키와 복구 기준이 필요합니다. 요즘뭐써 카탈로그에서 로그와 중복 방지 기능을 확인해 보세요.
공식 확인 자료
- Stripe webhooks
웹훅 재시도, 중복 이벤트, 응답과 이벤트 순서를 확인할 공식 문서
- Zapier deduplication
폴링 트리거의 고유 ID와 중복 제거 조건을 확인할 공식 문서
자주 묻는 질문
- 자동화 실행 기록이 두 건이면 트리거가 두 번 발생한 것인가요?
- 확정할 수 없습니다. 같은 이벤트의 재시도, 수동 재실행, 병렬 분기일 수 있으므로 원본 이벤트 ID와 실행 ID를 함께 확인하세요.
- 재시도를 끄면 중복 실행이 해결되나요?
- 권하지 않습니다. 재시도는 일시 장애 복구에 필요할 수 있습니다. 같은 이벤트를 여러 번 받아도 업무 효과가 한 번만 생기도록 중복키와 처리 상태를 설계하세요.
- 멱등키는 자동화 실행 ID를 쓰면 되나요?
- 재시도마다 실행 ID가 달라질 수 있어 적합하지 않을 수 있습니다. 폼 제출 ID, 주문 ID처럼 같은 업무 요청을 안정적으로 식별하는 값을 검토하세요.
- 이미 만들어진 중복 CRM 레코드는 바로 삭제해도 되나요?
- 먼저 소유자, 활동, 동의 이력과 외부 연동을 확인하세요. 제품이 병합이나 비활성 처리를 지원하는지 보고, 삭제 권한과 복구 가능성을 확인한 뒤 처리해야 합니다.
출처와 확인 범위
- Receive Stripe events in your webhook endpoint · Stripe Docs · 확인 2026-10-27
뒷받침하는 내용: 웹훅 자동 재시도, 중복 이벤트 처리, event ID 기록, 이벤트 순서 비보장과 빠른 2xx 응답 권고를 설명합니다.
확인 범위·한계: Stripe 웹훅 동작이며 다른 자동화·연동 서비스의 재시도 정책과 같다고 볼 수 없습니다. - How does deduplication work in Zapier? · Zapier Platform Docs · 확인 2026-10-27
뒷받침하는 내용: 폴링 결과의 고유 id를 기본키로 사용해 이미 본 항목을 제외하며 id는 항상 제공되고 결과에서 유일해야 한다고 안내합니다.
확인 범위·한계: Zapier 통합 개발 문서이며 사용 중인 앱의 REST Hook이나 다른 자동화 플랫폼 동작은 별도 확인해야 합니다. - Idempotent requests · Stripe Docs · 확인 2026-10-27
뒷받침하는 내용: 생성·수정 API 요청에 멱등키를 사용해 연결 오류 뒤 같은 요청을 재시도할 때 중복 작업을 막는 방법을 설명합니다.
확인 범위·한계: Stripe API 요청 규칙이며 웹훅 이벤트 중복 제거와 같은 기능은 아닙니다.