AWS 기술 블로그
롯데백화점의 생성형 AI 기반 파트너 제안 채널 ‘AI 비즈센터’ 구축기

AI 비즈센터 키 비주얼
롯데백화점은 수천 개의 입점 브랜드 및 파트너사와 협력하며 입점, 계약, 행사 기획, 마케팅 제휴 등 다양한 비즈니스 프로세스를 운영하고 있습니다. 고객용 앱에서 AI 컨시어지 ‘더스틴‘을 운영하는 등 생성형 AI를 고객 접점에 적용해 왔으며, 이번에는 그 활용 범위를 파트너사의 입점 및 협업 지원 영역으로 확장했습니다.
롯데백화점은 파트너사의 정보 탐색과 제안 준비, 제안서 작성, 담당 부서 연결, 접수 이후 관리를 하나의 흐름으로 지원하는 파트너사 전용 AI 에이전트 서비스 ‘AI 비즈센터’를 구축했습니다. AI 비즈센터는 Amazon Bedrock(완전관리형 생성형 AI 서비스)을 기반으로 AI 챗봇, 제안서 작성 지원, 담당 부서 자동 매칭, 파일과 링크 기반 정보 분석 기능을 제공합니다.
서비스 오픈 후 2개월간 제안서 접수 건수는 전년 동기간 대비 160% 증가했으며, 같은 기간 제안서를 접수한 고객 중 약 25%가 AI 제안서 작성 기능을 활용했습니다. AI 챗봇을 실제 입점과 제휴 접수 과정에 연결하면서 파트너사가 제안에 참여하는 방식도 넓어졌습니다.
이 글에서는 AI 비즈센터의 도입 배경과 서비스 구성, 주요 기술 구현 방식, 운영 과정에서 확인한 기술 과제와 해결 방법, 도입 이후의 비즈니스 성과를 소개합니다.
도입 배경: 파트너사와 내부 담당자의 업무를 함께 개선하기
기존에는 입점 및 제휴 업무에 필요한 정보가 여러 시스템과 문서에 분산되어 있었습니다. 백화점의 조직 구조나 입점 절차를 알기 어려운 신생 브랜드와 소규모 파트너사는 어떤 정보를 준비하고 어느 부서에 제안해야 하는지 파악하는 데 어려움을 겪었습니다. 이 과정에서 제안 준비에 부담을 느끼거나 협업 기회를 놓치기도 했습니다.
내부 담당자도 유사한 문의에 반복적으로 답변하고, 접수된 제안 내용을 확인해 적합한 부서를 찾아 전달해야 했습니다. 제안서마다 포함된 정보와 형식이 달라 추가 확인이 필요한 경우도 있었습니다. 이런 작업에 시간을 쓰다 보니 MD와 관련 담당자가 신규 브랜드 발굴, 상품 큐레이션, 제안 검토 같은 핵심 업무에 집중하기 어려웠습니다.
롯데백화점은 다음 네 가지 문제를 해결하기 위해 AI 비즈센터를 기획했습니다.
- 정보 접근성 개선: 여러 시스템과 문서에 분산된 입점 기준, 행사 가이드, 수수료 정책, 계약 관련 정보를 하나의 대화형 채널에서 탐색할 수 있도록 합니다.
- 제안서 작성 부담 완화: 브랜드명, 타깃 고객, 제품 특징 등 주요 정보를 대화로 수집하고 내부 검토 양식에 맞게 구조화합니다.
- 담당 부서 연결 자동화: 제안 내용과 유형을 분석해 적합한 내부 담당 부서 후보를 찾고 수작업 확인과 전달을 줄입니다.
- 운영 과정의 일관성 확보: 표준화된 제안 양식과 처리 상태 관리 기능을 통해 접수부터 검토까지의 흐름을 일관되게 관리합니다.
목표는 기존 문의 채널을 온라인으로 옮기는 것보다 한 걸음 나아가, 제안 준비부터 담당 부서 연결과 접수 후 관리까지 이어지는 전 과정을 생성형 AI로 지원하는 것이었습니다.
AI 비즈센터 솔루션 개요
서비스 화면: 대화에서 제안서 제출까지 하나의 흐름으로 연결
AI 비즈센터는 웹페이지 우측의 플로팅 챗봇에서 주요 기능을 시작할 수 있도록 구성했습니다. 다음 그림은 사용자가 처음 만나는 챗봇 화면과 주요 업무 진입 방식을 보여줍니다.

