n8n 워크플로 자꾸 멈출 때 점검 체크리스트: 타임아웃·인증·재시도부터 보세요

2026년 07월 04일

0 Views

n8n 워크플로 자꾸 멈출 때 점검 체크리스트: 타임아웃·인증·재시도부터 보세요

n8n 워크플로 자꾸 멈출 때 점검 체크리스트의 핵심은 간단합니다. 먼저 마지막으로 성공한 노드, 인증 만료, API 제한, 타임아웃, 재시도 설정을 순서대로 보면 대부분 원인이 좁혀집니다.

이 글에는 제휴(어필리에이트) 링크가 포함될 수 있으며, 링크를 통해 가입·구매 시 소정의 수수료를 받을 수 있습니다. 추천은 실제 사용 경험에 기반합니다.

실패한 실행 3개를 비교한 뒤, 가장 자주 멈추는 노드에 Wait·Retry·Error Workflow를 하나씩 붙여보세요.

저는 Docker로 띄운 n8n에서 Slack 알림, Notion DB 기록, OpenAI API 요약, Airtable 업데이트를 묶어 테스트할 때 비슷한 멈춤을 자주 봤습니다. 노드가 복잡해서라기보다, 외부 서비스 응답 지연이나 토큰 만료를 워크플로가 안전하게 처리하지 못한 경우가 많았습니다.

지금 할 일:
n8n의 Executions 화면을 열고, 실패한 실행 3개만 비교해보세요. 같은 노드에서 멈추면 설정 문제, 매번 위치가 다르면 외부 API나 데이터 크기 문제일 가능성이 큽니다.

가장 먼저 볼 5가지

1. 실행 로그에서 ‘마지막 정상 노드’를 찾기

감으로 고치기 전에 Executions에서 실패한 실행을 열어보세요. 빨간 노드만 보지 말고, 그 직전 노드의 출력 데이터도 확인해야 합니다.

예를 들어 HTTP Request 노드가 실패해도 원인은 이전 Set 노드에서 빈 이메일, 잘못된 URL, 너무 긴 텍스트를 넘긴 것일 수 있습니다. n8n은 노드 단위로 보이지만 문제는 데이터 흐름에서 생깁니다.

2. Credential 만료와 권한 변경 확인

Google Sheets, Slack, Notion, Airtable 같은 서비스는 토큰이 만료되거나 권한 범위가 바뀌면 갑자기 멈춥니다. 특히 팀원이 앱 권한을 수정했거나 워크스페이스 정책이 바뀐 뒤 발생하기 쉽습니다.

Credentials 메뉴에서 다시 인증하고, 같은 계정으로 실제 서비스 접근이 되는지 확인하세요. Notion은 데이터베이스 공유 권한이 빠져도 API에서는 권한 오류처럼 보입니다.

3. API rate limit과 타임아웃

OpenAI, Anthropic, Slack, GitHub API를 많이 호출하는 자동화라면 제한에 걸릴 수 있습니다. 한 번에 100개 행을 돌리는 것보다 Split In Batches와 Wait 노드를 넣는 편이 안정적입니다.

외부 API가 느린 날에는 n8n 문제가 아닌데도 멈춘 것처럼 보입니다. HTTP Request 노드의 timeout, retry, 응답 코드 처리를 같이 봐야 합니다.

증상별 빠른 진단표

증상	가능한 원인	확인 위치	바로 해볼 조치
항상 같은 노드에서 실패	인증 만료, 필수값 누락, API 변경	Executions, Credentials	토큰 재연결, 입력 데이터 샘플 확인
가끔만 멈춤	rate limit, 외부 서비스 지연	HTTP 응답 코드, 실행 시간	Wait 노드, retry, batch 크기 축소
Webhook이 안 들어옴	URL 변경, reverse proxy, 도메인 SSL	Webhook URL, 서버 로그	Production URL 재확인, Nginx/Cloudflare 점검
대량 처리 중 중단	메모리 부족, binary 데이터 과다	서버 리소스, Docker logs	파일 저장 방식 변경, 배치 처리
성공으로 보이는데 결과 없음	조건 분기 오류, 빈 배열 처리	IF, Switch, Merge 노드	빈 값 분기 추가, 테스트 데이터 고정

