[Tech Series] kt cloud AI 검색 증강 생성(RAG) #4 : 임베딩(Embedding)과 벡터 인덱싱 기술

Tech Story/Tech Inside

[Tech Series] kt cloud AI 검색 증강 생성(RAG) #4 : 임베딩(Embedding)과 벡터 인덱싱 기술

kt cloud 기술 블로그 2026. 3. 23. 16:58

[ kt cloud 마케팅커뮤니케이션팀 김지웅 님 ]

📋 요약

이 글에서는 RAG 시스템의 핵심 구성 요소인 임베딩 원리, 다국어 모델 선정 전략,
그리고 HNSW·DiskANN·GPU 가속·양자화 등 벡터 인덱싱 최적화 기법을 다룹니다.
모델의 표현력과 인프라 검색 효율 사이의 트레이드오프를 이해하는 것이
실무 RAG 시스템의 품질과 운영 비용을 동시에 결정짓는다는 점을 정리합니다.

#RAG #벡터임베딩 #HNSW #DiskANN #양자화

들어가며 💭

안녕하세요, kt cloud 테크 마케터 김지웅 입니다. 🙋‍♂️

RAG를 구축하다 보면 지난 3편에서 다룬 '청킹' 다음으로 반드시 마주하는 거대한 산이 하나 있어요.

“문서를 잘게 쪼개긴 했는데, 이걸 도대체 어떤 기준으로 수치화하고(임베딩), 수억 개의 데이터 속에서 어떻게 0.1초 만에 찾아낼까(인덱싱)?”

이때 많은 분들이 단순히 벤치마크 리더보드 1위 임베딩 모델을 가져다 쓰면 모든 게 해결될 거라고 믿어요. 하지만 실무 현장은 생각보다 훨씬 다이내믹하죠.

당장 한국어 환경에서는 영문 1위 모델이 힘을 못 쓰기도 하고, 데이터가 조금만 쌓여도 벡터 데이터베이스의 메모리 유지 비용이 눈덩이처럼 불어나 인프라 운영의 큰 골칫거리가 되곤 하거든요. 결국 모델의 '표현력'과 인프라의 '검색 효율'이 완벽한 밸런스를 이뤄야만 진정한 RAG 시스템이 완성됩니다.

이번 4편에서는 이 보이지 않는 엔진의 속사정을 제대로 들여다보려고 해요.

텍스트를 고차원 숫자로 변환하는 임베딩의 원리와 다국어 모델 선정 전략부터, 거대한 메모리 압박을 이겨내고 초고속 탐색을 가능하게 하는 HNSW, 디스크 기반 탐색(DiskANN), GPU 가속, 양자화(Quantization) 같은 최신 인덱싱 최적화 기법까지 차근차근 정리해 볼게요. 🛠️

그럼 이제 RAG 품질과 인프라 비용을 동시에 결정짓는 핵심 단계, 임베딩과 벡터 데이터베이스의 세계로 함께 들어가 보겠습니다. 🥸

1. 텍스트에서 벡터 공간으로

의미 기반 검색의 핵심: '표현(Representation)'으로서의 임베딩

RAG 시스템에서 검색의 정확도는 비정형 데이터를 얼마나 정교한 수치적 '표현'으로 변환하느냐에 달려 있어요. 🎯

임베딩 모델은 텍스트나 이미지 등을 고정된 길이의 고차원 벡터 공간 내 한 점으로 매핑하는 수학적 함수 f: X → Rᵈ 로 정의됩니다.

이렇게 생성된 벡터는 원본의 의미론적 정보를 압축적으로 담아내게 되죠.

"유사한 의미를 가진 데이터는 공간상 가까운 거리에 위치한다"는 원칙이 실무에서 완벽히 작동하려면 다음 두 가지 조건이 필요해요.

