전자 상거래 검색에 거버넌스가 필요한 이유

전자 상거래 소매 업체는 동일한 시스템 내에서 근본적으로 서로 다른 다양한 쿼리 유형을 처리해야 합니다. 고객이 '오렌지'를 검색할 때는 과일 그 자체를 기대하는 것이지, 오렌지 주스나 오렌지 마멀레이드처럼 '오렌지'라는 단어가 포함된 상품이나 오렌지와 의미적으로 유사한 다른 감귤류 제품을 찾는 것이 아닙니다. ‘단것을 좋아하는 할아버지를 위한 선물’을 검색하는 고객에게는 단순한 키워드 매칭이 아니라, 의미론적 검색이 필요합니다.

어휘 검색(텍스트 매칭), 의미 검색(개념 매칭), 그리고 이 둘을 결합한 하이브리드 검색도 그 자체만으로는 이러한 문제를 해결할 수 없습니다. 어휘 검색은 '오렌지'라는 단어가 포함된 것이라면 무엇이든 반환할 수 있고, 반대로 '오렌지'처럼 고의도 쿼리에 대해 순수 의미 검색을 적용하면 레몬이나 자몽 같은 연관 상품까지 검색 범위가 지나치게 넓어질 수 있습니다. 하이브리드 검색은 어휘 신호와 의미 신호를 혼합하지만, 해당 쿼리를 목적형으로 간주할지, 어떤 제약 조건을 적용할지, 혹은 어떤 비즈니스 정책을 적용할지는 여전히 결정하지 못합니다. 결국 문제는 검색 기술 그 자체에 있는 것이 아닙니다. 이 쿼리가 어떤 성격인지 파악하고, 검색이 시작되기도 전에 어떤 제약 조건을 적용해야 하는지 판단하는 거버넌스 계층이 없다는 것이 핵심 문제입니다.

이 블로그에서는 전자 상거래 검색 거버넌스란 무엇인지, 왜 중요한지, 그리고 제어 계층이 어떻게 예측 가능하고 정확한 검색 결과를 보장하는지 자세히 살펴봅니다.

전자 상거래 검색에서 거버넌스가 의미하는 것

이러한 맥락에서 거버넌스는 사용자의 쿼리와 검색 엔진 사이에 의사 결정 계층을 도입하는 것을 의미합니다. 이 계층은 다음과 같은 기능을 수행합니다.

• 쿼리 의도 분류: 이 검색이 목적형('오렌지')인가요, 아니면 발견형('할아버지를 위한 선물')인가요?
• 비즈니스 제약 조건 적용: 어떤 카테고리 경계, 적격성 규칙, 재고 가용성 제약, 또는 머천다이징 정책을 적용해야 할까요?
• 적절한 전략으로 가는 방법: 어휘 검색, 의미 검색, 하이브리드 중 어떤 것을 사용해야 할까요?

거버넌스 계층은 각 쿼리에 사용할 검색 접근 방식, 적용해야 하는 제약 조건, 검색을 시작하기 전에 적용해야 하는 비즈니스 정책을 결정합니다. 거버넌스와 하이브리드 검색을 혼동하지 않는 것이 중요합니다. 하이브리드 검색은 어휘와 의미 신호를 결합한 하나의 검색 전략일 뿐이지만, 거버넌스는 어휘, 의미, 하이브리드 중 어느 방식을 사용할지 결정하는 상위 의사 결정 계층입니다.

현재 상태: 애플리케이션 계층 "스파게티" 구현

현재 많은 소매 업체에서 이 문제를 해결하기 위해 애플리케이션 계층에 직접 로직을 추가하려고 시도합니다. 이로 인해 종종 하드코딩된 수천 줄의 if-then 문, 정규 표현식 및 복잡한 검색 템플릿으로 뒤엉킨 스파게티 코드라는 결과가 초래됩니다.

이러한 방식은 앞서 살펴본 것처럼 원하는 검색 결과를 제공할 수는 있지만, 운영상 상당한 마찰을 초래한다는 문제가 있습니다.

• 엔지니어링 의존성: 비즈니스 사용자와 머천다이저는 엔지니어링 티켓을 발행하고 대개 몇 주씩 걸리는 긴 배포 주기를 거치지 않고서는 검색 동작을 조금도 수정할 수 없습니다.
• 파편화: 검색 로직이 애플리케이션 코드와 검색 템플릿 사이에 흩어져 있으면 논리적 근거를 설명하거나 감사하기가 어려워지며, 이는 결국 발전 과정에 위험을 초래합니다.

