n8n 자동화의 함정과 예외 처리(Error Handling)의 필요성
n8n을 활용하여 복잡한 데이터 파이프라인이나 외부 API 연동 워크플로우를 구축하면, 수십 개의 노드가 거미줄처럼 얽혀 백그라운드에서 24시간 동작하게 됩니다. 초기 테스트 단계에서는 모든 것이 완벽하게 돌아가는 것처럼 보이지만, 실제 운영 서버에 배포하고 나면 통제할 수 없는 다양한 외부 변수에 의해 시스템이 중단되는 사태가 빈번하게 발생합니다.
예를 들어, 데이터를 긁어오려는 타겟 웹사이트의 서버가 일시적으로 다운되거나, 텔레그램(Telegram) API의 일일 호출 한도를 초과하거나, 데이터베이스(Supabase)에 삽입하려는 데이터의 타입이 일치하지 않는 등 사소한 오류 하나만 발생해도 워크플로우의 실행은 그 즉시(Crash) 멈춰버립니다.
관리자가 대시보드에 매일 접속하여 실패한 내역(Executions)을 확인하기 전까지 시스템은 죽은 채로 방치되며, 이는 비즈니스 데이터 누락이라는 치명적인 결과로 이어집니다. 이러한 ‘조용한 실패(Silent Failure)’를 원천적으로 방지하고, 에러가 발생했을 때 시스템이 스스로 이를 감지하여 관리자에게 알림을 보내거나 예비 경로(Fallback)를 실행하게 만드는 전역 예외 처리 메커니즘이 바로 n8n의 ‘Error Trigger’ 노드입니다.
Error Trigger 노드의 작동 원리와 설계 시 겪는 치명적 오류
Error Trigger 노드는 일반적인 노드들처럼 기존 워크플로우의 중간에 끼워 넣는 것이 아닙니다. 오직 에러 감지만을 전담하는 완전히 새롭고 독립적인 ‘관제 워크플로우’를 생성한 뒤, 그 최상단에 Error Trigger 노드를 배치하는 구조를 가집니다. 이 관제탑은 다른 모든 워크플로우들의 실행 상태를 24시간 감시합니다.
이론은 간단하지만, 실제 이 무중단 관제망을 설계하고 연동하는 과정에서 초보자들이 흔히 저지르는 논리적 결함과 시스템 오작동 사례들이 존재합니다.
1. ‘Continue On Fail’ 옵션 남용에 따른 에러 감지 실패
가장 빈번한 실수는 개별 노드의 설정(Settings) 탭에 있는 ‘Continue On Fail(실패 시 계속 진행)’ 옵션을 남용하는 것입니다. API 통신이 불안정할 때 워크플로우가 멈추는 것을 막기 위해 이 옵션을 켜두는 경우가 많습니다.
하지만 이 옵션이 활성화된 노드에서 에러가 발생하면, n8n 시스템은 이를 ‘정상적으로 처리된 예외 상황’으로 간주해버립니다. 결과적으로 전체 워크플로우의 최종 상태는 ‘Success(성공)’로 기록되며, 최상위 관제탑인 Error Trigger 노드는 에러가 발생했다는 사실 자체를 전달받지 못하게 됩니다. 에러는 덮어지고 잘못된 NULL 데이터가 데이터베이스에 계속 쌓이는 심각한 데이터 오염을 유발하므로, 에러 관제망을 구축할 때는 반드시 모든 노드의 Continue On Fail 옵션을 해제하여 시스템이 명확하게 ‘Error’ 상태를 뱉어내도록 강제해야 합니다.
2. 에러 워크플로우 내의 재귀적 무한 루프(Infinite Loop) 현상
두 번째로 겪는 치명적인 시스템 마비는 에러를 처리하는 워크플로우 자체가 또 다른 에러를 발생시킬 때 일어납니다. Error Trigger 노드가 작동하여 텔레그램으로 경고 메시지를 발송하려 했는데, 하필 텔레그램 API 토큰이 만료되었거나 네트워크가 단절되어 발송 노드에서 에러가 터졌다고 가정해 봅시다.
이때 Error Trigger 노드의 감시 대상을 ‘All Workflows(모든 워크플로우)’로 설정해 두었다면, 텔레그램 발송 에러가 다시 Error Trigger를 깨우고, 그 트리거가 다시 텔레그램 노드를 실행시키는 끔찍한 무한 루프(Infinite Loop)에 빠지게 됩니다. 단 몇 분 만에 수천 번의 실행이 반복되며 NAS의 CPU와 메모리를 100% 점유하여 서버 전체를 다운시킵니다. 이를 방지하기 위해 Error Trigger 노드의 설정에서 ‘에러 감시 대상 워크플로우 목록’에 자기 자신(관제 워크플로우)은 명시적으로 제외(Exclude)하는 안전장치가 필수적입니다.
3. 에러 페이로드(Payload) 파싱 실패와 추상적 알림
Error Trigger 노드가 성공적으로 실행되었음에도, 텔레그램 메시지 내용이 텅 비어있거나 “[Object object]” 형태로 깨져서 전송되는 데이터 직렬화 오류도 자주 발생합니다. 에러가 발생하면 n8n은 방대한 구조의 JSON 데이터를 내뿜습니다. 여기에서 내가 정확히 어떤 워크플로우의 어느 노드에서, 어떤 사유로 에러가 났는지 핵심 정보만 발췌(Parsing)하는 표현식(Expression) 문법의 이해가 부족하기 때문입니다.
견고한 자가 복구 파이프라인의 완성
페이로드 파싱 오류를 해결하려면 Telegram 노드의 텍스트 입력창에 정확한 JSON 경로를 매핑해야 합니다. 오류가 발생한 워크플로우 이름은 `{{ $json.workflow.name }}`, 오류를 일으킨 특정 노드의 이름은 `{{ $json.execution.lastNodeExecuted }}`, 그리고 가장 중요한 핵심 에러 메시지는 `{{ $json.execution.error.message }}`라는 고정된 변수명으로 추출할 수 있습니다.
이렇게 추출된 직관적인 에러 트레이스백(Traceback)을 텔레그램으로 즉시 받아보게 되면, 관리자는 모바일 환경에서도 서버의 어느 지점 통신망이 끊어졌는지 단번에 파악할 수 있습니다.
더 나아가, Error Trigger 뒤에 단순히 알림 노드만 붙이는 것이 아니라, ‘Switch’ 노드를 활용하여 에러의 종류를 판별하게 할 수 있습니다. API 타임아웃 에러라면 10분 뒤에 대상 워크플로우를 강제로 재실행(Retry)시키고, 데이터 구조 에러라면 백업용 로컬 파일에 임시 저장하도록 분기 로직을 짜넣으면 비로소 관리자의 개입 없이 시스템이 스스로 판단하고 대처하는 ‘자가 복구(Self-healing) 아키텍처’가 완성됩니다. 이는 취미 수준의 자동화를 기업용 인프라 급으로 끌어올리는 가장 중요한 서버 관리의 이정표입니다.
