OpenSearch 는 대규모 데이터를 저장하고 검색하고 분석하기 위한 오픈소스 검색 및 분석 플랫폼입니다.
기본적으로 JSON 문서를 인덱스에 저장하고, 사용자는 REST API나 client library를 통해 문서를 색인하고 검색합니다.
OpenSearch는 단순히 데이터를 저장하는 DB가 아니라 “검색 가능한 데이터 플랫폼”에 가깝습니다.
왜 필요한가 #
일반적인 RDBMS도 데이터를 저장하고 조건 검색을 할 수 있습니다.
하지만 RAG 시스템에서는 다음 요구가 자주 발생합니다.
- 사용자의 자연어 질문과 의미적으로 가까운 문서 조각을 찾아야 합니다.
- 정확한 용어, 제품명, 에러 코드, 정책 번호처럼 keyword matching이 중요한 경우가 있습니다.
- 사용자 권한, 문서 출처, 작성일, 카테고리 같은 metadata filter를 함께 적용해야 합니다.
- 검색 결과의 relevance score, latency, 실패 질의를 관찰하고 개선해야 합니다.
- 운영 환경에서는 문서 재색인, mapping 변경, embedding model 교체, index alias 전환이 필요합니다.
OpenSearch는 이런 요구를 하나의 검색 플랫폼 안에서 처리할 수 있습니다.
RAG 관점에서의 의미 #
RAG는 크게 ingestion, retrieval, generation으로 나눌 수 있습니다.
문서 수집 → 정제 → chunking → embedding → OpenSearch 색인
→ 사용자 질문 → keyword/vector/hybrid retrieval → LLM 답변 생성
이 구조에서 OpenSearch는 다음 역할을 맡습니다.
| RAG 단계 | OpenSearch의 역할 |
|---|---|
| 문서 저장 | 원문 chunk, metadata, embedding vector를 함께 저장 |
| 검색 | BM25 기반 full-text search, vector search, hybrid search 수행 |
| 필터링 | source, doc_type, created_at, tenant_id 같은 metadata 조건 적용 |
| 품질 개선 | score, ranking, reranking, search pipeline을 통해 relevance 조정 |
| 운영 분석 | 검색 로그, latency, 실패 질의, top-k 결과 분포를 분석 |
중요한 점은 OpenSearch를 RAG에서 “벡터 저장소”로만 보면 안 된다는 것입니다.
실제 업무형 RAG에서는 용어 기반 검색과 의미 기반 검색이 모두 중요합니다.
예를 들어 E1023 오류 조치 방법 같은 질문은 embedding 유사도만으로 찾기보다 에러 코드 keyword matching이 매우 중요합니다.
반대로 결제 실패 시 고객에게 어떻게 안내해야 하나요? 같은 질문은 의미 검색이 더 효과적일 수 있습니다.
공식 문서 출처 #
- OpenSearch About: https://docs.opensearch.org/latest/about/
- OpenSearch Vector Search: https://docs.opensearch.org/latest/vector-search/
