고객지원 챗봇은 겉으로 보기에는 가장 익숙한 AI 응용처럼 보인다. 질문이 들어오고, 답하면 된다. 하지만 실제로는 가장 쉽게 사고가 나는 분야 가운데 하나다. 이유는 간단하다. 고객지원에서는 그럴듯한 말보다 정확한 처리가 중요하기 때문이다. 상품 설명을 조금 멋지게 잘못 말하는 것과, 환불 정책을 잘못 안내하는 것은 무게가 다르다.
그래서 고객지원 챗봇의 품질은 말솜씨보다 경계 설정에서 갈린다. 무엇을 답할 수 있고, 무엇은 답하면 안 되는지 분명해야 한다. FAQ를 잘 찾아주는 능력도 중요하지만, 더 중요한 것은 정책 문서의 우선순위를 이해하고, 예외 상황에서는 멈추고, 필요할 때 사람에게 넘기는 능력이다. 좋은 고객지원 챗봇은 모든 질문에 답하는 챗봇이 아니라, 답할 질문과 넘길 질문을 제대로 구분하는 챗봇이다.
고객지원 챗봇은 왜 자주 실패하는가
많은 팀이 고객지원 챗봇을 만들 때 처음에는 FAQ 문서를 넣는다. 그러고 나서 "주문 취소는 어떻게 해요?", "배송이 늦어요", "환불은 언제 들어오나요?" 같은 질문에 답하게 한다. 초반 데모는 제법 그럴듯하다. 문제는 현실의 고객이 FAQ 문서처럼 질문하지 않는다는 데 있다.
실제 문의는 대개 여러 층이 섞여 있다. 감정이 들어 있고, 정보가 빠져 있고, 자기 상황을 중심으로 말한다. 예를 들어 고객은 "어제 취소했는데 왜 아직 카드값이 안 돌아오죠? 너무 답답하네요"라고 말한다. 이 질문은 단순한 환불 FAQ가 아니다. 주문 상태 확인이 필요할 수도 있고, 카드사 반영 지연이라는 정책 설명이 필요할 수도 있으며, 이미 한 차례 처리 실패가 있었는지 확인해야 할 수도 있다.
고객지원 챗봇이 실패하는 전형적인 이유는 다음 네 가지다.
일반 FAQ 답변과 계정별 처리 답변을 구분하지 못한다.
오래된 정책과 최신 정책이 섞여 있다.
예외 상황에서 확신에 찬 말투로 잘못 안내한다.
사람 상담원에게 넘겨야 할 순간을 놓친다.
이 네 가지는 모두 모델의 똑똑함보다 컨텍스트 설계 문제에 가깝다. 챗봇이 무엇을 볼 수 있는지, 어떤 순서로 참고하는지, 어디서 멈춰야 하는지가 설계되어 있지 않으면 실수는 반복된다.
고객지원에서 컨텍스트는 무엇으로 이루어지는가
고객지원 챗봇의 컨텍스트는 단순히 "답변 참고 자료"가 아니다. 고객의 질문을 처리하기 위해 모델이 지금 이 순간 봐야 하는 운영 환경 전체에 가깝다. 보통 다음 요소가 함께 묶인다.
역할과 행동 규칙이 담긴 시스템 지시문
자주 묻는 질문과 사용법 문서
환불, 교환, 배송, 멤버십 같은 공식 정책 문서
주문 상태, 배송 상태, 계정 상태를 확인하는 도구 결과
현재 대화의 맥락과 감정 상태
상담원 이관 조건과 금지 응답 규칙
여기서 중요한 점이 하나 있다. 모든 정보를 한데 넣는다고 좋은 챗봇이 되지 않는다. 오히려 고객지원에서는 정보의 계층을 나누는 일이 더 중요하다. 사용법을 설명하는 FAQ와 법적 책임이 걸린 정책 문서는 같은 무게로 다뤄지면 안 된다. 계정 정보가 필요한 질문에 일반 문서만 넣어도 안 된다. 반대로 계정 조회 없이도 답할 수 있는 질문에 굳이 민감한 고객 데이터를 불러올 필요도 없다.
고객지원 챗봇은 언제나 이렇게 생각하도록 설계되어야 한다. "이 질문은 일반 안내로 충분한가, 정책 확인이 필요한가, 개인 계정 조회가 필요한가, 아니면 사람 판단이 필요한가?"
FAQ와 정책 문서를 같은 것으로 취급하면 안 된다
많은 조직에서 FAQ는 고객이 자주 물어보는 질문을 쉽게 풀어 쓴 문서다. 반면 정책 문서는 환불 조건, 예외 규정, 처리 기한, 제한 사항처럼 운영 원칙을 공식적으로 적은 문서다. 둘은 비슷해 보이지만 역할이 다르다.
FAQ는 빠르고 친절한 설명에 적합하다. 예를 들어 비밀번호 재설정 방법, 배송 조회 위치, 쿠폰 사용 절차 같은 질문에는 FAQ가 잘 맞는다. 고객은 길고 딱딱한 규정보다 바로 따라 할 수 있는 설명을 원한다.
하지만 환불 가능 여부, 취소 시점, 부분 환불 조건, 약관 예외처럼 결과가 달라지는 질문에서는 정책 문서가 기준이 되어야 한다. FAQ는 설명 문서일 뿐이고, 정책은 판단 기준이다. 이 둘이 충돌할 때는 언제나 정책이 우선해야 한다.
그래서 고객지원 챗봇의 지식 계층은 적어도 이렇게 나뉘어야 한다.
FAQ 계층: 자주 묻는 일반 안내, 사용법, 절차 설명
정책 계층: 환불, 배송, 멤버십, 보안, 개인정보, 약관 등 공식 규정
계정별 데이터 계층: 주문 상태, 결제 상태, 배송 추적, 티켓 이력
이 구조를 분리해 두면 챗봇은 질문 유형에 따라 다른 자료를 우선 참조할 수 있다. 예를 들어 "회원 탈퇴는 어디서 하나요?"에는 FAQ를 먼저 보고, "탈퇴하면 적립금은 어떻게 되나요?"에는 정책을 우선 확인하게 만들 수 있다. "내 주문은 왜 취소가 안 되죠?"는 정책만으로는 부족하므로 계정 데이터 조회까지 이어져야 한다.
즉, 고객지원 챗봇은 문서를 많이 읽는 모델이 아니라, 문서의 법적·운영적 무게를 구분하는 모델이어야 한다.
먼저 해야 할 일은 답변 범위를 정하는 것이다
고객지원 챗봇을 설계할 때 가장 먼저 작성해야 하는 문서는 답변 문서가 아니라 범위 문서다. 챗봇이 할 수 있는 일과 할 수 없는 일을 정의하는 문서다.
예를 들어 다음과 같이 나눌 수 있다.
답할 수 있는 질문: 사용법 안내, 일반 정책 설명, 공개 FAQ, 주문 상태 조회 후 단순 안내
조건부로 답할 수 있는 질문: 계정 인증 후 배송 상태 설명, 환불 진행 상태 확인, 구독 상태 안내
답하면 안 되는 질문: 법적 해석, 보상 확정, 예외 승인, 분쟁 판정, 민감 정보 변경
반드시 이관해야 하는 상황: 환불 분쟁, 욕설 및 감정 악화, 정책 충돌, 보안 사고 의심, 반복 실패
이 범위가 없으면 챗봇은 아는 척을 시작한다. "가능할 것 같아서" 답하고, "대체로 그렇다"는 식의 답변을 내놓는다. 고객지원에서 이런 답변은 위험하다. 특히 "아마 환불될 것입니다"처럼 추정으로 말하는 문장은 고객 기대를 잘못 만든다.
좋은 시스템 지시문은 챗봇에게 친절하라고만 말하지 않는다. 대신 이렇게 가르친다. "정책상 확정되지 않은 결과는 확정적으로 말하지 말 것.", "계정 상태 확인 없이 개인 사례를 단정하지 말 것.", "정책 문서와 실제 상태가 다를 수 있으면 상태 조회 또는 상담원 이관을 우선할 것."
고객지원 챗봇이 신뢰를 얻는 방식은 모든 걸 해결하는 능력이 아니라, 확실한 것만 확실하게 말하는 태도다.
질문을 네 가지 유형으로 분류하라
실전에서는 고객 질문을 몇 가지 유형으로 분류해 두면 컨텍스트 조립이 훨씬 쉬워진다. 고객지원 챗봇에서는 특히 다음 네 가지 구분이 유용하다.
1. 일반 안내형 질문
제품 사용법, 기능 위치, 절차 설명처럼 누구에게나 같은 답을 줄 수 있는 질문이다. 이런 질문에는 FAQ와 도움말 문서만으로 충분한 경우가 많다.
예를 들어 "알림 설정은 어디서 바꾸나요?" 같은 질문은 계정 정보가 필요 없다. 이때 챗봇은 불필요하게 주문 정보나 고객 이력을 불러오지 않아도 된다. 답변은 짧고 명확할수록 좋다.
2. 정책 설명형 질문
환불 규정, 배송 기준, 멤버십 혜택, 개인정보 보관 기간처럼 공식 기준이 중요한 질문이다. 이런 질문은 FAQ보다 정책 문서를 우선해야 한다.
예를 들어 "구독을 중간에 취소하면 남은 기간은 환불되나요?"는 친절한 추정이 아니라 정책 문장에 기반한 설명이 필요하다. 이때 챗봇은 가능하면 조건을 분리해서 설명해야 한다. 언제는 가능하고, 언제는 불가능한지 구체적으로 나눠야 한다.
3. 계정 상태 확인형 질문
주문, 결제, 배송, 구독, 티켓 처리 상태처럼 고객마다 답이 달라지는 질문이다. 이런 질문은 문서만으로 답하면 안 된다. 도구 호출이 필요하다.
예를 들어 "왜 아직 환불이 안 들어왔죠?"는 일반 정책으로는 절반만 답한 셈이다. 실제 환불 요청 일시, 처리 상태, 카드사 반영 소요 시간 같은 데이터가 필요하다. 계정 상태 확인 전에는 일반적인 절차만 설명하고, 확정적인 표현은 피해야 한다.
4. 예외 판단형 질문
정책의 경계선에 있거나 사람 판단이 필요한 질문이다. 예를 들어 약간 늦은 취소 요청, 특별 보상 요청, 반복 장애로 인한 크레딧 요구, 가족 계정 예외 처리 같은 상황이 여기에 해당한다.
이런 질문은 챗봇이 가장 실수하기 쉬운 영역이다. 규정과 사정이 충돌하고, 고객 감정도 실려 있다. 따라서 챗봇이 할 일은 결정을 내리는 것이 아니라 사실을 정리하고 적절한 경로로 넘기는 것이다.
질문 유형을 이렇게 나누면, 같은 "환불" 문의라도 어떤 컨텍스트를 붙여야 하는지가 달라진다. 질문 분류는 답변 생성 이전에 일어나는 가장 중요한 고객지원 작업이다.
최신성 관리가 무너지면 친절한 오답이 된다
고객지원은 시간이 지나면 문서가 낡는다. 배송 정책은 바뀌고, 구독 플랜은 개편되고, 이벤트 환불 조건은 시즌마다 달라진다. 챗봇이 오래된 문서를 계속 참고하면 문제는 조용히 커진다. 겉으로는 여전히 자연스럽게 답하지만, 실제 운영과 맞지 않기 때문이다.
최신성 관리는 고객지원 챗봇의 생명줄이다. 보통은 다음 네 가지를 함께 설계해야 한다.
문서마다 발행일, 개정일, 적용 시작일을 메타데이터로 저장한다.
폐기된 정책 문서는 검색 대상에서 제외하거나 강하게 감점한다.
같은 주제의 문서가 여러 버전이면 최신 공식 문서를 우선한다.
정책 변경 공지는 FAQ보다 높은 우선순위로 반영한다.
예를 들어 예전에는 "결제 후 7일 이내 취소 가능"이었는데 지금은 "출고 전까지만 취소 가능"으로 바뀌었다고 하자. 이때 챗봇이 둘 다 검색해 와서 적당히 섞어 말하면 고객은 더 혼란스러워진다. 최신성 문제는 단순한 검색 품질 문제가 아니라 운영 리스크다.
좋은 고객지원 챗봇은 답변 속에 최신성을 드러내기도 한다. "현재 정책 기준으로", "주문 상태를 확인한 결과", "오늘 적용 중인 구독 정책에 따르면" 같은 표현은 고객에게 지금 보고 있는 기준이 무엇인지 알려 준다. 물론 이런 표현은 실제로 최신 문서를 참조하고 있을 때만 써야 한다.
정책이 충돌할 때 챗봇은 똑똑해지면 안 되고 안전해져야 한다
현실의 조직 문서는 깔끔하지 않다. 운영팀 문서와 마케팅 페이지가 다를 수 있고, 오래된 공지와 새 정책이 함께 남아 있을 수도 있다. 고객지원 챗봇이 이런 충돌을 만나면, 인간처럼 눈치껏 결론을 내리려 해서는 안 된다.
이때의 원칙은 단순하다. 정답을 추론하지 말고 충돌을 감지하라.
예를 들어 한 문서는 "무료 체험 기간 중 취소해도 결제되지 않음"이라고 말하고, 다른 문서는 "체험 중이라도 특정 기능 사용 시 과금 시작"이라고 적고 있을 수 있다. 이런 경우 챗봇이 해야 할 일은 둘 중 하나를 적당히 고르는 것이 아니다. 정책 충돌 가능성을 감지하고, 더 높은 우선순위 문서 또는 상담원 검토로 연결해야 한다.
고객 입장에서는 "모르겠습니다"보다 "서로 다른 안내가 보여 정확한 확인이 필요합니다"가 훨씬 낫다. 전자는 무능해 보이지만, 후자는 책임감 있어 보인다. 고객지원에서는 모르는 척하는 것보다, 확인이 필요하다고 정확히 말하는 능력이 중요하다.
예외 처리는 챗봇의 말하기 기술이 아니라 멈추기 기술이다
예외 상황은 고객지원 챗봇의 품질을 판가름하는 시험장이다. 평범한 질문은 대부분의 시스템이 어느 정도 처리한다. 하지만 예외에서 챗봇의 설계 수준이 드러난다.
예외 처리는 보통 다음 네 갈래로 나타난다.
정책 예외: 일반 규정으로 처리되지 않는 특수 사례
데이터 예외: 주문 정보 없음, 상태 불일치, 조회 실패
감정 예외: 강한 불만, 불안, 반복 문의, 분쟁 조짐
보안 예외: 본인 확인 필요, 계정 탈취 의심, 민감 정보 요청
이 상황에서 챗봇이 할 일은 더 길게 설명하는 것이 아니다. 오히려 짧고 안전하게 정리해야 한다. 예를 들어 데이터 조회가 실패했다면 원인을 지어내지 말고, 필요한 확인 절차와 다음 단계를 안내해야 한다. 고객이 화가 난 상태라면 장문의 정책 설명보다 불편을 인정하고 빠른 이관 경로를 제공하는 편이 낫다.
특히 감정 예외는 자주 과소평가된다. 고객이 같은 질문을 세 번 반복했거나, "이거 사기 아니냐"처럼 신뢰가 크게 떨어진 표현을 사용했다면, 정보 정확성만으로는 문제를 해결하기 어렵다. 이때 챗봇은 문제 해결 엔진이 아니라 관계 악화 방지 장치가 되어야 한다.
상담원 이관 기준은 마지막 장치가 아니라 처음부터 설계해야 한다
많은 팀이 상담원 이관을 실패 처리처럼 여긴다. 챗봇이 못 하면 사람이 받는다고 생각한다. 하지만 실제로는 반대다. 이관 기준은 챗봇의 실패를 수습하는 장치가 아니라, 처음부터 포함되어야 하는 핵심 기능이다.
고객지원 챗봇은 사람과 경쟁하는 시스템이 아니다. 사람 상담원이 더 잘하는 일을 앞단에서 정리해 주는 시스템에 가깝다. 따라서 이관 기준은 보수적으로 설계하는 편이 대체로 안전하다.
다음과 같은 경우에는 이관을 강하게 고려해야 한다.
환불, 보상, 계정 복구처럼 금전 또는 권한 영향이 큰 결정이 필요한 경우
정책 문서 간 충돌이 감지된 경우
계정 정보가 불완전하거나 조회 결과가 이상한 경우
고객이 강한 불만, 법적 표현, 반복 항의를 보이는 경우
동일 질문에 대해 두 번 이상 해결 실패한 경우
본인 확인이 필요한 민감 요청인 경우
여기서 중요한 것은 단순히 "상담원에게 문의하세요"라고 말하는 것이 아니다. 좋은 이관은 맥락을 함께 넘긴다. 고객이 무엇을 물었고, 어떤 문서를 참조했고, 어떤 조회를 했고, 어디서 막혔는지를 요약해서 전달해야 상담원이 처음부터 다시 묻지 않는다.
즉, 이관은 대화 종료가 아니라 컨텍스트 전달이다. 고객이 가장 싫어하는 문장 가운데 하나는 "처음부터 다시 설명해 주세요"다. 컨텍스트 엔지니어링의 관점에서 보면, 훌륭한 고객지원 챗봇은 답변을 잘하는 챗봇이 아니라, 이관할 때도 맥락을 잃지 않는 챗봇이다.
고객지원 챗봇의 시스템 지시문에는 무엇이 들어가야 하는가
고객지원용 시스템 지시문은 친절함만 강조해서는 부족하다. 행동 경계를 명확히 넣어야 한다. 좋은 지시문은 보통 다음 내용을 포함한다.
챗봇의 역할: 일반 안내, 정책 설명, 상태 확인 보조, 이관 안내
우선순위: 정책 문서가 FAQ보다 우선, 최신 문서가 이전 문서보다 우선
금지사항: 미확인 사실 단정 금지, 예외 승인 금지, 법적 해석 금지
응답 스타일: 짧고 명확하게, 필요한 경우 단계별로, 확신 수준을 과장하지 않기
이관 조건: 충돌, 감정 악화, 민감 요청, 반복 실패 시 즉시 전환
데이터 사용 규칙: 계정 조회 전 본인 확인 조건, 민감 정보 직접 노출 금지
특히 고객지원에서는 "모르면 솔직히 말하라"는 지시보다 "모를 때 어떤 절차를 밟을지"를 지정하는 지시가 더 유용하다. 모델은 빈칸을 싫어한다. 그냥 두면 그 빈칸을 추정으로 메우려 한다. 따라서 안전한 기본 동작을 명시해야 한다.
예를 들어 이렇게 설계할 수 있다. "정책이 불명확하거나 계정 상태 확인이 필요한 경우, 일반적 가능성을 추정하지 말고 필요한 확인 절차 또는 상담원 이관 경로를 안내하라." 이 한 줄이 챗봇의 위험한 자신감을 많이 줄여 준다.
고객지원용 컨텍스트 패킷은 이렇게 조립한다
고객 질문이 들어오면 매번 같은 정보를 다 넣을 필요는 없다. 질문 유형에 따라 필요한 컨텍스트만 조립하는 편이 정확성과 비용 측면에서 모두 유리하다.
고객지원용 컨텍스트 패킷은 대개 이런 흐름으로 구성할 수 있다.
첫째, 질문을 분류한다. 일반 안내형인지, 정책 설명형인지, 계정 상태 확인형인지, 예외 판단형인지 먼저 판단한다.
둘째, 필요한 지식 계층만 불러온다. 일반 안내면 FAQ 중심, 정책 질문이면 공식 정책 중심, 상태 질문이면 계정 조회 결과까지 함께 붙인다.
셋째, 최신성과 우선순위를 정리한다. 동일 주제 문서가 여러 개면 최신 공식 문서만 남기고, 폐기된 자료는 제거한다.
넷째, 응답 제한 규칙을 함께 넣는다. 예외 승인 금지, 확정 표현 제한, 이관 기준 적용 같은 규칙을 마지막에 다시 상기시킨다.
다섯째, 필요한 경우 이관 요약을 생성한다. 답변이 아니라 상담원용 메모를 만드는 것이다.
이 과정을 거치면 챗봇은 "자료가 많아서 아무 말이나 하는 상태"에서 벗어나, 질문에 맞는 정보만 보고 판단하는 상태가 된다.
답변 템플릿보다 판단 템플릿이 먼저다
고객지원 팀은 자주 답변 템플릿을 먼저 만든다. 물론 필요한 일이다. 하지만 그보다 더 먼저 필요한 것은 판단 템플릿이다. 즉, 챗봇이 어떤 경로로 갈지 정하는 틀이다.
간단한 판단 템플릿은 다음처럼 구성할 수 있다.
이 질문은 일반 안내인가, 정책 설명인가, 계정 상태 확인인가, 예외 판단인가?
개인 데이터 조회가 필요한가?
공식 정책 확인이 필요한가?
최신성 충돌이 있는가?
확정적으로 말할 수 있는가?
상담원 이관이 더 안전한가?
이 템플릿이 있으면 챗봇은 답변을 만들기 전에 먼저 상황을 구조화한다. 고객지원에서 이는 매우 중요하다. 고객의 질문은 대개 자연어로 엉켜 있지만, 운영 판단은 구조화되어야 하기 때문이다.
예를 들어 "택배가 아직 안 왔는데 환불도 안 되고 상담도 안 돼요"라는 문장은 한 문장 안에 배송 지연, 환불 요청, 상담 불만이라는 세 문제가 들어 있다. 이때 챗봇이 문장 표면만 따라가면 어설픈 종합 답변을 하기 쉽다. 하지만 판단 템플릿을 적용하면 배송 상태 조회 필요, 환불 정책 확인 필요, 반복 실패로 인한 이관 필요라는 식으로 분리할 수 있다.
좋은 고객지원 챗봇은 항상 한 걸음 덜 나간다
고객지원 챗봇은 똑똑해 보이려고 할수록 위험해진다. 사용자의 의도를 넓게 해석하고, 그럴듯한 다음 단계를 제안하고, 정책을 유추해서 말하면 일시적으로는 편해 보일 수 있다. 하지만 고객지원은 창의성보다 일관성이 중요한 영역이다.
그래서 좋은 챗봇은 늘 한 걸음 덜 나간다. 확실하지 않으면 확인하고, 경계선에 있으면 넘기고, 문서가 충돌하면 멈춘다. 얼핏 소극적으로 보이지만, 실제 서비스에서는 이것이 신뢰를 만든다.
특히 고객은 챗봇에게 완벽함보다 공정함을 기대한다. 누구에게는 되고 누구에게는 안 되는 듯한 답변, 상황마다 말이 바뀌는 답변, 상담원마다 다른 답변은 큰 불만을 만든다. 컨텍스트 설계가 중요한 이유는 여기에 있다. 같은 질문에 같은 기준이 적용되도록 만드는 것, 바로 그것이 고객지원 챗봇의 핵심이다.
실전 설계 예시
예를 들어 전자상거래 서비스의 고객지원 챗봇을 설계한다고 해 보자. 이 챗봇은 다음처럼 동작할 수 있다.
고객이 "주문 취소하고 싶어요"라고 말하면 먼저 주문 상태 확인 필요 여부를 판단한다. 주문번호가 없으면 주문 식별 정보를 요청한다. 주문번호가 있으면 계정 도구로 주문 상태를 확인한다. 아직 출고 전이면 취소 가능 정책과 실제 취소 절차를 안내한다. 이미 출고 후면 취소 불가 정책을 설명하되, 반품 가능 조건을 함께 안내한다. 만약 상품 특성상 반품 제한 품목이면 해당 정책 문서를 우선 제시한다. 고객이 강하게 항의하거나 예외 승인을 요구하면 상담원 이관으로 전환한다.
이 흐름에서 중요한 것은 챗봇이 말을 잘하는지가 아니다. 어떤 문서를 먼저 보고, 어떤 상태를 확인하고, 어디서 멈추는지가 더 중요하다. 고객지원 챗봇은 결국 답변 생성기이기 전에 판단 라우터다.
고객지원 챗봇 설계 체크포인트
챕터를 마무리하기 전에, 고객지원 챗봇을 설계할 때 꼭 확인해야 할 질문을 정리해 보자.
FAQ와 정책 문서가 분리되어 있는가?
질문 유형에 따라 다른 컨텍스트를 조립하는가?
계정별 질문에 문서만으로 답하지 않도록 설계했는가?
오래된 정책이 검색되지 않거나 낮은 우선순위를 갖는가?
정책 충돌 시 추론이 아니라 이관이 일어나도록 했는가?
민감 요청과 감정 악화 상황에 대한 예외 규칙이 있는가?
상담원에게 넘길 때 대화 맥락과 조회 결과를 함께 전달하는가?
이 질문에 자신 있게 답할 수 있다면, 그 챗봇은 단순한 자동응답기를 넘어 실제 운영에 투입할 수 있는 고객지원 시스템에 가까워진다.
핵심은 답변 능력이 아니라 경계 설계다
고객지원 챗봇을 만들 때 사람들은 종종 "얼마나 자연스럽게 말하느냐"에 눈길을 빼앗긴다. 하지만 진짜 품질은 다른 곳에서 결정된다. 어떤 질문에 답할지, 어떤 문서를 기준으로 삼을지, 언제 도구를 호출할지, 언제 멈추고 사람에게 넘길지에서 결정된다.
고객지원은 서비스의 얼굴이면서 동시에 규정의 현장이다. 그래서 이 영역의 컨텍스트 엔지니어링은 특히 정교해야 한다. 친절함은 필요하지만, 친절한 오답은 위험하다. 반대로 신중한 정확함은 때로 조금 덜 화려해 보여도 오래 살아남는다.
좋은 고객지원 챗봇은 모든 문의를 혼자 처리하지 않는다. 대신 올바른 문의는 빠르게 해결하고, 위험한 문의는 안전하게 넘긴다. 결국 고객이 원하는 것은 만능 AI가 아니다. 내 상황을 이해하고, 틀리지 않게 안내하며, 필요할 때 사람에게 잘 연결해 주는 시스템이다. 고객지원 챗봇 설계의 핵심은 바로 그 기대를 배신하지 않는 컨텍스트 구조를 만드는 데 있다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.