팀에서 라우팅의 필요성을 인식하더라도 '어떤 검색 방법을 선택해야 하는가'라는 잘못된 질문에 초점을 맞추는 경우가 많습니다.

잘못된 논쟁: 어휘 검색, 의미 검색, 그리고 하이브리드 검색 사이의 선택

검색 팀은 흔히 '어휘/BM25 검색이냐, 의미/벡터 검색이냐, 아니면 하이브리드냐'와 같이 어떤 검색 전략을 채택할 것인가를 결정하는 것이 가장 큰 과제라고 생각하곤 합니다. 이러한 관점이 이해되지 않는 것은 아닙니다(검색 방식은 중요합니다). 하지만 이는 실제 배포 환경에서 가장 흔히 발생하는 실패 유형을 간과하고 있습니다. 바로 모든 쿼리에 단일 검색 방식만 사용하다가 결국 최적의 결과를 내지 못하는 상황입니다.

전자 상거래 검색은 근본적으로 서로 다른 의도가 혼합된 것입니다.

• 확정적인 고의도 목적형 검색('오렌지', '우유', '땅콩 없는 초콜릿', '저렴한 올리브 오일').
• 탐색형 검색('산악용 재킷', '로봇 공학을 좋아하는 12세 어린이를 위한 선물').
• 운영상의 제약 조건(재고 가용성, 크기, 가격, 색상).
• 머천다이징 및 캠페인(상위 노출, 하위 노출, 시즌 캠페인).

시스템이 이처럼 다양한 의도를 모두 동일한 검색 전략으로 라우팅하면, 결과는 흔히 계통적인 오류를 범하게 됩니다. 이는 예측 가능한 실패인데, 운영 모델에 거버넌스가 부재하여 발생하기 때문입니다. 팀이 이를 거버넌스의 공백으로 인식하지 못하면, 결국 팀이 가진 유일한 해결 수단인 추가적인 조정으로 대응합니다.

'정확도 조정'이 악순환이 되는 이유

라우팅 계층이 없으면, '정확도 개선' 작업은 흔히 끝이 보이지 않는 무한한 백로그로 변질되곤 합니다.

• 이 쿼리에서 핵심 제품 위에 액세서리가 표시되는 이유는 무엇인가요?
• 왜 갑자기 이 헤드 쿼리에서 관련 항목들이 나타나기 시작했나요?
• 동의어를 추가하고, 분석기를 조정하거나 하이브리드 검색을 활성화했는데, 왜 검색 결과가 변한 걸까요?
• 검색어 하나를 수정하는 데 왜 비즈니스 팀이 엔지니어링 배포까지 기다려야 하나요?

팀은 동의어 추가, 상위 노출, 순위 재지정 실험, 애플리케이션 코드 내 예외 로직 삽입과 같은 더 많은 조정으로 대응합니다. 이 방식이 당분간은 통할지 모르나, 시스템이 여전히 쿼리 유형을 결정하고 검색 전에 올바른 제약 조건을 적용하는 명시적인 결정 계층이 부족하기 때문에 취약한 동작 일으킵니다.

전자 상거래 의도 파헤치기: 헤드와 테일

이 섹션에서는 전자 상거래에서 흔히 나타나는 목적형(Navigational) 및 탐색형(Exploratory) 쿼리 패턴을 실무적으로 구분하기 위해, 이를 각각 ‘헤드(Head)’와 ‘테일(Tail)’이라는 약어로 지칭하겠습니다. 실제 환경에서는 많은 쿼리가 두 가지 측면을 모두 포함하는 경우가 많습니다.

헤드 쿼리(확정적 의도)

이는 사용자가 원하는 바를 정확히 알고 입력하는 직접적이고 목적성 뚜렷한 쿼리입니다.

• 단일 항목 의도 ('오렌지', '우유', '빵').
• 정확한 브랜드 또는 제품군('iPhone 15 Pro' '다이어트 콜라').
• SKU, 모델 번호, 크기('ABC123', 'air max 270').

이런 쿼리들의 경우, 어휘 검색만으로도 토큰 대응(일치하는 단어)을 충분히 처리할 수 있습니다. 하지만 비즈니스는 제약 조건을 준수하고, 예측 가능한 순위를 반환하며, 결과를 직접 제어할 수 있기를 기대합니다. 머천다이저는 쿼리가 정확한 카테고리 범위 내에서 도출되고, 구매 자격을 준수하며, 특정 비즈니스 우선순위가 반영되도록 보장해야 합니다.

