OpenSearchCon 2026: AI 에이전트에게 벡터 데이터베이스 이상의 것이 필요한 이유

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

OpenSearchCon 2026: Why AI Agents Need More Than a Vector Database

OpenSearchCon North America 2026은 “검색”이 유사한 문서를 찾는 것보다 훨씬 더 큰 문제가 되어가는 시점에 개최됩니다. AI 에이전트는 증거를 검색하고, 유용한 컨텍스트를 보존하고, 도구를 호출하며, 작업이 잘못되었을 때 무슨 일이 일어났는지 설명해야 합니다.

벡터 데이터베이스는 이 문제의 일부를 해결합니다. 진지한 에이전트에는 정확한 검색, 메타데이터, 최신성, 메모리, 실행 트레이스 및 권한도 필요합니다. 새롭게 등장하는 AI 데이터 계층은 “데이터베이스에 저장된 임베딩”이라기보다 검색 + 메모리 + 옵저버빌리티에 가깝습니다.

OpenSearchCon 2026이 보여주는 검색의 미래

OpenSearchCon North America 2026은 9월 22일부터 24일까지 미국 캘리포니아주 산호세에서 개최됩니다.

의제에는 여전히 관련성, Lucene, 클러스터 운영 및 기존 옵저버빌리티가 포함되지만, 2026년 논의의 상당 부분은 이제 RAG, 하이브리드 검색, 벡터 성능, MCP 및 AI 에이전트 옵저버빌리티까지 확장됩니다.

이러한 방향은 프로젝트의 2026년 로드맵과 일치합니다. 이 로드맵은 AI 에이전트를 새로운 유형의 검색 사용자로 보고 에이전트 컨텍스트, 메모리, 도구 라우팅 및 MCP를 포함합니다.

중요한 변화는 OpenSearch가 AI 기능을 추가했다는 사실이 아닙니다.

검색은 정보를 검색한 후 그에 따라 행동하는 시스템의 인프라가 되고 있습니다.

진지한 AI 에이전트에는 검색 가능한 이력이 두 가지 필요합니다

대부분의 RAG 튜토리얼은 하나의 질문에 집중합니다.

모델이 무엇을 알아야 하는가?

장시간 실행되는 에이전트에는 또 다른 요소가 필요합니다.

에이전트가 실제로 무엇을 했는가?

인덱스	핵심 질문	일반적인 데이터
지식 인덱스	에이전트가 어떤 증거를 검색해야 하는가?	문서, 청크, 임베딩, 메타데이터, 버전, 권한
실행 인덱스	작업 중 무슨 일이 일어났는가?	모델 호출, 검색, 도구 호출, 지연 시간, 토큰, 오류, 재시도

첫 번째는 답변을 개선합니다. 두 번째는 시스템을 진단 가능하게 만듭니다.

이 점이 중요한 이유는 최종 채팅 메시지가 실패한 워크플로를 숨길 수 있기 때문입니다. 에이전트는 잘못된 컨텍스트를 검색했거나, 잘못된 도구를 선택했거나, 예상된 작업을 전혀 수행하지 않았는데도 작업이 완료되었다고 주장할 수 있습니다.

OpenSearchCon에는 바로 이 문제를 다루는 세션이 마련되어 있습니다: AI 워커 관찰하기: OpenClaw 및 Hermes-agent를 위한 OpenSearch 옵저버빌리티.

설명된 실패 사례가 중요한 이유는 해결책이 더 나은 채팅 기록이 아니었기 때문입니다. 해결책은 모델 호출, 컨텍스트 검색, 도구 호출을 트레이스로 표현하는 운영 텔레메트리였습니다.

에이전트는 검색 가능한 기록을 두 종류 생성합니다. 자신이 알고 있던 것과 자신이 수행한 것입니다.

많은 RAG 실패는 LLM이 무엇인가를 보기 전에 발생합니다

