Vector Store 선택은 모델보다 운영에 더 가깝다
title: "Vector Store 선택은 모델보다 운영에 더 가깝다" slug: "spring-ai-2-vector-stores" status: "draft" series: "Spring AI 2.0 읽는 순서" order: 8 description: "Spring AI 2.0의 Vector Store 문서와 PGvector 예제를 바탕으로, 벡터 저장소 선택이 모델보다 운영과 데이터 설계에 더 가까운 문제임을 설명하는 글." tags: ["Spring AI", "Vector Store", "PGvector", "RAG", "Embeddings"] source_docs:
- "downloads/spring-ai-reference-2.0-ko/api/vectordbs.html"
- "downloads/spring-ai-reference-2.0-ko/api/vectordbs/pgvector.html"
- "downloads/spring-ai-reference-2.0-ko/api/etl-pipeline.html"
RAG를 처음 붙일 때 많은 팀이 제일 오래 고민하는 건 모델이 아니라 벡터 저장소다.
이유는 단순하다. 모델은 비교적 쉽게 바꿔 볼 수 있지만, 벡터 저장소는 한 번 들어가면 데이터 적재 방식, 메타데이터 구조, 운영 방식, 비용 구조에 오래 영향을 주기 때문이다.
Spring AI 문서를 읽어 보면 이 점이 꽤 잘 드러난다. 다양한 Vector DB를 지원하지만, 메시지는 의외로 소박하다.
중요한 건 제품 이름보다 검색 동작과 운영 특성을 어떻게 다룰지다.
Vector Store를 모델의 부속품으로 보면 안 된다
임베딩 모델을 고르고 나면, 벡터 저장소는 그냥 “붙이는 저장소”처럼 보일 수 있다. 하지만 실제로는 RAG 품질과 운영성의 절반 이상이 여기에 걸린다.
왜냐하면 Vector Store는 단순 저장 역할만 하지 않기 때문이다.
- 문서 청크를 저장한다.
- 임베딩 벡터를 저장한다.
- 메타데이터를 같이 저장한다.
- 유사도 검색을 수행한다.
- 필터링을 적용한다.
- 경우에 따라 읽기/쓰기 경로를 분리한다.
즉 Vector Store는 RAG의 데이터 계층이자 검색 계층이다.
Spring AI 문서에서 먼저 봐야 할 포인트
vectordbs.html은 지원 제품 목록보다 먼저 공통 API를 설명한다. 이 순서가 꽤 중요하다.
문서에서 먼저 눈에 들어오는 항목은 대략 이렇다.
VectorStore인터페이스VectorStoreRetrieverSearchRequestBuilder- metadata filters
- batching strategy
- schema initialization
- read / write operation 분리
이걸 보면 Spring AI의 의도가 분명해진다. 특정 벡터 DB 사용법 자체보다, 검색 시스템을 공통 추상화로 다루는 법을 먼저 익히게 하려는 것이다.
SearchRequest와 메타데이터 필터가 실무에서 중요하다
처음 RAG를 붙일 때는 “유사한 문서 몇 개만 가져오면 되지 않나?” 싶다. 하지만 운영에 들어가면 그걸로는 부족하다.
예를 들면 이런 요구가 생긴다.
- 특정 제품군 문서만 검색하고 싶다.
- 최신 버전 문서만 보이고 싶다.
- 권한 있는 부서 문서만 검색해야 한다.
- 실험용 문서는 운영 검색에서 빼고 싶다.
이때 필요한 것이 메타데이터 필터다. Spring AI 문서에서 filter string과 metadata filters를 자세히 다루는 이유도 여기에 있다.
즉 벡터 검색 품질은 임베딩 모델만이 아니라, 메타데이터 설계와 검색 범위 통제에서 크게 갈린다.
읽기와 쓰기를 분리해서 생각해야 한다
문서에 Separation of Read and Write Operations가 별도 항목으로 있는 것도 눈여겨볼 만하다.
초기에는 문서 적재와 검색이 같은 경로처럼 보이지만, 운영 환경에서는 성격이 꽤 다르다.
쓰기 경로에서 중요한 것
- 문서 수집
- 청킹 전략
- 임베딩 생성
- 배치 적재
- 재색인
읽기 경로에서 중요한 것
- 검색 지연 시간
- 필터 정확성
- 결과 수와 품질
- 장애 시 fallback
이 둘을 한 덩어리로 보면 문제 원인을 찾기 어렵다. 그래서 Vector Store는 “DB 하나 붙인다”가 아니라, 색인 파이프라인과 검색 파이프라인을 함께 운영한다는 감각으로 보는 편이 맞다.
PGvector가 자주 현실적인 기본값이 되는 이유
Spring AI 문서에 여러 구현이 있지만, 실무에서 첫 선택으로 많이 고려되는 건 역시 PGvector다.
이유는 대체로 현실적이다.
- 이미 Postgres를 운영 중인 팀이 많다.
- 인프라 복잡도를 크게 늘리지 않을 수 있다.
- 메타데이터와 관계형 데이터 관리가 익숙하다.
- 초기 문서 규모에서는 충분히 실용적일 때가 많다.
즉 “가장 최신 벡터 DB”라서가 아니라, 기존 운영 체계 안에 넣기 쉽기 때문에 기본값 후보가 된다.
물론 문서량이 커지거나 검색 특성이 복잡해지면 다른 선택지가 더 나을 수 있다. 하지만 처음부터 별도 전문 벡터 DB를 도입한다고 항상 이득인 건 아니다.
스키마 초기화와 배치 전략은 생각보다 중요하다
문서에서 Schema Initialization과 Batching Strategy를 따로 다루는 이유도 실전적이다.
문서 적재가 작을 때는 잘 안 보이지만, 조금만 규모가 커져도 다음 문제가 생긴다.
- 초기 인덱스 생성 시간이 길어진다.
- 임베딩 생성과 저장이 병목이 된다.
- 재색인 배치 중 서비스 영향이 생긴다.
- 문서가 부분적으로만 들어가 품질이 흔들린다.
즉 Vector Store는 검색 API만 잘 붙인다고 끝나는 게 아니라, 데이터가 들어가는 방식까지 같이 설계해야 한다.
Auto-Truncation 같은 세부도 품질에 영향을 준다
Working with Auto-Truncation 같은 섹션은 얼핏 사소해 보이지만, 실제로는 입력 길이와 데이터 손실 문제를 다룬다.
긴 문서가 적재 과정에서 어떻게 잘리는지, 검색용 청크가 어떤 기준으로 만들어지는지는 결국 응답 품질에 직접 영향을 준다. RAG가 잘 안 되는 이유가 검색 엔진보다 청킹과 적재 정책인 경우가 정말 많다.
처음 선택할 때 추천하는 질문
Vector Store를 고를 때는 “무슨 제품이 최고인가”보다 아래 질문을 먼저 던지는 편이 낫다.
1) 문서 규모가 얼마나 되는가
작은 규모라면 운영 단순성이 더 중요할 수 있다.
2) 이미 운영 중인 데이터베이스가 무엇인가
기존 Postgres 활용이 가능한지부터 보는 편이 현실적이다.
3) 메타데이터 필터링이 얼마나 중요한가
권한, 버전, 카테고리 필터가 강하면 저장소 선택 기준이 달라질 수 있다.
4) 적재 빈도는 어느 정도인가
정적 문서 위주인지, 자주 업데이트되는 데이터인지에 따라 배치 전략이 달라진다.
5) 검색 지연 시간과 품질 요구가 어느 정도인가
채팅 UX, 운영 부하, 문서량에 따라 임계점이 다르다.
Spring AI가 주는 실용적인 장점
Spring AI의 좋은 점은, 저장소 제품이 달라도 최소한 애플리케이션 코드의 사고방식을 일정하게 유지할 수 있다는 데 있다.
VectorStore추상화SearchRequest- metadata filters
- RAG Advisor와의 연결
이 덕분에 초기에는 PGvector 같은 현실적인 선택으로 시작하고, 나중에 다른 저장소를 검토할 여지를 남길 수 있다.
물론 완전 무손실 교체는 아니지만, 최소한 애플리케이션 계층을 덜 오염시킨다는 장점이 있다.
한 문장으로 정리하면
Vector Store 선택은 “어떤 AI 제품이 더 멋진가”의 문제가 아니라, 문서 적재·메타데이터·검색 지연 시간·운영 복잡도를 어떻게 감당할 것인가의 문제에 가깝다.
그리고 Spring AI는 그 판단을 조금 덜 아프게 만들 공통 추상화를 제공한다.
마무리
RAG에서 임베딩 모델이 눈에 잘 띄는 건 맞다. 하지만 운영 단계에서 더 오래 남는 결정은 보통 Vector Store 쪽이다.
- 문서가 어떻게 들어가는가
- 어떤 필터로 검색하는가
- 읽기와 쓰기를 어떻게 분리하는가
- 기존 운영 체계와 얼마나 잘 맞는가
이 질문에 답해야 실제 서비스가 버틴다.
다음 글에서는 운영 관점의 마지막 축으로 넘어가서, Spring AI에서 관찰 가능성, 평가, 업그레이드 노트를 왜 함께 봐야 하는지 정리해 보겠다.