일관된 입력 규칙: 같은 용도의 데이터는 동일한 규칙으로 처리해야 해요. 예를 들어 Cohere Embed v4는 문서와 쿼리의 입력 타입을 명확히 구분해 검색 품질을 높이는 특징이 있어요.
정보 밀도 보존 (3편 연계): 청크가 벡터의 의미를 훼손해서는 안 됩니다. 지나치게 작으면 문맥이 잘리고, 크면 토픽이 섞여 정밀도가 떨어지거든요. 2025년 연구들을 보면 단답형 환경은 64~128 토큰, 넓은 문맥 파악은 512~1,024 토큰이 유리한 경향을 보이고 있어요. 즉, "청크가 의미의 경계를 보존해야 한다"는 지난 3편의 원칙이 이번 '표현의 품질'과 직결되는 셈이죠.

나아가 2025~2026년에는 모델의 장문 처리 능력이 비약적으로 커지면서 청크 전략에도 새로운 변화가 일어나는 추세예요. 압도적인 길이를 처리하는 모델들이 등장함에 따라, 긴 문서를 통째로 임베딩해 문맥을 충분히 반영한 뒤 마지막에 청크를 나누는 '지연 청킹' 방식이 새롭게 주목받고 있죠.

다만, 이 방식은 연산 비용과 메모리 사용량을 크게 증가시킬 수 있어서 품질과 인프라 비용 간의 트레이드오프를 반드시 계량화하는 과정이 필요해요.

결론적으로 임베딩 모델 선정과 청킹은 결코 분리할 수 없으며, 이 둘의 최적 조합을 찾는 것이 RAG 시스템 성공의 핵심 변수가 될 거예요.

벡터 공간(Vector Space)의 수학적 직관과 Manifold 가설

임베딩 모델의 목표는 데이터의 의미를 기하학적 관계로 변환하는 거예요. 🌌 학습이 잘 된 고차원 공간에서는 의미가 비슷할수록 자연스럽게 가까운 거리에 놓이게 되죠.

임베딩 벡터 간의 유사도는 주로 코사인 유사도, 내적, 유클리드 거리 등으로 계산됩니다. 실무 데이터베이스는 계산 효율을 높이기 위해 벡터를 정규화한 뒤 내적을 사용해 이를 '거리'라는 단일 개념으로 제공하기도 해요.

그런데 왜 벡터 차원은 768, 1536처럼 아주 높아야 할까요?
차원이 커질수록 거릿값의 분산이 줄어들어 가장 가까운 것과 먼 것의 차이가 무의미해지는 '거리 집중' 현상이 발생하기 쉬워요. 고차원 공간에서는 우리가 흔히 아는 기하학적 직관이 쉽게 깨질 수 있는 셈이죠.

[Deep Dive] 매니폴드(Manifold) 가설 — 왜 임베딩은 잘 작동할까?

고차원의 역설에도 불구하고 임베딩 기반 검색이 훌륭하게 작동하는 이유는 '매니폴드 가설' 덕분이에요.

이 가설은 현실의 고차원 데이터가 공간 전체에 무작위로 흩어진 것이 아니라, 내재된 훨씬 낮은 차원의 매끄러운 표면(다양체) 위에 밀집해 있다는 이론입니다.

직관적 비유: 3차원 지구에서 우리가 2차원 표면을 걷는 것과 같아요. 아주 큰 방에 마구 구겨진 '얇은 종이'를 상상해 보세요. 실제 자연어 데이터는 문법과 주제가 반복되므로 방을 꽉 채우지 않고 이 구겨진 종이 위에만 모여 분포하게 돼요. 결국 검색은 이 종이 위에서 가장 가까운 이웃을 찾는 문제로 바뀌죠.

차원 축소의 비밀: 이 덕분에 핵심 정보는 주요 축에 이미 집중되어 있어요. 학습 시점에 3072차원을 768차원으로 과감히 줄여도 성능 저하가 크지 않은 이유죠. 주성분 분석에서 소수의 주성분만으로 데이터 분산을 대부분 설명하는 것과 같은 이치예요.

하지만 최근 연구 동향을 보면 이런 무조건적인 낙관은 다소 경계하는 추세예요. 대형 언어 모델의 임베딩 공간이 항상 매끄럽게 연결된 완벽한 종이는 아닐 수 있다는 강력한 통계적 반박이 제기되고 있거든요. 여러 도메인이 무리하게 섞이거나 토큰화 결함으로 인해 종이가 찢어지거나 겹쳐 있을 가능성도 꾸준히 지적되고 있죠.

