벡터 DB 5곳, 차원 수가 요금을 정합니다

글쓴이김성진·발행일2026년 8월 25일

차원 수는 성능 지표가 아니라 매달 나가는 돈입니다

내 문서를 AI가 찾아서 대답하게 만들고 싶을 때, 문서를 숫자 덩어리로 바꿔서 어딘가에 쌓아 둬야 합니다.

그 숫자 덩어리를 임베딩(문장의 뜻을 숫자 목록으로 바꾼 것)이라고 부르고, 쌓아 두는 창고를 벡터 데이터베이스라고 부릅니다.

여기까지가 이 글을 읽는 데 필요한 사전 지식 전부입니다.

문제는 창고를 고르는 순간 시작됩니다. 다섯 곳의 요금 페이지를 열어 보면 이렇게 적혀 있습니다.

파인콘은 기가바이트당 0.33달러. 크로마도 기가바이트당 0.33달러. 위비에이트는 100만 차원당 0.00465달러. 큐드란트는 아예 단가가 안 적혀 있습니다. pgvector는 0원입니다.

단위가 넷 다 다릅니다. 그래서 나란히 놓고 봐야 아무것도 안 보입니다.

그런데 이 넷을 하나로 묶는 값이 하나 있습니다. 벡터의 차원 수입니다.

차원 수는 임베딩 하나가 숫자 몇 개짜리인지를 말합니다. 오픈AI의 text-embedding-3-large는 기본이 3,072개, text-embedding-3-small은 1,536개입니다. 이건 오픈AI 임베딩 가이드에 그대로 적혀 있는 값입니다.

숫자 하나가 4바이트니까, 3,072차원짜리 벡터 한 개는 12,288바이트를 씁니다. 100만 개면 12.288기가바이트입니다.

그리고 이 12.288기가바이트가 매달 청구서에 올라갑니다. 임베딩을 만드는 값은 한 번 내고 끝이지만, 저장은 안 끝납니다.

이 글은 RAG(내 문서를 AI에게 물어보게 만드는 방식)를 처음 붙여 보려는 사람, 그리고 이미 붙였는데 청구서가 왜 이 모양인지 모르겠는 사람을 위한 것입니다. 다섯 곳의 공식 요금 페이지를 2026년 8월 25일에 직접 열어 확인했고, 확인 못 한 숫자는 마지막에 따로 적어 뒀습니다.

환율은 1달러 1,385.48원(2026년 8월 24일 기준)으로 환산했습니다.

3,072차원을 256차원으로 줄여도 옛 모델보다 정확합니다

먼저 이 글의 결론에 해당하는 사실 하나를 앞에 놓겠습니다.

오픈AI 공식 문서는 dimensions 파라미터로 임베딩 차원을 줄일 수 있다고 안내하면서, 이렇게 적어 놨습니다.

text-embedding-3-large 임베딩은 크기 256으로 줄여도, 크기 1536짜리 줄이지 않은 text-embedding-ada-002 임베딩보다 성능이 좋습니다.

즉 3,072차원을 256차원으로 12분의 1로 깎아도, 한 세대 전 모델을 온전히 쓰는 것보다 낫다는 뜻입니다.

그리고 저장 비용은 정확히 12분의 1이 됩니다. 차원이 12분의 1이면 바이트도 12분의 1이니까요.

여기서 짚어야 할 게 하나 있습니다. 사람들은 임베딩 모델을 고를 때 벤치마크 점수만 봅니다. 3-large가 3-small보다 점수가 높으니 3-large를 씁니다.

그 선택이 벤치마크가 아니라 매달 청구서에 12배로 찍힌다는 걸 요금 페이지 어디에도 안 적어 놨습니다. 임베딩 회사는 토큰으로 돈을 받고, 창고 회사는 바이트로 돈을 받으니, 둘 사이를 잇는 차원 수는 아무도 설명하지 않습니다.

물론 차원을 줄이면 검색 품질은 조금 떨어집니다. 위 인용문이 보장하는 건 “256차원 3-large가 1,536차원 ada-002보다 낫다”는 것이지, “3,072차원과 같다”는 게 아닙니다. 그건 각자 데이터로 재 봐야 하는 값입니다.

