모든 기업이 겪는 동일한 내부 문서 Q&A 문제를 Vertex AI RAG Engine을 통해 해결합니다. Terraform은 인프라를 프로비저닝하고, SDK는 코퍼스(Corpus)를 관리하며, 설계 구조는 생성 모델(Generation Model)을 교체 가능하게 유지하고 임베딩(Embedding) 업그레이드를 수월하게 만듭니다.

모든 기업이 직면한 동일한 문제: 제품 문서, FAQ, 정책 PDF가 쌓여가고, 지원 요원들은 정답을 충분히 빠르게 찾지 못하며, 매주 동일한 질문이 동일한 Slack 채널에 올라옵니다. 이 포스트는 GCP의 관리형 RAG 서비스인 Vertex AI RAG Engine을 사용하여 해결책인 내부 지식 Q&A를 구축합니다. RAG Engine은 관리형 벡터 데이터베이스(Vector Database)를 통해 청킹(Chunking), 임베딩(Embedding), 검색(Retrieval)을 내부적으로 처리합니다.

Terraform은 거의 변경되지 않는 인프라, 즉 API, GCS 버킷, IAM, RAG Engine의 데이터베이스 계층을 프로비저닝합니다. Python SDK는 자주 변경되는 요소인 코퍼스 및 파일 작업을 관리합니다. 이 설계는 단 한 줄의 변경만으로 생성 모델을 교체할 수 있게 유지하며, 임베딩 모델을 업그레이드할 때도 정직하고 실행 가능한 패턴을 제공합니다. 🎯

🏗️ 아키텍처 (The Architecture)

Docs (PDF/HTML/TXT) → GCS bucket
        ↓
RAG Engine Corpus (chunking + embedding)
...

🔧 Terraform: 인프라 계층 (Infrastructure Layer)

API 및 설정 (APIs and Config)

# rag/main.tf

