에이전트 가이드#
이 워크플로우는 고객지원(CS) 챗봇용 라우팅 + RAG + 사람 상담원 연계를 한 번에 처리하는 템플릿입니다.사용자 질문이 들어오면 아래 3가지 경로 중 하나로 자동 라우팅됩니다.1.
일반 챗봇 응답: 단순 문의·안내 → LLM 단독 답변
2.
지식 검색 기반 RAG 응답: 도움말/정책/매뉴얼 등 문서 조회 필요 → RAG 검색 + LLM 답변
3.
긴급 케이스 사람 상담원 연결: 사기/보안/서비스 중단 등 → 상담원 인계 요약 + 사용자 안내
워크플로우 사진

| 항목 | 항목 | 노드 유형/ID | 워크플로우 설명 |
|---|
| 1 | storm/request | Start / 1 | 외부에서 들어온 사용자 질문(query)을 워크플로우로 전달하는 진입점. |
| 2 | 커스텀 변수 생성 | LLM / 5 | 사용자의 질문을 분석하여 |
need_rag (지식 검색 필요 여부) | | | |
need_api (API 호출 필요 여부) | | | |
intent_label (사용자의 질문 의도 라벨) | | | |
user_language (사용자의 언어) | | | |
priority (우선순위: low/normal/high/urgent) | | | |
entities (사용자 이름, 고객정보 라벨 등) | | | |
| 엄격한 JSON으로 생성. | | | |
| 3 | 커스텀 변수에게 값 할당 | 변수 할당 / 11 | [5] 결과 JSON에서 필요한 필드를 꺼내서custom_variables.need_rag, need_api, intent_label, entities, user_language, priority 로 세팅. |
| 4 | 커스텀 변수에 기반한 조건 분기 | If Else / 6 | priority와 need_rag 값에 따라 분기: |
1.
priority == "urgent" → 사람 상담원 인계 플로우(그 외 중)
2.
need_rag == "TRUE" → RAG 검색 플로우
3. 나머지 → 일반 챗봇 플로우 |
| 4-1 | priority == "urgent" | If Else / 6 (IF1) | |
| 4-1-1 | → 상황 요약 드래프트 생성 | LLM / 7 | 상담원에게 전달할 드래프트 생성 |
| 4-1-2 | → 커스텀 변수에게 값 할당 | 변수할당 / 13 | [7] 결과를assistant_draft_ko로 세팅 |
| 4-1-3 | →안내 메세지 생성 | LLM / 9 | [7] 결과를 유인상담원에게 전달 완료 했다는 안내 메세지 생성 |
| 4-1-4 | →storm/response | END / 4 | 최종 응답을 외부에 반환 |
| 4-2 | need_rag == "TRUE" | If Else / 6 (IF2) | |
| 4-2-1 | →검색 쿼리 확장 | LLM / 12 | RAG하기 전 검색 키워드 확장 |
| 4-2-2 | → 필요한 지식 검색 | 검색 / 2 | [12] 결과를 기반으로 유사도 높은 정보 검색 |
| 4-2-3 | →답변 생성 | LLM / 3 | [2] 결과를 기반으로 응답 생성 |
| 4-2-4 | →storm/response | END / 4 | 최종 응답을 외부에 반환 |
| 4-3-1 | IF1,IF2 조건 불충족 | If Else / 6 (Else) | |
| 4-3-2 | →답변 생성 | LLM / 10 | 일반 대화로 판정하여 질문에 해당하는 답변 생성 |
| 4-3-3 | →storm/response | END / 4 | 최종 응답을 외부에 반환 |
문의 분류 및 메타데이터 추출 (노드 5 + 11)분류 스키마 커스터마이징#
[출력 형식]
출력은 JSON 형식으로만 작성합니다.
JSON 코드 외의 다른 내용은 절대 포함하지 않습니다.예시:
{
"need_rag": "TRUE|FALSE",
"need_api": "TRUE|FALSE",
"intent_label": "",
"entities": {"product": "","order_id": "","account_id": "","dates": [],
"amount": ""
"user_language": "ko|en|ja|...",
"priority": "low|normal|high|urgent",
"confidence": 0.0,
"reason": "",
"pii_flags": {"email": false,"phone": false,"address": false}
}
‘문의 분류’ 단계에서는 문의 유형, RAG 필요 여부, API 필요 여부, 우선순위, language 등 라우팅에 필요한 핵심 요소를 JSON 코드로 출력하도록 지시하고 있습니다.
기본 스키마 외에 추가로 저장·활용하고 싶은 메타데이터(예: 채널, 요금제, 조직/팀 등)가 있다면, JSON 스키마에 필드를 추가한 뒤 variable 노드에서 해당 값을 새로운 커스텀 변수에 할당해 사용할 수 있습니다.
예시:
{
"need_rag": "TRUE|FALSE",
"need_api": "TRUE|FALSE",
"intent_label": "",
"entities": {"product": "","order_id": "","account_id": "","dates": [],
"amount": ""
"user_language": "ko|en|ja|...",
"priority": "low|normal|high|urgent",
"confidence": 0.0,
"reason": "",
"pii_flags": {"email": false,"phone": false,"address": false}
**"channel": "web|app|phone",
"plan_tier": "free|pro|enterprise"**
}
위와 같이 필드를 추가하고, variable 노드에서 "channel", "plan_tier" 등을 새로운 커스텀 변수에 매핑하면, 이후 라우팅 단계나 답변 생성 단계에서 더 정교하게 활용할 수 있습니다.
분기 조건 커스터마이징#
현재 템플릿에서는 우선순위가 urgent인 경우 무조건 사람 상담원 인계 플로우로 보내고, 그 외에는 need_rag 값에 따라 RAG 플로우 / 일반 챗봇 플로우로 라우팅하고 있습니다.
만약 API 호출이 필요한 케이스를 별도 플로우로 빼고 싶다면, need_api == "TRUE" 조건을 가진 IF 블록을 추가하고, 별도의 API 호출 워크플로우 노드로 연결하면 됩니다.
상담원 인계 요약 생성 (노드 7 + 13 + 9)상담원용 요약 구조 변경#
템플릿에서는 불릿 리스트 + JSON 2단 구조로 인계 내용을 생성하고 있습니다.
사내 티켓 시스템과의 연동 스펙에 맞추고 싶을 경우, JSON 구조를 해당 시스템의 필드명에 맞게 수정한 뒤, 연동 로직에서 이 JSON을 그대로 사용하면 됩니다.
1. 상담원용 불릿 리스트 (예: 한국어 또는 영어)
- 사용자 요청 요약
- 이미 시도한 단계
- 현재 상태 및 차단 요소
- 긴급도와 그 근거
- 필요한 권한/시스템
- 추출된 식별자(주문번호, 계정 등)
- 제안 해결책/우회 방법
- 상담원이 해야 할 다음 액션시스템 연계를 위한 JSON 블록
{
"summary_ko": "",
"priority": "low|normal|high|urgent",
"entities": {
"order_id": "",
"account_id": "",
"email": "",
"product": "",
"dates": []
},
"requested_action": "refund|cancel|investigate|update_info|escalate|other"
}
사용자 안내 메시지 커스터마이징#
템플릿에서는 상담원 인계 이후, 사용자 언어(user_language)에 맞춘 안내 메시지를 생성해 “어떤 내용으로, 어떻게 접수되었는지 / 이후 어떤 절차가 진행되는지”를 알려줍니다.
예: “접수 완료 후 24시간 이내 답변”, “이메일로 결과 안내”, “추가로 준비하면 좋은 정보” 등 정책에 맞는 내용을 프롬프트에 고정해 둘 수 있습니다.
지식 검색 (RAG) 설정 (노드 12 + 2)쿼리 확장 규칙 조정#
이 단계에서는 원문의 질문 + intent + entities를 기반으로, 검색 재현율이 높은 하나의 쿼리 문자열을 만들어 RAG 검색 노드에 전달합니다.
특정 제품군, 특정 기간, 특정 정책 문서 위주로 검색하고 싶다면, 프롬프트에 “제품명/버전/릴리즈 날짜/정책 키워드” 등을 더 강조해 주거나, 별도 커스텀 변수를 쿼리에 강제 포함하도록 설정할 수 있습니다.
[출력 형식]
출력은 확장된 최종 검색 쿼리 문자열 1줄만 작성합니다.
JSON, 설명 문장, 인용부호는 절대 포함하지 않습니다.
- 사용자의 언어를 우선 사용하되, 필요 시 영어 동의어를 1~2개 추가합니다.
- product, amount, dates 등 핵심 엔티티를 포함합니다.
- 민감한 PII는 "email", "phone" 등 일반화된 토큰으로 변환합니다.
답변 생성 (일반 LLM & RAG LLM) (노드 3 + 10)RAG 기반 답변 정책 설정#
정책/약관 관련 문의가 많은 환경에서는, 위와 같이 “컨텍스트 내 정보만 사용” 규칙을 강하게 걸어두면 할루시네이션을 최소화할 수 있습니다.
도메인에 따라 필수로 포함해야 하는 안내 문구(예: 금융 상품 고지사항, 개인정보 처리 안내 등)를 system 프롬프트에 고정해 두면, CS 응답 품질을 표준화할 수 있습니다.
1. 반드시 제공된 컨텍스트 내 정보만 사용하여 답변합니다.
2. 컨 텍스트에 답이 없으면, 사전에 정의된 사과 문구를 그대로 사용합니다.
3. 정책/보증/수수료/날짜는 컨텍스트에 적힌 값을 수정 없이 그대로 포함합니다.
4. 숫자, URL, 특정 계정 정보는 절대 지어내지 않습니다.
일반 챗봇 답변 톤/형식 설정#
템플릿에서는 “한 줄 요약 → 번호 목록 단계 → 선택적 팁 한 줄” 형식으로 답변을 생성하게 되어 있습니다.
개발자용 기술 지원: 에러 코드/로그 요청을 디폴트로 포함
일반 소비자용 CS: “앱에서의 실제 버튼 위치” 등 UI 경로 위주 설명와 같이, 안내의 포맷과 단계 구성을 원하는 형태로 조정할 수 있습니다.
현재 템플릿에서 긴 대화나 많은 컨텍스트를 한 번에 다룰 경우, 일부 LLM 노드(특히 RAG 답변 노드 및 상담원 인계 요약 노드)에서 최대 토큰 한도를 초과해 출력이 중간에 끊길 수 있습니다. 이 경우 사용자는 “지금까지 요약해서 다시 말해줘”, “위 답변의 3번 단계만 다시 자세히 설명해줘” 등의 쿼리를 입력해 필요한 부분만 재생성하는 식으로 보완할 수 있습니다.
문의 분류(노드 5)와 단계 판단(노드 6)은 기본적으 로 LLM 판단에 의존하고 있기 때문에, **경계 케이스(예: 애매한 불만/컴플레인, 농담, 잡담)**에서 의도·우선순위가 잘못 분류될 수 있습니다. 중요한 비즈니스 도메인에서는:특정 키워드 기반의 규칙(예: “카드 도용”, “보안”, “결제 사기”)을 IF/ELSE 조건에 추가하고
우선순위를 강제로 상향 조정하거나 상담원 플로우로 보내는 방식으로 안정성을 높일 수 있습니다.
RAG 기반 답변 품질은 사전에 준비된 지식 데이터의 품질과 범위에 따라 크게 달라집니다. 특정 상품/정책에 대한 문의가 반복적으로 “컨텍스트 없음” 응답을 유도한다면, 해당 영역의 자료를 별도로 정리하여 버킷에 추가하고, 쿼리 확장 규칙에서 그 키워드를 더 강하게 반영하도록 프롬프트를 조정해야 합니다.
SaaS 제품 고객지원용 에이전트로 활용하여,요금제/과금/업데이트 정책 등은 RAG로 정확히 안내하고
비정형 문의나 계정 관련 이슈는 필요 시 상담원 플로우로 자동 인계하는 하이브리드 CS 챗봇 구축
전자상거래(이커머스) 환경에서 주문/배송/환불 문의를 처리하는 에이전트로 활용하여,배송·반품·쿠폰 정책 문서는 RAG 버킷에 저장하고
“미승인 결제”, “계정 도용” 등의 키워드는 자동으로 urgent 처리하여 보안/결제 전담팀에 인계
Modified at 2025-12-23 07:58:24