본문 바로가기

AI - 검색의 여정/Step 1 - 준비

🏷️ 메타데이터 필터링: 더 똑똑한 AI 검색을 만드는 비밀

검색은 어떻게 똑똑해질까?
AI 검색의 정확도를 높이고 비용을 줄이는 핵심 원리

 

 

이 섹션에서는 

검색 시스템이 사용자의 질문에 대한 

답변을 찾아가는 전체 여정을 살펴봅니다. 

 


 

우리는 이미 방대한 원본 문서를 잘게 나누는 '청킹(Chunking)'의 중요성을 알고 있습니다. 

https://u-so-pretty.tistory.com/8

 

✂️ 검색 품질의 첫 단추: '청킹(Chunking)' 완벽 이해하기

문서를 임베딩(벡터화)과 검색에 알맞은 크기로 나눠, AI 검색이 제대로 작동하도록 데이터를 준비하는 출발점 벡터 검색(의미 검색)은 보통 문서 전체가 아니라, **문서를 쪼갠 '청크 단위'**로

u-so-pretty.tistory.com

 

이제 그 다음 단계로, 

검색의 효율과 정확도를 극적으로 끌어올리는 **'메타데이터 필터링'**이 

왜 필수적인지 그 맥락을 짚어보겠습니다.


검색 답변 생성 프로세스

[원본 문서] → [청킹] → [🧩청크 + 🏷️메타데이터] → [검색(키워드/의미)] → [필터로 범위 좁히기] → [답변]

 

청킹을 통해 문서를 잘게 나누면, 

검색 시스템이 살펴봐야 할 대상(청크)의 수가 

폭발적으로 늘어납니다. 

 

이 수많은 청크 조각들 속에서 무작정 정답을 찾으려고 하면, 

엉뚱한 결과를 내거나 너무 많은 컴퓨터 자원을 소모하게 됩니다. 

 

따라서 그 다음 단계로, 

**관련성이 높은 후보군만 남도록 '범위를 효율적으로 좁히는 것'**이 

매우 중요해집니다.

이 '범위 좁히기'의 핵심 도구가 바로 메타데이터입니다. 

다음 섹션에서 메타데이터의 개념을 자세히 알아보겠습니다.


🏷️ 메타데이터란?

 

메타데이터는

본문 내용 자체가 아니라 **"문서를 설명하는 꼬리표(라벨)"**입니다. 

 

예를 들어, 작성자: 홍길동, 작성일: 2024-10-26 과 같은 정보가 바로 메타데이터입니다.

'작성자'라는 꼬리표 이름(Key)에 '홍길동'이라는 실제 값(Value)을 붙이는 것과 같이,

항상 '이름'과 '값'이 쌍으로 이루어진 구조입니다.

 

메타데이터에는 다음과 같은 구체적인 예시들이 있습니다.

  • 출처 (Source): 문서가 어디에서 왔는지 나타냅니다. (예: docs.example.com/guides)
  • 작성 날짜 (Date): 문서가 생성되거나 수정된 날짜입니다. (예: 2024-10-26)
  • 문서 종류 (Category): 문서의 성격을 구분합니다. (예: FAQ, 가이드, 공지사항)
  • 작성자 (Author): 문서를 작성한 개인 또는 팀을 명시합니다. (예: 기술문서팀)
  • 접근 권한 (Permission): 문서의 공개 범위를 설정합니다. (예: 전체 공개, 팀 내부)
  • 버전 정보 (Version): 특정 제품이나 서비스의 버전을 나타냅니다. (예: v2.1)

❓ 그렇다면 이 꼬리표는 왜 필요할까요 ❓ 


🔍 왜 메타데이터가 필요할까?

메타데이터는 

단순히 정보를 추가하는 것을 넘어, 

검색 시스템의 성능과 효율성을 극적으로 향상시키는 

세 가지 핵심적인 이유가 있습니다.

 

1. 정확도 향상: 관련 없는 정보 미리 제거하기

메타데이터를 사용하면, 검색을 시작하기도 전에 관련 없는 문서들을 미리 제외할 수 있습니다. 

예를 들어 사용자가 "최신 업데이트"에 대해 물었을 때, 
작성 날짜 메타데이터를 이용해 최근 1개월 내 문서들만 검색 대상으로 삼는 것입니다. 

