이 마지막 게시물에서는 다음과 같은 질문을 던집니다. 대신 AI 에이전트가 입력을 받으면 어떻게 달라질까요?

아키텍처는 변하지 않지만, 중요성은 변한다는 것이 정답입니다. 상위 의사 결정자가 대규모 언어 모델(LLM)인 경우, 사람이 작성한 쿼리에 중요한 관리 제어 평면의 모든 속성이 더욱 중요해집니다. 입력을 생성하는 시스템이 본질적으로 확률적이기 때문에 결정론, 감사 가능성, 충돌 해결 및 제약 조건 적용은 운영상의 편의라기보다 중요한 가드레일이 됩니다.

에이전틱 검색

AI 기반 검색에 대한 가장 일반적인 접근 방식은 간단합니다. 데이터베이스 스키마를 LLM에 제공하고, 프롬프트에 비즈니스 규칙을 제시한 다음, 에이전트가 직접 쿼리를 생성하도록 합니다.

전자상거래 챗봇의 경우에는 Elasticsearch 인덱스 매핑, 필드 타입, 카테고리 분류 체계, 가격 로직, 비즈니스 제약 조건을 에이전트의 컨텍스트 윈도우에 주입한 후 LLM이 자연어를 유효한 Elasticsearch Query DSL로 변환하도록 하는 것을 의미합니다. LLM이 쿼리 작성자가 됩니다.

이 접근 방식은 데모에서 올바로 작동하지만, 프로덕션 환경에서 실패하는 데에는 네 가지 이유가 있습니다.

컨텍스트 팽창

기업의 전자상거래 인덱스 매핑은 결코 간단한 문서가 아닙니다. 비즈니스 로직이 추가되기 전에 필드 정의, 중첩 객체, 멀티 필드 설정, 분석기 설정만으로도 수천 개의 토큰을 실행해야 할 수 있습니다. 매핑 외에도 에이전트는 카테고리 분류 체계(기업 전자상거래에서는 수만 개의 값을 포함할 수 있음), 가격 규칙, 브랜드 계층 구조, 자격 제약 조건, 캠페인 로직이 필요합니다.

그 결과, 컨텍스트 창은 사용자의 실제 의도보다는 구조적 메타데이터에 의해 좌우됩니다. 이는 지연 시간을 증가시키고 토큰 비용을 높이며, 컨텍스트가 커질수록 LLM의 지시 이행 능력을 저하시킵니다. 프롬프트가 길어질수록 특정 지시에 대한 모델의 주의력이 약해지는 이러한 현상은 컨텍스트 부식이라고도 잘 알려져 있습니다.

확률적 환각

LLM은 훈련된 데이터의 패턴과 제공된 컨텍스트를 기반으로 쿼리를 생성합니다. Elasticsearch Query DSL을 생성하라는 요청을 받았을 때, 모델은 존재하지 않는 필드 이름을 착각하거나, 구문상 잘못된 쿼리 절을 구성하거나, 잘못된 필드 유형에 필터 유형을 잘못 적용하거나, 구문상으로는 유효하지만 의미상으로는 잘못된 쿼리를 생성해 사용자의 의도와 일치하지 않는 결과를 반환할 수 있습니다.

Text-to-SQL에 대한 Google Cloud의 BIRD 벤치마크는 이 접근 방식의 한계를 잘 보여줍니다. Google의 최신 단일 모델은 생성된 쿼리 약 4개 중 1개가 잘못되어 70~80%의 정확도를 달성했습니다. 이 수치는 Elasticsearch Query DSL보다 훨씬 표준화된 SQL의 경우입니다. 실제 운영 환경에서 복잡한 매핑과 비즈니스 특화 의미론을 가진 LLM 생성 Elasticsearch 쿼리의 오류율은 더 높을 것입니다.

매출이 매우 중요한 전자상거래 시스템에서, 4건 중 1건 꼴로 쿼리 오류가 발생하는 문제는 반복적인 튜닝으로 해결할 수 없습니다. 이는 접근 방식의 구조적 한계입니다.

보안 공백

LLM이 데이터베이스 스키마에 접근하여 쿼리 작성자 역할을 할 때, 시스템은 간접 프롬프트 인젝션 공격에 취약해집니다. 이커머스 챗봇과 상호작용하는 사용자가 에이전트를 조작하여 의도하지 않은 쿼리를 생성하도록 설계된 입력값을 만들 수 있습니다.

이론상의 위험이 아닙니다. 프롬프트 인젝션은 배포된 LLM 시스템에서 가장 활발하게 연구되는 공격 표면 중 하나입니다. 근본적인 문제는 에이전트가 쿼리를 직접 작성할 때 사용자 의도와 쿼리 실행 사이에 구조적 경계가 없다는 것입니다. LLM은 사용자의 요청을 해석하고 동시에 데이터베이스 작업을 구성합니다. 첫 번째를 조작하면 두 번째에 직접적인 영향을 미칩니다.

높은 카디널리티 확장 실패

특정 전자상거래 분야는 극도로 높은 카디널리티를 가지고 있습니다. 제품 카탈로그에 카테고리 값 17,000개, 브랜드 이름 수천 개, 속성 조합이 수백 가지 있을 수 있습니다. 표준 에이전트 워크플로우에서는 이러한 값을 컨텍스트에 주입해야 LLM이 쿼리를 구성할 때 올바른 값을 선택할 수 있습니다.

이로 인해 가능한 모든 값을 주입하거나(막대한 컨텍스트 소비 및 성능 저하), 일부만 주입하거나(에이전트가 해당 범위 밖의 값을 참조할 수 없음을 감수), 아니면 비거버넌스 검색으로 폴백하는 등의 해결 불가능한 트레이드오프가 발생합니다. 이는 1부의 핵심 문제와 직접적으로 연결됩니다. LLM이 '오렌지'를 검색하고 Elasticsearch가 오렌지맛 청량음료를 반환하면 검색 환경과 동일한 방식으로 채팅 환경이 저하됩니다. 거버넌스가 없다는 것은 구매자가 의도한 해결책을 시스템이 시행할 수 없다는 것을 의미합니다.

쿼리를 기반으로 관련 값을 동적으로 검색하는 것은 알려진 대안이지만, 검색 자체가 관련 값을 누락할 수 있는 추가적인 비결정론적 단계를 도입합니다. 또한 모든 쿼리에 지연 시간과 복잡성이 추가됩니다.

아키텍처적 대안: 의도와 실행의 분리

1부에서 7부까지 설명한 관리형 제어 평면은 근본적으로 다른 접근 방식을 제시합니다. LLM이 최종 쿼리를 직접 작성하는 것이 아니라, 사용자의 자연어 입력에서 검색 의도 문자열을 추출하는 작업 하나만을 담당하는 한정된 역할을 수행합니다.

사용자가 '가격이 저렴한 갈색 구두를 찾아줘'라고 요청합니다. 에이전트의 역할은 Elasticsearch 쿼리를 생성하는 것이 아닙니다. 검색 의도(이 경우 '가격이 저렴한 갈색 구두')를 추출하여 제어 평면에 전달하는 것입니다. 그런 다음 제어 평면은 저장된 정책에 대해 의도 문자열 퍼콜레이션을 실시하고, 계단식 변환을 통해 일치하는 정책을 구성하고, 결정론적으로 충돌을 해결하고, 관리형 Elasticsearch 쿼리를 생성하는 등 이전과 동일한 작업을 수행합니다.

LLM은 인덱스 매핑을 절대 볼 수 없습니다. 필드 유형, 카테고리 분류 체계 또는 가격 임계값에 대해서는 전혀 알 수 없습니다. 또한 쿼리 절을 생성하지 않습니다. LLM은 메타데이터 에어갭이라고 부르는 아키텍처 경계의 자연어 처리 측에서 작동하며 확률론적 구성 요소(LLM)와 구조화된 데이터 레이어(스키마, 정책, 쿼리 구성) 사이를 엄격하게 분리합니다.

메타데이터 에어 갭이 제공하는 것

• 스키마 맹목성. LLM은 데이터베이스 스키마에 접근할 수 없으므로 잘못된 쿼리를 생성하거나, 필드 이름을 착각하거나, 구조적 정보를 노출하도록 조작될 수 없습니다. 스키마는 에어 갭의 결정론적 측면에만 존재합니다.

• 최소한의 컨텍스트. LLM의 프롬프트에는 수천 개의 매핑 데이터, 비즈니스 규칙 및 카테고리 분류 체계 토큰 대신, 페르소나 및 의도 추출 지침만 포함되어 있습니다. 덕분에 토큰 비용, 대기 시간 및 컨텍스트 열화를 크게 줄일 수 있습니다.

• 결정론적 실행. Elasticsearch에 도달하는 모든 쿼리는 LLM(대규모 언어 모델)에 의해 확률적으로 생성되지 않고, 인간이 검증한 정책 템플릿을 사용하여 제어 평면에 의해 구성됩니다. 구문 유효성이 보장됩니다. 의미론적 정확성은 1부부터 6부까지 설명한 것과 동일한 정책 프레임워크에 의해 보장됩니다.

• 아키텍처별 보안. 프롬프트 인젝션은 구조적으로 비효율적입니다. 사용자가 에이전트를 조작하여 비정상적인 의도 문자열을 생성하더라도 해당 문자열은 저장된 정책에 대해 퍼콜레이션을 실시합니다. 일치하는 정책이 없으면 쿼리가 생성되지 않습니다. 에이전트는 쿼리를 생성하지 않으므로 사용자는 에이전트에게 쿼리를 구성하라고 지시할 수 없습니다. 쿼리는 제어 평면에서 작성되며, 제어 평면은 결정론적입니다.

각 부분이 어떻게 연결되는지

다음 단계에서는 관리형 제어 평면이 에이전트 매개 쿼리를 처리하는 방법을 보여 줍니다.

1단계: 사용자와 에이전트의 대화

전자상거래 챗봇과 상호작용하는 한 쇼핑객이 '가격이 저렴한 초콜릿을 찾고 있는데, 땅콩이 포함된 제품은 제외해'라고 이야기합니다.

2단계: 에이전트가 의도 추출

LLM의 역할은 쿼리 생성이 아니라 의도 추출입니다. 최소한의 프롬프트로 제품 의도를 파악하도록 지시하기만 하면 에이전트가 '땅콩이 없고 가격이 저렴한 초콜릿'과 같은 검색 의도 문자열을 생성합니다.

이는 가벼운 분류 작업입니다. LLM은 인덱스 매핑, 카테고리 분류 체계 또는 가격 규칙 없이도 이를 수행할 수 있습니다. 이 작업에는 LLM이 가장 잘하는 일인 '자연어 이해'만 필요합니다.

3단계: 제어 평면이 쿼리 제어

'땅콩 없고 가격이 저렴한 초콜릿'이라는 의도 문자열이 제어 평면으로 전달되어 정책 인덱스에 대해 퍼콜레이션을 실시합니다. 일치하는 정책은 세 가지입니다.

• '가격이 저렴한' 정책('가격이 저렴한'을 추출하여 제품 카테고리에 따라 가격 필터를 적용).

• '초콜릿' 정책(결과를 초콜릿 카테고리로 제한).

• 제외 정책 '없이'(제외 대상을 추출하고 must_not 필터 적용)

