n8n AI Agent 노드 완전 정복

챗봇이 아니라 실행 엔진이다

n8n에서 AI Agent 노드를 처음 열면 많은 사람이 이렇게 생각한다. "아, 여기서 챗봇을 만드는구나." 반은 맞고 반은 틀리다. AI Agent는 대화할 수 있지만, 본질은 챗봇이 아니다. 더 정확히 말하면 목표를 이해하고, 필요한 도구를 고르고, 실행 결과를 확인한 뒤, 일이 끝날 때까지 다음 행동을 결정하는 실행 엔진이다.

챗봇은 말한다. 에이전트는 움직인다.

예를 들어 사용자가 "지난주 신규 리드 중 구매 가능성이 높은 사람만 골라서 슬랙에 알려줘"라고 요청했다고 하자. 단순 챗봇은 "리드를 평가하려면 업종, 예산, 문의 내용 등을 확인하세요"라고 조언할 수 있다. 하지만 AI Agent는 Google Sheets에서 리드 목록을 읽고, 각 문의 내용을 분류하고, CRM에서 과거 접촉 이력을 확인하고, 점수를 매긴 뒤, Slack에 요약을 보낼 수 있다. 이 차이가 바로 1인 회사 자동화의 분기점이다.

앞 장들에서 우리는 콘텐츠, 마케팅, 제품 운영, 인프라 모니터링을 n8n 워크플로우로 시스템화했다. 그 워크플로우들은 대체로 "정해진 순서대로 움직이는 기계"에 가까웠다. 트리거가 발생하면 A를 하고, B를 하고, 조건에 따라 C나 D로 간다. 반면 AI Agent 노드는 조금 다르다. 모든 단계를 사람이 미리 박아두는 대신, 사람이 목표와 권한을 정해주고 에이전트가 그 안에서 판단한다.

n8n 공식 문서에서도 Tools Agent는 외부 도구와 API를 사용해 정보를 가져오거나 행동을 수행하며, 작업에 따라 어떤 도구를 사용할지 결정할 수 있는 에이전트로 설명된다.¹ 이 문장을 1인 회사 언어로 바꾸면 이렇다. "사장이 모든 클릭 순서를 정하지 않아도, 위임받은 직원이 상황을 보고 필요한 사내 시스템을 열어 일을 처리한다."

다만 여기서 중요한 단서가 있다. 에이전트는 유능한 직원처럼 보이지만, 아직은 충동적인 신입 직원에 가깝다. 권한을 너무 많이 주면 엉뚱한 도구를 누르고, 설명이 모호하면 잘못된 고객에게 메일을 보내고, 반복 한도를 두지 않으면 같은 API를 계속 호출하며 비용을 태운다. 그래서 이번 장의 목표는 "멋진 AI 비서 만들기"가 아니다. 프로덕션에서 쓸 수 있는 에이전트의 뼈대를 이해하는 것이다.

Basic LLM Chain과 AI Agent는 무엇이 다른가

n8n에서 AI 기능을 쓰다 보면 Basic LLM Chain과 AI Agent를 모두 만나게 된다. 둘 다 LLM, 즉 대규모 언어 모델을 호출한다. 하지만 구조는 완전히 다르다.

Basic LLM Chain은 자판기와 비슷하다. 프롬프트를 넣으면 답변이 나온다. "이 글을 요약해줘"라고 넣으면 요약문이 나오고, "이 이메일을 정중하게 바꿔줘"라고 넣으면 다듬어진 이메일이 나온다. 입력 하나, 응답 하나. 빠르고 예측 가능하며 비용도 상대적으로 관리하기 쉽다.

AI Agent는 작은 현장 매니저에 가깝다. 사용자의 요청을 받고, 지금 가진 정보가 충분한지 판단하고, 필요하면 도구를 호출하고, 도구 결과를 읽고, 다시 판단한다. 답을 바로 할 수도 있고, 검색을 먼저 할 수도 있고, 데이터베이스를 조회한 뒤 고객에게 질문을 되돌려줄 수도 있다.

판단 기준은 간단하다. 순서가 고정되어 있으면 워크플로우나 Basic LLM Chain을 쓰고, 다음 행동을 AI가 판단해야 하면 AI Agent를 쓴다.

예를 들어 "블로그 글을 5줄로 요약하기"는 Agent가 필요 없다. Basic LLM Chain이면 충분하다. "경쟁사 3곳의 가격 페이지를 찾아서 변경 사항을 요약하고, 우리 가격표와 비교한 뒤, 변경이 크면 Slack에 알려주기"는 Agent에 가깝다. 중간에 어떤 페이지를 읽을지, 정보가 부족하면 검색을 더 할지, 결과를 어떻게 종합할지 판단이 필요하기 때문이다.

이 차이를 모르면 모든 일에 Agent를 붙이게 된다. 그러면 자동화가 똑똑해지는 것이 아니라 비싸지고 느려진다. 1인 회사에 필요한 것은 과시용 AI가 아니라 마진을 지키는 자동화다. 에이전트는 비장의 카드처럼 써야 한다.

AI Agent의 내부 루프 이해하기

AI Agent 노드는 겉으로 보기에는 하나의 노드지만, 안쪽에서는 작은 회의가 반복된다.

