n8n 트리거 하나는 한 번 실행되지만, 모델 비용은 여러 번 지불하게 됩니다. 이것은 버그나 설정 오류가 아닙니다. AI Agent 노드에 문서화된 방식 그대로입니다. 캔버스 위에는 깔끔한 직사각형 하나가 놓여 있지만, 실행 패널 뒤에는 스키마(Schema)에 나타나지 않았던 일련의 호출 체인이 숨어 있습니다.

검색창에 “n8n 인공지능(n8n нейросеть)”을 입력할 때, 보통은 시각적 워크플로우(Workflow)와 그 내부에서 의사결정을 내리는 언어 모델(Language Model)의 결합을 의미합니다. 문제는 스키마(Schema)와 트레이스(Trace)가 서로 다른 두 개의 문서라는 점입니다. 스키마는 예측 가능성을 약속합니다. 반면 트레이스는 당신이 실제로 모델에 몇 번이나 요청했는지, 재시도가 몇 번 있었는지, 그리고 어느 분기에서 모든 것이 실패했는지를 보여줍니다.

다음은 하나의 에이전트 워크플로우(Agentic Workflow)에 대한 트레이싱(Tracing) 일지입니다. 논지는 단순하고 검증 가능합니다: 만약 트레이스가 스키마가 예상하는 것보다 더 많은 호출을 보여준다면, 해당 워크플로우는 확장(Scaling)하기 전에 제한 조치가 필요합니다. 첫 번째 청구서를 받은 후가 아니라, 실행 빈도를 높이기 전에 말입니다. 구역 분리에 대해 미리 말씀드리자면, 모델 비용을 어디서 지불할 것인가는 별개의 문제이며 provod.ai (러시아의 OpenRouter)가 이를 해결해 주지만, 호출 횟수를 결정하는 것은 제공업체가 아니라 당신의 스키마입니다.

왜 n8n 트리거 하나가 모델 호출 한 번이 아닌가?

“n8n 인공지능 공식 사이트(n8n нейросеть официальный сайт)”를 검색하면 docs.n8n.io로 연결되며, 그곳에 답이 있습니다. n8n 문서(docs.n8n.io, 2026년 7월 18일 참조)에 따르면, AI Agent 노드(n8n-nodes-langchain.agent)는 도구 에이전트(Tools Agent)로 작동하며 최소 하나 이상의 연결된 도구(Tool) 하위 노드를 필요로 합니다. 에이전트는 어떤 도구를 호출할지 스스로 결정합니다. 여기서 핵심 단어는 “스스로”입니다. 하나의 트리거는 고정된 호출을 생성하는 것이 아니라 내부 루프(Internal Loop)를 생성합니다: 모델이 도구 스키마를 살펴보고, 동작을 요청하고, 결과를 받은 뒤, 다시 모델에 요청하는 과정을 거칩니다.

Tools Agent 문서(2026년 7월 18일 참조)에는 다음과 같이 명시되어 있습니다: n8n의 자체 실행 루프(execution loop)는 모델에 도구 스키마(tool schema)를 전송하며, 모델이 독립적인 동작을 요청할 경우 도구들을 병렬로 호출할 수 있습니다. 이는 로그에서 모델이 다시 호출되기 전, 여러 개의 tool-call 기록이 연속적으로 나타나는 것으로 확인할 수 있습니다. 즉, 캔버스(canvas) 상의 하나의 "에이전트(agent)" 노드가 단 한 번의 실행 과정 동안 내부적으로는 모델에 대한 여러 번의 호출에 해당할 수 있다는 의미입니다.

여기서 비용을 지불하는 사람에게 중요한 시사점이 도출됩니다. "n8n에서 AI 에이전트를 만드는 방법"과 같은 지침들은 거의 항상 에이전트가 작동하고 응답을 한다는 단계에서 끝납니다. 하지만 "작동한다"는 것과 "예측 가능한 비용이 든다"는 것은 동일하지 않습니다. 워크플로우(workflow) 설계도는 노드 간의 연결 관계를 보여줄 뿐, 실제 호출 횟수를 보여주지 않습니다. 캔버스는 경로 계획(route plan)이지 비용 계산기(counter)가 아님에도 불구하고, 사람들은 이를 견적서처럼 읽곤 합니다.