제어 평면은 3부와 4부에서 설명한 것과 같은 계단식 변환(우선 순위 지정, 필드별 충돌 해결, 소비된 구문 추적)을 통해 이러한 정책을 적용합니다. '크리스마스 캠페인' 정책도 활성화되어 있는 경우 3부에서 설명한 대로 제품 정책이 구성되며, 에이전트의 참여로 인해 거버넌스 모델이 전혀 변경되지 않습니다.

4단계: 관리형 쿼리 실행

제어 평면은 '가격이 저렴한' 정책에서 파생된 가격 상한, 땅콩 함유 제품에 대한 제외 필터, 활성 캠페인 부스트가 적용된 적절한 카테고리로 제한되는 '초콜릿' 검색과 같이 완전히 관리되는 Elasticsearch 쿼리를 생성합니다. '초콜릿' 정책에 경제성 최적화 가중치(7부)가 포함되어 있는 경우 해당 가중치도 적용됩니다. 마진 부스팅이 3.0배로 설정된 이유는 '초콜릿'은 마진이 높은 제품을 홍보함으로써 소매업체에 이득을 주는 검색 쿼리이기 때문입니다. 쇼핑객에게 구매 기록이 있는 경우(6부) 개인화 신호가 위에 겹쳐집니다. 이 쿼리는 구조상 구문적으로 유효하고, 정책 설계상 의미적으로 정확합니다.

5단계: 에이전트가 결과 반환

에이전트에게 제품 결과가 반환되고, 이를 에이전트가 사용자에게 대화식으로 제시합니다. 반환 경로에서 에이전트의 역할은 결과를 형식화하고, 후속 질문에 답변하며, 제품 정보를 제공하는 것입니다. 검색 자체가 통제되고 결정론적이며 설명 가능합니다.

에이전트가 잘하는 것(그리고 잘 못하는 것)

이 아키텍처는 LLM이 잘하는 부분을 활용하고, 부족한 부분에서는 시스템을 보호합니다.

LLM은 자연어 의도를 이해하는 데 탁월합니다. '가격이 저렴한 초콜릿을 찾고 있는데, 땅콩이 포함된 제품은 제외해'는 의도를 파싱하고, 제품 참조를 식별하며, 부정을 인식하는 자연어 이해 작업입니다. 이는 생성 문제가 아닌 분류 문제이기 때문에 LLM이 안정적으로 처리할 수 있습니다. 출력은 복잡한 구조화된 쿼리가 아니라 짧은 의도 문자열입니다.

LLM은 복잡한 제약 조건 하에서 정확하고 구조화된 결과물을 도출하는 데 어려움을 겪습니다. 유효한 Elasticsearch 쿼리 DSL을 생성하려면 정확한 필드 이름, 올바른 절 중첩, 각 필드에 적합한 필터 유형, 수천 가지에 달하는 예외적인 상황에 걸쳐 비즈니스 규칙을 일관되게 적용해야 합니다. 이러한 속성은 결정론적 시스템에서는 아주 쉽게 적용되는 반면, 확률론적 시스템에서는 불안정하게 적용되는 속성입니다.

관리형 제어 평면은 LLM은 자연어 처리 측에, 결정론적 정책 엔진은 쿼리 구성 측에, 그리고 그 사이에 아키텍처 경계를 두는 식으로 각 구성 요소를 적절한 위치에 배치합니다.

거버넌스는 폭발 반경을 제한

이것은 3부의 동일한 인사이트를 에이전트 컨텍스트로 확장한 것입니다. 3부에서는 거버넌스가 검색 시작 전에 후보 집합을 좁혀 의미 검색을 더 안전하게 만든다는 점을 살펴보았습니다. 관리형 카테고리 내 제품 500개에 대한 시맨틱 검색은 SKU 500,000개에 대한 시맨틱 검색과는 근본적으로 다른 문제입니다.

동일한 원리는 에이전트 매개 쿼리에도 적용됩니다. 거버넌스가 없으면 에이전트가 '가격이 저렴한 초콜릿'을 잘못 해석하고 가격 제약, 카테고리 필터, 제외 조건 없이 전체 카탈로그를 검색하는 쿼리를 생성할 수 있습니다. 거버넌스를 사용하면 에이전트가 불완전한 의도 문자열을 생성하더라도 제어 평면이 일치하는 정책으로 쿼리를 제한합니다. 최악의 경우는 무제한 쿼리가 제품 카탈로그에 도달하는 것이 아니라, 실행되는 정책의 수가 줄어드는 것입니다.

거버넌스는 확률적인 오류의 영향 범위를 좁힙니다. 이는 확률론적 구성 요소가 시맨틱 검색 모델이든 LLM 에이전트이든 동일하게 적용됩니다.

LLM이 제안하는 정책: 적용 범위 확대

2부에서는 LLM이 인간이 작성한 정책과 동일하게 저자 → 테스트 → 프로모션 파이프라인에 진입하는 새로운 정책을 제안할 수 있다는 아이디어를 소개했습니다. 에이전트 컨텍스트에서 이것은 강력한 피드백 루프가 됩니다.

LLM은 쿼리 로그를 분석하고, 제어 평면에 일치하는 정책이 없는 패턴(수정되지 않은 검색으로 넘어가는 쿼리)을 식별하며, 이러한 격차를 커버하기 위한 새로운 정책을 제안할 수 있습니다. 상품 담당자는 각 제안을 검토하고, 그것을 테스트한 후 예상된 행동을 생성하는 경우 그것을 홍보합니다. 거버넌스 모델은 사람의 검증 없이 LLM이 제안한 정책이 프로덕션에 적용되지 않도록 보장합니다.

시간이 지남에 따라 이것은 선한 순환을 만들어냅니다: 제어 평면의 정책 범위가 확장되고, 수정되지 않은 검색이 필요한 쿼리의 비율이 줄어들며, 시스템은 점점 더 관리되고, 모든 정책은 감사 가능하고, 버전이 관리되며 개별적으로 되돌릴 수 있게 됩니다.

더 넓은 패턴: 확률론적 시스템을 위한 결정론적 가드레일

이 시리즈에서 설명하는 아키텍처, 즉 확률적 입력 소스와 데이터 검색 시스템 사이에 위치하는 결정론적 제어 평면은 전자상거래 검색에만 국한되는 것이 아닙니다. 인공지능 에이전트가 구조화된 데이터와 상호 작용해야 하는 모든 곳에 동일한 패턴이 적용됩니다.

SQL 데이터베이스를 쿼리하는 에이전트 역시 스키마 삽입으로 인한 컨텍스트 과부하, 잘못된 열 이름, 프롬프트 삽입 위험, 높은 카디널리티의 값 선택과 같은 동일한 문제에 직면합니다. Jira 같은 티켓 시스템, Salesforce 같은 고객 관계 관리(CRM) 시스템, GitHub 같은 코드 저장소와 상호 작용하는 에이전트도 비슷한 문제를 겪습니다. 모든 경우에서 핵심 아키텍처 질문은 한 가지입니다. 'LLM이 쿼리를 작성해야 하는가, 아니면 LLM이 의도를 추출하여 쿼리를 작성하는 결정적 계층으로 전달해야 하는가?'

관리형 제어 평면은 이 질문에 대해 반복 가능한 답을 제공합니다. 정책은 데이터입니다. 의도 추출은 LLM의 일입니다. 쿼리 구성은 제어 평면의 역할입니다. 메타데이터의 공중층이 두 가지를 분리해 줍니다. 거버넌스 프레임워크(우선 순위 지정, 충돌 해결, 계단식 변환, 감사 가능성)는 정책 수가 증가하더라도 결정론적 레이어를 운영 가능한 상태로 유지하도록 보장합니다.

결론

이 시리즈에서 설명한 전자상거래 검색 거버넌스 패턴(데이터로서의 정책, 작성 → 테스트 → 승격 워크플로우, 계단식 변환, 필드별 충돌 해결, 퍼콜레이터 기반 역방향 매칭, 다중 계층 폴백)은 머천다이저가 정책을 작성하고 구매자가 쿼리를 입력하는 환경을 위해 설계되었습니다. 그러나 이 아키텍처는 초기 사용 사례를 훨씬 뛰어넘는 가능성을 제공할 수 있습니다.

입력 소스가 사람 구매자가 아닌 AI 에이전트일 때, 관리형 제어 평면은 확률론적 시스템과 프로덕션 데이터 저장소 사이에서 핵심적인 안전 계층이 됩니다. 이는 기업 시스템에 필요하지만 LLM이 단독으로는 제공할 수 없는 결정론적 보장(구문적 유효성, 의미론적 정확성, 감사 가능성, 보안)을 제공합니다.

결정론적 제어 평면은 AI 에이전트를 대체하지 않습니다. 안전하게 배포할 수 있는 AI 에이전트를 만듭니다.

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

이 시리즈에서 설명한 관리형 제어 평면 아키텍처는 정책-데이터 패러다임에서 퍼콜레이터 기반 조회, 개인화, 경제적 최적화 및 에이전트 에어 갭에 이르기까지 Elastic Services Engineering이 설계하고 구축했습니다. 이 시리즈에 걸쳐 설명되는 모든 패턴은 기업 규모의 제품 카탈로그를 기준으로 구축되고 검증된 작업 시스템에서 가져온 것입니다.

팀에서 AI 기반 검색 환경을 구축하고 있고 에이전트 매개 쿼리에 대한 결정론적 가드레일이 필요하거나 Elasticsearch에서 관리되고 비즈니스 편집이 가능한 검색 아키텍처를 구현하려는 경우, Elastic Professional Services를 통해 구현을 가속화할 수 있습니다. Elastic 전문 서비스에 문의하세요.

논의에 참여하기

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

본 게시물에서는 기존 아키텍처를 변경하지 않고도 거버넌스 제어 평면을 확장할 수 있는 두 가지 개인화 메커니즘을 소개합니다. 두 메커니즘 모두 1부에서 5부까지의 거버넌스 계층과 곱연산 방식으로 중첩됩니다. 즉, 정책은 여전히 실행되고 제약 조건은 적용되며, 충돌은 해결되는 동시에 개인화 신호가 동일한 거버넌스 쿼리에 구성되어 Elasticsearch가 반환하는 결과가 이미 개인화되도록 보장합니다.

첫 번째 메커니즘은 개별 쇼핑객이 이전에 구매한 적이 있는 제품을 부스트하는 것입니다. 두 번째는 쇼핑객의 프로필을 기반으로 특정 코호트별 정책을 활성화하는 것입니다. 이 두 가지는 개인화가 검색 시스템 옆에 별도로 덧붙여지거나 검색 후처리로 적용되는 독립적인 시스템이 아니라 정책 기반 제어 평면의 자연스러운 확장임을 보여줍니다.

본 게시물에 사용된 개인화 기법의 수학적 원리를 자세히 살펴보려면 ML 후처리 없는 Elasticsearch 검색 개인화 및 Elasticsearch의 코호트 인식 랭킹을 참조하세요.

재방문 고객을 위해 구매 이력을 사용하여 검색 결과를 부스팅하는 방법에 대한 라이브 데모를 보려면 설명 가능한 개인화: 구매 이력을 통한 검색 부스팅 영상을 시청해 보세요.

개인 구매 이력 부스팅

개인화의 가장 단순한 형태는 가장 효과적인 방법 중 하나이기도 합니다. 즉, 쇼핑객이 이전에 제품을 구매한 적이 있다면 관련 내용을 검색할 때 해당 제품을 부스트하는 것입니다. 특정 브랜드의 초콜릿 칩 쿠키를 정기적으로 구매하는 쇼핑객이 "cookies"를 검색하면 해당 쿠키가 더 높은 순위에 노출되어야 합니다. 이는 모델이 선호도를 예측했기 때문이 아니라 직접적인 행동 증거가 존재하기 때문입니다.

