n8n에서 600개 이상의 노드로 구성된 AI 오케스트레이션 인프라를 구축했습니다. 실제로 일어난 일은 다음과 같습니다.

[최대 규모일 때의 전체 인프라입니다. 600개 이상의 노드가 병렬로 에이전트를 실행하는 모습입니다.] 대부분의 사람들은 단순한 자동화(Automation)를 위해 n8n을 사용합니다. Webhook → Gmail → Slack 같은 방식 말이죠. 그것도 괜찮습니다. 원래 그렇게 만들어졌으니까요. 하지만 저는 600개 이상의 상호 연결된 노드, 병렬 에이전트 실행 파이프라인(Parallel agent execution pipelines), 동적 라우팅 계층(Dynamic routing layers), 모듈형 도구 레지스트리(Modular tool registries), 그리고 중앙 집중식 집계 시스템(Centralized aggregation systems)을 갖춘 분산형 AI 오케스트레이션 시스템(Distributed AI orchestration system)을 구축하는 데 n8n을 사용했습니다. 그 단계에 도달하기까지 수개월간의 지속적인 반복(Iteration)이 필요했습니다. 이 시스템은 결코 이렇게 거대하게 설계되지 않았습니다. 하나의 워크플로우(Workflow)가 10개가 되고, 10개가 서로 연결된 실행 체인(Execution chains)이 되면서, 결국 전체 시스템은 자동화라기보다는 분산형 인지 인프라(Distributed cognitive infrastructure)에 가까운 모습으로 변모했습니다. 이것은 그 과정이 어떻게 일어났는지, 도중에 무엇이 망가졌는지, 그리고 이를 구축하며 실제로 무엇을 배웠는지에 대한 솔직한 이야기입니다.

왜 n8n인가, 그리고 왜 놀라울 정도로 강력해졌는가
원래 문제는 간단했습니다. 저는 모든 결정 경로를 하드코딩(Hardcoding)하지 않고도 모듈식으로 생각하고, 작업을 동적으로 라우팅하며, 도구를 자율적으로 사용하고, 다단계 추론(Multi-step reasoning)을 실행할 수 있는 AI 시스템을 구축하고 싶었습니다. 당시 대부분의 프레임워크는 너무 많은 것을 숨기거나, 너무 많은 설정(Setup)을 요구하거나, 실행 중에 실제로 어떤 일이 일어나고 있는지 확인하는 것을 불가능하게 만들었습니다. n8n은 제가 예상치 못했던 문제 하나를 우연히 해결해 주었습니다. 바로 복잡한 실행 과정을 가시화(Visible)해 준다는 점이었습니다. 실행 그래프(Execution graph)를 말 그대로 직접 볼 수 있었습니다. 모든 분기(Branch), 모든 연결, 모든 데이터 흐름이 눈앞에 펼쳐져 있었습니다. 그것은 제가 시스템을 구축하는 방식 자체를 바꾸어 놓았습니다. 코드를 고민하는 대신, 실행 아키텍처(Execution architecture)를 고민하기 시작했습니다. 그 변화가 결국 600개 이상의 노드로 이어졌습니다.

아키텍처: 5개의 계층
인프라는 무작위로 구축되지 않았습니다. 각각 특정한 책임을 가진 5개의 뚜렷한 계층으로 진화했습니다.

계층 1: 트리거 계층 (Trigger Layer)
모든 것은 중앙 집중식 HTTP 트리거 시스템을 통해 유입되었습니다.

전체 인프라는 API 우선(API-first) 방식으로 구축되어, 외부 애플리케이션, 프론트엔드 시스템, 그리고 에이전트 자체가 동적으로 실행을 호출할 수 있었습니다. 모든 유입 요청은 실행 로직에 닿기 전에 정규화(Normalization) 과정을 거쳤습니다. 그 어떤 것도 가공되지 않은 상태로 파이프라인에 진입하지 않았습니다.

계층 2: 전처리 계층 (Preprocessing Layer)
어떠한 AI 실행이 시작되기 전에, 요청은 풍부해지고(Enriched), 분류되고, 변환되었습니다. 이 계층은 의도 분류(Intent classification), 역량 매핑(Capability mapping), 컨텍스트 주입(Context injection), 그리고 검증(Validation)을 처리했습니다. 대규모 운영 시 이 부분은 시스템에서 가장 조용하지만 중요한 부분이 되었습니다. 이 계층이 없었다면, 하위 에이전트 실행은 그 근원을 추적하는 것이 거의 불가능할 정도로 일관성 없는 방식으로 나타났을 것입니다.

