text-embedding-3-small 차원(Dimensions) 설명: 1536 vs 1024 vs 512

text-embedding-3-small을 사용한다면, 하나의 작은 설정이 전체 검색 시스템(retrieval system)에 조용히 영향을 미칠 수 있습니다. 바로 임베딩 차원(embedding dimensions)입니다.

기본 벡터 길이는 1536 차원입니다. 이는 좋은 기본값입니다. 하지만 벡터 데이터베이스(vector database)에 수백만 개의 청크(chunks)를 저장하게 되면, 이것이 항상 가장 저렴하거나 빠른 선택은 아닙니다.

이 가이드는 text-embedding-3-small 차원이 무엇을 의미하는지, 언제 1536을 유지해야 하는지, 언제 더 작은 벡터를 테스트해야 하는지, 그리고 실제 코드로 OpenAI 호환 임베딩 엔드포인트(embeddings endpoint)를 호출하는 방법을 설명합니다.

text-embedding-3-small 차원이란 무엇인가?

임베딩(embedding)은 텍스트를 숫자 리스트로 변환합니다. 그 리스트가 바로 벡터(vector)입니다.

text-embedding-3-small의 경우, 기본 벡터는 1536개의 숫자를 가집니다. 만약 다음과 같은 문장을 임베딩한다면:

“API gateways help developers route model calls.”

모델은 해당 입력 전체의 의미를 나타내는 하나의 벡터를 반환합니다. 벡터는 단어당 하나의 숫자로 구성되는 것이 아닙니다. 당신이 보내는 입력 텍스트에 대한 하나의 의미론적 표현(semantic representation)입니다.

그 다음 pgvector, Pinecone, Milvus, Weaviate, Chroma 또는 Qdrant와 같은 벡터 데이터베이스(vector database)에 해당 벡터를 저장합니다. 사용자가 검색을 수행하면, 쿼리(query)를 임베딩하고 이를 저장된 벡터들과 비교합니다.

OpenAI 공식 문서에 따르면 text-embedding-3-small은 기본적으로 1536 차원을 사용하며, text-embedding-3-large는 기본적으로 3072 차원을 사용합니다. 또한 출력 벡터의 길이를 줄일 수 있는 dimensions 파라미터(parameter)를 지원합니다.

외부 참조:

외부 참조:

• OpenAI embeddings guide
• OpenAI text-embedding-3-small model page
• Stack Overflow discussion on embedding dimensions

text-embedding-3-small의 기본 차원: 1536이 일반적인 이유

1536차원은 기본값(default)이기 때문에 인기가 많습니다. 또한, 많은 시맨틱 검색(semantic search) 및 RAG 워크로드에 대해 품질과 비용 사이에서 실용적인 균형을 제공합니다.

다음과 같은 경우 기본 1536차원을 사용하세요:

• 첫 번째 검색 시스템을 구축하는 경우.
• 아직 평가 데이터가 없는 경우.
• 데이터셋이 작아서 벡터 저장에 큰 부담이 아닌 경우.
• 저장 공간 몇 기가바이트보다 검색 품질이 더 중요한 경우.
• 첫 출시 단계에서 움직이는 부분이 적기를 원하는 경우.

마지막 점이 중요합니다. 앱이 아직 초기 단계라면, 가장 큰 위험은 보통 벡터 크기가 아닙니다. 나쁜 청킹(chunking), 약한 검색 평가(retrieval evaluation), 누락된 메타데이터 필터, 또는 부실한 프롬프트가 원인일 수 있습니다.

간단하게 시작하고, 그 다음에 최적화하세요.

dimensions 파라미터: 무엇이 바뀌고 무엇이 바뀌지 않는가

dimensions 파라미터는 더 짧은 임베딩 벡터를 요청할 수 있게 해줍니다.

예를 들어, 기본 1536차원 벡터를 요청하는 대신, 제공업체가 해당 모델에 대해 지원한다면 1024, 768 또는 512 차원을 요청할 수 있습니다.

변화하는 것:

