n8n 자동화, 에이전트와 워크플로우 중 무엇을 쓸까

통제된 지원 대화 30턴에서 두 설계 모두 동일하게 20건을 완료했습니다. 다만 새 n8n 에이전트는 범위가 제한된 워크플로우를 40회 호출했고 대화 세션 20개를 유지했습니다. n8n 자동화에서 따져야 할 것은 어느 쪽이 더 많이 자동화하느냐가 아닙니다. 순서가 정해져 있으면 워크플로우가 주도하고, 대화가 다음 단계를 결정해야 할 때만 에이전트를 써야 합니다.

n8n 자동화의 선택 기준: 에이전트 vs 워크플로우

실행이 시작되기 전에 순서를 그릴 수 있다면 n8n 워크플로우를 선택합니다. 사용자의 말, 툴의 반환값, 또는 이미 확인한 대화 내용에 따라 다음 유용한 행동이 달라진다면 n8n 에이전트를 선택합니다. 실제 운영의 고객 지원과 업무 자동화에서는 대개 하이브리드 설계가 가장 탄탄합니다. 에이전트가 선택하고, 범위를 좁힌 워크플로우가 실제 작업을 수행하는 구조입니다.

이 차이는 자동화 안에 모델이 들어가느냐보다 중요합니다. 워크플로우가 모델을 호출하더라도 흐름은 결정론적일 수 있습니다. 반대로 에이전트가 워크플로우를 호출하더라도 다음 툴을 캔버스가 아니라 모델이 고른다면 에이전트 방식입니다.

결정을 가르는 질문은 간단합니다. 다음 단계를 누가 결정해야 할까요? 자동화 설계자가 결정해야 한다면 워크플로우가 주도해야 합니다. 현재 대화와 툴 결과를 읽은 모델이 결정해야 한다면 에이전트를 쓸 차례입니다. n8n도 출시 자료에서 같은 기준을 제시합니다. 고정된 순서는 워크플로우에, 열려 있는 요청은 스스로 단계를 판단하는 에이전트에 맞다고 n8n 출시 설명에서 명확하게 밝힙니다.

9월 25일, n8n에서 무엇이 바뀌었나

n8n은 2026년 9월 25일에 새 Agents 화면을 공개했습니다. 이제 Agent는 고유한 모델, 지침, 툴, 메모리, 세션, 초안, 게시 버전, 채널, 스케줄을 가진 독립적인 프로젝트 자산입니다. 특정 캔버스 안이 아니라 워크플로우 옆에 자리합니다. 현재 n8n Agents 문서는 고정된 워크플로우로 처리하기에는 너무 열려 있는 업무를 담는 곳으로 이를 설명합니다.

여러 경로에서 공유하는 하나의 정체성이 이번 변화의 핵심입니다. 게시된 하나의 Agent가 채널에서 답하고, 스케줄에 맞춰 실행되며, 다른 워크플로우의 메시지를 받을 수 있습니다. 세션 기록에는 대화, 툴, 출력, 오류, 대기 중인 승인이 담깁니다. 초안을 편집해도 게시된 버전이 조용히 바뀌지는 않습니다.

그렇다고 모델에게 모든 시스템을 폭넓게 열어 줄 이유는 없습니다. 워크플로우 툴을 쓰면 이름이 붙은 입력, 통제된 인증 정보, 예측 가능한 출력, 필요할 때 적용하는 승인 경계로 행동 범위를 좁힐 수 있습니다. 초기 사용자의 반응도 이 핵심을 잘 짚었습니다. 기존 워크플로우를 툴로 재사용하는 것이 채팅 래퍼를 하나 더 붙이는 것보다 훨씬 유용하다는 평가였습니다.

n8n AI Agent 워크플로우 빌더, 무엇이 달라졌나

기존 방식은 Chat Trigger, 메모리, AI Agent 노드, 모델, 툴을 조합해 워크플로우 안에 에이전트를 만들었습니다. 이 구조는 여전히 작동합니다. 새 빌더는 지속되는 Agent의 정체성, 세션, 버전, 여러 입력 경로를 공유 자산 안으로 옮겼습니다.

이는 화면만 바꾼 것이 아닙니다. 업무의 소유권이 다음처럼 나뉩니다.

• Agent는 대화와 툴 선택 루프를 책임집니다.
• 게시된 워크플로우는 계정 정보 조회나 답변 초안 작성과 같이 범위가 한정된 작업을 책임집니다.
• 호출하는 채널, 스케줄, 또는 워크플로우는 Agent가 일을 받는 시점을 책임집니다.
• 승인자는 민감한 툴의 최종 결정을 책임집니다.

