N8N 워크플로우 30개 굴리다 터진 날 — 자동화 안정성 3단계 체크리스트
2025년 11월 어느 화요일 오전 9시, 슬랙에 에러 알림이 27개 동시에 떴습니다. N8N으로 굴리던 고객 온보딩 워크플로우가 전부 멈춘 거예요. 원인은 전날 밤 업데이트한 Notion API 버전 변경이었죠. 변수명 database_id가 databaseId로 바뀌면서 30개 워크플로우가 한꺼번에 죽었습니다. 이 글을 읽고 나면 여러분은 워크플로우 모니터링 체계를 구축하고, 로그를 추적 가능하게 남기며, 변경 전 테스트로 대참사를 막는 방법을 실습할 수 있습니다.
준비물
N8N 자체 호스팅 환경 또는 N8N Cloud 계정이 필요해요. 저는 Docker 기반 자체 호스팅(v1.17.2)으로 진행했습니다. 모니터링용으로 Uptime Kuma 같은 무료 도구나 N8N 자체 웹훅 기능만으로도 충분합니다. 요금·플랜은 N8N 공식 페이지에서 확인하세요.
테스트용 워크플로우를 최소 3개 이상 준비해두면 실습이 수월합니다.
워크플로우 모니터링은 어떻게 설정하나요?
1단계: 에러 감지 웹훅 달기
모든 워크플로우에 Error Trigger 노드를 추가하세요. N8N 에디터에서 워크플로우를 열고, 왼쪽 패널에서 "Error Trigger"를 검색해 캔버스에 끌어다 놓으면 됩니다. 이 노드는 워크플로우 어디서든 에러가 발생하면 자동으로 실행돼요.
Error Trigger 다음에 HTTP Request 노드를 연결하고, 슬랙 웹훅 URL을 입력합니다. 저는 이렇게 설정했어요.
입력:
Method: POST
URL: https://hooks.slack.com/services/YOUR/WEBHOOK/URL
Body:
{
"text": "워크플로우 에러: {{$json.error.message}}\n실행 ID: {{$runIndex}}"
}출력: 슬랙 채널에 "워크플로우 에러: Cannot read property 'databaseId' of undefined / 실행 ID: abc123" 같은 메시지가 실시간으로 떨어집니다.
이걸 30개 워크플로우에 전부 복사해 붙이려면 하루 날렸을 겁니다. 그래서 저는 템플릿 워크플로우를 하나 만들어서 Export → Import 방식으로 10분 만에 끝냈어요. N8N 설정 화면에서 "Download" 버튼 → JSON 파일 저장 → 다른 워크플로우에서 "Import from File"로 Error Trigger 부분만 가져오면 됩니다.
2단계: 실행 빈도 대시보드 만들기
N8N 자체 호스팅이라면 PostgreSQL 실행 로그를 직접 쿼리할 수 있어요. 저는 Metabase를 연결해서 "최근 24시간 워크플로우별 실행 횟수" 차트를 만들었습니다.
입력:
SELECT workflow_id, COUNT(*) as execution_count
FROM execution_entity
WHERE finished_at > NOW() - INTERVAL '24 hours'
GROUP BY workflow_id
ORDER BY execution_count DESC;출력: 워크플로우 ID 27번이 평소 하루 150회인데 오늘은 3회만 실행됐다면, 뭔가 막혔다는 신호입니다.
로그를 추적 가능하게 남기는 방법은요?
3단계: 실행 컨텍스트 태깅
워크플로우가 왜 실패했는지 나중에 추적하려면, 입력 데이터를 로그에 남겨야 합니다. 저는 각 워크플로우 시작 부분에 Set 노드를 추가해서 executionContext라는 변수를 만들어요.
입력:
executionContext: {
"triggered_by": "{{$json.email}}",
"source": "typeform_webhook",
"timestamp": "{{$now}}"
}이 변수를 워크플로우 마지막에 있는 "성공 로그" 웹훅에도 함께 보냅니다. 그러면 나중에 "user@example.com이 11월 15일 오후 3시에 트리거한 실행이 왜 실패했지?" 같은 질문에 바로 답할 수 있어요.
출력: 로그 수집 도구(제 경우엔 Elasticsearch)에 이렇게 쌓입니다.
{
"workflow": "lead_onboarding",
"status": "error",
"triggered_by": "test@example.com",
"source": "typeform_webhook",
"error": "API rate limit exceeded"
}4단계: 변경 전 테스트 루틴
API 버전을 올리거나 노드 설정을 바꾸기 전에, 반드시 복제본 워크플로우에서 먼저 테스트하세요. N8N 에디터 상단의 "Duplicate" 버튼으로 워크플로우를 복사한 뒤, 이름에 "-TEST"를 붙여요.
테스트 워크플로우에는 실제 데이터 대신 Mock 데이터를 넣습니다. 저는 Webhook 노드 대신 Manual Trigger를 달고, Set 노드로 가짜 입력을 만들어요.
입력:
{
"email": "test@example.com",
"name": "테스트 사용자",
"database_id": "abc123"
}변경 사항을 테스트 워크플로우에 적용하고 "Execute Workflow" 버튼을 누릅니다.
출력: 테스트 실행 결과에서 각 노드의 출력 데이터를 눈으로 확인할 수 있습니다. Notion 노드가 databaseId를 제대로 받았는지, 응답 코드가 200인지 등을 체크하죠.
저는 이 루틴을 건너뛰었다가 운영 워크플로우 30개를 동시에 날린 겁니다. 테스트 워크플로우에서 5분만 돌려봤으면 막을 수 있었어요.
흔한 실수와 해결법
변수명 충돌로 3시간 날림: 워크플로우 A에서 {{$node["HTTP Request"].json["data"]}}로 변수를 참조했는데, 나중에 노드 이름을 "Notion API Call"로 바꾸니까 모든 참조가 깨졌습니다. 해결책은 노드 이름을 절대 바꾸지 말거나, 바꿀 거면 Ctrl+F로 전체 워크플로우를 검색해서 참조를 전부 업데이트하는 겁니다. 저는 지금 노드 이름에 버전 번호를 붙여요(예: "NotionAPIv2").
API Rate Limit을 몰라서 1시간 다운타임: Slack 웹훅은 채널당 초당 1건 수준 제한이 있는데, 워크플로우가 100개 알림을 동시에 쏘려다 429 에러로 전부 막혔어요. N8N의 Batch 설정으로 전송 간격을 1초 이상으로 벌렸더니 해결됐습니다.
자주 묻는 질문
Q. N8N 자체 호스팅과 클라우드 중 뭐가 모니터링에 유리한가요?
A. 자체 호스팅은 PostgreSQL 직접 접근으로 커스텀 쿼리를 쓸 수 있어 유연합니다. 클라우드는 인프라 관리 부담이 없지만 내장 실행 기록만 쓸 수 있어요. 제 경우 월 500회 이상 실행되는 워크플로우는 자체 호스팅으로 옮겼습니다.
Q. 워크플로우가 100개 넘으면 Error Trigger를 일일이 달아야 하나요?
A. N8N API로 워크플로우를 프로그래밍 방식으로 수정할 수 있습니다. 저는 Python으로 /workflows/:id PATCH 요청을 보내는 스크립트를 만들어서 50개 워크플로우에 10분 만에 적용했어요.
Q. 테스트 워크플로우 복제본이 실수로 실행되면 어쩌죠?
A. 테스트 워크플로우는 Active를 꺼두세요. N8N 에디터 우측 상단 토글을 OFF로 하면 Webhook이나 Schedule이 있어도 실행 안 됩니다.
Q. 외부 API 변경을 미리 알 수 있는 방법은 없나요?
A. 대부분의 API 제공자는 변경 로그나 개발자 뉴스레터를 운영합니다. 저는 Feedly로 10개 API 변경 로그를 구독하고, 중요한 업데이트가 나오면 슬랙으로 알림 받습니다.
다음 단계
지금 당장 가장 자주 실행되는 워크플로우 3개에 Error Trigger와 실행 컨텍스트 태깅을 추가해보세요. 30분이면 충분합니다. 다음 주부터는 API 변경이 나올 때마다 테스트 워크플로우에서 먼저 돌려보는 습관을 들이면, 제가 겪은 "화요일 아침 27개 에러" 같은 상황은 피할 수 있을 거예요. 자동화는 만들 때보다 유지할 때가 진짜 싸움이거든요.