요청이 들어오면 모델은 먼저 상황을 해석한다. "사용자가 원하는 최종 결과는 무엇인가?"를 파악한다. 그다음 연결된 도구 목록을 살핀다. "이 일을 끝내려면 어떤 도구가 필요한가?"를 고른다. 도구를 호출하면 n8n이 실제 API나 노드를 실행하고, 결과를 다시 모델에게 돌려준다. 모델은 그 결과를 보고 "목표가 달성됐는가?"를 판단한다. 부족하면 다른 도구를 부르거나 같은 도구를 다른 인자로 다시 호출한다. 충분하면 최종 응답을 만든다.

흐름을 말로 그리면 이렇다.

입력 수신
→ 목표 해석
→ 사용 가능한 도구 검토
→ 도구 호출 또는 직접 응답 결정
→ 도구 결과 관찰
→ 추가 행동 필요 여부 판단
→ 완료 또는 반복

이 구조를 흔히 "추론·결정·행동" 루프라고 부른다. n8n의 Tools Agent 문서에는 Max Iterations 옵션이 있으며, 모델이 좋은 답을 만들기 위해 실행을 시도하는 횟수를 설정할 수 있다고 설명되어 있다.¹ 이 값이 중요한 이유가 여기에 있다. 에이전트는 한 번의 응답으로 끝나지 않을 수 있다. 리서치 에이전트라면 검색하고, 페이지를 읽고, 다시 검색하고, 요약하고, 출처를 검증한다. 각 단계마다 토큰과 API 비용이 발생한다.

그러니 Agent를 만들 때는 늘 이렇게 질문해야 한다.

"이 직원에게 최대 몇 번까지 고민하게 할 것인가?"

단순 분류 에이전트라면 3~5회면 충분하다. 웹 리서치처럼 여러 출처를 확인해야 하는 작업은 10~15회가 필요할 수 있다. 하지만 30회, 50회로 늘리는 것은 대부분 문제 해결이 아니라 비용 폭주다. 에이전트가 계속 헤맨다면 반복 횟수를 늘릴 게 아니라 도구 설명, 시스템 프롬프트, 입력 데이터, 출력 형식을 고쳐야 한다.

AI Agent를 구성하는 다섯 가지 부품

AI Agent 노드는 혼자 일하지 않는다. 적어도 모델이 필요하고, 제대로 쓰려면 Tools, Memory, Output Parser, System Prompt가 함께 설계되어야 한다. 이 다섯 가지를 이해하면 Agent가 갑자기 신비로운 검은 상자가 아니라 조립 가능한 업무 엔진으로 보이기 시작한다.

모델: 생각하고 말하는 두뇌

모델은 에이전트의 두뇌다. 사용자의 요청을 해석하고, 도구를 고르고, 도구 호출에 필요한 인자를 만들고, 최종 답변을 작성한다. OpenAI, Anthropic Claude, Google Gemini, Ollama 기반 로컬 모델 등이 여기에 해당한다.

단순한 글쓰기 자동화에서는 "문장이 자연스러운가"가 모델 선택의 핵심이다. 하지만 에이전트에서는 기준이 달라진다. 더 중요한 것은 도구 호출 정확도, JSON 출력 안정성, 긴 작업 중 오류 복원력이다. 말은 그럴듯하지만 도구 인자를 자주 틀리는 모델은 에이전트용으로 위험하다. 고객 이름을 잘못 넣어 CRM을 조회하거나, 필요 없는 메일 발송 도구를 호출할 수 있기 때문이다.

에이전트의 모델은 작가가 아니라 운영 담당자에 가깝다. 글솜씨보다 업무 처리 실수가 적어야 한다.

Tools: 손과 발

Tools는 에이전트가 실제 세상에 손을 뻗는 통로다. HTTP Request로 외부 API를 부를 수 있고, Google Sheets에서 데이터를 읽을 수 있으며, Gmail로 이메일을 보낼 수 있고, Slack에 알림을 남길 수 있다. n8n Tools Agent는 Call n8n Workflow, Code, HTTP Request, Gmail, Google Sheets, Slack, Notion, Postgres, Supabase, Vector Store 등 다양한 도구 연결을 지원한다.¹

도구가 없으면 Agent는 말만 잘하는 상담원이다. 도구가 있으면 업무를 처리하는 직원이 된다.

하지만 도구는 권한이다. 권한은 항상 위험을 동반한다. 조회 도구는 비교적 안전하지만, 발송·삭제·결제·DB 업데이트 도구는 조심해야 한다. 특히 1인 회사에서는 "사람이 한 번 확인해야 하는 일"과 "AI가 바로 실행해도 되는 일"을 나눠야 한다.

예를 들어 리서치 에이전트에게 웹 검색과 페이지 읽기 도구를 주는 것은 안전하다. 고객지원 에이전트에게 FAQ 검색과 주문 조회 도구를 주는 것도 괜찮다. 하지만 "환불 처리", "계정 삭제", "대량 메일 발송"은 Human-in-the-loop, 즉 사람 승인 단계를 거치는 편이 좋다. n8n Tools Agent 문서도 민감한 도구 실행 전 사람 승인을 요구하는 human review 구성을 지원한다고 설명한다.¹