RAG 답변이 틀렸을 때 언어 모델을 교체하는 것은 당연한 반응입니다. 하지만 수정해야 할 계층이 아닐 수도 있습니다.

OpenSearchCon의 검색을 고치고 RAG를 고치세요 세션은 이러한 주장을 직접 제시합니다. 겉보기에는 생성 실패처럼 보이는 많은 문제가 어떤 증거를 모델에 전달할지 결정하는 검색 계층에서 발생합니다.

검색 실패	사용자에게 보이는 현상	실제 문제
잘못된 문서가 1위를 차지함	확신에 찬 무관한 답변	순위 지정
올바른 소스의 순위가 너무 낮음	정보 누락	재현율
이전 버전이 선택됨	오래된 답변	최신성 및 메타데이터
청크에서 맥락이 사라짐	부분적으로 올바른 답변	청킹 및 구조
정확한 식별자가 사라짐	잘못된 기술 진단	어휘 검색
평가된 테스트 세트가 없음	“더 나아 보인다”	검색 평가

디버깅 규칙은 간단합니다.

검색 결과가 증거를 컨텍스트에 배치하지 않았다면 모델은 그 증거를 바탕으로 추론할 수 없습니다.

프로덕션 RAG에서는 단순히 의미적으로 유사한 결과가 아니라 최신 결과도 필요합니다. 소프트웨어 버전 2.0용 문서는 임베딩 공간에서 버전 4.0용 문서와 매우 가까울 수 있지만, 에이전트에 잘못된 절차를 제공할 수 있습니다.

따라서 유용한 검색 메타데이터에는 다음이 포함될 수 있습니다.

버전,
게시일,
제품 또는 환경,
문서 상태,
소스의 신뢰도,
및 액세스 권한.

검색 품질은 올바른 맥락에서의 관련성입니다.

키워드 검색은 벡터 검색에 패배하지 않았습니다

벡터 검색의 붐은 단순한 이야기를 부추겼습니다. 키워드 검색은 낡았고 임베딩이 그 대체재라는 이야기였습니다.

기술 문서 검색에서는 이러한 구분이 훨씬 덜 명확합니다.

쿼리 유형	어휘 검색	벡터 검색
오류 코드	매우 우수	변수
제품/모델 번호	매우 우수	변수
함수 또는 API 이름	매우 우수	상황에 따라 다름
자연어 의도	보통	매우 우수
개념적으로 유사한 표현	약함에서 보통	매우 우수

다음과 같은 쿼리 RTX 5090 CUDA 오류 802 의미적 의미와 정확히 일치해야 하는 토큰을 모두 포함하므로, 근사 유사도 속으로 사라져서는 안 됩니다.

OpenSearchCon이 하이브리드 검색을 계속 강조하는 이유도 여기에 있습니다. 어려운 점은 키워드 검색과 벡터 검색을 함께 실행하는 데 그치지 않고, 두 검색의 점수를 어떻게 정규화하고 순위를 매기며 결합할지 결정하는 것입니다.

이제 중요한 선택은 키워드냐 벡터냐가 아닙니다. 각 쿼리에 어느 정도의 정확성과 의미 이해가 필요한지입니다.

벡터 검색에는 자체 메모리 예산이 있습니다

로컬 AI 하드웨어에 관한 논의는 보통 모델 RAM과 VRAM에서 시작합니다. RAG에는 또 다른 메모리 사용자가 있습니다. 바로 검색입니다.

OpenSearchCon의 벡터 검색 세션에서는 그래프 메모리, 압축, 재현율, 처리량, P99 지연 시간이 함께 논의되는 경우가 점점 늘고 있습니다. 임베딩 규모가 커지면 메모리는 단순한 구현 세부 사항이 아니라 검색 아키텍처의 일부가 됩니다.

로컬 AI 구성 요소	주요 리소스 압박
LLM	RAM / VRAM
임베딩 모델	RAM / VRAM
OpenSearch	JVM 힙 및 시스템 메모리
벡터 인덱스	메모리 및 스토리지
문서 캐시	메모리
에이전트 도구	CPU, RAM 및 서비스별 리소스