따라서 실무 시스템을 설계할 때는 수학적 비유를 출발점 삼되, 실제 데이터 분포의 거리를 꼼꼼히 측정하고 품질과 비용의 트레이드오프를 직접 실측하는 엔지니어링 접근이 반드시 동반되어야 합니다.

2. 임베딩 모델(Embedding Model) 선정 전략

Dense vs Sparse, 그리고 Multimodal 임베딩

Dense 임베딩은 인코더를 활용해 텍스트의 전체 의미를 실수 값의 고정 크기 벡터로 압축하는 기술입니다. 🗂️

동의어나 문장 구조가 달라도 의미적 유사성을 탁월하게 포착하죠. 최근 벤치마크에서는 Gemini, NV-Embed, Qwen 등 다목적 모델들이 뚜렷한 강세를 보이고 있어요. 특히 NV-Embed 계열은 어려운 오답 데이터를 걸러내는 하드 네거티브 마이닝과 합성 데이터를 결합해 최상위권 성능을 굳건히 유지하는 추세예요.

반면, Sparse 임베딩은 전체 어휘 사전 크기만큼 차원이 크지만 대부분의 값이 0으로 채워진 벡터를 생성합니다.

과거 BM25를 넘어, 최근엔 SPLADE 같은 학습 기반 모델이 주류로 자리 잡았어요. 문서에 직접 등장하지 않은 관련 단어까지 가중치를 부여하는 '의미 확장' 기능 덕분에 어휘 불일치 문제를 크게 완화했거든요. 키워드 매칭이 중요한 법률·의료 분야에서 Dense 모델의 약점을 훌륭히 보완해 주죠. 실무에서는 이 둘을 함께 사용하는 하이브리드 검색이 표준 패턴으로 자리 잡았고, 주요 벡터 데이터베이스들도 이를 기본적으로 지원하고 있어요.

마지막으로, Multimodal 임베딩은 텍스트와 이미지 등 서로 다른 형태의 데이터를 하나의 공유된 벡터 공간에 매핑하는 모델입니다.

초기 모델들을 지나, 최근엔 텍스트와 이미지가 혼합된 기업용 문서 검색 니즈가 커지면서 더욱 주목받고 있어요. Cohere Embed v4 같은 최신 모델은 PDF 스크린샷이나 표 등 시각적 요소를 직접 벡터화해 복잡한 파싱 과정을 획기적으로 줄여주죠. 최근엔 다국어와 멀티모달을 통합한 모델까지 등장하며, RAG 파이프라인의 데이터 소화 범위가 무한히 확장되는 흐름을 보이고 있답니다.

[임베딩 유형별 특징 요약]

유형	벡터 구조	대표 모델	주요 강점	한계
Dense	고정 차원, 모든 값 활성	Gemini, NV-Embed	의미적 유사성, 문장 변형 포착	정확한 키워드 매칭에 약함
Sparse	어휘 크기 차원, 대부분 0	SPLADE, BGE-M3	정확한 키워드 매칭, 의미 확장	깊은 의미적 추론에는 한계
Multimodal	공유 벡터 공간	Cohere Embed v4, SigLIP	텍스트와 이미지 통합 검색	상대적으로 높은 계산 비용

MTEB v2 & MIRACL: 다국어(Korean) 및 SOTA 모델 성능 분석

최근 임베딩 평가 생태계에서 가장 주목할 변화는 MTEB v2와 MMTEB의 등장이에요. 📊

이제 평가는 단순 텍스트를 넘어 표나 이미지, 레이아웃까지 포괄하는 '문서 표현 계층'으로 확장되는 추세예요. 특히 2025년 초 발표된 MMTEB는 영문 중심이던 평가를 250개 이상의 언어와 500개 이상의 태스크로 대폭 확장했죠. MTEB v2 역시 파인튜닝 데이터를 배제한 '제로샷' 평가로 전환해 진정한 일반화 성능을 측정하고, 지역별 다국어 벤치마크를 독립시켜 정밀도를 한층 높였답니다.

이러한 변화 속에서 2026년 현재, 글로벌 SOTA 임베딩 모델들의 경쟁은 더욱 치열해지는 양상을 보이고 있어요.

