AI 쇼핑몰 검색 개발 전에 정해야 할 5가지 운영 정책

AI는 상품 목록 API, 검색창, 정렬 버튼을 빠르게 만들 수 있다. 그러나 어떤 상품을 보여주고, 어떤 상품을 숨기며, 무엇을 ‘추천’이라고 부를지는 코드가 아니라 운영 정책이다. 쇼핑몰 검색은 단순한 조회 기능이 아니라 매대 배치, 광고 지면, 재고 처리, 고객 경험, 데이터 수집이 한곳에 결합된 의사결정 시스템이다.

정책을 주지 않은 채 “상품 검색 기능을 만들어 줘”라고만 지시하면 AI는 최신 등록순, 상품명 부분 일치, 단순 페이지네이션 같은 익숙한 예시를 임의로 채울 수 있다. 코드는 실행되더라도 매장 운영에는 맞지 않을 수 있다. 최신 상품이 품절인데도 첫 줄에 노출되고, 판매 종료 상품이 장바구니에 담기며, 고객이 “사과”를 검색해도 “청송 부사”를 찾지 못하는 문제가 대표적이다.

검색 순위는 기술 기능이 아니라 운영 정책이다

상품 진열 순서는 사업자가 설계할 수 있다. 다만 화면이 소비자에게 전달하는 의미와 실제 순위 산정 방식이 어긋나거나, 경제적 이해관계가 있는 노출을 일반 추천처럼 보이게 하면 법적·신뢰상 위험이 커진다.

공정거래위원회는 2024년 6월 쿠팡과 CPLB의 검색순위 운영 및 임직원 구매후기 작성 등을 문제 삼아 잠정 1,400억 원의 과징금을 발표했고, 같은 해 8월 의결서 기준 과징금은 1,628억 원으로 정해졌다. 사업자 측은 처분에 불복했으며, 2026년 4월 보도 기준 관련 취소소송은 계속 중이었다. 이 사례의 실무적 교훈은 “자사 상품 우대는 언제나 불법”이라는 단순 명제가 아니다. 추천이라는 표시가 무엇을 뜻하는지, 광고·자사 이해관계를 명확히 드러냈는지, 순위 변경을 데이터와 문서로 설명할 수 있는지를 설계 단계에서 검토해야 한다는 점이다.

법률 적용은 서비스 구조와 표시 방식에 따라 달라질 수 있으므로 실제 출시 전에는 관련 법령과 최신 집행 사례를 별도로 확인하는 것이 안전하다.

한 줄 프롬프트가 만드는 ‘뚝딱 버전’의 실패 지점

AI는 요구사항의 빈칸을 메울 수 있지만, 그 선택이 매장의 전략과 법적 책임에 맞는지는 판단하지 못한다. 따라서 구현 전에 최소한 다음 다섯 가지 정책을 문서로 확정해야 한다.

1. 정렬 기본값: 무엇을 ‘추천순’이라고 부를 것인가

기본 정렬은 고객이 가장 먼저 보는 진열대다. 다수의 사용자는 정렬 옵션을 바꾸지 않으므로 기본값은 매출, 재고 소진, 신상품 육성, 고객 만족도에 직접 영향을 준다.

먼저 순위 산정 단계를 분리한다

검색 결과는 한 번에 섞어 계산하기보다 다음 순서로 나누는 것이 안전하다.

1. 노출 자격 판정: 판매 가능, 공개 가능, 법적·운영상 차단 대상이 아닌 상품만 후보에 포함한다.
2. 검색 관련도 계산: 상품명, 브랜드, 카테고리, 속성, 동의어가 검색어와 얼마나 맞는지 계산한다.
3. 유기적 순위 계산: 판매 속도, 전환율, 평점 신뢰도, 배송 품질 같은 신호를 결합한다.
4. 비즈니스 규칙 적용: 품절 감점, 신상품 탐색 기회, 다양성 제한 등을 적용한다.
5. 광고 슬롯 결합: 광고 상품은 유기적 순위와 분리해 삽입하고 명확히 표시한다.
6. 안정적 동률 처리: 같은 점수일 때 product_id 같은 고정 키로 순서를 결정한다.

추천 점수는 문서화된 공식이어야 한다

다음은 구조를 설명하기 위한 예시일 뿐, 모든 쇼핑몰에 맞는 정답은 아니다.

organic_score =
  0.45 × query_relevance
+ 0.20 × conversion_rate_28d
+ 0.15 × sales_velocity_14d
+ 0.10 × rating_confidence
+ 0.10 × fulfillment_quality

