임베딩(Embedding) 모델이란?

앞서 RAG 검색의 개괄적인 내용을 정리해봤고, 이번엔  세부 기술들을 정리해보려고 한다.

2025.10.20 - [개발/AI] - RAG 이해하기: Embedding부터 평가 지표까지

 

RAG는 Retrieval(검색)과 Generation(생성)으로 나뉘는데, 검색의 핵심은 ‘어떻게 의미적으로 비슷한 문서를 찾느냐’이다. 여기서 임베딩이 그 열쇠가 된다.

 

임베딩 기술이 뭔지, 임베딩이 어떻게 구성되는지는 나보다 더 잘알고 잘 설명해주는 글이 많아 짧게 정리해보면 다음과 같다.

임베딩은 텍스트(문장, 단어, 문서 등)를 고차원 벡터 형태로 변환하는 과정이다. 이렇게 하면 문장 간의 의미적 유사도를 수치적으로 비교하기 위한 기법입니다.

 

최근 가장 보편적으로 사용되는 건 openai의 text-embedding 모델이다.

 

하드웨어가 갖춰지지 않아도, API로 사용가능하고 가격도 저렴하고 성능도 나쁘지 않기 때문이다.

 

이 모델을 기준으로 글을 작성해보면 좋을 것 같다.

 

임베딩 : 텍스트의 수치화

모델은 언어를 직접 이해하지 못한다. 텍스트를 고차원 벡터(숫자들의 배열) 로 변환해야, 단어 간의 관계나 문맥적 유사성을 계산할 수 있다. 예를 들어 "강아지"라는 단어가 [0.12, -0.43, 0.89, ...] 같은 벡터로 변환되면, "고양이"의 벡터와 비교해 “얼마나 가까운 의미인지”를 수학적으로 계산할 수 있다.

 

따라서 임베딩은 단순히 “텍스트 → 숫자”가 아니라, 의미를 얼마나 잘 보존하느냐가 중요하다. 과거엔 단어 단위로 임베딩을 만들었지만, 최근에는 문장 단위(sentence-level) 로 임베딩을 생성하는 모델이 주류다. 즉, 문장 전체의 의미를 하나의 벡터로 압축하여 의미적으로 가까운 문장끼리 군집되도록 만든다.

 

과거의 임베딩 모델은 단어들을 수치화하는데 그쳤지만, 현대 임베딩 모델은 다음과 같은 특징을 갖는다.

 

1. 문장 단위 의미 보존 (Sentence-level semantics)
문장 전체의 맥락을 벡터 하나로 표현한다. 예를 들어 “오늘 날씨가 춥다”와 “기온이 많이 내려갔다”는 서로 다른 문장이지만 임베딩 공간에서는 매우 가깝게 위치한다.

2. 언어 간 일반화 (Multilingual capability)
최신 임베딩 모델은 여러 언어를 공통 의미 공간에 매핑한다. 즉, "apple"(영어)과 "사과"(한국어)가 비슷한 벡터로 표현되어 언어 간 검색에도 활용할 수 있다.

3. 유사도 계산 (Cosine similarity, Dot product)
벡터화된 문장 간 거리를 계산하여 의미적 유사도를 판단한다. 보통 코사인 유사도(Cosine similarity)를 사용하며, 값이 1에 가까울수록 두 문장은 의미적으로 더 유사하다.

 

현대 임베딩 : BERT-style Embedding

기존의 Word2Vec이나 GloVe는 “단어 하나하나의 의미”를 잘 잡아내는 데 초점을 두었다. 하지만 이런 모델은 문맥을 충분히 반영하지 못한다는 한계가 있었다.

 

“은행 앞에 나무가 있다” vs “은행 계좌를 만들었다”

이 두 문장에서 “은행”은 완전히 다른 의미이지만, Word2Vec은 이를 구분하지 못한다.

이 문제를 해결하기 위해 등장한 게 BERT(Bidirectional Encoder Representations from Transformers)이다. BERT는 문장을 왼쪽에서 오른쪽, 오른쪽에서 왼쪽 양방향으로 동시에 학습하여, 단어가 등장한 문맥(Context) 을 고려한 임베딩을 생성한다.

 

이처럼 BERT는 문맥에 따라 변화하는 동적 임베딩(Contextual Embedding) 을 생성한다. 같은 단어라도 문장에 따라 다른 벡터를 부여받는다는 점이 가장 큰 혁신이다. 즉, BERT-style 임베딩은 단어 자체의 의미 + 문맥에서의 의미를 함께 반영한 벡터를 만들어낸다.

이러한 문맥 기반 임베딩은 문장 단위의 의미 보존으로 확장되면서, 현재 RAG에서 사용되는 대부분의 Sentence Embedding 모델의 기반이 되었다.

 