실질적인 의미는 간단합니다.

로컬 RAG 서버에는 모델 예산뿐 아니라 검색 예산도 필요합니다.

동일한 호스트에서 문서 임베딩, 인덱스 유지 관리, 에이전트 실행까지 수행한다면 “이 컴퓨터에서 내 모델을 실행할 수 있나요?”만으로는 더 이상 충분한 용량 산정 지침이 되지 않습니다.

에이전트는 옵저버빌리티를 데이터 레이어의 일부로 만듭니다

기존 옵저버빌리티는 요청이 실패했는지, 어떤 서비스가 느렸는지, 로그에 무엇이 기록되었는지를 확인합니다.

에이전트는 모델 호출, 검색 결정 및 도구 실행을 추가합니다.

기존 소프트웨어	에이전트 시스템
요청	에이전트 작업
함수 호출	도구 호출
서비스 지연 시간	모델 + 검색 + 도구 지연 시간
오류	모델, 검색 또는 도구 오류
인프라 사용량	인프라 + 토큰 사용량
분산 추적	에이전트 실행 추적

현재 OpenSearch 에이전트 추적은 OpenTelemetry 규약을 사용해 에이전트, LLM, 검색, 임베딩 및 도구 작업을 표현합니다.

이를 통해 훨씬 더 구체적인 질문을 할 수 있습니다.

검색에 너무 오래 걸렸나요?
에이전트가 같은 도구를 반복해서 호출했나요?
재시도 루프로 인해 토큰 사용량이 증가했나요?
모델은 올바른 선택을 했지만 도구가 실패했나요?
새 에이전트 버전이 실행 동작을 변경했나요?

영구 메모리는 이와 관련된 수명 주기 문제를 야기합니다. 모든 정보를 영원히 보관하면 스토리지 사용량이 증가하고 오래된 맥락을 계속 검색할 수 있게 되며, 반대로 너무 적극적으로 삭제하면 에이전트가 유용한 정보를 반복해서 다시 학습해야 합니다.

즉, 에이전트 메모리에는 다음과 같은 명시적인 규칙이 필요합니다.

장기 메모리가 되는 것은 무엇인지,
만료될 수 있는 것은 무엇인지,
감사 기록에 포함해야 하는 것은 무엇인지,
그리고 향후 검색에 계속 영향을 미치지 않아야 하는 것은 무엇인지

에이전트 메모리는 단순한 검색 기능이 아닙니다. 데이터 수명 주기 정책입니다.

검색자가 작업을 수행할 수 있을 때 검색은 보안 경계가 됩니다

실패한 백업을 검색하는 사람과 실패한 백업을 검색하는 에이전트는 서로 다른 위험을 초래합니다.

사람은 결과를 확인할 수 있습니다. 에이전트는 결과를 사용해 다른 도구를 호출할 수 있습니다.

OpenSearch에는 호환되는 에이전트에 검색, PPL, SQL 및 클러스터 정보를 노출할 수 있는 MCP 서버가 포함되어 있습니다.

기존 검색	에이전트 검색
이 사용자가 인덱스에 액세스할 수 있나요?	이 에이전트가 검색할 수 있는 것은 무엇인가요?
이 쿼리를 실행할 수 있나요?	에이전트가 호출할 수 있는 검색 도구는 무엇인가요?
이 레코드를 읽을 수 있나요?	이를 읽은 후 어떤 작업을 수행할 수 있을까요?

검색이 작업 루프의 일부가 되면 검색 권한도 에이전트의 기능 경계에 포함됩니다.

데이터 레이어가 중요한 이유를 보여주는 실제 셀프 호스팅 AI 사례 3가지

모델, 검색, 에이전트 상태 간의 구분은 실제 셀프 호스팅 시스템에서 더 쉽게 이해할 수 있습니다.