이는 Elasticsearch에서 'filter context'가 점수 계산 없이 
'반드시 포함해야 할(must have)' 조건을 적용하는 것과 같은 원리로, 
처음부터 정답이 있을 만한 곳에만 집중하게 해 정확도를 높입니다.

 

2. 비용 절감: 불필요한 계산량 줄이기

수천, 수만 개의 청크 전체를 대상으로 복잡한 계산을 하는 것은 비효율적입니다.

메타데이터 필터는 검색 후보의 수를 수백 개 수준으로 줄여, 계산량을 획기적으로 감소시킵니다.
OpenSearch 문서에서 강조하듯, 특히 계산 비용이 큰 벡터 검색(k-NN)과 같은 기술에서 이 장점은 더욱 두드러집니다.

* 물론 필터가 덜 제한적이라 통과하는 문서(청크)가 너무 많으면,
   '먼저 거르기'로 얻는 비용 절감 이점이 줄어들 수 있습니다.
   이런 경우에는 필터가 실제로 후보군을 충분히 줄이는지 먼저 확인하는 편이 안전합니다.

 

3. 신뢰도 확보: 답변의 근거 제시하기

사용자는 "왜 이 결과가 나왔는지" 궁금해할 수 있습니다.
메타데이터는 이 질문에 대한 명확한 답변을 제공합니다.

예를 들어, "이 답변은 최신 '릴리즈 노트' 카테고리의 문서에서 찾았기 때문에 신뢰할 수 있습니다" 와 같이
답변의 출처와 근거를 명확히 제시할 수 있어 검색 결과에 대한 신뢰도를 높여줍니다.

 

메타데이터의 필요성을 이해했으니, 

이제 어떤 종류의 메타데이터를 붙여야 할까요 ❓ 


🏷️ 어떤 메타데이터를 붙여야 할까?

이론적인 개념을 넘어, 

실제 서비스에서 필터링에 매우 유용하게 사용되는 

7가지 실용적인 메타데이터 유형을 소개합니다.

 

  1. 시간 정보 (날짜/기간):
       "최신 정보를 보여줘야 할 때 유용해요." (예: Pinecone의 year, Weaviate의 DATE 타입)
  2. 출처 정보 (도메인/채널):
       "특정 웹사이트나 팀의 자료만 보고 싶을 때 유용해요." (예: source: "engineering_blog")
  3. 문서 종류 (가이드/FAQ/릴리즈노트):
       "사용법이 궁금할 땐 '가이드' 문서만 검색하고 싶을 때 유용해요." (예: category: "guide")
  4. 주제 카테고리 (태그):
       "특정 주제와 관련된 모든 문서를 한 번에 찾고 싶을 때 유용해요." (예: Pinecone의 genre: "documentary")
  5. 제품/버전/환경 정보 (prod/dev):
       "특정 버전의 제품 설명서만 찾아야 할 때 유용해요." (예: version: "v3.5")
  6. 권한/공개 범위 (public/internal/team):
       "팀 내부 문서만 안전하게 검색해야 할 때 유용해요.
       (예: LlamaIndex 문서에서 여러 사용자 그룹이 같은 시스템을 쓸 때
             데이터를 격리하는 '멀티테넌시'를 구현하는 핵심 기술로 메타데이터 필터링을 제시합니다.)"
  7. 언어/지역 정보:
       "한국어 사용자에게는 한국어 문서만 보여줘야 할 때 유용해요." (예: lang: "ko")

유용한 메타데이터의 종류를 알았으니, 

이제 이것들을 어떻게 잘 설계할 수 있는지 

그 원칙을 살펴보겠습니다.


🧱 설계 원칙 5가지

효과적인 🏷️ 메타데이터 시스템 🏷️을 구축하기 위해

반드시 기억해야 할 5가지 핵심 설계 원칙입니다.

 

이 원칙들은 시스템을 안정적이고 확장 가능하게 만듭니다.

 

  • 원칙 1: 필터는 점수 계산 없이 '정확한 일치(Exact Match)'에 사용합니다
필터의 역할은 관련도를 점수로 매기는 것이 아니라 '맞다/아니다'만 판단하는 것입니다.

Elasticsearch의 'filter context'처럼 점수 계산 없이 빠르고 명확하게 범위를 좁히는 작업에 적합합니다.

예를 들어 Pinecone에서는 $eq(정확히 일치)나 $in(목록 중 하나와 일치) 같은 연산자를 사용해
점수 계산 없이 대상을 빠르게 필터링합니다.

 

  • 원칙 2: 메타데이터 값은 '단순하고 안정적인 형태'로 유지합니다
