OpenSearch Serverless GA, 에이전트 검색 비용을 60% 낮춘 AWS

AI 요약

• 무슨 일: AWS가 2026년 5월 29일 차세대 Amazon OpenSearch Serverless를 공개했습니다.
  • 발표 수치는 scale from zero, 20배 빠른 autoscaling, 최대 60% 비용 절감, 동시 query 10배입니다.
• 개발자 영향: RAG, agent memory, log analysis를 위한 검색 backend의 idle 비용과 burst latency를 줄이는 데 초점을 둡니다.
• 주의점: 60% 절감은 모든 workload 보장이 아니라 collection type, vector dimension, query burst, ingestion pattern에 따라 달라집니다.
  • 기존 OpenSearch Serverless의 최소 OCU 비용 논쟁을 고려하면, 실제 팀은 새 pricing과 usage meter를 다시 측정해야 합니다.

AWS가 2026년 5월 29일 차세대 Amazon OpenSearch Serverless를 공개했습니다. AWS News Blog는 이 릴리스를 agentic AI 애플리케이션 구축을 위한 검색 backend로 소개했습니다. 발표 수치는 분명합니다. 몇 초 안에 0에서 scale up, 이전 대비 20배 빠른 autoscaling, 최대 60% 비용 절감, 동시 query 10배, petabyte급 데이터 지원입니다. 새 모델이나 에이전트 UI가 아니라, 에이전트가 검색하고 기억하고 로그를 분석할 때 붙는 backend 비용을 겨냥한 인프라 뉴스입니다.

AI 제품에서 검색 backend는 모델보다 덜 보이지만 비용표에는 자주 남습니다. RAG pipeline은 문서를 embedding하고, vector index를 만들고, query마다 semantic search와 keyword search를 함께 수행합니다. coding agent나 운영 agent는 tool 결과, 로그, 이슈, PR, 문서, run history를 검색해야 합니다. 사용자가 없는 시간에도 index는 남아 있고, 트래픽이 몰릴 때는 latency가 튑니다. OpenSearch Serverless의 이번 개편은 이 두 지점, idle floor와 burst scaling을 직접 겨냥합니다.

AWS 발표문에서 가장 먼저 봐야 할 문구는 "scale from zero"입니다. 기존 serverless 검색 서비스는 이름은 serverless여도 최소 capacity나 collection 단위 비용이 작은 workload에 부담이 되는 경우가 많았습니다. OpenSearch Serverless도 community 토론에서 최소 OpenSearch Compute Unit, collection별 비용, small workload의 경제성 질문이 반복됐습니다. AWS가 이번 발표에서 0에서 시작하는 scaling과 최대 60% 비용 절감을 전면에 둔 이유는 그 불만 지점을 알고 있다는 뜻입니다.

OpenSearch Serverless의 기본 단위는 OCU입니다. AWS는 indexing, search, storage capacity를 관리형으로 추상화하고, 사용자는 cluster sizing이나 shard 운영을 직접 하지 않는다고 설명합니다. Big Data Blog의 deep dive는 next generation이 이전 구조보다 더 세밀하게 OCU를 공유하고, collection별 pre-provisioning 부담을 줄이는 방향으로 바뀌었다고 설명합니다. agentic AI 워크로드에서는 이 차이가 큽니다. 하루 종일 steady traffic이 있는 검색 서비스와, 사용자가 agent를 실행할 때만 query가 폭증하는 RAG 앱은 capacity 패턴이 다릅니다.

AWS가 agentic AI를 전면에 놓은 이유는 검색 유형도 달라졌기 때문입니다. 단순 full-text search만 있으면 로그나 문서 검색으로 충분했습니다. 에이전트는 vector search, hybrid search, metadata filtering, 최근 대화 memory, tool output indexing, observability query를 함께 씁니다. LLM이 tool로 검색 backend를 호출하는 순간, 검색 latency는 모델 latency와 합쳐집니다. 검색 backend가 느리면 agent가 더 많은 재시도와 fallback을 수행하고, 그 비용은 모델 토큰과 search query 양쪽에 쌓입니다.