1. 비공개 RAG 워크스페이스에는 추론과 별개의 데이터 워크로드가 있습니다.

AnythingLLM은 유용한 예입니다. 애플리케이션은 문서, 임베딩 및 검색을 관리하면서 언어 모델은 로컬, 원격 또는 API를 통해 실행할 수 있습니다.

현재 AnythingLLM RAG 하드웨어 가이드는 이러한 구분을 명확히 보여 줍니다. 문서 수집, 로컬 임베딩, 벡터 데이터 및 영구 스토리지는 각각 별도의 리소스 요구 사항을 만들며, 로컬 모델 추론에는 별도로 용량을 맞춰야 합니다.

이것이 바로 OpenSearchCon 토론에서 명확히 설명하는 핵심 실수입니다.

RAG 시스템에는 하나의 하드웨어 요구 사항만 있는 것이 아닙니다. 적어도 두 가지가 있습니다.

모델 워크로드,
그리고 지식/검색 워크로드입니다.

문서 컬렉션이 커지면 언어 모델이 바뀌지 않더라도 수집, 인덱싱, 메타데이터 및 백업이 병목이 될 수 있습니다.

2. 24시간 작동하는 에이전트는 지속적인 실행 상태를 생성합니다

OpenClaw은 Two Indexes 모델의 다른 측면을 보여 줍니다.

셀프 호스팅 OpenClaw 게이트웨이는 지속적인 대화를 유지하고, 도구를 호출하며, 예약된 작업을 실행하고, 웹훅을 수신하고, 여러 에이전트 워크플로를 조정할 수 있습니다. 비공개 AI 에이전트 게이트웨이 가이드는 에이전트를 노트북을 닫으면 사라지는 채팅 창이 아니라 상시 가동 서비스로 다룹니다.

이러한 지속성은 일반적인 채팅에서는 발생하지 않는 운영상의 질문을 만들어 냅니다.

에이전트가 어떤 도구를 호출했나요?
밤새 어떤 작업이 실패했나요?
작업이 몇 번 재시도되었나요?
결정 전에 어떤 컨텍스트가 로드되었나요?
에이전트가 작업을 완료하지 않고도 성공했다고 보고했나요?

이 때문에 OpenSearchCon의 OpenClaw/Hermes 관측성 세션은 셀프 호스팅 에이전트와 특히 관련이 깊습니다. 에이전트가 무인으로 작동하기 시작하면 실행 기록은 단순한 디버깅 정보가 아니라 인프라가 됩니다.

3. 영구 메모리는 워크스페이스 아키텍처의 일부가 됩니다

실제 Hermes 워크플로는 세 번째 패턴을 보여 줍니다. 모든 것을 불투명한 하나의 에이전트 데이터베이스에 넣는 대신, 비공개 AI 에이전트 워크스페이스는 에이전트 런타임, 사람이 읽을 수 있는 Markdown 메모리, Git 기록, 커뮤니케이션 채널 및 상시 가동 스토리지를 분리할 수 있습니다.

이 아키텍처가 유용한 이유는 “에이전트 메모리”가 반드시 하나의 모놀리식 벡터 스토어일 필요는 없기 때문입니다.

정보마다 서로 다른 수명 주기 규칙이 필요할 수 있습니다.

데이터	보관하는 이유
작업 컨텍스트	단기 작업 연속성
선별된 메모	장기 지식
Git 기록	검토 및 롤백
에이전트 추적 기록	운영 조사
원시 도구 출력	임시 증거 또는 디버깅

최적의 메모리 아키텍처는 “모든 것을 영원히 저장하는 것”이 아닐 수 있습니다. 정보의 각 부분이 실제로 어떤 유형의 상태인지 결정하는 것이 중요합니다.

셀프 호스팅 OpenSearch가 실제로 의미 있는 경우는 언제인가?