n8n Agents와 AI Agent 노드의 차이

기존 AI Agent 노드는 여전히 워크플로우의 노드입니다. 채팅 모델과 최소 하나의 툴에 연결된 뒤, 해당 워크플로우가 실행되는 동안 툴을 선택합니다. n8n은 기존 AI Agent 노드로 만든 자동화도 계속 작동한다고 밝혔습니다. 현재 노드 문서도 모델과 툴을 결합한 이 설계를 그대로 설명합니다.

한 워크플로우에 속한 에이전트라면 그 노드를 쓰고, 해당 워크플로우가 트리거, 메모리 구성, 생명주기를 소유하게 합니다. 하나의 정체성을 여러 대화에 걸쳐 유지하거나 여러 곳에서 호출해야 한다면 새 Agent를 쓸 때입니다. 기존 노드 기반 에이전트를 계속 사용하기 위해 반드시 마이그레이션할 필요는 없습니다.

같은 고객 지원 업무를 두 방식으로 구현한 결과

통제 비교는 일회용 로컬 n8n 2.40.7 인스턴스, 결정론적으로 동작하는 하나의 OpenAI 호환 로컬 모델 엔드포인트, 고정된 JSON 픽스처를 사용했습니다. 모델 품질이나 클라우드 지연 시간이 아니라 라우팅과 오케스트레이션을 비교한 테스트입니다.

n8n AI Agent 예제: 고객 지원 분류

픽스처에는 가상의 고객 지원 티켓 20개가 들어 있었습니다.

• 10개는 티켓 ID, 계정 ID, 제품 영역, 문제가 명시된 고정 형식으로 도착했습니다.
• 다른 10개에서는 계정 ID와 제품 영역을 의도적으로 뺀습니다. 유용한 시스템이라면 추가 질문을 한 번 해야 했습니다.
• 모든 최종 케이스의 기대 큐는 billing, technical, general 중 하나로 고정했습니다.

각 설계는 같은 사용자 대화 30턴을 처리했습니다. 정보가 완전한 티켓 10개는 각각 한 턴이 걸렸습니다. 불완전한 티켓 10개는 첫 질문과 후속 답변을 위해 20턴이 더 필요했습니다.

1. 1

   고정된 순서 구축

   워크플로우는 노드 3개로 구성했습니다. 웹훅이 티켓을 받고, 공유 로컬 모델이 분류한 뒤, 파서가 구조화된 JSON을 반환했습니다. 모든 수신 메시지는 항상 이 순서대로 노드를 거쳤습니다.

2. 2

   Agent 구축

   Agent에는 같은 모델, 명확한 분류 지침, 저장된 세션 메모리, 게시된 워크플로우 툴 3개를 연결했습니다. 툴은 Get Account Context, Draft Support Reply, Page On Call입니다. 첫 두 툴은 바로 사용할 수 있지만 Page On Call은 승인이 필요했습니다.

3. 3

   완료된 작업 채점

   출력에 기대한 최종 큐가 들어 있어야 해당 케이스를 완료로 계산했습니다. 확인 질문, 실행, 세션, 모델 엔드포인트 요청, 워크플로우 툴 호출, 실패, 불필요한 행동은 각각 따로 기록했습니다.

두 설계 모두 최종 케이스 20개를 기대한 큐로 보냈습니다. 이 결과가 에이전트와 워크플로우의 판단력이 동일하다는 뜻은 아닙니다. 테스트는 오케스트레이션만 분리해 보려고 의도적으로 결정론적 스텁을 썼습니다. 추가 장치가 드러난 지점이 핵심입니다. 고정 워크플로우는 턴당 모델에 한 번 요청했지만, Agent는 툴을 고르고 결과를 받아 답을 만들며 실행을 유지하는 동안 모델을 반복해 호출했습니다.

Agent의 엔드포인트 요청 100회는 이 로컬 설정에서 스트리밍 추론 또는 툴 루프 요청 70회와 비스트리밍 보조 요청 30회로 구성됐습니다. 이 수치를 보편적인 배수로 보지 말고 제공자 사용량을 측정해야 한다는 경고로 받아들여야 합니다. 모델, 메모리 구성, 프롬프트, 제품 버전이 달라지면 요청 횟수도 바뀔 수 있습니다.

n8n 에이전트를 써야 할 때