여기서 지식의 경계를 명확히 할 필요가 있습니다. 트레이싱(Tracing)은 명시적인 노드와 재시도(retries)를 확실하게 보여줍니다. 이는 문서화된 동작 방식에서 직접적으로 도출되는 결과입니다. 루프(loops), 메모리(memory), 그리고 재시도가 호출 횟수를 증가시킬 것이라는 점은 가능성이 높다고 판단하지만, 이는 어디까지나 가능성입니다. 모델의 종류와 호출 빈도를 고려하지 않은 특정 실행의 비용은 그 누구도 단정 지을 수 없습니다. n8n의 어떤 페이지에서도 "전형적인" 트리거가 얼마나 많은 숨겨진 호출을 발생시키는지 명시하지 않습니다. 이 수치는 벤더(vendor)가 제공하는 것이 아니라, 오직 당신의 트레이스(trace)를 통해서만 생성됩니다.

관찰 가능한 트레이스는 캔버스가 아닌 Executions에 존재한다

실질적인 첫 번째 단계는 캔버스를 신뢰하는 것을 멈추고 Executions를 여는 것입니다. 이는 표준적인 뷰(view)이며, n8n 문서(2026년 7월 18일 참조)는 그 기능을 상세히 설명하고 있습니다. 과거의 모든 실행 내역을 열어보고, 각 노드의 입력(input)과 출력(output)을 확인하며, 상태(Failed, Running, Success, Waiting)나 저장된 사용자 데이터에 따라 필터링할 수 있습니다. 또한 실패한 실행을 현재 저장된 워크플로우(workflow) 또는 원래의 워크플로우로 재실행할 수도 있습니다. 호출과 재시도에 대한 관찰 가능한 트레이스는 바로 여기서 비롯됩니다.

작동 규칙은 간단합니다. 모든 호출(call)과 모든 재시도(retry)에 표시를 남기세요. 실행(run)을 열고, 노드(node)를 위에서 아래로 따라가며 계산하면 됩니다. 하나의 AI Agent 노드 내부에서 모델이 몇 번 호출되었는지, 다음 모델 호출이 일어나기 전까지 얼마나 많은 도구 호출(tool-call) 기록이 지나갔는지, 어디에서 반복이 발생하는지 확인하십시오. 그러면 당신의 손에는 추측이 아닌 목록이 쥐어집니다. '이 노드는 이만큼의 호출 횟수를 가졌고, 이 분기(branch)에서 오류가 발생했다'는 식의 목록 말입니다. 트레이싱(tracing)을 시작할 때 가졌던 가설, 즉 '하나의 트리거가 여러 개의 숨겨진 호출을 생성할 수 있다'는 가설이 맞는지 틀린지는 이제 느낌이 아닌 숫자로 확인하게 됩니다.

Диагностический маршрут одного прогона n8n: один триггер разворачивается в цепочку LLM-вызовов и tool-call внутри узла AI Agent

이 방법에 대해 한 가지 주의할 점이 있습니다. 단 하나의 트레이스(trace)가 미래의 모든 볼륨을 예측할 수는 없습니다. 그것은 특정 버전의 노드에서 특정 입력값이 어떻게 작동하는지를 보여줄 뿐입니다. n8n은 노드 버전을 자주 변경합니다. 예를 들어, AI Agent 노드의 에이전트 유형 설정은 버전 1.82.0에서 삭제되었습니다. 따라서 현재 사용 중인 n8n 버전과 대조하여 노드의 최신 파라미터를 확인해야 합니다.

호출을 증폭시키는 세 가지 노드

에이전트(Agent)는 이미 살펴보았습니다. 에이전트는 내부적으로 호출을 증폭시킵니다. 하지만 에이전트 주변에는 보통 두 개의 블록이 더 배치되는데, 이들은 설치하기 편리하여 과소평가하기 쉽지만 각각 역시 증폭기 역할을 합니다.

첫 번째는 Loop Over Items (Split in Batches)입니다. 문서(2026년 7월 18일 기준)에 따르면, 이 노드는 입력 데이터를 배치(batch)로 나누고 모든 요소를 처리할 때까지 각 배치에 대해 하위 노드들을 재실행하며, 별도의 If 노드 없이 스스로 멈춥니다. 편리하게 들릴 수 있습니다. 하지만 배치의 각 반복(iteration)은 루프 본문에 있는 모든 하위 노드를 다시 실행하며, 여기에는 모델을 호출하는 모든 노드가 포함됩니다. 입력 데이터가 100개라면 분기(branch)가 100번 실행되는 것입니다. 만약 해당 분기 내부에 이전 섹션에서 다룬 내부 루프를 가진 에이전트가 있다면, 증폭 계수들은 서로 곱해지게 됩니다.

