6편에서 “Import 가능한 워크플로우 JSON”을 뽑아내는 템플릿을 만들었습니다. 이번 편은 그 다음 단계입니다. 운영에서 워크플로우는 성공보다 실패를 어떻게 다루는지가 더 중요합니다. 그래서 이번 편의 목표는 “에러 처리/재시도/알림”을 표준 패턴으로 만들어, 어떤 워크플로우든 똑같은 방식으로 운영 가능하게 만드는 것입니다.

0) 표준 패턴 개요: “본문 워크플로우”와 “에러 워크플로우”를 분리

n8n은 “에러 워크플로우(Error workflow)”를 별도로 만들고, 각 워크플로우의 설정에서 “이 워크플로우가 실패할 때 실행할 에러 워크플로우”를 지정하는 방식을 제공합니다. (Error handling, Workflow settings)

1) 1분 만에 “에러 워크플로우(표준 핸들러)” 만들기

Step 1) 새 워크플로우 생성 → 첫 노드는 Error Trigger

n8n 문서의 Error handling 가이드는 “새 워크플로우를 만들고, 첫 노드를 Error Trigger로 둔다”를 기본 절차로 안내합니다. (Error handling)

Step 2) 에러 정보를 “알림”으로 보내기

에러 워크플로우는 실패를 감지한 뒤 “사람이 볼 수 있는 곳”으로 보내야 의미가 있습니다. 여기서는 예시로 Slack/Email 같은 알림을 권장하되, 도구 선택은 팀 환경에 맞추면 됩니다. n8n의 레벨2 코스에서도 “Error Trigger 기반 에러 워크플로우를 만들어 알림 노드를 붙여라”는 형태로 안내합니다. (Dealing with errors in workflows)

2) 본문 워크플로우에 “에러 워크플로우” 연결하기

n8n 공식 문서의 Error handling 절차는 본문 워크플로우에서 Options(설정) → Settings → Error workflow로 들어가 방금 만든 에러 워크플로우를 선택하라고 안내합니다. (Error handling)

동일 내용이 Workflow settings 문서에도 “Error Workflow (to notify when this one errors)” 항목으로 정리돼 있습니다. (Workflow settings)

3) 실패를 “의도적으로” 만들기: Stop And Error로 검증 실패를 표준화

운영형 워크플로우에서는 “데이터가 이상하면 그냥 종료”가 아니라, 명확한 에러로 실패 처리를 해야 에러 워크플로우가 잡아서 알림을 보낼 수 있습니다. 이때 n8n의 Stop And Error 노드는 의도적으로 워크플로우를 오류로 종료시키는 용도로 쓰며, 문서에서도 Error Trigger(에러 워크플로우)와 함께 사용하라고 안내합니다. (Stop And Error)

4) 재시도(Retry) 전략: 자동 재시도 vs 운영 재시도

4-1) 운영 재시도: Executions에서 “Retry failed workflows”

실패가 발생했을 때, n8n은 Executions 목록에서 실패 실행을 재시도할 수 있습니다. 문서에서는 “Executions list에서 Retry(Refresh 아이콘)로 재시도”하며, “현재 저장된 워크플로우로 재시도” 같은 옵션도 제공한다고 안내합니다. (Retry failed workflows)

4-2) 자동 재시도는 ‘원인별’로 다르게 접근

모든 실패를 무조건 재시도하면 더 큰 사고가 납니다. 대표적으로 HTTP 429(레이트 리밋)처럼 “잠깐 기다리면 해결되는 실패”는 재시도가 의미가 있지만, 입력 데이터가 잘못된 실패는 재시도해도 똑같이 실패합니다. n8n 문서는 HTTP Request 노드에서 429(too many requests) 같은 레이트 리밋 이슈와 해결 접근을 안내합니다. (HTTP Request common issues, Handling API rate limits)

5) 안티그래비티 프롬프트 템플릿 2: “표준 에러 핸들러 + 본문 JSON”을 한 번에

이제부터가 진짜 핵심입니다. 안티그래비티에게 “에러 워크플로우까지 포함한 표준 패턴”을 만들게 하면, 이후 어떤 자동화든 같은 방식으로 확장할 수 있습니다. (5편에서 Rules로 “출력 포맷/보안/검증”을 이미 고정했다는 전제)

템플릿 A) 에러 워크플로우 JSON 생성

너는 n8n 워크플로우 설계자야.
"표준 에러 워크플로우"를 만들어줘.

요구:
- 첫 노드는 Error Trigger
- 실패한 워크플로우 이름/실패 노드/에러 메시지를 추출해 알림 메시지로 만든다
- 알림은 Slack(또는 Email)로 보내는 형태로 구성하되, Credential 값은 절대 넣지 말고 이름만 사용
- 민감 데이터가 섞일 수 있으니 입력/에러 내용은 마스킹 전제를 안내해줘

출력 형식(반드시):
1) Import 가능한 워크플로우 JSON (코드블록)
2) 노드별 역할 1~2줄
3) 사용자가 채워야 할 Credential/환경변수 목록
4) 본문 워크플로우에서 "Error workflow"로 연결하는 방법(설정 경로)까지

템플릿 B) 본문 워크플로우 JSON 생성(Stop And Error 포함)

너는 n8n 워크플로우 설계자야.
아래 본문 워크플로우를 Import 가능한 JSON으로 만들어줘.
그리고 "입력 검증 실패"는 Stop And Error로 명확히 실패 처리해줘(에러 워크플로우가 잡을 수 있게).

[자동화 목표]
- Webhook(POST)로 문의 JSON 수신
- email 형식 검사
- 정상: ok:true 응답
- 비정상: Stop And Error로 실패 처리(에러 메시지 포함)

[입력 JSON 샘플]
{
  "name": "홍길동",
  "email": "[email protected]",
  "message": "테스트",
  "createdAt": "2026-03-10T09:00:00+09:00"
}

출력 형식(반드시):
1) Import 가능한 워크플로우 JSON (코드블록)
2) 노드별 역할 설명
3) 로컬 테스트(Execute Workflow → Test URL → curl)
4) 에러 워크플로우 연결 위치(Workflow Settings의 Error workflow 설명)

6) 운영 체크리스트(최소)

1. 에러 워크플로우(첫 노드 Error Trigger)를 만들었다. (Error Trigger)
2. 본문 워크플로우 Settings에서 Error workflow로 연결했다. (Error handling)
3. 입력 검증 실패는 Stop And Error로 “실패”로 처리한다. (Stop And Error)
4. 실패가 쌓이면 Executions에서 Retry 기준을 정해 운영한다. (Retry failed workflows)
5. 429 같은 레이트 리밋 실패는 원인에 맞게 대응한다. (Handling API rate limits)

다음 편 예고

8편에서는 “협업/외주” 관점으로 갑니다. 안티그래비티의 Rules / Workflows로 산출물 포맷을 강제하고, “키/개인정보를 절대 출력하지 말 것” 같은 보안 규칙을 팀 단위로 고정하는 방법을 다룹니다. (Rules / Workflows)