영역	1536 차원	1024 / 768 / 512 차원
벡터 저장 공간	더 큼 (Larger)	더 작음 (Smaller)
...

보통 변하지 않는 것: 전송하는 입력 토큰(input tokens)의 수입니다. 임베딩 API 가격은 일반적으로 최종 벡터 크기가 아닌 입력 토큰을 기반으로 책정됩니다.

이는 더 작은 차원(dimensions)이 주로 저장 공간(storage), 인덱스 메모리(index memory), 그리고 검색 속도(retrieval speed)를 개선하는 데 도움이 된다는 것을 의미합니다. 차원을 줄이는 것이 임베딩 생성 비용(embedding generation bill)을 줄이는 마법 같은 방법은 아닙니다.

저장 공간 계산: 1536 vs 1024 vs 512 차원

float32 숫자는 4바이트(bytes)를 사용합니다. 따라서 원시 벡터 크기(raw vector size)는 다음과 같습니다:

vector_size_bytes = dimensions × 4

벡터 1개 기준:

차원 (Dimensions)	벡터당 바이트 (Bytes per vector)	1536 대비 저장 공간 (Storage vs 1536)
1536	6,144 bytes	기준점 (Baseline)
...

100만 개의 청크(chunks)에 대한 원시 float32 벡터 저장 공간은 다음과 같습니다:

차원 (Dimensions)	원시 벡터 저장 공간 (Raw vector storage)	약 35%의 인덱스 오버헤드 포함 (With rough 35% index overhead)
1536	~5.72 GiB	~7.72 GiB
...

이것이 바로 규모(scale)가 커질 때 차원이 중요해지는 이유입니다. 벡터당 발생하는 작은 차이가 수백만 개의 청크를 저장할 때는 실제 인프라 비용(infrastructure cost)이 됩니다.

임베딩 차원 계산기

저장 공간과 대략적인 생성 비용을 추정하는 데 사용할 수 있는 간단한 Python 도구입니다.

#!/usr/bin/env python3
import argparse

...

예시:

python3 embedding_dimension_calculator.py --documents 1000000 --avg-tokens 350

출력 예시:

Embedding Dimension Calculator
================================
Documents/chunks: 1,000,000
...

중요한 교훈: 생성 비용(generation cost)은 작게 유지될 수 있지만, 벡터 데이터베이스(vector database) 비용과 메모리는 빠르게 증가할 수 있습니다.

API 예시: 기본 1536 차원

다음은 표준 OpenAI 호환 임베딩 호출 방식입니다.

curl https://crazyrouter.com/v1/embeddings \
  -H "Authorization: Bearer $CRAZYROUTER_API_KEY" \
  -H "Content-Type: application/json" \
...

응답에는 임베딩 배열(embedding array)이 포함됩니다. 기본 설정에서 그 길이는 1536이어야 합니다.

OpenAI 호환 클라이언트라면 어떤 것이든 동일한 패턴을 사용할 수 있습니다. Crazyrouter를 사용할 경우, 베이스 URL(base URL)과 API 키만 변경하면 됩니다:

• Base URL: https://crazyrouter.com/v1
• Endpoint: /embeddings
• Auth: Authorization: Bearer YOUR_KEY

관련 내부 가이드:

• OpenAI와 호환되는 기본 URL 설명
• AI API 가격 책정 가이드
• AI API 비용 최적화 가이드
• 구조화된 출력 JSON 모드 가이드
• RAG 구현 가이드

Python 예제: 벡터 길이 확인

from openai import OpenAI