다만 재 보지도 않고 기본값을 쓰는 것과, 재 보고 기본값을 쓰는 것은 다릅니다. 이 글은 그 차이를 만들려고 씁니다.

위비에이트만 대놓고 차원으로 청구서를 씁니다

다섯 곳 중 요금 단위에 “차원”이라고 못 박은 곳은 위비에이트 한 곳뿐입니다.

위비에이트 요금 페이지는 “저장된 벡터 차원의 총 개수가 필요한 자원을 나타내는 좋은 지표”라고 적어 두고, 등급별로 이렇게 받습니다.

“부터”가 붙은 이유도 페이지에 적혀 있습니다. 차원 단가가 인덱스 종류·압축 방식·리전에 따라 달라진다고 명시하고, 내 데이터 기준 단가는 콘솔의 Running Costs 모듈에서 보라고 안내합니다.

무료 샌드박스는 계정당 클러스터 하나이고, 오브젝트 10만 개 · 메모리 1GB · 디스크 10GB까지입니다.

10만 개라는 숫자를 기억해 두세요. 문서를 조각내서 넣다 보면 생각보다 빨리 넘습니다. A4 한 장짜리 문서 1만 개를 500토큰 단위로 자르면 이미 10만 조각 근처입니다.

파인콘과 크로마는 기가바이트로 받는데, 그 기가바이트도 차원이 정합니다

두 곳은 저장 단가가 소수점까지 똑같습니다. 우연이지만 비교하기엔 편합니다.

파인콘은 요금 페이지에서 이렇게 받습니다.

백업은 GB당 월 $0.10, 데이터 임포트는 GB당 $0.25가 따로 붙습니다. Standard는 3주 체험에 $300 크레딧이 들어 있고, HIPAA 애드온은 월 $190입니다.

읽기·쓰기 단가에 폭이 있는 건 클라우드와 리전에 따라 달라지기 때문입니다.

크로마 클라우드는 요금 문서에서 셋으로 쪼개 받습니다.

• 쓰기: 논리 GiB당 $2.50 — add·update·upsert로 실제로 밀어 넣은 양 기준입니다. 백그라운드 압축이나 재색인은 다시 안 받는다고 명시돼 있습니다.
• 저장: GiB당 월 $0.33, 시간 단위로 비례 계산합니다.
• 읽기: 조회한 양 TiB당 $0.0075, 돌려받은 양 GiB당 $0.09.

포크는 요청당 $0.03, 싱크는 처리량 GiB당 $0.04에 문서 페이지 추출·스크랩이 각각 페이지당 $0.01입니다.

크로마에는 월 최소 요금이 없습니다. 신규 사용자에게 $5 크레딧을 줍니다. 다섯 곳 중 “안 쓰면 0원”에 가장 가까운 관리형 서비스가 여깁니다.

대신 쓰기 단가가 셉니다. GiB당 $2.50이면 12기가바이트를 처음 밀어 넣을 때만 30달러 가까이 나갑니다. 이건 뒤에서 계산해 보겠습니다.

큐드란트는 단가를 안 내놓는 대신 계산식을 내놨습니다

큐드란트 요금 페이지에는 달러 숫자가 한 개도 없습니다.

적혀 있는 건 과금 방식뿐입니다. “클러스터가 쓴 컴퓨트(vCPU)·메모리(GB)·저장(GB), 백업이 쓴 저장(GB), 유료 모델 추론 토큰”을 시간 단위로 계산한다고만 하고, 구체적인 금액은 계산기를 쓰라고 안내합니다.

무료 등급은 0.5 vCPU / 램 1GB / 디스크 4GB 단일 노드입니다. Standard는 사용량 기반, Premium은 최소 지출이 필요하다고만 적혀 있고 액수는 없습니다.

요금은 안 알려주지만 대신 아주 유용한 걸 공개합니다. 용량 산정 문서에 벡터가 자원을 얼마나 먹는지 계산식이 그대로 나와 있습니다.

base = 포인트 수 × 복제 계수
dense_size = base × 차원 수 × 차원당 바이트

