내가 모든 프로젝트에서 사용하는 5가지 n8n 워크플로우 패턴

Source: Dev.to

오류 처리 서브 워크플로우

메인 워크플로우에 오류 처리를 흩어 놓지 마세요. 전용 오류 처리기를 만드세요:

Main Workflow → On Error → Call Error Handler Sub-Workflow

오류 처리기가 해야 할 일:

• 전체 오류 컨텍스트 로그 기록
• 알림 전송 (Slack/이메일)
• 실패한 항목을 재시도를 위해 저장
• 오류 발생 빈도 추적

모든 오류 로직을 한 곳에서 관리합니다.

시작 시 Config 노드

모든 워크플로우의 첫 번째 노드로 Set 노드를 배치하고 설정을 지정하세요:

{
  "env": "production",
  "batchSize": 100,
  "retryAttempts": 3,
  "alertChannel": "#ops-alerts",
  "dryRun": false
}

나머지 로직을 수정하지 않고 동작을 변경합니다. 드라이‑런 모드를 토글하고, 배치 크기를 조정하는 등 모든 것을 한 곳에서 할 수 있습니다.

멱등성 검사

항목을 처리하기 전에 이미 처리됐는지 확인합니다:

// Check processed items table
const alreadyProcessed = await checkDatabase(item.id);
if (alreadyProcessed) {
  return []; // Skip
}

이를 방지합니다:

• 중복 이메일
• 이중 청구
• 반복 API 호출

재시도가 가능한 워크플로우에 필수적입니다.

배치 + 지연 패턴

레이트 제한이 있는 API를 호출할 때:

Split In Batches (10 items) → Process → Wait (1 second) → Loop

간단하지만 대부분의 레이트 제한 문제를 방지합니다. API 제한에 따라 배치 크기와 지연 시간을 조정하세요.

헬스 체크 워크플로우

다른 워크플로우를 모니터링하는 별도 워크플로우:

• 실행 기록에서 실패 여부 확인
• 예상 실행이 이루어졌는지 검증
• 중요한 API 연결 테스트
• 문제가 있으면 알림

사용자보다 먼저 문제를 알 수 있도록 매시간 실행하세요.

보너스: 로깅 패턴

모든 워크플로우는 다음을 로그해야 합니다:

• 시작 시간 및 트리거 정보
• 처리된 항목 수
• 건너뛴 항목 및 이유
• 소요 시간 및 결과

로그를 간단한 데이터베이스나 Google Sheet에 저장하세요. 디버깅에 매우 유용합니다.

구현 팁

단순하게 시작하세요. 모든 패턴을 모든 워크플로우에 적용하지 말고 필요에 따라 도입하세요.

서브 워크플로우를 사용하세요. 오류 처리기, 로깅, 알림은 재사용 가능해야 합니다.

결정을 문서화하세요. n8n에 왜 그렇게 동작하는지 설명하는 메모를 추가하세요.

버전 관리. 워크플로우를 정기적으로 내보내고 Git에 보관하세요.

결과

다음과 같은 워크플로우:

• 실패를 우아하게 처리
• 디버깅이 쉬움
• 부하가 걸려도 중단되지 않음
• 안전하게 수정 가능

이것이 프로토타입과 프로덕션의 차이점입니다.

More production patterns at