카테고리나 태그 값이 너무 자주 바뀌거나, ["개발", "서버", "인프라"]처럼 복잡한 구조를 가지면
관리가 어렵고 필터링 성능도 저하될 수 있습니다.

category: "server"처럼 단순하고 표준화된 값을 사용하는 것이 좋습니다.

 

  • 원칙 3: 문서의 꼬리표는 청크에게 '상속'시킵니다
원본 문서가 가진 출처, 날짜, 카테고리 같은 중요한 메타데이터
그 문서에서 잘라낸 모든 청크 조각에도 똑같이 복사해서 붙여줘야 합니다.

그래야 어떤 청크가 검색되더라도 원본의 맥락 정보를 잃지 않고 필터링에 활용할 수 있습니다.

 

  • 원칙 4태그는 너무 자유롭게 늘리지 마세요
사용자나 부서별로 태그를 자유롭게 만들게 허용하면,
순식간에 수백, 수천 개의 태그가 생겨나 관리가 불가능해집니다.

이는 오히려 필터로 쓰기 어렵게 만듭니다.
사전에 정의된 목록을 사용하거나, 태그 생성에 대한 명확한 규칙을 두어야 합니다.

 

  • 원칙 5: 시간 필터는 거의 항상 준비해두세요
Weaviate, Elasticsearch 등 대부분의 검색 시스템에서 날짜/시간 필터는 매우 중요하게 다뤄집니다.

최신 정보를 우선적으로 보여주거나, 특정 기간의 자료만 조회하는 기능은
거의 모든 서비스에서 요구되는 핵심 기능이므로 반드시 포함하는 것이 좋습니다.

 

그럼 이 필터는 검색 과정 중 언제 사용하는 게 가장 좋을까요 ❓


⚖️ 언제 필터를 걸어야 할까

필터를 적용하는 시점에 따라 검색 효율이 크게 달라질 수 있습니다. 

'먼저 거르기(Pre-filter)'와 '나중에 거르기(Post-filter)' 두 가지 방식을 

도서관 비유를 통해 알아보겠습니다.

 

  • 먼저 거르기 (Pre-filter): 
이는 **'도서관에 들어가자마자 '어린이 코너'로 직행해서 책을 찾는 것'**과 같습니다.
검색할 범위를 처음부터 확 줄여놓고 시작하는 방식입니다.

OpenSearch의 'Scoring script filter'가 이 개념에 해당하며, 검색 대상 자체를 줄여놓고 시작합니다.

애초에 검색 대상이 '어린이 코너'의 책들로 한정되므로, 컴퓨터가 살펴봐야 할 책의 총량이 줄어듭니다.

 

  • 나중에 거르기 (Post-filter):
이는 **'도서관의 모든 책을 일단 다 꺼내 본 뒤, 그 중에서 어린이 책을 골라내는 것'**과 같습니다.

일단 전체를 대상으로 검색을 수행한 후, 얻어진 결과물 중에서 조건에 맞는 것만 남기는 방식입니다.

OpenSearch의 'Boolean post-filter'가 이 방식을 사용합니다.

컴퓨터는 일단 도서관의 '모든' 책을 다 살펴본 후에야 어린이 책을 골라내므로, 계산 부담이 더 클 수 있습니다.

 

특히 벡터 검색처럼 계산량이 많은 경우에는,

검색 대상을 '먼저 거르기'로 좁혀주는 것이

컴퓨터의 부담을 덜어줘서 더 빠를 수 있습니다.

 

무거운 검색을 하기 전에 후보군을 최대한 줄여주는 것이 효율적이기 때문입니다.


개념을 배웠으니, 이제 내 서비스에 맞는 메타데이터를 직접 찾아보는 실험 방법을 알아보겠습니다.


🧪 "내 서비스에 맞는 메타데이터" 찾는 방법

모든 서비스에 완벽한 정답은 없습니다.

간단한 실험을 통해 우리 서비스에 가장 효과적인 메타데이터를 찾아내는

실용적인 방법을 소개합니다.