참여 방법

세션이 활성화된 사용자의 경우처럼 검색 요청에 사용자 식별자가 포함되면 제어 평면은 스레드 풀을 사용하여 두 개의 Elasticsearch 쿼리를 병렬로 실행합니다.

1. 정책 인덱스에 대한 퍼콜레이터 쿼리(3부와 4부에서 설명한 거버넌스 조회와 동일)

2. user_purchases 인덱스에 대한 구매 이력 쿼리이며 term(user_id)을 통해 특정 사용자로 필터링한 후 현재 검색 문자열을 해당 사용자의 제품 제목과 매칭합니다.

이 쿼리들은 동시에 실행되므로(어느 쪽도 상대방을 기다리지 않음) 개인화 조회 작업이 거버넌스 파이프라인에 유의미한 지연 시간을 추가하지 않습니다.

구매 이력 쿼리는 현재 검색 문자열을 저장된 제품 제목과 매칭할 때 Elasticsearch의 텍스트 분석(어간 추출, 토큰화)을 사용합니다. 이는 "cookies"를 검색했을 때 표준 텍스트 분석을 통해 과거에 구매한 "brownie cookies"와 매칭됨을 의미하며 정확한 문자열 일치를 요구하지 않습니다.

부스트 가중치 산출

모든 과거 구매 이력이 동일한 부스트 가중치를 가져야 하는 것은 아닙니다. 가중치는 두 가지 직관적인 요소, 즉 쇼핑객이 해당 제품을 얼마나 자주 구매했는지와 얼마나 최근에 구매했는지를 고려합니다. 지난주에 15번 구매한 제품은 6개월 전에 한 번 구매한 제품보다 훨씬 더 강력한 신호입니다. 가중치 산정 시 빈도에는 로그 스케일링을 적용하여 특정 품목의 대량 구매가 전체 결과를 압도하지 않도록 하며, 최신성에는 지수 감쇠를 적용하여 오래된 구매 기록이 시간이 지남에 따라 자연스럽게 희미해지도록 합니다.

부스트 공식에 대한 자세한 수학적 내용은 ML 후처리 없는 Elasticsearch 검색 개인화를 참조하세요.

쿼리 구성 방식

구매 이력 부스팅은 3부와 4부에서 다룬 거버넌스 정책 필터 및 부스트 그리고 마진이나 인기도(7부에서 살펴볼 예정) 같은 비즈니스 신호 부스트를 감싸는 최외곽 스코어링 계층으로 쿼리에 구성됩니다. 이는 거버넌스 정책에 의해 제외된 제품이 구매 이력 부스트로 인해 다시 나타나지 않음을 의미합니다. 거버넌스가 결과 세트를 제어한다면 개인화는 그 안에서 순위를 조정합니다. 구매 이력이 없는 제품에 불이익이 주어지지는 않습니다. 다른 모든 조건이 동일할 때 관련 구매 이력이 있는 제품이 더 높은 순위를 차지할 뿐이며 구매 이력이 없는 제품의 거버넌스 랭킹은 그대로 유지됩니다.

매 검색마다 Elasticsearch에 쿼리를 수행하는 이유는 무엇인가요?

구매 이력은 애플리케이션 계층에 캐싱되는 대신 매 검색 시 Elasticsearch에서 조회됩니다. 이는 의도적인 설계 결정입니다. 쿼리가 Elasticsearch의 텍스트 분석 파이프라인을 사용하여 현재 검색 문자열을 제품 제목과 매칭하기 때문에 시스템은 제품 검색 자체를 구동하는 것과 동일한 어간 추출, 토큰화 및 언어 처리 기능의 이점을 누릴 수 있습니다. 인메모리 캐시 조회를 사용한다면 이러한 분석 기능을 다시 구현하거나 정밀도가 떨어지는 매칭 방식을 수용해야만 합니다.

이러한 순서가 왜 중요한지 확인하기 위해 이전에 오렌지 주스를 구매했던 쇼핑객이 현재 "oranges"를 검색하는 상황을 가정해 보겠습니다. 구매 이력 쿼리는 텍스트 분석을 통해 검색어 "oranges"와 과거 구매 이력인 "orange juice"를 매칭하고 해당 제품에 대한 부스트 가중치를 계산합니다. 하지만 거버넌스 계층은 이미 "oranges" 검색을 농산물 카테고리로 제한하여 오렌지 주스를 결과에서 완전히 필터링한 상태입니다. 쿼리 내에 오렌지 주스에 대한 구매 이력 부스트가 존재하더라도 거버넌스 제어를 거친 결과 세트 내에 적용 대상이 되는 문서가 없기 때문에 아무런 영향을 주지 못합니다. 쇼핑객은 관련성과 개인화에 따라 정렬된 신선한 오렌지를 보게 되며 이로써 거버넌스 가드레일은 유지됩니다.

성능 비용은 최소화됩니다. 구매 이력 인덱스는 규모가 작고(한 사용자의 구매 이력은 보통 수백만 건이 아니라 수십에서 수백 건의 문서에 불과함) 쿼리가 퍼콜레이터 조회와 병렬로 실행되므로 임계 경로를 연장하지 않기 때문입니다.

사용자 이력이 없는 경우의 "spring water" 쿼리 예시

로그인하지 않은 사용자나 "spring water"를 구매한 적이 없는 사용자가 검색할 경우 다음과 유사한 결과를 보게 될 수 있습니다.

사용자 구매 이력 예시

반면 Carol이라는 사용자는 다음과 같은 제품들이 포함된 쇼핑 이력을 보유하고 있습니다.

상기 구매 이력이 있는 경우의 "spring water" 검색 예시

Carol이 "spring water"를 검색하면 과거에 구매했던 내역이 반영된 개인화된 결과를 보게 됩니다. 위의 구매 이력을 보면 Carol은 "Carbonated Spring Water"(초록색 병)를 약 40회 구매했으며 가장 최근 구매일은 이틀 전입니다. Carol이 "spring water"를 검색하면 그녀가 해당 제품을 선호한다는 점을 시스템이 알고 있으므로 그 제품을 부스트합니다. 개인화되지 않은 결과에서는 루비콘(Rubicon) 생수가 대신 첫 번째 검색 결과로 노출된 점에 주목해 주세요.

코호트 인지형 정책 활성화

개별 구매 이력은 행동 패턴이 확립된 재방문 고객에게 효과적입니다. 그러나 많은 쇼핑객은 신규 방문자이거나 익명 혹은 평소 패턴을 벗어나 검색하는 방문자입니다. 이러한 쇼핑객들에게 코호트 멤버십은 과거의 행동이 아닌 쇼핑객이 누구인가에 기반한 다른 차원의 개인화를 제공합니다.

비건 쇼핑객이 "chocolate"을 검색하면 비건 초콜릿이 더 높은 순위에 노출되어야 합니다. 할랄을 준수하는 쇼핑객이 "snacks"를 검색하면 할랄 인증 제품이 눈에 띄게 표시되어야 합니다. 건강에 관심이 많은 쇼핑객이 "yogurt"를 검색하면 프로바이오틱스 제품이 부스트되어야 합니다.

제품 태그가 아닌 정책으로서의 코호트

제품에는 이미 dietary_restrictions: ["vegan"] 또는 dietary_restrictions: ["halal"]과 같은 필드를 포함하여 일반적인 속성들이 부여되어 있습니다. 문제는 쇼핑객의 코호트와 이러한 제품 속성을 연결하는 로직이 어디에 위치하느냐 하는 것입니다.

단순한 접근 방식은 애플리케이션 계층이나 검색 템플릿에 해당 매핑을 하드코딩하는 것입니다. 예를 들어 사용자가 비건이라면 dietary_restrictions: "vegan"에 부스트를 추가하는 식입니다. 하지만 이는 1부에서 설명한 동일한 애플리케이션 계층 스파게티 코드이며 새로운 코호트를 추가하거나 코호트의 의미를 변경할 때마다 코드 수정이 필요하다는 동일한 운영상의 마찰을 야기합니다.

대신 거버넌스 제어 평면은 코호트 로직을 정책 엔진 내에 유지합니다. 코호트 정책은 쇼핑객의 코호트 멤버십(예: "vegan")과 제품 속성(예: dietary_restrictions: “vegan”)이라는 두 가지 요소를 연결하는 다리 역할을 합니다. 이 정책은 비건 코호트에 속한 쇼핑객이 검색할 때 dietary_restrictions 항목에 "vegan"이 포함된 제품을 부스트하도록 그 연결 고리를 정의합니다.

코호트 로직이 애플리케이션 코드가 아닌 정책 엔진 내에 존재한다는 것은 다음을 의미합니다.

• 새로운 정책을 만드는 것만으로도 신규 코호트를 추가할 수 있으며 제품을 다시 인덱싱할 필요가 없습니다.

• 코호트 정책은 규칙 엔진의 모든 기능을 활용합니다. 즉, 필터 추가, 소프트 부스트 적용, 유의어 확장, 검색 전략 변경 등 정책이 수행할 수 있는 모든 조치를 취할 수 있습니다.

• 코호트의 동작은 다른 모든 정책과 동일한 관리자 UI를 통해 관리됩니다. 머천다이저는 2부에서 설명한 Author → Test → Promote 워크플로우를 통해 코호트 정책을 생성하고 테스트한 뒤 배포할 수 있습니다.

비건 코호트 정책 예시

머천다이저는 다음과 같은 특성을 가진 코호트 정책을 생성합니다.

• 코호트: ["vegan"]

• 일치 조건: 모든 쿼리(또는 특정 제품 카테고리)에 일치

작업: dietary_restrictions: "vegan" 항목에 부스트 가중치 2를 적용하는 소프트 부스팅 수행

코호트 활성화 방식

각 정책 문서에는 cohorts 필드가 있습니다. 코호트에 관계없이 모든 쇼핑객에게 적용되는 유니버설 정책은 이 필드를 비워둘 수 있으며 이 경우 거버넌스 제어 평면에 의해 내부적으로 "_all"이라는 값이 할당됩니다. 코호트별 정책에는 ["vegan", "kosher", “sweet_tooth”]와 같이 대상이 되는 코호트 이름이 저장됩니다.

검색 요청에 사용자 프로필이 포함될 경우 제어 평면은 퍼콜레이터 쿼리를 위한 단순한 terms 필터를 구성합니다.

이 단일 필터에는 모든 유니버설 정책과 사용자의 코호트별 정책이 함께 포함됩니다. _all 센티널 덕분에 깔끔한 포함 필터 구성이 가능해지며 정책에 코호트 제한이 없는 경우를 처리하기 위해 별도의 must_not이나 exists 쿼리를 사용할 필요가 없습니다.

그런 다음 퍼콜레이터는 평소와 같이 정책 일치 여부를 평가합니다. 유일한 차이점은 후보 정책 세트가 해당 쇼핑객의 코호트와 관련된 것들로 한정되었다는 점뿐입니다. 이후 단계의 모든 과정(연쇄적인 변환, 필드별 충돌 해결, 소비된 구문 추적 등)은 3부와 4부에서 설명한 비개인화 흐름과 동일하게 작동합니다.

"chocolate" 검색 시 비건이 아닌(일반) 사용자의 결과