임베딩과 RAG 시스템과의 관계

결국 RAG와 임베딩의 상관관계를 정리하면, 질문과 문서가 같은 의미 공간에 존재하는가다. 임베딩은 단순히 단어의 유사성을 넘어서, 문장 전체의 의미를 하나의 벡터로 표현할 수 있기 때문에 질문 → 의미적으로 가장 가까운 문서 를 정확하게 찾아낼 수 있게 도움을 준다.

[질문(Query)] 
  ↓ (임베딩 변환)
[질문 벡터]
  ↓ (벡터 DB 검색)
[유사 문서 Top-k]
  ↓ (LLM 컨텍스트로 전달)
[최종 응답 생성]

즉, RAG가 “문맥적으로 올바른 정보를 검색”하기 위해서는 BERT-style 임베딩 기반의 문장 벡터가 사실상 필수적인 구성 요소가 되어 버렸다.

 

이에 따라 RAG 시스템에 사용할 데이터와 검색 용도에 따라 임베딩 모델을 잘 선택해야한다. 왜냐하면, 임베딩의 품질이 낮으면 검색 결과가 부정확해지고, 결국 LLM은 엉뚱한 문서를 근거로 답변을 생성(할루시네이션)하게 된다. 즉, RAG의 정확도와 사실성(factuality)은 결국 임베딩의 품질에 달려 있다.

 

간단한 임베딩 파이썬 코드

임베딩은 대부분의 라이브러리에서 API로 제공하고 있다. 그래서 코드 자체는 매우 단순하다.

 

openai의 예를 들면,

from openai import OpenAI
client = OpenAI()

res = client.embeddings.create(
    model="text-embedding-3-small",
    input="임베딩은 텍스트를 벡터로 변환하는 과정이다."
)
print(res.data[0].embedding[:5])  # [0.01, -0.02, 0.05, ...]

위와 같이 간단한 코드로 표현할 수 있다. 이렇게 생성된 벡터를 저장소에 저장하고, 검색 알고리즘을 통해 검색 후 LLM을 통해 응답을 만드는게 RAG 시스템의 한 사이클로 구성된다.

 

임베딩 기술이 나온지는 꽤 시간이 지나서 용도에 맞는 다양한 모델들이 나오게 되었고, 비교 분석한 자료도 많다. 허깅페이스 리더보드를 보면 필요한 모델에 대한 정보를 얻을 수 있으니 잘 선택해서 사용하면 좋을 것 같다.

https://huggingface.co/spaces/mteb/leaderboard

주의할 점?

임베딩 모델을 이것저것 써보면서 배운점을 정리해보면 다음과 같다

 

1. 데이터에서 추출할 때와 검색할 때 동일한 임베딩 모델을 사용해야 한다. 어떻게 보면 당연한 이야기지만, 초기 구축 및 테스트할 때나 배치를 돌릴때 실수가 발생하면 임베딩 정확도가 이상하게 떨어질 때가 있다.

 

2. 위에서 거듭 이야기했지만, 데이터셋 특화 모델이 가장 큰 성능 향상을 만든다.  데이터가 한글 위주라면, 한국어 학습이된 임베딩 모델로 변경했을 때 정확도 상승폭이 제일 컸다.

 

3. 모델 크기와 정확도는 대체로 정비례하지만, 데이터 적합성이 더 중요하다. 사용하는 언어의 종류에 맞거나 데이터 종류에 맞는 모델을 사용했을 때의 정확도 상승폭이 더 컸다.

 

청킹, 차원 축소 기술도 임베딩 성능에 영향을 줄 수 있으니 다양한 기법을 사용해보는 것도 좋을 것 같다.

마치며

새로운 분야에 도전하면서 공부할 거리가 너무 많이 늘어났다.

 

RAG 시스템에서 가장 중요한 부분은 벡터 데이터베이스 조회 성능일거라 생각했는데, 생각보다 더 임베딩 모델의 성능이 중요했다. 

 

2023년 임베딩 모델을 찾을 당시엔 임베딩 모델의 성능이 대부분 별로 였고 openai에서 제공한 ada 정도의 성능을 가진게 없었는데, 요즘엔 좋은 성능을 가진 다양한 모델들이 만들어지고 공유되고 있는 것 같다(허깅페이스의 역할이 매우 큰 것 같다. openai도 계속해서 모델을 업데이트해서 ada 시절보다 성능이 많이 좋아졌다.)

 

현재 개발하고 있는 솔루션에 임베딩 모델이 들어가서 이 자료를 정리해보게 됐다. 블로그는 RAG 시스템을 완성해가며 필요하거나 중요한 구성요소들에 대해서 계속해서 작성해볼 것 같다.