리테일 AI 코파일럿을 구축하기 전에, '진실의 근원(Source-of-Truth)' 계약서를 작성하세요

리테일 AI 코파일럿은 문장을 쓸 수 없어서 실패하는 경우는 거의 없습니다.

이것은 누군가가 “오늘 이거 가져갈 수 있나요?”, “이 할인이 저에게 적용되나요?”, “뜯어본 후에 반품할 수 있나요?”와 같이 겉보기에는 평범하지만 속임수가 있는 질문을 던질 때 실패합니다. 그리고 그 답변은 서비스 데스크에서 사과해야 했던 경험이 전혀 없는 사람의 자신감으로 도착합니다.

모델(model)은 시스템의 눈에 보이는 부분일 뿐입니다. 어려운 부분은 모델이 어떤 정보를 사용할 수 있게 할지, 누가 그 정보의 소유자인지, 그리고 정보가 불완전할 때 무엇을 해야 하는지를 결정하는 것입니다.

리테일 코파일럿을 구축하기 전에, '진실의 근원(Source-of-Truth)' 계약서를 작성하세요.

40페이지짜리 거버넌스 문서(governance document)가 아닙니다. 파일럿 단계에서는 1페이지면 충분합니다. 이 문서는 엔지니어, 매장 관리자, 고객 서비스 담당자가 도구가 도움이 되는 상황과 직접 인계해야 하는 상황을 모두 명확하게 판단할 수 있을 만큼 충분히 명료해야 합니다.

계약은 모델이 아닌 질문에서 시작한다

발생 빈도가 높아 중요하고, 테스트하기에 충분히 좁은 결정을 하나 고르세요. 예를 들어:

“재고, 가격 또는 정책 조건이 확인되지 않은 경우, 고객을 위해 두 품목을 비교하는 것을 매장 동료에게 도와주세요.”

이는 “제품 자문가(product adviser)를 구축하세요”보다 훨씬 좋습니다. 첫 번째 문장은 경계(boundaries)를 제시합니다. 두 번째 문장은 회사 내의 해결되지 않은 모든 비즈니스 질문들을 서서히 수집할 프로젝트를 제공합니다.

도구가 제공하는 답변 각각에 대해 네 가지 필드를 정의하세요.

재고는 하나의 숫자가 아니다

개발자들은 종종 “코파일럿을 재고에 연결하세요”와 같은 요청을 받습니다. 이는 첫 통합 회의가 열릴 때까지는 정확하게 들립니다.

재고(Inventory)는 창고의 재고일 수도 있고, 진열대의 재고일 수도 있으며, 다른 고객을 위해 예약된 재고일 수도 있고, 주문에 할당된 재고일 수도 있습니다. 또한 반품 검사를 기다리는 재고이거나 40분 전에 마지막으로 업데이트된 수량일 수도 있습니다. Shopify는 온 핸드(on hand), 사용 가능(available), 약정됨(committed), 예약됨(reserved)을 포함하여 여러 개의 분리된 재고 상태를 문서화합니다. 이러한 구분은 단순한 구현상의 세부 사항이 아닙니다. 이는 동료가 고객에게 약속을 할 수 있는지 여부를 결정하기 때문입니다.

좋은 코파일럿은 그러한 불확실성을 단순히 “네, 사용 가능합니다”로 평준화하지 않습니다. 대신 다음과 같이 말할 수 있습니다:

“이 상품은 온라인에서 사용 가능한 것으로 보입니다. 이 매장에서 당일 픽업 가능 여부는 아직 확인할 수 없습니다. 다음으로 확인해야 할 사항은 이것입니다.”

이 답변은 마법처럼 느껴지지 않을 수 있습니다. 하지만 미래의 좌절감을 남기는 대신, 고객에게 진실된 다음 단계를 제시하기 때문에 훨씬 더 유용합니다.

시스템이 작업 과정을 보여주도록 하라

