n8n 워크플로우가 조용히 죽지 않게 — Error Trigger로 실패를 슬랙으로 받는 에러 알림 만들기

Error Trigger 노드로 시작하는 워크플로우 하나를 만들어 다른 워크플로우의 Settings에 등록해 두면, 그 워크플로우들이 실패할 때마다 어떤 워크플로우의 어느 노드가 무슨 에러로 멈췄는지가 실행 화면 링크와 함께 슬랙으로 옵니다. 노드는 세 개면 되고 설정할 파라미터도 거의 없지만, 이 워크플로우가 있느냐 없느냐가 "돌려본 자동화"와 "운영하는 자동화"를 가릅니다.

이 워크플로우 하나로 보여줄 수 있는 것

재고 알림 편의 마지막에서 "워크플로우가 실패했을 때 조용히 멈추지 않도록 Error Trigger를 붙이는 편"을 예고했습니다. 이 글이 그 편입니다. 만드는 데 10분도 안 걸리지만, 포트폴리오에서는 이 워크플로우가 가장 짧은 문장으로 가장 큰 차이를 냅니다. "제 워크플로우들은 전부 에러 워크플로우에 물려 있어서, 실패하면 슬랙으로 바로 압니다."

이 한 문장 안에 들어가는 역량은 세 가지입니다.

• 실패를 전제로 한 설계 — 자동화는 언젠가 실패한다는 걸 알고, 실패를 감지하는 경로를 미리 깔아본 경험
• 워크플로우 간 연결 — 노드를 잇는 게 아니라 워크플로우 설정으로 워크플로우끼리 묶는 n8n의 또 다른 연결 방식을 써본 경험
• 에러 페이로드 다루기 — n8n이 실패 시점에 넘겨주는 데이터 구조를 읽고, 사람이 바로 행동할 수 있는 메시지로 바꿔본 경험

재고 알림이나 날씨 알림은 "잘 돌아갈 때" 무엇을 하는지 보여줍니다. 이 워크플로우는 "안 돌아갈 때" 무엇이 일어나는지를 보여줍니다. 면접관이 자동화 경험자에게 정말 묻고 싶은 건 후자입니다.

배경 — Active를 켠 워크플로우는 실패해도 아무도 모릅니다

워크플로우를 Active로 켜고 나면 그때부터는 아무도 캔버스를 보고 있지 않습니다. 구글시트 인증이 만료되거나, 외부 API가 403을 돌려주거나, 시트 컬럼명이 바뀌어서 표현식이 깨지면 실행은 그 자리에서 실패로 끝납니다. n8n 실행 목록에는 빨간 줄이 남지만, 실행 목록을 매일 열어보는 사람은 없습니다. 재고 알림이 3주째 안 오고 있었다는 걸 품절이 나고 나서야 알게 되는 식입니다.

이 글의 원본은 데이터팝콘 n8n 인스턴스에서 실제로 켜져 있는 에러 워크플로우입니다. 2025년 10월에 만들어졌고, 워크플로우 export를 훑어보면 408개 워크플로우 중 8개가 Settings에서 이 워크플로우를 Error workflow로 지정해 둔 상태입니다. 이 시리즈에서 앞으로 다룰 급식 API 페이지네이션, Gmail 자동 분류, 슬랙 대화 아카이브 봇의 원본도 그 8개에 들어 있습니다. 즉 여러 워크플로우가 에러 워크플로우 하나를 공유하는 구조이고, 이게 이 패턴의 핵심입니다. 설치나 기본 노드 설명은 n8n으로 반복업무 자동화 포트폴리오 만들기에 있으니 여기서는 에러 워크플로우 자체만 다룹니다.

구조 — Trigger / Task / Target

• Trigger — 이 워크플로우를 Error workflow로 등록한 다른 워크플로우가 실패했을 때
• Task — 에러 페이로드에서 워크플로우 이름·실패 노드·에러 메시지·실행 URL을 꺼내 메시지 한 줄로 조립
• Target — 슬랙 채널. 원본에는 같은 메시지를 디스코드 웹훅과 카카오톡으로도 보내는 분기가 붙어 있습니다

