n8n, LangGraph, Temporal: 제대로 된 자동화

누구나 n8n을 연결할 수 있습니다. 하지만 n8n이 어디에서 멈추는지 말할 수 있는 사람은 거의 없습니다. 그 간극이 바로 업무의 전부입니다. 진정한 자동화는 하나의 도구가 아니라 세 개의 계층으로 이루어지며, 대부분의 사람들이 구축하는 계층은 쉬운 세 번째 계층입니다. 우리는 자체 시스템과 고객사를 위해 프로덕션 환경에서 이 세 가지를 모두 운영하고 있으며, 그 가치는 결코 모든 사람이 이미 가지고 있는 부분에서 나오지 않았습니다.

n8n은 기묘한 한 해를 보냈습니다. 2025년 10월, 이 회사는 1억 8천만 달러를 유치하며 기업 가치 25억 달러를 돌파했는데, 이는 4개월 전의 3억 달러에서 급증한 수치입니다. 현재 약 230,000명이 n8n을 실행하고 있으며, 그중 4분의 3이 AI 노드(AI nodes)를 사용하고 있습니다. LinkedIn의 자동화 게시물 두 개 중 하나는 몇 개의 박스와 화살표가 있는 n8n 캔버스(canvas)입니다. 이 도구는 그 기대를 충족시켰습니다. 진정으로 훌륭하며, 셀프 호스팅(self-hostable)이 가능하고, 거의 모든 것과 연결됩니다.

그리고 바로 그 지점이 대부분의 자동화 프로젝트가 조용히 멈추는 곳입니다. 누군가 n8n을 설정하고, 웹훅(webhook)을 Slack 메시지에 연결한 뒤, 이를 자동화 전략이라고 부르며 다음 단계로 넘어갑니다. 워크플로(workflow)가 판단을 내려야 하거나, 위치를 잃지 않고 4일 동안 서버 재시작을 견뎌내야 할 때까지는 작동합니다. 그 시점이 되면 시각적 캔버스는 한계에 부딪히고, 캔버스만 아는 사람들도 함께 한계에 부딪힙니다.

자동화에 실제로 필요한 것

도구들을 걷어내면 모든 진지한 자동화의 밑바탕에는 세 가지 작업이 있습니다. 이것들은 서로 다른 문제이며, 한 가지를 잘 수행하는 도구는 대개 나머지 두 가지를 형편없이 수행합니다.

첫 번째 작업은 것들을 연결하는 것입니다. 가입 요청이 들어오면, 기록이 CRM에 저장되고, 환영 메일이 발송되며, 누군가의 휴대폰으로 알림이 전달됩니다. 사고할 필요 없이, 서로 대화하도록 설계되지 않은 시스템들 사이에서 신뢰할 수 있는 배관(plumbing) 역할만 하면 됩니다. 이것이 수량 면에서 자동화의 대부분을 차지하며, n8n이 만들어진 목적이기도 합니다.

두 번째 작업은 판단(judgment call)을 내리는 것입니다. 워크플로우는 모호한 내용을 읽고, 그것이 무엇을 의미하는지 결정하며, 그 결정에 따라 다음 단계를 선택해야 합니다. 이메일이 도착했을 때 시스템은 이것이 실제 잠재 고객(lead)인지 아니면 노이즈인지 판단한 후 그에 따라 경로를 지정해야 합니다. 초안이 검토될 때 시스템은 이것이 배포하기에 충분히 괜찮은지, 아니면 한 번 더 검토가 필요한지 결정해야 합니다. 이것은 배관(plumbing) 작업이 아닙니다. 이것은 추론(reasoning)이며, 다른 종류의 도구가 필요합니다.