차원당 바이트는 자료형이 정합니다. float32 = 4바이트(기본), float16 = 2바이트, uint8 = 1바이트, turbo4 = 0.5바이트.

문서에 실린 예시가 이 글의 주장을 그대로 증명합니다.

포인트 100만 개, 768차원, 복제 계수 2, float32, 기본 cached 등급: base = 1,000,000 × 2 = 2,000,000 dense_size = 2,000,000 × 768 × 4바이트 ≈ 5.72GB

그리고 4비트 TurboQuant(8배 압축, 차원당 0.5바이트)를 켜고 원본을 cold로 내리면 같은 데이터가 0.72GB가 됩니다.

HNSW 인덱스와 페이로드에는 1.5배 오버헤드가 더 붙는다고도 적혀 있습니다. 램 용량을 잡을 때 이 1.5를 빼먹으면 클러스터가 부족해집니다.

큐드란트 본체는 아파치 2.0 라이선스라 직접 서버에 올려 쓰는 건 공짜입니다. docker run -p 6333:6333 qdrant/qdrant 한 줄이면 뜹니다. 관리형을 안 쓰면 요금표가 없어도 아쉬울 게 없습니다.

pgvector에는 2,000차원짜리 벽이 있습니다

이미 포스트그레스를 쓰고 있다면 창고를 새로 사지 않아도 됩니다. pgvector는 포스트그레스에 벡터 검색을 붙이는 확장이고, 라이선스는 포스트그레스 라이선스입니다. 값은 0원입니다.

같은 데이터베이스 안에 벡터와 일반 데이터가 같이 있으니 트랜잭션도 백업도 그대로 굴러갑니다. 이게 가장 큰 장점입니다.

그런데 여기에 함정이 하나 있고, 그게 정확히 차원 얘기입니다.

vector 타입에는 16,000차원까지 넣을 수 있습니다. 하지만 검색을 빠르게 해 주는 HNSW 인덱스는 2,000차원까지만 걸립니다.

오픈AI text-embedding-3-large의 기본값이 3,072차원입니다.

즉 기본 설정 그대로 pgvector에 넣으면 인덱스를 못 만듭니다. 데이터는 들어가는데 검색이 전수 조사로 떨어집니다. 문서가 몇천 개일 땐 티가 안 나다가, 몇십만 개가 되면 조회가 눈에 띄게 느려집니다.

빠져나갈 길은 둘입니다. halfvec으로 바꾸면 4,000차원까지 인덱스가 걸리고 저장 공간도 절반(차원당 2바이트)이 됩니다. 아니면 애초에 임베딩을 1,536차원 이하로 만들면 됩니다.

어느 쪽이든 결정을 내리는 값은 또 차원 수입니다.

그리고 pgvector가 공짜라고 포스트그레스가 공짜인 건 아닙니다. 수파베이스 요금 기준으로 무료 플랜은 데이터베이스 500MB, Pro는 월 $25부터에 프로젝트당 디스크 8GB가 포함되고 초과분은 GB당 $0.125입니다. Team은 월 $599부터입니다.

GB당 $0.125면 파인콘·크로마의 $0.33보다 쌉니다. 다만 벡터 전용 인덱스 튜닝은 직접 해야 합니다.

조각 100만 개를 넣으면 청구서가 이렇게 갈립니다

이제 숫자를 한자리에 놓겠습니다. 조건은 이렇습니다.

• 문서 조각 100만 개 (A4 기준 대략 문서 10만 장 분량)
• 조각당 평균 500토큰
• 자료형은 기본값 float32(차원당 4바이트)
• 복제·백업은 계산에서 뺐습니다

먼저 임베딩을 만드는 값입니다. 이건 한 번만 냅니다.

100만 조각 × 500토큰 = 5억 토큰입니다. 오픈AI 요금표 기준으로:

한 번에 9만 원이면 감당할 만합니다. 그래서 다들 3-large를 씁니다.

그다음이 매달 나가는 저장 값입니다.

3,072차원이면 100만 × 3,072 × 4바이트 = 12.288GB(11.44GiB), 총 차원 수는 30억 7,200만 개입니다.

256차원으로 줄이면 1.024GB(0.95GiB), 총 차원 수는 2억 5,600만 개입니다.