이번 릴리스는 vector search와 text search를 분리된 제품으로 보지 않습니다. AWS News Blog 예시는 collection을 만들고, vector index를 생성하고, 애플리케이션에서 검색하는 흐름을 보여줍니다. 같은 글은 Vercel AI SDK integration 이미지와 Kiro가 OpenSearch Serverless를 활용하는 예시도 포함했습니다. AWS가 단순히 "검색 서비스가 빨라졌다"가 아니라 "AI 앱 개발자가 바로 붙이는 backend"로 포지셔닝한 대목입니다.

수치별로 보면 개발자가 확인할 항목이 나뉩니다. 20배 빠른 autoscaling은 traffic spike 대응입니다. 갑자기 많은 사용자가 같은 knowledge base를 검색하거나, agent가 여러 subtask에서 병렬 검색을 수행할 때 search capacity가 빨리 늘어나는지의 문제입니다. 최대 60% 비용 절감은 idle과 low utilization workload의 문제입니다. 동시 query 10배는 agent가 병렬 tool call을 수행하거나 dashboard·log analysis가 동시에 붙는 상황과 연결됩니다. petabyte scale은 enterprise log, security analytics, 대형 문서 corpus 쪽의 조건입니다.

이 표에서 "최대 60%"를 그대로 예산표에 넣으면 위험합니다. AWS가 말하는 절감률은 workload와 사용 패턴에 따라 달라집니다. vector dimension이 크고, ingestion이 계속 일어나고, query가 steady하게 유지되는 서비스라면 idle 절감 효과가 작습니다. 반대로 내부 문서 agent, 개발자용 log search, 주기적 분석 agent처럼 사용 시간이 뚝뚝 끊기는 workload는 scale-to-zero의 이득을 크게 볼 수 있습니다. 실제 비교는 OpenSearch Service provisioned domain, 기존 OpenSearch Serverless, Pinecone·Weaviate·Elastic 같은 대안과 같은 query set으로 해야 합니다.

Big Data Blog는 구조 변화도 설명합니다. 이전 세대 OpenSearch Serverless는 collection마다 capacity isolation을 제공했지만, 그만큼 작은 collection에서도 일정 capacity가 남는 문제가 있었습니다. next generation은 indexing과 search가 workload에 맞춰 더 탄력적으로 움직이고, AWS가 내부에서 capacity를 더 효율적으로 배치하는 방향입니다. 사용자가 직접 node type과 shard를 고르지 않는다는 장점은 유지하면서, serverless라는 이름과 실제 비용 곡선을 더 가깝게 만들려는 시도입니다.

에이전트 개발자에게 가장 현실적인 use case는 세 가지입니다. 첫째는 RAG입니다. 문서 chunk와 embedding을 OpenSearch에 넣고, agent가 질문마다 vector search와 keyword search를 함께 수행합니다. 둘째는 memory입니다. agent가 과거 작업 결과, 사용자 선호, run log, tool output을 검색 가능한 형태로 저장합니다. 셋째는 observability입니다. 운영 agent가 로그와 metric을 검색하고, incident ticket이나 deployment history를 연결합니다. 이 세 영역 모두 query burst와 idle interval이 공존합니다.

AWS가 Vercel AI SDK 이미지를 발표문에 넣은 것도 이 맥락입니다. Vercel AI SDK는 프론트엔드와 API route에서 LLM 호출, streaming, tool calling을 다루는 개발자 표면입니다. OpenSearch Serverless가 이 흐름에 붙으면 agent 앱은 "모델 호출"과 "검색 backend"를 같은 애플리케이션 코드에서 연결할 수 있습니다. AWS가 Kiro 예시까지 함께 둔 것은 coding agent와 agentic IDE가 검색 backend의 고객이라는 메시지입니다. 에이전트가 코드를 고치려면 repo, docs, logs, issue history를 계속 찾아야 합니다.