대화에 따라 계획이 바뀔 때 Agent를 쓰는 것이 맞습니다. “청구 내용이 잘못됐어요”라고 시작한 지원 요청은 계정 조회, 추가 질문, 정책 확인, 행동 전 승인 중 어느 쪽으로 이어질지 알 수 없습니다. 부족한 정보가 들어와야 올바른 분기를 결정할 수 있습니다.

계획이 이미 정해져 있다면 워크플로우를 쓰는 편이 낫습니다. 매일 밤 내보내기, 웹훅에서 CRM으로 동기화, 잠재 고객 정보 보강은 명시적인 노드, 예측 가능한 재시도, 모델의 결정을 다시 구성하지 않고도 확인할 수 있는 실행 경로에서 이점을 얻습니다.

통제와 디버깅의 승자: 워크플로우

가능한 다음 노드가 캔버스에 드러나므로 워크플로우를 이해하기가 더 쉽습니다. 결정론적 프로세스에 문제가 생기면 실행 기록에서 실패한 노드를 바로 확인할 수 있습니다. 자금 이동, 레코드 삭제, 권한 변경처럼 유연성이 장점보다 부담이 되는 작업에서는 이 방식이 기본값이 되어야 합니다.

Agent 세션은 다른 유형의 추적 기록을 제공합니다. 메시지, 툴 선택, 출력, 오류, 승인을 확인할 수 있습니다. 유용한 기록이지만 확률적인 결정을 명시된 그래프로 바꾸어 주지는 않습니다. 순서가 달라질 필요가 전혀 없다면 추론 루프를 더하는 것은 또 하나의 실패 지점만 만듭니다.

대화와 상태 관리의 승자: Agent

여러 턴에 걸쳐야 하는 업무에서는 Agent가 앞섭니다. 세션이 저장되고 재개될 수 있으며, 세션 메모리가 기본으로 켜져 있습니다. 픽스처에서 정보가 부족한 티켓 10개는 누락됐던 계정 및 제품 정보가 들어왔을 때 기존 세션을 그대로 이어갔습니다. 고정 워크플로우가 같은 답을 낸 것은 후속 메시지에 무상태 분류기가 필요로 하는 맥락이 다시 들어 있었기 때문입니다.

실제 고객 지원에서는 이 간격이 더 커집니다. 두 번째 메시지가 “EU 계정이에요”라는 말뿐이라면 워크플로우는 이전 티켓을 데이터 저장소에서 다시 불러오거나 입력으로 대화 내역을 받아야 합니다. Agent 세션은 이미 해당 대화 맥락을 가지고 있습니다. 에피소드 메모리를 쓰면 세션 간에도 정보를 이어갈 수 있지만, 현재 n8n에서는 이 기능에 OpenAI 인증 정보가 필요합니다.

민감한 행동의 승자: 앞단은 Agent, 실행은 워크플로우

가장 안전한 하이브리드 설계는 읽기 전용 툴을 Agent에 자유롭게 제공하되, 부수 효과가 있는 작업에는 승인을 둡니다. 별도의 긴급 티켓 스모크 테스트에서 Agent는 읽기 전용 계정 조회를 완료한 뒤 Page On Call을 선택하고 멈췄습니다. 승인자가 툴 호출을 허용하기 전에는 호출 워크플로우가 실행되지 않는 구조였습니다.

올바른 보안 모델은 명확합니다. Agent는 행동을 제안하거나 요청할 수 있지만, 영향 범위는 좁은 워크플로우와 명시적 승인이 통제합니다. 인증 정보는 툴에 연결되므로 Agent가 모든 작업을 수행할 수 있는 폭넓은 인증 정보를 가질 필요가 없습니다.

최종 승자: 하이브리드

새 화면의 가장 강력한 쓰임새는 워크플로우를 대체하는 것이 아니라, 그 위에 놓는 대화형 제어 계층입니다. Agent는 의도를 해석하고, 묻고, 선택합니다. 워크플로우는 검증하고, 시스템을 변경하고, 구조화된 결과를 돌려줍니다. 이렇게 나누면 작업 자체와 그 작업을 선택하는 모델을 독립적으로 테스트할 수 있습니다.

n8n Agents의 실행 비용

2026년 9월 26일 기준, n8n은 Agents에 별도 요금제를 매기지 않습니다. Agent 한 턴이 한 번의 실행으로 계산되며, Agent와 워크플로우의 실행은 같은 할당량에서 차감됩니다. n8n의 출시 글은 이 안에서 호출된 워크플로우 툴과 서브 에이전트는 별도의 요금제 실행으로 세지 않는다는 중요한 내용도 밝힙니다.