이러한 예가 모든 로컬 AI 서버에 OpenSearch를 설치해야 한다는 뜻은 아닙니다.

사용 사례	OpenSearch 적합성
수십 개의 PDF와 채팅	아마도 과도함
소규모 개인 메모 RAG	더 간단한 옵션이 일반적으로 존재함
크고 지속적으로 변화하는 문서 모음	유용함
키워드 검색 + 시맨틱 검색	적합성이 높음
여러 앱이 하나의 지식 인덱스를 공유	적합성이 높음
로그, 트레이스 및 검색을 하나의 플랫폼에서 처리	적합성이 높음
에이전트 메모리 및 실행 분석	잠재적으로 적합성이 높음

OpenSearch 자체가 상태 저장 인프라입니다. 이를 실행한다는 것은 인덱스, JVM 메모리, 영구 스토리지, 스냅샷, 보존 정책, 권한, 업그레이드 및 복구를 관리해야 한다는 뜻입니다.

로컬 OpenSearch Observability Stack은 Docker Compose를 통해 실행할 수 있지만, 공식 설치 사전 요구 사항에서는 이미 사용 가능한 RAM을 최소 8GB로 요구합니다.

배포하기 전에 다음을 질문해 보세요.

실제로 얼마만큼의 데이터를 인덱싱하고 있는가?
키워드 검색과 시맨틱 검색을 함께 사용해야 하는가?
같은 데이터 플랫폼에서 로그, 트레이스 또는 에이전트 상태도 저장할 것인가?
또 하나의 상태 저장 서비스를 운영할 의향이 있는가?

유용한 질문은 “집에서 OpenSearch를 실행할 수 있는가?”가 아니라 “내 AI 스택의 검색 및 관측 가능성 복잡도가 이를 정당화할 만큼 충분한가?”입니다.

모델 이상의 요구 사항에 맞춰 AI 서버 용량 산정하기

로컬 AI가 단순한 채팅 인터페이스를 넘어 성장하면 하드웨어 계획도 달라집니다.

더 큰 RAG 또는 에이전트 서버에는 다음 리소스가 필요할 수 있습니다.

모델 추론,
임베딩,
검색 인덱스,
문서 스토리지,
데이터베이스,
에이전트 런타임,
로그와 트레이스,
및 백업

현재의 Open WebUI 하드웨어 용량 산정 가이드도 같은 패턴을 보여 줍니다. 애플리케이션 메모리, 문서 처리, 임베딩, RAG 스토리지는 로컬 LLM에 필요한 훨씬 더 큰 메모리 또는 VRAM 요구 사항과는 별개입니다.

더 큰 시스템 메모리, 여러 드라이브에 걸친 데이터 세트, 호환 가능한 GPU 추론을 한 시스템에서 실제로 필요로 하는 워크로드라면, 대용량 스토리지 로컬 AI 서버로 이러한 계층을 통합할 수 있습니다. 하지만 하드웨어는 “AI 서버”라는 명칭이 아니라 실제 모델, 벡터 코퍼스, 보존 기간, 동시성을 기준으로 선택해야 합니다.

GPU를 늘려도 부족한 검색 인덱스는 해결되지 않으며, 스토리지를 늘려도 부족한 모델 메모리는 해결되지 않습니다.

AI 서버에는 더 큰 모델만이 아니라 데이터 계층이 필요합니다

로컬 AI에 관한 논의는 모델이 벤치마크 차트를 주도하기 때문에 자연스럽게 모델에 초점을 맞춥니다.

하지만 장시간 실행되는 RAG 및 에이전트 시스템에는 점차 또 다른 인프라 계층이 축적됩니다.

문서 및 메타데이터,
어휘 인덱스와 벡터 인덱스,
에이전트 메모리,
도구 통합,
로그 및 실행 추적,
권한,
및 보존 정책.

