Chat Hub 한 줄 정의와 전체 구조
Chat Hub는 n8n 안에서 “대화 UI(채팅)”를 중심으로
- 여러 LLM 모델을 선택해 대화하거나
- 내가 만든 Personal Agent(가벼운 커스텀 프롬프트 에이전트) 를 쓰거나
- 내가/동료가 만든 워크플로우를 ‘에이전트처럼’ 호출(Workflow agent) 하도록 해주는 중앙 채팅 인터페이스입니다.
즉, “대화 → (선택한 에이전트/워크플로우 실행) → 응답”이 한 화면에서 연결됩니다.
Chat Hub에서 에이전트를 만드는 2갈래(핵심 비교)
간단 Personal Agent (Chat Hub 안에서 즉시 생성)
- 목적: 반복적인 프롬프트 템플릿, 톤/규칙 고정, 간단한 작업에 “AI를 더 안정적으로” 쓰기
- 장점: 빠르고 간단, Chat Hub 모델 선택기에서 즉시 선택 가능
- 한계(공식 제한)
- 파일 지식(file knowledge) 추가 불가
- Tool 선택이 제한적
워크플로우 기반 Agent (Workflow agent로 Chat Hub에 노출)
- 목적: 내부 데이터/외부 API/SaaS/DB 등 “실제 업무 자동화”를 대화로 호출
- 핵심 요구사항(공식)
- Chat Trigger가 있어야 함
- 그리고 AI Agent 노드에서 streaming이 활성화된 워크플로우만 Chat Hub에서 workflow agent로 쓸 수 있음
- 공유/권한: 동료가 쓰려면 워크플로우를 공유하거나 프로젝트에서 최소 Viewer 권한이 필요
Chat Hub에서 “간단 Personal Agent” 만드는 법
생성 절차(공식 흐름)
- n8n 상단 내비게이션에서 Chat(Chat Hub) 로 이동
- Personal Agents → +New Agent 클릭
- 아래 항목 입력: name / description / system prompt / preferred model / tools access
- Save → 이후 모델 선택기에서 해당 personal agent를 바로 선택 가능
System Prompt를 “업무용”으로 설계하는 실전 템플릿
Personal Agent는 “라이트”라서, 프롬프트 설계를 잘하면 체감 품질이 확 올라갑니다.
(예시) 보안 로그 요약봇(System Prompt 샘플)
- 목적: 과도한 추정 금지, 민감정보 마스킹, 조치 포인트 제공
너는 보안 운영 분석가다.
- 사용자가 준 원문/로그 범위 밖으로 추정하지 말 것.
- IP/계정/토큰/쿠키/세션ID/개인정보로 보이는 값은 요약 시 마스킹할 것.
- 출력 형식:
1) 요약(3줄)
2) 의심 포인트(근거 로그/필드 중심)
3) 즉시 조치(차단/격리/추가 수집)
4) 추가 질문(확인 필요한 정보 3개)Personal Agent 운영 시 한계(문서 기준)와 권장 사용처
- 파일 기반 지식(RAG) 넣고 싶다 → Personal Agent로는 불가
- 다양한 도구(사내 DB, 티켓 시스템, SIEM 등)까지 붙이고 싶다 → 워크플로우 기반 Agent로 가는 게 정답
“워크플로우 기반 Agent”를 Chat Hub 노출하는 법 — Chat Trigger + AI Agent 조합
공식 문서가 말하는 핵심은 이 한 줄입니다.
“Chat Hub에서 workflow agent로 쓰려면 Chat Trigger가 있고, Agent node에서 streaming이 enabled 여야 한다.”
워크플로우를 Agent로 “보이게” 만드는 절차
- 워크플로우 열기
- Chat Trigger 열기
- Make Available in n8n Chat 옵션 ON → Chat Hub에 보일 Agent name/description 입력
- 워크플로우 내 AI Agent 노드에서 streaming 관련 옵션 활성화(문서 요구)
- 워크플로우를 Active로 전환
- Chat Hub 모델 선택기에서 해당 워크플로우를 선택해 대화 시작
“Chat Trigger 최신 버전” 이슈(중요)
Chat Hub 문서는 최신 버전 Chat Trigger만 동작한다고 명시합니다.
기존 Chat Trigger가 오래된 버전이면 삭제 후 새로 추가해야 최신 버전을 얻을 수 있다고 안내합니다.
Chat Trigger 설정을 제대로 이해해야 “운영 가능한 챗봇/에이전트”가 됩니다
워크플로우 기반 Agent는 결국 Chat Trigger가 관문입니다. (접근 방식/인증/CORS/세션/응답 모드/스트리밍 등)
“메시지 1개 = 워크플로우 실행 1회” (비용/운영 영향)
Chat Trigger 문서: 사용자 메시지마다 워크플로우가 실행되며, 대화에서 10번 메시지를 보내면 10 executions를 소모한다고 명시합니다. 운영 환경에서는 rate limit / 안내 문구 / 짧은 대화 유도 / 캐시 같은 설계가 중요해집니다.
접속 방식(Hosted vs Embedded)과 인증 옵션
Chat Trigger의 “Make Chat Publicly Available” 아래에서
- Hosted Chat: n8n이 제공하는 호스티드 채팅 UI(대부분 추천)
- Embedded Chat: 직접 UI를 만들고, Chat Trigger가 제공하는 webhook(Chat URL)로 호출
- n8n은 @n8n/chat 위젯을 쓰거나 직접 만들 수 있다고 안내
인증(Authentication) 옵션
- None / Basic Auth / n8n User Auth 제공
→ 사내용이면 최소 n8n User Auth 또는 Basic Auth는 강력 권장입니다.
CORS(Allowed Origin) — Embedded에서 특히 중요
Chat Trigger 옵션에 Allowed Origin(CORS) 가 있으며, 기본은 *로 “모든 오리진 허용”입니다.
→ 운영/보안 관점에서는 * 금지하고 사내 도메인만 허용하는 게 정석입니다.
“Load Previous Session”과 Memory 연결(대화 맥락 유지)
Chat Trigger의 Load Previous Session을 켜면,
- Chat Trigger와 Agent를 같은 memory sub-node에 연결하라고 n8n이 권장합니다. (단일 소스 of truth)
→ “대화 이력 저장”은 곧 “데이터 보관”이므로, 보안 정책과 함께 설계해야 합니다.
Response Mode와 Streaming response의 관계
Chat Trigger의 Response Mode는 크게
- When Last Node Finishes
- Using Response Nodes(Chat 노드/Respond to Webhook 노드로 응답 제어)
여기에서 Streaming response(실시간 스트리밍)는
- 트리거에서 스트리밍을 켜고
- 스트리밍을 지원하는 노드(AI Agent 등) 가 실제로 스트림을 내보내야 동작합니다.
n8n의 streaming 문서도,
- 트리거가 스트리밍을 지원/설정해야 하고
- 노드도 최소 1개는 스트리밍 출력이 가능해야 하며
- 그렇지 않으면 데이터가 안 나갈 수 있다고 경고합니다.
Chat Hub 권한/운영 통제(관리자 관점)
Chat user 역할(일반 사용자용)
Chat Hub는 Chat user라는 역할을 제공하며,
- 워크플로우를 “만들지는 않고 쓰기만 하는” 조직 구성원을 위한 역할
- 기본적으로 chat 인터페이스만 보이고, credential/workflow 추가는 못한다고 설명합니다.
또한 이 역할은 특정 플랜(Starter/Pro/Business/Enterprise)에서만 제공된다고 명시합니다.
Provider settings(모델/공급자 통제)
관리자는 Settings > Chat에서
- 특정 모델/공급자 활성/비활성
- 사용자 임의 모델 추가 제한
- 공급자별 default credential 설정
- 사용자 credential 추가 제한(권한 시스템 연동)
등을 제어할 수 있다고 안내합니다.
Chat Hub / Workflow Agent 보안 가이드 & 점검 포인트
아래는 “실제 운영”에서 꼭 체크해야 할 포인트를, 문서의 기능과 연결해서 정리한 것입니다.
접근통제(누가 이 챗을 쓰는가)
- Embedded/Hosted 모두 인증을 걸어라: None은 내부 유출/남용 리스크가 큼
- Embedded라면 CORS를
*에서 사내 도메인 allowlist로 좁혀라 - Chat user 역할로 “사용자(실행자)”와 “제작자(관리자)” 분리
데이터 보호(대화 내용/세션/메모리)
- Load Previous Session + Memory는 “편의”지만 “보관”이기도 함
- 저장되는 대화가 개인정보/인증정보/고객데이터를 포함하지 않게 프롬프트로 제한
- 필요 시 보관 기간/마스킹/접근권한을 별도 정책으로 정의
비용/남용 통제(Execution 폭증)
- 메시지 1개당 실행 1회 소모
- 챗봇 UI에서 길게 대화 유도하면 비용/부하 폭증
- “요약해서 한번에 질문”, “1회 요청당 1개 작업” 같은 UX 가이드 권장
프롬프트 인젝션/도구 오남용(Workflow Agent의 본질적 리스크)
Workflow agent는 툴(HTTP/DB/SaaS)을 실제로 실행할 수 있으므로,
- “사용자 입력을 그대로 툴 파라미터로” 연결하지 않기
- 민감 API는 중간 검증 노드(If/Code) 를 넣고 allowlist 검증
- n8n에는 “AI가 툴 파라미터를 채우는” 패턴도 있으므로, 더더욱 입력 검증이 중요
“보안 로그 요약/티켓 생성” Workflow Agent 설계 예
노드 구성(개념)
- Chat Trigger
- Authentication: n8n User Auth 또는 Basic Auth
- Embedded 사용 시 Allowed Origin 제한
- Response Mode: Streaming response 사용(스트리밍 목적)
- Make Available in n8n Chat: ON (Chat Hub 에이전트로 노출)
- AI Agent
- 시스템 프롬프트: “로그 근거 기반, 추정 금지, 마스킹, 조치” 강제
- 툴: (예) HTTP Request로 SIEM 검색 API 호출, Jira/ServiceNow 티켓 생성 등
- Streaming 옵션: Chat Hub workflow agent 요구사항에 맞게 활성화
- (선택) Memory sub-node
- Load Previous Session을 쓴다면 Chat Trigger와 Agent를 같은 memory에 연결 권장
임베디드 위젯(@n8n/chat) 최소 예시(참고)
n8n은 Embedded Chat에서 @n8n/chat 위젯 사용을 언급하고, npm에서는 설치 명령을 제공합니다.
npm i @n8n/chat실제 프런트 코드에서는 Chat Trigger가 보여주는 Chat URL(webhook)을 호출하도록 구성합니다. (Embedded Chat 설명)
어떤 방식부터 쓰면 좋은가
- “정해진 프롬프트로 반복 작업(요약/정리/표준 답변)”이면
→ Chat Hub Personal Agent가 가장 빠르고 안정적 - “내부 데이터 연동/도구 실행/권한 분리/감사/운영 자동화”가 목표면
→ Chat Trigger + AI Agent 워크플로우를 만들고 Make Available in n8n Chat으로 노출하는 방식이 정석
댓글