각 신호는 동일한 범위로 정규화하고, 기간과 집계 대상을 명시해야 한다. 단순 평균 별점은 리뷰 1개의 5점 상품을 리뷰 1,000개의 4.8점 상품보다 높게 만들 수 있으므로 리뷰 수를 함께 반영한 보정 점수를 쓰는 편이 낫다. 판매량만 쓰면 오래 팔린 상품이 영구적으로 유리해질 수 있으므로 최근 기간의 판매 속도와 전환율을 함께 본다.

반드시 정해야 할 세부 항목

• 추천순의 목표가 검색 적합도, 구매 가능성, 고객 만족, 재고 효율 중 무엇인지
• 각 신호의 집계 기간과 갱신 주기
• 취소율, 반품률, 배송 지연, 품절 가능성 같은 감점 신호
• 리뷰가 적은 신상품에 줄 탐색 기회와 최대 가산점
• 동일 브랜드나 동일 판매자가 상단을 과도하게 점유하지 않도록 할 다양성 규칙
• 점수 동률 시 사용할 고정 정렬 키
• 순위 공식의 버전, 변경 사유, 적용 시각, 승인자를 남기는 감사 기록
• A/B 테스트의 성공 지표와 중단 조건

광고와 유기적 추천을 섞지 않는다

광고비, 자사 상품 여부, 높은 마진 같은 경제적 이해관계를 반영할 수는 있지만, 이를 일반적인 “인기순”이나 “추천순”으로 오인하게 만들면 위험하다. 공정거래위원회는 2025년 고가 상품 판매 플랫폼 사건에서도 유료 옵션을 구매한 판매자의 상품이 기본 정렬에서 우선 노출되는 구조와 관련 표시를 문제 삼았다. 광고 상품은 별도 후보군과 슬롯으로 관리하고, 카드 단위에서 식별 가능한 “광고” 또는 “스폰서” 표시를 제공하는 것이 기본이다. 관리자 화면에는 광고 노출 규칙과 유기적 순위 공식을 분리해 보여줘야 한다.

2. 비정상 상태 상품: 품절과 판매 중지는 다른 상태다

is_sold_out 하나로 모든 예외를 처리하면 검색, 상세, 장바구니, 주문 검증이 서로 어긋난다. 최소한 판매 상태, 재고 상태, 공개 상태, 규제 상태를 분리해야 한다.

권장 상태 모델

품절 상품은 재입고 알림과 검색 수요 파악에 가치가 있으므로 무조건 삭제할 필요가 없다. 반면 판매 종료 상품은 일반 목록에서 제외하되, 기존 북마크나 외부 링크로 들어온 고객에게 “판매가 종료되었습니다”라는 설명과 유사 상품을 제공할 수 있다. 상세 URL을 유지할지 410 Gone으로 종료할지는 검색 유입, 법적 공지 필요성, 대체 콘텐츠 가치에 따라 결정한다.

검색 인덱스는 주문 가능 여부의 최종 권한이 아니다

검색 인덱스는 동기화 지연이 생길 수 있다. 따라서 검색 결과에서 재고가 있다고 보여도 다음 단계에서 다시 검증해야 한다.

• 장바구니 담기 시 판매 상태와 재고 재검증
• 주문서 진입 시 가격, 할인, 재고 재검증
• 결제 직전 재고 예약 또는 원자적 차감
• 판매 중지 이벤트 발생 시 검색 인덱스 긴급 제거
• 색인 지연 시간과 실패 건수를 모니터링

이 규칙이 없으면 검색 화면은 정상인데 결제 단계에서만 실패하는 CS 사고가 반복된다.

3. 목록 노출 방식: 페이지네이션, 더 보기, 무한 스크롤 중 무엇을 쓸 것인가

상품이 수천·수만 개라면 한 번에 모두 내려보내면 안 된다. 다만 “쇼핑몰은 언제나 숫자 페이지가 정답”이라고 단정하는 것도 정확하지 않다. 비교 중심 검색에서는 위치와 상태 복원이 중요하고, 카테고리 탐색에서는 “더 보기”가 편할 수 있다.

실무적으로는 검색 결과에는 페이지네이션 또는 “더 보기 + 복원 가능한 페이지 URL”, 발견형 추천 피드에는 무한 스크롤을 우선 검토할 수 있다. 순수 무한 스크롤을 쓰더라도 다음 조건을 충족해야 한다.

• 검색어, 정렬, 필터, 페이지 또는 커서를 URL이나 복원 가능한 상태에 저장
• 상세 페이지에서 뒤로 갔을 때 이전 상품과 스크롤 위치를 복원
• 키보드 탐색, 스크린리더, 포커스 이동을 지원
• 푸터와 주요 탐색 링크에 접근 가능한 대안 제공
• 로딩 실패와 재시도 UI 제공
• 각 결과 묶음에 접근 가능한 고유 URL 또는 링크 구조 마련