Gemini Embedding: 100개 이상의 언어와 차원 축소 학습(MRL)을 기본 지원해요. 2048차원에서 256차원으로 대폭 줄여도 성능 하락이 완만해 MRL 설계의 우수성을 입증하고 있죠.
NV-Embed-v2: 기존 MTEB에서 압도적인 평균 점수를 기록하며 영어권 벤치마크 최강자의 면모를 굳건히 보여주었어요.
Cohere Embed v4: 12만 8천 토큰의 압도적인 컨텍스트 길이와 함께 PDF 등 혼합 입력을 단일 임베딩으로 처리하는 강력한 멀티모달 성능을 자랑해요.
OpenAI text-embedding-3: Large 모델 기준, 다국어 평가인 MIRACL 점수를 이전 세대 대비 대폭 끌어올리며 괄목할 만한 성장을 보여주었죠.

하지만 여기서 가장 중요한 질문은 "이 영어권 최상위 모델들이 한국어 환경에서도 여전히 강력할까?" 예요.

결론부터 말하자면 반드시 그렇진 않아요.

MMTEB 결과를 보면, 영어 위주로 학습된 70억 파라미터의 대형 모델이 다국어 비중이 높은 5억 6천만 파라미터의 소형 모델에게 밀리기도 하거든요. 즉, 비영어권 환경에서는 모델 크기보다 '사전 학습 데이터의 다국어 비중'이 훨씬 중요한 변수로 작용해요.

실제로 Kor-IR이나 AutoRAG 같은 한국어 특화 벤치마크를 보면, Solar 임베딩, BGE-M3, KoE5 등 다국어 특화 모델들이 글로벌 범용 모델을 상회하는 성능을 자주 보여주고 있답니다.

따라서 한국어 RAG 시스템을 위한 최적의 모델을 선정할 때는 리더보드 평균 점수에만 의존하지 말고, 사내 데이터 기반의 자체 벤치마크 교차 검증 및 태스크별 점수 분해를 포함하는 '3중 검증'을 반드시 거쳐야 합니다.

[한 단계 더 들어가 보기] 모델 레벨의 효율화: Matryoshka(MRL)와 Binary Embedding

검색 성능은 챙기면서 저장 공간과 비용은 팍 줄일 수 있는 두 가지 최적화 기법을 조금 더 살펴볼게요. 🪆

마트료시카 표현 학습 (MRL)

2022년에 등장한 MRL은 인형 속에 더 작은 인형이 겹겹이 들어있는 러시아 전통 인형에서 영감을 받았어요.

핵심은 긴 벡터의 앞부분만 뚝 잘라내어 사용해도 원래의 의미가 충분히 유지되도록 핵심 정보를 앞쪽에 몰아넣어 학습시키는 것입니다.

기존에는 정해진 길이 끝에서 딱 한 번만 오차를 계산했다면, MRL은 학습할 때 벡터를 여러 길이(예: 64, 128, 256 등)로 토막 내어 각각의 오차를 구하고 이를 모두 합산해요.

MRL의 총 손실 = ∑ [각 차원별 가중치 × 해당 길이까지의 오차]

복잡해 보이지만 원리는 아주 간단해요. 여러 길이로 정답을 맞히도록 훈련시켜서, 모델 스스로 '가장 중요한 정보는 무조건 맨 앞에 둬야겠다'라고 깨닫게 만드는 거죠.

현재 이 기술은 실무 최적화의 표준으로 자리 잡는 추세예요. OpenAI의 text-embedding-3-large, Gemini Embedding, Cohere Embed v4 같은 모델들은 API를 호출할 때 우리가 직접 원하는 차원을 지정할 수 있거든요. 똑같은 비용으로 추론하면서 목적에 맞게 인프라 비용만 유연하게 줄일 수 있는 엄청난 장점이 있죠.

다만 2026년 연구들을 보면, 너무 짧게 자르면 성능이 확 떨어지고 새로운 지식을 추가로 학습시키는 데는 다소 불리하다는 단점도 꾸준히 제기되어 이를 보완하는 연구도 활발히 진행되고 있답니다.

이진 임베딩 (Binary Embedding)