세 번째 작업은 시간이 흘러도 생존하는 것입니다. 어떤 워크플로우는 몇 시간 또는 며칠 동안 실행됩니다. 사람이 무언가를 승인하기를 기다리기도 합니다. 여섯 개의 외부 서비스(external services)를 호출하는데, 그중 어떤 것이라도 실패할 수 있으며, 중간에 실패하더라도 나머지 다섯 개에 영향을 주어서는 안 됩니다. 만약 일곱 단계 중 네 번째 단계에서 기계가 재부팅된다면, 작업은 처음부터 다시 시작하는 것이 아니라 네 번째 단계부터 재개되어야 합니다. 이것은 내구성(durability)이며, 세 가지 작업 중 가장 흉내 내기 어려운 부분입니다.

이 세 가지 작업은 서로 직교(orthogonal)합니다. 세 가지를 한꺼번에 모두 하려는 도구는 결국 각각의 분야에서 평범한 수준에 머물게 됩니다. 각 계층에 적합한 전문가를 선택하는 스택이 언제나 올인원(all-in-one) 도구를 이깁니다. 우리의 세 명의 전문가는 n8n, LangGraph, 그리고 Temporal입니다.

n8n: 모두가 이미 가지고 있는 계층

n8n은 연결 계층(connecting layer)이며, 그 작업에 있어서는 매우 탁월합니다. 400개 이상의 사전 구축된 통합(integrations), 비엔지니어(non-engineer)도 실제로 읽을 수 있는 시각적 캔버스(visual canvas), 30분 이내에 가능한 셀프 호스팅(self-hosting)을 제공합니다. 우리는 비즈니스를 움직이게 만드는, 화려하지는 않지만 필수적인 작업들을 위한 자동화 허브(automation hub)로 n8n을 운영합니다. CRM 리드(lead)를 생성하고 환영 메일을 발송하는 가입 웹훅(signup webhook), 소셜 미디어 초안 게시물로 퍼지는 새로운 블로그 포스트, 서비스 목록을 확인하고 하나라도 응답이 없으면 채널에 알림을 보내는 예약된 상태 확인(health check), 사람이 확인하기 전에 의도(intent)를 파싱(parsing)하는 수신 이메일 등이 그 예입니다.

이것은 진정한 가치이며, 저는 이 점을 명확히 하고 싶습니다. n8n은 장난감이 아니며, 파워 유저를 위한 Zapier도 아닙니다. n8n은 제대로 된, 공정한 라이선스를 가진, 셀프 호스팅(self-hostable)이 가능한 오케스트레이션(orchestration) 플랫폼이며, 시스템을 연결하는 데 있어 종종 가장 빠르고 정확한 해답이 됩니다. 만약 클라이언트의 운영(ops) 팀이 배포 주기(deployment cycle) 없이 워크플로우(workflow)를 편집해야 한다면, 비주얼 캔버스(visual canvas)는 그 자체의 장점만으로도 승리합니다.

정직함은 n8n이 무엇이 아닌지를 살펴볼 때 시작됩니다. n8n은 기본적으로 단계를 순차적으로 실행하므로, 공유 상태(shared state)를 가진 진정한 병렬 작업은 금방 취약해집니다. 사람들은 제어된 코드에서는 단순히 존재하지 않는 레이스 컨디션(race condition, 경쟁 상태)으로 인해 몇 퍼센트의 확률로 실패하는 머지 노드(merge node)를 보고하곤 합니다. n8n은 결정론적 재생(deterministic replay)이 가능한 상태 머신(state machine)이 아니므로, 실행 도중 충돌(crash)이 발생하면 깔끔하게 재개되지 않습니다. 퍼스트 클래스 테스트(first-class testing) 기능도 없습니다. 그리고 워크플로우에 조금이라도 특이한 것이 필요해지는 순간, 당신은 코드 노드(Code node)를 사용하게 되며, 이 코드 노드는 아무도 캔버스 위에 기록하지 않은 기술 부채(technical debt)가 조용히 쌓이는 곳이 됩니다. 이 중 어느 것도 결함은 아닙니다. 단지 레이어(layer)의 경계일 뿐입니다. 실수는 n8n을 사용하지 않는 것이 아닙니다. 실수는 캔버스가 지도 전체라고 믿는 것입니다.

