에러 핸들링 — Try/Catch와 오류 알림

🎯 학습 목표

이 강을 마치면 다음을 할 수 있습니다.

• n8n 노드의 Error Output 핀을 활성화해 오류를 포착하고 별도로 처리합니다.
• Error Trigger 워크플로우를 설정해 전체 워크플로우 오류를 중앙에서 관리합니다.
• 오류 발생 시 슬랙·이메일로 알림을 자동 발송하는 패턴을 구축합니다.
• 재시도(Retry) 설정으로 일시적 네트워크 오류를 자동 복구합니다.

💡 에러 핸들링이 왜 중요한가

이 섹션에서는 자동화 워크플로우에서 에러 핸들링이 필수인 이유를 살펴보겠습니다.

자동화는 한 번 설정하면 사람의 개입 없이 반복 실행됩니다. 이것이 자동화의 강점이지만, 동시에 위험이기도 합니다. 외부 API가 다운되거나, 네트워크 연결이 끊기거나, 예상치 못한 데이터 형식이 들어오면 워크플로우가 오류로 종료됩니다. 에러 핸들링이 없으면 이 사실을 아무도 모른 채 업무가 누락됩니다. 예를 들어 매일 밤 고객에게 리포트를 자동 발송하는 워크플로우가 오류로 멈추면, 수백 명의 고객이 리포트를 받지 못하지만 관리자는 다음 날 아침까지 이를 알 수 없습니다.

프로덕션 수준의 자동화에서 에러 핸들링은 선택이 아닌 필수입니다. n8n은 에러를 처리하는 두 가지 접근 방식을 제공합니다. 첫 번째는 노드 레벨 에러 핸들링으로, 특정 노드에서 발생하는 오류를 해당 노드의 Error Output 핀으로 포착합니다. 두 번째는 워크플로우 레벨 에러 핸들링으로, Error Trigger 워크플로우를 통해 어떤 워크플로우에서든 오류가 나면 별도의 알림 워크플로우가 실행됩니다. 두 방식을 상황에 맞게 조합하는 것이 이상적입니다.

🔴 노드 레벨 에러 핸들링 — Error Output

이 섹션에서는 개별 노드의 오류를 Error Output 핀으로 처리하는 방법을 살펴보겠습니다.

n8n의 각 노드는 기본적으로 오류가 발생하면 워크플로우 실행 자체를 중단합니다. 그런데 일부 노드는 Error Output 핀을 활성화할 수 있습니다. 노드 설정에서 "Continue on Fail" 또는 "Error Output"을 켜면, 오류가 발생한 아이템이 에러 정보와 함께 Error Output 핀으로 나옵니다. 워크플로우가 멈추지 않고, 오류 아이템을 별도로 처리할 수 있습니다.

Error Output으로 나온 아이템에는 에러 정보가 포함됩니다. {{ $json.error.message }}로 에러 메시지에 접근할 수 있고, {{ $json.error.statusCode }}로 HTTP 오류 코드를 알 수 있습니다. 이 정보를 Set 노드로 가공해 슬랙이나 이메일 노드에 전달하면 맞춤형 오류 알림을 만들 수 있습니다.

실전 패턴으로 살펴보겠습니다. 외부 API를 호출하는 HTTP Request 노드에서 Error Output을 활성화합니다. Error Output 핀을 Slack 노드에 연결합니다. Slack 노드의 메시지로 ⚠️ API 오류 발생: {{ $json.error.message }} (코드: {{ $json.error.statusCode }})처럼 설정합니다. 이렇게 하면 API 오류가 날 때마다 슬랙 채널로 즉시 알림이 옵니다. 동시에 성공 경로는 정상적으로 계속 진행됩니다.

🔔 워크플로우 레벨 에러 핸들링 — Error Trigger

이 섹션에서는 전체 워크플로우의 오류를 중앙에서 관리하는 Error Trigger를 살펴보겠습니다.

Error Trigger는 다른 워크플로우에서 처리되지 않은 오류가 발생했을 때 실행되는 특수 트리거입니다. 이 트리거를 사용하면 오류 알림을 별도의 워크플로우로 분리해 중앙에서 관리할 수 있습니다. 모든 워크플로우에 개별적으로 오류 알림을 설정하는 것보다 훨씬 효율적입니다.

Error Trigger 워크플로우 설정 방법은 다음과 같습니다. 새 워크플로우를 만들고 트리거 노드로 Error Trigger를 선택합니다. 그러면 이 워크플로우는 다른 워크플로우에서 오류가 날 때마다 자동으로 실행됩니다. Error Trigger 노드의 출력에는 오류 정보가 담겨 있습니다.

