n8n 멀티채널 고객상담 자동화 — OpenAI RAG와 Supabase로 이메일부터 디스코드까지 한 번에 응대하기

n8n.io 공식 템플릿 마켓플레이스에 공개된 이 워크플로우를 가져오면, 이메일·라이브챗·왓츠앱·슬랙·디스코드로 들어오는 고객 문의를 자체 문서 기반 RAG로 답하고, 답변 근거가 부족하거나 고객 감정이 안 좋을 때는 Zendesk 티켓으로 자동 이관하는 멀티채널 고객상담 자동화를 구성할 수 있습니다.

이 템플릿 하나로 보여줄 수 있는 것

면접에서 "고객 응대 자동화 해보셨어요?"라는 질문을 받으면, 이 템플릿은 "다섯 개 채널의 문의를 하나로 합치고, 모델 호출 전에 비용을 아끼는 가드레일을 먼저 통과시킨 다음, 답변 신뢰도를 근거 유무로 채점해 사람에게 넘길지 판단하게 만들었습니다"라고 답할 재료를 줍니다.

문장 하나지만 안에 들어간 역량은 네 가지입니다.

• 멀티채널 정규화 — 이메일·라이브챗·왓츠앱·슬랙·디스코드처럼 형태가 다른 입력을 하나의 스키마로 합쳐 이후 로직을 채널과 무관하게 짠 경험
• 비용 가드레일 설계 — 모델 호출 전에 걸러야 할 조건을 순서대로 배치해, 답할 필요 없는 메시지에 API 비용을 쓰지 않게 만든 경험
• grounding 기반 신뢰도 채점 — 그럴듯한 답변과 실제로 근거를 찾아 만든 답변을 구분하는 판단 기준을 설계한 경험
• 장애 격리 설계 — 외부 서비스 하나가 죽어도 알림·기록·고객 응답까지 전부 멈추지 않게 만든 경험

이 네 가지는 고객상담뿐 아니라 영업 리드 응대, 사내 헬프데스크, 커뮤니티 운영처럼 "여러 채널의 반복 질문에 사람이 매번 붙어 있어야 하는" 상황 전부에 그대로 쓰입니다.

이 템플릿은 무엇인가

이 워크플로우는 데이터팝콘이 만든 게 아닙니다. n8n 공식 템플릿 마켓플레이스(n8n.io/workflows)에 Answer multi-channel support queries with OpenAI RAG and Supabase라는 이름으로 공개된 템플릿이고, 제작자는 Țugui Dragoș입니다. 카테고리는 Support Chatbot과 AI RAG로 등록돼 있습니다.

공식 설명에 따르면 이 템플릿은 다섯 채널로 들어오는 고객 문의를 자체 문서 기반 RAG로 답하는 워크플로우입니다. 근거가 부족한 답변, 부정적인 감정, 명시적인 이관 요청은 Zendesk 티켓으로 에스컬레이션되고, 모든 대화는 분류·기록되며 주간 리포트로 정리됩니다.

이 시리즈의 다른 템플릿들과 비교하면 노드 수(30개 이상)와 공식 문서 분량 모두 가장 풍부합니다. n8n 설치나 기본 노드 조작법은 n8n으로 반복업무 자동화 포트폴리오 만들기에 정리돼 있으니, 이 글은 노드를 전부 나열하는 대신 배울 만한 설계 패턴 몇 가지에 집중합니다.

구조 — Trigger / Task / Target

공식 문서의 "How it works"를 데이터팝콘 방식인 Trigger/Task/Target 세 칸으로 정리하면 이렇습니다.

• Trigger — 다섯 채널(이메일, 라이브챗, 왓츠앱, 슬랙, 디스코드)의 메시지가 채널별 분기를 거쳐 하나의 공통 스키마로 정규화되며 시작됩니다.
• Task — 다섯 개의 가드레일을 통과한 메시지만 Supabase 벡터스토어를 도구로 쓰는 AI Agent 노드가 사내 문서를 검색해 답을 만들고, grounding(검색 여부·검색 결과 유무)을 기준으로 confidence 점수를 받습니다. 기준 미달이거나 부정적인 감정, 명시적인 이관 요청이 있으면 에스컬레이션 경로로 빠집니다.
• Target — confidence가 충분하면 답변은 원래 채널로 그대로 나갑니다(이메일은 기존 제목 유지, 슬랙은 스레드 답장). 에스컬레이션된 대화는 AI가 작성한 메모와 감정 기반 우선순위를 달고 Zendesk 티켓이 되고, 모든 대화는 분류되어 Google Sheets에 기록됩니다.

노드가 30개가 넘어 구조 전체를 다 옮기기는 어려우니, 설계 의도가 가장 뚜렷한 네 가지만 깊이 봅니다.

다섯 개의 가드레일 — 모델을 부르기도 전에 걸러낸다

공식 문서는 "모델 호출에 비용을 내기 전에 다섯 개의 가드가 먼저 돈다"고 표현합니다. 자동 응답·반송 메일, 빈 본문, 중복 전달, 지나치게 긴 메시지, 6개 언어로 매칭되는 명시적인 사람 요청까지 다섯 가지입니다. 어느 하나라도 걸리면 AI Agent 노드까지 가지 않고 그 자리에서 처리가 끝나 OpenAI API 비용이 나가지 않습니다.