계층 3: 라우팅 계층 (Routing Layer)
이곳은 가장 복잡한 섹션이었습니다. 라우팅 계층은 AI 실행을 위한 운영체제 스케줄러(Operating system scheduler)처럼 작동하며, 어떤 에이전트를, 어떤 순서로, 어떤 조건 하에서, 어떤 도구와 함께, 어떤 우선순위로 실행할지를 결정했습니다. 여기에는 조건부 실행 시스템, 의도 라우터(Intent routers), 역량 디스패처(Capability dispatchers), 폴백 메커니즘(Fallback mechanisms), 그리고 재시도 로직(Retry logic)이 포함되었습니다. 워크플로우가 선형적인 구조를 벗어나 트리(Tree) 구조가 되는 지점이 바로 여기입니다.

계층 4: 병렬 에이전트 실행 (Parallel Agent Execution)
이 지점에서 인프라는 진정으로 강력해졌습니다. 단일 체인 대신, 시스템은 연구 에이전트, 요약 에이전트, 검증 에이전트, 변환 계층, 분류 파이프라인 등 병렬 브랜치(Parallel branches)를 통해 특화된 에이전트들을 동시에 실행했습니다. 여러 브랜치가 동시에 실행되었으며, 그 출력값들은 나중에 하류(Downstream)에서 병합되었습니다. 다른 부분을 건드리지 않고도 새로운 브랜치를 추가함으로써 새로운 역량을 더할 수 있었습니다. 하나의 브랜치가 실패하더라도 전체 시스템이 붕괴되지는 않았습니다.

계층 5: 집계 계층 (Aggregation Layer)
모든 병렬 브랜치는 결국 중앙 집중식 집계 시스템으로 수렴되었습니다. 이 계층은 출력값을 수집하고, 충돌을 해결하며, 컨텍스트를 합성하고, 결과를 순위 매기며, 응답을 포맷팅했습니다. 이 계층은 제대로 구현하기 가장 어려웠으며, 시스템의 모든 것을 거의 무너뜨릴 뻔했던 계층이었습니다.

모든 것이 무너졌던 그날 밤

이 부분에 대해서는 구체적으로 말하고 싶습니다. 왜냐하면 "디버깅 문제"라는 모호한 표현으로는 이 정도 규모에서 작업하는 것이 실제로 어떤 느낌인지 제대로 전달할 수 없기 때문입니다. 제가 겪었던 최악의 문제는 집계 (Aggregation) 과정에서의 컨텍스트 일관성 (Context consistency) 문제였습니다. 상황은 이랬습니다: 병렬 브랜치 (Parallel branches)들이 동시에 실행되고 있었지만, 모두가 같은 시간에 종료되지는 않았습니다. 어떤 브랜치는 즉시 완료되었습니다. 다른 브랜치는 일시적인 오류 이후 재시도 루프 (Retry loop)에 진입했습니다. 세 번째 브랜치는 무거운 처리 단계 때문에 더 오래 걸렸습니다. 이 브랜치들이 마침내 집계 계층 (Aggregation layer)에서 수렴했을 때, 이들은 서로 다른 시점의 상태 (States)를 병합하고 있었습니다. 그 결과: 출력값이 일관되지 않게 되었습니다. 메모리 객체 (Memory objects)가 손상되었습니다. 한 브랜치의 유효한 데이터가 다른 브랜치의 오래되었거나 부분적인 데이터와 충돌했습니다. 그리고 가장 최악인 점은, 개별 브랜치들을 따로 분리해서 점검했을 때는 완전히 정상적으로 보였다는 것입니다. 문제는 오직 수렴 (Convergence) 단계에서만 나타났습니다. 저는 완벽하게 유효한 출력값들이 왜 집계 단계에서만 무너지는지 이해하기 위해, 수십 개의 상호 연결된 브랜치들을 가로지르며 실행 경로 (Execution paths)를 수동으로 추적하며 밤을 꼬박 새웠습니다. 이것은 단일 노드의 버그가 아니었습니다. 전체 그래프 (Graph)에 걸친 타이밍 차이로 인해 발생하는 창발적 특성 (Emergent property)이었습니다. 해결책은 엄격한 실행 장벽 (Execution barriers)을 강제하는 것이었습니다. 집계 계층은 모든 상위 브랜치(Upstream branches)가 완료되거나 명시적으로 실패한 후에만 출력을 병합해야 하며, 중간 상태 (Intermediate state)에서는 절대 병합하지 않도록 설정했습니다. 지나고 보니 단순한 방법이었습니다. 하지만 직접 데어보기 전까지는 보이지 않는 해결책이었습니다.