LangGraph: 워크플로우가 사고해야 할 때

워크플로우가 단순히 경로를 지정하는 대신 추론(reasoning)을 해야 할 때, 우리는 LangGraph를 찾습니다. LangGraph는 LangChain 팀이 만든 코드 우선(code-first) 프레임워크로, 고정된 다이어그램이 아니라 언어 모델(language model)이 다음에 무엇이 일어날지를 결정하는 단계들의 그래프(graph)로 워크플로우를 모델링합니다. LangChain 1.0이 출시된 이후, LangChain 자체의 에이전트(agents)들은 내부적으로 LangGraph 위에서 실행되고 있으며, Uber, LinkedIn, Klarna, Replit과 같은 기업들이 포함된 프로덕션 사용자 명단은 그 위상을 증명하고 있습니다.

그 자리를 차지하게 만드는 두 가지 기능은 상태(State)와 일시 중지(Pausing)입니다. 상태(State)란 워크플로(Workflow)가 자신이 어디에 있는지 기억한다는 것을 의미합니다. 모든 단계는 데이터베이스에 체크포인트(Checkpoint)로 기록되므로, 3단계에서 충돌(Crash)이 발생하더라도 전체 실행을 다시 시작하는 대신 3단계부터 재개할 수 있습니다. 일시 중지(Pausing)는 워크플로가 중간에 멈춰서 사람이 승인하거나 무언가를 수정할 때까지 기다린 후, 그 답변을 포함하여 계속 진행할 수 있음을 의미합니다. LangGraph에서 이것은 별도로 구축된 사이드 시스템이 아니라 하나의 기본 요소(Primitive)입니다.

우리가 이를 활용해 실행하는 구체적인 형태는 다음과 같습니다. 한 단계에서는 계획을 초안하고, 다음 단계에서는 그 계획에 따라 구축하며, 세 번째 단계에서는 결과를 검토하고, 네 번째 단계에서는 이를 테스트하는 다단계 에이전트 파이프라인(Multi-step agent pipeline)입니다. 이때 검토 결과가 불확실할 때마다 사람이 개입할 수 있도록 전체 과정을 일시 중지하는 승인 게이트(Approval gate)를 둡니다. 이것이 바로 추론(Reasoning), 체크포인트(Checkpoints), 그리고 인간 참여형(Human-in-the-loop)의 결합이며, LangGraph가 존재하는 정확한 이유이자 n8n의 캔버스(Canvas)가 중첩된 서브 워크플로(Sub-workflows)나 폴링(Polling) 해킹 없이는 표현하기 힘들어하는 바로 그 조합입니다.

트레이드오프(Trade-off)는 실재하며 명확히 언급할 가치가 있습니다. 단순히 모델을 호출하고 결과를 어딘가에 게시하는 워크플로에 LangGraph를 사용하는 것은 과잉(Overkill)입니다. 너무 일찍 LangGraph를 도입하면, 50줄의 평이한 로직으로 더 명확하게 작성할 수 있는 코드를 200줄의 프레임워크 코드로 쓰게 됩니다. 또한 독점적 라이선스(Proprietary license)를 수반하며, 이는 우리가 무시하기보다는 의도적으로 관리하는 락인(Lock-in) 위험입니다. 원칙은 추론(Reasoning)과 재개(Resume) 기능이 추가된 무게만큼의 가치를 진정으로 제공하는 곳에만 이를 사용하는 것입니다.

Temporal: 워크플로가 절대 중단되어서는 안 될 때