비건이 아닌 사용자가 초콜릿을 검색할 경우 해당 결과에 비건 코호트 부스트가 적용되지 않습니다. 이들 사용자는 다음과 같이 상위 검색 결과에서 비건이 아닌 초콜릿을 자주 보게 됩니다.

"chocolate" 검색 시 비건 코호트 정책이 적용된 결과

비건 코호트 쇼핑객이 "chocolate"을 검색하면 이 정책이 퍼콜레이터 후보 세트에 포함됩니다. 정책이 일치하면 거버넌스 제어 평면은 비건 인증 초콜릿에 소프트 부스트를 적용합니다. 이 부스트는 곱연산 방식으로 적용되어 비건 초콜릿이 더 높은 순위에 오르지만 위 필터는 이 시리즈의 3부에서 자세히 설명한 소프트 부스팅으로 정의되었기에 비건이 아닌 초콜릿이 결과에서 완전히 제외되지는 않습니다.

하지만 쇼핑객이 명시적으로 "Hershey milk chocolate"을 검색한다면 비건 부스트가 여전히 적용되기는 하지만 Hershey 밀크 초콜릿 제품이 가진 더 강력한 텍스트 관련성에 의해 그 효과가 상쇄될 수 있습니다.

비건 코호트에 속하지 않은 쇼핑객이 동일한 쿼리를 검색할 때는 "vegan cohort" 정책을 전혀 보지 못하며 해당 정책은 그들의 후보 세트에도 포함되지 않습니다. 거버넌스 계층은 동일하며 오직 활성화된 정책 세트만 다를 뿐입니다.

구매 이력과 코호트의 결합

방대한 구매 이력을 가진 비건 쇼핑객은 구매 이력 기반의 부스트뿐만 아니라 비건 코호트 전용 정책 활성화 혜택을 동시에 받게 됩니다. 신규 방문자나 익명 쇼핑객의 경우 어떠한 행동 데이터가 없더라도 추정된 코호트 멤버십만으로 의미 있는 개인화를 제공할 수 있습니다. 예를 들어 익명 사용자가 비건 제품만 검색했다면 해당 사용자를 비건 코호트 멤버로 분류할 수 있습니다. 계정 생성 시 스스로를 할랄 준수자로 식별한 쇼핑객은 첫 번째 검색부터 즉시 할랄에 최적화된 결과를 받게 됩니다.

개인화 계층의 구성 방식

function_score 계층의 중첩 순서는 매우 중요합니다. 최내곽에서 최외곽 순으로 나열하면 다음과 같습니다.

1. 기본 쿼리: 명명된 쿼리(fulltext_match, title_phrase_match)를 사용한 키워드 또는 시맨틱 매치

2. 거버넌스 정책 계층: bool.filter 절로 구현된 하드 필터와 function_score 함수로 구현된 소프트 부스트(3부 및 4부 참고)

3. 비즈니스 신호 부스트: 마진 및 인기도 부스팅(7부에서 자세히 다룰 예정)

4. 구매 이력 부스트: 최외곽의 function_score 계층

이러한 순서는 거버넌스가 결과 세트를 제어(무엇이 노출될지)하고 비즈니스 신호가 해당 세트 내의 순위를 조정(소매업체 관점에서 무엇을 먼저 보여줄지)하며, 구매 이력이 개인의 행동에 기반해 순위를 추가로 조정(쇼핑객 관점에서 무엇을 먼저 보여줄지)하도록 보장합니다. 각 계층은 이전 계층을 곱연산 방식으로 감싸기 때문에 효과들이 서로 충돌하지 않고 결합되어 작용하게 됩니다.

운영 측면에서의 의미

거버넌스 제어 평면을 통한 개인화는 1부와 2부에서 설명한 모든 운영적 특성을 그대로 유지합니다.

• 배포가 필요 없는 변경: 코호트 정책은 관리자 UI를 통해 생성, 테스트 및 배포됩니다. 새로운 식단 관련 코호트를 추가하거나 부스트 가중치를 조정할 때 코드 수정이나 엔지니어의 개입이 전혀 필요하지 않습니다.

• 감사 가능성: 모든 코호트 정책은 버전이 관리되는 개별 문서입니다. 머천다이저가 "왜 이 사용자에게 비건 제품이 더 높게 노출되나요?"라고 묻는다면 해당 쿼리에 실행된 다른 모든 정책과 함께 디버그 패널에 표시되는 특정 우선순위의 특정 정책이 그 답이 됩니다.

• 충돌 해결: 코호트 정책은 3부에서 설명한 것과 동일한 필드별 충돌 해결 프로세스에 참여합니다. 만약 코호트 정책의 카테고리 부스팅이 캠페인 정책의 카테고리 오버라이드와 충돌하더라도 별도의 처리 없이 동일한 우선순위 및 전략 프레임워크에 의해 결정론적으로 해결됩니다.

• 측정 가능성: 코호트 정책은 개별적으로 분리되어 있고 각각 활성화 여부를 전환할 수 있으므로 시스템 내 다른 정책들과 마찬가지로 전환율, 클릭률, 장바구니 담기 비율에 미치는 영향을 독립적으로 측정할 수 있습니다.

이 시리즈의 다음 내용

다음 게시물에서는 거버넌스 제어 평면의 또 다른 측면을 살펴봅니다. 바로 정책을 통해 마진과 인기도 부스팅을 쿼리마다 세밀하게 조정하여 경제적 최적화를 단순한 정적 설정을 넘어 거버넌스 차원의 의사결정으로 전환하는 방법입니다.

7부 참조: 쿼리 기반의 거버넌스 경제적 최적화: 쿼리별 마진 및 인기도 부스팅

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

이 게시물에서 설명한 개인화 패턴(개별 구매 이력 부스팅 및 코호트 인지 정책 활성화)은 Elastic 서비스 엔지니어링 팀이 반복 가능한 이커머스 검색 액셀러레이터의 일환으로 설계하고 구축했습니다. 두 메커니즘 모두 이 시리즈 전반에서 설명한 거버넌스 제어 평면 아키텍처와 통합됩니다. Elastic 전문 서비스에 문의하세요.

논의에 참여하기

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

아키텍처에서 구현까지

3부에서는 제어 플레인 아키텍처에 대해 설명했습니다. 여기에는 조회 기본 메커니즘으로서의 역방향 매칭, 매칭과 동작을 분리하는 정책 문서, 그리고 여러 정책을 하나의 실행 계획으로 조합하는 연쇄적 변환이 포함됩니다. 이 게시물에서는 정책 조회를 가능하게 하는 Elasticsearch 기능인 퍼콜레이터 쿼리를 실제 구현 관점에서 자세히 다룹니다.

퍼콜레이터는 제어 플레인에 필요한 방식 그대로 검색 방향을 반대로 뒤집기 때문에, 거버넌스 용도에 매우 잘 어울립니다. 이 게시물에서는 먼저 퍼콜레이터가 무엇을 하는지, 왜 중요한지를 명확히 설명한 뒤, 인덱스 설계, 정책 저장, 쿼리 시점 평가, 여러 정책의 조합까지 구현 과정을 단계별로 살펴봅니다.

일반 검색이 작동하는 방식

전자 상거래 시스템에서는 title, category, price와 같은 필드를 포함하는 수십만 또는 수백만 개의 제품 문서가 존재할 수 있습니다. 사용자가 일치하는 문서를 검색할 때는, Elasticsearch가 사용자의 검색 문자열을 이러한 제품 문서에 저장된 하나 이상의 필드와 비교하도록 요청하는 것입니다. Elasticsearch의 기본 분석기인 표준 분석기는 텍스트를 소문자로 변환하고 토큰으로 분리합니다. “oranges” 검색이 “Oranges”와 일치하는 것은 소문자 변환 처리 때문입니다. 어간 추출 기능이 포함된 언어 인식 분석기를 사용하면 “orange”와도 일치하게 되는데, 이는 두 형태가 동일한 어간으로 축약되기 때문입니다. 예를 들어, 다음 매치 쿼리는 “title” 필드에 “orange” 또는 “oranges”가 포함된 문서를 반환합니다.

따라서 위의 쿼리에 대해 Elasticsearch는 title 필드가 "oranges"와 일치하는 제품 문서들을 반환합니다. 여기에는 "Orange Fruit Spread", "Orange Juice", "Juicy oranges", "Orange Marmalade" 등의 결과가 포함될 수 있습니다. 기억해야 할 핵심 사항은 Elasticsearch가 일반적으로 검색 문자열을 문서와 비교하고, 그 검색 문자열과 일치하는 문서를 반환하는 데 사용된다는 점입니다.

거버넌스 문제: 제품 검색 전에 관련 정책 찾기

1~3부에서 설명했듯이, 거버넌스 기반 검색 시스템은 사용자의 검색 문자열을 제품 카탈로그에 직접 전달하지 않습니다. 먼저 해당 검색 문자열에 적용되는 정책이 있는지 확인합니다.

한 판매자가 사용자가 정확히 "oranges"를 검색할 때, 검색 결과를 오렌지 카테고리로만 제한하고 오렌지 주스, 오렌지 마멀레이드, 오렌지 탄산음료는 제외하기로 결정했습니다. 이 비즈니스 결정은 정책 형태로 저장됩니다. 사용자가 "oranges"를 입력하면, 제어 플레인은 해당 정책을 찾아 그 지침을 읽고, 그에 맞게 상품 카탈로그에 대한 검색을 수정해야 합니다. 이를 수행하려면, 제어 플레인은 어떤 저장된 정책들이 해당 검색 문자열과 관련 있는지 판별해야 합니다.

기업 환경에는 이러한 정책이 수백 개에서 수천 개에 이를 수 있습니다. 이를 if/else 논리로 하나씩 확인하는 것은 2부에서 설명한 애플리케이션 계층 안티패턴입니다. 필요한 것은 모든 정책을 인덱스에 저장하고 주어진 검색 문자열과 일치하는 정책을 즉시 찾을 수 있는 방법입니다. 바로 이 지점에서 퍼콜레이터가 사용됩니다.

방향 뒤집기: 퍼콜레이터

이전에 언급했듯이, 일반적인 검색에서 Elasticsearch는 검색 문자열을 문서들과 비교하고, 해당 검색 문자열을 포함하는 문서들을 반환하는 데 주로 사용됩니다.

퍼콜레이터는 이 과정을 반대로 뒤집습니다. 퍼콜레이터에서는 각 문서가 쿼리 패턴을 저장하는 인덱스를 만들고, 이후 들어온 검색 문자열을 이 저장된 쿼리들과 비교하여 어떤 저장된 쿼리 패턴이 트리거되었는지를 판별합니다.

거버넌스 측면에서 "저장된 쿼리 패턴"은 곧 정책을 의미합니다. 각 정책에는 자신이 어떤 종류의 검색 문자열과 일치해야 하는지를 설명하는 패턴이 포함되어 있습니다. 예를 들어, 검색 문자열이 "oranges"와 정확히 일치하는지, 혹은 검색 문자열에 “olive oil”이 포함되어 있는지를 판별하는 식입니다. 들어오는 문자열은 사용자의 검색 텍스트이며, 이는 쿼리 시점에 전달되어 저장된 모든 정책 패턴과 대조되어야 합니다. 이에 대해서는 관련 PRISM 영상의 4분 9초 부분에서 다루고 있습니다.

단계별 설명: "oranges" 검색으로 관련 정책을 찾는 방식

정책