현재 연간 결제 기준 요금은 Starter가 월 $20에 2,500회 실행, Pro가 월 $50에 10,000회 실행입니다. 연간 결제 토글에 17% 절감이 표시된 n8n 요금 페이지에서 두 가격을 확인했습니다. 전체 요금제의 장단점은 별도의 n8n 요금 분석에서 다룹니다.

브리프의 계획 시나리오인 대화 200건, 각 3턴을 계산해 봅시다.

• Agent 실행 600회는 200 × 3에서 나옵니다. 내부 워크플로우 툴은 할당량 계산에서 별도 실행으로 더해지지 않습니다.
• Starter에서 $20 ÷ 2,500은 포함된 실행당 구독료 할당액인 $0.008입니다. 600턴은 월 구독료 중 $4.80을 배분하며 1,900회의 실행을 남깁니다.
• Pro에서 $50 ÷ 10,000은 포함된 실행당 구독료 할당액인 $0.005입니다. 같은 600턴에 $3.00을 배분하며 9,400회의 실행을 남깁니다.

이 몫은 추가 청구액이 아니라 구독료를 배분한 계산값입니다. 601번째 턴도 요금제 한도 안에 있다면 Starter 청구서에 $0.008 항목이 추가되지 않습니다.

경계를 가르는 것은 Agent와 워크플로우 간의 할인 차이가 아니라 할당량입니다. Starter는 3턴 대화 833건을 2,499회 실행으로 처리할 수 있고, 834번째 대화는 2,502회에 도달해 2,500회 한도를 넘습니다. Pro는 그런 대화 3,333건을 9,999회 실행으로 처리하며, 3,334번째 대화는 10,002회에 도달해 10,000회 한도를 넘습니다.

고정 워크플로우가 채팅 메시지마다 웹훅을 한 번 받는다면, 같은 600턴에 실행 600회를 씁니다. 따라서 실행 요금은 무승부입니다. 다만 고정 워크플로우는 Agent가 툴 주변에서 몇 번의 판단을 내릴 때 모델을 한 번만 호출할 수 있으므로 모델 계층에서는 더 저렴할 수 있습니다.

모델 사용량은 실행 할당량과 별개입니다. n8n Gateway 크레딧은 별도의 선불 잔액을 사용하며, 직접 선택한 제공자 인증 정보를 쓸 수도 있습니다. Gateway 크레딧 문서에 따르면, 잔액이 없을 때 소유자가 충전하거나, 자동 충전을 켜거나, 인증 정보를 바꾸기 전까지 지원 노드가 실패합니다. 로컬 테스트의 30회 대 100회 요청 결과가 실행 횟수와 모델 지출을 모두 대시보드에 넣어야 하는 이유입니다.

세션, 버전, 승인, 워크플로우 호출을 실무에서 쓰는 법

새 Agent는 여러 입력 경로가 같은 행동을 필요로 할 때 가치가 있습니다. n8n은 모든 대화를 세션으로 저장하며 메시지, 툴, 대기 중인 승인도 포함합니다. 측정 픽스처는 티켓마다 하나씩 세션 20개를 만들었고, 후속 대화가 필요한 티켓 10개는 둘째 턴에서 기존 세션을 이어갔습니다.

버전 관리는 실험과 운영을 분리합니다. 편집하면 초안이 자동 저장되지만, Publish는 채널, 스케줄, 운영 채팅에서 쓰는 스냅샷을 만듭니다. 로컬 확인에서 초안에만 지침을 추가했을 때 새 초안 버전이 만들어졌지만, 활성 버전 ID와 게시된 지침은 그대로였습니다. 운영 중에 프롬프트를 다듬을 때 필요한 동작입니다.

n8n Message an Agent: 하나의 Agent를 여러 경로에서 호출하기

Message an Agent 노드를 쓰면 워크플로우에서 기존의 게시된 Agent를 호출할 수 있습니다. 노드 2개로 만든 스모크 워크플로우가 같은 Support Triage Agent에 청구 티켓을 보내자 완전한 결과가 돌아왔고, 범위가 제한된 동일한 툴 호출 2건이 기록됐습니다. 계정 맥락 조회 후 답변 초안 작성이었습니다. 이 노드는 사용자 정의 세션 키도 받으므로, 워크플로우가 대화를 새로 시작하지 않고 기존 대화를 이어갈 수 있습니다.