의도한 도출 결과를 시행하기 위해서는 거버넌스가 필요합니다. 예를 들어, '오렌지'는 오렌지 주스, 오렌지 마멀레이드, 오렌지 소다가 아니라 반드시 농산물 카테고리로 연결되어야 합니다.

테일 쿼리(탐색형 검색)

이는 쇼핑객이 상품을 탐색할 때 나타나는 설명적이고 의도가 명확한 쿼리입니다.

• ‘단것을 좋아하는 할아버지를 위한 선물’
• '산악용 외투'
• '오래 서 있어도 편한 신발'

이러한 쿼리에서는 어휘 검색이 제 성능을 발휘하지 못하는 경우가 많습니다. 의미 검색은 단어가 정확히 일치하지 않더라도 쿼리의 개념과 상품을 연결할 수 있기 때문에 이러한 경우에 매우 탁월합니다. 그러나 의미 검색만으로도 충분하지 않은 경우도 많습니다. 실제 쿼리에서는 어떤 검색 방식을 사용하든 상관없이, 반드시 준수되어야 하는 제약 조건들이 있기 마련입니다.

제약 조건은 검색 방식과 무관

의미 검색에 제약 조건을 적용하는 것이 하이브리드 검색을 의미하는 것은 아닙니다. 이것들은 서로 무관합니다. Elasticsearch의 필터 및 상위 노출 같은 제약 조건은 어휘, 의미 또는 하이브리드 검색에 모두 적용할 수 있습니다. 관건은 이 쿼리를 어떻게 해석할지, 어떤 제약 조건을 적용할지, 그리고 어떤 검색 전략을 사용할지 결정하는 것입니다.

아래는 검색과 엄격한 제약 조건을 결합한 쿼리의 몇 가지 예시입니다.

• 오렌지: '오렌지'에 대한 어휘 검색과 '과일' 또는 '농산물'과 같은 카테고리 제약 조건을 추가하여 오렌지 마멀레이드, 오렌지 주스, 오렌지 소다를 제외합니다.
• 4달러 미만의 비타민 C 함량이 높은 과일: 영양학적 의도에 기반한 의미 검색을 수행하되, 결과를 과일 카테고리 및 4달러 미만 제품으로 제한하는 제약 조건을 적용합니다.
• 업무용 편안한 신발: 문맥적 의도에 따른 의미 검색을 수행하되, 결과를 신발로 제한하는 제약 조건을 적용합니다.

이러한 쿼리는 단일 방법으로 처리할 수 없습니다.

• 순수 어휘 검색만으로는 충분하지 않은 경우가 많습니다. '비타민 C 함량이 높은'이나 '편안한' 같은 문구들은 깔끔하고 구조화된 속성으로 존재하지 않을 수 있기 때문입니다. 제품 설명, 리뷰 또는 사양을 통해 추론해야 할 수도 있습니다.
• 또한 순수 의미 검색으로도 항상 충분하지 않습니다. 명시적인 제약 조건이 없으면 '비타민 C 함량이 높은 과일'과 같은 쿼리가 의도한 카테고리와 가격 범위를 넘어 비타민 보충제, 과일 맛 음료 또는 비타민 함량이 높은 채소로 확대될 수 있습니다.

거버넌스 계층은 쿼리에 어휘 검색, 의미 이해, 제약 조건 적용 또는 이것들의 조합이 필요한지를 결정합니다. 이 계층이 없으면 전자 상거래 팀은 다음과 같은 상황에 처할 수 있습니다.

• 과도한 제약: 의미 요청에 어휘 검색을 사용(예: '할아버지를 위한 선물')합니다.
• 제약 조건 미달: 고의도 헤드 쿼리(예: '오렌지')에 의미 쿼리를 사용합니다.

거버넌스의 과제는 각 쿼리 유형에 대해 적절한 판단을 내릴 수 있는 시스템을 구축하는 것입니다.

거버넌스가 부재할 경우 발생하는 문제

가장 흔한 실패 유형은 단순합니다. 바로 중간 거버넌스 계층 없이, 사용자 쿼리 그대로를 단일 검색 전략(어휘, 의미 또는 하이브리드)에 직접 전달하는 것입니다.

의도한 결과를 도출하지 못하는 어휘 검색