둘째 - Simple Memory (Window Buffer Memory). 이 노드는 Session Key 아래에 대화 기록을 저장하며, 이전 상호작용을 얼마나 포함할지를 결정하는 "Context Window Length" 파라미터를 가집니다 (docs.n8n.io, 2026년 7월 18일 참조). 여기서 중요한 세부 사항이 있습니다. n8n의 문서는 이 파라미터의 기본값(default value)을 명시하지 않습니다. 이는 연구의 결함이 아니라 벤더(vendor) 문서 자체의 공백입니다. 저장된 과거의 각 상호작용은 해당 세션의 이후 모델 호출 시 다시 재생됩니다. 윈도우(window)가 길어질수록 매 요청마다 더 많은 컨텍스트(context)가 전달되며, 이는 대화의 다음 호출 비용이 더 높아짐을 의미합니다.

Сравнительная таблица трёх узлов n8n, которые множат число вызовов модели, и стоп-условий для каждого

이 모든 것을 하나의 그림으로 모아보면, 왜 n8n AI 에이전트를 구축하는 것이 예상치 못한 청구서로 쉽게 이어지는지 알 수 있습니다. 에이전트는 내부에서 호출을 증폭시킵니다. 루프(Loop)는 외부에서 에이전트를 증폭시킵니다. 메모리(Memory)는 각 호출의 무게를 키웁니다. 워크플로우 캔버스 상에서 이 노드들 중 어느 것도 위험해 보이지 않습니다. 모두 단 하나의 직사각형으로 그려지기 때문입니다.

비용이 발생하고 오류가 발생하는 분기(branch)를 어떻게 식별할 것인가?

다음은 가장 자주 간과되는 부분입니다. 두 가지 서로 다른 메커니즘이 존재하며, 이를 혼동하는 것은 n8n이 실제로 실패를 어떻게 라우팅(routing)하는지 잘못 설명하는 것과 같습니다.

첫 번째는 노드 수준의 Retry On Fail입니다. 이 설정은 실패한 노드를 자동으로 재시도합니다: Max Tries(최대 시도 횟수), Wait Between Tries(시도 간 대기 시간), 지수 백오프(exponential backoff) 등이 포함됩니다. 요청 제한이 있는 API의 경우, n8n은 Wait Between Tries를 허용된 간격보다 높게 설정할 것을 권장합니다. 예를 들어, 초당 1회 제한이라면 1000ms로 설정하는 식입니다. 여기서 예산 측면에서 매우 중요한 점은 다음과 같습니다: 각 재시도는 무료 시도가 아니라, 모델이나 API에 대한 추가적인 실제 호출이라는 점입니다. 모델이 포함된 노드에서 3번의 리트라이(retry)가 발생했다면, 이는 한 번의 호출이 아니라 세 번의 유료 호출이 발생한 것입니다.

두 번째 메커니즘은 프로세스 전체 수준에서의 에러 워크플로우 (error workflow)입니다. 오류 처리에 대한 n8n의 공식 권장 사항(2026년 7월 18일 기준)은 Workflow Settings에서 에러 워크플로우를 설정하는 것을 중심으로 하며, 이는 별도의 Error Trigger 노드에 의해 실행됩니다. 여기에 의도적인 실패를 강제하기 위한 Stop And Error 노드가 추가됩니다. 노드 수준에서의 리트라이 (retry) 및 실패 시 계속 (continue-on-fail) 동작은 워크플로우 수준의 이러한 오류 라우팅과는 별개의 이야기입니다. 이 둘은 독립적으로 설정되는 두 가지 메커니즘입니다.