이 구조는 다음과 같은 구성 방식을 만듭니다.

1. 결정론적 워크플로우가 이벤트를 받고 검증합니다.
2. Message an Agent가 대화형 판단에 필요한 정보만 게시된 Agent에게 넘깁니다.
3. Agent가 범위를 좁힌 워크플로우 툴 중에서 선택합니다.
4. 호출한 워크플로우는 Agent의 텍스트, 사용량, 툴 호출 로그, 세션 참조를 받습니다.

이 아키텍처를 순환으로 만들지 마세요. Agent를 호출하는 워크플로우를 동시에 그 Agent의 툴로 연결하면 안 됩니다. 입력 경로 워크플로우와 작업 워크플로우를 분리하고, 경계가 드러나는 이름을 붙입니다.

승인도 같은 세션 추적 기록 안에 들어갑니다. 민감한 툴이 선택되면 Agent가 멈추고 인자를 보여 줍니다. Approve를 선택하면 그 지점에서 이어서 실행하고, Reject는 행동을 취소합니다. 승인자가 인증 정보 사용 전에 제안된 툴과 입력값을 볼 수 있으므로, 막연한 ‘휴먼 인 더 루프’ 약속보다 실질적입니다.

고위험 자동화라면 세션 기록만으로는 부족합니다. Agent 실패와 의심스러운 툴 선택을 독립적인 검토 경로로 보내고, 관련 데이터에 맞게 보존, 비식별화, 알림 정책을 맞춥니다. 별도의 AI 에이전트 실패 분석 가이드가 이 관측성 계층을 자세히 다룹니다.

모두 다시 만들지 않고 전환하는 법

전환은 안정적인 워크플로우를 프롬프트 안에 다시 그리는 것이 아니라, Agent 주변을 감싸는 방식이어야 합니다. 기존 워크플로우에는 이미 인증 정보, 검증, API 호출, 변환, 실패 처리라는 핵심 자산이 들어 있습니다.

1. 1

   결정론적 중심축 유지

   스케줄, 웹훅, 검증, 돌이킬 수 없는 쓰기 작업은 워크플로우에 남깁니다. 고정된 순서를 에이전트 아키텍처처럼 보이게 하려고 옮기지 않습니다.

2. 2

   행동을 계약으로 변환

   호출 가능한 각 워크플로우에 좁은 입력 스키마와 구조화된 출력을 부여합니다. 승인이 필요한 곳에만 적용할 수 있도록 읽기 전용 조회와 부수 효과가 있는 작업을 분리합니다.

3. 3

   최소한의 툴만 연결

   한 업무에 필요한 소수의 워크플로우로 Agent를 시작합니다. 구체적인 이름과 설명은 모델의 선택을 돕고 세션 로그를 감사하기 쉽게 만듭니다.

4. 4

   프롬프트가 아니라 대화를 테스트

   고정 형식 케이스, 정보가 부족한 케이스, 반복 메시지, 안전하지 않은 요청을 사용합니다. 게시된 스냅샷을 운영에 내보내기 전에 최종 출력, 확인 질문 턴, 툴 호출, 거부된 행동, 모델 사용량을 채점합니다.

5. 5

   입력 경로는 마지막에 추가

   게시된 Agent가 안정된 뒤에 채널, 스케줄, 또는 Message an Agent 워크플로우를 연결합니다. 여러 캔버스에 지침을 복제하지 말고 같은 정체성을 재사용합니다.

순서가 고정돼 있거나, 현재 AI Agent 노드가 한 워크플로우에 속해 있거나, 컴플라이언스 체계가 Preview 소프트웨어를 허용하지 않는다면 전환하지 않는 편이 낫습니다. 셀프호스팅 Enterprise와 큐 모드 배포의 답은 더욱 분명합니다. 지금은 기다려야 합니다. n8n을 포함한 더 큰 자동화 스택을 고르고 있다면 AI 자동화 툴 비교에서 더 넓은 맥락을 확인할 수 있습니다.

마이그레이션 비용은 노드 수가 아니라 인터페이스에 숨어 있습니다. 모든 워크플로우 툴에는 명확한 입력, 통제된 인증 정보, 예측 가능한 출력, 중복에 안전한 행동, 승인 담당자가 필요합니다. Agent는 원래 설계자가 예상하지 않은 순서로 같은 툴을 호출할 수 있으므로 약한 계약을 빠르게 드러냅니다.