그림 1. AI 비즈센터 초기 화면
초기 화면은 ‘입점 제안’, ‘마케팅 제휴 제안’, ‘영업점 제휴 제안’, ‘Q&A’ 등 자주 사용하는 기능을 카드형 버튼으로 제공합니다. 사용자는 메뉴를 여러 단계 탐색하지 않고 필요한 업무로 바로 진입할 수 있으며, 자연어로 질문해 관련 정보를 확인하고 다음 업무를 이어갈 수 있습니다. 입력창 아래에는 AI 답변에 오류가 포함될 수 있다는 안내를 함께 노출해 사용자가 결과를 확인하도록 했습니다.
입점 제안서를 작성할 때는 상황에 따라 직접 입력하거나 파일 또는 링크를 활용할 수 있습니다. 다음 그림은 세 가지 정보 입력 방식을 보여줍니다.

그림 2. 입점 제안서 작성 방식 세 가지
- 직접 작성하기: AI의 질문에 답하면서 브랜드와 제안 정보를 입력합니다.
- 자료 올리기: 브랜드 소개서나 기존 제안서 파일을 업로드하면 AI가 PDF와 이미지의 주요 내용을 분석합니다.
- 링크 입력하기: 기업 공식 홈페이지, SNS, 네이버맵 등의 URL을 입력해 제안서 작성에 활용합니다.
그림 3은 대화에서 추출한 정보가 제안서 양식과 담당 부서 추천 결과에 반영되는 화면입니다.

그림 3. 대화 내용이 제안서 양식에 반영되는 화면
AI는 브랜드명, 타깃 고객, 브랜드 특장점, 희망 점포 등 제안서 작성에 필요한 정보를 자연어 대화에서 추출합니다. 제품과 브랜드 특성을 바탕으로 담당 부서와 세부 상품 카테고리도 추천합니다. 파트너사는 추천 결과와 입력 내용을 최종 확인한 뒤 제안서를 제출하며, 접수 이후 진행 상태와 피드백을 모바일에서도 확인할 수 있습니다.
시스템 아키텍처: 의도 분류부터 부서 매칭까지
그림 4는 사용자 요청이 AI 비즈센터에 전달된 뒤 질문 유형에 따라 처리되고, 파일 분석과 담당 부서 매칭을 거쳐 제안서에 반영되는 전체 흐름입니다.