차원을 12분의 1로 줄이면 모든 칸이 정확히 12분의 1이 됩니다. 예외가 없습니다.

그리고 임베딩 값(9만 원)보다 저장 값이 더 큰 지점이 생각보다 빨리 옵니다. 3,072차원 그대로 파인콘 Standard에 두면 저장만 연 $48.7(약 6만 8천 원)입니다. 2년이면 임베딩을 다시 만드는 값을 넘어섭니다.

즉 차원을 줄이고 임베딩을 다시 만드는 쪽이 이득으로 뒤집히는 시점이 있습니다. 데이터를 오래 들고 갈수록 그 시점은 빨리 옵니다.

최소 요금이 절약을 통째로 삼키는 구간

위 표를 보고 “그럼 위비에이트가 제일 비싸네”라고 결론 내면 절반만 맞습니다.

월 최소 요금이 있기 때문입니다.

위비에이트 Flex는 최소 $45/월입니다. 3,072차원 계산값이 $14.28 + $1.37 = $15.65인데, 최소가 $45라 $45(약 62,300원)를 냅니다.

256차원으로 줄이면 계산값은 $1.30이 되는데, 그래도 $45를 냅니다. 12분의 1로 줄인 노력이 청구서에 한 푼도 안 나타납니다.

파인콘도 같습니다. Standard는 최소 사용 $50/월이라, 저장이 $4든 $0.34든 **$50(약 69,300원)**입니다. Builder는 아예 월 $20 정액입니다.

정리하면 이렇습니다.

작게 시작하는 사람에게 차원 최적화는 아직 할 일이 아닙니다. 최소 요금이 없는 크로마이거나, 셀프호스팅 큐드란트이거나, pgvector여야 절약이 실제로 통장에 남습니다.

반대로 데이터가 커져서 최소 요금을 넘어선 뒤에는, 차원 수가 청구서에 1대 1로 반영됩니다. 그때는 임베딩 모델을 다시 고르는 게 인프라 최적화보다 효율이 좋습니다.

이 구조는 AI 모델 게이트웨이 비교에서 본 것과 정반대입니다. 거기선 호출 수가 곧 요금이라 처음부터 단가가 그대로 걸렸는데, 벡터 DB는 최소 요금이 바닥을 깔고 있어서 작을 땐 뭘 해도 똑같고 커지면 갑자기 다 걸립니다.

쓰기와 읽기는 또 따로 셉니다

저장만 보면 안 됩니다. 세 곳은 데이터를 넣고 꺼내는 데도 값을 매깁니다.

크로마의 첫 쓰기가 가장 눈에 띕니다. 논리 GiB당 $2.50이라, 3,072차원 100만 조각(11.44GiB)을 처음 밀어 넣으면 **$28.61(약 39,600원)**이 한 번에 나갑니다.

이게 저장 7개월 반 치입니다. 크로마를 고르면서 “월 $3.78이면 싸다”고만 계산하면 첫 달 청구서에서 놀랍니다.

다만 크로마는 백그라운드 압축·재색인을 다시 안 받는다고 못 박아 뒀습니다. 넣은 만큼만 한 번 받겠다는 뜻이라, 데이터를 자주 갈아엎지 않는다면 합리적입니다.

파인콘은 읽기·쓰기를 “유닛”으로 셉니다. Standard 기준 쓰기 유닛 100만당 $44.50, 읽기 유닛 100만당 $1618입니다.

여기서 솔직하게 적겠습니다. 조회 한 번이 읽기 유닛 몇 개인지는 이 글에서 확인하지 못했습니다. 레코드 크기와 질의 형태에 따라 달라지는 값이라, 아무 계수나 가정해서 곱하면 그 순간 이 글의 숫자가 전부 거짓말이 됩니다. 그래서 안 곱했습니다.

크로마의 읽기는 단위가 아예 다릅니다. 조회한 양 TiB당 $0.0075에 돌려받은 양 GiB당 $0.09입니다. 벡터 유사도 질의뿐 아니라 메타데이터·전문 검색 조건도 질의 단위로 추가됩니다.

