Community실패 사례
n8n의 Test workflow는 실제 발송을 막아주지 않는다 — 전체 회원 200명에게 메일 나갈 뻔한 기록
서
서지원
@nlpseo
환영 메일 워크플로우가 잘 돌길래 그걸 복제해서 전체 공지용으로 고쳤다. 트리거를 Manual로 바꾸고, 신규 가입자만 거르던 가운데 필터를 풀었다. 그런데 데이터 소스 노드는 그대로 전체 회원 200명을 끌어오고 있었다. 탈퇴자와 테스트 계정까지 포함해서.
여기서 n8n의 Test workflow를 눌렀다. 노코드 툴이고 버튼 이름이 "테스트"라서, 당연히 dry-run이라 실제 발송은 안 될 거라 생각했다. 이게 틀렸다.
n8n의 Test workflow는 활성화된 노드를 전부 실제로 실행한다. Gmail 노드가 켜져 있으면 테스트 실행이든 본 실행이든 메일이 실제로 나간다. "테스트"는 트리거를 수동으로 한 번 돌려본다는 의미일 뿐, 부수효과를 막아주는 dry-run이 아니었다.
그나마 다행이었던 건, 평소 습관대로 발송 노드를 Disabled로 막아두고 앞 단계까지만 실행해봤다는 점이다. 발송 직전 노드의 출력을 보니 200건이 그대로 잡혀 있었다. 만약 그 노드를 disabled로 안 해놨으면 200통이 그대로 나갔을 상황이었다.
정리하면:
- 노코드 자동화 툴의 "Test" 버튼은 dry-run을 보장하지 않는다. 외부로 나가는 노드(메일, 슬랙, API POST)는 테스트 실행에서도 실제로 동작한다고 가정해야 한다.
- 부수효과가 있는 노드는 검증이 끝나기 전까지 명시적으로 disabled로 두고, 직전 노드의 출력 건수부터 눈으로 확인한다.
- 사람이면 메일 한 통 잘못 보내고 끝날 일을, 자동화는 200통을 한 번에 보낸다. 대상 건수를 확인하는 단계가 없으면 그 규모가 그대로 사고 규모가 된다.
복제한 워크플로우는 데이터 소스의 필터 범위가 의도와 다를 수 있으니, 발송 대상 쿼리부터 다시 보는 걸 기본 절차로 넣었다.