n8n은 자동화 외주 상담에서 점점 자주 등장하는 이름입니다. 오픈소스 워크플로 도구라 라이선스 비용 없이 자체 서버에서 돌릴 수 있고 수백 개의 서비스 연동이 준비되어 있습니다. 그런데 "n8n으로 해 주세요"라는 요청과 "우리 문제에 n8n이 맞나요"라는 질문은 다릅니다. 해외 매장의 메신저 자동화를 n8n 기반으로 구축·운영해 본 경험으로 발주자 관점의 판단 가이드를 정리합니다.
n8n 자동화가 맞는 일
n8n의 본질은 이벤트를 받아 여러 서비스를 잇는 오케스트레이션입니다. 다음 조건이 겹칠수록 잘 맞습니다.
- 연동 중심 업무: 메시지가 오면 번역해 시트에 적고 드라이브에 저장하는 식의, 기존 서비스들을 잇는 흐름.
- 이벤트 구동: 웹훅·주기 실행으로 트리거되는 처리. 상주 계산보다 "받으면 처리"형.
- 가시성이 필요한 운영: 워크플로가 그림으로 보이므로, 나중에 다른 개발자(또는 내부 인력)가 흐름을 파악하기 쉬움.
- 점진 확장: 방 하나의 번역으로 시작해 정산·영수증으로 늘려 가는 식의 단계적 성장.
우리 사례가 정확히 이 조합이었습니다. 메신저 수신을 워크플로로 받아 LLM·시트·드라이브를 잇는 일에서 n8n은 접착제 역할을 충실히 했습니다.
n8n만으로 안 되는 일
경험상 경계도 분명합니다.
- 연동 대상에 공식 경로가 없는 경우: 우리 프로젝트의 왓츠앱 단톡방이 그랬습니다. n8n의 기성 노드로는 불가능해, 세션을 관리하는 브리지 서버를 별도로 개발해 n8n 앞에 세웠습니다. "n8n 프로젝트"라 불러도 실제로는 맞춤 개발이 결합된 하이브리드였습니다.
- 복잡한 로직: 노드 안의 코드 실행 환경에는 제약이 있습니다(외부 패키지 설치 불가 등). 우리는 구글 인증 서명을 표준 라이브러리만으로 구현해야 했습니다. 로직이 무거워지면 그 부분은 외부 서비스로 빼는 것이 맞습니다.
- 밀리초 지연·대용량 처리: 워크플로 도구의 영역이 아닙니다.
발주 관점의 함의는 이렇습니다. n8n 견적에서 "기성 노드로 되는 부분"과 "맞춤으로 지어야 하는 부분"의 경계를 물어보세요. 그 경계가 곧 공수와 리스크의 지도입니다.
견적을 좌우하는 것들
같은 "n8n 자동화"라도 공수 차이를 만드는 요소들입니다.
| 요소 | 공수가 작은 쪽 | 공수가 큰 쪽 |
|---|---|---|
| 연동 대상 | 공식 API · 기성 노드 존재 | 비공식 경로 · 브리지 개발 필요 |
| 운영 주체 | 개발자가 계속 관리 | 비개발자 셀프서비스 요구 |
| 안전 요건 | 내부 알림 수준 | 실제 고객 채팅 · 금전 데이터 |
| 규모 | 워크플로 한두 개 | 모듈 분해 · 회귀 검증 필요 |
특히 두 번째와 세 번째가 숨은 비용입니다. "사장님이 직접 운영"하려면 설정의 시트화와 동기화 구조가 추가로 필요하고(구글시트 관리 콘솔 설계) 실제 고객 방에 발송하는 봇이라면 안전장치가 공수의 절반을 차지합니다(메신저 봇 안전장치 설계).
인수인계에서 확인할 것
n8n 프로젝트의 산출물은 코드가 아니라 워크플로라 인수인계 점검도 조금 다릅니다.
- 워크플로 JSON의 저장소 관리: 화면에서 만든 워크플로가 서버에만 있으면 백업도 이력도 없습니다. 내보낸 JSON이 저장소에 버전 관리되는지 확인하세요.
- 검증 스크립트: 수정 후 핵심 경로가 살아 있는지 확인할 실행 가능한 검증이 있는지. 우리는 열여덟 종의 검증 스크립트를 배포 게이트로 뒀습니다.
- 시크릿의 위치: API 키가 워크플로 안에 박혀 있지 않고 자격증명 저장소·환경변수로 분리되어 있는지.
- 운영 문서: 장애 시나리오별 대응(세션 재연결, 재실행)이 운영자 언어로 적혀 있는지.
이 네 가지가 갖춰지면 n8n의 가시성과 결합해 인수인계가 오히려 코드 프로젝트보다 수월해집니다. 노코드와 맞춤 개발 사이의 더 일반적인 선택 기준은 콘텐츠 자동화 노코드 vs 맞춤에서, 워크플로가 커졌을 때의 구조화는 n8n 워크플로 모듈화에서 다룹니다. 이런 요소가 전부 들어간 실제 구축 사례는 왓츠앱 번역 자동화에서 볼 수 있습니다.
자주 묻는 질문
n8n 자동화 외주는 어떤 업무에 적합한가요?
기존 서비스들(메신저, 시트, 드라이브, LLM 등)을 잇는 이벤트 구동형 업무에 적합합니다. 웹훅이나 주기 실행으로 트리거되어 여러 서비스를 오가는 흐름이라면 n8n의 기성 노드와 가시성이 큰 이점입니다. 반대로 비공식 연동이나 무거운 로직은 맞춤 개발이 결합되어야 합니다.
n8n은 무료인데 왜 외주 비용이 드나요?
도구가 무료인 것과 시스템을 짓는 일은 별개입니다. 업무 분석, 워크플로 설계, 비공식 연동의 브리지 개발, 안전장치, 셀프서비스 운영 구조, 검증과 문서가 공수의 실체입니다. 특히 실고객 채팅이나 금전 데이터를 다루면 안전장치 비중이 커집니다.
납품받은 뒤 우리가 직접 수정할 수 있나요?
n8n의 강점이 그 지점입니다. 워크플로가 그림으로 보여 흐름 파악이 쉽고 설정을 시트로 분리해 두면 일상 변경은 개발 없이 가능합니다. 다만 워크플로 JSON의 저장소 관리와 검증 스크립트가 갖춰져 있어야 수정이 안전해지므로, 인수인계 때 이 두 가지를 꼭 확인하세요.
서버는 어디에 두나요?
자체 VPS나 클라우드에 도커로 올리는 구성이 일반적이고 우리 사례도 VPS 위 도커였습니다. 관리형(클라우드) n8n을 쓰면 서버 운영 부담이 없는 대신 월 비용과 데이터 위치 제약이 생깁니다. 데이터 민감도와 운영 역량에 따라 고르면 됩니다.