이전 페이지에서는 AI 상담 챗봇의 백엔드 오케스트레이션을 설계했습니다. 이제 그 백엔드 API를 storefront에 붙여 실제 사용자가 질문하고 답변을 받을 수 있는 경험으로 완성합니다. 이번 페이지의 핵심은 "채팅창을 예쁘게 만든다"가 아닙니다. 사용자가 어떤 화면에서 어떤 질문을 하게 되고, 챗봇이 답하지 못할 때 어떻게 멈추며, 운영자에게 어떤 맥락을 넘길지를 정하는 것입니다.
실전 서비스에서 챗봇은 구매 흐름을 돕는 보조 인터페이스입니다. 상품 상세에서는 상품과 정책을 설명해야 하고, 주문 상세에서는 내 주문 상태를 안내해야 하며, 결제 실패 화면에서는 사용자가 다음에 무엇을 해야 하는지 알려줘야 합니다. 반대로 확실하지 않은 답변이나 권한이 필요한 정보는 운영자 상담으로 넘겨야 합니다.
즉 이번 페이지는 챗봇을 "LLM 답변 출력기"가 아니라, 구매자 흐름 안에서 안전하게 작동하는 상담 surface로 만드는 단계입니다.
채팅 UI는 겉으로 보기에는 단순합니다. 입력창, 메시지 목록, 전송 버튼만 있으면 되는 것처럼 보입니다. 하지만 실제 서비스에서는 아래 질문을 먼저 정해야 합니다.
이 질문이 정리되지 않으면 UI는 만들어져도 서비스 흐름 안에서 어색하게 동작합니다.
이 페이지를 읽고 나면 아래 항목이 정리되어 있어야 합니다.
MVP에서는 챗봇을 모든 화면에 무작정 띄우기보다, 구매 흐름에서 도움이 되는 화면에 우선 배치합니다.
홈 화면이나 로그인 화면에도 진입 버튼을 둘 수 있지만, 처음에는 상품과 주문 맥락이 있는 화면에서 더 높은 품질의 답변을 만들 수 있습니다.
챗봇 진입 버튼은 단순한 floating button이 아닙니다. 사용자가 지금 화면에서 질문할 수 있다는 신호입니다.
초기 UI에서는 아래 정도가 적절합니다.
중요한 것은 구매 버튼, 결제 버튼, 에러 메시지를 가리지 않는 것입니다. 챗봇은 보조 인터페이스이지, 핵심 구매 행동을 방해하면 안 됩니다.
채팅 패널은 최소한 아래 구조를 가져야 합니다.
초기에는 복잡한 실시간 스트리밍 UI가 없어도 됩니다. 먼저 요청, 응답, 실패, 재시도 흐름이 안정적으로 동작해야 합니다.
챗봇 품질은 현재 화면 맥락에 크게 의존합니다. 따라서 프론트는 질문과 함께 아래 정보를 넘길 수 있어야 합니다.
예를 들어 상품 상세 화면에서는 product_id를 함께 보내고, 주문 상세 화면에서는 order_id를 함께 보냅니다. 그러면 백엔드는 사용자가 "이거 언제 배송돼요?"라고 물어도 어떤 상품이나 주문을 말하는지 추론할 수 있습니다.
추천 질문은 사용자에게 챗봇 사용법을 설명하는 문구보다 낫습니다. 사용자가 바로 눌러볼 수 있는 실제 질문을 제공하기 때문입니다.
상품 상세에서는 아래 질문이 적절합니다.
주문 상세에서는 아래 질문이 적절합니다.
추천 질문은 화면 맥락별로 달라져야 합니다.
챗봇 답변은 단순 문장 하나로 끝나지 않는 편이 좋습니다. 백엔드가 구조화 응답을 반환한다면 UI는 아래 요소를 표현할 수 있습니다.
근거를 너무 길게 보여줄 필요는 없지만, 사용자가 답변이 어디에서 왔는지 최소한 알 수 있어야 합니다. 예를 들어 "배송 정책 기준"이나 "현재 주문 상태 기준" 정도의 출처 표시는 충분히 유용합니다.
상품 정책 질문은 비회원도 답변할 수 있습니다. 하지만 주문 상태나 결제 상태 질문은 로그인과 소유자 확인이 필요합니다.
UI에서는 아래처럼 처리합니다.
백엔드 권한 실패를 단순 오류로 보여주면 안 됩니다. 사용자가 다음 행동을 이해할 수 있게 바꿔야 합니다.
운영자 핸드오프는 챗봇 실패의 패배 선언이 아닙니다. 자동 상담이 처리할 수 없는 상황을 사람에게 넘기는 정상 흐름입니다.
핸드오프 기준은 아래처럼 잡을 수 있습니다.
이 기준이 있어야 챗봇이 억지 답변을 하지 않고 안전하게 멈춥니다.
운영자에게 넘길 때는 사용자가 다시 설명하지 않도록 필요한 맥락을 함께 넘겨야 합니다.
최소한 아래 정보를 전달합니다.
단, 비밀번호, 토큰, 결제 수단 원문, 내부 시스템 오류 상세는 넘기지 않습니다. 운영자가 필요한 것은 문제 맥락이지 민감 정보가 아닙니다.
안전장치는 프론트 문구만으로 해결되지 않습니다. 최소한 세 층에서 필요합니다.
프론트는 사용자가 이해할 수 있게 보여주는 역할이고, 실제 보안과 데이터 제한은 백엔드에서 강제해야 합니다.
실패 메시지는 개발자용 오류를 그대로 보여주면 안 됩니다. 사용자가 할 수 있는 다음 행동을 포함해야 합니다.
예를 들어 아래처럼 구분합니다.
실패를 모두 "오류가 발생했습니다"로 뭉개면 챗봇은 신뢰를 잃습니다.
프론트 상태는 단순 문자열 배열보다 명확한 모델로 관리하는 편이 좋습니다.
메시지는 최소한 아래 필드를 가질 수 있습니다.
status는 sending, done, failed 정도로 시작할 수 있습니다. 이 구조가 있어야 전송 중 메시지, 실패한 메시지 재시도, 답변 근거 표시를 안정적으로 구현할 수 있습니다.
핸드오프가 발생하면 운영자 화면에서도 해당 상담을 볼 수 있어야 합니다. MVP에서는 완전한 상담 티켓 시스템까지 만들지 않아도 됩니다.
초기 운영자 화면에는 아래 정도를 추가할 수 있습니다.
이렇게 해 두면 다음 확장에서 상담 티켓, 알림, 담당자 배정으로 확장할 수 있습니다.
LLM 응답 스트리밍은 사용자 경험을 좋게 만들 수 있지만, MVP의 첫 목표는 안정적인 상담 흐름입니다.
처음에는 일반 요청/응답 방식으로 구현하고, 아래가 안정화된 뒤 스트리밍을 붙이는 편이 좋습니다.
스트리밍은 나중에 붙여도 되지만, 권한과 근거 처리는 나중으로 미루면 위험합니다.
이번 장에서 완료라고 볼 수 있는 상태는 아래 정도입니다.
즉 사용자는 챗봇으로 도움을 받을 수 있고, 챗봇이 처리하지 못하는 문제는 운영자에게 맥락과 함께 넘어가야 합니다.
이번 페이지를 코드와 실행 결과로 옮기면 최소한 아래 산출물이 있어야 합니다.
이 산출물이 있어야 다음 장에서 전체 제품을 통합 검증할 때 챗봇까지 실제 서비스 흐름 안에서 점검할 수 있습니다.
이 여덟 가지 실수는 AI 기능이 있어 보이지만 실제 운영에서는 신뢰하기 어려운 상태로 이어집니다.
다음 단계에서는 제품 전체를 통합 검증하고 품질을 끌어올립니다. 상품 탐색, 인증, 장바구니, 주문, 결제, 운영자 화면, AI 상담 챗봇이 하나의 이커머스 서비스로 이어지는지 확인합니다.