Embedding은 AI 검색과 RAG를 이해할 때 거의 반드시 만나는 개념입니다. 어렵게 들리지만 출발점은 단순합니다. 사람이 읽는 문장이나 문서를 컴퓨터가 비교할 수 있는 숫자 묶음으로 바꾸는 것입니다.
핵심은 문장의 의미를 숫자 벡터로 바꾸고, 가까운 벡터끼리 비슷한 의미로 다루는 것입니다. 이 기준을 잡으면 RAG, Vector DB, 추천 시스템이 왜 embedding을 쓰는지 자연스럽게 이어집니다.
Embedding을 이해하는 핵심 흐름
Embedding은 텍스트의 의미 좌표다
컴퓨터는 문장 자체의 의미를 바로 비교하지 못합니다. 그래서 embedding 모델은 텍스트를 여러 개의 숫자로 된 벡터로 바꿉니다. OpenAI 공식 문서도 embedding을 텍스트를 숫자로 바꾸어 search, clustering 같은 작업에 활용할 수 있다고 설명합니다.
예를 들어 “비밀번호를 잊어버렸어요”와 “로그인이 안 돼요”는 단어가 완전히 같지는 않지만 고객센터 관점에서는 가까운 문제일 수 있습니다. embedding은 이런 의미적 가까움을 계산할 수 있게 도와줍니다.
검색에서 embedding이 필요한 이유
전통적인 키워드 검색은 단어가 정확히 맞는지에 강합니다. 반면 의미 검색은 표현이 달라도 의도가 비슷한 문서를 찾고 싶을 때 유용합니다. 사용자가 “환불은 언제 들어오나요”라고 물었는데 문서에는 “결제 취소 처리 기간”이라고 적혀 있어도, embedding 기반 검색은 둘을 가깝게 볼 수 있습니다.
물론 embedding이 키워드 검색을 완전히 대체하는 것은 아닙니다. 정확한 상품명, 에러 코드, 법적 문구처럼 단어 일치가 중요한 경우에는 키워드 검색이 더 강할 수 있습니다. 실무에서는 키워드 검색과 벡터 검색을 함께 쓰는 하이브리드 방식도 자주 고려합니다.
RAG에서는 어디에 들어갈까
RAG에서는 먼저 문서를 잘게 나누고, 각 조각을 embedding으로 바꿔 저장합니다. 사용자가 질문하면 질문도 embedding으로 바꾸고, 벡터 공간에서 가까운 문서 조각을 찾습니다. 그 다음 찾은 문서를 LLM 입력에 넣어 답변을 생성합니다.
문서 조각 -> embedding -> Vector DB 저장
사용자 질문 -> embedding -> 가까운 문서 검색
검색 결과 + 질문 -> LLM 답변 생성이 흐름에서 embedding 품질이 낮거나 문서 조각이 잘못 나뉘면 RAG 답변도 흔들립니다. 그래서 RAG를 만들 때는 모델만 바꾸기보다 chunking, metadata, reranking, context packing까지 함께 봐야 합니다. 검색 결과를 다시 정렬하는 문제는 RAG reranking 글에서 더 자세히 다뤘습니다.
추천 시스템에서도 같은 감각을 쓴다
추천 시스템에서도 embedding은 유용합니다. 사용자가 읽은 글, 클릭한 상품, 좋아한 문장 등을 벡터로 바꾸면 비슷한 취향이나 비슷한 콘텐츠를 찾을 수 있습니다. 텍스트뿐 아니라 이미지, 상품, 사용자 행동도 벡터 표현으로 다룰 수 있습니다.
다만 추천에서는 “비슷함”이 항상 좋은 것은 아닙니다. 너무 비슷한 것만 추천하면 다양성이 줄고, 사용자는 새로운 선택지를 발견하기 어렵습니다. 그래서 embedding 기반 유사도는 추천의 한 재료이지 전체 전략은 아닙니다.
벡터 DB는 왜 함께 등장할까
Embedding을 만들었다고 끝은 아닙니다. 문서가 수천 개, 수백만 개가 되면 모든 벡터를 매번 하나씩 비교하기 어렵습니다. 그래서 벡터를 저장하고 가까운 벡터를 빠르게 찾는 저장소가 필요해집니다. 이 역할을 하는 도구를 흔히 Vector DB라고 부릅니다.
하지만 작은 서비스나 실험 단계에서는 반드시 별도 Vector DB부터 도입할 필요는 없습니다. 데이터 규모가 작고 업데이트가 적다면 일반 DB, 파일, 간단한 인덱스로도 시작할 수 있습니다. 중요한 것은 “검색해야 할 벡터가 얼마나 많고, 얼마나 자주 바뀌며, 응답 속도 요구가 어느 정도인가”입니다.
Embedding을 쓸 때 조심할 점
- 벡터가 가깝다고 항상 정답 문서라는 뜻은 아니다.
- 문서 조각이 너무 크면 필요한 부분을 정확히 찾기 어렵다.
- 문서 조각이 너무 작으면 맥락이 끊길 수 있다.
- 최신 정보가 필요한 서비스라면 embedding 재생성 주기를 관리해야 한다.
- 개인정보나 민감한 문서를 벡터 DB에 넣을 때는 접근 제어를 함께 설계해야 한다.
좋은 embedding 설계를 위한 질문
Embedding을 도입하기 전에 어떤 텍스트를 벡터로 만들지 정해야 합니다. 문서 제목만 넣을지, 본문 전체를 넣을지, 제목과 본문을 합칠지에 따라 검색 결과가 달라집니다. 질문과 문서의 언어가 다르거나, 코드와 자연어가 섞여 있거나, 짧은 FAQ와 긴 문서가 함께 있다면 실험이 더 필요합니다.
또한 검색 결과를 그대로 답변에 넣을지, reranking으로 다시 고를지도 결정해야 합니다. embedding 검색은 후보를 빠르게 찾는 데 강하지만, 최종 답변에 넣을 근거를 고르는 단계에서는 추가 판단이 필요할 수 있습니다.
정리
Embedding은 텍스트를 의미가 담긴 숫자 벡터로 바꾸는 기술입니다. RAG에서는 질문과 문서를 같은 공간에 놓고 가까운 문서를 찾는 데 쓰이고, 추천 시스템에서는 비슷한 콘텐츠나 취향을 찾는 데 쓰입니다. 중요한 것은 embedding 자체보다 어떤 문서를 어떻게 나누고, 어떤 기준으로 검색 결과를 다시 검증할지까지 함께 설계하는 것입니다.