사용자가 '오렌지'를 검색할 때, 어휘 검색 전략은 해당 토큰이 포함된 모든 상품, 즉 오렌지 주스, 오렌지 마멀레이드, 오렌지 소다 등을 모두 결과로 반환할 수 있습니다. 시스템은 용어를 올바르게 일치시켰지만, 거버넌스 없이는 의도한 쇼핑 맥락(과일)을 도출하지 못할 수 있습니다.

의도한 제약 조건을 넘어 확장하는 의미 검색

사용자가 '오렌지'를 검색할 때, 의미 시스템은 주변 제품 개념 전반에 걸쳐 개념적으로 관련된 항목을 검색할 수 있습니다. 시스템은 더 넓은 영역(과일이나 농산물)을 정확히 이해할 수 있지만, 명시적인 거버넌스 없이는 여전히 사용자가 의도한 제약 조건(특히 오렌지)을 넘어 범위가 지나치게 넓어질 수 있습니다.

문제의 핵심은 결국 거버넌스

필요한 것은 검색이 시작되기 전, 쿼리의 의도를 파악하고 적절한 제약 조건을 강제하는 업스트림 의사 결정 계층입니다. 이렇게 하면 다음과 같은 문제가 해결됩니다.

• 사용자가 실제로 원했던 항목과 유사하거나 관련된 항목이 함께 표시됩니다.
• 모호한 카테고리 경계(예: '음료'와 '농산물'의 혼선).
• 시즌별 상위 노출이나 캠페인 실행 불가.
• 예측할 수 없고 설명할 수 없는 결과.

의도 이해 및 라우팅: 반드시 필요한 제어 평면

거버넌스가 적용된 검색 시스템은 검색 실행 전(Elasticsearch에서 쿼리를 수행하기 전) 단계에 경량화된 제어 평면을 도입합니다. 제어에 대한 자세한 내용은 이번 블로그 시리즈의 3부와 4부에서 다룰 예정입니다. 지금은 이 계층이 어떻게 작동하는지보다는 무엇을 할 수 있는지를 중심으로 살펴보겠습니다.

제어 평면은 의도를 파악하고, 비즈니스 정책을 적용하며, 다음과 같이 적절한 검색 전략을 보장할 수 있습니다.

1. 의도 신호 감지

• 이 쿼리는 목적을 위한 것인가요, 아니면 발견을 위한 것인가요?
• 이미 알고 있는 헤드 쿼리(우유, 빵, 바나나)인가요?
• 이미 알고 있는 제품, 브랜드 또는 카테고리 해석이 있나요?(예: '오렌지'는 농산물로 도출해야 함).
• 쿼리가 SKU와 유사한 패턴인가요?
• 쿼리가 현재 진행 중인 캠페인이나 시즌 정책에 해당하나요?(예: 크리스마스 기간 중 칠면조 관련 검색 결과에 상위 노출)
• 해당 쿼리에 제약 조건(카테고리, 속성, 제외 항목, 가격/크기/색상)이 포함되어 있습니까?

2. 거버넌스 및 비즈니스 정책 적용

• 확정적 제약 조건(카테고리/속성/제외 조건/재고 가용성)을 먼저 적용합니다.
• 활성화된 머천다이징 정책(상위 노출, 하위 노출, 위치 고정, 결과 재정의)을 적용합니다.
• 우선순위 규칙에 따라 충돌을 해결합니다(예: 캠페인 재정의와 글로벌 정책 간의 충돌).

3. 적절한 검색 전략으로 라우팅

• 목적형/고의도 헤드 쿼리를 위한 어휘(빠르고 확정적)입니다.
• 진정한 발견형 쿼리를 위한 의미 검색입니다.
• 명시적인 비즈니스 제약 조건하에, 어휘 및 의미 신호를 결합하여 가치를 더하는 하이브리드 방식입니다.

실제로, 제어 평면의 출력은 단순히 '하이브리드 사용' 또는 '의미 사용'이 아닙니다. 이것이 바로 거버넌스 기반의 검색 계획입니다. 즉, 쇼핑객의 의도를 해석하고, 적용해야 할 제약 조건과 정책을 결정하며, 실행할 검색 전략을 수립합하는 것입니다. 몇 가지 간단한 사례를 통해 이를 구체적으로 살펴보겠습니다.