client = OpenAI(
...

실제 키를 코드에 붙여넣지 마세요. 프로덕션 환경에서는 환경 변수를 사용하세요.

import os
from openai import OpenAI

...

Python 예제: 사용자 지정 차원 요청

만약 사용하는 임베딩 제공업체가 text-embedding-3-small에 대해 dimensions 매개변수를 지원한다면, 더 짧은 벡터를 요청할 수 있습니다.

from openai import OpenAI

client = OpenAI(
...

중요: 동일한 벡터 인덱스에서 차원을 혼합하지 마세요. 컬렉션이 1536차원 벡터용으로 생성되었다면, 1024차원 벡터는 일반적으로 삽입 시 실패합니다.

각 차원 설정별로 하나의 컬렉션을 사용하세요.

Node.js 예제: OpenAI와 호환되는 기본 URL을 사용한 임베딩 요청

import OpenAI from "openai";

const client = new OpenAI({
...

어떤 차원을 선택해야 할까요?

만능의 최적 값은 없습니다. 느낌이 아니라 평가를 기반으로 선택하세요.

실용적인 시작점:

사용 사례 (Use case)	권장 시작 차원 (Suggested starting dimensions)	이유 (Why)
프로토타입 / 소규모 앱 (Prototype / small app)	1536	학습하는 동안 품질을 극대화하세요
...	...	...

프로덕션(Production) 환경을 위해서는 평가 세트(evaluation set)를 실행하세요. 50개에서 200개 사이의 실제 사용자 쿼리(queries)를 준비합니다. 가장 잘 매칭되는 문서들에 라벨을 지정하세요. 1536, 1024, 768, 512 차원에 대해 recall@5 또는 recall@10을 비교합니다.

만약 1024 차원이 1536 차원과 거의 동일한 재현율(recall)을 제공한다면, 사용자 경험을 해치지 않으면서 저장 공간과 메모리를 줄일 수 있습니다.

text-embedding-3-small 차원 설정 시 흔히 하는 실수

실수 1: 하나의 인덱스(index)에 1536과 1024 벡터를 혼합하는 것

벡터 데이터베이스(Vector databases)는 컬렉션(collection) 또는 인덱스당 고정된 차원을 기대합니다. 차원을 변경하려면 새로운 인덱스를 생성하고 코퍼스(corpus)를 다시 임베딩(re-embed)해야 합니다.

실수 2: 청킹(chunking) 전에 차원을 최적화하는 것

잘못된 청킹은 더 큰 벡터가 주는 이점보다 검색(retrieval) 성능을 더 크게 저하시킵니다.

먼저 청킹을 해결하세요:

• 청크(chunks)가 주제에 집중되도록 유지하세요.
  -n 유용한 메타데이터(metadata)를 추가하세요.
• 여러 주제가 섞인 거대한 청크를 피하세요.
• 추측하는 대신 오버랩(overlap)을 테스트하세요.

실수 3: 더 작은 차원이 API 비용을 줄여줄 것이라고 가정하는 것

임베딩 생성 비용(Embedding generation cost)은 대개 입력 토큰(input tokens)을 기준으로 합니다. 더 작은 벡터는 저장 및 검색 비용을 줄여주지만, 반드시 API 호출 비용을 줄여주는 것은 아닙니다.

실수 4: 평가 없이 512 차원을 선택하는 것

512 차원 벡터가 일부 워크로드(workloads)에서 작동할 수도 있습니다. 하지만 미묘한 차이가 있는 쿼리(nuanced queries)에서는 재현율(recall)을 잃을 수 있습니다. 프로덕션 검색 시스템으로 옮기기 전에 반드시 테스트하세요.

실수 5: 다운스트림 스키마(downstream schema) 변경을 잊는 것

pgvector를 사용하는 경우, 스키마에 고정된 차원이 포함되어 있을 수 있습니다:

CREATE TABLE documents (
  id bigserial PRIMARY KEY,
  content text,
...

1024 차원으로 전환하려면 다른 컬럼이나 테이블이 필요합니다:

CREATE TABLE documents_1024 (
  id bigserial PRIMARY KEY,
  content text,
...

간단한 평가 워크플로우 (evaluation workflow)

프로덕션에서 차원을 변경하기 전에 이 워크플로우를 사용하세요:

1. 100개의 실제 사용자 쿼리(queries)를 선정합니다.
2. 각 쿼리에 대해 올바른 문서(documents)를 레이블링(Label)합니다.
3. 1536, 1024, 768, 512 차원 각각에 대해 별도의 인덱스(indexes)를 생성합니다.
4. 각 인덱스에 대해 동일한 쿼리를 실행합니다.
5. recall@5, recall@10, 지연 시간(latency), 그리고 메모리(memory)를 비교합니다.
6. 검색 품질(retrieval quality)을 저해하지 않는 가장 작은 차원을 선택합니다.

이는 벤치마크를 읽고 그것이 귀하의 데이터와 일치하기를 바라는 것보다 훨씬 더 신뢰할 수 있는 방법입니다.

최종 권장 사항 (Final recommendation)

대부분의 팀에게 가장 좋은 첫 번째 단계는 간단합니다:

• text-embedding-3-small을 1536 차원으로 시작하세요.
• 깨끗한 검색 평가 세트(retrieval evaluation set)를 구축하세요.
• 코퍼스(corpus)가 커지면 1024 차원을 테스트하세요.
• 저장 공간, 메모리 또는 지연 시간(latency)이 중요해질 때만 768 또는 512 차원을 시도하세요.

이미 OpenAI 호환 도구를 사용 중이라면, base URL을 https://crazyrouter.com/v1로 설정하고 일반적인 SDK로 /embeddings를 호출함으로써 Crazyrouter를 통해 이를 테스트할 수 있습니다.

목표는 가장 작은 벡터를 사용하는 것이 아닙니다. 목표는 여전히 정답을 검색할 수 있는 가장 작은 벡터를 사용하는 것입니다.

FAQ: text-embedding-3-small 차원 (dimensions)

text-embedding-3-small의 기본 차원은 무엇인가요?

text-embedding-3-small의 기본 출력은 1536 차원입니다. 이는 각 입력 텍스트가 1536개의 숫자 값으로 구성된 벡터를 반환함을 의미합니다.

text-embedding-3-small의 차원을 변경할 수 있나요?

네, 제공업체(provider)가 dimensions 파라미터를 지원하는 경우, 더 짧은 벡터를 요청할 수 있습니다. 일반적인 테스트 값은 1024, 768, 512입니다.

임베딩 차원이 작아지면 API 비용이 줄어드나요?

보통 직접적으로 줄어들지는 않습니다. 임베딩 API 비용은 일반적으로 입력 토큰(input tokens)을 기준으로 합니다. 작은 차원은 주로 벡터 저장 공간, 인덱스 메모리, 그리고 검색 지연 시간(search latency)을 줄여줍니다.

text-embedding-3-small에 512 차원이면 충분한가요?

경우에 따라 다릅니다. 이는 데이터셋과 검색 품질 요구 사항에 따라 달라집니다. 프로덕션 환경에서 512 차원을 사용하기 전에 반드시 평가 세트(evaluation set)를 사용하세요.

1536 차원과 1024 차원 벡터를 동일한 데이터베이스 테이블에 저장할 수 있나요?

일반적으로는 불가능합니다. 대부분의 벡터 인덱스 (Vector Index)는 고정된 차원 (Fixed Dimension)을 요구합니다. 서로 다른 차원을 테스트할 때는 별도의 컬렉션 (Collection)이나 테이블을 생성하세요.

text-embedding-3-small을 사용해야 할까요, 아니면 text-embedding-3-large를 사용해야 할까요?

비용 효율적인 일반 검색 (General Retrieval)을 원한다면 text-embedding-3-small을 사용하세요. 검색 품질 (Retrieval Quality)이 주요 병목 현상(Bottleneck)이고 더 큰 벡터를 감당할 여력이 있다면 text-embedding-3-large를 테스트해 보세요.

RAG를 위한 최적의 차원은 무엇인가요?

text-embedding-3-small의 경우 1536 차원으로 시작하세요. 그다음 실제 쿼리 (Queries)를 대상으로 1024와 768 차원을 테스트해 보세요. 최적의 차원은 설정한 재현율 (Recall) 목표를 유지하면서 가장 작은 차원입니다.