AWS가 에이전틱 AI 워크로드를 위해 Amazon OpenSearch Serverless를 새롭게 설계했다. 발표에서 가장 눈에 띄는 수치는 분명하다. 유휴 컬렉션의 컴퓨팅 용량을 0까지 낮출 수 있고, 필요할 때는 수 초 안에 20배까지 확장할 수 있으며, 이전 용량 모델과 비교해 최대 60%의 비용 절감을 기대할 수 있다.

특히 OpenSearch Serverless를 관리형 지식 기반의 벡터 스토어로 사용하는 RAG 환경이라면 이는 직접적인 비용 이슈다. 하지만 실제 마이그레이션을 검토해 보니 핵심은 절감액 자체가 아니었다. 발표가 약속하는 변화와 마이그레이션에 실제로 드는 비용 사이에는 간극이 있다. 이 발표가 하나로 묶어 보이기 쉬운 두 가지 결정을 분리해서 살펴보자.

발표가 실제로 바꾸는 것

마케팅 표현을 걷어내면 NextGen은 새로운 검색 기능이 아니라 비용 구조와 탄력성의 변화다.

  • Scale-to-zero. 기존 모델에서는 컬렉션마다 일정 수의 OCU(OpenSearch Compute Unit)를 최소 용량으로 유지해야 했다. 트래픽이 없어도 그 최소 용량에 대한 비용은 계속 발생했다. NextGen에서는 유휴 상태의 인덱싱 및 검색 컴퓨팅 용량을 0까지 낮출 수 있다. 유휴 컴퓨팅 비용 대신 스토리지 비용만 부담한다.
  • 즉시 20배 확장. 트래픽이 돌아오면 수 분이 아니라 수 초 안에 용량을 다시 늘릴 수 있다.
  • 최대 60% 비용 절감. 트래픽이 간헐적이거나 가동률이 낮은 워크로드에 특히 유리하다. 내부 도구나 개발·QA용 RAG 환경이 대표적이다.

반대로 이것은 더 나은 검색기나 새로운 순위 모델, 새로운 커넥터가 아니다. RAG가 반환하는 결과의 품질을 직접 바꾸는 기능도 아니다. 벡터 계층의 비용을 최적화하는 변화일 뿐이다. 이 구분은 글의 후반부에서 중요해진다.

발표에서 빠진 마이그레이션 함정

CloudFormation 변경을 직접 검토하면서 확인한 사실이 있다. NextGen은 기존 컬렉션에서 켜는 플래그가 아니다. CloudFormation에서는 컬렉션을 새 AWS::OpenSearchServerless::CollectionGroup 리소스에 연결하는 방식으로 NextGen을 사용한다. 이 그룹의 CapacityLimits에서 인덱싱과 검색의 최소 OCU를 0으로 설정하면 Scale-to-zero를 활성화할 수 있고, 최대 용량도 함께 지정할 수 있다.

문제는 컬렉션과 그룹을 연결하는 속성의 업데이트 정책이 **Update requires: Replace**라는 점이다.

CloudFormation 문서의 이 한 줄이 마이그레이션의 성격을 바꾼다. 기존 컬렉션을 그룹에 연결하는 작업은 제자리에서 설정을 바꾸는 것이 아니다. CloudFormation이 컬렉션을 삭제한 뒤 다시 생성한다. 그 결과는 다음과 같다.

  • 벡터 인덱스를 새로 구축해야 한다.
  • Bedrock Knowledge Bases처럼 해당 컬렉션을 사용하는 관리형 지식 기반이 있다면, 새 컬렉션에 전체 코퍼스를 다시 수집하고 인덱싱해야 한다.

즉, 이것은 “설정 한 줄 변경"이 아니라 “새 컬렉션 생성과 전체 재인덱싱"이다. 원본 문서가 별도의 위치에 보관된 내부 지식 기반이라면 데이터 유실 위험은 크지 않다. 그렇더라도 실제 재수집과 재인덱싱 작업은 필요하며, 운영 리전 수만큼 반복된다. 그 비용과 시간을 계획에 넣어야 한다. 발표문은 이 부분을 말해 주지 않는다.