MRL이 데이터의 '길이'를 줄여준다면, 이진 임베딩은 데이터의 '용량 자체'를 극단적으로 압축하는 마법 같은 기술이에요.

벡터를 구성하는 복잡한 소수점 숫자(32비트 실수)를 오직 0 또는 1(1비트)로만 강제 변환하여, 원본 대비 무려 32배나 저장 공간을 아끼는 기술입니다.

무거운 소수점 계산 대신 단순한 비트 연산(해밍 거리)을 쓰기 때문에 검색 속도도 최대 40배까지 엄청나게 빨라져요. 실무에 적용하는 방식은 크게 두 가지인데요.

처음부터 모델이 0과 1로 된 압축 결과를 내놓도록 훈련된 경우(Cohere Embed v4 등)가 있고, 평범한 실수 벡터를 일단 만든 다음 저장하기 직전에 특정 기준을 두고 강제로 0과 1로 바꿔버리는 후처리 방식이 있어요.

후처리 방식을 쓸 때는 필연적으로 의미가 크게 손실되므로, 이진 임베딩으로 후보군을 크고 빠르게 추려낸 뒤 상위 소수의 결과만 원본 실수 벡터로 정밀하게 재계산하는 '2단계 검색 구조'를 필수적으로 채택해야 합니다.

3. 인덱싱(Indexing) 알고리즘의 해부

In-Memory 인덱싱: HNSW의 그래프 탐색 원리

현재 주류 벡터 데이터베이스들이 기본으로 채택하는 지배적인 인덱싱 방식이 있어요. 바로 HNSW 알고리즘입니다. 🛣️

HNSW는 데이터 간의 연결을 다층적인 그래프로 구성하여 빠르고 정확하게 이웃을 찾는 근사 최근접 이웃 검색 기술입니다.

이 복잡한 원리를 '내비게이션의 경로 탐색'에 비유해 볼게요. 최상위 레이어는 톨게이트 간격이 넓은 고속도로처럼 듬성듬성 연결되어 목적지 근처로 단숨에 이동하게 해주고, 아래로 내려갈수록 촘촘한 국도와 골목길로 변해 아주 정교하게 최종 목적지를 찾아냅니다.

이때 각 데이터가 어느 층까지 존재할지 정할 때 수학적 확률 분포(지수적 감쇠)를 활용해요. 특정 상단 계층에 데이터가 과도하게 몰려 길이 꽉 막히는 병목 현상을 방지하고, 탐색의 효율을 보장하기 위함이죠.

실제 쿼리가 들어오면 탐색은 진입점인 최상위 고속도로에서 시작해요. 현재 위치에서 목적지와 가장 가까운 노드로 일단 직진(탐욕적 이동)하다가, 더 이상 가까운 길이 없으면 바로 아래층 국도로 내려갑니다. 마지막 최하위 골목길에 도달하면, 주변의 여러 후보지를 동시에 꼼꼼히 살피는 방식(빔 서치)을 써서 최종적으로 가장 비슷한 이웃을 찾아내는 구조예요.

이러한 내비게이션 성능을 조율하는 두 가지 핵심 설정값이 있어요.

M: 한 데이터가 가질 수 있는 최대 연결 선의 개수 (교차로에서 뻗어 나간 길의 수)
efConstruction: 인덱스를 만들 때 탐색할 후보 반경의 넓이 (내비게이션이 경로를 탐색할 때 고려하는 주변 범위)

두 값을 높일수록 더 꼼꼼하게 길을 찾으니 검색 품질은 좋아지지만, 도로를 닦는 시간(구축 시간)과 유지비(메모리)도 정비례해서 늘어나게 됩니다.

여기서 실무자들이 맞닥뜨리는 치명적인 한계, 바로 막대한 '메모리 압박'이 드러납니다.

HNSW는 초고속 탐색을 위해 원본 데이터뿐만 아니라 수많은 연결선과 메타데이터까지 통째로 메모리에 올려두어야만 합니다.

예를 들어 1억 개의 768차원 데이터를 띄운다면, 순수 데이터는 약 286GB 정도지만 수많은 교차로와 골목길의 연결 정보가 더해져 무려 500GB에 달하는 RAM이 필요해지거든요.