Memory: 대화 기록이 아니라 상태 관리 계층

Memory는 흔히 "이전 대화를 기억하는 기능"으로 이해된다. 틀린 말은 아니다. n8n 문서도 AI 메모리를 이전 메시지의 히스토리를 유지해 매번 새 대화처럼 시작하지 않도록 돕는 요소로 설명한다.² 하지만 실무에서는 이보다 더 넓게 봐야 한다.

Memory는 에이전트의 상태 관리 계층이다. 상태란 "지금 이 고객과 어떤 관계인가", "이 작업은 어디까지 진행됐는가", "이 사용자는 어떤 표현을 선호하는가", "지난번에 어떤 문제가 있었는가" 같은 맥락이다.

1인 회사의 고객지원 에이전트를 생각해보자. 사용자가 어제 "결제가 두 번 됐어요"라고 문의했고, 오늘 "그 건 어떻게 됐나요?"라고 물었다. 메모리가 없으면 에이전트는 "어떤 건을 말씀하시나요?"라고 되묻는다. 메모리가 있으면 이전 문의와 결제 이력을 이어서 볼 수 있다. 고객 입장에서는 전자는 기계이고, 후자는 회사처럼 느껴진다.

n8n에는 Simple Memory처럼 현재 세션의 최근 대화 맥락을 유지하는 데 적합한 방식이 있다. 공식 문서에 따르면 Simple Memory는 현재 세션의 사용자 지정 길이만큼 채팅 기록을 저장하는 가장 쉬운 시작점이다.² 빠른 테스트나 단일 세션 챗봇에는 이 정도면 충분하다.

하지만 사용자가 며칠 뒤 다시 돌아왔을 때도 선호도, 이전 문의, 작업 이력을 기억해야 한다면 이야기가 달라진다. 이때는 지속 메모리가 필요하다. Redis Chat Memory, Postgres Chat Memory 같은 메모리 서비스 노드를 쓰거나, 외부 DB와 벡터 스토어를 조합하거나, 서브워크플로우를 메모리 저장소처럼 설계할 수 있다. n8n 문서에는 Redis, Postgres, Xata, Zep 등 메모리 서비스 노드와 더 복잡한 메모리 관리를 위한 Chat Memory Manager가 소개되어 있다.²

핵심은 "많이 저장하기"가 아니다. 필요한 기억만 꺼내 쓰기다. 모든 과거 대화를 매번 모델에 넣으면 비용이 커지고, 정작 중요한 정보가 묻힌다. 좋은 메모리는 창고가 아니라 잘 정리된 비서 수첩이다.

Output Parser: 후속 자동화를 위한 계약서

AI Agent가 최종 답변을 자연어로만 내보내면 사람은 읽기 편하지만 워크플로우는 불안정해진다. 다음 노드가 category, confidence, next_action 같은 필드를 기대하는데 에이전트가 어느 날 "아마도 고객지원 이슈로 보입니다"라고 문장으로 답하면 자동화가 깨진다.

Output Parser는 이 문제를 줄이는 장치다. 결과 형식을 JSON처럼 고정해 후속 노드가 안정적으로 처리할 수 있게 한다. n8n의 Structured Output Parser는 JSON Schema를 기준으로 필드를 반환하도록 돕는다.³

예를 들어 고객지원 분류 에이전트의 출력은 다음처럼 고정할 수 있다.

{
  "category": "billing",
  "confidence": 0.87,
  "summary": "사용자가 중복 결제를 문의함",
  "suggested_reply": "확인 후 안내드리겠다는 답변 초안",
  "needs_human_review": true
}

이렇게 만들면 다음 노드는 needs_human_review가 true일 때 Slack 승인 요청을 보내고, false일 때만 자동 답변 초안을 저장할 수 있다.

다만 Output Parser를 만능 안전장치로 착각하면 안 된다. n8n 문서는 Structured Output Parser가 에이전트의 최종 출력을 구조화하는 용도이며, 에이전트와 함께 사용할 때 구조화 출력 파싱이 항상 안정적이지 않을 수 있고, 더 일관된 결과가 필요하면 별도 LLM Chain으로 에이전트 결과를 다시 파싱하는 방식을 권장한다.⁴ 실무적으로도 복잡한 Agent 하나에 "리서치도 하고, 판단도 하고, 완벽한 JSON도 내라"고 시키면 종종 흔들린다.

안정성이 중요하다면 Agent의 결과를 먼저 자연어 또는 느슨한 JSON으로 받고, 그다음 Basic LLM Chain이나 Information Extractor 계열 노드로 한 번 더 정리하는 2단 구성이 더 낫다.

System Prompt: 업무 규정집

System Prompt는 에이전트의 업무 규정집이다. "너는 누구인가", "무엇을 목표로 하는가", "어떤 도구를 언제 써야 하는가", "무엇을 하면 안 되는가", "응답 형식은 어떠해야 하는가"를 정한다.

나쁜 시스템 프롬프트는 이렇게 생겼다.

너는 친절한 AI 비서야. 고객 문의를 잘 처리해줘.

