테스트할 땐 분명히 잘 돌았습니다. 노드를 하나씩 실행해 보고, 마지막에 초록불이 뜨는 것까지 확인하고 워크플로우를 켜뒀죠. 그런데 며칠 뒤 결과물이 쌓이는 시트를 열어보니 이틀치가 비어 있습니다. 에러 메시지도, 알림도 없었습니다. n8n 워크플로우를 조금이라도 실전에 써 본 사람이라면 한 번쯤 겪는 상황입니다. 문제는 자동화가 멈췄다는 사실이 아니라, 멈춘 걸 아무도 몰랐다는 데 있습니다.
이 글에서는 잘 돌던 자동화가 왜 조용히 멈추는지, 그리고 n8n이 기본으로 제공하는 세 가지 장치로 어떻게 자동 복구와 알림을 붙이는지 정리합니다. 새로 배워야 할 노드는 거의 없습니다. 이미 있는 설정을 켜기만 하면 됩니다. (본 글은 작성 시점 기준 n8n 최신 버전을 기준으로 합니다.)
왜 잘 돌던 워크플로우가 소리 없이 멈출까
가장 큰 이유는 실패의 기본 동작이 '조용히 멈추기'이기 때문입니다. n8n에서 노드 하나가 에러를 내면 워크플로우는 그 지점에서 실행을 중단합니다. 그런데 이 중단은 화면 어딘가에 경고를 띄워 주는 게 아니라, 실행 기록(Executions) 안에만 '실패'로 남습니다. 사람이 그 목록을 직접 열어보지 않으면 알아차릴 방법이 없죠.
두 번째 이유는 자동화가 대부분 외부 서비스에 의존한다는 점입니다. 오픈API 호출, 구글 시트 기록, 메신저 전송처럼 바깥으로 나가는 요청은 내가 짠 흐름이 멀쩡해도 실패할 수 있습니다. 상대 서버의 일시적 점검, 요청량 제한(rate limit), 순간적인 네트워크 끊김 같은 것들이죠. 이런 오류는 대부분 일시적이라 몇 초 뒤 다시 시도하면 성공합니다. 하지만 재시도 설정이 없으면 그 한 번의 깜빡임에 전체 실행이 통째로 죽습니다.
흔한 시나리오를 하나 그려보겠습니다. 매일 아침 뉴스 API에서 데이터를 받아 요약한 뒤 노션에 정리해 두는 워크플로우가 있다고 해보죠. 평소엔 잘 돌지만, 어느 날 뉴스 API 서버가 30초쯤 응답하지 않았습니다. 재시도 설정이 없으니 그 첫 노드가 바로 실패했고, 워크플로우는 그 자리에서 멈췄습니다. 요약도, 노션 정리도 실행되지 않았죠. 그런데 화면엔 아무 일도 없었던 것처럼 보입니다. 며칠 뒤 노션이 비어 있는 걸 발견하고 나서야 '아, 그때 멈췄구나'를 알게 됩니다. 단 30초의 일시적 장애가 며칠치 공백으로 번지는 것, 이게 방어막 없는 자동화의 전형적인 실패 방식입니다.
정리하면, 워크플로우가 멈추는 건 대개 설계가 틀려서가 아니라 '실패할 수 있다'는 전제를 넣지 않았기 때문입니다. n8n은 이 전제를 다루라고 세 가지 장치를 준비해 뒀습니다.
n8n 워크플로우가 주는 세 가지 방어막
공식 문서의 에러 핸들링 가이드는 크게 노드 단위 설정과 워크플로우 단위 설정으로 나눠 설명합니다. 실전에서 자주 쓰는 건 다음 세 가지입니다.
1) Retry On Fail — 노드가 실패하면 스스로 다시 시도
모든 노드의 Settings 탭에 'Retry On Fail' 옵션이 있습니다. 이걸 켜면 노드가 실패했을 때 지정한 횟수만큼, 지정한 간격을 두고 다시 실행합니다. 앞서 말한 일시적 오류 대부분이 여기서 걸러집니다. 외부 API를 호출하는 노드라면 이 옵션 하나만 켜도 '깜빡임' 때문에 실행이 죽는 일이 크게 줄어듭니다. 위의 뉴스 API 예시라면, 30초 응답 지연이 있어도 몇 초 뒤 재시도가 성공하면서 워크플로우는 아무 일 없이 끝까지 돌게 됩니다.
2) On Error — 실패했을 때 어떻게 행동할지 고르기
같은 Settings 탭에 On Error 설정이 있고, 선택지는 세 가지입니다.
| 옵션 | 동작 | 언제 쓰나 |
|---|---|---|
| Stop Workflow (기본값) | 실패 지점에서 실행을 멈춤 | 꼭 성공해야 하는 핵심 단계 |
| Continue | 실패해도 다음 노드로 진행 | 없어도 되는 선택적 단계(예: 통계 기록) |
| Continue (using error output) | 노드에 별도 에러 출력을 만들어 실패 건만 따로 흘려보냄 | 실패한 건만 모아 알림·로그로 처리할 때 |
세 번째 옵션이 특히 유용합니다. 노드에 출력구가 두 개 생겨서 성공은 성공대로 흐르고, 실패한 항목만 아래쪽 갈래로 빠집니다. 그 갈래에 메신저 알림이나 로그 기록을 붙이면 '어디서 뭐가 실패했는지'가 눈에 보이게 됩니다. 여러 건을 한꺼번에 처리하는 워크플로우에서, 한 건이 실패했다고 나머지까지 멈추지 않게 하려면 이 방식이 특히 잘 맞습니다.
3) Error Trigger — 실패를 한곳에서 모아 알림
노드마다 일일이 설정하는 게 부담이라면, Error Trigger 노드로 만든 '에러 전용 워크플로우'를 하나 두는 방법이 있습니다. 다른 워크플로우가 실패하면 이 워크플로우가 대신 실행되면서, 어떤 워크플로우의 어느 노드에서 어떤 에러가 났는지 정보를 넘겨받습니다. 여기에 이메일이나 메신저 알림을 붙여두면 실패가 발생하는 즉시 통보를 받을 수 있습니다. 워크플로우 설정에서 이 에러 워크플로우를 지정하면 여러 자동화가 같은 알림 창구를 공유하게 됩니다. 특히 직접 서버에 올려 쓰는 셀프호스팅 환경이라면 누가 대신 상태를 챙겨주지 않으므로, 이 알림 창구 하나가 사실상 유일한 감시 장치가 됩니다.
실전 적용 순서: 무엇부터 켤까
세 가지를 한꺼번에 다 붙일 필요는 없습니다. 다음 순서로 하나씩 쌓는 걸 권합니다.
- 외부 API를 부르는 노드부터 Retry On Fail을 켠다. 재시도 횟수는 3회, 간격은 몇 초 정도로 시작하면 무난합니다. 요청량 제한이 잦은 서비스라면 간격을 조금 더 길게 잡으세요. 여기서 대부분의 일시적 오류가 사라집니다.
- 없어도 되는 단계는 On Error를 Continue로 바꾼다. 예를 들어 조회수 집계 같은 보조 작업 때문에 본 작업까지 멈추면 손해입니다. 이런 노드는 실패해도 흐름이 이어지게 둡니다.
- Error Trigger 워크플로우를 하나 만들어 알림을 붙인다. 이게 마지막 안전망입니다. 위 두 단계를 빠져나간 실패까지 붙잡아 곧바로 통보해 줍니다.
- 가끔 실행 기록을 직접 열어본다. 알림이 온 적 없더라도 Executions 목록을 주기적으로 훑으면, 미처 알림을 걸지 못한 실패나 예상보다 오래 걸리는 실행을 발견할 수 있습니다.
한 가지 주의할 점도 있습니다. Retry On Fail과 On Error의 'Continue' 계열을 한 노드에 같이 걸면 재시도 결과가 의도와 다르게 처리될 수 있다는 사용자 보고가 있습니다. 두 설정을 겹쳐 쓸 계획이라면 실제 실행 결과를 한 번 확인하고, 확신이 안 서면 공식 문서를 다시 참고하는 편이 안전합니다.
결론: 자동화의 완성은 '실패 처리'까지다
자동화를 만들 때 우리는 보통 '성공했을 때의 흐름'만 그립니다. 하지만 오래 살아남는 워크플로우와 며칠 만에 조용히 죽는 워크플로우를 가르는 건, 바로 '실패했을 때 어떻게 할지'를 정해뒀는지 여부입니다. 재시도로 일시적 오류를 흘려보내고, 선택적 단계는 넘어가게 두고, 마지막엔 실패를 한곳에 모아 알림을 받는 것 — 이 세 겹이 전부입니다. 화려한 노드를 더 붙이는 것보다, 이 세 가지 설정을 켜는 것이 자동화를 훨씬 오래 살아 있게 만듭니다.
오늘 당장 가장 자주 쓰는 워크플로우 하나를 열어, 외부 API 노드에 Retry On Fail부터 켜보세요. 5분이면 충분하고, 그 5분이 다음 '조용한 멈춤'을 막아줍니다.
※ 본 글은 정보 제공을 목적으로 하며, n8n의 기능과 화면 구성은 버전에 따라 달라질 수 있습니다. 실제 설정 위치와 옵션 이름은 사용 중인 버전에서 확인하시기 바랍니다.
댓글 없음:
댓글 쓰기