Vertex AI RAG Engine 서버리스 실전 가이드: Spanner보다 먼저 검토해야 할 기준, 메타데이터 검색까지 어떻게 설계할까

발행일: 2026-04-14 | 카테고리: 개발정보

1) 한 줄 문제 정의

핵심 요약: RAG를 빨리 붙이고 싶을수록, 벡터DB보다 먼저 운영 경계와 필터 설계를 정해야 합니다.

많은 팀이 검색증강생성(RAG)을 도입할 때 가장 먼저 부딪히는 문제는 모델 성능이 아니라 지식 저장소 운영 복잡도입니다. 문서는 쌓이는데 어떤 저장소를 써야 할지, 권한 경계를 어떻게 나눌지, 특정 문서군만 검색하게 만들 수 있는지가 애매하면 파일 수가 늘수록 정확도보다 운영비가 먼저 흔들립니다.

이 글은 Vertex AI RAG Engine 도입을 검토하는 백엔드 개발자, 플랫폼 엔지니어, AI 기능 PM을 대상으로 합니다. 범위는 서버리스 모드와 Spanner 모드 비교, 메타데이터 검색 설계, 실제 API 흐름입니다. 자체 랭킹 모델 튜닝이나 대규모 오프라인 평가 파이프라인 구축은 제외합니다.

2) 먼저 결론

핵심 요약: 초기 도입이라면 서버리스가 기본값이고, 규제나 강한 격리가 필요할 때만 Spanner를 올리는 편이 안전합니다.

제가 권하는 기본값은 서버리스 모드 + 명시적 메타데이터 스키마 + 작은 파일 단위 코퍼스 분리입니다. Google 공식 문서도 서버리스를 가장 저렴하고 추천되는 시작점으로 설명합니다. 대신 "서버리스니까 아무 준비 없이 올려도 된다"는 뜻은 아닙니다. 실제 성공 여부는 검색 전 필터링 기준을 얼마나 먼저 정의하느냐에 달려 있습니다.

• 잘 맞는 팀: 2주 안에 RAG MVP를 내야 하는 팀, 인프라 운영 인력이 적은 팀, 문서 소스가 계속 늘어나는 팀
• 과한 경우: 강한 데이터 격리, CMEK, 전용 성능 티어가 필요한 규제 산업
• 핵심 판단축: 단순 저장이 아니라 "누가, 어떤 문서를, 어떤 조건으로 찾게 할 것인가"

3) 핵심 구조 분해

핵심 요약: RAG Engine은 문서를 넣는 통, 메타데이터는 필터 키, 벡터DB는 검색 엔진 역할로 나눠서 봐야 이해가 쉽습니다.

공식 문서 기준으로 메타데이터 검색 계층은 RagCorpus → RagDataSchema → RagFile → RagMetadata 순서로 구성됩니다. 쉽게 말하면 RagCorpus는 문서 보관함, RagDataSchema는 "이 보관함에서 year, department, product 같은 필터 키를 쓸 수 있다"고 선언하는 규칙, RagFile은 실제 문서, RagMetadata는 각 문서에 붙는 태그입니다.

서버리스 모드에서는 RAG 관리용 데이터와 벡터 검색 엔진을 분리해서 봐야 합니다. Google 문서에 따르면 서버리스 모드는 RAG 리소스 관리와 오케스트레이션은 완전관리형으로 처리하고, 임베딩 인덱싱과 벡터 검색은 기본적으로 Vertex AI Vector Search 2.0 컬렉션을 프로젝트에 프로비저닝해 사용합니다. 즉 "RAG 엔진 하나면 다 끝난다"기보다, 운영면은 단순화하고 검색면은 Vector Search 2.0으로 표준화하는 구조에 가깝습니다.

4) 설계 의도 해설

핵심 요약: 이 구조의 목적은 성능 극대화보다 초기 운영 부담을 줄이면서도 확장 여지를 남기는 데 있습니다.

서버리스 모드가 중요한 이유는 데이터베이스 용량 계획, 티어 선택, 복잡한 확장 결정을 뒤로 미룰 수 있기 때문입니다. 반대로 Spanner 모드는 전용 인프라와 CMEK 같은 요구를 만족시키는 대신, 티어 선택과 비용 관리 책임이 따라옵니다. Google 문서에도 Spanner는 전용 인프라와 격리, CMEK 지원이 필요한 워크로드에 맞고, 서버리스는 빠른 온보딩과 완전관리형 확장에 맞는다고 정리돼 있습니다.

이 설계는 분명한 트레이드오프가 있습니다.