실제에 가까운 예: Slack 문의를 Notion에 정리하는 자동화

가상의 셋업을 하나 보겠습니다. Slack 채널에 새 문의가 오면 n8n Webhook이 받고, OpenAI API로 요약한 뒤 Notion 데이터베이스에 저장하는 흐름입니다. 테스트에서는 잘 되는데 운영 중 간헐적으로 멈출 수 있습니다.

이 경우 흔한 원인은 OpenAI 응답 지연 또는 429 제한입니다. 해결은 거창하지 않습니다. Slack 입력을 바로 OpenAI로 보내지 말고, Set 노드로 필요한 텍스트만 줄이고, Wait 노드로 호출 간격을 만들고, 실패 시 Slack에 관리자 알림을 보내는 Error Workflow를 붙이면 됩니다.

여기서 중요한 점은 “한 번에 성공하는 자동화”가 아니라 “실패해도 어디서 왜 실패했는지 남기는 자동화”로 바꾸는 것입니다.

n8n Cloud, 셀프호스팅, Make/Zapier 중 무엇이 덜 멈출까?

자주 하는 실수: Continue On Fail을 무작정 켜기

멈춤을 피하려고 모든 노드에 Continue On Fail을 켜면 나중에 더 큰 문제가 됩니다. 실패했는데도 다음 노드가 실행되어 잘못된 데이터가 Notion, Airtable, Google Sheets에 쌓일 수 있습니다.

대신 실패해도 넘어가도 되는 노드와 반드시 멈춰야 하는 노드를 나누세요. 예를 들어 “Slack 알림 실패”는 넘어갈 수 있지만 “결제 상태 업데이트 실패”는 멈추고 관리자에게 알려야 합니다.

바로 적용할 복구 순서

실패한 실행 3개를 열어 같은 노드에서 멈추는지 확인합니다.
Credentials를 재연결하고, 해당 SaaS에서 권한이 유지되는지 봅니다.
HTTP Request 노드의 응답 코드와 timeout 값을 확인합니다.
대량 반복은 Split In Batches로 나누고 Wait를 넣습니다.
Error Trigger 워크플로를 만들어 Slack 또는 이메일로 실패 메시지를 받습니다.
셀프호스팅이면 Docker logs, 메모리, 디스크, PostgreSQL 상태를 확인합니다.

FAQ

n8n이 멈췄는데 실행 기록도 안 남습니다. 어디를 봐야 하나요?

Webhook이 호출되지 않았거나 서버 레벨에서 막혔을 수 있습니다. Production Webhook URL, reverse proxy, SSL 인증서, 방화벽, Cloudflare 설정을 먼저 확인하세요. 셀프호스팅이면 Docker 컨테이너 로그도 같이 봐야 합니다.

OpenAI나 Claude API 노드에서만 자주 실패합니다. n8n 문제인가요?

항상 n8n 문제는 아닙니다. 모델 API는 응답 지연, rate limit, 입력 토큰 초과가 흔합니다. 텍스트를 줄이고, 재시도 간격을 늘리고, 실패 응답을 별도 분기로 저장하는 방식이 안정적입니다.

워크플로가 길어질수록 불안정해집니다. 쪼개야 하나요?

네, 운영용 자동화는 기능별로 나누는 편이 좋습니다. 수집, 정제, AI 처리, 저장, 알림을 별도 워크플로로 분리하면 실패 범위를 줄이고 재실행도 쉬워집니다.

정리하면, n8n 워크플로 자꾸 멈출 때 점검 체크리스트는 “로그 → 인증 → API 제한 → 데이터 크기 → 서버 상태” 순서로 보면 됩니다. 오늘은 전체를 뜯어고치기보다 실패 실행 3개를 비교하고, 가장 자주 멈추는 노드 하나에 재시도와 오류 알림을 붙이는 것부터 시작하세요.

n8n 워크플로 자꾸 멈출 때 점검 체크리스트: 타임아웃·인증·재시도부터 보세요