[LLM] 임베딩이란 — 의미를 숫자로 바꾸는 법

RAG 편에서 임베딩을 “글을 숫자 목록으로 바꾸는 것, 뜻이 비슷하면 숫자도 가까워진다”라고만 쓰고 넘어갔습니다. 예고한 대로 이번 편에서 그 원리를 다룹니다.

왜 굳이 숫자로 바꾸나

컴퓨터는 “뜻이 비슷하다”를 그냥은 보지 못합니다.

두 문장을 놓고 보겠습니다.

• 출장비 정산 기한은?
• 여비 청구 마감일은?

사람에게는 같은 질문입니다. 그런데 겹치는 글자가 “은?” 뿐입니다. 글자를 맞춰 찾는 키워드 검색으로는 두 번째 문서를 첫 번째 질문으로 찾아낼 수 없습니다.

임베딩은 이 문제를 다르게 풉니다. 글을 숫자 목록으로 바꿔놓고, 글자 대신 숫자를 비교합니다.

직접 그린 그림입니다. 오른쪽은 이해를 돕기 위해 2차원으로 줄인 것입니다

벡터가 무엇인가

여기서 말하는 숫자 목록을 벡터(vector)라고 부릅니다. 숫자를 순서대로 늘어놓은 것뿐입니다.

좌표를 떠올리면 쉽습니다. [3, 5] 는 2차원 평면 위의 한 점입니다. 점이 둘 있으면 얼마나 떨어져 있는지 잴 수 있습니다.

임베딩 벡터도 같은데 차원이 훨씬 많습니다. 요즘 모델은 보통 수백에서 수천 개의 숫자를 내놓습니다.

차원이 많으면 그림으로 그릴 수는 없지만, 거리를 재는 계산은 그대로 됩니다. 그림이 안 그려질 뿐 원리가 달라지지는 않습니다.

가까움을 재는 법

가장 널리 쓰는 것은 코사인 유사도입니다.

\[\text{cos}(A, B) = \frac{A \cdot B}{\lVert A \rVert \, \lVert B \rVert}\]

이름은 어렵지만 재는 것은 단순합니다. 두 화살표가 같은 방향을 가리키는가입니다.

값	뜻
1에 가까움	거의 같은 방향 — 뜻이 비슷합니다
0 근처	직각 — 별 관계가 없습니다
-1에 가까움	정반대 방향입니다

길이가 아니라 방향만 본다는 점이 중요합니다. 덕분에 짧은 질문과 긴 문단도 견줄 수 있습니다.

뜻이 어떻게 숫자에 담기나

핵심 아이디어 자체는 오래됐습니다. 어떤 말의 뜻은 그 말과 함께 나오는 말들이 정한다는 관점입니다.

“커피”와 “차”는 마시다·잔·카페 같은 말과 나란히 자주 등장합니다. 반면 “컴파일러”는 전혀 다른 말들과 붙어 다닙니다. 함께 나오는 말이 비슷하면 뜻도 비슷하다고 보는 것입니다.

word2vec 논문이 이 방식을 널리 알렸습니다. 논문 서두가 인용한 유명한 예가 있습니다.

vector(“King”) - vector(“Man”) + vector(“Woman”) 의 결과가 Queen 의 벡터에 가장 가깝다.

왕에서 남성을 빼고 여성을 더하면 여왕이 나온다는 것입니다. 뜻 사이의 관계가 벡터의 뺄셈과 덧셈으로 나타난다는 뜻이라 인상적입니다.

다만 이 계산이 늘 맞지는 않습니다. 같은 논문이 이런 유추 문제를 모아 시험했을 때 가장 좋은 정확도가 65.6% 였습니다. 1000차원 벡터를 60억 단어로 학습한 조건입니다. 셋 중 하나는 틀렸다는 뜻입니다.

단어에서 문장으로

여기서 중요한 전환이 있습니다. RAG가 다루는 것은 단어가 아니라 문단입니다.

단어 벡터를 평균 내면 될 것 같지만 잘 안 됩니다. 어순과 문맥이 사라지기 때문입니다.

그렇다고 BERT 같은 모델에 두 문장을 함께 넣어 비교하면 정확하긴 한데, 비교할 때마다 모델을 돌려야 합니다.

Sentence-BERT가 그 비용을 보고했습니다.

1만 개 문장에서 가장 비슷한 짝을 찾으려면 BERT 로는 약 5천만 번의 추론이 필요하고, 이는 약 65시간이 걸린다.