결국 1억 건이 넘는 초대규모 환경에서는 이 거대한 지도를 디스크에 내려놓거나 압축하는 기술, 혹은 GPU로 연산을 쪼개는 기술이 필연적으로 요구돼요. 이것이 바로 다음 절에서 살펴볼 핵심 주제랍니다.

[한 단계 더 들어가 보기] 대규모/고성능 인덱싱: DiskANN 및 GPU 가속(CAGRA)

앞선 메모리 기반 인덱싱의 한계를 극복하기 위해, 최근 저장 매체를 혁신한 '디스크 기반 인덱싱'과 연산 속도를 극대화한 'GPU 가속' 기술이 양대 축으로 자리 잡았어요. 🚀

DiskANN: SSD 기반 억 단위 벡터 인덱싱

Microsoft의 DiskANN은 "빠른 검색을 위해 모든 데이터를 RAM에 올려야 한다"는 전제를 깬 혁신적인 디스크 기반 아키텍처입니다.

핵심인 Vamana 알고리즘은 중앙점에서 탐색을 시작해 정교하게 가지치기를 하며 노드 간 연결 균형을 최적화해요.

가장 눈에 띄는 건 영리한 2단계 전략이에요. 무거운 전체 그래프와 원본 데이터는 저렴한 SSD에 밀어 넣고, 고도로 압축된 벡터만 메모리에 유지하죠. 쿼리가 들어오면 메모리의 압축 데이터로 후보의 90% 이상을 순식간에 걸러내고, 최종 후보만 SSD에서 읽어와 거리를 정확히 계산해요. 덕분에 HNSW 대비 최대 50배 적은 메모리만으로 10억 개의 데이터를 5ms 이내에 처리할 수 있죠. 최근엔 디스크 I/O 병목을 줄이려 그래프 노드와 SSD 페이지를 정렬하는 연구가 이어지며 기술이 한층 성숙해지는 추세랍니다.

NVIDIA cuVS와 CAGRA: GPU 가속의 파괴력

디스크가 용량을 해결했다면, GPU는 인덱스 구축과 검색의 압도적인 '계산 시간' 병목을 단번에 해결해 줘요.

NVIDIA cuVS 생태계의 핵심인 CAGRA는 GPU의 병렬 처리 아키텍처에 완벽히 최적화된 네이티브 그래프 검색 알고리즘입니다.

대규모 인덱스 빌드나 배치 쿼리 처리 시 기존 CPU 기반 HNSW 대비 수십 배 이상 빠른 속도를 뽐내죠. 실무에서는 엄청난 양의 데이터를 색인할 때 막강한 GPU 연산력으로 초고속 빌드를 마친 뒤, 이를 일반 HNSW 형식으로 변환하는 '하이브리드 아키텍처'가 널리 쓰여요. 서빙 단계에선 비용 효율적인 CPU 환경을 유지할 수 있어 Milvus나 Weaviate 같은 주요 DB들이 앞다투어 채택하고 있답니다.

Google ScaNN: 클라우드 생태계의 숨은 강자

마지막으로 ScaNN 알고리즘도 빼놓을 수 없어요.

데이터를 트리 형태로 분할한 뒤, 비대칭 해싱 기법으로 근사 점수를 매기고 다시 정밀 계산하는 3단계 파이프라인 구조를 가졌죠. 최근 직교성을 증폭시키는 새 알고리즘을 도입해 검색 효율을 한층 끌어올리며, Vertex AI나 AlloyDB 등에서 강력한 기반 기술로 맹활약하고 있답니다.

인프라 레벨의 효율화: 양자화(Quantization)와 메모리 최적화

앞선 내용의 MRL이나 Binary Embedding이 '임베딩 모델' 스스로 짐을 덜어내는 방법이었다면, 이번에 다룰 양자화는 '벡터 데이터베이스' 측면에서 생성된 데이터를 효율적으로 압축하는 기술이에요. 🗜️

두 기법의 근본적인 차이는 다음과 같아요.