오프셋과 커서 페이지네이션

OFFSET 5000 LIMIT 40 같은 깊은 오프셋은 데이터가 많고 갱신이 잦을수록 느려지고 중복·누락이 생기기 쉽다. 얕은 페이지와 관리자 화면에는 오프셋이 단순하지만, 대규모 검색에는 마지막 결과의 정렬 키를 넘기는 커서 방식이 안정적이다.

ORDER BY score DESC, product_id DESC
cursor = last_score + last_product_id

점수만 커서로 쓰면 동률 상품이 빠질 수 있으므로 고유 키를 함께 사용한다. 추천 점수가 실시간으로 자주 바뀐다면 검색 세션 동안 스냅샷 버전이나 랭킹 기준 시각을 고정하는 정책도 필요하다.

4. 검색 범위와 결과 없음 화면: 고객의 표현을 상품 데이터에 연결한다

고객은 운영자가 등록한 정확한 상품명을 모른다. “사과”를 찾는 고객에게 “청송 부사”, “홍로”, “가정용 사과”를 보여주려면 상품 데이터와 검색 사전을 함께 설계해야 한다.

검색 필드 우선순위

한국어 검색에서는 띄어쓰기 차이, 자모 분리, 영문·한글 브랜드 표기, 숫자와 단위, 복합명사도 고려해야 한다. 예를 들어 “에어팟프로2”, “에어팟 프로 2”, “AirPods Pro 2”가 같은 상품군으로 연결되도록 정규화 규칙을 둔다.

권장 검색 파이프라인

1. 입력 길이와 허용 문자를 검증한다.
2. 대소문자, 공백, 특수문자, 단위를 정규화한다.
3. 상품 코드와 정확 일치를 먼저 확인한다.
4. 토큰화와 형태·철자 변형을 적용한다.
5. 운영자가 관리하는 동의어와 카테고리 사전을 확장한다.
6. 텍스트 검색으로 후보를 찾는다.
7. 필요하면 의미 검색을 보조 후보 생성에 사용한다.
8. 판매·공개·규제 상태를 필터링한다.
9. 유기적 점수를 계산하고 광고를 별도로 결합한다.
10. 결과와 진단 정보를 반환한다.

생성형 AI나 벡터 검색을 도입하더라도 SKU, 브랜드, 모델명 같은 정확 일치를 약화시키면 안 된다. 쇼핑 검색에서는 정확 검색 + 텍스트 관련도 + 선택적 의미 검색을 결합한 하이브리드 방식이 일반적으로 안전하다. AI가 카탈로그에 없는 상품, 가격, 재고를 만들어 말하지 않도록 모든 응답을 실제 상품 ID와 현재 데이터에 연결해야 한다.

결과 없음 화면은 두 번째 진열대다

검색 결과가 없을 때 빈 화면만 보여주지 않는다. 다만 관련 없는 인기 상품을 검색 결과인 것처럼 섞어서도 안 된다.

권장 구성은 다음과 같다.

• 사용자가 입력한 검색어를 그대로 보여주고 일치 상품이 없음을 명확히 안내
• 오타 교정 후보와 동의어 제안
• 필터 때문에 0건이 된 경우 제거 가능한 필터 안내
• 범위를 넓힌 결과를 별도 라벨로 제시
• 관련 카테고리, 대체 상품, 전체 인기 상품을 구분해 노출
• 재입고·입점 요청 또는 고객센터 연결
• 결과 없는 검색 이벤트를 관리자 분석에 기록

“결과 없음”과 “필터 적용 후 없음”은 다른 문제다. 원래 후보는 있었지만 가격·색상 필터로 0건이 된 경우라면 필터 완화가 가장 유용하고, 카탈로그 자체에 상품이 없다면 소싱 데이터로 활용해야 한다.

5. 검색 기록: 시장조사 데이터와 개인정보를 함께 관리한다

결과 없는 검색어는 고객이 찾았지만 구매하지 못한 수요를 보여준다. 인기 검색어는 진열과 재고 계획에 도움이 되고, 검색 후 클릭·장바구니·구매 흐름은 검색 품질을 평가하는 핵심 지표가 된다.

그러나 “검색어와 횟수만 저장하면 언제나 개인정보가 아니다”라고 단정할 수는 없다. 검색어 자체에 전화번호, 주문번호, 이름, 건강·종교·성생활 같은 민감한 내용이 들어갈 수 있고, 계정·IP·기기 정보와 결합되면 개인을 식별하거나 추적할 가능성이 커진다.