이래서는 검색에 쓸 수 없습니다. Sentence-BERT 는 문장을 한 번만 벡터로 바꿔두고 이후에는 벡터끼리만 비교하는 구조를 썼습니다. 같은 작업이 약 5초로 줄었습니다.

이 전환이 RAG 를 실용적으로 만든 지점입니다. 미리 벡터로 만들어 저장해두는 색인 단계가 성립하는 이유가 여기 있습니다.

모델은 어떻게 고르나

임베딩 모델은 종류가 많습니다. 고르는 기준으로 가장 널리 쓰이는 것이 MTEB 입니다.

MTEB 논문은 8개 과제, 58개 데이터셋, 112개 언어에 걸쳐 33개 모델을 재봤습니다. 결론이 중요합니다.

모든 과제에서 앞서는 임베딩 방법은 없었다.

“제일 좋은 임베딩 모델”이라는 건 없다는 뜻입니다. 검색에 강한 모델과 분류에 강한 모델이 다릅니다. 자기가 할 일에 맞는 항목을 봐야 합니다.

한국어를 다룬다면 하나 더 봐야 합니다. 영어 중심으로 만들어진 모델이 많아서, 한국어 성능은 따로 확인하는 편이 안전합니다.

실무에서 지킬 것 세 가지

색인과 질의에 같은 모델을 씁니다. 문서는 A 모델로, 질문은 B 모델로 벡터를 만들면 두 벡터는 비교 자체가 성립하지 않습니다. RAG 편 그림에서 양쪽에 임베딩이 하나씩 있던 이유입니다.

모델을 바꾸면 전부 다시 색인해야 합니다. 저장소에 든 숫자가 옛 모델 기준이라 그렇습니다. 모델 교체는 가벼운 결정이 아닙니다.

차원 수는 곧 비용입니다. 차원이 크면 대체로 표현력이 좋지만 저장 공간과 검색 시간이 함께 늘어납니다.

임베딩이 못 하는 것

비슷한 것과 답인 것은 다릅니다. 임베딩은 주제가 가까운 조각을 찾아줄 뿐, 그 조각에 답이 들어 있는지는 알지 못합니다. RAG 편에서 검색 문제를 따로 진단하라고 한 이유입니다.

정확히 그 글자를 찾는 일에 약합니다. 제품 코드, 사람 이름, 오류 번호처럼 철자가 중요한 것은 벡터가 잘 잡지 못합니다. RAG 편에서 본 하이브리드 검색 권고가 여기서 나옵니다.

부정과 반대말에 자주 걸립니다. “환불이 된다”와 “환불이 안 된다”는 함께 쓰이는 말이 거의 같아서 벡터도 가깝게 나오기 쉽습니다.

학습 데이터 밖에서는 약합니다. 사내 약어나 특정 분야 용어는 모델이 본 적이 없으면 엉뚱한 자리에 놓입니다.

정리

임베딩은 글을 숫자 목록으로 바꿔 뜻의 비슷함을 거리 문제로 바꾸는 장치입니다.

원리는 함께 나오는 말이 비슷하면 뜻도 비슷하다고 보는 것이고, 문단 단위로 한 번만 벡터를 만들어두는 구조가 RAG 의 색인 단계를 가능하게 했습니다.

한계도 분명합니다. 유추 계산은 셋 중 하나를 틀렸고, 모든 과제에서 앞서는 모델은 없으며, 철자가 중요한 검색과 부정 표현에는 약합니다.

그래서 RAG 에서 벡터 검색만 쓰지 말고 키워드 검색을 함께 쓰라는 권고가 나옵니다. 두 글이 여기서 만납니다.

참고

• Efficient Estimation of Word Representations in Vector Space — Mikolov, Chen, Corrado, Dean, 2013-01-16 (2026-08-14 arXiv 원문 확인). King/Queen 예시와 유추 정확도 65.6%(1000차원·60억 단어)는 본문에서 확인했습니다
• Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks — Reimers, Gurevych, 2019-08-27, EMNLP 2019 (2026-08-14 arXiv 원문 확인). 65시간 → 5초 수치는 초록에서 옮겼습니다
• MTEB: Massive Text Embedding Benchmark — Muennighoff, Tazi, Magne, Reimers, 2022-10-13 (2026-08-14 arXiv 원문 확인). 8개 과제·58개 데이터셋·112개 언어와 인용문은 초록에서 옮겼습니다
• RAG 기초 — 내 문서를 LLM에 물어보게 만들기 — 이 글이 받는 앞 편
• 컨텍스트 윈도우 — 대화가 길어지면 앞을 잊는 이유 — 왜 다 넣지 않고 골라 넣는지