따라 만들 때는 Error Trigger → Set → Slack 세 노드면 충분합니다. 디스코드와 카카오톡 분기는 아래에서 따로 설명합니다.

만들기

1. Error Trigger — 설정할 게 없는 노드

새 워크플로우를 만들고 첫 노드로 Error Trigger를 넣습니다. 원본 JSON에서 이 노드의 parameters는 빈 객체입니다. 이 노드의 역할은 "나를 에러 워크플로우로 등록한 워크플로우가 실패했다"는 신호를 받는 것뿐이고, 무엇을 받을지는 n8n이 정해서 넘겨줍니다.

넘어오는 데이터는 공식 문서에 예시가 있는데, 실행 중 에러가 났을 때의 구조는 이렇습니다.

{
  "execution": {
    "id": "231",
    "url": "https://n8n.example.com/execution/231",
    "retryOf": "34",
    "error": {
      "message": "Example Error Message",
      "stack": "Stacktrace"
    },
    "lastNodeExecuted": "Node With Error",
    "mode": "manual"
  },
  "workflow": {
    "id": "1",
    "name": "Example Workflow"
  }
}

알림에 쓸 만한 건 네 개입니다. workflow.name(어느 워크플로우인지), execution.lastNodeExecuted(어느 노드에서 멈췄는지), execution.error.message(왜 멈췄는지), execution.url(클릭하면 그 실행 화면으로 가는 링크). 트리거 노드 자체가 활성화에 실패한 경우에는 execution 대신 trigger.error와 trigger.mode가 오는 다른 모양의 페이로드가 넘어옵니다. 원본 워크플로우는 이 경우를 따로 처리하지 않아서, 트리거 활성화 실패 시에는 메시지의 해당 자리가 비어서 올 수 있습니다.

2. Set — 페이로드를 메시지 한 줄로

Set 노드(지금 이름은 Edit Fields)에 String 필드 message 하나를 만들고 값에 아래 표현식을 넣습니다. 원본 그대로입니다.

:warning: [prod] workflow `{{$json["workflow"]["name"]}}` failed to run! <{{ $json.execution.url }}|execution>

error message from node: {{ $json.execution.lastNodeExecuted }}
 {{ $json.execution.error.message }}

두 군데를 눈여겨볼 만합니다. execution.url을 꺾쇠괄호 안에 |execution과 함께 넣은 부분은 슬랙 mrkdwn의 링크 문법으로, 긴 URL 대신 "execution"이라는 글자에 링크가 걸립니다. 알림을 받은 사람이 그 글자를 누르면 바로 실패한 실행 화면이 열리니 "어디서 뭐가 터졌지"를 n8n에서 다시 찾을 필요가 없습니다. 앞의 [prod]는 n8n 인스턴스가 여러 개일 때 어느 인스턴스에서 온 알림인지 구분하는 접두어라, 하나만 쓴다면 지워도 됩니다.

원본은 Set 노드 1버전이라 "Keep Only Set" 옵션이 켜져 있는데, 지금의 Edit Fields 노드에서는 Include Other Input Fields를 끄면 같은 뜻입니다. 이 옵션 때문에 이 노드를 지나면 아이템에는 message 필드만 남고, 원래 페이로드는 사라집니다. 뒤에서 이게 한 번 문제가 됩니다.

3. Slack — 알림 전용 채널로

Slack 노드(Send a message)에서 알림 전용 채널을 하나 만들어 고르고 Text에 {{ $json.message }}를 넣습니다. 원본 캔버스의 스티키 노트에 적힌 Setup 항목도 두 줄뿐입니다. 첫째, Slack credential을 붙일 것. 둘째, 이 에러 워크플로우를 다른 워크플로우에 등록할 것.

4. 다른 워크플로우의 Settings에 등록하기

여기가 이 패턴의 본체입니다. 에러 워크플로우는 저장만 해두고, 감시하고 싶은 워크플로우를 열어 Options > Settings로 들어가 Error workflow 항목에서 방금 만든 워크플로우를 고르고 Save합니다. 이걸 워크플로우마다 반복합니다. 공식 문서가 말하듯 같은 에러 워크플로우를 여러 워크플로우에 쓸 수 있고, 원본이 8개 워크플로우에 물려 있는 게 그 예입니다.