실제로 확인한 주의점

  • aws-cdk-lib에는 이미 L1 리소스가 있을 수 있다. CfnCollectionGroup과 collectionGroupName 속성을 사용하려면 CDK를 올려야 한다고 생각하기 쉽다. 하지만 최신 버전이 아니더라도 비교적 최근의 aws-cdk-lib에는 이미 두 항목이 포함돼 있을 수 있다. 업그레이드하기 전에 현재 설치된 버전을 먼저 확인하는 편이 낫다.
  • generation 필드는 없다. generation: NEXTGEN처럼 세대를 지정하는 토글을 찾게 되지만, 그런 필드는 존재하지 않는다. 컬렉션 그룹 연결 자체가 NextGen을 표현하는 방식이다.
  • cdk synth 성공은 검증이 아니다. 최소 OCU 0, 최대 OCU N으로 설정한 CollectionGroup과 연결된 컬렉션을 포함해 CloudFormation 템플릿을 생성할 수 있다. 이는 템플릿이 컴파일된다는 뜻일 뿐, 하위 시스템이 새 컬렉션을 런타임에 받아들이는지를 증명하지는 않는다.
  • 리소스 타입의 존재와 실제 배포 성공은 다르다. 주요 리전에서 CollectionGroup 리소스 타입을 사용할 수 있는지 확인하면 리전 지원 여부라는 장애물은 제거된다. 그러나 API가 그 타입을 인식하는 것과 실제 배포 후 지식 기반이 해당 컬렉션에 인덱싱하는 것은 별개의 검증 단계다. 전자가 통과했다고 후자를 건너뛰면 안 된다.
  • Scale-to-zero는 콜드 스타트와 맞바꾼다. 유휴 컴퓨팅 비용이 0이 되는 것은 개발·QA 환경에서는 분명한 이점이다. 다만 사용자 요청을 처리하는 경로에서는 유휴 상태 뒤 첫 쿼리가 워밍업 시간을 부담한다. 이는 비용이 아니라 지연 시간의 문제다. 그래서 먼저 비프로덕션 환경에 적용해 콜드 스타트 동작을 확인한 뒤 운영 환경을 검토하는 편이 안전하다.

이 발표가 대신 결정해 주지 않는 것

팀이 빠지기 쉬운 함정이 있다. 벡터 스토어 비용 절감 소식이 나오면 이를 RAG 엔진을 교체하라는 신호로 읽는 것이다. “관리형 검색 서비스를 버리고 OpenSearch로 옮겨야 할까?“라는 질문으로 곧장 이어진다.

하지만 이것은 서로 다른 결정이며, 이번 발표는 그중 하나에만 영향을 준다.

  • “기존 OpenSearch 벡터 스토어를 NextGen으로 옮길 것인가?” 충분히 검토할 만하다. 이미 운영 중인 인프라의 비용 최적화이기 때문이다. 판단 기준은 마이그레이션 비용과 재인덱싱 비용, 그리고 유휴 컴퓨팅 비용 절감의 비교다. 가동률이 낮은 환경이라면 계산은 비교적 단순하다.
  • “관리형 RAG 서비스를 OpenSearch로 대체할 것인가?” 이번 발표는 이 질문과 직접적인 관련이 없다. 엔진 선택은 검색 품질, 관련성 튜닝, ACL 및 멀티 테넌트 필터링의 동등성, 커넥터 생태계, 운영 부담을 기준으로 판단해야 한다. 벡터 계층 비용이 60% 낮아진다는 사실은 OpenSearch가 특정 코퍼스에서 더 나은 검색 결과를 내는지, 기존 접근 제어 모델을 재현할 수 있는지 알려주지 않는다. 엔진 교체를 평가한다면 바로 이 기준을 검증해야 하며, 비용 절감 수치가 그 작업을 대신하게 해서는 안 된다.

두 결정을 섞으면 유휴 컴퓨팅 비용에 관한 수치 하나로 몇 달에 걸친 엔진 마이그레이션을 정당화하게 된다.

실제로 해야 할 일

  1. 이미 OpenSearch Serverless를 벡터 스토어로 사용하고 있다면, 개발 환경에서 NextGen 마이그레이션을 검증한다. 최소 OCU가 0인 CollectionGroup을 만들고 컬렉션을 연결한 뒤, 실제로 배포한다. 그런 다음 지식 기반이 새 컬렉션에 재인덱싱하고 검색 결과를 반환하는지 확인해야 한다. cdk synth의 성공만으로는 충분하지 않다.
  2. 설정 변경이 아니라 재인덱싱 작업으로 계획한다. 컬렉션은 교체된다. 적용하기 전에 환경별 재인덱싱 비용과 소요 시간을 파악해야 한다.
  3. 먼저 비프로덕션 환경에 적용한다. 유휴 시간이 많은 환경에서 비용 절감 효과를 확인하고, 사용자 경로에 적용하기 전에 콜드 스타트 지연 시간을 측정한다.
  4. 이 발표로 RAG 엔진을 결정하지 않는다. 관리형 검색 서비스에서 OpenSearch로 옮길지 검토 중이라면 검색 품질과 접근 제어를 중심으로 별도의 평가를 진행해야 한다. 이번 발표는 그 결정의 근거가 아니다.

NextGen은 적절한 워크로드에는 분명히 좋은 변화다. 다만 이 변화가 답하는 결정과, 사람들이 그 답을 핑계로 건너뛰기 쉬운 결정을 구분해야 한다.