Weaviate 단일 서버에서 100만 벡터 메모리 사용량과 한국어 임베딩 운영 비용 계산법

100만 개 한국어 문서를 벡터로 올리기 전에, 팀장이 물어봐요.

“서버 얼마짜리 쓸 거야?”

“그냥 넉넉하게요"라고 답했다가는, 월 수백만 원짜리 인프라를 돌리게 될 수 있어요. 반대로 너무 빡빡하게 잡으면 프로덕션 올리고 나서 OOM으로 서버가 죽죠.

실제로 계산해봤어요. 모델 차원 수별 메모리 실측치, 서버 스펙별 비용, 한국어 임베딩 선택이 운영비에 미치는 영향까지요.

이 글에서 다룰 내용이에요:

• 벡터 1개당 메모리 계산 공식 (임베딩 모델별 차이 포함)
• 100만 벡터 기준 실측 메모리 추정치
• 단일 서버 구성별 비용 비교
• 한국어 임베딩 모델 선택이 운영비에 미치는 영향

핵심 요약

• Weaviate에서 벡터 1개의 메모리 점유는 차원 수 × 4바이트(float32) 공식으로 계산되며, 1536차원 모델 기준 100만 벡터에 약 6GB의 벡터 전용 RAM이 필요하다.
• 한국어 특화 모델(klue/roberta-base 등 768차원)은 영어 대형 모델(text-embedding-3-large 3072차원) 대비 벡터 메모리를 4분의 1 수준으로 줄일 수 있다.
• Weaviate는 벡터 외에도 HNSW 인덱스, 객체 스토리지, 오버헤드를 포함해 실제 RAM 사용량이 벡터 순수 용량의 2~3배에 달한다.
• AWS ap-northeast-2 기준, 100만 벡터 단일 서버 운영에 월 15만~45만 원 범위의 인프라 비용이 발생하며, 모델 차원 수 선택이 가장 큰 비용 변수다.

Weaviate가 메모리를 쓰는 방식

Weaviate는 HNSW(Hierarchical Navigable Small World) 그래프 기반 인덱스를 쓰는 오픈소스 벡터 데이터베이스예요. Pinecone, Qdrant 같은 제품과 달리, 객체 스토리지(텍스트 원문, 메타데이터)와 벡터 인덱스를 한 곳에서 관리하는 구조라 메모리 구성이 좀 복잡해요.

RAM 사용량은 크게 세 덩어리로 나뉘어요:

1. 벡터 데이터 자체: 차원 수 × 4바이트(float32) × 벡터 개수
2. HNSW 인덱스: 그래프 연결 정보 저장 — 보통 벡터 데이터의 50~100% 추가 메모리 소비
3. 객체 스토리지 + JVM 오버헤드: 원문 텍스트, 메타데이터, 내부 캐시

Weaviate v1.24 이상에서는 PQ(Product Quantization)와 SQ(Scalar Quantization) 압축을 지원하는데, 이걸 쓰면 벡터 메모리를 4~8배 줄일 수 있어요. 단, 검색 정확도(recall)가 약간 떨어지는 트레이드오프가 있어요.

국내 LLM 서비스들이 PoC를 넘어 프로덕션 단계로 이동하면서, “돌아가게 만들기"에서 “돈이 얼마나 들지"로 관심사가 이동했어요. GPT 임베딩 API를 쓰다가 자체 서버로 전환하거나, 클라우드 벡터DB에서 자체 호스팅으로 옮기는 팀들이 이 계산을 피할 수 없는 시점이 왔거든요.

100만 벡터 메모리 실측: 모델 차원 수별 계산

벡터 순수 용량 계산

계산 공식 자체는 단순해요:

벡터 메모리(GB) = (차원 수 × 4바이트 × 벡터 개수) ÷ (1024³)

100만 벡터 기준 주요 모델별 계산값이에요:

3GB 차이가 별거 아닌 것 같지만, HNSW 인덱스와 오버헤드를 얹으면 이야기가 달라져요.

HNSW 인덱스가 만드는 실제 메모리 배수

Weaviate의 HNSW 인덱스는 기본 파라미터(ef_construction=128, maxConnections=64) 기준으로 벡터 데이터의 약 6080%를 추가로 사용해요. 여기에 객체 스토리지(문서당 평균 500바이트 가정)와 JVM 힙 오버헤드(기본 24GB)까지 더하면 아래 표처럼 나와요.

16GB 서버로 768차원 모델은 여유 있게 돌아가지만, 1536차원은 빡빡하고, 3072차원은 32GB 서버가 필요한 셈이에요.

