n8n 자동화, 처음 만드는 슬랙 봇에 꼭 넣어야 할 다섯 가지 (직접 굴려 본 기준)

n8n 자동화를 검색했다면

n8n은 노드를 이어 붙여 업무 흐름을 자동화하는 도구다. 셀프호스트하면 실행 횟수 과금이 없어서 1인 사업자나 작은 팀이 많이 쓴다. 검색하면 "이런 것도 된다" 목록은 많은데, 처음 만든 자동화가 왜 사고를 치는지는 잘 안 나온다. 여기는 우리가 실제로 운영하면서 정리한 기준이다.

먼저, 우리가 잰 숫자 하나

우리 저장소에는 n8n 워크플로가 23개 있었다. 그런데 이걸 고객에게 설치해 주려고 세어 보니, 고객이 설치 직후 바로 쓸 수 있는 것은 0개였다. 전부 우리 서버를 부르는 내부용이었기 때문이다. 그래서 외부 엔드포인트 없이 환경변수만으로 도는 스타터 3개를 새로 썼다(슬랙 봇 · 웹훅 LLM 응답 · 에러 알림). 아래 다섯 가지는 그중 16개 노드짜리 슬랙 봇에 넣은 것들이다.

꼭 넣어야 할 다섯 가지

1. 봇 자기 메시지 무시 — 맨 앞에. 없으면 봇이 자기 답변에 또 답하면서 무한 루프가 된다. LLM을 붙였다면 그대로 청구서가 된다. 가장 비싼 실수를 막는 한 줄이다.

2. 빈 본문 차단. 파일만 올리거나 메시지를 편집하면 본문 없는 이벤트가 온다. 걸러내지 않으면 뒤의 모든 노드가 쓰레기 입력을 받는다.

3. url_verification 응답. 슬랙 앱에 주소를 등록할 때 슬랙이 확인 요청을 보낸다. challenge 값을 그대로 돌려줘야 등록이 끝난다. 워크플로를 먼저 활성화해 둬야 이 단계가 통과된다.

4. 정규식으로 먼저 분류하고, 애매한 것만 LLM에. "도움말", "취소" 같은 말은 정규식으로 공짜로 처리된다. 규칙 표를 늘릴수록 LLM 호출이 준다.

5. 사용자당 하루 상한, 그리고 fail-open. 우리 기본값은 1인당 하루 50회다. 다만 제한기 자체가 고장 나면 막지 않고 통과시킨다. 제한기 버그로 봇 전체가 멈추는 게 더 나쁘기 때문이다.

이 기준이 답하지 못하는 것

스타터는 아직 고객 설치 사례가 없다. 그래서 정규식이 실제로 몇 %를 처리하는지는 재지 못했다. 50회라는 상한도 실측이 아니라 출발점이다. 또 상한을 워크플로 메모리에 세기 때문에 n8n을 여러 대로 늘리면 각자 따로 센다 — 그때는 공유 저장소로 바꿔야 한다.

이 기준이 들어간 설치형 자동화: 업무 자동화