친절하긴 하겠지만, 무엇을 해도 되는지 알 수 없다. 좋은 시스템 프롬프트는 업무 범위와 금지선을 명확히 한다.

너는 1인 SaaS 회사의 고객지원 1차 분류 에이전트다.
목표는 고객 문의를 읽고 billing, bug, feature_request, general 중 하나로 분류한 뒤 답변 초안을 작성하는 것이다.

규칙:
- 주문 상태나 결제 내역이 필요하면 Order Lookup 도구를 먼저 사용한다.
- 환불 승인, 계정 삭제, 요금제 변경은 직접 실행하지 말고 needs_human_review를 true로 설정한다.
- 확신도가 0.75 미만이면 사람 검수로 보낸다.
- 모르는 내용은 추측하지 말고 추가 확인이 필요하다고 말한다.
- 최종 출력은 지정된 JSON 형식을 따른다.

System Prompt는 길다고 좋은 것이 아니다. 업무 규정집처럼 짧고 명확해야 한다. 특히 도구가 많을수록 "언제 어떤 도구를 써야 하는지"를 구체적으로 써야 한다. 에이전트는 도구 이름보다 도구 설명과 프롬프트 맥락을 보고 선택하기 때문이다.

Tools 설계: 에이전트에게 어떤 권한을 줄 것인가

에이전트 성능의 절반은 모델이 만들고, 나머지 절반은 도구 설계가 만든다. 같은 모델을 써도 도구 설명이 엉성하면 결과가 흔들린다.

도구 설명은 짧은 라벨이 아니라 사용 설명서여야 한다.

나쁜 설명은 이렇다.

CRM을 검색합니다.

좋은 설명은 이렇다.

현재 문의한 사용자의 이메일 주소로 CRM 고객 정보를 조회할 때 사용한다.
입력: email.
출력: customer_id, plan, signup_date, last_contacted_at, account_status.
답변 초안을 작성하기 전에 고객의 요금제나 계정 상태가 필요하면 이 도구를 먼저 사용한다.

이 정도로 써야 에이전트가 "아, 고객의 요금제 확인이 필요할 때 이 도구를 쓰는구나"라고 판단한다. 도구 설명에는 최소한 세 가지가 들어가야 한다.

• 언제 사용하는가

• 무엇을 입력해야 하는가

• 무엇이 결과로 돌아오는가

• 사용하면 안 되는 상황은 무엇인가

마지막 항목이 특히 중요하다. 예를 들어 "Email Send" 도구 설명에 "고객에게 최종 메일을 보낼 때 사용"이라고만 쓰면 위험하다. 대신 이렇게 써야 한다.

사람 승인이 완료된 답변만 고객에게 발송할 때 사용한다.
입력: to, subject, body.
주의: 환불, 해지, 법무, 보안 관련 문의에는 이 도구를 직접 사용하지 않는다. 해당 경우에는 needs_human_review를 true로 반환한다.

1인 회사에서 추천하는 도구 설계 원칙은 간단하다. 처음부터 많은 도구를 주지 말고, 에이전트가 성공적으로 다루는 도구만 하나씩 늘린다. 도구가 2개일 때는 헷갈릴 일이 적지만, 8개가 되면 에이전트는 어느 도구를 써야 할지 흔들리기 시작한다. 신입 직원에게 첫날부터 회계, CS, 영업, 서버 운영, 결제 취소 권한을 모두 주지 않는 것과 같다.

가장 안전한 시작 조합은 다음 정도다.

• 조회 도구: 고객 정보, 주문 정보, 문서, 검색 결과를 읽는 도구

• 기록 도구: Airtable, Notion, Google Sheets, CRM에 로그를 남기는 도구

• 알림 도구: Slack, Telegram, 이메일 초안 저장처럼 사람이 확인할 수 있는 도구

발송, 삭제, 환불, 결제, 권한 변경은 나중에 붙여도 늦지 않다.

Memory 설계: Simple Memory에서 지속 메모리까지

Memory를 설계할 때 가장 먼저 나눠야 할 것은 세션 메모리와 지속 메모리다.

세션 메모리는 지금 이어지는 대화의 맥락을 유지한다. 사용자가 "아까 말한 그 제품"이라고 했을 때 무엇을 말하는지 알게 해준다. Simple Memory는 이런 용도에 잘 맞는다. 설정도 쉽고, 빠르게 테스트하기 좋다.

지속 메모리는 실행이 끝나도 남아야 하는 기억이다. 고객의 선호도, 이전 티켓, 마지막 구매 제품, 리드의 관심사, 콘텐츠 제작 스타일 같은 정보가 여기에 해당한다. 이 정보는 하루 뒤, 일주일 뒤, 한 달 뒤에도 다시 써야 한다.

실무에서는 메모리를 세 층으로 나누면 이해하기 쉽다.

이 세 층을 모두 처음부터 만들 필요는 없다. 처음에는 Simple Memory로 시작한다. 그다음 고객지원이나 리드 관리처럼 "다음 방문에도 기억해야 하는 정보"가 생기면 Postgres나 Supabase에 구조화 메모리를 만든다. 문서나 과거 대화가 많아져서 의미 기반 검색이 필요해질 때 벡터 스토어를 붙인다.

