n8n 재시도 중복 생성, CRM 시간 초과 후 안전하게 복구하는 순서

CRM 등록 단계에서 시간 초과가 나면 재실행부터 누르기 쉽습니다. 하지만 CRM에는 문의가 저장됐고, n8n만 응답을 받지 못했을 수 있습니다. 이때 필요한 것은 같은 요청을 빨리 보내는 일이 아니라, 저장 결과를 확인하고 다음 행동을 고르는 기준입니다. 문의 고유 ID를 중심으로 조회, 갱신, 생성, 수동 확인을 나누면 복구 과정에서 생기는 중복을 줄일 수 있습니다.

시간 초과는 저장 실패의 확정 증거가 아닙니다

문의 등록은 요청을 보내는 과정과 CRM이 저장 결과를 돌려주는 과정으로 나눠 보세요. 응답을 제때 받지 못했다는 사실만으로 저장되지 않았다고 결론 내리면 안 됩니다. Reddit의 Workflows Problems and Errors 토론에도 CRM 생성 요청이 시간 초과됐지만 리드는 이미 저장됐을 수 있다는 문제가 등장합니다. 이는 한 작성자가 제기한 상황이며, 국내 발생 빈도를 보여주는 자료는 아닙니다. 실무에서는 이 상태를 미저장이 아니라 저장 결과 미확인으로 분류하는 편이 안전합니다.

복구의 첫 단계는 같은 문의를 처리할 다른 실행이 있는지 확인하고, 겹치는 재실행을 멈추는 것입니다. 이어 실패한 실행의 입력, 문의 고유 ID, 요청 시각을 확보하세요. CRM에서는 같은 고유 ID가 저장된 기록을 조회합니다. 이메일이나 이름만으로 찾으면 동일 고객의 다른 문의를 혼동할 수 있습니다. 체크리스트는 원본 문의를 식별할 수 있는가, 목적지 기록과 연결할 수 있는가, 다른 실행이 처리 중인가입니다. 이 세 가지를 확인한 뒤 재시도 범위를 정하세요.

문의 고유 ID는 재시도해도 유지하세요

문의 고유 ID는 고객 한 명이 아니라 문의 한 건을 구분하는 기준으로 설계하세요. 같은 고객이 다른 날짜에 새 문의를 남겼다면 별도 문의로 다룰 수 있어야 합니다. 반대로 같은 문의를 복구하는 동안에는 처음 부여한 ID를 계속 사용해야 합니다. 재시도할 때 ID를 새로 만들면 CRM에서 기존 문의를 찾아 연결하기 어려워집니다. 원본에 제출 식별자가 있다면 활용 가능성을 살피고, 없다면 최초 접수 단계에서 부여해 이후 단계와 목적지까지 전달하는 구조를 권합니다.

가상 예시로, 상담 문의에 문의 고유 ID 상담가가 붙었다고 가정하겠습니다. CRM 저장 응답이 늦어 실패로 표시돼도 재시도에는 상담가를 그대로 전달합니다. CRM에서 상담가가 발견되면 해당 기록과 원본 내용을 비교하고 필요한 정보만 갱신합니다. 발견되지 않았더라도 조회 오류인지 실제 검색 결과가 없는지 먼저 구분해야 합니다. 조회 자체가 실패했는데 결과가 없다고 간주해 생성하는 것은 피하세요. 고유 ID는 중복 판단의 기준이며, 그것만으로 중복 저장이 자동 차단되지는 않습니다.

조회 결과에 따라 갱신·생성·수동 확인을 나누세요

팀의 복구 판단표에는 조회 결과와 다음 행동을 함께 적으세요. 같은 고유 ID가 한 건 있고 내용도 맞으면 신규 생성은 생략합니다. 빠진 정보가 있다면 기존 기록을 갱신하되, 담당자가 이미 바꾼 상담 상태를 과거 입력으로 덮어쓰지 않도록 항목을 정하세요. 같은 ID가 여러 건이면 추가 생성을 멈추고 수동 확인으로 넘깁니다. 조회에 실패했거나 원본 ID가 없어 일치 여부를 판단할 수 없는 경우도 보류합니다. 기록이 없는 경우와 확인할 수 없는 경우를 구분하는 것이 핵심입니다.

