임베딩 차원 축소를 해서 벡터를 절반으로 잘라내도, MRL(Matryoshka Representation Learning) 방식으로 학습된 모델이라면 검색 품질 저하는 생각보다 크지 않은 경우가 많습니다. 다만 이 말은 아무 임베딩 모델에나 해당되는 이야기가 아니고, 모델이 애초에 그렇게 학습됐을 때만 성립합니다. 일반적인 방식으로 학습된 벡터를 그냥 절반으로 잘라내면 검색 품질이 급격히 무너지는 경우도 흔합니다.
이 글에서는 임베딩 차원 축소가 실제로 무엇을 하는 작업인지, MRL이 왜 이 문제를 해결하는 열쇠로 언급되는지, 그리고 어떤 상황에서 차원을 줄이면 안 되는지를 구체적으로 정리해 보겠습니다.
임베딩 차원 축소, 정확히 뭘 잘라내는 걸까요
임베딩 모델은 문장 하나를 숫자 배열, 즉 벡터로 바꿔서 표현합니다. OpenAI의 text-embedding-3-large는 기본적으로 3072개의 숫자로 문장을 표현하고, Google의 Gemini Embedding 모델도 기본 출력 차원이 3072차원으로 알려져 있습니다.
차원 축소는 이 벡터의 뒷부분 숫자를 잘라내서 더 짧은 벡터로 만드는 작업입니다. 3072차원을 1536차원으로 줄이면 저장 공간이 절반으로 줄고, 벡터 DB에서 유사도를 계산하는 속도도 그만큼 빨라집니다. 문제는 뒷부분에 있던 숫자들이 실제로 의미 없는 잉여 정보였는지, 아니면 검색에 꼭 필요한 정보였는지가 모델마다 다르다는 점입니다.
일반적인 방식으로 학습된 임베딩 모델은 벡터의 모든 차원이 서로 얽혀서 의미를 표현합니다. 이런 벡터를 중간에서 잘라버리면 정보가 고르게 손실되는 게 아니라 특정 의미 축이 통째로 사라지는 경우가 생깁니다. 그래서 예전에는 차원을 줄이려면 PCA나 SVD 같은 별도의 차원 축소 알고리즘을 다시 학습시켜야 했습니다.
MRL로 학습된 벡터만 잘림에 강합니다
MRL은 학습 단계에서부터 벡터의 앞부분 몇 개 차원만 잘라내도 의미를 표현할 수 있도록 손실 함수를 설계하는 방법입니다. 이름 그대로 러시아 마트료시카 인형처럼, 큰 벡터 안에 작은 벡터가 겹겹이 들어 있는 구조로 학습시킵니다. 3072차원 벡터의 앞쪽 256개만 떼어내도 그 자체로 하나의 완결된 임베딩처럼 동작하도록 훈련하는 방식입니다.
이 방식이 중요한 이유는, 별도의 차원 축소 모델을 다시 학습시키지 않고도 서비스 요구사항에 맞춰 벡터 길이를 즉석에서 조절할 수 있다는 점 때문입니다. 검색 정확도가 중요한 구간에서는 긴 벡터를 쓰고, 1차 후보군을 빠르게 걸러내는 구간에서는 짧은 벡터를 쓰는 식의 2단계 검색 구조도 MRL 덕분에 가능해졌습니다.
OpenAI는 공식 블로그에서 text-embedding-3 계열 모델을 이런 방식으로 학습시켰다고 밝히면서, 벡터를 256차원까지 줄여도 1536차원짜리 구버전 모델(text-embedding-ada-002)보다 MTEB 벤치마크 성능이 더 높게 나왔다고 소개한 바 있습니다. 이 내용은 OpenAI의 공식 발표 글에서 직접 확인할 수 있습니다. 반대로 말하면, MRL로 학습되지 않은 모델에서는 이런 결과를 기대하기 어렵다는 뜻이기도 합니다.
차원을 절반으로 줄였을 때 검색 품질 하락 폭
실무에서 자주 나오는 질문은 “그래서 몇 퍼센트나 떨어지느냐”입니다. 정확한 하락 폭은 모델, 언어, 검색 대상 문서의 성격에 따라 달라지기 때문에 하나의 숫자로 단정하기는 어렵습니다. 다만 MRL 기반 모델에서 공개된 사례들을 종합하면 대략적인 감을 잡을 수 있습니다.
| 벡터 차원 | 원본(3072차원) 대비 저장 용량 | 검색 품질 경향 |
|---|---|---|
| 3072 | 100% | 기준 성능, 가장 세밀한 의미 구분 가능 |
| 1536 | 50% | MRL 학습 모델이라면 체감 가능한 저하가 거의 없음 |
| 768 | 25% | 근사 검색(ANN) 조합 시 미세한 재현율 저하 시작 |
| 256 | 약 8% | OpenAI 공식 벤치마크에서 구버전 1536차원 모델보다 우수했던 사례 존재 |
이 표에서 눈여겨볼 부분은 차원이 줄어드는 속도와 품질이 떨어지는 속도가 비례하지 않는다는 점입니다. 초반 절반(3072→1536)을 잘라낼 때보다, 후반부로 갈수록(768→256) 남아있는 정보의 밀도가 더 높아서 오히려 저하 폭이 완만해지는 구간이 나타나는 경우도 보고되고 있습니다. 이는 MRL 학습 과정에서 앞쪽 차원에 더 중요한 의미 정보를 몰아주도록 손실을 설계하기 때문입니다.
OpenAI dimensions 파라미터로 직접 잘라보세요
OpenAI API는 embeddings 엔드포인트에 dimensions 파라미터를 넣으면 서버 단에서 바로 축소된 벡터를 돌려줍니다. 별도의 후처리 코드를 짤 필요 없이 요청 값만 바꾸면 됩니다.
from openai import OpenAI
client = OpenAI()
def get_embedding(text, dimensions=None):
params = {"model": "text-embedding-3-large", "input": text}
if dimensions:
params["dimensions"] = dimensions
return client.embeddings.create(**params).data[0].embedding
text = "임베딩 차원 축소가 검색 품질에 미치는 영향"
full_vec = get_embedding(text) # 기본 3072차원
half_vec = get_embedding(text, dimensions=1536) # 절반으로 축소
print(len(full_vec), len(half_vec))
위 코드를 실행하면 3072 1536이 출력됩니다. 두 벡터를 같은 문서 집합에 대해 각각 저장해 두고, 동일한 질의로 상위 k개 검색 결과를 비교해 보면 벡터 절반 축소가 자신의 데이터셋에서 실제로 얼마나 영향을 주는지 직접 확인할 수 있습니다. 파라미터 이름과 동작 방식은 OpenAI 임베딩 가이드 문서에 정리돼 있습니다.
이미 다른 회사에서 이런 실험을 대규모로 돌린 사례도 참고할 만합니다. 우버이츠가 자사 검색 시스템에 MRL을 적용한 사례를 소개하면서, 특정 언어권 기준으로 256차원까지 줄였을 때 전체 크기 대비 품질 저하가 0.3% 미만이었다고 밝힌 적이 있습니다. 다만 이 수치는 우버이츠의 특정 데이터와 모델에 한정된 결과이므로, 다른 서비스에 그대로 적용된다고 보기는 어렵습니다.
차원 축소를 피해야 하는 상황도 있습니다
임베딩 차원 축소가 항상 이득인 것은 아닙니다. 먼저, 이미 파인튜닝을 마치고 서비스 중인 벡터 DB가 있다면 차원을 바꾸는 순간 기존에 저장해 둔 모든 벡터를 다시 계산해서 재색인해야 합니다. 문서 수가 수백만 건을 넘어가면 이 작업 자체가 상당한 시간과 비용을 요구합니다.
다음으로, MRL로 학습되지 않은 임베딩 모델은 애초에 차원을 잘라내는 방식이 지원되지 않거나, 지원되더라도 품질 저하가 급격하게 나타날 수 있습니다. 이런 모델에서는 PCA 같은 별도 차원 축소 기법을 벡터 위에 다시 학습시켜야 하는데, 이 경우 원본 벡터를 만든 모델의 검색 품질을 그대로 보장하기 어렵습니다.
마지막으로, 미세한 의미 차이를 구분해야 하는 검색(예: 법률 조항 비교, 의료 문헌 검색처럼 뉘앙스 차이가 결과를 좌우하는 영역)에서는 차원을 줄일수록 세밀한 구분 능력이 떨어질 가능성이 큽니다. 저장 비용을 아끼려다가 검색 정확도가 서비스 핵심 가치인 영역에서 오히려 손해를 볼 수 있으므로, 차원을 줄이기 전에 해당 검색 작업이 어느 정도의 정밀도를 요구하는지부터 따져보는 편이 안전합니다. 고차원 벡터 공간에서 데이터가 희소해지는 현상 자체는 위키백과의 차원의 저주 항목에서도 다루고 있으니 배경 개념을 참고할 만합니다.
차원을 줄였는데 검색 품질이 오히려 나아 보이는 경우, 왜 그런가요
실무에서 종종 보고되는 현상인데, 벡터를 잘랐더니 특정 검색 케이스에서 결과가 오히려 더 깔끔해 보이는 경우가 있습니다. 이는 잘려나간 뒤쪽 차원에 검색 목적과 무관한 미세한 노이즈성 정보가 섞여 있었고, 그 정보가 코사인 유사도 계산에 약간의 잡음을 더하고 있었기 때문일 가능성이 있습니다.
다만 이 현상을 일반적인 규칙으로 받아들이면 안 됩니다. 노이즈가 제거되는 효과보다 의미 정보 손실 효과가 더 큰 데이터셋에서는 당연히 품질이 떨어지고, 어느 쪽이 우세할지는 실제로 자신의 문서 집합과 질의 패턴으로 테스트해 보기 전까지는 예측하기 어렵습니다. 그래서 차원을 확정하기 전에 원본 차원과 축소된 차원으로 각각 검색을 돌려서 상위 결과를 사람이 직접 비교해 보는 과정이 여전히 필요합니다.
임베딩 차원 축소는 MRL을 지원하는 모델을 쓰고 있다면 저장 비용과 조회 속도를 크게 아낄 수 있는 실용적인 선택지입니다. text-embedding-3 계열이나 Gemini Embedding처럼 MRL 기반으로 학습된 모델인지부터 확인하고, 자신의 문서 집합에서 1536차원과 768차원 정도로 축소한 검색 결과를 실제로 비교해 보는 것이 다음 단계로 적당합니다. 그 결과를 보고 서비스에 필요한 정밀도와 비용 사이의 지점을 정하면 됩니다.