Preview 제약과 최종 권고안

n8n Agents는 Preview 단계입니다. n8n Cloud에서는 최신 안정 버전을 쓰는 모든 사용자에게 제공됩니다. 셀프호스팅은 2.32.3부터 지원하며 수동 설정에서 agents 모듈을 활성화해야 합니다. 전체 AI 보조 빌더는 선택 사항이지만, 셀프호스팅 지식 베이스에는 Daytona 샌드박스가, 채널에는 공개 웹훅 URL이 필요합니다.

매력적인 마이그레이션을 멈출 수 있는 제약은 두 가지입니다. Agents는 셀프호스팅 Enterprise에서 사용할 준비가 되지 않았고 큐 모드를 지원하지 않습니다. n8n은 Telegram 같은 셀프호스팅 채널 연결이 실패할 수 있다고도 경고하므로, 현재는 일반 모드가 권장됩니다.

현실적인 운영 아키텍처는 보수적이어야 합니다. 이미 알고 있는 모든 순서는 워크플로우가 주도하게 합니다. 대화가 다음 단계를 골라야 하는 바로 그 지점에만 Agent를 둡니다. 좁은 워크플로우를 툴로 제공하고, 세션을 저장하고, 테스트한 스냅샷을 게시하고, 중요한 부수 효과의 앞에는 승인을 둡니다.

그렇게만 해도 Preview Agent에게 자동화 시스템 전체를 맡기지 않고 새 화면의 자율성을 활용할 수 있습니다.

자주 묻는 질문

n8n으로 에이전트형 AI를 만들 수 있나요?

네. 새 Agents 화면에서는 세션에 걸쳐 툴을 선택하는 지속형 Agent를 만들 수 있고, 기존 AI Agent 노드에서는 워크플로우 안에 에이전트형 행동을 넣을 수 있습니다. 업무에 맞는 범위를 선택하면 됩니다.

대표적인 AI 에이전트 4가지는 무엇인가요?

AI 에이전트에는 권위 있는 ‘4대 AI 에이전트’ 기준이 없습니다. 일반적인 인기 목록보다 업무, 필요한 통합, 승인 모델, 배포 제약, 비용을 기준으로 고르는 편이 낫습니다.

AI 에이전트의 5가지 유형은 무엇인가요?

보편적인 5가지 분류법은 없습니다. n8n 자동화에서는 고정 그래프가 다음 행동을 소유하는지, 모델이 제한된 툴 사이에서 고르는지를 구분하는 편이 실용적입니다.

n8n 워크플로우와 에이전트형 워크플로우는 어떻게 다른가요?

n8n 워크플로우는 미리 선언한 노드 그래프를 따릅니다. 에이전트형 설계에서는 모델이 다음 행동을 고르지만, 승인된 툴의 실제 실행은 여전히 아래의 워크플로우가 맡을 수 있습니다.

ChatGPT는 에이전트형 AI인가요?

채팅 답변 그 자체만으로는 에이전트형이라고 할 수 없습니다. 에이전트형 행동은 목표를 향해 행동이나 툴을 선택하고, 결과를 관찰하고, 다음 일을 결정하는 것을 뜻합니다.

에이전트의 4가지 유형은 무엇인가요?

n8n에 일률적으로 적용할 수 있는 4가지 유형 분류법은 없습니다. 대신 상태, 계획, 툴 접근, 자율성과 같은 운영 특성을 평가해야 합니다.

상위 3개 AI 에이전트는 무엇인가요?

모든 상황에 맞는 절대적인 상위 3개는 없습니다. 적합한 Agent는 연결해야 하는 시스템, 필요한 통제 정도, 실행할 수 있는 환경에 따라 달라집니다.

AI의 7가지 유형은 무엇인가요?

7가지 목록은 교육용 분류법일 뿐 아키텍처 규칙이 아닙니다. 이런 목록은 고객 지원이나 운영 프로세스를 n8n 워크플로우에 둘지, Agent에 둘지 결정해 주지 않습니다.

AI 에이전트의 5가지 구성 요소는 무엇인가요?

n8n에서 구현할 때는 모델, 지침, 툴, 메모리, 접근 제어부터 시작합니다. 사용 사례에 필요할 때만 지식, 채널, 스케줄, 서브 에이전트를 추가합니다.

대화형 판단 지점이 가장 어려운 부분이라면, 기존 워크플로우를 통제 계층으로 유지하면서 Agent를 설계하고 구축하는 일을 도와드릴 수 있습니다.