이번 포스트에서는 OpenSearch Dashboard 란 또 무엇인지까지만 정리해봅니다.
OpenSearch와 OpenSearch Dashboards는 역할이 다릅니다.
| 구분 | OpenSearch | OpenSearch Dashboards |
|---|---|---|
| 정체 | 검색 및 분석 엔진 | OpenSearch를 위한 웹 UI |
| 핵심 역할 | 데이터 저장, 색인, 검색, 집계, 벡터 검색 | 데이터 탐색, 시각화, Dev Tools, 운영 화면 제공 |
| 통신 방식 | REST API, client library | OpenSearch REST API를 호출해 결과를 표시 |
| RAG에서의 위치 | Retriever, Vector DB, Hybrid Search Engine | 검색 품질 분석, 로그 분석, 운영 가시화 |
| 예시 포트 | 9200 | 5601 |
OpenSearch는 실제 데이터를 저장하고 검색하는 서버입니다.
반면 OpenSearch Dashboards는 OpenSearch에 저장된 데이터를 사람이 쉽게 보고, 질의하고, 시각화할 수 있도록 도와주는 웹 애플리케이션입니다.
따라서 Dashboards가 없어도 Python 애플리케이션은 OpenSearch REST API나 opensearch-py를 통해 검색할 수 있습니다.
하지만 Dashboards가 있으면 개발자가 Query DSL을 빠르게 실험하고, 운영자가 검색 로그와 시스템 지표를 시각화하며, RAG 품질을 관찰하기 쉬워집니다.
왜 필요한가 #
RAG 시스템을 만들 때 초기에 가장 많이 하는 실수는 “검색 코드만 작성하고 검색 품질을 관찰하지 않는 것”입니다.
예를 들어 사용자가 다음과 같은 질문을 했다고 가정합니다.
결제 실패 시 고객에게 어떤 안내를 해야 하나요?
Python retriever는 OpenSearch에서 관련 문서를 검색하고 LLM에 context를 전달합니다. 하지만 실무에서는 다음 질문에 답할 수 있어야 합니다.
- 어떤 문서 chunk가 검색되었는가?
- top-k 결과의 score 분포는 어떤가?
- keyword search와 vector search 중 무엇이 더 효과적이었는가?
- 특정 source나 doc_type에서만 결과가 편중되는가?
- 검색 latency가 갑자기 증가했는가?
- 사용자가 질문했지만 관련 문서를 찾지 못한 실패 질의는 무엇인가?
OpenSearch는 이런 로그를 저장하고 검색하는 엔진 역할을 하고, OpenSearch Dashboards는 그 로그를 사람이 볼 수 있는 운영 화면으로 만들어 줍니다.
자세한 이용 방법은 이후에 다룹니다. ^^