PQ 압축 적용 시 변화

Weaviate의 Product Quantization을 쓰면 벡터 메모리를 4분의 1에서 8분의 1로 줄일 수 있어요. 768차원 기준 3.0GB가 0.40.75GB로 내려가죠. 다만 recall@10이 95%대에서 8892%대로 떨어지는 걸 감수해야 해요. FAQ 검색처럼 정확도보다 속도가 중요한 케이스엔 좋은 선택이에요.

단일 서버 구성별 실제 운영 비용

AWS ap-northeast-2 기준 비용 분석

AWS 서울 리전 기준, 온디맨드 가격(2026년 3월 기준)으로 계산했어요.

1년 예약 인스턴스로 전환하면 온디맨드 대비 35~40% 저렴해져요. 프로덕션 운영이 확정됐다면 예약 인스턴스가 합리적이에요.

Weaviate Cloud vs 자체 호스팅 비교

Weaviate Cloud(WCD)를 쓰는 선택지도 있어요. Particula Tech의 2026년 분석에 따르면, Weaviate Cloud Standard 플랜은 100만 벡터 기준 월 약 $150250(한화 2033만 원) 수준이에요. 인프라 관리 비용(엔지니어 공수)을 아끼는 대신 유연성은 줄어들죠.

자체 호스팅이 유리한 경우:

• 데이터 규제(금융, 의료)로 클라우드 SaaS 사용 불가
• 벡터 수가 500만 개 이상으로 클라우드 비용이 급격히 올라갈 때
• 이미 Kubernetes 운영 인력이 있는 팀

Weaviate Cloud가 유리한 경우:

• DevOps 인력이 없는 스타트업
• PoC 단계 또는 벡터 수가 100만 개 이하
• 빠른 프로토타이핑이 필요할 때

한국어 서비스 팀이 지금 해야 할 결정

모델 선택이 비용 구조를 만든다

한국어 서비스라면 768차원 한국어 특화 모델이 출발점으로 좋아요. ko-sroberta-multitask나 klue/roberta-base 기반 모델은 한국어 검색 품질이 영어 대형 모델 대비 크게 뒤지지 않으면서, 서버 비용을 절반 이하로 낮출 수 있거든요.

다국어 지원이 필요하다면 bge-m3(1024차원)나 multilingual-e5-large가 현실적인 중간 지점이에요.

지금 당장 체크해야 할 세 가지

1. 현재 또는 목표 벡터 수 확인: 10만, 100만, 1000만은 완전히 다른 서버 스펙이에요. 1000만 개부터는 단일 서버보다 샤딩을 검토해야 해요.
2. PQ 압축 허용 여부: 검색 정확도 허용 범위가 recall@10 기준 90% 이상이면 PQ로 서버 등급을 한 단계 낮출 수 있어요.
3. 1년 로드맵 확인: 6개월 내 벡터 수가 세 배에서 네 배 증가할 예정이라면, 지금 16GB 서버로 시작해도 6개월 뒤 마이그레이션 비용이 더 클 수 있어요.

“넉넉하게"가 아니라 “계산하고”

Weaviate 단일 서버 100만 벡터 운영에서 메모리 실측 결과를 정리하면 이래요:

• 768차원 한국어 모델 기준: 총 8~10GB RAM, 16GB 서버로 충분
• 1536차원 범용 모델 기준: 총 13~15GB RAM, 32GB 서버 필요
• 3072차원 대형 모델 기준: 총 22~25GB RAM, 32GB도 위험, 64GB 권장
• HNSW 인덱스 오버헤드가 벡터 데이터만큼 메모리를 잡아먹는다는 사실, 빠뜨리면 안 돼요

한국어 임베딩 운영 비용에서 가장 큰 레버는 모델 차원 수예요. 3072차원과 768차원의 월 인프라 비용 차이가 두 배를 넘을 수 있으니까요. 서버를 고르기 전에 모델을 고르고, 모델을 고르기 전에 벡터 수와 정확도 요구사항부터 확정하는 순서로 결정해 보세요.

그다음 단계로 검토할 것: 벡터 수가 500만 개를 넘어가는 시점에 단일 서버와 멀티 샤드 Weaviate 클러스터의 비용 분기점은 어디일까요? 그 계산도 꽤 흥미로운 주제예요.

참고자료

1. 벡터디비 및 임베딩 관련 글 :: By oneself
2. Weaviate 완전 정복: 오픈소스 벡터 데이터베이스의 모든 것
3. Weaviate Pricing in 2026: Free Tier, Plans, and Real Costs

Photo by Maria Ionova on Unsplash