AWS 기술 블로그
더블유젯소프트(WZSOFT)의 미음 챗봇 도입기: AWS Bedrock 기반 AI 챗봇으로 뷰티샵 상담 자동화 하기
들어가며
더블유젯소프트(WZSOFT)는 뷰티샵 운영의 디지털 전환을 선도하는 SaaS 플랫폼 미음을 통해, 예약 관리, 고객 응대, 매출 분석 등 운영에 필요한 기능을 통합적으로 제공합니다. 미음은 디자이너가 시술에 집중할 수 있도록 반복적인 관리 업무를 자동화하고, 매장 운영 효율을 극대화하는 것을 목표로 합니다.
뷰티샵의 고객 상담은 운영 시간, 시술 가격, 예약 변경 등 정형화된 문의가 대부분입니다. 하지만 이러한 반복적인 업무는 여전히 사람의 개입이 필요하고, 그로 인해 디자이너는 시술에 집중하기 어려워집니다. 특히 시술 중에는 실시간으로 들어오는 고객 문의에 즉시 응답하기 어렵기 때문에, 응답이 늦어지거나 누락되며, 이는 고객 불만이나 예약 이탈로 이어질 수 있습니다. 이를 해결하기 위해 미음은 Amazon Bedrock과 Claude 3.5 모델을 기반으로 한 생성형 AI 챗봇을 도입해 반복 상담 업무를 자동화했습니다.
이번 글에서는 미음 서비스에 Amazon Bedrock을 활용해 구축한 AI 예약 상담 챗봇이 어떻게 뷰티샵의 고객 응대 효율을 높이고 반복 업무를 자동화하는지 소개합니다. 특히 Lambda 기반의 Action Group 설계, 프롬프트 최적화 전략, 그리고 세션 및 메시지 관리 워크플로우를 중심으로, 운영 경험을 바탕으로 얻은 인사이트를 통해 생성형 AI 도입을 고민하는 팀이 실질적인 참고 사례를 얻을 수 있도록 공유드립니다.
도입 배경
미음은 뷰티샵 운영자가 카카오톡, 인스타그램, 네이버 톡톡 같은 여러 채널을 오가며 고객 문의에 응대해야 하는 불편함을 해결하기 위해, 다양한 채널의 메시지를 한 플랫폼에서 통합 관리하는 ’SNS 채팅 통합 기능’을 제공하고 있습니다. 이를 통해 디자이너는 고객 정보와 예약 내역을 한눈에 확인하며 더 효율적으로 상담할 수 있는 환경을 갖췄습니다.
Figure 1. 미음 통합 채팅 화면
하지만 채널이 통합되었음에도 운영 시간, 시술 가격, 예약 변경 같은 반복적인 문의가 매일 이어졌고, 특히 1인 샵이나 소규모 매장에서는 디자이너가 시술 중에도 모든 문의를 직접 처리해야 했습니다. 미음이 실제 고객 상담 데이터를 분석한 결과, 디자이너 한 명이 하루 평균 20~30건의 문의를 처리하며, 이 중 샵 정보 문의(시술 가격, 예약금, 운영 시간 등)가 약 37%, 예약 관련 문의(예약 가능 시간 확인, 변경, 취소 등)가 약 28%, 시술 디자인 문의가 약 15%를 차지했습니다. 샵 정보와 예약 관련 문의가 전체의 약 65%를 차지하면서, 이 두 영역이 반복 상담의 핵심이라는 점이 분명해졌습니다. 그러나 시술 중에는 실시간 문의에 바로 응답하기 어려워 답변이 늦어지거나 누락되는 경우가 많았고, 결국 고객이 예약을 취소하거나 다른 매장을 선택하는 일이 발생했습니다.
이러한 비효율을 해결하기 위해 미음은 생성형 AI를 활용한 상담 자동화를 구상했고, 여러 기술 옵션을 검토한 끝에 Amazon Bedrock과 Claude 3.5 모델 기반의 AI 챗봇을 선택했습니다. 이 기술은 빠른 프로토타이핑과 테스트가 가능하며, Lambda 함수 호출로 예약 시스템과 유연하게 연동되고, 기존 AWS 인프라와의 통합이 쉬워 실 서비스 적용에 적합했습니다. 이 챗봇 솔루션은 디자이너의 상담 부담을 줄이고 고객 문의에 신속 정확하게 응답함으로써 고객 유지율을 높이고 뷰티샵 운영 효율을 극대화하는 것을 목표로 합니다.
AI 챗봇 아키텍처
Figure 2. GenAI 챗봇 아키텍처
저희는 Amazon Bedrock을 중심으로 샵의 예약 관련 문의와 샵 정보 문의를 실시간으로 처리할 수 있는 생성형 AI 챗봇 아키텍처를 설계했습니다. 이 시스템은 고객 메시지
수신부터 응답 생성까지 다음과 같은 단계로 구성됩니다.
- 소켓 서버의 고객 메시지 수신 고객이 카카오톡, 인스타그램, 네이버 톡톡 등 다양한 채널에서 메시지를 보내면, 소켓 서버가 이를 수신합니다. WebSocket 기반의 소켓 서버는 실시간 메시지 처리를 지원하며, 수신된 메시지는 Amazon DynamoDB에 저장되어 대화 이력이 관리됩니다.
- Amazon Bedrock 에이전트 호출고객 메시지는 Amazon Bedrock 에이전트로 전달됩니다. Claude 3.5 모델 기반의 에이전트는 메시지의 의도를 분석한 뒤, 등록된 Action Group과 함수 스키마를 바탕으로 어떤 작업이 필요한지를 판단하고, 그에 필요한 데이터를 수집합니다.예를 들어, 고객이 예약 등록을 요청한 경우, 예약 날짜나 원하는 시술 정보를 확인하기 위해 추가 질문을 생성하고, 수집된 정보를 바탕으로 적절한 Lambda 함수를 호출합니다.
- AWS Lambda 기반 액션 실행 에이전트가 판단한 작업을 실행하기 위해 AWS Lambda Action Group 함수가 호출됩니다. Lambda는 Amazon RDS PostgreSQL에 접근하여 예약 가능 시간 확인, 새로운 예약 등록, 예약 변경, 취소 같은 작업을 수행합니다.
- 최종 응답 생성 및 고객 전달 Lambda의 실행 결과는 다시 Bedrock 에이전트로 전달되고, 에이전트는 이를 바탕으로 자연스러운 응답 메시지를 생성합니다. 최종 응답은 소켓 서버를 통해 고객에게 전송됩니다.
솔루션 구현 상세
Action Group 및 함수 스키마 설계
Amazon Bedrock 에이전트는 Action Group에 정의된 함수 스키마를 기반으로 고객과의 대화에서 필요한 정보를 수집하고, 이를 바탕으로 Lambda 함수를 호출해 작업을 수행합니다. 하나의 Action Group은 단일 Lambda 엔드포인트를 호출하며, 이 Lambda는 내부적으로 여러 기능을 분기하여 처리할 수 있습니다. 이를 통해 에이전트는 복잡한 사용자 요청도 대화 흐름에 따라 자연스럽게 처리할 수 있습니다.
Action Group에서 가장 중요한 요소는 바로 함수 스키마입니다. 스키마는 함수의 역할과 입력 파라미터(이름, 타입, 설명 등)를 명확히 정의하며, 이를 통해 에이전트는 고객에게 어떤 정보를 어떻게 질문할지 판단하게 됩니다. 스키마가 명확할수록 불필요한 재질문을 줄이고, 에이전트의 응답 정확도를 향상시킬 수 있습니다.
register-reservation-action-group은 뷰티샵 예약 등록에 필요한 함수들이 포함된 Action Group입니다. 이 그룹은 다음과 같은 함수들로 구성되어 있습니다.
retrieve-entity-id: 직원 또는 시술명을 기반으로 고유 ID를 조회합니다.get-reservation-windows: 특정 날짜, 직원 ID, 시술 ID를 기반으로 예약 가능한 시간대를 반환합니다.register-reservation: 고객 정보와 예약 시간, 직원/시술 ID 등을 입력받아 예약을 등록합니다.
먼저 get-reservation-windows 함수의 스키마를 살펴보겠습니다.
{
"name": "get-reservation-windows",
"description": "Returns available reservation times for a specific date and selected treatment. The returned `from` and `to` times define the complete window of acceptable starting times. IMPORTANT: These times already factor in the full treatment duration, so any starting time within this range (including exactly at the `from` or `to` time) is valid and will ensure the treatment can be completed without scheduling conflicts. Customers can choose any 10-minute slot within this range. Do not further restrict the time range by attempting to subtract the treatment duration from the `to` time - this calculation has already been performed by the system.",
"parameters": {
"date": {
"description": "The date for which the reservation is requested. Past dates will return no availability. Ex) '2024-12-23'",
"required": "True",
"type": "string"
},
"staffIds": {
"description": "The IDs of staff members to check availability for. If empty, availability for all staff members will be returned.",
"required": "True",
"type": "array"
},
"treatmentIds": {
"description": "The IDs of treatments to be reserved. These IDs are used to determine the total treatment duration, which is then used to calculate the available reservation time window. The returned time window ensures that any selected time within this range will allow the treatment(s) to be completed within the designer’s available schedule.",
"required": "True",
"type": "array"
}
},
"requireConfirmation": "DISABLED"
}이 함수는 특정 날짜와 선택한 시술에 대해 예약 가능한 시간대를 반환합니다.
함수는 반환 시점에 이미 시술 소요 시간을 고려하여 고객이 시술을 시작할 수 있는 예약 가능한 시간대를 제공합니다. 예를 들어, 해당 함수가 소요시간이 3시간인 시술이 가능한 시간대를 요청했을 때 “14:00~16:00” 라는 시간대를 반환했다면, 이는 고객이 시술을 16:00에 시작하더라도 3시간이 소요되는 전체 시술을 마칠 수 있는 시간대임을 의미합니다.
하지만 초기 구현에서는, 에이전트가 이를 다시 검토하며 잘못 이해해 불필요하게 시간대를 축소하는 문제가 발생했습니다. 예를 들어, 14:00~16:00 라는 시간대가 반환되었고 시술 시간이 3시간일 경우, 에이전트가 “해당 시간대는 2시간밖에 안 되므로 예약이 불가능하다”는 잘못된 응답을 생성하는 문제였습니다. 이는 에이전트가 반환값의 의미를 정확히 이해하지 못한 데서 비롯된 오류였습니다.
이를 해결하기 위해 스키마의 description에 함수 반환값과 사용법을 명확히 안내하는 문구를 추가했습니다. 반환된 시간대가 시술 시간을 이미 반영한 값임을 강조하고, 불필요한 추가 계산을 하지 않도록 주의 문구를 포함하여 응답 오류를 방지했습니다.
다음으로, register-reservation 함수의 스키마 설계를 살펴보겠습니다.
저희는 예약 등록 전에 고객이 최종 예약 상세 내역을 확인하고 동의하는 절차를 거쳐야 한다는 요구사항이 있었습니다. 초기에는 이 절차를 스키마의 instructions 필드에 명시했으나, 에이전트가 이를 종종 무시하는 문제가 발생했습니다.
이를 해결하기 위해 register-reservation 함수의 파라미터 중 notes라는 파라미터를 활용했습니다.
"parameters": {
"notes": {
"description": "Required field containing special requests or important information for staff.",
"required": "True",
"type": "string"
}
}기존에는 notes 파라미터를 통해, 해당 예약에 대해 직원에게 전달해야 할 주요사항 또는 특이사항에 대한 메모 작성을 강제하고 있었습니다. 여기에 “고객이 최종 예약 상세 내역을 확인하고 동의했는지 여부”를 반드시 포함하도록 스키마 설명을 수정했습니다.
"parameters": {
"notes": {
"description": "This field contains special requests or important notes for staff. It must start with 'Confirmed, ' followed by any special requests or notes. This field should only be populated after the agent has summarized all reservation details to the customer in a step-by-step manner, received explicit confirmation from the customer, and requested confirmation again if not initially received. The 'Confirmed' prefix serves as verification that this confirmation process has been completed.",
"required": "True",
"type": "string"
}
}이후 에이전트는 예약 등록 전에 고객 확인 절차를 거치는 과정의 누락 비율이 현저히 낮아졌으며, 이를 통해 예약 과정의 정확성이 개선되었습니다.
결론적으로, 스키마 설계 시 상세하고 명확한 설명을 통해 에이전트가 작업의 목적과 파라미터를 정확히 이해하도록 하는 것이 중요합니다. 스키마를 통해 거쳐야 할 절차나 필요한 데이터를 명확히 정의하면, 에이전트가 해당 과정을 누락 없이 수행하도록 유도할 수 있습니다. 위 사례들은 스키마를 통해 필요한 절차와 데이터를 명확히 정의함으로써 에이전트가 더 정확한 동작을 수행할 수 있음을 보여줍니다.
에이전트 Instructions 최적화
Instructions는 Amazon Bedrock 에이전트가 고객과의 대화에서 어떤 방식으로 응답하고, 어떤 절차를 따라야 하는지를 정의하는 지침입니다. 이는 에이전트의 대화 흐름과 응답 스타일을 결정하며, Action Group에서 정의된 작업과 데이터를 실제 대화에 적용하는 데 중요한 역할을 합니다.
저희는 챗봇 베타 버전을 신속히 개발해 파트너 샵에서 테스트하고자 했습니다. 빠른 개발을 위해 초기 Instructions(v1)은 한글로 작성되었으며, 예외 케이스가 발견될 때마다 지침을 추가해 안정성을 높였습니다. 하지만 이 과정에서 프롬프트 크기가 급증해 Claude 3.5 기준 약 5,300 토큰에 달했고, 이는 높은 비용과 유지보수 어려움을 초래했습니다.
실 서비스 도입에 앞서 챗봇 응답 품질을 유지하면서 비용과 유지보수성을 높이고자, Anthropic의 prompt engineering과 prompt improver를 참고해 에이전트 Instructions를 전면 재구성하며 프롬프트 효율성을 개선했습니다. 주요 변경 사항은 아래와 같이 정리할 수 있습니다.
1. 영어 기반 작성 및 prompt template 사용
프롬프트의 토큰 수를 줄이기 위해 한글로 작성된 v1 Instructions를 영어로 변환하고, 반복적으로 등장하던 응답 형식을 템플릿으로 통합해 중복을 제거했습니다. 예약 등록, 조회, 변경, 취소 관련 모든 내용에서 반복적으로 사용되던 예약 상세 내역 포맷을 prompt template으로 작성해 Instructions 상단에 배치했습니다.
기존에는 태그를 사용해 응답 형식을 제공했으나, 응답에 태그가 같이 노출되는 버그가 있어 이를 triple backticks(“`)로 대체했습니다. 아래는 v1과 v2의 차이를 보여줍니다.
- v1 Instructions
- v2 Instructions
이를 통해 중복된 응답 형식을 템플릿화하여 Instructions의 크기를 줄이고, 유지보수성을 높였습니다.
2. Multi-shot prompting
앞서 다룬 get-reservation-windows 함수의 시간대 계산 오류 문제를 해결하기 위해 multi-shot prompting을 사용했습니다. 에이전트가 시간대 계산 오류를 반복하지 않도록, 구체적인 시간대 처리 규칙과 함께 예시를 제공하여 에이전트의 이해를 강화했습니다. 아래는 적용된 Instructions의 일부입니다.
이를 통해 에이전트는 시간대 처리 규칙을 더 명확히 이해하고, 고객 요청에 정확히 응답할 수 있게 되었습니다.
3. 단계별 절차 정의
기획 단계에서 예약 등록, 변경, 취소 전에 최종 예약 내역을 고객에게 확인받는 과정이 필요하다는 요구사항이 있었습니다. Action Group 스키마 설계에서 이를 notes 파라미터에 반영했지만, Instructions에서도 이를 명확히 정의하지 않으면 에이전트가 확인 절차를 누락할 가능성이 있었습니다. v1 Instructions에서는 이 절차를 단순히 “예약 등록 전에 고객 확인을 받아라” 정도로만 정의했으나, 테스트 결과 에이전트가 고객에게 예약 내역을 제공하며 최종 확인을 받는 경우가 매우 낮았습니다.
이를 해결하기 위해 예약 관련 프로세스별로 에이전트의 작업 단계를 명확히 정의했습니다. 아래는 수정된 Instructions의 일부입니다.
4. 다국어 대응 강화
글로벌 고객을 고려해, 에이전트가 고객의 입력 언어를 감지하고 해당 언어로 자연스럽게 응답하도록 지침을 강화했습니다. 아래는 관련 Instructions의 일부입니다.
위의 개선 작업을 통해 Instructions v2는 최종 토큰 수를 약 1,800까지 줄이는 데 성공했습니다. 이는 v1 대비 약 66% 감소한 수치로, 비용 절감 효과가 뚜렷했습니다. 또한, 템플릿화와 단계별 절차 정의로 프롬프트의 구조가 간결해지면서 유지보수성이 크게 향상되었습니다. 새로운 기능 추가나 예외 케이스 반영 시에도 기존 지침을 수정하는 데 드는 시간이 줄어들었습니다. 무엇보다, 응답 품질은 v1과 동등하거나 더 안정적으로 유지되었습니다.
실서비스 적용 과정
Session 관리
Amazon Bedrock 에이전트는 고객과의 대화를 세션 단위로 관리하며, 각 세션은 고유한 sessionId로 구분됩니다. 세션은 대화의 맥락을 유지하기 위해 일정 시간 동안 지속되며, 고객 응답이 없을 경우 자동으로 종료되는 idle session timeout이 설정되어 있습니다. 이러한 특성 때문에, 세션 종료 시점을 인지하고 고객에게 상담 종료를 안내하는 로직이 필요했습니다. 이를 위해, 세션을 생성하고 실시간으로 세션 상태를 추적할 수 있는 아키텍처를 구성하게 되었습니다.
Figure 3. Session 관리 워크플로우
세션 관리는 다음과 같은 흐름으로 이루어집니다.
고객이 메시지를 보내면 해당 메시지는 Amazon MSK를 통해 소켓 서버로 전달됩니다. 소켓 서버는 메시지를 Amazon DynamoDB에 저장한 뒤, 기존 세션의 TTL을 갱신하거나 새로운 세션을 생성합니다. 생성된 sessionId는 Amazon ElastiCache Redis에 저장되어 유효 시간이 관리됩니다.
Redis에 설정된 TTL이 만료되면 세션 만료 이벤트가 감지되고, 소켓 서버는 고객에게 상담 종료 메시지를 전송합니다. 이를 통해 사용자가 대화가 종료되었음을 명확히 인지할 수 있도록 하고, 이후 재접속 시 새로운 세션으로 대화를 시작할 수 있도록 처리하고 있습니다.
고객 메세지 묶음 처리
초기에는 고객이 전송한 메시지 한 건당 Amazon Bedrock 에이전트를 한 번씩 호출하는 구조로 동작했습니다. 하지만 고객이 한 문장을 여러 번에 나누어 보내는 경우, 예를 들어 “안녕하세요!”와 “예약 날짜를 변경하고 싶어요”를 따로 전송하면, 에이전트가 각각의 메시지에 대해 별도로 응답을 생성하는 문제가 있었습니다. 이로 인해 대화 흐름이 어색해지거나, 같은 내용을 반복 안내하는 등 사용자 경험에 혼선을 주는 경우가 발생했습니다.
이를 해결하기 위해, 일정 시간 동안 들어온 메시지를 하나로 묶어 처리하는 메시지 묶음 처리 방식을 도입했습니다. 핵심 아이디어는 고객이 마지막 메시지를 보낸 후 일정 시간 동안 추가 메시지가 없는 경우, 그 시점까지 받은 메시지를 하나로 합쳐 에이전트를 한 번만 호출하는 방식입니다.
Figure 4. 고객 메세지 묶음 처리 워크플로우
고객 메시지는 Amazon ElastiCache Redis에 저장되며, Redis는 큐 역할을 하며 일정 시간 동안 메시지를 수집합니다. 메시지 수신 후 5초 동안 추가 입력이 없으면, Redis에 저장된 메시지들을 하나의 문자열로 병합한 뒤 Amazon Bedrock 에이전트를 한 번만 호출합니다. 에이전트는 병합된 입력을 기반으로 응답을 생성하고, 해당 응답은 소켓 서버를 통해 고객에게 전달됩니다.
이 방식을 통해 대화 맥락이 자연스럽게 유지되고, 에이전트 호출 횟수를 줄여 비용 효율성도 함께 개선할 수 있었습니다.
고객 메세지 카테고리 분류
실서비스에 생성형 AI를 도입할 때 가장 중요한 고려사항 중 하나는 비용 효율성입니다.
Amazon Bedrock 에이전트는 호출 시 사용하는 토큰 수에 따라 과금되기 때문에, 의미 없는 요청이나 에이전트가 처리할 수 없는 메시지까지 호출되면 불필요한 비용이 발생할 수 있습니다.
이를 방지하기 위해, Bedrock 에이전트의 Pre-processing prompt를 사용해 고객 메시지를 사전에 분류하고, 유효하지 않은 입력은 에이전트 호출을 차단하는 구조를 도입했습니다.
Figure 5. Bedrock agent runtime process
Pre-processing prompt와 isValid의 역할
Pre-processing prompt는 Amazon Bedrock 에이전트 런타임 프로세스에 따라, 에이전트가 메시지를 본격적으로 처리하기 전에 실행되는 전처리 단계입니다.
이 단계에서 Claude 모델은 입력 메시지의 의도를 분석하고, 해당 메시지가 유효한 요청인지 판단하여 isValid라는 Boolean 값으로 결과를 반환합니다. isValid: true인 경우에만 본처리가 진행되고, 그렇지 않으면 호출이 차단됩니다.
저희는 Pre-processing prompt를 통해 고객 메시지를 5가지 카테고리로 분류하도록 구성했습니다.
preProcessingTrace 예시
아래는 Pre-processing 단계의 trace 예시입니다.
{
"preProcessingTrace": {
"modelInvocationOutput": {
"parsedResponse": {
"isValid": false,
"rationale": "\\nThe user's input \\\"재미있는 얘기해주세요\\\" (which translates to \\\"Tell me an interesting story\\\" in English) is not directly related to beauty shop topics or reservations. It's a general request for entertainment ... Given these considerations, this input would best fit into Category B.\\n"
},
"rawResponse": {
"content": "...\"text\":\"<thinking>\\nThe user's input \\\"재미있는 얘기해주세요\\\" (which translates to \\\"Tell me an interesting story\\\" in English) is not directly related to beauty shop topics or reservations. It's a general request for entertainment ... Given these considerations, this input would best fit into Category B.\\n</thinking>\\n\\n<category>B</category>\"..."
}
}
}
}입력된 메시지 “재미있는 얘기 해주세요”는 뷰티샵 운영과 무관한 내용으로 분류되어 isValid: false로 처리되고, 에이전트 호출이 차단됩니다.
isValid 판단 오류와 서버 단 보완 로직
다만 테스트 과정에서, 메시지가 명확하게 비정상 입력으로 분류되었음에도 불구하고 isValid: true로 반환되어 에이전트가 호출되는 사례가 종종 발견되었습니다.
이 문제를 해결하기 위해, 서버 측에서 rawResponse의 <category> 태그를 직접 파싱해 유효 여부를 판단하는 로직을 추가했습니다.
또한, 동일 세션에서 처리 불가능한 입력이 반복될 경우에는 에이전트 호출을 일정 횟수 이후 차단하고, 사용자에게 적절한 안내 메시지를 전달하도록 설정했습니다.
서버 측 유효성 판단 코드
아래는 해당 기능을 서버에서 구현한 코드 일부입니다.
private async validateUserInput(preProcessingTrace: any, sessionId: string): Promise<void> {
const modelOutput = preProcessingTrace.modelInvocationOutput;
const isValid = modelOutput?.parsedResponse?.isValid;
const rawResponse = modelOutput?.rawResponse;
const isValidCategory = this.isValidCategoryFromRawResponse(rawResponse);
if (isValid === false || isValidCategory === false) {
const invalidCount = await this.chatSessionService.setOrIncreaseInvalidCount(sessionId);
if (invalidCount >= this.MAX_INVALID_USER_INPUT) {
throw new Error('AGENT_BLOCKED_RESPONSE');
}
throw new Error('AGENT_INVALID_USER_INPUT');
}
}응답에서 카테고리를 추출하고 유효성을 판단하는 로직은 다음과 같이 구성되어 있습니다.
private isValidCategoryFromRawResponse(rawResponse: any): boolean {
const category = this.extractCategoryFromResponse(rawResponse);
return this.isValidCategory(category);
}
private extractCategoryFromResponse(rawResponse: any): string | undefined {
try {
if (!rawResponse?.content) {
return undefined;
}
const contentString: string = rawResponse.content;
let content;
try {
content = JSON.parse(contentString);
} catch {
return undefined;
}
if (!content?.content?.[0]?.text) {
return undefined;
}
const text: string = content.content[0].text;
const categoryMatch = text.match(/<category>(.*?)<\/category>/i);
if (!categoryMatch) {
return undefined;
}
return categoryMatch[1];
} catch (error) {
return undefined;
}
}
private isValidCategory(category: string | undefined): boolean {
if (!category) {
return false;
}
const validCategory = [...];
return validCategory.includes(category);
}이 구조를 통해 에이전트 호출의 정확도를 높이고, 의미 없는 요청에 대한 호출 비용을 효과적으로 차단할 수 있었습니다. 또한, 반복 입력이나 실수로 인한 불필요한 호출도 줄이면서, 전체적인 시스템 안정성과 응답 품질 역시 개선되었습니다.
데모 영상
도입 효과
Amazon Bedrock과 Claude 3.5 모델 기반의 생성형 AI 챗봇을 미음에 도입하면서 뷰티샵의 고객 응대 효율이 향상되었습니다. 챗봇을 사용한 샵의 평균 응답 시간이 기존 38분에서 1분 이내로 감소하며 평균 고객 이탈률이 30% 줄었고, 예약 및 샵 정보 문의에 대한 평균 챗봇 처리율은 90%를 달성해 디자이너의 반복 상담 부담을 줄였습니다.
향후 기능 확장 방향
현재 챗봇은 예약 등록, 변경, 취소, 샵 정보 안내를 중심으로 운영되고 있습니다. 향후에는 시술 추천, 복합 질문 대응, 고객 성향 기반 응대와 같은 더 복잡한 시나리오로 기능을 확장할 계획입니다. 또한, 예약금 처리나 샵별 예약 정책 적용과 같이 아직 수동 확인이 필요한 부분을 완전 자동화하는 것을 목표로 하고 있습니다. 이를 위해 샵별 정책에 따라 예약금 유무, 환불 기준, 시술 조건 등을 커스터마이징할 수 있는 기능을 추가할 예정입니다.
더불어, 현재 예약 및 샵 정보 문의 중심의 챗봇 구조에서 한 단계 나아가 고객이 디자이너에게 요청하는 시술 디자인 질문까지 처리할 수 있도록 기능 범위를 확대할 계획입니다. 이를 위해 샵별로 등록된 디자인 이미지와 시술 설명 데이터를 활용해 더 풍부한 상담을 제공할 예정입니다. 사용자 피드백을 반영해 응답의 자연스러움과 다양성을 지속적으로 개선하고, 프롬프트 구성과 Action Group 스키마의 확장성을 고도화하여 다양한 예약 조건과 시나리오에 유연하게 대응할 수 있도록 발전시켜 나갈 것입니다.