한 판매자는 사용자가 다른 단어 없이 정확히 "oranges"만 검색했을 때 일치하도록 정책을 작성했습니다. 퍼콜레이터에서 일치가 발생하면, 문서의 나머지 내용에는 제어 플레인이 제품 쿼리를 구성할 때 사용할 규칙들이 포함됩니다. 이 예시에서는 그 규칙 중 하나로 검색 결과를 과일 카테고리로 제한(필터링)하는 설정이 있습니다.

percolator 필드에는 이 정책이 언제 실행되어야 하는지를 정의하는 패턴이 포함되어 있습니다. 이 경우에는 "START oranges END" 문구와 일치합니다. rule_type, rule_args 필드는 정책이 실행되었을 때 어떤 동작을 수행해야 하는지를 정의합니다. START, END 토큰은 경계 표시자이며, 이에 대해서는 곧 설명하겠습니다.

정책이 어떻게 작성되는지는 관련 PRISM 동영상의 2:52에 나오는 PRISM Studio UI에서 확인할 수 있습니다.

사용자 검색

한 쇼핑객이 검색창에 "oranges"라고 입력합니다.

제어 플레인이 일치하는 정책을 확인

제품 카탈로그를 검색하기 전에 제어 플레인은 사용자의 검색 문자열을 가로채 경계 표시로 감싼 뒤 퍼콜레이터로 전송합니다.

"START oranges END" 문자열은 저장된 모든 정책 패턴과 대조됩니다. 내부적으로는 Elasticsearch가 저장된 정책 패턴들을 이 문자열에 대해 실행한 뒤, 일치하는 항목들을 반환합니다. 이것이 바로 퍼콜레이터입니다. 사용자의 검색 문자열은 저장된 모든 정책 패턴과 비교되었고, 일치하는 패턴이 반환되었습니다. if/else 체인은 없습니다. 순차적 평가도 없습니다. 인덱스가 매칭 처리를 담당합니다.

제어 플레인이 정책 적용

제어 플레인은 일치하는 정책들의 동작 규칙을 읽어들입니다. 위의 정책은 제어 플레인이 결과를 과일 카테고리로 제한하도록 지시합니다. 이에 따라 제어 플레인은 제품 카탈로그를 대상으로 다음과 같은 최종 Elasticsearch 쿼리를 구성합니다.

사용자가 "oranges"를 검색했습니다. 제품 카탈로그는 과일 카테고리로 제한된 "oranges"에 대한 쿼리를 수신합니다. 이 제한 조건 때문에 오렌지 주스, 오렌지 마멀레이드, 오렌지 탄산음료는 제외됩니다.

"orange marmalade"가 오렌지 정책을 트리거하지 않는 이유

다른 사용자가 “orange marmalade”를 검색한다고 가정해 보겠습니다. 제어 플레인이 해당 문자열을 감싼 뒤 퍼콜레이션을 수행합니다. "START orange marmalade END". 오렌지 정책의 패턴은 match_phrase: "START oranges END"입니다. 오렌지 정책이 일치하지 않아 해당 정책은 적용되지 않으며, 결과도 과일 카테고리로 제한되지 않습니다.

이것이 START 및 END 경계 표시자의 목적입니다. 이 경계 표시자가 없다면, "oranges"라는 단어에 일치하도록 만든 정책이 "orange marmalade" 같은 쿼리에서도 의도치 않게 실행될 수 있습니다. 사용자의 검색 문자열을 START 와 END 로 감싸고 정책 패턴에 해당 표시자를 포함함으로써 "oranges"가 다른 단어 없이 완전한 검색 문자열일 때만 정책이 실행되도록 보장할 수 있습니다. 이는 쇼핑객과 판매자 양측의 의도 모두에 부합합니다.

두 번째 정책: 어간 추출 필드에서의 "olive oil"

모든 정책에 정확한 문자열 일치가 반드시 필요한 것은 아닙니다. “olive oil” 정책은 어간 추출 처리된 필드에서 일치 여부를 판단하므로, 사소한 단어 형태 변화와 관계없이 실행됩니다.

이 정책의 패턴은 query 대신 query.stemmed에 대해 매칭됩니다. 사용자의 검색 문자열이 들어오면, 이는 query 필드(정확한 원문 텍스트)와 query.stemmed 필드(어간 추출 분석기로 분석하여 단어를 어간으로 축약해, "olives"와 "olive", "oils"와 "oil"이 각각 같은 어간으로 처리됨) 둘 다에 저장됩니다. 정책의 패턴은 어간이 추출된 문자열과 비교하여 검사되므로, 단어 형태의 사소한 변형과 관계없이 실행됩니다.

START 및 END 경계 표시자는 어간 처리된 필드에서도 동일하게 작동하며, 이를 통해 "olive oil"이 더 긴 문장의 일부로 포함된 경우가 아니라 전체 검색 문자열 자체일 때만 이 정책이 실행되도록 보장합니다.

이 게시물의 나머지 부분에서는 이를 실제 운영 환경에서 사용할 수 있도록 만드는 구현 세부 사항들을 다룹니다. 여기에는 두 가지 매칭 방식을 모두 지원하는 인덱스 매핑, 하이라이트를 이용해 구문 제거 및 소비된 구문 추적을 수행하는 방법, 그리고 서로 충돌하는 여러 정책을 하나의 실행 계획으로 조합하는 방식이 포함됩니다.

정책 인덱스 매핑

정책 인덱스에는 저장된 쿼리 패턴을 담기 위한 퍼콜레이터 필드와, 퍼콜레이터가 매칭 대상으로 사용할 들어오는 검색 문자열의 구조를 반영하는 텍스트 필드가 필요합니다. 아래 매핑은 설명을 단순화하기 위해 간략화한 버전입니다. 실제 운영 환경의 배포 구성은 훨씬 더 복잡하며, 경계 표시 처리, 가변 패턴 매칭(예: “under $4”에 통화 값이 포함되어 있음을 인식하는 기능), 그리고 기타 다양한 분석 작업을 처리하기 위해 커스텀 분석기를 사용합니다.

이 인덱스의 이름이 policies인 이유는 각 문서가 2부에 정의된 대로 완전한 거버넌스 정책 하나를 나타내기 때문입니다. 여기에는 매칭 기준, 작업, 우선순위, 메타데이터가 포함됩니다. rule_type 및 rule_args 필드에는 정책의 작업 구성 요소가 포함되어 있으며, 여기에는 제어 플레인이 제품 카탈로그에 대해 실행할 쿼리를 구성할 때 사용할 지침이 담겨 있습니다.

query 필드는 퍼콜레이터가 매칭 대상으로 사용하는 문자열입니다. 이 필드에는 정확한 원문 버전과 어간 처리된 버전, 총 두 가지 형태가 있습니다. 사용자의 검색 문자열이 들어오면, 해당 문자열은 임시 인메모리 인덱스의 이 필드에 저장됩니다. query에 대해 매칭하는 정책은 정확한 원문 문자열을 기준으로 검사하며, query.stemmed에 대해 매칭하는 정책은 어간 처리된 버전을 기준으로 검사합니다.

하이라이트, 필터링, 정렬을 통한 퍼콜레이션

위의 간단한 예시는 최소한의 퍼콜레이터 요청만 보여주었습니다. 실제 환경에서는 제어 플레인이 하이라이트 기능을 추가하고, 비활성화된 정책을 필터링하며, 우선순위 기준으로 정렬을 수행합니다.

하이라이트 설정은 "query"를 필드 키로 사용하고 matched_fields 안에는 "query.stemmed"가 포함됩니다. 이 기능은 Elasticsearch의 통합 하이라이터에 대해, 부모 query 필드에 대한 하이라이트를 반환하되 어떤 토큰을 하이라이트할지 결정할 때는 query.stemmed 서브필드의 매칭 결과도 함께 고려하도록 지시하는 것입니다. 이 덕분에 어간 처리된 필드에서 매칭된 정책이라도 원본 텍스트에서 정확한 하이라이트 범위를 생성할 수 있으며, 이는 제어 플레인이 구문 제거 및 이미 적용된 구문 추적을 수행하는 데 필요합니다.

enabled: true 필터는 비활성화된 정책이 제외되도록 보장합니다. 우선순위에 적용된 sort는 우선순위가 높은 정책이 먼저 반환되도록 하며, 이를 통해 제어 플레인이 연쇄 변환을 올바른 순서로 처리할 수 있게 합니다. 가장 중요한 추가 요소는 highlight 필드로, 이는 사용자의 검색 문자열에서 어떤 단어들이 각 매칭을 유발했는지를 정확히 알려줍니다.

"olive oil" 검색에 대한 응답은 다음과 같은 형태일 수 있습니다.

하이라이트가 중요한 이유

응답의 하이라이트는 다음과 같습니다. "<em>START olive oil END</em>". Elasticsearch는 사용자의 검색 문자열에서 어떤 단어들이 정책 매칭을 유발했는지를 정확히 알려줍니다. 이는 단순한 시각적 표시용 기능이 아닙니다. 이 하이라이트 메타데이터는 이후 단계의 다음과 같은 두 가지 핵심 동작을 구동합니다.

구문 제거. 일부 정책은 제품 카탈로그 쿼리를 구성하기 전에 검색 문자열에서 매칭된 텍스트를 제거해야 합니다. 예를 들어 "cheap"에 매칭되는 정책은 해당 단어를 제거한 뒤, 대신 이를 가격 필터로 변환합니다. 하이라이트는 정책이 검색 문자열의 어느 부분과 정확히 매칭되었는지를 식별하므로, 시스템은 어떤 부분을 제거해야 하는지 알 수 있습니다.

처리된 구문 추적. 3부에서 설명했듯이, 여러 정책이 동일한 검색 문자열에 매칭될 경우 우선순위가 더 높은 정책이, 더 낮은 우선순위 정책이 매칭한 단어를 제거할 수 있습니다. 각 정책의 하이라이트를 현재의(계속 변화하는) 검색 문자열과 비교함으로써, 시스템은 특정 구문이 이미 처리되었음을 감지하고 우선순위가 더 낮은 정책을 건너뛸 수 있습니다. 이를 통해 중복 처리를 방지하고 결정론적인 동작을 보장할 수 있습니다.

하이라이트 기능의 동작 방식에 대해서는 이 문서에서 더 자세히 알아볼 수 있습니다.

퍼콜레이션에서 실행 계획까지

퍼콜레이터는 매칭된 정책들의 집합을 반환합니다. 그러나 3부에서 설명했듯이, 조회는 전체 과정의 절반에 불과합니다. 나머지 절반은 이러한 매칭 결과들을 일관된 실행 계획으로 조합하는 과정입니다. 실제 쿼리를 예로 들면 다음과 같습니다.

실제 사례: 크리스마스 캠페인 기간 중 "Cheap chocolate" 검색

시스템에 두 가지 활성 정책이 있다고 가정해 봅시다. 하나는 "Cheap chocolate" 정책(우선순위 210)이고, 다른 하나는 "Christmas chocolates" 정책(우선순위 300)이며, 둘 다 3부에 자세히 설명되어 있습니다.

1단계: 퍼콜레이션. 사용자가 "cheap chocolate"을 검색합니다. 제어 플레인은 검색 문자열을 "START cheap chocolate END" 형태로 감싼 뒤 퍼콜레이터로 전달합니다. 두 가지 정책이 매칭됩니다. "Cheap chocolate" 정책의 패턴은 "cheap chocolate" 구문에 매칭되고, "Christmas chocolates" 정책의 패턴은 어간 처리된 필드를 통해 "chocolate"에 매칭됩니다.