라이브챗 채널은 이 다섯 경로 각각에서 HTTP 응답을 바로 돌려받아, 호출한 쪽이 열린 연결을 붙잡고 기다리지 않습니다. 성공 케이스만 먼저 만들다 보면 놓치기 쉬운 부분을 실패·예외 경로에도 챙겨 둔 셈입니다.

grounding 기반 confidence 채점

신뢰도는 답변이 얼마나 길고 유창한지가 아니라, 에이전트가 실제로 지식베이스를 검색했는지와 그 검색이 뭔가를 찾아냈는지로 매깁니다. 술술 이어지는 문장이라도 검색 근거가 없으면 낮은 점수를 받아, 모델이 문서 없이 그럴듯한 말을 지어내는 RAG의 흔한 문제를 채점 단계에서부터 걸러냅니다.

다만 인사말이나 감사 인사는 이 채점을 그대로 통과시키는 대신 짧게 건너뛰게(short circuit) 되어 있습니다. "감사합니다" 같은 메시지가 근거 없는 답변으로 분류돼 매번 티켓이 열리는 일을 막는 예외 처리입니다.

에스컬레이션 로직 — 사유를 다시 판단하지 않는다

에스컬레이션이 필요하다고 판단되면, 이유를 다시 계산하지 않고 이미 앞 단계에서 나온 결과(가드레일 통과 여부, confidence 점수, 감정 분석 결과)를 재사용해서 사유를 정합니다. 같은 판단을 두 번 하지 않으니 로직이 중복되지 않고, 앞뒤 판단이 서로 어긋날 일도 없습니다.

확정되면 AI가 담당자용 짧은 메모를 작성해 티켓 본문에 넣고, 감정 분석 결과에서 우선순위를 끌어와 Zendesk에 전달합니다. 담당자는 대화 전체를 처음부터 읽지 않고도 티켓이 왜 만들어졌는지 바로 파악할 수 있습니다.

continue-on-error로 장애 하나가 전체를 막지 않게

에스컬레이션 경로의 마지막 몇 단계는 각 노드에 continue-on-error가 설정돼 있습니다. n8n에서 노드 설정의 On Error를 Continue로 두면 그 노드가 실패해도 워크플로우가 멈추지 않고 다음 노드로 넘어갑니다. Zendesk가 잠깐 다운돼도 알림·로그·고객 응답으로 이어지는 체인 전체가 함께 멈추지 않는 이유입니다.

이 워크플로우에는 Error Trigger 노드도 따로 있지만, Zendesk 실패는 그 전역 에러 트리거를 거치지 않고 Slack 알림으로 곧바로 드러나게 되어 있습니다. 노드 하나의 실패를 워크플로우 전체의 실패로 취급하지 않고, 그 실패 자체를 운영자에게 알리는 신호로 바꿔 쓴 설계입니다.

이외에도 채널별 정규화 세부 로직, 주간 리포트, 지식베이스 재수집 같은 기능이 더 있습니다만, 이 네 가지를 이해하면 나머지는 같은 설계 원칙의 반복입니다.

만들기

공식 Setup 단계를 취준생이 따라갈 수 있는 순서로 풀어씁니다.

1. Supabase에 벡터DB 스키마 만들기

템플릿 캔버스의 인입(ingestion) 브랜치 옆 노트에 Supabase SQL이 통째로 적혀 있습니다. 이 SQL을 그대로 실행하면 pgvector 확장, 테이블 3개, 검색용 함수, 인덱스까지 한 번에 만들어집니다.

2. 워크플로우 설정 4가지를 손으로 맞추기

n8n은 임포트 시 노드 설정은 가져오지만 워크플로우 전체 설정(타임존, 실행 타임아웃, 로그 저장 여부)은 가져오지 않습니다. 공식 문서는 임포트 직후 타임존, 실행 타임아웃 180초, 성공한 실행은 저장 안 함, 실패한 실행은 저장함, 이 네 가지를 손으로 맞추라고 안내합니다. 성공한 대화까지 매번 저장하면 실행 이력이 금방 부풀기 때문입니다.

3. n8n Variables 12개 등록

Global Configuration 노트에 정리된 변수 12개를 n8n Variables에 등록합니다. 이 중 4개는 인스턴스마다 값이 달라져서 SET_으로 시작하는 placeholder로 표시돼 있습니다. SUPPORT_EMAIL은 모든 이메일 답장의 발신 주소로 쓰이는 값이라 실제 지원 이메일 주소로 반드시 바꿔야 합니다.

4. 크리덴셜 연결

IMAP·SMTP(이메일), WhatsApp, Slack(트리거·API 두 개), Discord 봇, Zendesk, Google Sheets 서비스 계정, Supabase, OpenAI, Postgres(Supabase와 같은 프로젝트), 웹훅용 Header Auth까지 연결합니다. 다섯 채널을 처음부터 다 쓸 필요는 없으니, 8번처럼 안 쓸 채널의 크리덴셜은 건너뛰어도 됩니다.