권장 수집 항목

해시된 회원 ID도 자동으로 익명정보가 되는 것은 아니다. 다시 특정 사용자와 연결할 수 있으면 가명정보 또는 개인정보로 다뤄야 한다. 보관 기간도 일률적으로 정하지 말고 목적, 분석 주기, 보안 위험을 기준으로 원문과 집계 데이터에 각각 설정한다.

관리자 대시보드에 필요한 지표

• 검색량과 고유 검색어 수
• 결과 없음 비율
• 검색 결과 클릭률
• 검색 후 장바구니율과 구매 전환율
• 검색어 수정률과 필터 해제율
• 품절 상품 노출 비율
• 상위 결과 집중도와 브랜드 다양성
• 광고와 유기적 결과의 성과를 분리한 지표
• 검색 인덱스 최신성 및 색인 실패 건수

저빈도 원문 검색어는 개인정보가 포함될 가능성이 있으므로 최소 집계 기준을 넘은 항목만 운영자 화면에 노출하는 방법도 유용하다.

실전 프롬프트: 정책을 코드로 변환하는 방법

개발 용어를 많이 쓰는 것보다 운영 규칙을 명확하게 쓰는 편이 중요하다. 다음 템플릿을 서비스 상황에 맞게 채워 AI에게 제공할 수 있다.

우리 쇼핑몰의 상품 검색 기능을 설계하고 구현해 줘.

1. 노출 자격
- 판매 중이며 공개 상태이고 규제 차단이 없는 상품만 검색 후보에 포함한다.
- 일시 품절은 표시하되 동일 조건의 재고 상품보다 뒤로 보낸다.
- 판매 종료와 일시 판매 중지는 검색·카테고리에서 숨긴다.
- 판매 종료 상품의 직접 URL에는 종료 안내와 대체 상품을 보여주고 구매 버튼은 제거한다.

2. 기본 정렬
- 검색어 관련도를 가장 크게 반영한다.
- 최근 28일 전환율, 최근 14일 판매 속도, 보정 평점, 배송 품질을 반영한다.
- 각 가중치는 설정 파일 또는 관리자 정책으로 변경 가능하게 한다.
- 동률은 product_id 내림차순으로 안정적으로 정렬한다.
- 광고 상품은 유기적 점수에 섞지 말고 별도 슬롯에 넣어 '광고'로 표시한다.

3. 목록 탐색
- 한 번에 40개씩 반환한다.
- 검색어, 정렬, 필터, 페이지 또는 커서를 URL에서 복원할 수 있게 한다.
- 상세 페이지에서 뒤로 가면 목록과 스크롤 위치를 복원한다.
- 대규모 결과는 커서 페이지네이션을 사용한다.

4. 검색 범위
- SKU와 모델명 정확 일치를 최우선으로 한다.
- 상품명, 브랜드, 카테고리, 속성, 동의어 태그를 검색한다.
- 한국어 띄어쓰기와 영문·한글 브랜드 변형을 처리한다.
- 결과가 없으면 오타 제안, 필터 완화, 관련 카테고리, 대체 추천을 구분해 보여준다.

5. 검색 로그
- 정규화 검색어, 시간 구간, 결과 수, 필터, 집계 클릭·구매 지표만 기본 저장한다.
- 회원 ID와 IP는 검색 분석 로그에 저장하지 않는다.
- 이메일, 전화번호, 주문번호 형태는 마스킹한다.
- 원문 보관 기간과 집계 보관 기간을 설정값으로 분리한다.

6. 기술 요구
- 데이터 모델, API 계약, 검색 인덱스, 동기화 방식, 예외 처리, 관리자 지표를 함께 설계한다.
- 실제 조회 패턴에 맞는 인덱스를 제안하고 실행 계획 확인 방법을 설명한다.
- 검색 인덱스 지연 상황에서도 장바구니와 결제 단계에서 상태·가격·재고를 재검증한다.
- 단위 테스트, 통합 테스트, 성능 테스트, 접근성 테스트 시나리오를 작성한다.

구현을 시작하기 전에 내가 정하지 않은 정책 중 결과에 영향을 주는 결정이 있으면 먼저 질문하고, 임의로 정한 가정은 별도 목록으로 표시해 줘.

마지막 문장은 AI를 단순 코드 생성기에서 요구사항 검토 파트너로 바꾸는 핵심 장치다. 다만 질문만 받는 것으로 끝내지 말고, 확정된 답을 정책 문서와 테스트 조건에 반영해야 한다.

구현 설계: 정책을 데이터와 API에 고정한다

데이터 모델 예시