중요한 것은 메모리를 원문 그대로 쌓지 않는 것이다. 모든 대화를 통째로 저장하면 나중에 꺼내기도 어렵고, 모델에 넣을 때 토큰 비용도 커진다. 대신 에이전트 실행 후 별도 노드에서 요약 메모리를 저장하는 패턴이 좋다.

예를 들어 고객지원 대화가 끝난 뒤 다음과 같은 메모리를 남긴다.

{
  "user_id": "cus_123",
  "memory_type": "support_summary",
  "summary": "2026-05-06 중복 결제 문의. 환불 검토 필요. 고객은 빠른 이메일 답변을 선호함.",
  "tags": ["billing", "refund", "high_priority"],
  "created_at": "2026-05-06T10:15:00+09:00"
}

다음번 문의가 오면 전체 대화를 다 넣는 대신, 관련 요약만 검색해 Agent에게 제공한다. 이것이 메모리를 비용 폭탄이 아니라 레버리지로 만드는 방식이다.

Output Parser와 구조화 출력 패턴

n8n Agent를 후속 자동화에 연결하려면 자연어 답변만으로는 부족하다. 자동화는 "아마", "대략", "적절히" 같은 말을 싫어한다. 자동화는 필드와 값, 조건과 분기를 좋아한다.

그래서 Agent 출력에는 가급적 구조를 준다. 특히 다음과 같은 업무는 구조화 출력이 거의 필수다.

• 고객 문의 분류 후 티켓 라우팅

• 리드 점수화 후 CRM 업데이트

• 리서치 결과를 Notion DB에 저장

• 콘텐츠 초안을 검수 큐로 보내기

• 서버 알림을 위험도별로 분기

리드 분류 에이전트라면 출력 스키마를 이렇게 잡을 수 있다.

{
  "lead_score": 82,
  "segment": "high_intent",
  "reason": "가격 문의와 데모 요청이 함께 포함되어 있음",
  "recommended_action": "send_demo_link",
  "needs_human_review": false,
  "follow_up_deadline": "2026-05-07"
}

여기서 recommended_action은 반드시 허용된 값 중 하나만 나오게 해야 한다. 예를 들어 send_demo_link, ask_budget, book_call, nurture, discard처럼 enum을 정한다. 자유롭게 쓰게 두면 어떤 날은 "데모 링크 보내기", 어떤 날은 "send demo", 어떤 날은 "데모 안내"가 나와 후속 분기가 깨진다.

하지만 앞에서 말했듯 Agent 내부에서 직접 복잡한 구조화 출력을 강제하면 가끔 실패한다. 더 안정적인 프로덕션 패턴은 다음과 같다.

AI Agent: 조사와 판단을 수행하고 근거를 포함한 결과 생성
→ Basic LLM Chain 또는 Information Extractor: 결과를 지정 JSON으로 변환
→ IF / Switch 노드: JSON 필드 기준으로 분기
→ Slack / CRM / DB: 후속 처리

Agent에게는 판단을 맡기고, 파서는 정리를 맡기는 식이다. 회사에서도 영업 담당자가 통화 내용을 자유롭게 메모하면, 운영 담당자가 CRM 필드에 맞춰 정리하는 것과 비슷하다.

모델 선택 가이드: 말 잘하는 모델보다 도구 잘 쓰는 모델

에이전트용 모델을 고를 때 흔한 실수는 "가장 똑똑한 모델"을 고르는 것이다. 물론 어려운 추론이 필요한 작업에는 강한 모델이 좋다. 하지만 n8n Agent에서는 모델의 지능만큼이나 운영 특성이 중요하다.

특히 다음 기준을 봐야 한다.

• 가격: 반복 호출과 도구 호출을 감당할 수 있는가

• 응답 속도: 고객지원이나 내부 운영에서 기다릴 만한가

• 추론력: 모호한 요청을 올바르게 해석하는가

• 긴 컨텍스트 처리: 긴 문서, 과거 대화, 도구 결과를 다룰 수 있는가

• 도구 호출 안정성: 올바른 도구와 인자를 선택하는가

• JSON 출력 안정성: 후속 워크플로우가 깨지지 않는가

• 개인정보 통제권: 민감 데이터를 외부 API로 보내도 되는가

아래 표는 1인 회사 관점의 선택 가이드다. 가격과 모델 라인업은 자주 바뀌므로 실제 도입 전에는 각 제공사의 최신 요금표와 n8n 지원 상태를 반드시 확인해야 한다.

Ollama는 로컬 하드웨어에서 모델을 실행할 수 있어 데이터를 외부 API로 보내기 어려운 업무에 매력적이다. Ollama 공식 가격 페이지도 무료 플랜에서 로컬 하드웨어 실행과 데이터 프라이버시를 강조하며, 클라우드 모델 중 도구 지원 모델은 실제 에이전트 워크플로우로 테스트된다고 설명한다.⁵ 다만 로컬 모델은 "돌아간다"와 "에이전트로 안정적으로 일한다" 사이에 차이가 크다. 특히 도구 호출 JSON을 자주 틀리는 작은 모델은 Agent 루프를 깨뜨릴 수 있다.