5. 문서 소스 교체하기

Load Source Documents 노드는 샘플 문서 3개로 채워져 있어서 임포트 직후에도 파이프라인이 한 번 끝까지 돕니다. 실제로 쓰려면 이 노드를 자신의 문서 소스로 바꾸는데, 출력 형태만 title, url, content 세 필드로 맞추면 됩니다.

6. Google Sheet 준비

userId, channel, message, category, sentiment, timestamp, aiResponse, confidence, escalated, escalationReason 순서로 컬럼을 만듭니다. 순서가 바뀌면 로그 노드가 엉뚱한 컬럼에 값을 씁니다.

7. 수동 인입 실행 후 세 가지 경로 테스트

크리덴셜과 변수를 다 채웠으면 수동 ingestion 트리거를 한 번 실행해 지식베이스를 채웁니다. 이 단계를 건너뛰면 confidence는 항상 0점이고 모든 대화가 사람에게 넘어갑니다. 공식 문서는 이걸 버그가 아니라 의도된 폴백이라고 설명합니다. 지식베이스가 비어 있으면 아무 말이나 답하는 대신 전부 사람에게 넘기는 편이 더 안전하기 때문입니다. 채운 뒤에는 문서에 있는 질문, 사람 이관을 요청하는 메시지, 같은 메시지를 두 번 보내는 중복 상황까지 세 가지를 테스트합니다.

8. 안 쓰는 채널 브랜치 정리

다섯 채널을 다 쓸 필요가 없다면 안 쓰는 채널의 트리거와 정규화 브랜치를 지웁니다. 지우지 않아도 동작에는 문제가 없지만 캔버스가 훨씬 읽기 쉬워집니다.

주의할 점 · 제약

공식 문서에 적힌 제약 중 실제로 부딪히기 쉬운 것들만 추립니다.

• 버전이 고정돼 있습니다 — 제작자가 밝힌 빌드·검증 버전은 n8n 2.32.7, AI Agent 노드 3.1, Postgres 노드 2.7, Google Sheets 노드 4.7, Remove Duplicates 노드 2입니다. 임포트 후 노드별 버전 표시부터 확인하는 편이 안전합니다.
• 디스코드는 릴레이 봇이 필요합니다 — n8n에는 디스코드 전용 트리거가 없고, 디스코드는 커스텀 헤더를 보낼 수 없어 Discord Interactions URL로 직접 붙지도 못합니다. 릴레이 봇이 id, content, channel_id, author.id를 담은 JSON을 n8n 웹훅으로 대신 전달하며, 정확한 바디 형식은 캔버스의 디스코드 노트에 문서화돼 있습니다.
• 라이브챗 중복 판별은 폴백에 의존합니다 — message_id를 보내는 라이브챗이면 그걸로 중복을 정확히 걸러내지만, 안 보내는 provider는 콘텐츠 해시를 1분 단위로 묶어 판별합니다. provider의 재시도는 막아주지만 엄격한 보장은 아닙니다.
• 지식베이스 테이블 이름이 두 곳에 있습니다 — 변수로도 있고 검색 함수 안에도 하드코딩돼 있어서, 둘 다 바꾸지 않으면 검색이 에러 없이 오래된 테이블을 읽습니다. 임베딩 모델을 바꿀 때도 세팅 SQL의 벡터 차원을 함께 바꾸고 테이블을 다시 만들어야 합니다.
• 키워드 매칭이지 언어 감지가 아닙니다 — 이관 요청·에스컬레이션·카테고리 분류·스몰토크 판별 게이트는 영어·루마니아어·독일어·프랑스어·스페인어·이탈리아어 6개 언어를 커버하지만, 실제 언어 감지가 아니라 키워드 매칭이라 목록에 없는 표현은 걸러지지 않을 수 있습니다.

포트폴리오·면접 포인트

포트폴리오에 전체를 다 재현할 필요는 없습니다. 채널 하나(예: 이메일)만 남기고 나머지 네 브랜치를 지운 축소판으로도 "가드레일 → RAG 답변 → confidence 채점 → 에스컬레이션"이라는 핵심 구조는 그대로 보여줄 수 있습니다.

면접에서는 "왜 신뢰도를 답변 길이나 유창함이 아니라 검색 여부로 판단했나요?"라는 질문이 나올 수 있습니다. "모델은 근거가 없어도 그럴듯한 문장을 만들어낼 수 있어서, 실제로 지식베이스를 검색했고 결과가 있었는지를 기준으로 삼는 게 더 안전하다"고 답할 수 있으면, 템플릿을 그대로 가져다 쓴 사람과 구조를 이해한 사람이 갈립니다.

다음 액션

다음 편에서는 같은 마켓플레이스에서 유튜브 영상 자막을 외부 API로 추출하는 템플릿을 다룹니다. 이번 편처럼 여러 안전장치를 촘촘히 쌓는 대신, 외부 서비스 하나에 작업을 통째로 위임하는 정반대 접근을 보게 됩니다.