2단계: 우선순위 기준 정렬. 퍼콜레이터는 두 정책을 모두 반환하며, 우선순위가 높은 순서대로 정렬합니다. “Christmas chocolates” 정책(300)이 먼저 처리되고, 그다음 “Cheap chocolate” 정책(210)이 처리됩니다.

3단계: 연쇄 변환 적용. 이는 3부의 initial state → [Policy A] → state' → [Policy B] → state'' → execution plan 모델입니다.

"Christmas chocolates" 정책(우선순위 300)이 먼저 적용됩니다.

• "Christmas foods and drinks", "Christmas sweets" 카테고리에 대한 하드 필터를 추가합니다.

• 7달러 미만 가격 필터를 추가합니다.

• "Advent calendars" 카테고리에 3배 소프트 부스트를 적용합니다.

“Cheap chocolate” 정책(우선순위 210)이 수정된 상태를 기준으로 다음으로 적용됩니다.

• "Chocolates", "Milk chocolates"라는 카테고리 하드 필터를 추가하려고 시도하지만, 크리스마스 정책이 이미 이 필드를 on_conflict: override로 설정했기 때문에 Cheap chocolate 카테고리는 제외됩니다.

• 가격 필터 $2를 추가하려고 시도합니다. 크리스마스 초콜릿 정책이 이미 가격에 대해 on_conflict: restrict를 설정했지만, $2가 $7보다 더 제한적이므로 $2가 적용됩니다.

• 검색 문자열에서 "cheap"을 제거합니다.

4단계: Elasticsearch 쿼리 구성. 제어 플레인은 실행 계획을 조합하여 제품 카탈로그에 대해 실행할 단일 Elasticsearch 쿼리를 구성합니다.

원래 검색 문자열은 “cheap chocolate”이었습니다. 제품 카탈로그에 도달하는 쿼리는 거버넌스가 적용된, 의도 인식 기반의 검색 실행 계획입니다. "cheap"이라는 단어는 이미 처리되어 가격 제약 조건으로 변환되었으며, 결과는 크리스마스 시즌 카테고리로 제한되고, 어드벤트 캘린더 제품은 순위 부스트가 적용됩니다. 또한 가격 상한은 더 낮은 우선순위 정책에서 정의된, 더 엄격한 값을 따르게 됩니다. 모든 변환 과정은 결정적이며, 추적 가능하고, 설명 가능합니다.

이러한 배수값들이 기본 BM25 점수와 어떻게 상호작용하는지에 대한 간단한 개요는 관련 PRISM 동영상의 8:45에서 확인할 수 있으며, 여기서 곱셈 방식의 부스트에 대해 간단히 설명합니다.

이것이 확장 가능한 이유

퍼콜레이터는 비대칭성 덕분에 이러한 사용 사례에서 효율적으로 동작합니다. 기업용 전자 상거래 시스템에는 수백만 개의 제품이 있을 수 있지만, 거버넌스 정책은 보통 수백 개에서 수천 개 수준에 불과하기 때문입니다. 퍼콜레이터는 전체 제품 카탈로그를 스캔하는 것이 아니라, 들어온 하나의 검색 문자열을 저장된 정책 패턴 집합과 비교하는 방식으로 동작합니다. 비용은 정책 수에 비례하며, Elasticsearch는 내부 최적화(저장된 쿼리 패턴의 용어 인덱싱, 불 논리 단락 평가 등)를 적용하여 빠른 매칭 속도를 유지합니다.

새 정책을 추가하는 것은 단순히 새 문서를 인덱싱하는 작업에 불과합니다. 정책을 비활성화하는 것도 필드 하나를 업데이트하면 됩니다. 코드 변경도, 배포도, 재시작도 필요 없습니다.

조회에서 거버넌스 기반의 검색으로

퍼콜레이터는 3부에서 설명한 제어 플레인 아키텍처를 대규모 환경에서도 실용적으로 만들어 주는 고속 역매칭 기능을 제공합니다. 정책은 저장되고 인덱싱되는 데이터이며, 들어오는 검색 문자열에 대해 효율적으로 매칭됩니다. 제어 플레인은 3부에서 설명한 연쇄 변환과 필드별 충돌 해결 과정을 통해, 매칭된 정책들을 거버넌스된 실행 계획으로 조합합니다. 그리고 검색 엔진은 제품 카탈로그에 대해 이 거버넌스된 실행 계획을 수행합니다.

그 결과, 판매자가 애플리케이션 코드를 건드리지 않고도 새 정책을 작성하고, 대표 검색 쿼리를 대상으로 테스트한 뒤, 이를 운영 환경에 반영하고, 그 효과를 즉시 확인할 수 있는 시스템이 만들어집니다. 퍼콜레이터는 정책 조회를 빠르게 만들고, 제어 플레인은 정책 조합을 결정적으로 수행하며, 거버넌스 기반 워크플로는 전체 과정을 안전하게 만듭니다.

이 시리즈의 다음 내용

이 시리즈의 다음 게시물에서는 거버넌스 기반의 제어 플레인을 새로운 영역으로 확장합니다. 여기서는 다중 계층 검색 아키텍처를 소개하며, 안정적인 페이지 지정과 패싯을 유지하면서 엄격 검색, 완화 검색, 시맨틱 검색을 어떻게 오케스트레이션할 수 있는지를 설명합니다.

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

이 게시물에 설명된 퍼콜레이터 기반 제어 플레인은 인덱스 매핑과 경계 표시부터 하이라이트 기반 구문 추적 및 연쇄적 정책 조합에 이르기까지, Elastic Services Engineering이 반복 적용 가능한 전자 상거래 검색 가속기의 일부로 구축한 것입니다. 여기에 제시된 모든 쿼리 예시와 정책 구조는 엔터프라이즈 규모의 제품 카탈로그를 대상으로 검증된 실제 시스템에서 가져온 것입니다.

Elasticsearch 기반의 거버넌스가 적용된 정책 중심 제어 플레인을 구현하고자 한다면, Elastic Services를 통해 이를 더 빠르게 구축할 수 있습니다. Elastic 전문 서비스에 문의하세요.

논의에 참여하기

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

쿼리 해석이 종종 어려운 이유

정책을 코드(if/else 블록)로 저장하면 쿼리 시 효율적인 정책 검색을 위한 인덱싱이 없는 수만 줄의 취약한 논리가 생성됩니다. 반복 속도는 느리며(단일 쿼리 동작 변경에 6주 배포 주기가 필요할 수 있음), 책임이 불분명하며(왜 결과가 변했는가?), 비즈니스 사용자는 엔지니어링의 개입 없이는 검색 동작을 수정할 수 없습니다. 이는 다음 이미지의 왼쪽에 나와 있습니다.

위 이미지의 오른쪽에는 정책을 Elasticsearch 인덱스에 데이터로 저장하는 모습이 나와 있습니다. 이 접근 방식은 하드코딩된 쿼리 해결 논리와 관련된 모든 문제를 해결합니다. 그러나 이것이 작동하려면 사용자 쿼리와 일치하는 정책을 신속하게 결정하고 충돌을 해결하는 방법이 필요합니다. 이러한 이유로 거버넌스 기반 제어 평면이 필요합니다.

제어 평면 패턴

거버넌스 기반 제어 평면은 원시 사용자 쿼리와 Elasticsearch 검색 사이에 위치합니다. 사용자 텍스트를 입력으로 받으며, 출력은 필터, 부스트, 검색 라우팅 결정을 포함하는 실행 계획입니다.

제어 평면 파이프라인은 다음으로 구성됩니다.

1. 사용자 쿼리: 사용자가 "oranges" 또는 "gift for grandpa" 같이 찾고자 하는 문자열을 입력합니다.

2. 정책 조회: 사용자 쿼리를 정책 인덱스와 매칭합니다.

3. 일치하는 정책 반환: 사용자 쿼리와 일치하는 정책이 정책 인덱스에서 반환됩니다.

4. 정책 적용: 제어 평면은 반환된 정책을 분석하고, 일치하는 정책을 필터, 부스트, 재정의 및 가드레일을 포함하는 일관된 단일 실행 계획으로 구성합니다. 이 계획은 적절한 검색 방법(예: 어휘, 시맨틱, 하이브리드)을 적용합니다.

5. 실행: 수정된 의도 인식 Elasticsearch 쿼리가 애플리케이션으로 전달되어 제품 카탈로그 인덱스에서 실행됩니다.

6. 설명(선택 사항): 비즈니스 및 의도에 맞는 결과를 제공하는 쿼리를 생성하는 것 외에도, 제어 평면은 어떤 정책이 트리거되었고 어떻게 결합되었는지 보여주는 선택적 설명 가능성 페이로드를 제공합니다.

사용자의 검색 문자열에 적용할 정책을 찾으려면 빠른 역매칭 원시 기능이 필요하며, 이를 퍼콜레이터 쿼리로 해결합니다. 관련 정책을 검색한 후, 여러 매칭된 정책을 통합된 실행 계획으로 결합하려면 우선순위, 충돌 전략, 사용된 구문 추적, 그리고 독립적으로 적용되지 않고 순차적으로 적용되는 연쇄적 변환으로 이루어진 판단 프레임워크가 필요합니다. 또한, 가장 적합한 검색 기술을 선택해야 합니다(예: "oranges"의 경우 BM25, "gift for grandpa"의 경우 시맨틱 검색).

정책 조회: 제품 검색 전 쿼리 확인

쇼핑객이 쿼리를 입력할 때, 거버넌스 기반 제어 평면을 갖춘 검색 시스템은 해당 쿼리를 제품 카탈로그에 대해 직접 실행하지 않습니다. 먼저 저장된 정책 세트와 비교하여 쿼리를 확인하고 쿼리의 의도와 비즈니스 우선순위를 반영하도록 수정합니다.

정책 구조

각 정책은 두 가지를 정의하는 단순한 문서입니다.

• 일치 조건: 이 정책이 실행되도록 하는 쿼리 텍스트입니다. 정확한 구문, 단일 단어, 패턴 또는 조합일 수 있습니다.

• 작업: 정책이 실행될 때 수행해야 할 작업입니다. 카테고리 필터를 적용하거나, 제품을 제외하거나, 가격 제약 조건을 추출하거나, 검색 전략을 변경하는 것 등이 해당할 수 있습니다.

시스템은 일치하는 모든 정책을 찾아 실행 계획으로 구성한 다음, 그제야 제품 검색을 실행합니다. 종합적으로 볼 때, 정책은 마치 고객이 무엇을 찾고 있는지 이해하고 올바른 통로로 안내하는 지식이 풍부한 매장 직원과 같습니다.

정책 패턴

이 시리즈의 첫 번째 글에서는 실제로 적용된 정책의 예를 소개했습니다. "oranges"를 농산물 카테고리로 제한하고, "without peanuts"를 제외 사항으로 처리하며, "gift for grandpa"를 시맨틱 검색으로 라우팅했습니다. 아키텍처의 핵심은 각각의 경우 검색이 시작되기 전에 저장된 정책과 비교하여 쿼리를 검사한다는 점입니다. 정책은 어떤 제약 조건을 적용할지, 어떤 텍스트를 수정할지, 그리고 어떤 검색 전략을 사용할지를 결정합니다. 제품 카탈로그에 대한 쿼리는 정책이 적용된 후 새로 재작성된 쿼리가 생성된 다음에 실행됩니다.

이 과정이 빠르게 이루어지는 이유

