이전 페이지에서는 운영자가 상품을 관리하는 도구를 만들었습니다. 이제 그 상품 정보와 주문 정보를 AI 상담 챗봇이 안전하게 참고할 수 있도록 백엔드 구조를 설계합니다. 이번 페이지의 목표는 "LLM을 호출한다"가 아니라, 상담 챗봇이 어떤 근거로 답하고 어떤 서비스 데이터에 접근할 수 있는지를 명확히 정하는 것입니다.
실전 서비스의 상담 챗봇은 자유 대화 장난감이 아닙니다. 상품 정보, 배송/교환/환불 정책, 주문 상태, 결제 상태처럼 실제 서비스 데이터에 기대어 답해야 합니다. 동시에 개인정보, 결제 정보, 운영자 전용 정보는 함부로 노출하면 안 됩니다. 그래서 이번 장에서는 RAG, 도메인 조회, 권한 검사, LLM 호출을 하나의 애플리케이션 서비스로 묶어 오케스트레이션합니다.
즉 이번 페이지는 AI 챗봇을 "프론트 채팅창 뒤에 LLM API를 붙이는 기능"이 아니라, 이커머스 도메인 경계를 지키는 상담 백엔드로 만드는 단계입니다.
챗봇 UI를 먼저 만들면 입력창과 말풍선은 빠르게 만들 수 있습니다. 하지만 백엔드 경계가 없으면 곧바로 문제가 생깁니다.
따라서 이번 교재에서는 챗봇 UI보다 먼저 상담 백엔드의 책임과 데이터 흐름을 정합니다.
이 페이지를 읽고 나면 아래 항목이 정리되어 있어야 합니다.
처음부터 모든 질문에 답하는 챗봇을 만들면 구현과 검증이 불가능해집니다. 이번 단계에서는 상담 범위를 아래 네 가지로 제한합니다.
이 범위를 벗어나는 질문은 억지로 답하지 않고, 운영자 상담으로 넘길 수 있다는 응답을 준비합니다.
챗봇이 참고할 지식은 크게 두 종류입니다.
정적 지식은 RAG 검색에 적합합니다. 동적 데이터는 RAG 문서로 복사하지 말고 도메인 서비스를 통해 조회하는 편이 안전합니다. 예를 들어 주문 상태는 매번 바뀌므로 벡터 문서에 넣기보다 Order 조회 API 또는 애플리케이션 서비스를 통해 가져와야 합니다.
RAG는 LLM이 답변할 때 근거 문서를 함께 제공하는 방식입니다. 이번 프로젝트에서는 아래 질문에 유용합니다.
반대로 아래 질문은 RAG만으로 답하면 안 됩니다.
이 질문들은 사용자 세션과 도메인 데이터를 확인해야 합니다.
백엔드 챗봇 API는 최소한 아래 입력을 받습니다.
현재 화면 맥락은 중요합니다. 상품 상세 화면에서 "이거 배송 얼마나 걸려요?"라고 물으면 "이거"가 현재 상품을 의미할 수 있습니다. 주문 상세 화면에서 "왜 아직 안 왔나요?"라고 물으면 현재 주문 상태와 연결될 수 있습니다.
상담 백엔드는 하나의 함수에서 LLM을 바로 호출하지 않습니다. 아래 순서로 처리하는 편이 좋습니다.
이 순서를 지키면 "무엇을 근거로 답했는가"를 나중에 추적할 수 있습니다.
MVP에서는 복잡한 머신러닝 분류기를 만들 필요가 없습니다. 규칙 기반으로 시작해도 충분합니다.
초기 의도는 아래 정도로 나눕니다.
중요한 것은 의도 분류가 완벽한가가 아니라, 어떤 데이터 접근이 필요한지 결정할 수 있는가입니다.
주문 상태 질문은 권한 검사가 핵심입니다. 사용자가 자신의 주문을 물어보는 경우에만 상세 상태를 알려줘야 합니다.
처리 순서는 아래와 같습니다.
이렇게 해야 챗봇이 편해지는 대신 보안이 약해지는 문제를 막을 수 있습니다.
상품 질문은 정적 문서와 현재 상품 데이터를 함께 사용합니다.
Catalog에서 조회한다상품 데이터와 RAG 문서가 충돌하면 현재 도메인 데이터를 우선합니다. 예를 들어 FAQ에는 판매 중이라고 되어 있어도 admin에서 판매 중지한 상품이면 챗봇은 판매 중지 상태로 안내해야 합니다.
결제 질문은 사용자를 불안하게 만들기 쉽기 때문에 응답이 명확해야 합니다.
초기 MVP에서는 아래 정도만 다룹니다.
실제 카드 승인번호, 결제 수단 상세, PG 원문 오류는 사용자가 아닌 운영자 화면에서 다루는 편이 안전합니다.
프롬프트는 모델에게 모든 데이터를 던지는 곳이 아닙니다. 필요한 근거만 정리해서 넣는 계약입니다.
이번 단계에서는 아래 정보를 넣습니다.
반대로 아래 정보는 넣지 않습니다.
프론트가 안정적으로 처리하려면 LLM 응답을 자유 텍스트 하나로만 받지 않는 편이 좋습니다. 백엔드 응답은 아래 구조를 가질 수 있습니다.
이 구조가 있으면 UI는 답변만 보여주는 것을 넘어, 주문 상세 이동이나 고객센터 연결 같은 다음 행동을 자연스럽게 제공할 수 있습니다.
상담 로그는 디버깅과 운영에 유용하지만 개인정보 위험도 있습니다. MVP에서는 아래 정도를 저장합니다.
민감 정보가 들어갈 수 있는 원문 저장은 정책을 먼저 정해야 합니다. 교재에서는 처음부터 무기한 전체 원문 저장을 기본값으로 두지 않는 편이 좋습니다.
챗봇은 모든 질문에 답하려고 하면 위험합니다. 아래 상황에서는 명확히 제한 응답을 해야 합니다.
이때 "아마도"라고 꾸며내기보다, 확인 가능한 범위를 말하고 다음 행동을 안내해야 합니다.
초기 구현에서는 아래 정도의 모듈 경계가 적절합니다.
support/application/chat_service.py: 상담 유스케이스 오케스트레이션support/domain/intent.py: 상담 의도와 정책support/infra/retriever.py: RAG 문서 검색support/infra/llm_client.py: LLM 호출support/infra/conversation_repo.py: 상담 로그 저장catalog/application: 상품 조회order/application: 주문과 결제 상태 조회핵심은 챗봇 서비스가 Catalog, Order, Payment 데이터를 직접 테이블에서 훔쳐보지 않게 하는 것입니다. 각 컨텍스트의 애플리케이션 서비스를 통해 필요한 정보만 받아야 합니다.
이번 장에서 완료라고 볼 수 있는 상태는 아래 정도입니다.
즉 챗봇은 이제 실제 서비스 데이터와 정책 근거를 바탕으로 답해야 합니다.
이번 페이지를 코드와 실행 결과로 옮기면 최소한 아래 산출물이 있어야 합니다.
이 산출물이 있어야 다음 페이지에서 챗 UI, 운영자 핸드오프, 안전장치를 안정적으로 붙일 수 있습니다.
이 일곱 가지 실수는 AI 기능을 붙이는 순간 서비스 신뢰와 보안을 동시에 흔들 수 있습니다.
이번 페이지에서는 AI 상담 챗봇의 백엔드 구조를 설계했습니다. RAG는 정적 지식의 근거를 제공하고, 주문과 결제 같은 동적 정보는 도메인 서비스를 통해 조회해야 한다는 점을 확인했습니다. 또한 의도 분류, 권한 검사, 프롬프트 구성, 구조화 응답, 상담 로그까지 하나의 오케스트레이션 흐름으로 정리했습니다.
다음 페이지에서는 이 백엔드 위에 챗 UI를 붙이고, 운영자 핸드오프와 안전장치를 사용자 경험으로 완성합니다.