Source: Dev.to

벡터 데이터베이스 비용 절감하기: AWS에서 서버리스 RAG 설계

개요

최근 몇 년간 RAG (Retrieval‑Augmented Generation) 애플리케이션이 급증하면서, 벡터 데이터베이스(VectorDB)의 사용도 늘어나고 있습니다. 하지만 관리형 벡터 DB 서비스를 그대로 사용하면 불필요하게 높은 비용을 초래할 수 있습니다. 이 글에서는 AWS 기반의 서버리스 아키텍처를 활용해 비용을 크게 절감하면서도 확장성과 성능을 유지하는 방법을 살펴봅니다.

왜 기존 VectorDB 비용이 높은가?

서버리스 RAG 아키텍처 개요

아키텍처는 AWS Lambda, Amazon S3, Amazon DynamoDB, Amazon OpenSearch Service (or OpenSearch Serverless), 그리고 Amazon Bedrock(또는 외부 LLM) 등을 조합합니다.

┌─────────────┐      ┌─────────────┐
│   사용자 UI │─────►│   API GW    │
└─────┬───────┘      └─────┬───────┘
      │                    │
      ▼                    ▼
┌─────────────┐      ┌─────────────┐
│   Lambda    │─────►│   S3 (Docs) │
└─────┬───────┘      └─────┬───────┘
      │                    │
      ▼                    ▼
┌─────────────┐      ┌─────────────┐
│   DynamoDB │◄─────│   OpenSearch│
└─────────────┘      └─────────────┘

핵심 컴포넌트

구현 단계

1. 문서 업로드 & 인덱싱

1. 사용자가 S3 버킷에 문서를 업로드합니다.
2. S3 이벤트가 트리거되어 Lambda 함수가 실행됩니다.
3. Lambda 안에서:
   • 문서를 읽고 텍스트 추출 (예: pdfminer, docx 등)
   • Embedding 모델(예: sentence‑transformers 또는 Bedrock amazon.titan-embed-text-v1)을 호출해 벡터 생성
   • 벡터와 메타데이터를 OpenSearch Serverless에 저장
   • 문서 ID ↔ 벡터 ID 매핑을 DynamoDB에 기록

def handler(event, context):
    # S3 객체 정보 파싱
    bucket = event['Records'][0]['s3']['bucket']['name']
    key    = event['Records'][0]['s3']['object']['key']
    
    # 1️⃣ 텍스트 추출
    text = extract_text_from_s3(bucket, key)
    
    # 2️⃣ 임베딩 생성 (Bedrock 호출)
    embedding = get_embedding(text)
    
    # 3️⃣ OpenSearch에 인덱스
    index_document(embedding, metadata={...})
    
    # 4️⃣ DynamoDB에 매핑 저장
    save_mapping(document_id=key, vector_id=embedding_id)

주의: 코드 블록은 그대로 유지했습니다.

2. 질의 처리 (RAG)

1. 프론트엔드에서 질문을 받아 API Gateway → Lambda 로 전달합니다.
2. Lambda 내부:
   • 질문을 Embedding 모델에 전달해 쿼리 벡터 생성
   • OpenSearch에 k-NN 검색을 수행해 가장 유사한 문서 ID 반환
   • 반환된 문서 ID를 DynamoDB에서 조회해 원본 텍스트를 S3에서 가져옴
   • 가져온 텍스트와 질문을 LLM(예: Bedrock anthropic.claude-v2)에 전달해 최종 답변 생성
   • 답변을 사용자에게 반환

def rag_handler(event, context):
    query = event['body']['question']
    
    # 1️⃣ 질문 임베딩
    query_vec = get_embedding(query)
    
    # 2️⃣ OpenSearch k-NN 검색
    hits = knn_search(query_vec, k=5)
    
    # 3️⃣ 원본 문서 가져오기
    docs = fetch_documents_from_s3(hits)
    
    # 4️⃣ LLM 호출
    answer = generate_answer(query, docs)
    
    return {"answer": answer}

3. 비용 최적화 팁

실제 비용 비교 (예시)

※ 위 수치는 샘플이며 실제 비용은 사용량, 리전, 선택한 인스턴스 등에 따라 달라집니다.

마무리