엔터프라이즈 전자 상거래 시스템은 수백만 개의 제품을 보유할 수 있지만, 정책은 수백 개 또는 수천 개에 불과합니다. 정책 조회 단계는 전체 제품 카탈로그가 아니라 소규모로 큐레이션된 인덱스 기준으로 검색하므로 속도가 빠릅니다. 정책이 자체 인덱스에 데이터로 저장되기 때문에, 새 정책을 추가하는 판매자는 애플리케이션 코드에 영향을 주지 않으며, 제품 검색을 최적화하는 엔지니어는 정책 인덱스에 영향을 주지 않습니다. 이 두 가지 문제는 독립적으로 진화합니다.

위의 예는 과정을 개념적으로 설명합니다. 내부적으로 정책 조회는 Elasticsearch 퍼콜레이터 쿼리 유형을 사용해 구현되는데, 이는 들어오는 텍스트를 저장된 쿼리 집합과 대조하는 패턴을 위해 특별히 만들어졌습니다. 이 시리즈의 4부에서는 퍼콜레이터 구현에 대한 실습적인 심층 분석을 제공하며, 인덱스 매핑, 경계 마커 및 하이라이트 기반 구문 추적을 다룹니다. 4부에서 조회 메커니즘을 심층적으로 살펴보고, 여기에서는 정책 문서가 실제로 어떤 내용을 포함하고 있으며 제어 평면이 여러 정책을 하나의 실행 계획으로 어떻게 구성하는지 살펴보겠습니다.

정책 예시

정책이 개념적으로 어떤 역할을 하는지 살펴보았으니, 실제로 어떤 내용을 포함하고 있는지 살펴보겠습니다. 아래 두 정책은 의도적으로 충돌하도록 설계되었으며, 이는 다음 섹션에서 설명하는 충돌 해결 시스템을 보여줍니다.

저렴한 초콜릿

아래에 제시된 정책은 사용자가 "cheap chocolate"이라는 구문이 포함된 검색어를 입력했는지 여부를 감지합니다. 입력하면 결과는 "Chocolates" 및 "Milk chocolates" 카테고리로 제한됩니다. 이 정책은 또한 $2의 가격 필터를 적용합니다. 또한 정책의 우선순위가 210임을 주목하세요. 충돌 해결에 대해 더 자세히 논의할 때 다시 언급하겠습니다.

여기에 표시된 필터 모드 및 충돌 전략 설정(hard_filter, soft_boost, restrict, override)은 아래의 충돌 해결 섹션에서 자세히 설명합니다.

위 정책이 활성화되면 "cheap chocolate" 검색 시 $2 가격 필터가 적용되어 결과가 "Chocolates" 및 "Milk chocolates" 카테고리로 제한됩니다. 결과 예시는 아래와 같습니다.

크리스마스 초콜릿

아래에 표시된 정책은 크리스마스에 적용할 수 있는 정책의 예입니다. 이 예시는 결과를 "Christmas foods and drinks" 및 "Christmas sweets"로 제한하고, "Advent calendars" 카테고리에도 속하는 제품을 상위 노출하며, 가격 필터를 $7 미만으로 적용하여 저렴한 시즌 상품에 초점을 맞춥니다. 또한 이 정책의 우선순위가 300임을 주목하세요. 충돌 해결에 대해 더 자세히 논할 때 다시 다루겠습니다.

위의 정책이 다른 충돌 정책 없이 활성화된 경우, "초콜릿" 검색 시 $7 가격 필터가 적용되어 "Christmas food and drinks"와 "Christmas sweets" 카테고리의 결과만 표시되고, "Advent calendars"로 태그된 제품의 검색 결과 순위가 높아집니다. 결과 예시는 아래와 같습니다.

매칭된 정책 결합

위에서 설명한 정책 조회는 전체 중 절반에 해당합니다. 나머지 절반의 상황은 여러 정책이 동일한 쿼리와 일치하는 경우에 해당합니다.

복잡한 배포 환경에서는 단일 쿼리가 여러 정책을 동시에 실행하는 경우가 흔합니다. "Cheap chocolate"은 위에서 설명한 두 가지 정책 모두와 일치할 것입니다. 각각은 개별적으로 올바른 정책입니다. 문제는 이들을 충돌 없이, 이중 계산 없이, 그리고 한 정책이 다른 정책의 작업을 무효화하지 않으면서 단일하고 일관된 실행 계획으로 구성하는 것입니다.

이것은 조회 문제가 아니라 판단 문제입니다. 시스템은 다음과 같은 결정을 내려야 합니다:

• 적용 순서: 부정 정책이 쿼리에서 "without peanuts"를 제거하는 경우, 가격 정책은 여전히 원본 텍스트를 확인할까요, 아니면 수정된 텍스트를 활인할까요?

• 필터 충돌: 두 정책이 서로 다른 가격 상한선을 설정하는 경우 어느 정책이 우선할까요? 나머지 정책은 완전히 중단될까요, 아니면 점진적으로 부드러운 부스트로 강등될까요?

• 구문 소유권: 두 정책이 동일한 단어에서 모두 일치하고 첫 번째 정책이 이미 이 단어를 사용한 경우, 두 번째 정책을 여전히 실행해야 할까요?

단순하게 구현하면(모든 매칭된 정책을 독립적으로 적용하고 결과를 병합하는 방식) 정책이 상호작용하는 순간 실패합니다. 아키텍처는 정책이 어떻게 구성되는지에 대한 명시적인 모델이 필요합니다. 다음 두 섹션은 바로 이러한 모델을 설명합니다. 우선순위 및 충돌 해결 프레임워크와 정책 상호작용을 결정론적으로 만드는 연쇄적 변환 모델입니다.

핵심 인사이트는 정책 적용이 독립적인 작업의 집합이 아니라 연쇄적인 변환 과정이라는 점입니다. 각 정책은 우선순위가 높은 모든 정책에서 생성된 재작성 상태를 받아 이를 추가로 변환합니다.

초기 상태 → [정책 A] → 상태' → [정책 B] → 상태'' → ... → 실행 계획

상태는 다시 작성된 쿼리 텍스트, 누적된 필터, 현재 의도 및 동의어 확장을 포함합니다. 우선순위가 높은 정책은 쿼리에서 텍스트를 제거할 수 있으며, 이후의 모든 정책은 원본이 아닌 수정된 쿼리를 보게 됩니다. 컨텍스트는 누적됩니다. 순서가 중요합니다.

우선순위와 충돌 해결: 결정론의 중요성

구체적인 충돌 전략은 설계 선택 사항입니다. 서로 다른 조직은 비즈니스 요구 사항에 따라 충돌을 다르게 해결할 수 있습니다. 다음 접근 방식은 제어 평면에 필요한 판단 프레임워크의 유형을 보여줍니다. 중요한 것은 이러한 구체적인 전략이 아닙니다. 시스템이 예측할 수 없는 상호작용을 통해 충돌을 해결하는 것이 아니라 명시적이고 결정적인 전략을 가지고 있다는 것입니다.

우선순위 정렬

정책은 우선순위(가장 높은 것부터)에 따라 정렬됩니다. 여러 정책이 동일한 쿼리와 일치하는 경우 우선순위에 따라 적용됩니다. 두 정책이 동일한 필터 필드를 설정하려고 하면, 우선순위가 더 높은 정책이 해당 필드에 대해 선언한 전략이 우선 적용됩니다. 동일한 우선순위를 가진 여러 정책이 트리거될 경우, ID가 가장 높은 정책이 우선권을 갖습니다(더 높은 우선순위가 할당된 것과 같음). 이러한 선택은 충돌이 발생할 때 결정론적 동작을 보장합니다.

정책별이 아닌 필드별 해결

핵심 설계 원칙: 충돌 해결은 정책 단위가 아닌 필드 단위(예: 브랜드, 카테고리, 설명)로 이루어집니다. 두 정책이 특정 필드에서 겹치는 필터를 생성할 때, 해당 특정 필드만 충돌 해결 전략의 영향을 받으며 해결 전략은 최우선 일치 정책에 의해 정의됩니다. 두 정책에서 서로 충돌하지 않는 필드는 그대로 유지됩니다.

이것이 중요한 이유는 정책별 접근 방식을 채택할 경우 필드 중 하나만 충돌할 때 시스템이 전체 정책을 수락하거나 거부하도록 강요하기 때문입니다.

필드별 해결은 유용한 제약 조건 정보를 최대한 많이 보존합니다.

필터 필드별 3가지 설정

정책의 각 필터 필드에는 3가지 독립적인 설정이 있습니다.

필터 모드: 충돌이 없을 때 필터가 적용되는 방식입니다.

• hard_filter (기본값): Elasticsearch bool.filter 절로 적용됩니다. 관련 없는 제품을 완전히 제외하는 데 유용합니다. 예를 들어, "oranges" 검색을 농산물 카테고리로 제한하면 오렌지 주스나 오렌지 마멀레이드와 같은 결과가 제거됩니다. 일치하지 않는 문서는 결과에서 완전히 제외됩니다.

• soft_boost: Elasticsearch function_score 가중치로 적용되며 구성 가능한 boost_weight를 사용합니다. 일치하는 문서는 순위가 상승하지만, 일치하지 않는 문서는 제외되지 않습니다. 이는 다른 브랜드를 배제하지 않고 특정 브랜드를 홍보하는 등의 작업에 유용합니다.

충돌 전략

우선순위가 낮은 정책이 동일한 필드를 설정할 경우:

• override: 이 높은 우선순위 정책의 값이 적용되며, 낮은 우선순위 값은 완전히 삭제됩니다. 모든 필드 유형에 적용됩니다.

• restrict: 보다 제한적인 숫자 값을 사용합니다(예: price__max, the higher floor for price__min의 하한). 숫자 범위 필드에만 적용됩니다.

• merge: 두 값을 합집합으로 결합합니다. 숫자 이외의 필드에만 적용됩니다.

• soft_boost: 충돌하는 필터를 하드 필터 대신 구성 가능한 boost_weight 를 사용하여 function_score 가중치로 변환합니다. function_score 부스트에 대한 자세한 내용은 Elasticsearch에서 곱셈 기반 부스트로 BM25 순위에 영향 미치기를 참조하세요. 이는 부정이 아닌 필드에만 적용됩니다.

값: 실제 필터 값입니다(예: 카테고리 목록, 가격 임계값).

필드 유형별 전략: 모든 전략이 모든 필드 유형에 적합한 것은 아닙니다. 예를 들어, 제외는 본질적으로 이진이므로 소프트 부스트될 수 없습니다. 다음 표는 각 필드 유형에 사용할 수 있는 전략을 보여줍니다.

필드 유형

사용 가능한 전략

기본값

부정 필드 (__not, __match__not)

재정의, 병합

override

숫자 범위 필드(__max, __min, __gt, __lt)

제한, 재정의, soft_boost

restrict

기타 모든 필드(키워드, 텍스트)

soft_boost, override, merge

soft_boost

제외가 이진이므로 부정 필드는 소프트 부스트할 수 없습니다. "never show canned foods"를 "slightly prefer not-canned-foods"로 변환하는 것은 기본적으로 시맨틱을 변경합니다. "canned foods" 제품은 여전히 나타나지만 순위가 조금 낮아질 뿐이므로 제외의 목적을 달성하지 못합니다.

구체적인 예: 크리스마스 캠페인 기간에 "cheap chocolate"을 검색하는 경우