구분	모델 레벨	인프라 레벨
적용 시점	모델 학습 또는 쿼리 추론 시	인덱스 저장 시 (후처리 단계)
수행 주체	임베딩 모델 자체	벡터 데이터베이스 / 인덱스 엔진
대표 기법	차원 축소(MRL), 1-bit 출력	정밀도 축소 (SQ, PQ, BQ)
호환성	기능이 학습된 특정 모델만 가능	모델 종류와 무관하게 적용 가능

인프라 레벨의 양자화는 생성된 32비트 실수 벡터의 저장 정밀도를 강제로 낮춰, 저장 공간과 메모리 대역폭 비용을 극적으로 줄이는 기술입니다. 특정 모델에 종속되지 않아 MRL과 함께 쓰면 '차원 축소'와 '정밀도 축소'라는 이중 압축 효과를 낼 수 있죠.

현대 인덱스 엔진의 3대 양자화 기법은 다음과 같아요.

Scalar Quantization (SQ): 32비트 실수 값을 8비트 정수로 매핑하는 가장 단순한 기법이에요. 최솟값과 최댓값 기준의 선형 스케일링으로 공간을 4배나 절약하죠. Elasticsearch 등에서 널리 쓰이며, 정확도 손실이 적어 실무에서 가장 안전한 첫 번째 옵션으로 꼽혀요.
Product Quantization (PQ): 벡터를 여러 하위 벡터로 쪼갠 뒤, 사전 학습된 코드북의 '중심점 ID'로 대체해 압축하는 기법이에요.

768차원 벡터를 32배나 작게 압축하고, 미리 계산된 표를 써서 속도도 무척 빠르죠. 단, 훈련 샘플로 코드북을 학습하는 과정이 꼭 필요해요. 앞서 다룬 DiskANN이 메모리 내 압축 벡터를 유지할 때 이 PQ를 적극 활용하고 있답니다.

Binary Quantization (BQ): 임계치를 기준으로 각 차원을 1비트(0 또는 1)로 변환하는 극단적인 스칼라 양자화예요. 32배의 공간 절감 효과와 더불어 단순 비트 연산(Hamming Distance)으로 검색 속도를 수십 배 끌어올리죠. 정보 손실이 커서 보통 1024차원 이상의 고차원 데이터에 유리해요.

실무 설계 시 이런 기법들은 결코 단독으로 쓰이지 않아요.

양자화는 '인덱스(후보군 좁히기)' + '양자화 압축(빠른 근사 계산)' + '원본 실수 벡터(정밀 리스코어링)'가 결합된 2단계 파이프라인으로 설계되어야만 품질 저하를 막을 수 있습니다.

최근 Cohere Embed v4처럼 모델 자체가 정수나 이진 벡터를 반환해 인프라 변환을 생략하는 경우도 생겼죠. 하지만 어떤 방식이든 "벡터 타입", "거리 지표", "인덱스 구조"는 완벽한 삼위일체로 맞물려야 시스템의 정합성이 유지된답니다.

마무리: 모델과 인프라의 교차점에서 찾는 최적의 균형

지금까지 텍스트가 의미를 지닌 수치로 변환되는 원리부터, 수억 건의 데이터에서 눈 깜짝할 새 이웃을 찾아내는 인덱싱 아키텍처의 최전선까지 깊이 있게 살펴보았어요. 🧭

단순한 벤치마크 1위 모델 선정을 넘어, 데이터의 본질과 시스템의 물리적 한계를 동시에 이해하는 것이 무척 중요하죠. 결국 성공적인 RAG 시스템의 핵심은 '모델의 표현력'과 '인프라의 검색 효율'이 빈틈없이 맞물려 돌아가는 정교한 엔지니어링에 있습니다.

우리가 다룬 차원 축소(MRL), 양자화, 디스크 기반 탐색, GPU 가속 기술 등은 이제 폭발하는 비정형 데이터를 감당하기 위한 필수 생존 전략이 되었어요. 개발자가 무심코 설정한 탐색 파라미터 하나가 전체 인프라의 유지 비용과 검색 품질을 크게 쥐고 흔들 수 있거든요.

따라서 맹목적으로 최신 유행 알고리즘을 좇기보다, 현재 시스템의 진짜 병목이 메모리인지, 연산 처리량인지, 스토리지 비용인지 냉철하게 진단하고 적정 기술을 섬세하게 조립해 내는 통찰이 필요한 시점이에요.