사용자 인터페이스(UI)가 프롬프트 추적(prompt trace)을 노출할 필요는 없습니다. 하지만 답변의 운영 기반(operational basis)을 쉽게 검사할 수 있도록 해야 합니다.

파일럿 버전에서는 다음과 같은 간결한 출처 레이블을 보여주세요:

• 제품 사양 — 카탈로그 기록, 오늘 업데이트됨
• 오퍼 조건 — 프로모션 시스템, 23:59 만료
• 매장 재고 가능 여부 — 미확인; 매장 시스템 확인 필요

이 레이블은 동료가 데이터 엔지니어(data engineer)로 변하지 않으면서도 판단력을 사용하도록 돕습니다. 또한 구현팀에게 더 나은 버그 보고서를 제공합니다. “봇이 틀렸다”는 모호합니다. “오퍼 출처가 두 캠페인 뒤쳐져 있었다”는 수정할 수 있는 문제입니다.

안전한 거절을 제품 기능으로 다루라

모든 파일럿 버전은 임의로 답변하지 않을 작은 답변 세트를 가지고 있어야 합니다. 예를 들어, 의료 또는 법률 상품 주장, 개인 정보가 민감한 계정 세부 정보, 반품 정책 예외 사항, 적절한 출처 없이 라이브 재고 약속, 또는 권한을 가진 관리자의 결정이 필요한 경우 등이 있습니다.

폴백(fallback)은 막다른 길이 되어서는 안 됩니다. “도와드릴 수 없습니다”는 기술적으로 안전하지만 상업적으로는 쓸모가 없습니다. 유용한 폴백은 무엇을 확인할 수 있는지, 누가 결정을 소유하는지, 그리고 다음에 어떤 정보가 필요한지를 알려줍니다.

NIST의 AI 위험 관리 프레임워크(AI Risk Management Framework)는 거버닝(governing), 매핑(mapping), 측정(measuring), 그리고 위험 관리(managing risk) 측면에서 생명주기를 설명합니다. 리테일 분야에서는 이 단어들이 매우 실질적인 문제가 됩니다. 제품 사실 정보(product fact)의 소유자는 누구인가? 동료가 답변이 증거를 초과했을 때 알 수 있는가? 잘못된 약속을 어떻게 기록하는가? 로그가 패턴을 식별한 후 누가 프로세스를 변경하는가?

대시보드보다 로그 시스템을 먼저 구축하라

처음 몇 주 동안은 화려한 분석 화면보다 예외 로그(exception log)가 더 가치가 있습니다. 다음 사례들을 기록하세요:

• 오래된 출처를 사용했을 때;
• 수정이 필요한 주장을 했을 때;
• 답변할 수 없었지만 좋은 인계(handoff) 지점을 찾았을 때;
• 동료를 기존 프로세스보다 더 긴 경로로 안내했을 때;
• 누락된 정책이나 불분명한 소유권을 노출했을 때.

이 로그를 카탈로그(catalogue), 오퍼(offer), 정책 또는 워크플로우(workflow)를 변경할 수 있는 사람들과 검토하세요. 만약 같은 예외가 매주 반복된다면, 프롬프트 튜닝(prompt tuning)이 진정한 해결책일 가능성은 낮습니다.

초기 리테일 AI 제품 중 가장 좋은 것은 소박할 수 있습니다. 즉, 누군가가 검증된 답변을 더 빨리 찾도록 돕고, 자신이 답을 가지고 있지 않을 때도 아는 도구입니다. 이것은 타협이 아닙니다. 고객이 신뢰할 수 있는 시스템의 시작점입니다.

출처: NIST AI 위험 관리 프레임워크 및 Shopify 재고 상태(inventory states).

저자: Kirill Naumov는 리테일, 건설, 접객업 등에서 16년간의 경험을 가진 컨설턴트이자 기업가이며, Apple에서 11년, MBA 참가자 교육에서 7년을 보냈습니다. 추가 정보