resource "google_project_service" "required" {
...

RAG Engine을 사용하면 Basic, Scaled, Unprovisioned 중 선택하여 RagManagedDb 인스턴스를 확장할 수 있습니다. 티어(Tier)는 RagManagedDb를 사용하는 모든 RAG 코퍼스에 영향을 미치는 프로젝트 수준의 설정입니다. 개발용으로는 basic을, 운영 트래픽용으로는 scaled를 사용하세요.

소스 문서를 위한 GCS 버킷 (GCS Bucket for Source Documents)

# rag/storage.tf

resource "google_storage_bucket" "docs" {
...

서비스 계정 및 IAM (Service Account and IAM)

# rag/iam.tf

resource "google_service_account" "rag_app" {
...

모델 설정 - SDK로의 브릿지 (Model Config - Bridge to the SDK)

# rag/config.tf

resource "local_file" "rag_config" {
...

이것이 핵심적인 설계 결정입니다. 코퍼스 (Corpus) 표시 이름은 임베딩 모델 (Embedding model)로부터 파생됩니다. 임베딩 모델 변수를 변경하면 Terraform이 자동으로 새로운 코퍼스 이름을 계산하며, 이는 아래에서 다룰 업그레이드 패턴을 설정하게 됩니다.

🐍 코퍼스 생성 및 데이터 주입 (SDK)

# app/setup_corpus.py
import json
from vertexai import rag
...

🐍 파이프라인 쿼리 (모델 불가지론적 생성)

# app/query.py
from vertexai import rag
from vertexai.generative_models import GenerativeModel, Tool
...

생성 모델 (Generation model)은 쿼리 시점에 완전히 교체 가능합니다. tfvars에서 generation_model_id를 변경함으로써 gemini-2.5-flash를 gemini-2.5-pro로 바꾸거나, Llama와 같은 Model Garden 모델로 교체할 수 있습니다. 코퍼스를 변경할 필요는 없습니다.

⚠️ 임베딩 모델 정직성 체크

대부분의 튜토리얼이 생략하는 부분이 여기 있습니다: 임베딩 모델은 생성 시점에 코퍼스에 고정됩니다. 코퍼스를 재생성하고 모든 데이터를 다시 가져오지(re-import) 않는 한 모델을 변경할 수 없습니다. 임베딩 모델과 RAG 코퍼스 사이의 연관 관계는 해당 코퍼스의 수명 동안 고정된 상태로 유지됩니다.

이것이 바로 위의 Terraform 설정에서 코퍼스 이름을 임베딩 모델의 이름을 따서 명명한 이유입니다. 임베딩을 업그레이드한다는 것은 기존 것을 수정하는 것이 아니라, 새로운 코퍼스를 구축하는 것을 의미합니다. 그 패턴은 다음과 같습니다:

1. tfvars에서 embedding_model을 변경합니다 (예: text-embedding-004 → text-embedding-005)
2. terraform apply를 실행합니다 - 이렇게 하면 새로운 corpus_display_name이 계산되며, 기존 코퍼스에는 파괴적인 작업이 발생하지 않습니다.
3. setup_corpus.py를 다시 실행합니다 - 새로운 이름으로 신선한 코퍼스를 생성하고, 동일한 GCS 버킷에서 데이터를 다시 가져옵니다.
4. 아래의 평가(evaluation)를 두 코퍼스 모두에 대해 실행합니다.
5. 만약 새로운 코퍼스가 승리한다면, 앱 설정을 새로운 corpus_name으로 지정하고 기존 코퍼스를 삭제합니다.

이 패턴을 알고 나면 정말 간단하며, 전환(cut over)할 때까지 두 코퍼스가 나란히 존재하기 때문에 교체 과정에서 다운타임이 전혀 발생하지 않음을 의미합니다.

📐 환경 설정

# environments/dev.tfvars
environment          = "dev"
embedding_model      = "text-embedding-005"
...

청킹 (Chunking) 설정은 코퍼스 (Corpus) 단위가 아니라 임포트 (Import) 작업 단위로 설정됩니다. 따라서 임베딩 모델 (Embedding model)을 건드리지 않고도, 가장 효과적인 방식을 테스트하기 위해 동일한 파일을 서로 다른 청킹 방식으로 재임포트할 수 있습니다.

🧪 소규모 평가: 업그레이드가 실제로 도움이 되었는가?

모델 회귀 테스트 (Model regression check)와 동일한 경량화된 접근 방식을 사용합니다. 몇 가지 실제 질문을 바탕으로 검색 적중률 (Retrieval hit rate)과 답변 키워드 커버리지 (Answer keyword coverage)를 점수화합니다.

# evaluate.py
from vertexai import rag
from app.query import ask
...

교체 (Cut over) 전에 이 과정을 실행하십시오. 만약 새로운 임베딩 모델의 retrieval_hit_rate가 떨어진다면, 기존 코퍼스를 아직 삭제하지 말고 원인을 조사하십시오. 실제 지원 티켓 (Support tickets)에서 추출한 10~20개의 실제 질문만으로도 이러한 무결성 검사 (Sanity check)를 위한 회귀 현상을 충분히 잡아낼 수 있습니다.

⚠️ 주의 사항 및 팁

코퍼스 생성 및 임포트는 SDK를 통해서만 이루어집니다. 이 글을 쓰는 시점 기준으로 RAG 코퍼스 자체를 위한 네이티브 Terraform 리소스는 존재하지 않습니다. Terraform은 영구적인 인프라 (Durable infrastructure)를 관리하고, SDK는 코퍼스의 생명주기 (Lifecycle)를 관리합니다.

검색 속도 제한 (Retrieval rate limit). 검색 요청은 지역 (Region)당 분당 600회 (RPM)로 제한됩니다. 평가 배치 크기 (Evaluation batch sizes)와 운영 환경의 쿼리 볼륨 (Query volume)을 계산할 때 이 점을 고려하십시오.

기존 코퍼스는 자동으로가 아닌 의도적으로 삭제하십시오. 코퍼스는 Terraform 상태 (State) 외부에서 생성되므로, 정리 작업은 terraform destroy가 대신 해주는 것이 아니라 수동 또는 스크립트를 통한 단계로 진행해야 합니다.

모델 지원 종료 (Deprecation)를 주시하십시오. Google은 때때로 퍼블리셔 임베딩 모델 (Publisher embedding models)의 지원을 종료합니다. 코퍼스는 해당 코퍼스를 생성한 모델에 종속되므로, 지원 종료 날짜가 다가온 후에가 아니라 그 전에 마이그레이션 경로를 계획하십시오.

실제 내부 질문을 위한 모델 불가지론적 (Model-agnostic) RAG 파이프라인입니다. 임베딩을 업그레이드하는 정직한 프로세스와 그 업그레이드가 실제로 도움이 되었는지 확인하는 내장된 방법을 갖추고 있습니다. 인프라에는 Terraform을, 코퍼스에는 SDK를 사용하며, 모든 교체 전에는 평가를 수행합니다. 🔍

이 내용이 도움이 되었나요? 다음에 이어질 Azure 버전도 팔로우해 주세요! 💬