n8n Error Workflow + 재시도 전략

"내일 새벽 3시에 워크플로가 죽었다는 알림이 오면 어쩌지?" 운영 단계로 들어가면 모든 자동화 엔지니어가 마주하는 질문이다. n8n 의 답은 명확하다 — 3계층 에러 핸들링. 노드 단위 retry, Error Trigger 워크플로, 중앙 로깅·알림.

이번 17편은 이론보다 실전 위주. 어떤 에러를 재시도해야 하고 어떤 건 즉시 알림해야 하는지, 지수 백오프를 어떻게 거는지, quarantine·escalate 패턴까지 한 번에 정리한다. 운영 배포 직전 체크리스트로 쓰면 적합.

1. 3계층 복구 구조 — 한 장으로 끝

대부분의 운영 사고는 한 가지 패턴 — 한 노드가 실패 → 워크플로 전체 종료 → 알림 미발송 → 다음 날 발견. 이걸 막는 게 3 레이어다. 한 레이어로는 부족하고, 세 개가 보완하는 게 핵심.

주의 — Error Trigger 는 워크플로마다 따로 만들지 말고 하나만 만들어서 모든 워크플로에 연결한다. 워크플로 Settings → "Error Workflow" 드롭다운에서 같은 거 선택. DRY 원칙 + 알림 일관성.

2. 재시도 가능 vs 불가능 에러 분류

모든 에러를 재시도하면 안 된다. 401 (인증 실패) 를 5번 재시도하면 계정이 일시 차단되고, 404 (리소스 없음) 을 백오프로 미루면 알림만 늦어진다. 분류가 첫 단계.

3. 지수 백오프 — n8n 에서 두 가지 방법

n8n 기본 Retry on Fail 은 고정 간격이라 진짜 백오프는 따로 구성. 두 패턴 중 하나.

방법 A — Code 노드로 직접

본문 워크플로의 try 위치에 Code 노드 1개 추가, 안에서 setTimeout 으로 백오프:

const attempt = $input.item.json.retry_count || 0;
const wait = Math.min(5000 * Math.pow(2, attempt), 60000);
await new Promise(r => setTimeout(r, wait));
return [{json: {retry_count: attempt + 1}}];

장점 — 정교한 지터(±20% 랜덤) 추가 가능. 단점 — 코드 유지보수 필요.

방법 B — IF + Wait 노드 조합 (No-Code)

Wait 노드의 시간을 동적 표현식 ={{ Math.min(5 * Math.pow(2, $json.retry_count || 0), 60) }} 로 설정. retry_count 를 Set 노드로 증가시키며 IF 로 "Max 5회 초과? → Error Trigger" 분기.

장점 — 캔버스에서 흐름 시각화. 단점 — 노드 5-6개 더 필요해 캔버스가 복잡. 팀이 코드를 안 만지는 환경이면 이 방법.

4. Quarantine → Escalate 패턴

모든 영구 실패가 같은 대응을 요구하진 않는다. 로그만 남기면 되는 실패(누락된 1건)와 즉시 인간 호출 필요한 실패(결제 처리 실패)는 다르다. n8n 운영자들이 쓰는 4단계 시퀀스 — Retry → Quarantine → Escalate → Rollback.

1. Retry — 위 레이어 ①. 5분 내 자동 복구 시도.
2. Quarantine — 실패 데이터를 별도 "보류 큐" (Postgres 테이블 또는 Sheets) 에 격리. 메인 워크플로는 계속 진행. 다음 사이클이나 수동 검토 시 재처리.
3. Escalate — quarantine 큐가 N 건 이상 쌓이면 (또는 critical tag 가 붙은 실패면) 즉시 인간에게 Slack DM · SMS · 호출.
4. Rollback — 부분 완료된 트랜잭션을 되돌림. DB 작업이면 정말 트랜잭션, API 작업이면 보상 호출 (예: WP 글 발행 후 미디어 업로드 실패 → 글 status 를 draft 로 되돌림).

이 패턴이 자리 잡으면 새벽 사고로 깨어나는 빈도가 격감한다. 18편 (Postgres/DB 연동) 의 Upsert · 트랜잭션과 같이 쓰면 진짜 production-grade.