필드	의미	표현식 예시
execution.id	실패한 실행 ID	{{ $json.execution.id }}
execution.url	n8n에서 실패 실행 직링크	{{ $json.execution.url }}
workflow.id	실패한 워크플로우 ID	{{ $json.workflow.id }}
workflow.name	실패한 워크플로우 이름	{{ $json.workflow.name }}
error.message	오류 메시지	{{ $json.error.message }}
error.stack	스택 트레이스	{{ $json.error.stack }}

Error Trigger 워크플로우를 활성화하면, n8n 설정(Settings → Error Workflow)에서 이 워크플로우를 지정해야 합니다. 지정 후에는 플랫폼 내 어떤 워크플로우가 오류로 종료되든 이 중앙 알림 워크플로우가 실행됩니다. 슬랙, 이메일, SMS 등 원하는 채널로 알림을 보내도록 구성하면 됩니다.

🔁 재시도(Retry) 설정

이 섹션에서는 일시적인 오류를 자동으로 재시도해 복구하는 방법을 살펴보겠습니다.

많은 오류는 일시적입니다. 네트워크 타임아웃, API 서버 순간 과부하, DNS 조회 지연 등은 잠시 기다렸다 다시 시도하면 성공하는 경우가 많습니다. n8n은 노드 레벨에서 Retry on Error 설정을 제공합니다. 노드 설정 패널에서 "On Error" 옵션을 "Retry" 또는 "Continue"로 바꾸면 됩니다.

Retry 설정에서는 최대 재시도 횟수와 재시도 간격을 지정합니다. 예를 들어 최대 3회 재시도, 1초 간격으로 설정하면, 오류가 나도 1초 후 재시도, 또 오류가 나면 1초 후 다시 재시도를 최대 3번 합니다. 3번 모두 실패하면 그때 진짜 오류로 처리합니다. 이 설정만으로도 일시적 네트워크 오류의 대부분을 자동 복구할 수 있습니다.

재시도 전략에서 중요한 개념이 지수 백오프(Exponential Backoff)입니다. 첫 재시도 1초 후, 두 번째 재시도 2초 후, 세 번째 재시도 4초 후처럼 재시도 간격을 점점 늘리는 방식입니다. n8n의 기본 Retry는 균등 간격이지만, Code 노드에서 직접 구현하거나 외부 큐 시스템(Upstash 등)을 연동해 지수 백오프를 적용할 수 있습니다.

⚠️ 에러 핸들링 설계 시 주의점

이 섹션에서는 에러 핸들링 구성 시 놓치기 쉬운 주의사항을 살펴보겠습니다.

첫 번째 주의점은 알림 폭풍(Alert Storm)입니다. 에러가 반복적으로 발생하면 슬랙에 같은 오류 알림이 수십, 수백 번 올 수 있습니다. 이를 방지하기 위해 Redis나 DB에 최근 알림 시각을 기록하고, 일정 시간 내 같은 오류에 대해 중복 알림을 보내지 않는 로직을 추가하는 것이 좋습니다.

두 번째 주의점은 민감 정보 노출입니다. 에러 메시지나 스택 트레이스에 API 키, 사용자 데이터 등 민감 정보가 포함될 수 있습니다. 슬랙이나 이메일로 오류 메시지를 그대로 보내면 민감 정보가 노출됩니다. 알림 전에 Set 노드로 메시지를 필터링하거나, 에러 메시지 앞부분만 잘라서 보내는 것이 안전합니다.

세 번째 주의점은 Error Trigger 워크플로우 자체의 오류입니다. Error Trigger 워크플로우에서 오류가 나면, 그 오류를 처리할 상위 핸들러가 없습니다. 이 워크플로우는 최대한 단순하게 유지하고, 외부 의존성을 최소화해 오류 가능성을 낮추는 것이 중요합니다.

📝 핵심 요약

방식	적용 범위	특징
Error Output 핀	특정 노드	해당 노드 오류만 처리, 워크플로우 계속 진행
Error Trigger 워크플로우	전체 플랫폼	어떤 워크플로우 오류든 중앙 알림, 설정 필요
Retry on Error	특정 노드	일시적 오류 자동 복구, 횟수·간격 설정

다음 강에서는 Webhook 트리거를 살펴봅니다. 외부 서비스(GitHub, Stripe, 카카오 등)가 이벤트를 발생시켰을 때 n8n 워크플로우를 즉시 실행시키는 방법을 배우면, 진정한 이벤트 기반 자동화를 구현할 수 있습니다.