이 정도 규모가 실제로 내게 가르쳐준 것들

600개 이상의 노드로 시스템을 구축하면 튜토리얼이나 강의에서는 결코 배울 수 없는 것들을 배우게 됩니다. 디버깅 (Debugging)의 성격이 완전히 바뀝니다. 작은 규모에서 버그는 국소적 (Local)입니다. 하지만 이 정도 규모에서 실패는 창발적 (Emergent)입니다. 즉, 문제가 발생한 근원지와는 완전히 동떨어진 곳에서 실패가 나타납니다. 나중에 추가하는 것이 아니라, 처음부터 아키텍처 (Architecture) 내에 실행 관측성 (Execution observability)이 구축되어 있어야 합니다. 상태 (State)는 가장 어려운 문제입니다. 병렬 시스템은 서로 다른 속도로 실행되는 브랜치들 간에 상태를 공유합니다.

시스템의 서로 다른 부분이 동일한 데이터에 대해 일관되지 않은 관점을 갖게 되는 상태 드리프트 (State drift)는 지속적인 엔지니어링 과제가 됩니다. 시각적 아키텍처 (Visual architecture)에는 실질적인 한계가 있습니다. n8n의 시각적인 특성은 초기에는 가장 큰 장점이었으나, 후기에는 가장 큰 도전 과제가 되었습니다. 600개 이상의 노드(Nodes)에 도달하자 탐색이 어려워졌고, 의존성 추적 (Dependency tracing)은 고통스러워졌습니다. 실험을 빠르게 만들어 주었던 요소가 유지보수를 어렵게 만든 것입니다. 규모가 커지면 모듈화 (Modularity)는 선택이 아닌 필수입니다. 실행 로직을 하드코딩하는 대신 도구들을 재사용 가능한 호출 가능 모듈 (Callable modules)로 추상화하는 도구 레지스트리 (Tool registry) 시스템을 도입한 것이, 진화할 수 있는 시스템과 자체 복잡성으로 인해 붕괴할 시스템을 가르는 결정적인 단 하나의 아키텍처적 결정이었습니다.

더 큰 교훈
이 프로젝트를 통해 배운 가장 중요한 점은 n8n과 구체적으로 관련이 있는 것이 아닙니다. 지능 그 자체만으로는 AI 시스템의 어려운 부분이 아니라는 점입니다. LLM API를 호출하는 것은 쉽습니다. 하나의 모델이 하나의 프롬프트에 응답하도록 만드는 것은 이미 해결된 문제입니다. 진짜 엔지니어링 과제는 여러 기능을 조정하고, 병렬 프로세스 전반에 걸쳐 실행 상태 (Execution state)를 관리하며, 컨텍스트 (Context)에 따라 동적으로 작업을 라우팅하고, 부분적인 실패로부터 복구하며, 동시에 종료되지 않는 시스템들로부터 출력을 집계 (Aggregate)하려고 할 때 시작됩니다. 그것이 바로 오케스트레이션 (Orchestration)입니다. 그리고 오케스트레이션은 대부분의 AI 시스템이 조용히 실패하는 지점입니다. 모델이 틀렸기 때문이 아니라, 모델 주변의 인프라가 실제 실행의 복잡성을 처리할 수 있도록 구축되지 않았기 때문입니다. 이 프로젝트는 저에게 그 문제에 대한 교육이었습니다. 600개의 노드. 수개월의 시간. 실패해서는 안 되었던 집계 레이어 (Aggregation layer)를 응시하며 보낸 아주 긴 밤. 그 모든 순간은 가치가 있었습니다.

작성자: Nidhish Akolkar
저는 인도 푸네에 기반을 둔 컴퓨터 공학도이자 AI 시스템 엔지니어입니다. 자율형 멀티 에이전트 (Multi-agent) AI 인프라를 구축하며, 자금을 지원받는 기관 AI 및 ML 연구소를 운영하고 있습니다.
GitHub: github.com/nidhishakolkar01-lgtm
LinkedIn: linkedin.com/in/nidhish-a-akolkar-30a33238b