세 번째 계층은 n8n 사용자들 중 거의 아무도 들어본 적 없는 것이며, 취미 수준의 설정과 인프라(Infrastructure)를 구분 짓는 계층입니다. Temporal은 내구성이 있는 실행 엔진 (Durable execution engine)입니다. 워크플로의 모든 단계를 이벤트 히스토리 (Event history)로 기록하기 때문에, 서버가 충돌하더라도 새로운 워커 (Worker)를 실행하여 충돌 직전의 정확한 상태까지 히스토리를 재생(Replay)하고, 아무 일도 없었던 것처럼 작업을 계속 이어갑니다. 워크플로는 며칠 또는 몇 년 동안 실행될 수 있습니다. 이는 MIT 라이선스 하에 오픈 소스로 제공되며, 내구성이 있는 에이전트 실행 (Durable agent execution)의 표준으로 조용히 자리 잡았습니다. OpenAI는 인간의 승인을 기다리며 며칠을 대기하고, 재시작 시에도 진행 상태를 잃지 않는 에이전트들을 위해 프로덕션 환경에서 Codex를 Temporal 위에서 실행합니다.

이를 통해 가능해지는 것은 현실 세계와 맞닿아 있으며, 절반만 완료되어서는 안 되는 부류의 워크플로입니다. 구독이 갱신되고, 결제가 이루어지며, 만약 한 단계가 실패할 경우 일련의 부수 효과(Side effects)들을 깔끔하게 롤백(Rollback)해야 하는 결제 라이프사이클(Billing lifecycle)이 그 예입니다. 타이머와 대기(Wait) 기능이 내장되어 며칠에 걸쳐 실행되는 고객 온보딩(Customer onboarding), 그리고 수많은 소스에 걸친 작업을 집계하며 매번 반드시 신뢰성 있게 완료되어야 하는 반복 작업(Recurring job) 등이 있습니다. 이것들은 '사가 (Sagas)'라고 불리며, 무언가 고장 났을 때 보상(Compensation) 절차를 동반하는 장기 실행 트랜잭션 (Long-running transactions)입니다. 그리고 이것들은 바로 시각적 캔버스 (Visual canvas)가 결코 감당하도록 설계되지 않은 영역입니다.

이 분야에서 합의된 명확한 경험칙 (Rule of thumb)이 있으며, 저희도 이를 따릅니다. 만약 작업이 30초 미만의 단일 읽기 전용 (Read-only) 단계라면, 이 모든 것이 필요하지 않습니다. 하지만 워크플로가 세 개 이상의 외부 호출 (External calls)을 수행하거나, 이벤트가 발생할 때까지 몇 시간을 기다리거나, 결제 또는 삭제와 같이 되돌릴 수 없는 작업 (Irreversible actions)을 실행하는 순간, 내구성 (Durability)은 선택 사항이 아니게 됩니다. 저희는 이 패턴이 블랙박스가 되지 않도록 일련의 내구성 있는 워크플로 템플릿을 오픈 소스로 공개하고 있으며, github.com/studiomeyer-io/temporal-memory-workflows에서 확인할 수 있습니다. Temporal의 비용은 운영 오버헤드 (Operational overhead)와 코드를 작성하는 방식에 대한 몇 가지 규칙이며, 이것이 바로 임계값 미만에서는 Temporal을 선택하지 않는 정확한 이유입니다.

세 계층이 결합되는 방식

함정은 어떤 도구가 승리하는지를 묻는 것입니다. 그중 어느 것도 승리하지 않습니다. 왜냐하면 그들은 서로 다른 게임을 하고 있기 때문입니다. n8n은 시스템을 연결하고 무언가를 트리거(trigger)합니다. LangGraph는 추론(reasoning)하고 사람을 위해 일시 중지합니다. Temporal은 길고 중요한 작업이 반드시 완료됨을 보장합니다. 성숙한 설정에서는 이들이 계층적으로 쌓입니다. n8n이 이벤트를 포착하고 접착제(glue) 역할을 수행한 뒤, 사고(thinking) 과정을 LangGraph 에이전트(agent)에게 넘기고, 오래 지속되거나 되돌릴 수 없는 모든 작업은 Temporal 워크플로(workflow)로 감싸서 시스템 충돌이 문제가 되지 않도록 만듭니다. 동일한 아키텍처(architecture) 내에서 각 계층이 실제로 무엇을 했는지 관찰하는 관측성(observability) 측면은 별도의 전문 분야이며, 이는 에이전트 관측성 스택에 관한 글에서 별도로 다루었습니다.