n8n 공식 동작 두 가지를 알아두면 헷갈릴 일이 줄어듭니다. 첫째, Error Trigger로 시작하는 워크플로우는 publish(활성화)하지 않아도 됩니다. 등록만 되어 있으면 실패 시점에 n8n이 실행해 줍니다. 둘째, 에러 워크플로우는 자동 실행이 실패했을 때만 돕니다. 캔버스에서 Execute workflow 버튼으로 수동 실행한 워크플로우가 실패해도 알림은 오지 않습니다. "등록했는데 왜 슬랙에 아무것도 안 오지"의 대부분이 이 경우입니다.

5. 테스트 — 일부러 실패하는 워크플로우 만들기

수동 실행으로는 테스트가 안 되니 진짜 실패를 하나 만들어야 합니다. Schedule Trigger(몇 분 간격) 뒤에 Stop and Error 노드를 붙인 두 노드짜리 워크플로우를 만들고, Settings > Error workflow에 에러 워크플로우를 등록한 뒤 Active를 켭니다. Stop and Error는 실행을 강제로 실패시켜 에러 워크플로우를 부르는 노드라서, 다음 주기에 슬랙에 첫 알림이 옵니다. 메시지에 워크플로우 이름과 "Stop and Error"가 실패 노드로 찍혀 있으면 성공입니다. 확인이 끝나면 테스트 워크플로우는 꼭 비활성화하세요. 안 그러면 몇 분마다 알림이 계속 옵니다.

원본 캔버스에 남아 있는 흔적 — 채널 세 개와 지운 자국

이 워크플로우에는 실행 결과를 담은 스티키 노트가 없습니다. 대신 캔버스 자체에 만든 사람의 결정이 몇 개 남아 있어서 그걸 옮깁니다.

첫째, 스티키 노트가 영어이고 JSON 메타에 템플릿 credential 설정 흔적이 있는 걸 보면, n8n 템플릿에서 가져와 시작한 뒤 데이터팝콘 쪽에서 디스코드와 카카오톡 분기를 덧붙인 것으로 보입니다. 템플릿을 그대로 쓰지 않고 자기 채널에 맞게 늘린 흔적입니다. 스티키 노트에 적힌 공식 문서 링크는 지금은 주소가 바뀌어 열리지 않는데, 이 글의 링크는 현재 주소로 바꿔 두었습니다.

둘째, Set 노드에서 세 갈래로 갈라집니다. 디스코드 분기는 Discord 노드를 웹훅 인증으로 두고 Content에 같은 {{ $json.message }}를 넣은 것뿐이라 슬랙과 만드는 법이 같습니다. 카카오톡 분기는 HTTP Request 두 개로, 첫 노드가 카카오 OAuth 토큰 엔드포인트에서 refresh token으로 access token을 새로 받고, 둘째 노드가 카카오톡 "나에게 보내기" API에 피드형 메시지를 보냅니다. 이 분기에서 배울 점은 표현식 쪽에 있습니다. Set 노드가 message만 남기고 페이로드를 버렸기 때문에, 카카오 메시지 본문은 $json이 아니라 {{ $('On Error').item.json.workflow.name }}처럼 Error Trigger 노드의 출력으로 거슬러 올라가서 값을 꺼냅니다. 중간 노드가 데이터를 줄여버렸을 때 앞 노드를 이름으로 참조하는 방법인데, 이 워크플로우가 그 쓰임새를 보여주는 예입니다. 다만 이 분기는 토큰 갱신을 워크플로우 안에서 직접 처리하는 구조라, 따라 만든다면 client id와 토큰은 HTTP 노드 파라미터가 아니라 credential로 옮기길 권합니다.

