n8n 자동화의 실패를 이메일로 받으려면 Error Trigger로 시작하는 별도 워크플로를 만들고 원본 작업의 Error Workflow로 지정합니다. 이 글은 이미 n8n을 사용하는 독자가 알림 연결부터 의도적인 실패 테스트까지 진행하는 절차를 다룹니다. 기능 설명은 2026년 9월 7일 확인한 n8n 공식 GitHub 문서를 기준으로 합니다.
n8n 오류 알림은 어디에 연결하나요?
업무를 처리하는 원본과 실패를 전달하는 알림을 두 워크플로로 나눕니다. Error Trigger 공식 문서에 따르면 연결된 워크플로가 자동 실행 중 실패하면 오류 정보가 전달됩니다. Error Trigger가 들어간 알림 워크플로 자체는 별도로 Publish할 필요가 없습니다.
| 구분 | 구성 | 할 일 |
|---|---|---|
| 업무 워크플로 | 기존 트리거와 업무 노드 | 설정에서 오류 알림 대상을 지정합니다 |
| 알림 워크플로 | Error Trigger → Send Email | 실패 정보를 받아 본인에게 보냅니다 |
| 테스트 워크플로 | Schedule Trigger → Stop And Error | 업무 데이터 없이 실패 감지를 확인합니다 |
Error Trigger 뒤에 이메일 알림을 붙입니다
사용 가능한 SMTP 계정과 발신 주소, 테스트를 받을 본인 메일 주소를 준비합니다. Send Email 공식 문서는 SMTP 서버를 통한 발송과 Text 형식을 지원한다고 안내합니다. 아래는 처음 연결할 때 사용할 최소 설정입니다.
- 새 워크플로 이름을 ‘공통 오류 알림’으로 정하고 첫 노드로 Error Trigger를 추가합니다.
- 바로 뒤에 Send Email을 연결하고 사용할 SMTP 자격 증명을 선택합니다.
- Operation은 Send, From Email은 허용된 발신 주소, To Email은 본인 주소로 지정합니다.
- Email Format은 Text, 제목은 ‘n8n 자동화 실패’로 설정합니다. 본문은 우선 ‘n8n 실행 기록에서 실패한 작업을 확인해 주세요.’로 입력하고 저장합니다.
처음에는 고정 문구로 수신 여부를 확인합니다. 실패 정보가 들어온 뒤에는 Error Trigger의 출력에서 워크플로 이름을 찾아 메일 본문에 매핑합니다. 운영용 알림에는 작업 이름과 확인할 실행 위치를 남기되, 고객 입력이나 오류 원문 전체를 그대로 보내는 구성은 피합니다.
원본 워크플로에서 Error Workflow를 지정합니다
알림 워크플로를 만들기만 해서는 원본 작업과 연결되지 않습니다. 원본을 열고 우상단 점 3개 메뉴에서 Settings를 선택합니다. Error Workflow 항목에 저장한 ‘공통 오류 알림’을 지정하고 설정을 저장합니다. 정확한 항목 이름은 워크플로 설정 공식 문서에서 확인할 수 있습니다.
처음 검증하는 테스트 워크플로에서는 Save failed production executions를 저장하도록 설정합니다. 이 항목은 자동 실행 실패 기록을 남기는 설정입니다. 민감한 업무 원본에 적용할 때는 팀의 실행 데이터 보관 기준에 맞춥니다.
수동 실행에서는 왜 알림이 오지 않나요?
Error Trigger는 원본 워크플로를 에디터에서 수동 실행하다 실패한 경우에는 작동하지 않습니다. 따라서 수동 실행 버튼을 눌러 오류만 확인하는 것으로 연결 검증을 끝내면 안 됩니다. 별도 테스트 워크플로를 만들어 자동 실행에서 실패가 발생하도록 구성합니다.
- Schedule Trigger와 Stop And Error만 연결한 ‘오류 알림 테스트’ 워크플로를 만듭니다.
- Schedule Trigger의 Trigger Interval을 Minutes, Minutes Between Triggers를 5로 설정합니다. 5분은 이 실습에서 정한 값입니다.
- Stop And Error의 Error Type을 Error Message로 정하고 ‘알림 연결 확인용 실패’를 입력합니다.
- Settings에서 Error Workflow를 ‘공통 오류 알림’으로 지정하고 실패 기록을 저장하도록 설정합니다. 테스트 워크플로를 저장한 뒤 Publish합니다.
- 예약 실행을 기다린 뒤 테스트 워크플로의 실패 기록, 알림 워크플로의 실행 기록, 실제 메일 수신을 차례로 확인합니다. 확인을 마치면 테스트 워크플로를 Unpublish해 반복 실행을 끕니다.
Schedule Trigger 문서는 예약 실행에 저장과 Publish가 필요하다고 설명합니다. Stop And Error 문서는 사용자 지정 오류 메시지로 실행을 실패시키는 기능을 안내합니다. 이 두 노드를 조합하면 실제 고객 메일이나 외부 업무 데이터를 건드리지 않고 실패 알림을 점검할 수 있습니다.
알림이 없을 때 무엇부터 확인하나요?
다음 표는 실패 위치를 좁히기 위한 점검 순서입니다. 원본 작업의 실행 기록부터 확인하고 알림 노드로 이동합니다. 메일이 없다는 사실만으로 Error Trigger 설정이 잘못됐다고 단정하지 않습니다.
| 관찰한 상태 | 다음 확인 |
|---|---|
| 테스트 워크플로가 자동 실행되지 않았습니다 | 테스트 워크플로의 Publish 상태와 예약 간격을 확인합니다 |
| 실패 기록은 있지만 알림 워크플로가 실행되지 않았습니다 | 수동 실행이었는지, 원본의 Error Workflow 지정이 저장됐는지 확인합니다 |
| 알림 워크플로에서 Send Email이 실패했습니다 | SMTP 자격 증명과 허용된 발신 주소를 확인합니다 |
| Send Email은 성공했지만 메일이 보이지 않습니다 | 수신 주소와 스팸함을 확인합니다 |
실패 알림 구성에 자동 재실행은 넣지 않았습니다. 실무 적용 시에는 담당자가 실패 기록과 이미 처리된 항목을 확인한 뒤 재실행 여부를 결정하도록 정합니다. 오늘은 결과를 매번 수동 확인하던 업무 한 개에 알림을 연결하고, 본인 메일로 실패 한 건이 도착하는지 확인해 보세요.
댓글 남기기