n8n 실패 실행을 다시 돌리기 전에 워크플로 버전부터 골라보세요

2.44.0에서는 무엇이 바뀌었나요?

2026년 10월 13일 나온 n8n 2.44.0에는 실행 카드의 재시도 메뉴를 정리한 수정이 들어 있어요. 10월 19일 확인한 공식 릴리스 페이지에는 프리릴리스로 표시돼요. 이 변경만 보고 운영 환경을 바로 올리기보다 사용 중인 버전과 화면을 먼저 확인하세요.

이 수정은 메뉴를 정렬하고 버튼 너비를 조정하며, 선택지마다 짧은 제목과 설명을 넣었어요. 재시도 범위나 중복 방지 기능이 새로 추가됐다고 소개한 변경은 없어요. 메뉴가 읽기 쉬워져도 외부 서비스에 무엇이 반영됐는지는 따로 봐야 해요.

현재 버전과 원래 버전은 어떻게 고르나요?

실행 목록의 Retry execution에서 두 선택지를 고를 수 있어요. 2.44.0 수정에 들어간 짧은 이름과 공식 문서의 긴 이름을 맞춰 보면 이래요.

출처는 공식 수정 내역과 전체 실행 문서이고 확인일은 2026-10-19예요. 두 선택지 모두 이전 실행 데이터를 사용해요. 현재 저장본을 고른다고 입력까지 최신 자료로 바뀌는 건 아니에요.

실패 실행의 데이터 → 선택한 워크플로 버전 → 재시도 결과 확인

입력 자체가 잘못됐다면 같은 데이터로 재시도할지부터 다시 판단하세요. 새 자료로 시작하는 실행과 과거 실행을 재시도하는 작업은 기록에서도 구분해 두는 게 좋아요.

원인을 고칠 때는 데이터를 어떻게 불러오나요?

실행 내용을 편집기에서 보려면 해당 워크플로의 Executions를 열고 실패한 실행에서 Debug in editor를 골라요. 성공한 실행은 Copy to editor를 써요. n8n이 이전 실행 데이터를 현재 워크플로로 복사하고 첫 노드에 고정해요.

공식 디버깅 문서의 지원 범위는 n8n Cloud 전체 플랜과 자체 호스팅의 등록된 Community·Business·Enterprise예요. 실행 목록에 남아 있는 데이터가 있어야 비교할 수 있으니, 목록이 비어 있다면 저장 설정도 확인하세요.

고정 데이터는 개발 중 같은 입력을 재사용하는 데 쓰여요. 고정한 노드에서 새 자료를 가져오는 호출을 줄일 수 있지만, 그 뒤에 연결된 전송·수정 단계까지 모두 모의 실행으로 바꾸는 기능은 아니에요. 시험할 때는 외부 변경 단계가 실제 계정으로 이어지는지 확인하고 테스트용 대상으로 바꿔 두세요. 데이터 고정은 프로덕션 실행에서는 쓸 수 없어요.

재시도 전에 외부 서비스에서는 무엇을 보나요?

오류가 난 노드가 메일 전송이나 데이터 변경을 맡았다면, 해당 서비스의 전송함·변경 이력에서 요청이 반영됐는지 먼저 찾아보세요. 결과가 확인되지 않은 동안에는 같은 요청을 반복하지 않는 편이 안전해요. 아래는 재시도 버튼을 누르기 전 운영자가 확인할 순서예요.

1. 실패한 실행 ID와 오류가 난 노드를 적어 둬요.
2. 외부 서비스에서 같은 대상·시각의 처리 결과와 요청 ID를 대조해요.
3. 반영 여부가 확인되면 남은 작업과 다시 실행할 범위를 정해요.
4. 설정을 수정했다면 저장본을 확인한 뒤 맞는 재시도 선택지를 골라요.

서비스가 중복 요청 방지 키를 지원한다면 그 계약도 확인하세요. n8n 재시도 메뉴의 버전 선택만으로 외부 서비스의 중복 처리가 해결되지는 않아요.

다음 오류를 위해 어떤 기록을 남겨 두나요?

워크플로 메뉴의 Settings에는 실패한 프로덕션 실행을 저장하는 설정과 노드별 진행 상황을 저장하는 설정이 있어요. 공식 문서는 진행 상황을 저장하면 오류 시 멈춘 지점부터 재개하고 지연이 늘 수 있다고 설명해요. 실행을 저장할 때는 입력·출력에 남는 자료의 보관 범위도 함께 정하세요.

장애 기록에는 원래 실행 ID, 선택한 버전, 수정한 설정, 외부 처리 결과를 남겨 두세요. 다음 담당자가 같은 요청을 다시 보내기 전에 이 네 값을 찾을 수 있으면 돼요.

출처: n8n 2.44.0, 재시도 메뉴 수정, 전체 실행, 이전 실행 디버깅, 데이터 고정, 워크플로 설정. 확인일 2026-10-19.