Error Trigger에 관한 중요한 경계가 있습니다. 문서에 따르면 이 노드는 수동 테스트 실행이 아닌 워크플로우의 자동 실패 시에만 작동하며, 실행 ID (execution ID), 오류 메시지, 스택 트레이스 (stack-trace), 실패한 노드, 그리고 워크플로우 및 실행 메타데이터를 전달받습니다. 이는 실패한 브랜치를 표시하기 위한 구조적 신호이지만, 이미 한 번 실패한 이후에만 작동합니다. 오류 처리는 사후적으로 실패를 포착하는 것이지, 첫 번째 유료 호출이 실패하는 것을 방지하지는 못합니다.

Схема двух путей обработки сбоя в n8n: расходный Retry On Fail на уровне узла и error workflow через Error Trigger

여기서 비용 결제에 관한 솔직한 세부 사항을 언급할 필요가 있습니다. 리트라이 (retry)가 가장 뼈아픈 경우는 모델로 가는 채널이 일시적으로 사용할 수 없을 때입니다. 노드가 실패하면 Retry On Fail이 성실하게 반복을 시도하고, 각 시도마다 비용이 발생하지만 결국 동일한 벽에 부딪히게 됩니다. 이러한 고통의 일부를 완화해 주는 것은 마법이 아니라 변수 하나를 바꾸는 것입니다. provod.ai (러시아의 OpenRouter)에서는 거의 모든 최신 모델에 대한 접근이 하나의 OpenAI 호환 API를 통해 이루어집니다. 따라서 다른 모델이나 다른 제공업체로 전환하기로 결정했을 때, 스키마를 다시 작성할 필요 없이 HTTP Request 노드나 모델 자격 증명 (credentials)에서 기본 URL (base URL)과 키 (key)만 변경하면 됩니다.

하지만 이것이 리트라이 (retry) 횟수를 줄여주지는 않습니다. 제공업체를 변경하는 것은 모델에 대한 접근성 문제를 해결하는 것이지, 스키마 내의 불필요한 반복을 해결하는 것이 아니기 때문입니다. 제한 사항 (limits)은 여전히 사용자가 직접 설정해야 합니다.

빈도를 높이기 전에 어디에 제한(limit)을 설정해야 하는가?

여기서의 행동 순서는 중립적이지 않으며, 저는 이를 솔직하게 말씀드리겠습니다. 제한(limits)과 오류 처리(error handling)는 실행 빈도를 높이기 전에 설정해야 합니다. 이유는 간단합니다. 빈도가 낮고 트레이스(trace)를 눈으로 읽을 수 있을 때 제한을 설정하는 것이 더 쉽기 때문입니다. 빈도를 먼저 높이면, 동일한 결함이 볼륨에 따라 배수로 늘어나기 시작합니다.

이 결정에는 대가가 따릅니다. 중단 조건(stop-conditions)은 예산을 보호하지만 일부 작업을 놓치게 만듭니다. 도구(tool) 반복 횟수에 대한 제한은 에이전트가 복잡한 체인(chain)을 완료하기 전에 중단시킬 수 있습니다. 배치(batch) 크기 제한은 일부 요소를 다음 실행으로 남겨둡니다. 당신은 비용 예측 가능성을 위해 처리의 완전성을 의도적으로 희생하는 것입니다. 감독 없이 작동하는 비용 발생 분기(expenditure branch)의 경우, 저는 이러한 교환이 정당하다고 생각합니다.

제한이 실제로 설정되는 지점들을 목록으로 나누어 보겠습니다:

워크플로우를 확장(scale up)해서는 안 되는 기준 또한 미리 확정해 두어야 합니다. 트레이스에 반복(repetition) 표시가 없다면 확장하지 마십시오. 비용 발생 분기에 제한이 없다면 확장하지 마십시오. 그리고 실행 기록(Executions)을 통해 관찰 가능한 트레이스를 제공하지 않는 노드를 가진 워크플로우는 확장하지 마십시오. 기록이 없다면 당신은 눈을 감고 계산하는 것과 같습니다.

반대의 순서, 즉 지금 빈도를 높이고 청구서가 날아올 때 제한을 추가하는 방식은 유혹적이지만 한 가지 기준에서 패배합니다. 청구서가 도착할 시점에는 이미 결함이 볼륨만큼 증폭되어 있으며, 트레이스를 눈으로 읽을 수 없는 상태가 되기 때문입니다.

Решающая развилка оператора n8n: отвергнутый путь через рост частоты и принятый путь через лимиты и обработку ошибок

이 트레이싱(tracing)이 해결하지 못하는 것은 무엇인가?