처음 만드는 프로덕션 에이전트라면 추천 순서는 보수적으로 가는 편이 좋다. 먼저 도구 호출과 구조화 출력이 안정적인 상용 모델로 워크플로우를 완성한다. 그다음 비용이나 개인정보 이슈가 큰 부분만 로컬 모델로 대체해 테스트한다. 처음부터 로컬 모델로 모든 것을 해결하려고 하면 모델 튜닝보다 워크플로우 설계가 늦어진다.

예제 1: 리서치 에이전트 만들기

리서치 에이전트는 Agent 노드의 성격을 이해하기 가장 좋은 예제다. 정해진 페이지 하나를 요약하는 것은 Basic LLM Chain으로 충분하지만, "주제에 맞는 최신 정보를 찾아 비교하고 정리하기"는 Agent에 잘 맞는다.

목표는 다음과 같다.

입력된 주제에 대해 웹에서 최신 정보를 찾고, 핵심 요약과 참고 링크를 구조화된 형태로 반환한다.

워크플로우 구조는 단순하게 시작한다.

Manual Trigger 또는 Form Trigger
→ AI Agent
   - Chat Model
   - Web Search Tool
   - HTTP Request Tool
   - Memory 선택 사항
   - Output Parser 선택 사항
→ Notion 또는 Google Docs 저장
→ Slack 알림

System Prompt는 이렇게 잡을 수 있다.

너는 1인 창업자를 돕는 리서치 에이전트다.
목표는 입력된 주제에 대해 신뢰할 수 있는 최신 정보를 찾고, 실행 가능한 인사이트로 요약하는 것이다.

규칙:
- 최신 정보가 필요하면 Web Search 도구를 사용한다.
- 검색 결과만으로 판단하지 말고, 중요한 결과는 HTTP Request 도구로 원문을 확인한다.
- 최소 3개 이상의 서로 다른 출처를 비교한다.
- 광고성 문구는 제거하고 사실, 변화, 기회, 리스크 중심으로 정리한다.
- 불확실한 내용은 추측하지 말고 "확인 필요"로 표시한다.

도구 설명은 더 구체적으로 만든다.

Web Search Tool:
현재 웹에서 특정 주제의 최신 자료, 뉴스, 공식 문서, 블로그 글을 찾을 때 사용한다.
입력: search_query.
출력: title, url, snippet.
공식 문서나 원문 확인이 필요한 경우 검색 결과 URL을 HTTP Request Tool로 다시 읽는다.

HTTP Request Tool:
검색 결과에서 선택한 URL의 본문을 읽을 때 사용한다.
입력: url.
출력: 페이지 제목, 본문 텍스트, 상태 코드.
광고 페이지나 접근 불가 페이지는 건너뛰고 다른 출처를 찾는다.

출력은 처음부터 너무 복잡하게 만들지 않는다. 예를 들어 다음 정도면 후속 자동화에 충분하다.

{
  "topic": "검색 주제",
  "summary": "핵심 요약",
  "key_findings": ["발견 1", "발견 2", "발견 3"],
  "opportunities": ["기회 1", "기회 2"],
  "risks": ["리스크 1"],
  "sources": [
    {"title": "문서 제목", "url": "https://example.com", "note": "참고한 이유"}
  ],
  "confidence": 0.82
}

운영 팁은 Max Iterations다. 간단한 리서치는 8~10회로 시작하고, 깊은 리서치는 15회 정도까지 올린다. 대신 검색 도구 호출 수를 로그로 남긴다. 같은 주제에서 매번 15회를 꽉 채운다면 에이전트가 똑똑한 것이 아니라 길을 잃고 있을 가능성이 높다.

예제 2: 고객지원 에이전트 만들기

고객지원 에이전트는 1인 회사에서 체감 효과가 가장 크다. 다만 가장 조심해야 하는 영역이기도 하다. 고객에게 잘못된 답변을 보내거나 민감한 계정 작업을 실행하면 브랜드 신뢰가 흔들린다.

처음부터 자동 발송을 목표로 하지 말자. 첫 버전의 목표는 분류, 답변 초안, 사람 검수다.

Chat Trigger 또는 Email Trigger
→ 전처리 노드: 본문 정리, 서명 제거, 긴 이전 대화 자르기
→ AI Agent
   - Chat Model
   - Simple Memory 또는 Postgres Chat Memory
   - FAQ Search Tool
   - Order Lookup Tool
   - Ticket Create Tool
→ Structured Output 또는 별도 파서
→ IF: needs_human_review 분기
→ Slack 승인 요청 또는 Helpdesk 저장

System Prompt는 다음처럼 안전선을 먼저 긋는다.

너는 1인 SaaS 회사의 고객지원 1차 응대 에이전트다.
목표는 고객 문의를 분류하고, 필요한 정보를 조회하고, 답변 초안을 작성하는 것이다.

규칙:
- 결제, 환불, 계정 삭제, 보안, 법무 관련 문의는 반드시 needs_human_review를 true로 설정한다.
- 주문 상태가 필요하면 Order Lookup Tool을 사용한다.
- 제품 사용법 질문은 FAQ Search Tool을 먼저 사용한다.
- 확신도가 낮으면 답을 지어내지 말고 추가 정보 요청 초안을 작성한다.
- 고객에게 직접 발송하지 않는다. 최종 발송은 사람이 승인한다.

