저는 n8n을 사용하여 자동화를 시작했습니다: WhatsApp, Gmail, 그리고 웹훅 (webhooks)으로 연결된 몇 가지 내부 도구들을 활용했습니다. n8n이 설계된 목적, 즉 이벤트에 의해 트리거되어 처음부터 끝까지 한 번 실행되는 정의된 단계의 흐름(flows)에는 잘 작동합니다. 문제는 시스템이 메시지 사이의 문맥 (context)을 기억하고, 미리 그려진 고정된 흐름이 아니라 축적된 문맥에 따라 서로 다른 결정을 내려야 할 필요가 생기면서 발생했습니다.

n8n의 한계점

n8n은 자동화를 노드 그래프 (graph of nodes)로 모델링합니다: A가 B를 트리거하고, B가 C를 트리거하는 방식입니다. 이는 "이 제목으로 이메일이 오면 Asana에 작업을 생성하라"와 같은 작업에는 완벽하게 작동합니다. 하지만 "이 시점까지의 대화에서 발생한 모든 일을 고려했을 때, 시스템이 지금 무엇을 해야 하는가?"라는 질문에는 제대로 작동하지 않습니다. 왜냐하면 그 결정은 고정된 흐름이 아니라, 축적된 상태 (state)에 따라 변하는 동적인 평가이기 때문입니다.

제가 발견한 세 가지 구체적인 한계는 다음과 같습니다:

1. 실행 간의 상태 (State between executions). n8n은 워크플로우 (workflow)의 각 실행을 독립된 것으로 취급합니다. 몇 시간 또는 며칠 동안 지속되는 WhatsApp 대화의 문맥 — 누가 무엇을 물었는지, 무엇이 해결되었는지, 무엇이 미결 상태인지 — 을 유지하는 것은 n8n의 실행 모델을 활용하는 것이 아니라, 그 모델과 싸우는 것을 의미합니다.
2. 다음 단계에 대한 동적 결정. n8n의 흐름은 어떤 노드가 다음에 올지를 미리 정의합니다. 메시지 내용에 따라 N개의 도구 중 어떤 것을 사용할지 LLM (Large Language Model)이 실시간으로 결정하기를 원할 때 — 고정된 if/else가 아니라 추론에 기반한 진정한 결정 — 결국 코드 노드 내에 LLM 결정 인터프리터를 구축하게 됩니다. 이 시점에서는 더 이상 n8n을 본래 용도대로 사용하는 것이 아니라, 본인 코드의 래퍼 (wrapper)로 사용하고 있는 셈입니다.

출력 계약 (output contract)에 대한 정밀한 제어. LLM의 출력이 (WhatsApp이나 Gmail 같은 다운스트림 통합을 깨뜨리지 않도록) 엄격한 스키마 (schema)를 준수해야 하는 경우, 오류 컨텍스트를 포함한 검증 및 재시도 (retry) 레이어가 필요합니다. n8n에서는 이러한 로직이 함수 노드 (function nodes) 사이에 흩어져 있어, 하나의 일관된 단위로 테스트하거나 버전 관리하기가 어렵습니다.

n8n을 강제하는 대신 Hermes를 구축한 이유

Hermes는 EC2에서 실행되는 지속성 있는 에이전트 (persistent agent)이며, 다음과 같은 특징을 갖습니다:

• 웹훅 (webhook)으로 연결된 개별 노드 대신, MCP를 통한 폐쇄형 도구 카탈로그 (closed catalog of tools)를 사용합니다 (Self-hosted 모드의 WhatsApp, OAuth를 통한 Gmail, 내부 도구 등).
• 엄격한 입출력 계약: LLM (OpenRouter를 통한 deepseek-v4-flash)이 검증된 스키마 내에서 응답하며, 이를 준수하지 않을 경우 자동 재시도를 수행합니다.
• 고립된 실행이 아닌 지속적인 대화 상태 (persistent conversation state): 에이전트는 동일한 WhatsApp 스레드에서 이전에 어떤 일이 있었는지 알고 있습니다.

근본적인 차이점: n8n은 당신이 미리 결정한 단계들을 오케스트레이션 (orchestrate)합니다. 반면 Hermes는 당신이 정의한 제한 범위 내에서 (도구 카탈로그, 출력 스키마 등) 다음 단계를 실시간으로 결정하지만, 당신이 전체 그래프 (graph)를 미리 그려둘 필요는 없습니다.

n8n을 사용해야 하는 경우 (YES)

만약 작업이 진정으로 고정된 흐름 — "X가 발생하면, 변동 없이 항상 Y를 수행한다" — 라면, n8n은 여전히 구축하고 유지 관리하기에 가장 빠른 옵션입니다. 저의 실수는 n8n이 상태를 가진 동적 추론 (dynamic reasoning)을 하도록 강제한 것이었습니다. 바로 그 지점이 자체적인 것을 구축할 가치가 있는 지점이지, 그 전 단계가 아닙니다.

복사하여 붙여넣기 위한 요약

1. n8n = 고정된 흐름, 트리거 → 사전 정의된 단계 → 종료. 이 용도로는 탁월합니다.
2. 지속적인 상태 + 다음 단계에 대한 동적 결정 = 워크플로우 도구 (workflow tool)가 아닌 에이전트 (agent)가 필요합니다.
3. 스키마 계약 + 검증 + 재시도는 함수 노드에 흩어져 있는 것보다 자체 코드로 유지 관리하는 것이 더 쉽습니다.
4. 단순히 변덕 때문에 n8n을 교체하지 마세요. 흐름 (flow)이 더 이상 흐름이 아니라 결정 (decision)이 될 때 교체하세요.