셋째, 카카오 분기의 복사본 한 쌍과 Webhook 노드 하나가 아무 데도 연결되지 않은 채 떠 있습니다. 복사본은 client id와 토큰 자리가 자리표시자로 바뀌어 있어서 공유용으로 정리하다 만 것으로 보이고, Webhook 노드는 테스트 흔적입니다. 연결 안 된 노드는 실행에 영향이 없지만, 포트폴리오로 내놓을 캔버스라면 지우는 게 맞습니다.

한계 — 알림이 온다고 다 해결된 건 아닙니다

• 에러 워크플로우 자체의 실패 — 슬랙 credential이 만료되면 에러 워크플로우가 실패하고, 그 실패를 알려줄 곳은 없습니다. 원본이 디스코드와 카카오톡까지 세 채널로 보내는 건 이 문제에 대한 답이기도 합니다. 최소 두 채널을 두면 하나가 죽어도 알림은 옵니다.
• 트리거 활성화 실패는 메시지가 빕니다 — 위에서 말한 trigger.error 모양의 페이로드는 원본 표현식이 다루지 않습니다. {{ $json.execution ? $json.execution.error.message : $json.trigger.error.message }}처럼 둘 다 받게 고치면 됩니다.
• 같은 에러가 반복되면 알림도 반복됩니다 — 매시간 도는 워크플로우의 인증이 만료되면 매시간 같은 알림이 옵니다. 알림을 줄이려면 에러 워크플로우 쪽에서 워크플로우 이름과 에러 메시지를 시트에 적어두고 같은 조합이면 건너뛰는 로직이 필요합니다.
• 성공은 알 수 없습니다 — 이 워크플로우는 실패만 잡습니다. "오늘 아침 알림이 안 왔는데 실패한 건지 보낼 게 없었던 건지"는 구분해 주지 않습니다. 재고 알림 편의 Filter가 0건이면 조용히 끝나는 성질과 겹치는 부분이라, 정말 운영하려면 "실행은 됐고 보낼 게 없었다"는 신호를 따로 두는 편이 낫습니다.

포트폴리오·면접 포인트

포트폴리오에는 세 노드짜리 에러 워크플로우 캔버스, 다른 워크플로우의 Settings에서 Error workflow가 선택된 화면, 그리고 Stop and Error로 만든 실패 알림이 슬랙에 도착한 캡처 세 장이면 됩니다. 앞선 편에서 만든 재고 알림이나 날씨 알림이 있다면 그 워크플로우들을 이 에러 워크플로우에 등록해 두고 "포트폴리오의 모든 워크플로우가 하나의 에러 워크플로우에 물려 있다"고 쓰면, 개별 실습이 아니라 운영 체계로 읽힙니다.

응용은 두 방향이 있습니다. 하나는 에러 메시지에 따라 채널을 나누는 것입니다. 인증 만료면 담당자 DM, 외부 API 실패면 공용 채널처럼 IF 노드 하나로 갈라집니다. 다른 하나는 위 한계의 반복 알림을 시트로 억제하는 버전인데, "실패를 감지한다"에서 "실패를 관리한다"로 한 단계 올라가는 개선이라 면접에서 설명할 거리가 됩니다.

면접에서 "수동으로 실행했을 때는 왜 알림이 안 왔나요"라는 질문이 오면, 에러 워크플로우는 자동 실행이 실패했을 때만 돌고 수동 실행은 대상이 아니라는 n8n의 동작을 말하고, 그래서 Stop and Error로 실제 실패를 만들어 검증했다고 답하면 됩니다. 공식 동작을 알고 그에 맞는 테스트 방법까지 설계했다는 답이라서, 노드를 붙여봤다는 답과는 무게가 다릅니다.

다음 액션

여기까지가 "스케줄로 돌고, 실패하면 알려주는" 자동화의 기본 세트입니다. 다음 편은 방향을 바꿔서 밖에서 들어오는 요청에 반응하는 워크플로우로 갑니다. NFC 태그를 폰에 찍으면 웹훅이 호출되고 명언이 화면에 뜨는 흐름인데, Webhook 노드와 Respond to Webhook 노드로 n8n이 작은 웹 서버처럼 동작하는 걸 처음 보게 됩니다. 그 웹훅 워크플로우도 만들자마자 이 편의 에러 워크플로우에 등록해 두세요.