제어 평면은 각 쿼리에 대해 일관되고 예측 가능하며 확장 가능한 방식으로 적절한 정책과 검색 전략을 선택합니다. 이러한 방식은 의도에 부합하는 제약 조건을 최우선으로 적용하고 라우팅 결정을 명시화함으로써, 프로덕션에서 고도화된 검색 방법의 예측 가능성을 높여 줍니다.

다른 접근 방식과의 관계

일부 팀은 제품 의미를 더 잘 파악하기 위해 개선된 임베딩 모델을 사용하여 의미 검색 품질을 실질적으로 향상할 수 있습니다. 또 어떤 팀은 검색 후 참여도 또는 비즈니스 신호를 기반으로 결과 순서를 최적화하기 위해 LTR(Learning To Rank)과 같은 순위 재지정 방식을 사용하기도 합니다. 두 방식 모두 가치 있으며, 대개 상호 보완적입니다. 더 나은 임베딩은 유사성 매칭을 개선합니다. 순위 재지정은 검색된 후보 사이의 노출 순서를 개선합니다.

거버넌스는 검색의 업스트림에 위치한다는 점에서 다른 계층의 문제를 다룹니다. 제어 평면은 어떤 검색 전략(어휘, 의미, 또는 하이브리드)을 사용할지, 어떤 확정적 제약 조건을 적용할지, 그리고 어떤 쿼리가 여러 비즈니스 정책을 결합할지를 결정합니다.

거버넌스 기반의 제어 평면을 통해 가능한 것

거버넌스 계층이 구축되면 운영 모델이 근본적으로 바뀝니다. 수익에 직결되는 핵심 쿼리의 결과가 예측 가능해집니다. 비즈니스 팀은 엔지니어링팀의 배포 주기를 기다리지 않고도 검색 동작을 업데이트할 수 있습니다. 또한 의미 및 하이브리드와 같은 고급 검색 방법을 전체 시스템의 온/오프 스위치 대신 라우팅 및 가드레일 뒤에서 점진적으로 도입할 수 있습니다.

이 시리즈의 다음 게시물에서는 이러한 운영 모델이 실제로 어떻게 작동하는지, 그리고 왜 이 모델이 그 기반이 되는 검색 기술만큼이나 중요한지를 살펴봅니다.

머천다이저가 수익에 직결되는 핵심 쿼리 문제를 해결하기 위해 Jira 티켓을 생성하고 배포를 기다려야 한다면, 그 병목 지점은 검색 엔진이 아니라 운영 모델에 있는 것입니다. 현대 전자 상거래 검색은 비즈니스 의도를 제어되고 감사 가능한 검색 동작으로 신속하고 안전하게 변환하는 방법이 필요하며, 동시에 고도화된 검색은 실질적인 가치를 더할 수 있는 경우 고급 검색 기능을 활용해야 합니다.

이 시리즈의 다음 내용

이 시리즈에서 살펴본 패턴은 검색의 업스트림에서 작동합니다. 즉, 쿼리 생성이 시작되기도 전에 비즈니스 의도를 최적의 검색 전략으로 변환합니다. 다음 게시물에서는 기술적인 문제에서 운영의 영역으로 관점을 옮겨보겠습니다. 비즈니스 팀이 엔지니어링 배포 없이 검색 동작을 직접 수정할 수 있게 될 때 어떤 변화가 일어나는지, 그리고 거버넌스가 어떻게 그 과정을 안전하게 보장하는지 살펴봅니다.

거버넌스 기반 전자 상거래 검색 실제로 적용해 보기

엔지니어링 병목 현상, 취약한 애플리케이션 계층 로직, 예측할 수 없는 검색 결과는 엔터프라이즈 전자 상거래 서비스 계약을 통해 Elastic 서비스가 해결할 수 있는 문제입니다. 본 시리즈에서 설명하는 거버넌스 기반 제어 평면 아키텍처는 Elastic Services Engineering에서 구축했습니다.

여러분의 팀이 머천다이징 요청을 코드로 옮기는 데 엔지니어링 주기를 허비하고 있거나, 검색 정확성 백로그가 좀처럼 줄어들지 않는다면 Elastic이 도와드릴 수 있습니다. 현재 아키텍처를 평가하고 거버넌스 기반의 기업이 편집 가능한 검색 환경을 구축하는 데 도움을 드릴 수 있습니다. Elastic Services에 문의하세요.

논의에 참여하기

검색 거버넌스, 검색 전략 또는 전자 상거래 검색 아키텍처에 대해 궁금한 점이 있으신가요? Elastic 커뮤니티 대화에 참여하세요.