• 얻는 것: 빠른 시작, 인프라 추상화, 기본 검색 흐름의 단순화
• 포기하는 것: 저장소 격리 세밀 제어, 전용 성능 보장, CMEK 같은 규제 옵션
• 실무 해석: 파일이 많아질수록 "어떤 문서를 검색 대상에서 빼야 하는가"가 더 중요해지므로, 이번 4월 메타데이터 검색 추가는 단순 기능 추가가 아니라 운영성 보강입니다.

5) 근거 및 비교

핵심 요약: 비교 대상은 Spanner와 외부 벡터DB가 아니라, "초기 운영 단순성 대 규제/격리 요구"입니다.

공식 문서 근거를 묶어 보면 판단 기준은 아래처럼 정리됩니다.

• 비용: 서버리스는 리소스 관리와 오케스트레이션 비용 구조가 단순하고, 벡터DB 사용량을 별도로 보기 쉬운 편입니다.
• 운영: Spanner는 티어와 격리 전략을 직접 관리해야 하므로, 작은 팀에는 과투자일 수 있습니다.
• 정확도: 이번 메타데이터 검색 기능 덕분에 부서, 기간, 제품군 같은 필터를 검색 전에 걸 수 있어 "맞는 문서만 찾게 하는 정확도"를 높이기 쉬워졌습니다.
• 확장성: Vector Search 2.0은 컬렉션 기반 저장, 자동 임베딩, 하이브리드 검색과 재랭킹 방향을 제공하므로, RAG 데이터가 늘어날수록 기본 토대 역할을 합니다.

6) 실제 동작 흐름 / 단계별 실행 방법

핵심 요약: 문서를 넣기 전에 코퍼스 분리 기준과 필터 키를 먼저 정하면 나중에 재수집 비용을 크게 줄일 수 있습니다.

1. 코퍼스 경계부터 정합니다.
   예: policy-docs, product-manuals, support-runbooks처럼 검색 의도별로 나눕니다. 파일 타입 기준보다 업무 목적 기준이 더 오래 갑니다.
2. 메타데이터 스키마를 먼저 선언합니다.
   예: department(STRING), doc_year(INTEGER), product_line(STRING), is_public(BOOLEAN). 스키마 없는 태그 운영은 결국 필터 혼선을 만듭니다.
3. 파일 업로드 후 메타데이터를 붙입니다.
   문서가 1,000개를 넘으면 파일명 규칙보다 메타데이터 기반 필터가 훨씬 안정적입니다.
4. 검색 요청 전에 필터를 강제합니다.
   예: 고객지원 봇은 is_public=true와 product_line='A'만 허용합니다.
5. 모드 전환은 데이터 이동이 아니라 뷰 전환으로 이해합니다.
   공식 문서상 서버리스와 Spanner 데이터는 서로 격리되므로, 전환 전에 재인덱싱 또는 재업로드 계획이 필요한지 확인해야 합니다.

# 1) 메타데이터 스키마 예시
curl -X POST   -H "Authorization: Bearer $(gcloud auth print-access-token)"   -H "Content-Type: application/json"   "https://${LOCATION}-aiplatform.googleapis.com/v1beta1/projects/${PROJECT_ID}/locations/${LOCATION}/ragCorpora/${RAG_CORPUS_ID}/ragDataSchemas:batchCreate"   -d '{
    "requests": [
      {"rag_data_schema": {"key": "department", "schema_details": {"type": "STRING"}}},
      {"rag_data_schema": {"key": "doc_year", "schema_details": {"type": "INTEGER"}}},
      {"rag_data_schema": {"key": "is_public", "schema_details": {"type": "BOOLEAN"}}}
    ]
  }'

# 2) 파일 메타데이터 부착 예시
curl -X POST   -H "Authorization: Bearer $(gcloud auth print-access-token)"   -H "Content-Type: application/json"   "https://${LOCATION}-aiplatform.googleapis.com/v1beta1/projects/${PROJECT_ID}/locations/${LOCATION}/ragCorpora/${RAG_CORPUS_ID}/ragFiles/${RAG_FILE_ID}/ragMetadata:batchCreate"   -d '{
    "requests": [
      {"rag_metadata": {"user_specified_metadata": {"key": "department", "value": {"str_value": "support"}}}},
      {"rag_metadata": {"user_specified_metadata": {"key": "doc_year", "value": {"int_value": 2026}}}},
      {"rag_metadata": {"user_specified_metadata": {"key": "is_public", "value": {"bool_value": true}}}}
    ]
  }'

