임베딩 — 문장의 의미를 좌표로 바꾼다는 말

"임베딩을 쓰면 AI가 문장의 의미를 알아서 이해해 준다"고 생각하면 절반만 맞습니다. 임베딩은 의미를 '이해'하는 게 아니라 의미를 숫자 좌표로 바꿔 가까운 것과 먼 것을 구분할 뿐입니다. 이 차이를 모르면 RAG(검색 증강 생성) 검색 결과가 이상하게 나올 때 원인을 엉뚱한 곳에서 찾게 됩니다.

---

배경 / 왜 지금 이 용어인가

RAG 시스템, 사내 문서 검색, 챗봇의 "관련 질문 추천" 기능 뒤에는 거의 예외 없이 임베딩이 있습니다. 회사 문서를 LLM(거대 언어 모델)에게 직접 다 넣을 수 없으니, 질문과 관련된 문서만 먼저 골라내는 과정에 임베딩이 쓰입니다.

문제는 임베딩이 RAG 구축 도구 중 가장 자주 오해되는 부품이라는 점입니다. Pinecone 같은 벡터 데이터베이스 업체들의 설명에 따르면, RAG 파이프라인에서는 지식 베이스를 벡터 임베딩으로 저장해 두고 질의 시점에 관련 맥락을 검색해 LLM 응답의 근거로 삼습니다(Cyclr). 즉 임베딩은 LLM이 "생각"하기 전에 어떤 자료를 보여줄지 고르는 사서 역할입니다. 이 사서가 엉뚱한 책을 골라오면, LLM이 아무리 똑똑해도 답은 부정확해집니다.

핵심 데이터 & 현황

임베딩은 텍스트·이미지 같은 데이터를 부동소수점 숫자로 이뤄진 벡터(좌표)로 바꾼 결과물입니다. OpenAI 공식 문서에 따르면 임베딩은 텍스트 문자열 간의 관련성을 수치로 측정하는 데 쓰이며, 검색·클러스터링·추천·이상 탐지·분류 등에 활용됩니다(OpenAI API 문서).

모델(제공사)	벡터 차원	특징	출처·시점
text-embedding-3-small (OpenAI)	1536	저비용, 최대 입력 8,192토큰	OpenAI API 문서
text-embedding-3-large (OpenAI)	3072	MTEB 64.6점, 출시 이후 점수 변동 없음	premai.io 비교 자료, 2026년
Gemini Embedding 2 (Google)	비공개	텍스트·이미지·영상·오디오·PDF 5개 모달리티 지원, MTEB 다국어 태스크 평균 68.32점으로 최고 성능	Google, 2026년 3월 10일 공개
Voyage 4 Large (Voyage AI)	비공개	검색 벤치마크 nDCG@10 최고치, 코드·기술 문서 검색에 강점	premai.io 비교 자료, 2026년

해석: 같은 "임베딩"이라도 모델마다 벡터의 차원 수와 학습 데이터가 달라 결과가 다릅니다. 차원 수가 크다고 항상 더 정확한 것은 아니며, 검색 대상 언어·문서 종류에 따라 순위가 뒤바뀝니다. 실제로 다국어 문서가 많다면 Cohere나 Qwen3-Embedding 계열이 OpenAI 모델보다 높은 점수를 받는 경우가 보고됩니다(premai.io).

심층 분석

1) 임베딩은 정확히 무엇인가

임베딩은 문장 하나를 예를 들어 1536개, 3072개짜리 숫자 배열로 바꾸는 작업입니다. 이 숫자 배열 자체는 사람이 읽어서 의미를 알 수 없습니다. 대신 의미가 비슷한 문장일수록 이 좌표들이 고차원 공간에서 서로 가깝게 위치하도록 모델이 학습돼 있습니다.

두 벡터가 얼마나 가까운지는 보통 코사인 유사도로 잽니다. 두 벡터 사이 각도의 코사인 값을 쓰며, 방향이 비슷할수록 1에 가깝고 무관할수록 0에 가까워집니다(Devocean SK). "강아지"와 "반려견"의 벡터는 가깝고, "강아지"와 "주식시장"의 벡터는 멀리 떨어지는 식입니다.

2) 흔한 오해 — 왜 그렇게 읽게 되나

가장 흔한 오해는 임베딩 모델이 LLM처럼 문장을 "읽고 이해해서" 답을 낸다고 착각하는 것입니다. 실제로는 임베딩 모델은 답을 생성하지 않습니다. 오직 입력을 좌표로 바꾸는 계산만 합니다. ChatGPT 같은 대화형 AI와 임베딩 모델을 같은 API 요청 흐름 안에서 쓰다 보니 "하나의 AI가 다 알아서 처리한다"는 인상을 받기 쉽지만, 검색을 담당하는 임베딩 모델과 답변을 생성하는 LLM은 완전히 다른 모델이고 서로의 실수를 보완해 주지 않습니다.

두 번째 오해는 "임베딩 검색은 키워드 검색보다 항상 정확하다"는 생각입니다. 임베딩은 의미적 유사성은 잘 잡아내지만, 부정문("~가 아니다")이나 숫자 비교("작년보다 적다"), 고유명사의 정확한 일치 같은 부분에서는 오히려 전통적인 키워드 검색보다 약한 경우가 많습니다. 벡터 공간에서 "가깝다"는 것이 "정답에 가깝다"는 뜻은 아니기 때문입니다.

3) 실제로 판단하는 기준

임베딩 모델을 고를 때 성능 지표로 자주 인용되는 것이 MTEB(Massive Text Embedding Benchmark) 점수입니다. 다만 이 점수는 여러 작업(검색, 분류, 클러스터링 등)의 평균이라, 자신의 용도(예: RAG 검색)에 해당하는 세부 항목 점수를 따로 확인하는 편이 낫습니다. 아울러 벡터 차원 수가 크면 저장 비용과 검색 속도가 함께 늘어나므로, 정확도와 비용·속도 사이의 절충점을 실제 데이터로 테스트해 보는 것이 중요합니다.

4) 언제 쓸모 있고 언제 무의미한가

문서량이 많아 LLM 컨텍스트 창(한 번에 넣을 수 있는 글자 수)에 다 넣을 수 없을 때, 또는 비슷한 상품·게시글을 추천할 때 임베딩은 효율적입니다. 반대로 문서가 몇십 건 수준으로 적고 정확한 정답이 명확한 경우에는 벡터 검색을 새로 구축하기보다 LLM에 문서 전체를 직접 넣거나 단순 키워드 검색으로 충분한 경우가 많습니다. 벡터 데이터베이스 도입 자체가 별도의 인프라 비용과 유지보수 부담이기 때문입니다.

실전 — 임베딩을 제대로 읽는 4가지 원칙

1. 임베딩 모델과 LLM은 다른 모델입니다. 검색 결과가 이상하면 먼저 임베딩·검색 단계를 의심하고, 그다음 LLM의 답변 생성 단계를 의심하세요.
2. MTEB 점수는 참고용 평균일 뿐입니다. 실제 검색 대상 언어와 문서 종류에 맞는 세부 벤치마크를 확인하세요.
3. 코사인 유사도가 높다고 반드시 정답은 아닙니다. 부정문·숫자 비교·고유명사 일치가 중요한 질의에는 키워드 검색을 함께 쓰는 하이브리드 방식을 고려하세요.
4. 문서량이 적거나 컨텍스트 창에 다 들어간다면, 벡터 데이터베이스를 새로 구축하기 전에 더 단순한 방법으로 충분한지부터 확인하세요.