안전한 쿼리 실행을 위한 Elasticsearch의 결정론적 가드레일을 사용한 에이전틱 AI 검색

이 시리즈의 1부에서 7부까지는 전자상거래 검색을 위한 관리형 제어 평면을 설명했습니다. 사용자가 쿼리를 입력합니다. 제어 평면은 상품 카탈로그를 쿼리하기 전 단계에서 검색 의도를 분류하고 비즈니스 제약 조건을 적용하며, 정책 충돌을 해결하고 적절한 검색 전략으로 라우팅합니다. 전체 아키텍처는 사람이 직접 입력한 검색 문자열을 입력값으로 가진다는 가정하에 설계되었습니다.

이 마지막 게시물에서는 다음과 같은 질문을 던집니다. 대신 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 커뮤니티 대화에 참여하세요.