다만, 실무 현장에서 이 거대한 인덱싱 아키텍처와 임베딩 최적화 과정을 밑바닥부터 직접 구축하고 튜닝하는 것은 막대한 시간과 엔지니어링 리소스를 요구합니다.

바로 이 지점에서 kt cloud AI Foundry가 든든한 조력자가 되어 줍니다.

복잡한 파라미터 튜닝이나 벡터 데이터베이스의 메모리 압박에 대한 깊은 고민 없이도, 검증된 임베딩 모델과 고성능 인덱싱 환경을 손쉽게 활용해 본연의 AI 서비스 개발에만 집중할 수 있도록 돕거든요.

이번 4편이 탄탄한 AI 검색 기반을 다지는 의미 있는 이정표가 되었길 바라요.

다음 5편에서는 이렇게 구축된 든든한 인프라 위에서 실제 질의가 쏟아질 때 벌어지는 다이내믹한 '검색 전략과 최종 순위 재정렬(Reranking)'의 세계로 안내해 드릴게요!

RAG가 열어가는 지식 증강 AI의 미래,
kt cloud AI Foundry와 함께라면 더 가깝고 더 현실적인 길이 될 거예요.✨

❓ 자주 묻는 질문 (FAQ)

Q. 글로벌 벤치마크 1위 임베딩 모델과 가장 빠르다는 HNSW 인덱스를 적용했는데, 한국어 검색 품질은 기대 이하이고 서버(메모리) 비용만 감당하기 힘들 정도로 나옵니다. 무엇을 놓친 걸까요?

A. 두 가지 측면에서 '모델과 인프라의 핏(Fit)'이 어긋났을 확률이 높아요.

다국어 모델의 함정: 비영어권 환경에서는 모델의 파라미터 크기보다 '사전 학습 데이터의 다국어 비중'이 성능을 좌우하는 훨씬 중요한 변수입니다. 영어권 리더보드 1위 모델이라도 한국어 학습 비중이 낮으면 오히려 가벼운 다국어 특화 모델보다 성능이 떨어질 수 있어요. 따라서 반드시 사내 한국어 데이터로 교차 검증을 진행해야 해요.
메모리 압박과 최적화 부재: HNSW는 검색 속도가 무척 빠르지만, 원본 데이터와 수많은 그래프 연결선을 모두 메모리(RAM)에 올려야 해서 비용 압박이 극심해지죠. 이를 해결하려면 임베딩 모델 단에서 차원을 줄이는 MRL을 사용하거나, 인프라 단에서 양자화(Quantization)를 적용해 데이터 크기를 팍 줄여야 해요. 만약 데이터가 1억 건 단위로 넘어간다면, 무거운 데이터를 SSD로 내리는 DiskANN이나 연산을 쪼개는 GPU 가속(CAGRA) 아키텍처로의 전환을 고려해 보는 것이 좋습니다.

📚 관련/출처

저작자표시 비영리 변경금지 (새창열림)

'Tech Story > Tech Inside' 카테고리의 다른 글

[인사이트] EU AI Act 2026년 발효, 한국 기업의 AI 거버넌스 대응 전략 (2)	2026.03.12
[인사이트] Cloud 3.0 시대의 하이브리드 전략: 진정한 소버린을 달성하는 ktcloud와 Azure의 만남 #1 - 하이브리드 클라우드의 재정의 (0)	2026.03.12
[Tech Series] kt cloud AI 검색 증강 생성(RAG) #3 : 청킹(Chunking) 전략과 최적화 (0)	2025.11.25
[인사이트] 2025 글로벌 AI 경쟁 시대, 국내 클라우드 기업이 해결해야 할 5대 기술 과제 (0)	2025.11.13
[기술리포트] kt cloud로 완성하는 복원력 : 백업·DR·Multi-Region·HA 개념부터 설계 전략까지 (0)	2025.10.29

현재글[Tech Series] kt cloud AI 검색 증강 생성(RAG) #4 : 임베딩(Embedding)과 벡터 인덱싱 기술

기술 블로그 (Tech) | kt cloud