- 상품이 많은 온라인 매장일수록 고객은 오히려 결정을 어려워합니다. 몇 개로 추려 주는 사람이 없기 때문입니다.
- 좋은 판매 어시스턴트는 전체 상품을 늘어놓는 대신 예산, 용도, 제약 조건을 묻고, 두세 개를 골라 이유와 함께 제안합니다.
- 그러려면 먼저 상품 데이터가 정확하고 빠짐없어야 합니다. 시스템의 가격이나 재고가 실제와 다르면 추천도 틀립니다.
기존 웹사이트와 앱은 어디에서 멈춰 있을까
실제 매장에 고객이 들어오면 유능한 직원은 몇 가지만 묻고 두세 개를 골라 보여 줍니다. 그런데 웹사이트에서는 상품 100개를 검색창과 함께 고객 앞에 통째로 던져 놓습니다. 상품이 많을수록 고객은 결정을 내리지 못하고 페이지를 닫습니다.
카탈로그가 커진다고 고객의 결정이 쉬워지지는 않습니다. 기존 필터는 고객이 상품 용어를 알고 직접 비교하기를 요구하고, 가격, 재고, 리뷰, 조건 정보는 여기저기 흩어져 있습니다.
기존 검색과 필터는 구매자가 상품명을 알고 사양을 이해할 때 잘 작동합니다. 하지만 많은 고객은 원하는 결과에서 출발합니다. 작은 가게를 열고 싶다거나, 지금 쓰는 시스템과 함께 써야 한다거나, 공간이 좁다는 식입니다. 그래서 필터를 잘못 고르고, 엉뚱한 기준으로 비교하고, 보기에는 좋지만 실제 조건에는 맞지 않는 상품을 사기도 합니다.
새로운 세대의 AI 커머스 앱은 상품을 검색하기 전에 고객이 한 말을 요구 사항(Requirement)과 제약 조건(Constraint)으로 바꿔야 합니다. 시스템이 할 일은 쓸 수 없는 선택지를 걸러 내고, 무엇을 얻고 무엇을 포기하는지(Trade-off) 설명하고, 결정의 맥락을 다른 페이지와 기기로 이어 가거나 영업 직원에게 넘기는 것입니다. 마진이 가장 높은 상품만 밀어 주는 시스템은 이 일을 하지 못합니다.
| 기존 방식 | 새로운 AI 제품 방식 |
|---|---|
| 클릭 이력 기반 추천, 인기 상품 노출, FAQ에 답하는 채팅 | 평소 말로 요구를 받아 후보 목록(Shortlist)을 만들고, 트레이드오프를 설명하고, 재고와 배송 가능 지역을 확인한 뒤, 고객이 확정할 장바구니를 준비하는 퍼스널 쇼퍼(Personal Shopper) |
책임 있게 추천하는 시스템은 AI와 카탈로그 규칙(Catalog Rule), 실시간 데이터를 함께 씁니다. AI는 사람이 하는 말을 이해하도록 돕고, 제약 조건 엔진(Constraint Engine)은 쓸 수 없는 선택지를 걸러 내며, 장바구니에 담기 전에 API가 가격, 재고, 조건을 한 번 더 확인합니다.
기업이 쓸 수 있는 새로운 기능
그래서 좋은 상품 선택 어시스턴트는 더 똑똑한 검색창보다 사람에 가깝습니다. 어디에 쓸 것인지, 예산은 얼마인지, 어떤 제약이 있는지 묻고, 몇 개로 추린 다음 왜 그것을 골랐는지 알려 줍니다.
프로젝트의 모습
퍼스널 쇼퍼는 상품 코드(SKU)보다 고객이 풀려는 문제에서 출발하는 구매 경험입니다. 사용자는 대화를 나누거나, 공간 사진을 올리거나, 예산을 고른 뒤 비교 화면에서 후보 목록을 봅니다. 추천 뒤에 논리를 숨기지 말고, 고객이 제약 조건을 바꾸면 선택지가 왜 달라졌는지 바로 볼 수 있게 해야 합니다.
주요 기능
기능으로는 안내형 질문, 호환성 확인, 묶음 상품 구성, 대체품 찾기, 비교와 설명이 있을 수 있고, 재고, 가격, 프로모션, 배송, 반품 정책도 현재 데이터로 알려 줍니다. 상품이 품절이면 대체품을 제안하면서 어떤 사양이 같고 무엇을 포기해야 하는지 함께 알려야 합니다.
기술과 데이터
모델보다 중요한 기반은 상품 코드, 속성(Attribute), 측정 단위, 상품 간 관계를 일관되게 관리하는 상품 정보 관리(Product Information Management)입니다. 그 위에서 하이브리드 검색, 제약 조건 엔진, 랭킹 모델을 함께 쓰고, 재고, 가격, 프로모션, 장바구니를 API로 연결합니다. 시스템이 기억해야 할 선호 정보는 고객의 동의를 받아 저장합니다.
비즈니스 효과
고객은 상품을 찾는 데 시간을 덜 쓰고, 추천 이유가 보이니 더 확신을 갖고 삽니다. 기업은 잘못된 유형의 주문과 반복 문의가 줄고, 뛰어난 영업 직원의 지식을 언제든 고객에게 제공할 수 있습니다. 고객이 말한 제약 조건은 기존 검색 키워드로는 보이지 않던 상품 공백과 수요도 드러냅니다.
- 정형 데이터로 비교하고 사양을 지어내지 않기
- 선호 정보는 동의를 받아 기억하고, 고객이 고칠 수 있게 하기
- 비싼 상품만 밀지 말고 예산과 용도에 맞춰 묶음 구성하기
- 구매 후에도 챙기기: 사용 설명서, 클레임, 맞는 모델로 재구매
가상 사례
실제로 쓰이는 모습
한 사무용품 매장은 고객이 인원수, 공간, 예산, 구매 정책을 입력하게 합니다. 에이전트는 세 가지 구성안을 이유와 함께 제안하고, 재고를 확인해 승인 요청 목록을 만듭니다. 다만 권한이 있는 사람이 확정하기 전에는 결제하지 않습니다.
또 다른 가상 사례로, 한 카페가 전력 용량, 시간당 잔 수, 카운터 공간, 예산이라는 제약 안에서 커피 머신을 골라야 한다고 해 봅시다. 시스템은 결과를 바꾸는 정보만 묻고, 전력이 감당하지 못하는 모델을 제외한 뒤, 그라인더와 필터, 정기 점검 일정을 묶어 구성합니다.
가장 잘 맞는 모델이 품절이어도 시스템은 이유 없이 더 비싼 모델로 넘어가지 않습니다. 새 선택지를 비교해 어떤 사양이 낮아지는지 밝히고, 기다릴지, 대체 모델을 받을지, 직원과 상담할지 고객이 고르게 합니다. 결정에 쓰인 데이터는 모두 다음 단계로 함께 넘어갑니다.
설명 가능한 후보 목록(Explainable Shortlist)
추천한 상품마다 왜 맞는지, 언제 맞지 않는지, 데이터가 어디서 왔는지 답할 수 있어야 합니다.
설명하지 못한다면 시스템은 추측하지 말고 질문을 하나 더 해야 합니다.
범위, 위험, 성과 측정 방법
지표는 전환율(Conversion)과 함께 추천 수락률, 호환성 문제로 인한 반품, 직원이 추천을 고친 횟수, 고객 불만까지 봐야 합니다. 매출은 빨리 올리지만 반품을 늘리고 신뢰를 무너뜨리는 시스템은 실패한 것입니다. 후원이나 마진이 영향을 준 추천은 그 사실을 밝혀야 하고, 호환성 규칙을 건너뛰어서는 안 됩니다.
랭킹은 불완전한 데이터나 판매 목표 때문에 왜곡될 수 있습니다. 고객에게 실제로 도움이 되는 추천은 프로모션과 분리하고, 고객이 선호 정보를 고칠 수 있게 해야 합니다.
개발팀 참고 · 기술 지표
추적할 지표: Shortlist-to-Cart, Return Rate, Assisted Conversion, Margin Guardrail, Recommendation Override
- Discover: 실제 업무를 따라가며 일반 사례와 예외 사례를 모읍니다.
- Assist: AI가 초안을 쓰거나 추천하고, 통제는 사람이 계속 맡습니다.
- Act: 테스트 세트를 통과한 뒤 도구(Tool)를 하나씩 엽니다.
- Scale: 모니터링, 대체 경로(Fallback), 비용, 책임자가 갖춰지면 확대합니다.
추천으로 클릭은 늘었는데 반품, 직원의 추천 수정(Override), 불만도 함께 늘면 확대 속도를 늦춰야 합니다. 어떤 모델이 어느 규칙 때문에 제외됐는지 팀이 아직 설명하지 못할 때도 마찬가지입니다. 랭킹이 상품 데이터의 정확도보다 앞서 나가고 있다는 신호입니다.
BUSINESS & PRODUCT READINESS
AI가 영업 직원 대신 추천하려면 상품 데이터는 얼마나 준비되어 있어야 할까
개발팀 참고 · 기술 세부 사항
Personal Shopper가 신뢰를 얻으려면 모든 상품 데이터가 하나의 구조를 따라야 합니다. 이름, 모델, 가격, 단위, 재고, Compatibility, 제약 조건마다 ID와 책임자가 있어야 합니다. 웹사이트에는 이렇게, 마켓플레이스에는 저렇게 적혀 있고 PDF에는 아직 옛 가격이 남아 있다면 Agent는 서로 모순된 데이터 속에서 고르게 됩니다. 그래서 모델을 조정하기 전에 Product Data Readiness부터 갖춰야 합니다.
개발팀 참고 · 기술 세부 사항
다른 하나는 시스템의 인센티브입니다. 목표를 Conversion 하나로만 잡으면 시스템은 비싼 상품을 밀거나 단점을 숨길 수 있습니다. Return Rate, Complaint, Recommendation Override를 Guardrail로 추가하고, 일반 추천은 Promotion과 분리하십시오. 고객이 추천 이유를 보고, 비교하고, Preference를 바꿀 수 있어야 합니다.
먼저 상품 카테고리 하나의 속성 사전(Attribute Dictionary)을 만들어 단위, 의미, 허용 값, 책임자를 정하십시오. 예를 들어 "고강도 작업 가능" 같은 표현은 확인할 수 있는 조건으로 바꿔야 합니다. 데이터가 불완전한 상품은 AI가 추측으로 사양을 채우게 두지 말고 따로 표시해 두어야 합니다.
로직은 하드 제약(Hard Constraint)과 선호(Preference)로 분명히 나눠야 합니다. 호환성, 안전, 규제는 AI가 절대 어겨서는 안 되는 규칙이고, 색상, 스타일, 선호 순서는 모델이 랭킹을 돕게 해도 됩니다. 이 두 층을 나눠 두어야 팀이 추천을 설명하고 실제로 테스트할 수 있습니다.
시범 운영을 시작할 만큼 데이터가 갖춰진 SKU는 무엇입니까?
호환성 규칙은 누가 관리합니까?
프로모션은 랭킹에 어떤 영향을 줍니까?
잘못된 추천 하나의 비용은 얼마입니까?
영업 직원의 노하우를 더 많은 고객에게 닿는 상품 선택 경험으로 바꿉니다
DNA Maker는 상품, 머천다이징, 영업, 서비스 팀이 가장 뛰어난 직원들의 상품 선택 방식을 모아 제품 결정 지도(Product Decision Map)로 정리하도록 돕습니다. 저희는 각 사양이 누구에게 중요한지, 어떤 선택지끼리 함께 쓸 수 없는지, 어떤 경우에 고객에게 경고해야 하는지 묻습니다. AI가 상품의 논리 없이 판매 문구만 흉내 내지 않게 하기 위해서입니다.
그다음 프로덕트 디자인팀이 요구 사항을 묻는 질문, 후보 목록, 비교, 묶음 구성, 추천 이유 설명(Explain-why)을 경험으로 만들어 고객이 직접 써 보게 합니다. 저희는 질문이 충분히 짧은지, 고객이 제약 조건을 고칠 수 있는지, 설명이 실제로 결정을 돕는지 아니면 글만 늘리는지를 측정합니다.
DNA Maker는 요구 사항 요약, 후보 목록, 나란히 비교, 묶음 구성부터 장바구니와 인계까지, 추천의 근거가 화면에 드러나도록 설계합니다. 상품 데이터, 규칙, 콘텐츠를 프롬프트와 분리하는 아키텍처를 잡아 두므로, 고객사 팀은 대화 시스템을 뜯어고치지 않고도 속성이나 조건을 바꿀 수 있습니다.
시범 운영은 섀도 모드(Shadow Mode)로 시작할 수 있습니다. 시스템이 만든 후보 목록을 고객에게 보여 주지 않고 직원의 선택과 비교해 본 다음, 작은 상품 카테고리 하나에서 고객에게 엽니다. 저희는 실제 질문으로 평가 사례(Evaluation Case)를 만들고 호환성, 추천 이유, 반품, 결정 시간을 측정한 뒤, 더 복잡한 카테고리로 넓힐지 결정하도록 돕습니다.
엔지니어링 측면에서는 커머스 웹/앱, 상품 정보 계층(Product Information Layer), AI 퍼스널 쇼퍼, 재고/가격 API, 장바구니/승인, 구매 후 어시스턴트를 개발할 수 있고, 추천마다 어떤 데이터를 썼는지 로그로 남깁니다. 관리자는 규칙을 바꾸고 위험한 추천을 검토할 수 있습니다.
상품 옵션이 많아 직원이 모델을 권하기 전에 고객에게 여러 가지를 물어야 한다면, 카테고리 하나로 시작해 보십시오. 저희가 데이터를 평가하고 후보 목록 프로토타입을 만들어, 결제(Checkout)와 연결하기 전에 실제 대화로 시험해 봅니다.
SOFTWARE ENGINEERING GLOSSARY
소프트웨어 엔지니어링 용어집
상품 데이터와 랭킹부터 승인까지 다루는 용어입니다. 시스템이 제약 조건을 어디서 알게 되는지, 추천을 어떻게 설명하는지, 카탈로그 데이터가 불완전할 때 누가 책임지는지 물을 때 쓰십시오.
| 용어 | 의미 | 쉬운 예시 | 개발팀에 물어봐야 할 질문 |
|---|---|---|---|
| Product Feed | 시스템이 쓰도록 공급하는 상품 데이터. 좋은 피드에는 코드, 속성, 단위, 가격, 재고가 들어 있고 업데이트 주기가 일정해서 모든 채널이 같은 데이터를 참조합니다. | 가격, 재고, 사양, 상품 코드 | 데이터를 최신 상태로 유지하는 사람은 누구입니까? |
| Recommendation | 상황에 맞게 선택지의 순서를 매기는 일. 쓸 수 없는 선택지를 걸러 내는 규칙과 순서를 정한 이유가 있어야 하며, 말이 비슷하다는 것만으로 추천해서는 안 됩니다. | 사용자 수와 예산에 맞춰 기기 고르기 | 이 기준은 고객에게 도움이 됩니까, 매출에 도움이 됩니까? |
| Preference | 사용자가 좋아하는 것이나 피하고 싶은 조건. 상황에 따라 바뀌므로 고정 규칙처럼 다뤄서는 안 되고, 시스템은 사용자가 기억된 내용을 확인하고 고치고 지울 수 있게 해야 합니다. | 영구 설치가 필요한 상품은 제외 | 고객이 자신의 선호 정보를 보고 삭제할 수 있습니까? |
| Structured Output | 정해진 데이터 형식으로 나오는 AI 결과. 형식이 고정되어 있으면 프로그램이 빠진 항목을 검사하고 데이터를 다음 단계로 넘길 수 있어, 자유로운 문장에서 사실을 뽑아낼 때의 위험이 줄어듭니다. | SKU 목록과 추천 이유를 별도 필드로 반환 | 데이터가 불완전하면 시스템은 무엇을 합니까? |
| Approval Flow | 거래를 실행하기 전에 승인을 받는 경로. 금액, 위험도, 예외 여부에 따라 승인자를 정하고, 결정 이유와 시각을 기록해 나중에 검토할 수 있어야 합니다. | 팀장이 회사 장바구니를 확정 | 어느 금액부터 누구의 승인이 필요합니까? |
더 읽을거리(원문 자료): https://ai.google.dev/gemini-api/docs/function-calling