• 서버리스 아키텍처를 활용하면 필요한 만큼만 비용을 지불하고, 트래픽 급증에도 자동으로 확장할 수 있습니다.
• OpenSearch Serverless와 DynamoDB On‑Demand를 조합하면 기존 관리형 VectorDB 대비 30‑60% 비용 절감이 가능합니다.
• 코드와 인프라를 IaC(예: AWS CDK, Terraform) 로 관리하면 재현성과 운영 효율성을 동시에 확보할 수 있습니다.

다음 단계: 위 아키텍처를 실제 프로젝트에 적용해 보고, AWS Cost Explorer를 통해 비용 변화를 지속적으로 모니터링하세요.

이 글은 개인적인 실험과 비용 분석을 기반으로 작성되었습니다. 서비스 운영 시 반드시 자체 테스트와 비용 검증을 진행하시기 바랍니다.

The Problem: Vector Database Cost Trap

Retrieval‑Augmented Generation (RAG) 프로토타입은 주말만에 만들 수 있지만, 인프라 예산을 고갈시키지 않으면서 그 프로토타입을 프로덕션에 올리는 일은 완전히 다른 엔지니어링 과제입니다.

많은 창업자와 엔지니어링 팀은 프로비저닝된 벡터 데이터베이스를 띄우거나 전용 EC2 인스턴스를 24시간 가동하여 MVP를 출시합니다. 이는 처음 100명 사용자에게는 훌륭하게 작동하지만, 규모가 커지거나 트래픽이 예측 불가능해질 때 메모리에 벡터 인덱스를 유지하기 위해 유휴 컴퓨팅 비용을 지불하는 것은 런웨이에 큰 부담이 됩니다.

스타트업의 런웨이를 보호하면서 고도로 확장 가능한 AI 제품을 구축하려면, 프로비저닝된 인프라에서 이벤트‑드리븐 서버리스 아키텍처로 전환해야 합니다.

AWS에서 서버리스 RAG 아키텍처

이벤트 기반 파이프라인

주요 이점

• 인프라 관리 불필요 – 노드 패치나 샤드 관리를 할 필요가 없습니다.
• 이벤트 기반 – 파이프라인은 문서가 도착할 때만 실행됩니다; 인제스트가 없으면 비용도 없습니다.
• 분리된 스케일링 – 사용자가 10,000개의 문서를 업로드하면 Lambda가 동시에 처리하도록 확장되어 검색 성능에 영향을 주지 않습니다.

Alternatives & When to Use Them

• pgvector on Amazon RDS – 작은 데이터셋이나 낮은 지연 시간 요구에 적합하지만, 프로덕션 수준의 검색 지연 시간과 규모를 위해서는 전용 벡터 엔진이 일반적으로 필요합니다.

OpenSearch Serverless의 비용 혜택

AWS는 최근 최소 용량을 0.5 OCUs (OpenSearch Compute Units) 로 낮췄습니다. 이를 통해 고가용성 및 확장 가능한 벡터 데이터베이스의 기본 비용이 스타트업 친화적인 수준으로 내려가면서도, 애플리케이션이 급성장할 경우 자동 확장을 제공합니다.

설계 고려 사항

콜드 스타트

RAG 앱이 비활성 상태 후 첫 번째 요청에 대해 서브초 수준의 지연 시간을 요구한다면, Lambda Provisioned Concurrency를 사용하여 워밍된 인스턴스를 준비해 두는 것을 고려하세요.

스케일링 지연

OpenSearch Serverless는 자동으로 스케일링하지만, 대규모 급증에 대해 즉시 스케일링되지 않을 수 있습니다. max OCUs를 적절히 설정하고 스케일링 동작을 부하 테스트하세요.

벤더 종속성

AWS 기본 서비스(Bedrock, Lambda, OpenSearch Serverless)를 사용하고 있습니다. 통합이 Bedrock 및 OpenSearch API에 대한 표준 HTTP 요청에 의존하기 때문에, 나중에 애플리케이션 로직을 마이그레이션하는 것이 여전히 가능합니다.

결론

AI 제품을 검증하기 위해 과도하게 크고 활용되지 않는 벡터 데이터베이스에 과도한 비용을 지불하던 시대는 끝났습니다. Amazon Bedrock, Lambda, OpenSearch Serverless를 활용하면 Day 1부터 엔터프라이즈급 이벤트‑드리븐 AI 아키텍처를 구축할 수 있습니다.

원래는 내 Hashnode 블로그에 게시되었습니다: [HASHNODE_LINK]