간단한 4단계 실험 방법

  1. 사용자 로그 또는 예상 질문 분석:
       먼저 "사용자들이 주로 어떤 기준으로 정보를 찾으려 할까?"를 고민합니다.
       최신순, 특정 제품 버전, 특정 문서 종류 등 사용자가 원할 만한 필터 기준에 대한 가설을 세웁니다.
  2. 가설 검증용 질문 5개 준비:
       위 가설을 검증할 수 있는 똑같은 질문 5개를 준비합니다.
       (예: "가장 최신 버전의 설치 방법은?")
  3. 결과 비교:
       필터를 사용하지 않고 검색한 결과와, '출처(예: 가이드 문서)'나 '기간(예: 최근 6개월)' 같은
       가설 기반의 필터를 적용하고 검색한 결과를 비교합니다.
  4. 효과 측정:
       두 결과의 관련성, 불필요한 정보(노이즈)의 양,
       그리고 답변이 나오는 속도를 눈으로 직접 비교해봅니다.

"검색이 좋아졌는지" 판단하는 3가지 관점

  • 정확성: 내가 원했던 답변이 잘 나오는가?
  • 일관성: 비슷한 질문에 비슷하게 좋은 답변이 나오는가?
  • 운영 난이도: 이 메타데이터(특히 태그)를 앞으로 계속 관리하는 게 어렵지 않은가?

 

실험을 통해 우리에게 맞는 메타데이터를 찾았다면, 

최종적으로 점검해볼 체크리스트를 살펴보겠습니다.


✅ 메타데이터 설계 체크리스트

지금까지 논의한 내용을 바탕으로,

메타데이터 설계를 마친 후 스스로 점검해볼 수 있는 8가지 핵심 질문입니다.

 

  1. 문서와 청크에 어떤 메타데이터를 붙일지 정해졌는가?
  2. 가장 기본이 되는 시간, 출처, 권한 정보는 포함되었는가?
  3. 필터 값에 대한 표준(예: 정해진 카테고리 목록)이 있는가?
  4. 태그가 너무 많아지는 것을 막을 규칙이 있는가?
  5. 문서의 메타데이터가 청크에 잘 상속(복사)되도록 만들었는가?
  6. 필터를 적용했을 때 검색 품질이 실제로 더 좋아지는가?
  7. 메타데이터를 추가하거나 바꿀 때관리 비용을 감당할 수 있는가?
  8. 미리 준비한 평가 질문들로 성능을 확인했는가?

 

검색 시스템의 성능을 좌우하는 숨은 주인공

 

메타데이터는 단순히 정보를 추가하는 것을 넘어, 

검색의 정확도, 속도, 신뢰도를 모두 향상시키는 강력한 도구입니다.

 

청킹이 요리를 위해 재료를 잘게 썰어놓는 과정이라면, 

메타데이터는 그 재료마다 '돼지고기', '유통기한: 3일' 같은 

라벨을 붙여주는 것과 같습니다. 

 

어떤 재료를 언제, 어떻게 사용해야 할지 알려주는 이 라벨 덕분에 

우리는 더 빠르고 정확하게 훌륭한 요리(답변)를 완성할 수 있습니다. 

 

결국 잘 설계된 메타데이터는 단순히 검색 품질을 높이는 것을 넘어, 

사용자에게는 신뢰를, 시스템에게는 효율을, 

그리고 개발팀에게는 운영의 용이성을 선물합니다.


요약의 레퍼런스: 

https://developers.llamaindex.ai/typescript/framework/modules/rag/query_engines/metadata_filtering/
https://docs.pinecone.io/guides/search/filter-by-metadata
https://docs.weaviate.io/weaviate/search/filters
https://docs.opensearch.org/latest/vector-search/filter-search-knn/index/
https://www.elastic.co/docs/explore-analyze/query-filter/languages/querydsl

 

Metadata Filtering

 

developers.llamaindex.ai

 

Filter by metadata - Pinecone Docs

Narrow search results with metadata filtering.

docs.pinecone.io

 

Filters | Weaviate Documentation

Filters let you include, or exclude, particular objects from your result set based on provided conditions.

docs.weaviate.io

 

Filtering data

Filtering data

docs.opensearch.org

 

Query DSL | Elastic Docs

Query DSL is a full-featured JSON-style query language that enables complex searching, filtering, and aggregations. It is the original and most powerful...

www.elastic.co


해당 글은 AI 어시스턴트로 작성되었습니다.

NotebookLM과 Chat GPT를 사용하여 작성되었습니다.


 

 

2025년 한 해 고생 많으셨습니다.
2026년에도 잘 부탁드리겠습니다.
새해 복 많이 받으시길 기원합니다.