n8n is dead?

n8n is dead?

작년 이맘때만 해도 n8n은 자동화 툴의 대세였습니다. 유튜브와 각종 SNS에는 n8n 워크플로우로 자동화한 사례가 하루가 멀다 하고 올라왔습니다. 그런데 올해는 n8n 이야기는 사라지고 조용합니다. 이걸 반영이라도 하듯 해외 커뮤니티에서는 n8n is dead?라는 주제의 글이 종종 보이곤 합니다.

작년 7월부터 회사에서 팀에서 사용할 n8n을 구축하였습니다. 다른 팀보다 꽤 빠르게 도입하였습니다.

n8n을 적용하고, 실제 업무에 붙여보고 사용하면서 한계를 몸으로 겪었습니다. n8n 그 후기를 남겨보려고 합니다.

n8n의 적용에 막히는 지점들

1. 약한 병렬 처리

n8n에 병렬 처리 기능이 있긴 합니다. 그런데 각종 제약이 많기에 막상 써보면 리소스를 충분히 사용하지 못합니다. 이러한 n8n의 구조적 제약 앞에서 남는 리소스는 그냥 낭비되고 있는 상태입니다.

2. 메모리 제약

각 노드마다 메모리 제한이 있습니다. 그렇기 떄문에 대량의 데이터를 워크플로우 안에서 다루려 하면 OOM(Out of Memory)이 발생합니다. 결국 무거운 데이터는 n8n 바깥에서 전처리한 뒤에 넣어야 합니다. 워크플로우 툴인데 정작 핵심 처리를 워크플로우 밖에서 해야 하는 아이러니한 상황이 발생합니다.

3. 팀 협업을 위해 구매해야하는 라이센스

n8n을 구축하고 제일 먼저 받은 질문 중 하나가 여러 사람이 하나의 워크플로우를 작업할 수 있냐는 것이었습니다. n8n은 완전히 무료로 이용ㅇ할 수 있는 오픈소스가 아닙니다. 이런 기능은 엔터프라이즈 라이센스를 구매해야지 가능합니다.

물론 공용 계정에서 n8n을 접속할 수 있지만 이 또한 온전한 해결책이 아닌, 불편한 방법입니다. 개인 프로젝트라면 모를까, 팀 단위로 쓰려면 워크플로우를 공유하고 함께 관리할 수 있어야 편리한데 무료로 사용하기에는 여간 불편한것이 아닙니다.

4. 많은 대체제

n8n의 문제는 사실 프로그래밍 언어면 너무 쉽게 해결됩니다. 병렬처리 문법을 이용해서 워크플로우의 성능을 충분히 끌어올릴 수 있습니다. 그리고 작업 결과물 공유는 Git에 올리면 끝입니다.

그리고 지금은 바이브 코딩의 시대입니다. Claude Code나 Cursor에게 말로 설명하면 스크립트가 뚝딱 나옵니다. n8n에서 노드 사용법을 공부하고 한 땀 한 땀 연결하는 것보다 오히려 더 빠른 경우가 많습니다. 코딩을 못해서 n8n을 쓴다는 이유도 설득력을 잃어버렸습니다.

또한 마누스나 오픈클로처럼 n8n에서 한땀한땀 노드를 만들어야하는 비슷한 작업을 다양한 방법으로 쉽게 자동화 할 수 있습니다.

5. 어려운 제작과 테스트

n8n을 쓰다 보면 노드가 어느새 걷잡을 수 없이 늘어납니다. 복잡한 게임의 스킬 트리나 지하철 노선도처럼, 화면 가득 복잡한 노드를 볼 수 있습니다.

노드가 많이 늘어나면 문제가 생깁니다. 하나를 수정하면 그 이후 노드들이 다양한 케이스에서 제대로 동작하는지 일일이 확인해야 하고, 하나만 잘못 건드려도 전체 워크플로우가 멈춥니다.

코드였다면 단위 테스트를 작성해서 기능별로 검증할 수 있습니다. 하지만 n8n에서 오류가 난 노드는 어디서, 어떻게 고쳐야 할지 막막할 때가 많습니다. 고치다가 다른 곳이 또 터지는 경험도 자주 합니다.

n8n이 의미 없었을까?

n8n이 전혀 의미없는 시도였냐고 묻는다면 전혀 아닙니다.

n8n은 지금의 AI 에이전트 붐을 만든 기술이라고 생각합니다. 작년 초만 해도 에이전트가 뭔지, 어떻게 구성하는지 아는 사람이 드물었습니다. n8n을 만지면서 수많은 사람들이 트리거-액션-분기-루프의 흐름을 손으로 익혔습니다. 노드를 이리저리 연결하며 " 어떻게 판단하고 행동해야 하는가를 배운 거십니다.