모델은 답변을 생성합니다. 데이터 계층은 어떤 증거가 모델에 전달되는지, 어떤 컨텍스트가 유지되는지, 그리고 에이전트가 예상치 못하게 동작할 때 무슨 일이 있었는지 누가 설명할 수 있는지를 결정합니다.

이것이 OpenSearchCon 2026의 더 큰 이야기입니다.

AI 에이전트는 검색을 기능에서 인프라로 바꾸고 있습니다.

따라서 제대로 된 에이전트에는 다음과 같은 지속적인 두 질문에 대한 신뢰할 수 있는 답변이 필요합니다.

이 에이전트는 지금 무엇을 알아야 하나요?
이 에이전트는 실제로 무엇을 했나요?

벡터 데이터베이스는 첫 번째 질문에 답하는 데 도움이 될 수 있습니다. 프로덕션 에이전트 인프라는 결국 두 질문 모두에 답해야 합니다.

자주 묻는 질문

OpenSearchCon North America 2026은 언제 열리나요?

OpenSearchCon North America 2026은 2026년 9월 22일부터 24일까지 미국 캘리포니아주 산호세에서 개최됩니다. 이 컨퍼런스에서는 오픈 소스 검색, 옵저버빌리티, 벡터 검색, RAG 및 에이전틱 AI를 다룹니다.

OpenSearch는 벡터 데이터베이스인가요?

OpenSearch는 벡터 임베딩을 저장하고 검색할 수 있지만, 전용 벡터 데이터베이스보다 범용적입니다. 또한 어휘 검색, 하이브리드 검색, 메타데이터 필터링, 분석 및 옵저버빌리티 워크로드를 지원합니다.

OpenSearch는 RAG에 적합한가요?

RAG에 하이브리드 검색, 메타데이터 및 버전 필터링, 관련성 평가 또는 대규모의 지속적으로 변화하는 문서 컬렉션이 필요할 때 강력한 선택이 될 수 있습니다. 소규모 개인 RAG 시스템은 더 가벼운 인프라로 운영하는 편이 쉬울 수 있습니다.

OpenSearch의 하이브리드 검색이란 무엇인가요?

하이브리드 검색은 BM25와 같은 어휘 신호를 의미 검색 또는 벡터 검색과 결합합니다. 쿼리에 정확한 기술 식별자와 더 폭넓은 자연어 의도가 함께 포함될 때 특히 유용합니다.

OpenSearch로 AI 에이전트를 모니터링할 수 있나요?

예. OpenSearch Agent Traces는 OpenTelemetry 기반 텔레메트리를 사용하여 지연 시간 및 토큰 정보와 함께 모델 호출, 검색 및 도구 사용을 노출합니다.

OpenSearch는 MCP를 지원하나요?

예. OpenSearch는 호환되는 에이전트가 검색, PPL, SQL 및 기타 데이터 도구에 액세스할 수 있도록 MCP 기능을 제공합니다. 검색된 정보가 에이전트의 작업으로 직접 이어질 수 있으므로 권한 설정은 여전히 중요합니다.

로컬 RAG 서버에 OpenSearch가 필요한가요?

반드시 그런 것은 아닙니다. 소규모 개인 문서 컬렉션에는 일반적으로 더 간단한 검색 인프라를 사용할 수 있습니다. 시스템에 더 크고 지속적으로 변화하는 인덱스, 하이브리드 검색, 공유 지식, 옵저버빌리티 또는 여러 에이전트 워크로드가 필요할 때 OpenSearch가 더 매력적인 선택이 됩니다.

셀프 호스팅 OpenSearch에는 RAM이 얼마나 필요한가요?

요구 사항은 인덱스 크기, 벡터 차원, 쿼리 부하 및 보존 기간에 따라 달라집니다. 현재 로컬 OpenSearch Observability Stack은 최소 8GB의 사용 가능한 RAM을 전제 조건으로 제시하며, 더 큰 벡터 및 텔레메트리 워크로드에는 상당히 더 많은 메모리가 필요할 수 있습니다.