경쟁 구도는 vector database 시장과 managed search 시장이 겹치는 쪽으로 갑니다. Pinecone과 Weaviate는 vector search와 RAG 경험을 전면에 둡니다. Elastic Cloud와 MongoDB Atlas Vector Search는 기존 데이터·검색 고객에게 vector 기능을 붙입니다. Azure AI Search와 Google Vertex AI Search는 cloud AI stack 안에서 검색을 묶습니다. AWS OpenSearch Serverless의 강점은 OpenSearch 생태계, AWS IAM, VPC, Bedrock Knowledge Bases, log analytics와의 연결입니다. 약점은 가격 구조가 복잡하게 느껴질 수 있고, small team이 OCU 비용을 예측하기 어렵다는 점입니다.

이번 발표는 Bedrock Knowledge Bases와도 연결됩니다. AWS 생태계에서 RAG를 만들 때 Bedrock Knowledge Bases는 data source와 embedding, retrieval 구성을 관리합니다. OpenSearch Serverless는 그 뒤의 vector store로 자주 쓰입니다. OpenSearch Serverless가 idle 비용을 줄이고 autoscaling을 빠르게 만들면, Bedrock 기반 agent의 운영 비용도 달라질 수 있습니다. 다만 Bedrock, embedding model, storage, data transfer, OpenSearch query 비용이 함께 붙기 때문에 총비용은 search 서비스 하나로 계산되지 않습니다.

개발팀이 바로 확인할 첫 항목은 collection type입니다. OpenSearch Serverless는 search, vector search, time series 같은 workload 유형을 구분합니다. agent 앱에서 memory와 RAG를 한 collection에 섞을지, log analytics와 문서 검색을 분리할지에 따라 비용과 latency가 달라질 수 있습니다. 둘째는 index 설계입니다. vector dimension, HNSW parameter, metadata field, text analyzer, shard 성격의 내부 배치는 query latency와 storage 사용량에 영향을 줍니다. Serverless가 cluster sizing을 숨겨도 index 설계까지 대신해주지는 않습니다.

세 번째 항목은 cold start입니다. Scale-to-zero는 비용에 좋지만 첫 query latency를 만들 수 있습니다. AWS는 몇 초 안에 0에서 scale up한다고 설명합니다. 내부 문서 검색이나 야간 batch agent에는 몇 초 지연이 괜찮을 수 있습니다. 대화형 customer support agent가 사용자 첫 질문에서 검색 지연을 보이면 UX가 나빠집니다. 따라서 agent 앱은 첫 query prewarm, caching, fallback answer, progress UI를 같이 설계해야 합니다. 비용 절감과 첫 응답 latency는 같은 방향으로 움직이지 않습니다.

네 번째 항목은 병렬 tool call입니다. AI 에이전트는 한 번의 사용자 요청에서 여러 검색을 동시에 실행할 수 있습니다. coding agent는 dependency 문서, error log, repo search, issue search를 병렬로 요청할 수 있습니다. 운영 agent는 CloudWatch log, OpenSearch index, ticket system, runbook을 동시에 봅니다. AWS가 동시 query 10배를 말한 이유도 agent workflow가 단일 검색보다 병렬 검색을 더 자주 만들기 때문입니다. 팀은 p50 latency보다 p95·p99 latency와 throttling을 봐야 합니다.

다섯 번째 항목은 데이터 권한입니다. 검색 backend는 agent에게 강력한 tool입니다. 검색 index 안에는 고객 데이터, 내부 문서, 로그의 secret, 보안 이벤트가 들어갈 수 있습니다. OpenSearch Serverless가 IAM과 네트워크 정책을 제공하더라도, agent가 어떤 index를 검색할 수 있는지, 어떤 field를 반환할 수 있는지, 검색 결과를 모델 prompt에 그대로 넣어도 되는지 별도 정책이 필요합니다. RAG에서 data leakage는 모델 hallucination보다 조용하게 발생합니다.