products
- product_id
- sales_status
- stock_status
- visibility_status
- compliance_status
- brand_id
- category_id
- searchable_name
- search_tags
- price
- inventory_quantity
- ranking_feature_version
- updated_at

한 필드에 여러 의미를 넣지 않는다. 예를 들어 status = 1만 두면 판매 가능, 공개 가능, 재고 있음, 규제 통과 중 무엇을 뜻하는지 알 수 없다. 상태 전이도 표로 관리해 초안에서 판매 중으로, 판매 중에서 종료로 이동할 때 필요한 검수와 이벤트를 정의한다.

API 응답에 포함할 정보

• 정규화된 검색어
• 적용된 정렬과 필터
• 결과 묶음과 다음 커서
• 결과 수 또는 근사 결과 수
• 품절·판매 상태 배지
• 광고 여부와 광고 표시 문구
• 오타 교정·검색 범위 확대 여부
• 검색 정책 버전과 추적용 요청 ID

내부 디버깅 정보인 원시 점수와 사업상 민감한 가중치를 고객 API에 그대로 노출할 필요는 없다. 대신 운영자가 요청 ID로 순위 산정 경로를 재현할 수 있어야 한다.

인덱스는 실제 조회 패턴에 맞춰 설계한다

일반적으로 상태 필터와 정렬에 쓰는 열에는 B-tree 계열 인덱스를, 전문 검색 문서에는 역색인 계열을 검토한다. PostgreSQL이라면 tsvector와 GIN 인덱스, 유사 문자열 검색이 필요하면 pg_trgm을 사용할 수 있다. 외부 검색엔진을 쓰더라도 원칙은 같다.

CREATE INDEX idx_products_visibility
ON products (visibility_status, sales_status, compliance_status);

CREATE INDEX idx_products_search_document
ON products USING GIN (search_document);

인덱스를 많이 만들수록 쓰기 비용과 저장 공간도 증가한다. 예상만으로 결정하지 말고 실제 쿼리와 데이터 분포로 EXPLAIN ANALYZE, 슬로 쿼리 로그, 부하 테스트를 확인한다. 상품 수가 늘어날 때는 평균 응답시간보다 p95·p99 지연, 타임아웃률, 색인 최신성을 함께 본다.

생성형 AI를 붙일 때 추가할 안전장치

• 상품 존재 여부, 가격, 재고, 배송일은 카탈로그 API 결과만 사용
• 모델이 만든 검색어 확장은 원문과 함께 기록하고 과도한 확장을 제한
• 정확한 SKU·모델명 검색은 의미 검색보다 우선
• 판매 중지·리콜 필터는 AI 검색 후보에도 동일하게 적용
• 답변에 노출한 상품 ID와 근거 필드를 추적
• 모델 실패 시 일반 텍스트 검색으로 폴백
• 프롬프트 주입성 문구가 상품 설명이나 리뷰에 있어도 시스템 지침으로 실행하지 않도록 분리

출시 전 인수 테스트

운영 단계에서 반복해야 할 일

검색은 한 번 개발하고 끝나는 기능이 아니다. 상품 구성, 계절, 프로모션, 고객 표현이 바뀌므로 다음 주기를 운영 프로세스로 둔다.

1. 매주 결과 없는 검색어와 급증 검색어를 검토한다.
2. 동의어와 카테고리 매핑을 승인 절차로 갱신한다.
3. 품절 노출률, 클릭률, 전환율, 검색어 수정률을 함께 본다.
4. 가중치 변경은 오프라인 평가와 제한된 A/B 테스트 후 확대한다.
5. 광고·자사 상품·유기적 결과의 노출 비중을 별도로 감사한다.
6. 검색 로그의 보관 기간, 접근 권한, 마스킹 실패를 정기 점검한다.
7. 실제 트래픽으로 인덱스 사용률과 느린 쿼리를 재검토한다.

결론

AI는 검색 API와 화면을 빠르게 만들 수 있지만, 어떤 상품이 고객 앞에 설 자격이 있는지 결정하지는 못한다. 실전형 쇼핑몰 검색은 정렬 기본값, 상품 상태, 목록 탐색, 검색 범위와 결과 없음 처리, 검색 로그를 먼저 정책으로 확정하고 그 정책을 데이터 모델, API, 인덱스, 테스트, 관리자 지표에 일관되게 반영할 때 완성된다.

코딩은 자동화할 수 있어도 진열 원칙과 책임은 자동으로 생기지 않는다. 가장 좋은 AI 프롬프트는 길고 어려운 개발 용어가 아니라, 운영자가 이미 결정한 정책과 아직 결정하지 않은 질문을 명확히 구분한 문서다.