상품 판매자가 앞에서 보여준 두 가지 초콜릿 정책을 만들었다고 가정합시다. 하나는 저렴한 초콜릿에 대한 낮은 우선순위 정책이고, 다른 하나는 크리스마스 기간에 활성화될 더 높은 우선순위의 초콜릿 관련 정책입니다. 이 두 정책이 모두 활성화된 경우, 이들의 결합 방식은 상위 우선순위 정책의 필터 모드와 충돌 전략에 따라 달라집니다. 앞서 논의한 두 정책이 모두 활성화된 경우, 다음과 같이 결합됩니다.

이 결과는 카테고리와 가격에 관한 두 가지 충돌을 보여줍니다. 이 변환 후에 실행될 쿼리는 다음과 같은 특징을 가진다는 점도 주목할 만합니다.

• "Christmas foods and drinks"와 "Christmas sweets" 카테고리의 제품만 표시됩니다.

• 해당 카테고리 내에서 제품이 "Advent calendars" 카테고리로도 태그되어 있으면, 해당 제품은 3배로 부스트됩니다.

• $2의 가격 필터가 적용됩니다. 이는 하위 우선순위 정책에서 비롯된 것입니다(상위 우선순위 정책이 충돌 시 "제한"으로 지정되었기 때문입니다).

• "cheap"이라는 단어는 제외되고, "chocolate"과 일치하는 제품만 반환됩니다.

두 정책이 모두 활성화된 경우, "cheap chocolate"은 아래 이미지와 유사한 결과를 반환합니다.

제약 조건 완화

소매업체는 크리스마스 동안 "Chocolates"과 "Milk chocolates" 카테고리의 제품을 제외하고 싶지 않을 것입니다. 크리스마스 정책의 설정이 지나치게 확대되어 "cheap chocolate" 정책으로 적용된 카테고리를 의도하지 않게 제거했을 수 있습니다. 이는 낮은 우선순위 정책을 더 높은 우선순위의 충돌하는 정책과 결합하는 것이 더 바람직할 수 있는 이유를 보여주는 예입니다. 예를 들어, 충돌 시 "재정의" 대신 소프트 부스트를 적용하도록 크리스마스 초콜릿 프로모션을 수정할 수 있습니다. 이 정책을 변경한 결과는 다음과 같습니다.

이 수정 후, "cheap chocolate"에 대한 쿼리 재작성기 변환 파이프라인 실행은 다음과 같이 이루어집니다.

충돌 시 소프트 부스트를 사용하면 충돌하는 필터가 삭제되지 않고 소프트 부스트로 변환됩니다. 이 변환 후 제품 카탈로그에서 실행되는 쿼리는 다음과 같은 특징이 있습니다.

• 우선순위가 더 높은 정책에서 "충돌 시"가 "소프트 부스트"로 지정되어 있으므로, 충돌은 다음과 같이 부스트로 변환됩니다.

  • "Christmas foods and drinks" 및 "Christmas sweets" 카테고리의 제품에는 1배의 부스트가 적용됩니다.

  • "Chocolates" 및 "Milk chocolates" 카테고리의 제품에는 3배의 부스트가 적용됩니다.

• 이전 예시와 마찬가지로, 제품이 "Advent calendars" 카테고리로도 태그되어 있으면, 해당 제품은 3배로 부스트됩니다.

• 이전 예시에서와 마찬가지로 $2에 대한 가격 필터가 적용됩니다.

• "cheap"이라는 단어는 제외되고, "chocolate"과 일치하는 제품만 반환됩니다.

필터링이 완화된 상태에서 결과는 다음과 같습니다:

우선순위가 높은 정책의 가격 재정의

소매업체가 크리스마스 기간에 약간 더 비싼 초콜릿을 표시하기 위해 최대 가격을 $7로 올리려고 할 수 있습니다. "cheap chocolates"를 검색하는 사람이 있을 경우 크리스마스 초콜릿 정책의 최대 가격이 무시되지 않도록 하기 위해 가격에 대한 충돌 모드를 다음과 같이 "제한"이 아닌 "재정의"로 설정할 수 있습니다.

이 재정의 설정으로 "cheap chocolate"에 대한 쿼리는 "cheap chocolate policy"에 정의된 최대 가격을 무시하고 "Christmas chocolates" 정책에 지정된 가격만 적용합니다.

이전 예시와 유사하지만, 더 높은 우선순위 정책에서 충돌 시 "재정의"가 지정되어 있으므로 최대 가격이 이 정책의 값 $7로 설정된다는 차이가 있습니다. 크리스마스 가격 필터가 우선적으로 적용되어 결과는 다음과 같습니다.

이 세 가지 변형(재정의, 소프트 부스트, 가격 재정의)은 시스템의 핵심 속성을 보여줍니다. 판매자는 코드를 배포하지 않고도 단일 정책 내의 단일 필드 설정을 수정하여 두 정책의 상호작용 방식을 변경할 수 있다는 것입니다. 충돌 전략은 비즈니스 행동을 제어하는 핵심 수단입니다.

사용된 구문 추적

좀 더 미묘한 형태의 충돌이 있습니다. 동일한 구문에 두 가지 정책이 일치하는 경우입니다. 우선순위가 더 높은 정책이 쿼리에서 "without peanuts"를 제거하면, 우선순위가 낮은 정책은 "without"에 일치해도 적용할 대상이 남지 않습니다. 시스템은 재작성된 쿼리에 매칭된 구문이 더 이상 존재하지 않는지 감지하고 낮은 우선순위 정책을 건너뛸 수 있습니다.

의도 정책은 사용된 구문 추적에서 제외됩니다. 이 정책은 더 높은 우선순위 정책으로 제거된 텍스트와 관계없이 원래 쿼리 일치를 기반으로 검색 전략을 설정합니다.

우선순위 지정, 필드별 충돌 해결, 사용된 구문 추적 기능은 함께 작동하여 제어 평면에 결정론적 구성 모델을 제공합니다. 이 기반이 마련되면 시스템은 라우팅 결정을 내릴 수 있으며, 이러한 기반이 없다면 위험이 커질 수 있습니다.

거버넌스를 통해 안전해지는 검색 전략

올바른 검색 방법(텍스트, 시맨틱 또는 하이브리드)으로 라우팅하는 것과 관련된 중요한 인사이트는 이것이 거버넌스 이후에 실행된다는 점입니다. 정책에서 이미 "produce category"를 적용했다면 후보 집합이 제한되어 있기 때문에 시맨틱 검색의 위험이 더 적습니다. 제품 500개 이상에 대한 시맨틱 검색은 500,000개 이상의 SKU에 대한 시맨틱 검색과는 매우 다른 문제입니다. 거버넌스는 검색이 시작되기 전에 영향 범위를 좁힙니다.

예를 들어, 거버넌스가 없다면, "Fruit high in vitamin C under $4"에 대한 시맨틱 쿼리는 과일 외에도 비타민 병, 당근, 그리고 피망을 반환할 수 있습니다. 제어 평면은 이러한 원치 않는 결과가 시맨틱 확장의 일부로 고려되지 않도록 합니다.

이러한 제약 조건이 적용되면, 제어 평면은 실용적인 라우팅 논리를 적용합니다.

• 어휘 - 결정론적 정밀도가 중요한 탐색 및 헤드 쿼리용입니다.

• 시맨틱 - 개념 매칭이 도움이 되는 설명적 검색 쿼리용입니다.

• 하이브리드 - 이미 제약 조건이 적용되고 비즈니스가 광범위한 리콜을 허용하는 경우 선택적으로 사용됩니다.

아키텍처에서 구현까지

거버넌스 기반 제어 평면은 비즈니스 의도를 결정론적이고 조합 가능한 실행 계획으로 변환하지만, 해당 논리를 애플리케이션 코드에 내장하지는 않습니다. 정책은 데이터입니다. 쿼리 시점에 매칭되고, 명시적인 필드별 충돌 전략을 통해 해결되며, 설명 가능한 결과를 생성하는 연쇄적 변환으로 적용됩니다. Elastic Services Engineering은 반복 가능한 패턴과 개념에서 프로덕션까지의 경로를 압축하는 액셀러레이터를 사용하여 엔터프라이즈 전자 상거래 팀을 위한 이러한 아키텍처를 구축하고 배포했습니다. 제어 평면 구현 데모는 YouTube 몇 초 만에 검색 관련성 수정: PRISM 소개에서 확인할 수 있습니다.

이 시리즈의 다음 내용

다음 게시물에서는 구현에 대해 실질적으로 다룹니다. Elasticsearch 퍼콜레이터가 정책 조회를 어떻게 지원하는지 설명하고, 인덱스 매핑, 경계 마커, 하이라이트 기반 구문 추적, 구체적인 쿼리 예제 등을 다룹니다.

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

본 게시물에 설명된 제어 평면 아키텍처(필드별 충돌 해결, 연쇄적 정책 변환 및 거버넌스 제약 검색 라우팅)는 Elastic Services Engineering에서 설계 및 구축했습니다. 이 시리즈에 나오는 모든 패턴, 스크린샷 및 변환 파이프라인은 Elastic Services Engineering이 구축하고 엔터프라이즈 규모의 제품 카탈로그에 대해 검증된 작동 시스템에서 가져온 것입니다.

Elasticsearch에서 관리되는 정책 중심 제어 평면을 구현하려는 경우, Elastic 서비스를 통해 더 빠르게 구현할 수 있습니다.

논의에 참여하기

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

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

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

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

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

• 쿼리 의도 분류: 이 검색이 목적형('오렌지')인가요, 아니면 발견형('할아버지를 위한 선물')인가요?

• 비즈니스 제약 조건 적용: 어떤 카테고리 경계, 적격성 규칙, 재고 가용성 제약, 또는 머천다이징 정책을 적용해야 할까요?

• 적절한 전략으로 가는 방법: 어휘 검색, 의미 검색, 하이브리드 중 어떤 것을 사용해야 할까요?

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

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

현재 많은 소매 업체에서 이 문제를 해결하기 위해 애플리케이션 계층에 직접 로직을 추가하려고 시도합니다. 이로 인해 종종 하드코딩된 수천 줄의 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. 적절한 검색 전략으로 라우팅

• 목적형/고의도 헤드 쿼리를 위한 어휘(빠르고 확정적)입니다.

• 진정한 발견형 쿼리를 위한 의미 검색입니다.

• 명시적인 비즈니스 제약 조건하에, 어휘 및 의미 신호를 결합하여 가치를 더하는 하이브리드 방식입니다.

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

쇼핑객 쿼리

거버넌스 기반 해석

검색 계획 예시

'땅콩 없는 초콜릿'

엄격한 배제 제약 조건을 포함한 제품 지향 쿼리

초콜릿에 대한 어휘 검색 수행 및 땅콩 포함 제품 제외 필터 적용

“저렴한 올리브 오일”

가격 제약 조건이 있는 제품/카테고리 쿼리

올리브 오일에 대한 어휘 검색 및 소매 업체가 설정한 저가 기준에 맞춘 가격 필터 적용

'4달러 미만의 비타민 C 함량이 높은 과일'

의미 이해와 엄격한 제약 조건이 동시에 요구되는 발견형 쿼리

영양학적 의도에 대한 의미 검색을 수행하되, 카테고리는 과일로 제한하고 가격은 4달러 미만인 상품으로 필터링

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

다른 접근 방식과의 관계

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

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

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

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

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

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

이 시리즈의 다음 내용

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

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

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

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

논의에 참여하기

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