TiB당 $0.0075는 굉장히 싸 보이지만, 인덱스 없이 전수 조사가 도는 구조라면 조회 한 번에 스캔량이 훅 뜁니다. 여기서도 차원이 크면 스캔할 바이트가 커집니다.

위비에이트는 이 표에 읽기·쓰기 항목이 없습니다. 차원과 저장, 백업으로 받습니다. 데이터 전송은 현재 프로모션 기간이라 무료인데, 나중에 유료로 바꿀 수 있다고 페이지에 미리 적어 뒀습니다.

신용카드 없이 굴러가는 구간

각 서비스가 돈 안 받고 어디까지 해 주는지만 모아 봤습니다.

파인콘 2GB가 실제로 얼마인지 환산해 보겠습니다. 3,072차원 float32면 벡터 하나가 12,288바이트니까 약 16만 3천 개가 들어갑니다. 256차원으로 줄이면 195만 개가 들어갑니다.

같은 무료 한도인데 차원을 줄이는 것만으로 12배를 더 넣습니다. 개인 프로젝트라면 이 한 번의 선택으로 유료 전환 자체를 안 하게 될 수도 있습니다.

위비에이트의 10만 개는 오브젝트 수 기준이라 차원과 무관합니다. 대신 메모리 1GB 제한이 있어서, 차원이 크면 오브젝트 10만 개를 못 채우고 메모리에서 먼저 막힙니다.

차원을 줄이는 세 가지 방법과 각각의 대가

차원이 요금을 정한다면, 줄이는 방법도 알아야 합니다. 셋입니다.

첫째, 임베딩을 만들 때부터 짧게 뽑습니다. 오픈AI API의 dimensions 파라미터가 이걸 합니다. 3-large를 256·512·1024차원으로 뽑을 수 있습니다.

대가는 검색 품질입니다. 다만 공식 문서가 “256차원도 1,536차원 ada-002보다 낫다”고 보장하니, 출발점을 256으로 잡고 올려 가며 재는 게 합리적입니다.

둘째, 자료형을 바꿉니다. float32 대신 float16을 쓰면 차원당 4바이트가 2바이트가 됩니다. 차원 수는 그대로인데 용량이 절반입니다.

큐드란트는 float16·uint8·turbo4를 자료형으로 지원하고, pgvector는 halfvec이 같은 역할을 합니다. pgvector에서는 이 선택이 인덱스 가능 차원을 2,000에서 4,000으로 늘려 주기까지 합니다.

대가는 정밀도입니다. 대부분의 검색 용도에서는 체감이 거의 없지만, 재현율은 직접 재 봐야 합니다.

셋째, 양자화를 켭니다. 압축본을 따로 만들어 검색은 압축본으로 하고, 최종 순위만 원본으로 다시 매기는 방식입니다.

큐드란트 문서의 실측이 명확합니다. 4비트 TurboQuant(8배 압축)로 램 사용량이 5.72GB에서 0.72GB로 떨어집니다. 디스크는 원본을 그대로 두니 거의 안 줄지만, 램이 비싼 자원이라 관리형 요금에서는 이쪽이 더 큽니다.

큐드란트 문서는 여기에 경고를 붙여 놨습니다. 일부 임베딩 모델은 양자화가 잘 안 먹으니, 압축 안 한 결과와 재현율을 반드시 비교하라는 것입니다.

세 방법은 겹쳐 쓸 수 있습니다. 256차원 + float16이면 3,072차원 float32 대비 24분의 1입니다.

순서를 이렇게 잡으면 뒤집을 일이 없습니다

지금까지 나온 것들을 결정 순서로 다시 세웁니다. 요금표를 먼저 보면 틀립니다.

1단계 — 조각이 몇 개가 될지부터 셉니다. 문서 수가 아니라 조각 수입니다. 문서 1만 개를 500토큰으로 자르면 조각은 10만 개대가 됩니다. 이 숫자가 무료 한도 안이면 나머지 고민은 아직 이릅니다.

2단계 — 차원을 먼저 정합니다. 창고보다 먼저입니다. 256으로 시작해서 내 데이터로 재현율을 재고, 부족하면 512·1024로 올립니다. 3,072를 기본값이라는 이유로 쓰지 않습니다.