그림 4. AI 비즈센터 아키텍처
서비스는 서울 리전(ap-northeast-2)에 구성했으며, 요청은 다음 순서로 처리됩니다.
- 웹과 모바일 앱에서 발생한 요청이 Amazon CloudFront와 Application Load Balancer를 거쳐 Amazon Elastic Container Service(Amazon ECS)에서 실행되는 애플리케이션에 전달됩니다. 이 경로의 웹 요청은 AWS WAF가 검사합니다.
- 의도 분류기(Intent Classifier)가 발화를 분석해 입점 제안, 마케팅 제휴, 영업점 제휴, 일반 Q&A 등 처리 영역을 결정합니다.
- 일반 문의는 검색 증강 생성(Retrieval-Augmented Generation, RAG) 기반 Q&A로 전달하고, 업무형 대화는 프로세스 제어 로직에서 필요한 정보를 단계적으로 수집합니다. 대화 이력은 Amazon DynamoDB에 저장해 여러 턴에 걸쳐 제안서 작성 상태를 유지합니다.
- 사용자가 파일을 첨부하면 클라이언트가 Amazon Simple Storage Service(Amazon S3)에 직접 업로드하고, 애플리케이션은 Amazon Bedrock을 통해 Claude Haiku 4.5 모델을 사용해 파일을 분석합니다. 링크를 입력한 경우에는 Playwright 기반 웹 크롤러가 해당 페이지의 내용을 수집해 같은 분석 경로로 전달합니다.
- 제안서에 필요한 정보가 확보되면 Amazon OpenSearch Service의 키워드 검색과 벡터 검색, LLM 기반 정규화 및 검증을 결합해 담당 부서 후보를 찾습니다.
검색 대상 데이터는 별도의 배치 경로로 관리합니다. 담당자가 조직도와 Q&A 파일을 Amazon S3에 업로드하면 Amazon Simple Notification Service(Amazon SNS)와 Amazon Simple Queue Service(Amazon SQS)를 거쳐 AWS Lambda 함수가 실행되고, 이 함수가 문서를 임베딩해 OpenSearch 인덱스를 갱신합니다. 이 배치 경로를 통해 조직 개편이나 정책 변경이 있을 때 검색 대상 데이터와 결과가 함께 갱신되도록 했습니다.
기술 스택과 선택 이유
| 구분 | 기술 | 선택 이유 |
|---|---|---|
| 생성형 AI | Amazon Bedrock(Anthropic Claude Haiku 4.5) | 의도 분류, 대화 기반 정보 추출, 멀티모달 문서 분석, 검색어 정규화에 파운데이션 모델을 활용합니다. |
| 임베딩 | Amazon Bedrock(Amazon Titan Text Embeddings V2) | 브랜드 특장점과 조직도 문서를 벡터로 변환해 의미 기반 검색에 사용합니다. |
| 입출력 안전성 | Amazon Bedrock Guardrails | 사용자 입력과 AI 응답에 유해 콘텐츠, 프롬프트 공격, 민감정보 필터를 적용합니다. |
| 검색 | Amazon OpenSearch Service | BM25 키워드 검색과 k-NN 벡터 검색을 결합해 정확한 용어와 의미적 유사성을 함께 평가합니다. |
| 파일 저장 | Amazon S3 | Presigned POST를 이용해 파일이 애플리케이션 서버를 거치지 않고 직접 업로드되도록 구성합니다. |
| 대화 이력 | Amazon DynamoDB | 챗 히스토리를 저장해 여러 턴에 걸친 제안서 작성 상태를 유지합니다. |
| 색인 파이프라인 | Amazon SNS, Amazon SQS, AWS Lambda | 조직도와 Q&A 파일 업로드를 이벤트로 받아 OpenSearch 인덱스를 비동기로 갱신합니다. |
| 링크 수집 | Playwright | 사용자가 입력한 기업 홈페이지와 SNS 페이지의 내용을 수집합니다. |
| 자격 정보 관리 | AWS Secrets Manager | 외부 연동에 사용하는 인증키를 코드와 분리해 보관합니다. |
| 애플리케이션 실행 | Amazon Elastic Container Service(Amazon ECS) | 챗봇 애플리케이션과 제안 처리 로직을 컨테이너로 실행합니다. |
| 콘텐츠 전송 | Amazon CloudFront | 웹 콘텐츠를 사용자에게 전달하고 애플리케이션 오리진과 연결합니다. |
| 요청 분산 | Application Load Balancer(ALB) | 애플리케이션 요청을 ECS 서비스로 전달합니다. |
| 웹 요청 보호 | AWS WAF | SQL 명령어 삽입과 크로스 사이트 스크립팅 등 일반적인 웹 공격 패턴을 탐지하고 차단합니다. |
의도 분류, 정보 추출, 문서 분석, 검색어 정규화에는 모두 Anthropic Claude Haiku 4.5를 사용했습니다.
사용자 입력과 AI 생성 응답에는 Amazon Bedrock Guardrails를 적용했습니다. 입력과 출력에서 유해 콘텐츠와 욕설을 필터링하고, 사용자 입력의 프롬프트 공격을 차단합니다. 이메일, 전화번호, 카드번호, 주민등록번호, 계좌번호 같은 민감정보는 정규식 기반으로 입력과 출력에서 차단합니다. 정책에 따라 차단되면 사전에 정의한 안내 메시지를 반환합니다. 이를 통해 부적절하거나 위법한 콘텐츠, 보안 정책 우회 시도, 개인정보 노출 가능성을 줄였습니다.
핵심 구현과 운영 과정에서 확인한 개선 기회
1. 의도(Intent) 기반 라우팅과 대화 상태 격리
사용자가 챗봇에 발화를 입력하면 의도 분류기가 입점 제안, 마케팅 제휴, 영업점 제휴, 일반 Q&A 등 주요 목적을 판단하고 적합한 처리 영역으로 라우팅합니다.
입점 제안서를 작성하는 중에도 사용자는 “특약매입 거래 시 확인해야 할 체크리스트가 뭔가요?”, “입점 절차를 알려주세요”, “공지사항을 확인하고 싶어요”처럼 현재 프로세스와 다른 질문을 할 수 있습니다. AI 비즈센터는 정보 항목(Entity)을 추출하기 전에 현재 발화가 기존 제안서 작성 흐름을 유지하는지, 다른 업무로 이탈했는지를 판단하는 대화 이탈(Digression) 감지 구조를 적용했습니다.
발화 유형에 따라 요청은 다음과 같이 처리하며, 대화 이탈이 감지되어 다른 처리 영역으로 넘어가더라도 기존 입점 제안 프로세스의 상태는 그대로 유지합니다.
- 일반 문의: RAG 기반 Q&A에서 답변합니다.
- 입점 절차 등 정형화된 문의: 사전에 관리하는 정형 답변을 제공합니다.
- 다른 메뉴의 기능 요청: 해당 메뉴로 이동하도록 안내합니다.
- 기존 제안서와 관련된 발화: 진행 중인 프로세스를 계속 수행합니다.
이 구조를 통해 하나의 챗봇에서 여러 업무를 처리하면서도 각 업무의 대화 상태가 서로 영향을 주지 않도록 했습니다.
입점 제안은 정해진 양식을 순서대로 채우는 대신 자연스러운 대화에서 필요한 정보를 추출하도록 구현했습니다. AI는 브랜드명, 타깃 고객, 브랜드 특장점, 희망 점포 등을 동적으로 추출합니다. 이미 정상적으로 확보한 정보는 내부적으로 ALREADY_SET 상태로 마스킹해 LLM에 전달했습니다. 이렇게 하면 과거 대화 문맥 때문에 값이 다시 추출되거나 바뀌는 일을 줄일 수 있습니다.
서비스 계층은 현재까지 수집한 정보와 프로세스 상태를 기준으로 다음 행동을 결정합니다. 필수 정보가 누락되면 추가 질문을 하고, 필요한 정보가 모두 확보되면 담당 부서 검색과 제안서 제출 단계로 이동합니다.
2. 멀티모달 파일 분석: 용량 기준 처리와 Timeout 조정
파트너사는 내용을 직접 입력하는 대신 기존 PDF 제안서나 이미지 형태의 브랜드 자료를 업로드할 수 있습니다. PDF는 페이지 단위로 분리한 뒤 앞쪽 페이지부터 누적 용량이 4.5MB 이하인 페이지까지 처리합니다. 예를 들어 1~2페이지의 합계가 4.5MB 이하라면 2페이지까지 분석하고, 이후 페이지는 분석에 포함하지 않습니다. 이미지는 Converse API 이미지 콘텐츠 블록(ImageBlock)의 최대 허용 크기인 3.75MB를 넘으면 해상도를 줄여 3.75MB 이하로 변환한 뒤 처리합니다. Amazon Bedrock Converse API의 메시지 콘텐츠 제한은 문서당 4.5MB, 이미지당 3.75MB입니다. 추출한 텍스트를 바탕으로 브랜드명, 주요 상품, 타깃 고객, 가격대 등 제안서 작성에 필요한 정보를 추출합니다.
초기 운영에서는 텍스트 밀도가 높은 문서나 복잡한 이미지가 포함된 파일의 분석 시간이 길어지면서 일부 요청에서 HTTP 504 Gateway Timeout이 발생했습니다. CloudFront, ALB, 백엔드 서버의 Timeout 설정을 점검하고 요청 경로의 설정을 120초 수준으로 조정했습니다.
CloudFront 사용자 지정 오리진의 응답 Timeout은 기본 설정 범위에서 1~120초이며, 120초를 넘는 값은 서비스 할당량 증가 요청을 통해 조정할 수 있습니다. 동기 요청의 제한시간을 늘리면 대기 시간과 리소스 점유도 함께 늘어나므로, 처리 시간이 길어질 수 있는 파일은 작업을 먼저 접수한 뒤 상태를 조회하는 비동기 방식이나 진행 결과를 전달하는 스트리밍 방식을 검토할 수 있습니다.
3. 파일 업로드 경로 재설계: WAF 오탐과 S3 직접 업로드
초기에는 클라이언트가 파일 데이터를 백엔드 서버로 전송하고, 서버가 다시 S3에 업로드했습니다. 이 과정에서 AWS WAF의 요청 본문 검사 범위에 포함된 파일 앞부분이나 멀티파트 데이터의 일부 문자열을 SQL 명령어 삽입이나 크로스 사이트 스크립팅 규칙이 공격으로 잘못 탐지하는 사례가 발생했습니다.
WAF가 요청이 애플리케이션에 도달하기 전에 차단하면 애플리케이션이 추가하는 CORS 헤더가 응답에 포함되지 않습니다. 이 때문에 프론트엔드에서는 실제로는 WAF 차단인 상황이 CORS 오류처럼 보였습니다.
롯데백화점은 파일 업로드 경로를 Presigned POST 기반 S3 직접 업로드 방식으로 변경했습니다. 사용자가 업로드를 요청하면 백엔드가 제한된 시간 동안 사용할 수 있는 업로드 정보를 발급하고, 클라이언트는 이를 사용해 파일을 S3에 직접 업로드합니다. 업로드가 완료되면 애플리케이션은 S3 객체 키를 이용해 파일 분석을 시작합니다. S3 버킷에는 웹 클라이언트의 직접 업로드를 허용하는 CORS 정책을 함께 구성했습니다.
이 방식은 파일 데이터가 챗봇 애플리케이션 서버와 해당 경로의 WAF를 통과하지 않도록 해 오탐을 줄이고, 서버의 네트워크 및 메모리 부하도 낮춥니다. 다만 파일이 애플리케이션을 거치지 않게 되면서 업로드 경로의 검증 책임이 발급 시점과 S3 정책으로 이동하므로, 다음 통제를 함께 구성했습니다.
- 객체 키의 서버 측 생성과 퍼블릭 액세스 차단: 클라이언트가 임의의 경로를 지정하지 못하도록 API 서버가 세션 ID와 UUID를 결합해 S3 객체 키를 생성했습니다. S3 버킷에는 퍼블릭 액세스 차단을 적용했습니다.
- 짧은 유효시간: 발급한 업로드 정보의 유효시간을 5분으로 제한해 노출 시 악용 가능한 시간을 줄였습니다.
- POST 정책 조건: Presigned POST 정책의
conditions에Content-Type과 단일 파일 크기 상한(20MB)을 포함했습니다. S3는 이 조건으로 클라이언트가 선언한 형식과 파일 크기를 업로드 단계에서 제한합니다. - 확장자 화이트리스트: 업로드 정보를 발급하는 시점에 애플리케이션이 허용 확장자 목록을 검증하고, 업로드 시점에는 POST 정책의
Content-Type조건으로 클라이언트가 선언한 형식을 제한했습니다. - 자격 증명 만료 고려: 임시 자격 증명으로 서명한 Presigned POST는 정책에 지정한 만료 시각보다 자격 증명이 먼저 만료되면 함께 무효가 됩니다. 따라서 발급 시점에 자격 증명의 남은 유효시간이 업로드 정보의 유효시간 5분보다 충분히 길도록 고려했습니다.
4. 담당 부서 매칭: 다단계 검색과 사람의 최종 판단
초기에는 OpenSearch의 BM25 키워드 검색과 k-NN 벡터 검색만으로 담당 부서를 매칭했습니다. 그러나 데이터베이스에 존재하지 않는 신생 브랜드나 소규모 브랜드가 입력되면 BM25 검색 결과가 충분하지 않았습니다. 사용자가 자유롭게 작성한 브랜드 특장점과 조직도에 색인된 표현이 크게 다른 경우에는 벡터 검색에서도 기대한 유사도가 나오지 않았습니다.
롯데백화점은 단일 검색 결과로 부서를 결정하는 대신 1차 직접 검색, 1.5차 LLM 정규화 및 추론, 2차 교차 검증으로 이어지는 다단계 검색 파이프라인을 구성했습니다. 앞 단계에서 신뢰할 수 있는 결과를 확보하면 이후 단계를 수행하지 않는 단계적 중단 방식을 적용해 불필요한 LLM 호출과 응답 시간을 줄였습니다.
1차: BM25와 k-NN 하이브리드 검색
BM25는 정확한 키워드 일치를 찾고, k-NN 벡터 검색은 브랜드 특장점의 의미적 유사성을 평가합니다. 두 알고리즘은 점수 범위가 다르므로 점수를 단순히 합산하지 않고 알고리즘마다 별도의 고정 임계값을 두었습니다. 각 임계값을 통과한 결과는 임계값 대비 획득 점수의 비율을 비교해 신뢰도를 평가했습니다.
임계값은 담당 부서 매칭 테스트 케이스(TC) 목록을 검증 데이터로 사용해 정했습니다. 고정 임계값을 단계적으로 바꾸면서 같은 TC를 반복 테스트하고, 정답 부서 매칭률과 오매칭 발생 여부를 비교해 매칭률이 가장 높은 값을 선택했습니다. 질의별 최고점 대비 비율과 같은 동적 임계값은 사용하지 않았습니다.
점수를 결합하는 방법으로는 OpenSearch의 하이브리드 검색과 정규화 프로세서를 사용하는 방법도 있습니다. 롯데백화점은 앞서 운영을 시작한 AI 컨시어지 ‘더스틴’에서 이미 검증한 방식을 그대로 적용해 두 서비스의 검색 동작을 일관되게 유지하는 쪽을 선택했습니다.
1.5차: LLM 기반 검색어 정규화와 카테고리 추론
1차 검색에서 충분한 결과를 얻지 못하거나 입력 정보가 부족하면 BrandNormalizer가 동작합니다. BrandNormalizer는 사용자가 입력한 브랜드의 업종과 특성을 분석해 유사 브랜드와 핵심 키워드를 생성하고, 긴 자연어 형태의 특장점을 카테고리, 연령대, 가격대 등 검색에 적합한 형태로 정규화합니다.
또한 입력 정보를 바탕으로 가능성이 높은 상품 카테고리를 미리 추론합니다. 이 값을 OpenSearch 검색의 가중치 조건으로 활용해 유사한 검색 결과 중 해당 카테고리에 속한 부서가 우선 평가되도록 했습니다.
2차: 교차 검증과 Human-in-the-Loop
OpenSearch가 찾은 최상위 부서와 LLM이 미리 추론한 상품 카테고리가 일치하지 않으면 검색 후보와 사용자 문맥을 LLM에 다시 전달해 검증합니다. 여러 단계의 검색과 검증을 거친 뒤에도 신뢰도가 충분하지 않을 때는 부서를 자동으로 확정하지 않고, 가능성이 높은 상품 카테고리 후보를 사용자에게 보여줘 직접 선택하게 하는 사람 개입(Human-in-the-Loop) 구조를 적용했습니다.
이를 통해 자동화 범위를 넓히면서도 신뢰도가 낮은 결과가 잘못된 부서로 전달될 가능성을 줄였습니다. 담당 부서 매칭 테스트 케이스 90건 가운데 담당 부서를 판정할 수 있는 86건을 기준으로, 예상 담당 부서와 실제 매칭 결과가 일치한 비율은 하이브리드 검색만 사용했을 때 22건(25.58%)이었고, 다단계 검색 파이프라인을 적용한 뒤 72건(83.72%)으로 58.14%p 개선되었습니다. 담당 부서를 판정하기 어려운 4건은 정확도 산정에서 제외하고 사용자 선택으로 전환했습니다. 사용자 선택 전환 사례는 별도 로그를 수집하지 않아 추가 집계하지 않았습니다.
도입 성과: 제안 접수 확대와 업무 흐름 표준화
AI 비즈센터 도입 이후 롯데백화점은 파트너사의 제안 접근성을 높이고, 생성형 AI를 실제 입점과 제휴 프로세스에 적용했습니다.
| 구분 | 도입 전 | 도입 후 |
|---|---|---|
| 정보 탐색 | 입점 및 제휴 정보가 여러 시스템과 문서에 분산 | 대화형 채널에서 관련 정보와 업무를 연결 |
| 제안서 작성 | 제안서마다 정보와 형식이 달라 추가 확인 필요 | 대화와 첨부 자료에서 정보를 추출해 내부 검토 양식으로 구조화 |
| 담당 부서 연결 | 담당자가 제안 내용을 확인하고 적합한 부서를 수작업으로 탐색 | 다단계 검색과 검증으로 부서 후보를 추천하고 불확실하면 사용자가 선택 |
| 담당 부서 매칭 정확도(테스트 기준) | 하이브리드 검색 단독 25.58% | 다단계 파이프라인 적용 후 83.72% |
| 제안 접수 건수 | 전년 동기간 기준 | 서비스 오픈 후 2개월간 전년 동기간 대비 160% 증가 |
| AI 작성 기능 활용 | 해당 없음 | 같은 기간 제안 고객 중 약 25%가 AI 제안서 작성 기능 활용 |
파트너사가 제안 과정을 이해하고 접근할 수 있는 통합 채널이 생기면서 신규 브랜드를 비롯한 여러 파트너사와의 접점이 넓어졌고, 이것이 제안 접수 증가로 이어졌습니다. 제안 고객 중 약 25%가 AI 제안서 작성 기능을 활용했다는 수치는 자연어 대화를 바탕으로 제안을 준비하고 제출하는 방식이 실제 업무에 사용되고 있음을 보여줍니다.
내부적으로는 제안 정보가 일정한 형식으로 구조화되고 적합한 담당 조직으로 연결되면서 접수 이후 반복되던 정보 확인과 전달 업무를 줄일 수 있는 구조를 갖췄습니다. MD와 관련 담당자는 그만큼 단순 안내와 전달 대신 신규 브랜드 발굴, 상품 큐레이션, 제안 검토에 시간을 쓸 수 있게 되었습니다.
결론 및 향후 계획
롯데백화점은 AI 비즈센터를 통해 파트너사의 정보 탐색부터 제안서 작성, 담당 부서 연결, 접수 이후 관리까지 이어지는 업무 흐름에 생성형 AI를 적용했습니다. AI를 정보 안내뿐 아니라 실제 입점과 제휴 프로세스에 연결했고, 서비스 오픈 이후 제안 접수가 늘고 AI 제안서 작성 기능이 실제로 쓰이는 것을 보며 업무형 AI 서비스로 운영할 수 있다는 점을 확인했습니다.
서비스를 구축하고 운영하면서 확인한 내용은 다음 세 가지입니다.
- 업무 흐름과 상태의 안정적 관리: 대화형 서비스에서는 의도 분류와 대화 이탈 감지를 결합해, 진행 중인 제안서 작성 상태를 유지하면서도 사용자의 다양한 질문과 요청을 유연하게 처리해야 합니다.
- 자동화와 정확성의 균형: AI의 판단이 불확실한 영역에는 사람이 최종 확인하는 절차를 남겨두어야 합니다. 키워드 검색과 벡터 검색, LLM 기반 정규화와 검증을 단계적으로 적용하고, 신뢰도가 낮으면 사용자가 직접 선택하도록 전환해 정확도를 높일 수 있습니다.
- 운영 환경 통합 설계: AI 기능과 함께 이를 둘러싼 처리 구조와 운영 환경도 설계 대상에 포함해야 합니다. 멀티모달 파일 분석의 처리 시간, WAF 정책, 파일 업로드 경로 등 인프라 요소를 종합적으로 설계해야 안정적인 서비스 운영이 가능합니다.
생성형 AI를 업무에서 꾸준히 쓰이는 서비스로 만들려면 모델 성능과 함께 실제 업무 프로세스, 사용자 흐름, 검색 정확도, 보안과 운영 구조를 같이 설계해야 했습니다.
롯데백화점은 앞으로 축적되는 제안과 이용 데이터를 바탕으로 AI 적용 범위를 확장하고, 파트너사와 내부 담당자가 더 효율적으로 협업할 수 있도록 서비스를 지속적으로 개선해 나갈 계획입니다.
참고 자료
- Amazon Bedrock Converse API 메시지 콘텐츠 제한
- Amazon Bedrock Guardrails
- OpenSearch 하이브리드 검색
- Amazon S3 Presigned POST 정책
- Amazon CloudFront 배포 설정