세 가지 모두를 관통하는 가장 중요한 단 하나의 습관은 실제 비즈니스 로직(business logic)을 프레임워크(framework)로부터 분리하는 것입니다. 도메인(domain)의 규칙은 평이하고 테스트 가능한 코드에 존재해야 하며, 이 도구들은 단지 그 코드를 호출할 뿐입니다. 그렇게 한다면 워크플로를 한 계층에서 다른 계층으로 전환하는 것은 하루짜리 작업일 뿐, 재작성(rewrite)이 되지 않습니다. 중요한 부분은 결코 도구에 의존하지 않았기 때문입니다. 이를 생략하면 당신은 처음에 시작한 캔버스(canvas)와 결혼하게 되며, 이것이 팀들이 1년 전에 코드로 승격되었어야 할 n8n 워크플로 안에 갇히게 되는 방식입니다.

설정은 범용적이지만, 아키텍처는 그렇지 않다.

시장이 거꾸로 이해하고 있는 부분이 여기 있습니다. n8n을 설정하는 것은 이제 범용적인 서비스(commodity)입니다. 당신을 위해 캔버스를 그려줄 사람은 수천 명이나 되며, 도구가 이를 쉽게 만들었기 때문에(그것이 도구의 목적이었습니다) 해당 작업의 가격은 하락하고 있습니다. 만약 당신이 구매하는 것이 n8n 설정뿐이라면, 당신은 이미 구축 비용이 가장 저렴한 계층을 구매한 것입니다.

진정한 가치는 아무도 당신에게 팔지 않는 두 가지 결정에 있습니다. 첫째, 주어진 문제가 실제로 세 가지 계층 중 어느 것이 필요한지 파악하고, 두 가지 실패 모드(failure modes)를 거부할 수 있는 판단력을 갖추는 것입니다. 즉, 추론(reasoning) 문제가 썩어 문드러질 때까지 n8n의 Code 노드에 억지로 밀어 넣는 것과, 고작 50줄짜리 작업을 전혀 필요하지도 않은 내구성이 강한 워크플로(workflow)로 과잉 설계(over-engineering)하는 것을 모두 경계해야 합니다. 둘째, 선택을 다시 검토할 때 비용이 적게 들도록 경계(boundary)를 매우 깔끔하게 구축하는 것입니다. 그것이 바로 아키텍처(architecture)이며, 이는 캔버스 스크린샷에는 나타나지 않습니다.

솔직하게 말해야 할 것이 한 가지 더 있습니다. 저희의 내부 시스템을 운영하는 방식은 의도적으로 실용적이며, 자신의 한계를 알고 있는 1인 운영 체제에 충분할 정도로 조정되어 있습니다. 반면 고객 프로젝트에는 완전히 다른 장비가 투입됩니다. 동일한 세 가지 계층을 사용하되, 타인이 의존하는 시스템에 실제로 필요한 경화(hardening), 위험한 작업 전의 거버넌스 게이트(governance gates), 관측성(observability), 그리고 테스트(testing)가 포함됩니다. '우리에게 충분한 수준'과 '고객에게 적합한 수준'의 차이를 아는 것 자체가 스택(stack)을 마스터하는 과정의 일부입니다. 도구를 실행하는 것은 누구나 할 수 있습니다. 하지만 그 도구를 어디까지 활용해야 하는지 아는 것이 진짜 실력입니다.

그러므로 다음에 n8n으로 시작해서 n8n으로 끝나는 자동화 제안을 보게 된다면, 질문해야 할 것은 캔버스가 보기 좋은가가 아닙니다. 캔버스가 보여주지 않는 두 가지 경계, 즉 워크플로가 '생각'해야 할 때와 '생존'해야 할 때 어떤 일이 일어나는지를 물어야 합니다. 단순히 쉬운 세 번째 계층만이 아니라 전체 스택이 제대로 설계되기를 원하신다면, 저희가 나누는 대화는 바로 그것입니다.