출력은 이렇게 고정한다.

{
  "category": "billing | bug | how_to | feature_request | account | other",
  "priority": "low | normal | high | urgent",
  "confidence": 0.0,
  "customer_summary": "고객 문의 요약",
  "internal_note": "운영자가 볼 메모",
  "draft_reply": "고객에게 보낼 답변 초안",
  "needs_human_review": true,
  "reason_for_review": "검수가 필요한 이유"
}

Memory는 두 가지로 나눈다. 대화가 이어지는 동안에는 Simple Memory나 Postgres Chat Memory로 최근 맥락을 유지한다. 대화가 끝난 뒤에는 고객별 요약 메모리를 DB에 저장한다.

예를 들어 customer_memory 테이블을 만든다.

customer_id
email
preferred_language
last_issue_summary
open_ticket_id
risk_flags
updated_at

Agent가 매번 모든 과거 티켓을 읽게 하지 말고, 현재 문의와 관련된 요약만 넣는다. 고객지원에서 중요한 것은 기억력이 아니라 관련성이다.

예제 3: 리드 분류 에이전트 만들기

리드 분류는 AI Agent를 매출 엔진에 연결하는 대표 예제다. 웹사이트 문의, 뉴스레터 가입, 웨비나 신청, 무료 체험 가입자가 들어왔을 때 "누가 지금 연락할 가치가 있는가"를 자동으로 판단한다.

고정 규칙만으로도 어느 정도 가능하다. 회사 규모가 크면 +10점, 가격 페이지를 보면 +20점 같은 식이다. 하지만 실제 리드는 더 미묘하다. "팀에서 검토 중입니다", "이번 분기 예산이 있습니다", "대체 솔루션을 찾고 있습니다" 같은 문장에는 구매 의도가 숨어 있다. 이런 의미 판단은 Agent가 잘하는 영역이다.

흐름은 다음과 같다.

Webhook 또는 Form Trigger
→ 입력 정리: 이름, 이메일, 회사, 문의 내용
→ Enrichment Tool: 회사 도메인 조회, CRM 중복 확인
→ AI Agent
   - Chat Model
   - CRM Lookup Tool
   - Company Research Tool
   - Calendar Availability Tool 선택 사항
→ 구조화 출력
→ CRM 업데이트
→ high_intent면 Slack 알림 또는 이메일 초안 생성

System Prompt는 영업 보조 직원처럼 만든다.

너는 1인 B2B SaaS 회사의 리드 분류 에이전트다.
목표는 신규 리드의 구매 가능성을 평가하고 다음 액션을 추천하는 것이다.

평가 기준:
- 명확한 문제와 도입 목적이 있는가
- 예산, 일정, 의사결정자 정보가 있는가
- 회사 규모와 제품 적합도가 맞는가
- 단순 호기심인지, 실제 구매 검토인지 구분한다

규칙:
- 기존 고객 또는 기존 리드인지 CRM Lookup Tool로 확인한다.
- 회사 정보가 부족하면 Company Research Tool을 사용한다.
- 확신도가 낮으면 바로 영업 메일을 보내지 말고 추가 질문을 추천한다.
- 최종 출력은 지정된 JSON 형식을 따른다.

출력 예시는 다음과 같다.

{
  "lead_score": 78,
  "segment": "high_intent",
  "fit": "good",
  "intent_signals": ["데모 요청", "도입 일정 언급", "현재 솔루션 불만"],
  "missing_info": ["예산", "의사결정자"],
  "recommended_action": "book_call",
  "draft_followup": "상담 일정을 제안하는 이메일 초안",
  "needs_human_review": false
}

여기서 핵심은 recommended_action을 제한하는 것이다. 후속 자동화가 처리할 수 있는 액션만 허용한다.

book_call
send_pricing
ask_budget
nurture_sequence
disqualify
human_review

이렇게 해야 CRM 업데이트, 이메일 시퀀스 등록, Slack 알림이 안정적으로 이어진다.

폭주하지 않는 Agent를 만드는 여섯 가지 안전장치

AI Agent는 유연하지만, 그 유연성 때문에 망가질 수 있다. 1인 회사에서 자동화가 망가진다는 것은 곧 대표가 새벽에 알림을 받고 직접 수습해야 한다는 뜻이다. 그러니 처음부터 안전장치를 넣어야 한다.

Max Iterations로 생각의 상한선을 둔다

Max Iterations는 에이전트가 몇 번까지 판단과 도구 호출을 반복할 수 있는지 정한다. 기본값을 그대로 쓰기보다 업무별로 정하자.

반복 횟수를 늘리는 것은 마지막 수단이다. 먼저 도구 설명과 프롬프트를 고쳐야 한다.

Tool description을 업무 매뉴얼처럼 쓴다

도구 설명이 모호하면 에이전트는 감으로 도구를 고른다. 도구마다 "언제 쓰는지", "입력은 무엇인지", "출력은 무엇인지", "금지 상황은 무엇인지"를 써라. 특히 발송, 삭제, 결제, 고객 데이터 수정 도구에는 반드시 금지 조건을 넣는다.