커뮤니티 반응은 비용 쪽에 무게가 있습니다. OpenSearch Serverless 초기 사용자는 small workload에서 serverless가 기대보다 비싸다는 질문을 반복해 왔습니다. 일부 토론은 최소 OCU가 개발·테스트 환경에 부담이 된다고 지적했습니다. 이번 next generation이 그 문제를 해결하는지는 실제 billing data가 나와야 판단할 수 있습니다. AWS의 공식 수치가 방향을 보여주지만, 각 팀의 query distribution과 idle time이 다르면 결과도 달라집니다.

이 발표를 단순한 OpenSearch 업데이트로만 보면 AWS의 의도를 놓칩니다. AWS는 agentic AI를 새 수요로 보고 있습니다. 모델은 Bedrock, 앱 개발은 Kiro와 SDK, 검색은 OpenSearch Serverless, observability는 CloudWatch와 OpenSearch, 지식 기반은 Bedrock Knowledge Bases로 묶입니다. OpenSearch Serverless가 scale-to-zero와 cost saving을 내세운 것은 이 스택에서 agent 앱의 search layer가 더 많이 쓰일 것이라는 전제입니다.

AI 개발자에게 이번 뉴스는 "벡터 DB를 무엇으로 고를까" 질문을 다시 열게 합니다. 독립 vector DB는 RAG 개발 경험이 빠르고, managed search는 full-text와 log analytics까지 함께 묶기 쉽습니다. OpenSearch Serverless의 next generation은 후자에 비용·scaling 개선을 붙였습니다. AWS에 이미 IAM, VPC, Bedrock, CloudWatch, S3 data lake가 있는 팀은 OpenSearch를 더 쉽게 검토할 이유가 생겼습니다. 멀티클라우드나 작은 prototype 팀은 여전히 pricing과 setup overhead를 비교해야 합니다.

제품팀 관점에서는 benchmark를 세 겹으로 나눠야 합니다. 첫째, retrieval quality입니다. 같은 corpus에서 hybrid search가 답변 품질을 얼마나 올리는지 봅니다. 둘째, latency입니다. scale-to-zero 이후 첫 query, warmed state, burst traffic의 p95를 나눠 측정합니다. 셋째, total cost입니다. OpenSearch OCU, storage, ingestion, embedding, model token, network 비용을 합칩니다. 60% 절감 문구는 세 번째 표의 한 행일 뿐입니다.

이번 OpenSearch Serverless 개편은 에이전트 시장에서 보이지 않는 병목을 건드립니다. 모델이 더 좋아져도 agent가 매번 느린 검색을 기다리거나, 쓰지 않는 시간에도 검색 backend 비용을 태우거나, burst traffic에서 throttling을 만나면 제품 품질은 떨어집니다. AWS가 발표한 scale-to-zero, 20배 autoscaling, 최대 60% 비용 절감은 이 병목을 줄이겠다는 인프라 쪽 답입니다. 실제 채택 여부는 각 팀의 RAG corpus, query burst, 권한 모델, 비용 측정표가 결정합니다.

OpenSearch Serverless GA의 의미는 serverless 검색이 AI 앱의 기본 부품으로 다시 포지셔닝됐다는 데 있습니다. 에이전트가 더 많은 tool을 쓰고, 더 많은 memory를 남기고, 더 많은 로그를 검색할수록 search layer는 모델만큼 자주 호출됩니다. AWS는 그 layer를 Bedrock과 Kiro, Vercel AI SDK 예시 안에 넣었습니다. 개발자가 지금 확인할 것은 발표 수치의 크기보다 자기 agent가 언제 검색하고, 언제 쉬고, burst 때 몇 개 query를 동시에 던지는지입니다.