3단계 — 이미 포스트그레스가 있으면 pgvector부터 시도합니다. 단 차원이 2,000을 넘으면 halfvec으로 잡거나 차원을 내립니다. 이 확인을 안 하면 인덱스 없이 굴러가다 나중에 느려집니다.

4단계 — 관리형이 필요하면 최소 요금부터 봅니다. 규모가 작고 트래픽이 들쭉날쭉하면 월 최소가 없는 크로마, 데이터를 크게 오래 들고 갈 거면 차원 단가가 낮은 위비에이트 상위 등급, 운영을 직접 하기 싫고 규모가 중간이면 파인콘 순으로 봅니다.

5단계 — 직접 굴릴 수 있으면 큐드란트 셀프호스팅이 가장 쌉니다. 아파치 2.0에 도커 한 줄이고, 용량 계산식이 공개돼 있어 서버 크기를 미리 잡을 수 있습니다. 로컬 LLM 실행 도구를 이미 직접 굴리고 있다면 여기까지 같이 가는 편이 자연스럽습니다.

6단계 — 옮길 수 있게 짜 둡니다. 벡터 DB는 갈아타기가 비교적 쉽습니다. 원본 문서와 임베딩만 갖고 있으면 다시 밀어 넣으면 되니까요. 대신 임베딩을 안 갖고 있으면 다시 만들어야 하고, 그게 아까 계산한 9만 원입니다. 임베딩 원본은 따로 보관해 두세요.

문서를 아직 다 모으지 못했다면, 창고보다 웹 검색 API를 먼저 붙이는 게 나을 수도 있습니다. 남의 색인을 빌리면 저장 비용이 0이니까요.

이 글에서 못 채운 칸

비교 글은 빈칸을 숨기면 가치가 떨어집니다. 확인 못 한 것을 그대로 적습니다.

큐드란트 클라우드의 단가. 요금 페이지에 vCPU·GB·시간 단위로 받는다고만 적혀 있고 금액이 없습니다. 계산기를 돌리면 나오지만, 계산기 출력값은 조건에 따라 달라져서 “공식 요금표”라고 부르기 어렵습니다. 그래서 큐드란트는 관리형 금액 없이 무료 등급과 계산식만 적었습니다.

파인콘 읽기 유닛의 환산 계수. 조회 한 번이 몇 유닛인지 확인하지 못해서 질의 비용을 계산하지 않았습니다. 세 곳의 조회 비용을 나란히 비교하지 못한 이유입니다.

차원을 줄였을 때의 실제 검색 품질 하락 폭. 오픈AI 문서의 “256차원이 1,536차원 ada-002보다 낫다”는 문장 하나만 근거로 썼습니다. 우리 데이터로 재현율을 직접 재 보지 않았습니다.

위비에이트·파인콘의 “부터” 가격. 둘 다 인덱스 종류·리전·클라우드에 따라 단가가 달라진다고 명시합니다. 이 글의 계산은 공개된 최저 단가 기준이라 실제 청구서는 이보다 높을 수 있습니다.

직접 운영해 본 대상. 다섯 곳 모두 이 글을 위해 요금 문서를 조회한 것이지, 프로덕션에서 운영해 본 결과가 아닙니다.

마지막으로 남는 한 문장

벡터 DB를 고르는 일은 창고를 고르는 일처럼 보이지만, 실제로는 짐의 크기를 정하는 일입니다.

파인콘·크로마는 기가바이트로, 위비에이트는 차원으로, 큐드란트는 서버 자원으로, pgvector는 인덱스 가능 차원으로 받습니다. 단위는 넷인데 결국 하나가 정합니다.

임베딩 모델을 고르는 화면에는 벤치마크 점수만 있고 차원 수는 작은 글씨로 적혀 있습니다. 그 작은 글씨가 매달 청구서에 12배로 곱해집니다.

오늘 할 수 있는 건 하나입니다. 지금 쓰는 임베딩의 차원이 몇인지 확인하고, 그 절반이나 4분의 1로 줄였을 때 검색 결과가 실제로 나빠지는지 재 보세요.

안 나빠지면 그대로 두면 됩니다. 그게 매달 나가는 돈이니까요.