전자 상거래 검색을 관리하기 위한 제어 평면 구축

이 시리즈의 1부와 2부는 전자 상거래 검색에 거버넌스 계층이 필요한 이유를 설명했습니다. 이 계층은 사용자의 쿼리와 검색 엔진 사이의 의사결정 계층으로, 의도를 분류하고 제약 사항을 적용하며 올바른 검색 전략(예: BM25, 시맨틱, 하이브리드)으로 가는 경로를 제공합니다. 이 게시글에서는 쿼리 해석 정책이 문서로 저장되고 쿼리 시점에 빠른 역방향 매칭을 통해 검색되는 간단한 구조적 원시 요소를 사용하여 이러한 계층을 구축하는 방법을 보여줍니다. 새로운 검색 정책(예: "브랜드 X 강화" 또는 "카테고리 Y만 표시")이 코드 변경을 필요로 하지 않기 때문에, 결과적으로 정책이 진화하는 동안 라우팅 계층이 안정적으로 유지되고, 이는 고위험 환경에서 검색 엔진을 안전하게 유지합니다. 더 읽기 전에 이 아키텍처의 최종 결과를 보고 싶다면, 몇 초 만에 검색 관련성 수정: PRISM 소개 동영상을 확인하세요.

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

정책을 코드(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 순위에 영향 미치기를 참조하세요. 이는 부정이 아닌 필드에만 적용됩니다.

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

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

제외가 이진이므로 부정 필드는 소프트 부스트할 수 없습니다. "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 커뮤니티 대화에 참여하세요.