Fallback 경로를 만든다

Agent가 실패했을 때 워크플로우가 조용히 멈추면 안 된다. 실패 경로를 명시한다.

Agent 성공
→ 구조화 출력 검증
→ 후속 자동화

Agent 실패 또는 confidence 낮음
→ Slack에 원문과 오류 요약 전송
→ Notion/DB에 review 상태로 저장
→ 사람 처리

Fallback은 실패를 부끄러워하지 않는 설계다. 좋은 자동화는 실패하지 않는 자동화가 아니라, 실패했을 때 안전하게 멈추는 자동화다.

Structured output으로 후속 노드를 보호한다

후속 노드가 필요한 필드는 반드시 구조화한다. category, confidence, needs_human_review, recommended_action 같은 필드는 자동화의 기둥이다. 자유 문장에 의존하지 말고 JSON 필드로 받는다.

다만 중요한 업무에서는 Agent에 직접 파서를 붙이는 방식만 믿지 말고, 별도 파싱 단계나 검증 노드를 둔다. JSON이 비어 있거나 필수 필드가 없으면 자동 실행하지 말고 사람 검수로 보낸다.

Human-in-the-loop 조건을 명시한다

사람 검수 조건은 감이 아니라 규칙이어야 한다.

needs_human_review = true 조건:
- confidence < 0.75
- 환불, 결제 취소, 계정 삭제, 보안 문의
- 고객 불만 또는 법적 표현 포함
- recommended_action이 발송/수정/삭제 계열
- 도구 호출 실패 후 답변을 생성한 경우

이렇게 해두면 에이전트가 "이건 내가 처리할 일이 아니다"라고 판단할 수 있다. 좋은 직원은 모든 일을 혼자 처리하는 사람이 아니라, 언제 상사에게 올려야 하는지 아는 사람이다.

비용 한도와 실행 로그를 남긴다

Agent는 한 번 실행될 때 모델 호출이 여러 번 발생할 수 있다. 도구 호출도 비용이 들 수 있다. 특히 검색 API, 벡터 DB, 외부 enrichment API는 조용히 비용을 쌓는다.

최소한 다음 값은 로그로 남기자.

• workflow_execution_id

• agent_name

• input_type

• model

• max_iterations

• actual_iterations

• tools_called

• confidence

• final_action

• needs_human_review

• error_message

이 로그가 있어야 나중에 "왜 비용이 늘었는지", "어떤 도구를 자주 잘못 호출하는지", "어떤 입력에서 사람 검수가 많이 발생하는지"를 개선할 수 있다.

Agent를 쓸지 말지 결정하는 마지막 질문

AI Agent는 강력하다. 하지만 모든 자동화의 정답은 아니다. 1인 회사의 시스템은 똑똑해야 하지만, 그보다 먼저 안정적이어야 한다.

Agent를 붙이기 전에 마지막으로 세 가지를 물어보자.

첫째, 이 업무는 매번 같은 순서로 처리되는가? 그렇다면 일반 워크플로우가 낫다. 둘째, 중간 결과를 보고 다음 행동을 바꿔야 하는가? 그렇다면 Agent가 필요할 수 있다. 셋째, 잘못 실행했을 때 피해가 큰가? 그렇다면 사람 승인과 제한된 도구 권한부터 설계해야 한다.

이 장의 핵심은 하나다. AI Agent 노드는 챗봇 기능이 아니라 업무 실행 엔진이다. 모델은 두뇌이고, Tools는 손발이며, Memory는 상태 관리 계층이고, Output Parser는 후속 자동화를 위한 계약서다. System Prompt는 그 모든 것을 묶는 업무 규정집이다.

이 다섯 가지를 제대로 설계하면 1인 회사는 더 이상 대표 한 명의 기억력과 체력에만 의존하지 않는다. 리서치 담당, 고객지원 담당, 영업 보조, 운영 모니터링 담당이 n8n 안에서 각자 맡은 일을 처리하기 시작한다. 물론 완전한 직원은 아니다. 실수도 하고, 가끔 엉뚱한 판단도 한다. 그래서 우리는 권한을 나누고, 반복을 제한하고, 결과를 구조화하고, 중요한 순간에는 사람을 끼워 넣는다.

에이전트를 잘 만든다는 것은 AI에게 모든 것을 맡긴다는 뜻이 아니다. AI가 판단해도 되는 부분과 사람이 책임져야 하는 부분을 선명하게 나누는 것이다. 그 선을 그을 줄 아는 사람이 n8n으로 진짜 회사를 시스템화할 수 있다.

다음 장에서는 이 Agent에 장기 기억과 지식 검색 능력을 붙인다. 바로 RAG다. 에이전트가 단지 대화 몇 줄을 기억하는 수준을 넘어, 당신의 문서, 고객 이력, 제품 정책, 내부 매뉴얼을 찾아 읽고 답하는 지식 에이전트로 진화하는 단계다.

참고

¹Tools AI Agent node documentation | n8n Docs

²What's memory in AI? | n8n Docs

³Structured Output Parser node documentation | n8n Docs

⁴Structured Output Parser node common issues | n8n Docs

⁵Pricing · Ollama