같은 고유 ID가 없다는 조회가 정상적으로 끝났다면 신규 생성을 검토할 수 있습니다. 다만 다른 실행이 같은 문의를 저장하는 중인지도 확인하세요. 가상 예시로 문의 세 건 중 두 건이 CRM에 있고 한 건만 없다면, 세 건을 일괄 생성하는 대신 기존 두 건은 유지하거나 필요한 부분만 갱신하고 누락 한 건을 처리합니다. 복구 목록에는 문의 고유 ID, 조회 결과, 선택한 행동, 처리 후 CRM 기록 식별자를 남기세요. 담당자가 바뀌어도 이미 확인한 건을 다시 생성하지 않게 하는 운영 기록입니다.

실패 노드 재시도와 전체 실행은 범위가 다릅니다

n8n 공식 문서 View all executions는 재시도가 저장된 실행 상태에서 재개되며, 완료된 노드의 결과를 유지한다고 설명합니다. 주의할 부분은 실패 노드입니다. 이 노드는 저장된 입력의 모든 항목을 다시 처리하므로, 실패 전에 일부 항목의 외부 저장이 끝났다면 같은 작업이 반복될 수 있습니다. 실패한 노드만 재시도한다는 말이 아직 저장되지 않은 문의만 처리한다는 뜻은 아닙니다. 해당 노드에 들어간 문의 목록과 CRM의 실제 저장 결과를 먼저 대조하세요.

워크플로를 처음부터 수동 실행하는 것은 저장된 실패 지점에서 재개하는 방식과 구분해야 합니다. 워크플로 구성에 따라 CRM 등록 앞의 조회나 변환, 외부 작업까지 다시 실행될 수 있으므로 반복 범위를 살펴보세요. 같은 공식 문서는 실패한 하위 워크플로 노드를 재시도하면 하위 워크플로 전체가 다시 실행된다고 안내합니다. 따라서 하위 흐름에 CRM 생성과 후속 알림이 함께 있다면 두 작업의 처리 여부를 각각 확인하세요. 재시도 버튼의 위치보다 실제 반복되는 작업의 범위가 판단 기준입니다.

동시 실행까지 고려하고 복구 결과를 검증하세요

조회 후 생성만으로 동시 중복을 완전히 막을 수는 없습니다. 가상 예시로 두 실행이 같은 문의 ID를 조회하는 순간 모두 기록이 없다고 판단하면, 각각 생성을 시도할 수 있습니다. 사용하는 CRM이 같은 ID의 중복 저장을 거부하는 고유 제약이나, 같은 요청의 반복 처리를 막는 멱등성을 지원하는지 확인하세요. 기존 기록이 있으면 갱신하고 없으면 생성하는 upsert도 이름만으로 판단하지 마세요. 동시 요청에서 어떤 결과를 내는지 해당 CRM의 공식 문서를 기준으로 확인해야 합니다.

복구 완료 기준은 n8n의 성공 표시와 CRM의 저장 결과를 함께 확인하는 것으로 정하세요. 원본 문의별로 의도한 기록이 있는지, 같은 ID가 중복되지 않았는지, 갱신 과정에서 상담 상태가 덮어써지지 않았는지 점검합니다. 후속 알림이 있다면 재발송 여부도 확인하세요. 테스트용 문의로 정상 저장, 저장 후 응답 미수신, 일부 항목 저장, 동시 재시도 상황을 검증하면 복구 규칙의 빈틈을 찾는 데 도움이 됩니다. 오늘은 최근 시간 초과 한 건부터 골라 원본 ID와 CRM 기록을 대조하고, 그 판단 과정을 팀의 복구 기준으로 남겨보세요.

그로스 마케팅 에이전시 히치하이커 AI

히치하이커 AI(hitchhiker-ai.com)는 스타트업과 중소기업을 위한 그로스 마케팅·퍼포먼스 마케팅 에이전시입니다. 김도엽 대표가 광고 운영, 데이터 분석, 마케팅 자동화를 월 구독으로 처음부터 끝까지 직접 실행합니다.

현재 광고와 전환 흐름을 점검하고 실행 우선순위를 정하고 싶다면 30분 무료 상담으로 시작해 보세요.

참고 자료