실무에서는 "문서를 다 넣은 뒤 나중에 필터링하자"가 가장 비싼 선택입니다. 이유는 검색 품질 문제가 생겼을 때 재수집, 재태깅, 검증을 한 번 더 해야 하기 때문입니다.

7) 실수/함정(Pitfalls)

핵심 요약: 대부분의 실패는 모델이 아니라 문서 경계와 태그 체계가 흐릿해서 생깁니다.

• 실수 1: 코퍼스를 조직도 기준으로만 나눔
  예방: 검색 시나리오 기준으로 코퍼스를 분리합니다. 복구: 사용 로그를 보고 검색 의도별로 코퍼스를 재편합니다.
• 실수 2: 메타데이터 키를 문서팀마다 다르게 사용
  예방: department와 dept를 동시에 허용하지 말고 사전 스키마를 고정합니다. 복구: 배치 정규화 스크립트로 키를 통일하고 미일치 문서를 재태깅합니다.
• 실수 3: 서버리스와 Spanner 전환을 데이터 이전으로 오해
  예방: 공식 문서처럼 두 모드 데이터는 격리된다고 이해하고, 전환 체크리스트에 가시성 재검증을 넣습니다. 복구: 전환 전후 코퍼스 목록과 검색 결과를 비교해 누락 여부를 점검합니다.
• 실수 4: 공개/비공개 필터를 애플리케이션 레이어에서만 처리
  예방: 검색 전 metadata filter를 기본값으로 넣습니다. 복구: 민감 문서 코퍼스를 분리하고 기본 필터를 강제합니다.

8) 강점과 한계

핵심 요약: 서버리스는 시작은 빠르지만, 모든 규제 요구를 대신 해결해주지는 않습니다.

• 강점: 빠른 도입, 완전관리형 시작점, Vector Search 2.0과 연결되는 확장성, 메타데이터 기반 정밀 필터링
• 한계: CMEK 부재, 강한 저장 격리 요구에는 부적합, 모드 간 데이터 격리로 전환 설계 필요
• 반례: 금융, 공공, 헬스케어처럼 데이터 경계가 아주 엄격한 환경은 Spanner 또는 별도 저장소 전략이 더 적합할 수 있습니다.

9) 더 깊게 공부할 포인트

핵심 요약: 다음 단계는 모델보다 검색 품질과 운영성 실험입니다.

• Vector Search 2.0 컬렉션 구조와 스키마 설계
• 하이브리드 검색과 재랭킹을 언제 붙일지
• 코퍼스 단위 접근제어와 애플리케이션 권한 모델 연결
• 오답 사례를 기준으로 메타데이터 필터 실험표 만들기

10) 실행 체크리스트 + 작성자 관점

핵심 요약: 서버리스를 쓰더라도 검색 정책은 직접 설계해야 합니다.

• 검색 의도 기준으로 코퍼스를 3개 이내 초안으로 나눴는가?
• department, doc_year, is_public 같은 필수 메타데이터 키를 문서화했는가?
• 민감 문서가 기본 검색 경로에 섞이지 않도록 필터 기본값을 정했는가?
• 서버리스와 Spanner 전환 시 데이터가 자동 이동하지 않는다는 점을 팀이 이해했는가?
• 검색 품질 평가는 "답변 품질"뿐 아니라 "잘못 검색된 문서 비율"로도 보고 있는가?
• 2주 안에 MVP를 낼 목표라면 Spanner 대신 서버리스로 범위를 줄였는가?

Definition of Done: 코퍼스 경계, 메타데이터 스키마, 기본 필터 정책이 문서화되어 있고, 테스트 질문 20개 기준으로 금지 문서 노출 0건이면 1차 도입 완료로 봅니다.

제 추천은 명확합니다. 대부분의 팀은 서버리스로 시작하고, 메타데이터 검색을 초기에 같이 설계해야 합니다. 반대로 규제 이유 없이 처음부터 Spanner를 고르는 것은 과한 경우가 많습니다. 다만 고객별 완전 격리나 CMEK가 계약상 필수라면, 서버리스에서 억지로 버티지 말고 Spanner 또는 별도 저장소 아키텍처를 먼저 검토하는 편이 낫습니다.

참고자료

• Google Cloud Vertex AI release notes (확인일: 2026-04-14, 2026-04-03 서버리스 배포 모드, 2026-04-06 메타데이터 검색 업데이트 확인)
• Google Cloud Docs - Deployment modes in Vertex AI RAG Engine (확인일: 2026-04-14)
• Google Cloud Docs - Filter with metadata search (확인일: 2026-04-14)
• Google Cloud Docs - Vector Search 2.0 overview (확인일: 2026-04-14)