임베딩 모델 뜻: RAG 검색 품질을 좌우하는 부품과 폐쇄망에서 고르는 기준

한 직원이 사내 규정 챗봇에 해외 출장비 정산 기한을 물었는데, 국내 출장 규정을 근거로 한 답이 돌아온 경우가 있었습니다. 답변 모델을 더 큰 것으로 바꿔도 결과는 비슷합니다. 답변 모델은 검색 단계에서 넘겨받은 문서 조각만 보고 답을 쓰기 때문에, 처음부터 엉뚱한 규정을 받았다면 문장이 아무리 매끄러워도 내용은 사실과 다릅니다. 이럴 때 먼저 살펴볼 곳이 문서를 고르는 임베딩 모델입니다.

임베딩 모델은 문장이나 문서를 수백 개의 숫자로 이루어진 벡터로 바꿔, 뜻이 비슷한 글끼리 가까운 위치에 놓이게 하는 AI 모델입니다. 이렇게 글을 벡터로 바꾸는 일, 또는 그 결과로 나온 벡터를 임베딩이라고 부릅니다. 사내 문서 검색, 추천, 중복 문서 찾기에 두루 쓰이고, 생성형 AI가 사내 문서를 근거로 답하게 하는 RAG(검색 증강 생성)에서는 임베딩 결과에 따라 답변 모델에 넘길 문서가 달라집니다.

이 글에서는 임베딩의 뜻과 RAG 안에서 하는 일을 정리하고, 외부 API를 쓸 수 없는 폐쇄망 기관이 임베딩 모델을 고를 때 확인할 것을 살펴봅니다.

임베딩이란: 키워드 검색과 무엇이 다를까요?

키워드 검색은 질문에 들어 있는 단어가 문서에 그대로 있는지를 봅니다. "연차 신청 방법"으로 검색하면 "연차"와 "신청"이 들어간 문서가 위로 올라오고, "휴가 사용 절차"라고 쓴 문서는 뜻이 같아도 놓치기 쉽습니다.

임베딩 검색은 단어 대신 뜻의 거리를 봅니다. 임베딩 모델은 "연차"와 "휴가", "정산"과 "청구"처럼 비슷한 맥락에 쓰이는 표현을 가까운 숫자로 바꾸도록 학습되어 있어서, 질문과 문서의 표현이 달라도 뜻이 비슷하면 가까운 문서로 나옵니다. 지도에 비유하면 문서마다 좌표를 찍어 두고, 질문의 좌표와 가까운 문서부터 꺼내 오는 방식입니다.

다만 뜻의 거리를 보다 보니, 품번이나 규정 번호처럼 글자 하나까지 정확히 맞아야 하는 검색에는 약합니다. 그래서 실제 시스템에서는 키워드 검색과 함께 쓰는 경우가 많습니다. 이 부분은 RAG 운영 단계에서 정확도가 떨어지는 이유 글에서 자세히 다뤘습니다.

RAG에서 임베딩 모델이 하는 일

RAG에서 임베딩 모델은 두 번 쓰입니다. 먼저 문서를 넣을 때입니다. 규정집, 매뉴얼, 보고서를 적당한 길이의 조각으로 나누고, 조각마다 임베딩 모델로 벡터를 만들어 벡터 저장소에 넣습니다. 이 작업을 색인이라고 합니다.

다음은 질문이 들어올 때입니다. 사용자의 질문도 같은 임베딩 모델로 벡터로 바꾸고, 저장소에서 질문 벡터와 가까운 문서 조각 몇 개를 고릅니다. 답변을 쓰는 LLM은 이렇게 고른 조각만 받아서 답을 만듭니다.

이 흐름을 보면 검색 단계에서 맞는 조각을 고르지 못했을 때 답변 모델을 바꿔도 같은 질문에서 계속 오답이 나오는 이유가 보입니다. 또 질문과 문서는 같은 임베딩 모델로 바꿔야 서로 비교할 수 있습니다. 모델마다 숫자를 매기는 방식이 달라서, 임베딩 모델을 교체하면 저장해 둔 문서 벡터도 전부 새로 만들어야 합니다.

예를 들어 규정 문서 조각이 수십만 개인 기관이라면, 임베딩 모델 교체는 설정 한 줄을 고치는 일로 끝나지 않고 전체 문서를 다시 색인하는 작업이 됩니다. 처음 고를 때 여러 기준을 함께 따져 봐야 하는 이유입니다.

폐쇄망에서 임베딩 모델을 고를 때 확인할 것

클라우드 환경에서는 임베딩도 외부 API로 호출하면 되는데, 폐쇄망 기관은 문서를 밖으로 보낼 수 없으니 임베딩 모델도 기관 안에서 운영해야 합니다. 이때는 성능 점수 외에도 확인할 것이 많습니다.

확인할 것	이유	확인 방법
라이선스	상업적 이용과 내부 배포가 가능해야 기관 시스템에 넣을 수 있음	모델 카드의 라이선스 문구
실행 환경과 메모리	GPU 서버 없이 업무용 PC나 CPU 서버에서 운영해야 하는 경우가 많음	기관 장비에서 직접 실행해 메모리와 처리 시간 기록
벡터 크기	차원이 클수록 저장 공간과 검색 시간이 늘어남	문서 조각 수와 차원 수로 저장 용량 계산
한국어 검색 품질	공개 벤치마크와 기관 문서의 결과가 다를 수 있음	실제 업무 질문으로 자체 평가
재색인 비용	모델이나 문서가 바뀌면 벡터를 다시 만들어야 함	전체 문서 색인에 걸리는 시간 기록

벡터 크기는 생각보다 저장 비용에 영향을 줍니다. 예를 들어 문서 조각 100만 개를 768차원 벡터로 저장하면, 숫자 하나에 4바이트를 쓰는 일반적인 방식(float32) 기준으로 벡터만 약 3GB가 되고, 128차원으로 줄이면 약 0.5GB가 됩니다. 실제 용량은 저장소 방식과 압축 여부에 따라 달라질 수 있습니다.

모델을 어디서 운영할지는 망분리 AI 도입 글에서 업무용 PC, 내부망 서버, 전용 인프라 단계로 나눠 정리했습니다. 임베딩 모델은 보통 답변용 LLM보다 크기가 작아서, 업무용 PC 단계에서 검토할 만한 후보도 나와 있습니다.

경량 임베딩 모델의 예: EmbeddingGemma 2

구글은 2026년 10월 6일 EmbeddingGemma 2를 Apache 2.0 라이선스로 공개했습니다. 전체 7억4천만 파라미터로 텍스트, 코드, 이미지, 영상, 음성을 같은 임베딩 공간에 담는 모델인데, 텍스트만 다룬다면 그중 2억7천만 파라미터만 쓰면 된다고 합니다. 구글은 양자화를 적용하면 Pixel 11 Pro 스마트폰에서 텍스트용 가중치는 약 191MB, 멀티모달 전체는 약 567MB의 메모리로 실행된다고 밝혔습니다. 한 번에 넣을 수 있는 입력은 8K 토큰이고, 출력 벡터를 768차원에서 512, 256, 128차원으로 줄여 저장 공간을 최대 6분의 1까지 줄일 수 있습니다. Hugging Face와 Kaggle에서 내려받을 수 있고, 구글은 인터넷 연결 없이 기기 안에서 검색을 운영하는 용도를 강조했습니다.

도입 과정에서 자주 생기는 문제

공개 벤치마크 순위만 보고 고르는 경우

공개 벤치마크 순위표는 후보를 좁히는 데 쓸모가 있지만, 기관 문서에는 약어와 내부 용어, 한자어가 많아서 순위표와 다른 결과가 나오곤 합니다. 실제 업무 질문 몇십 개와 그 질문에 맞는 문서를 미리 짝지어 두고, 후보 모델마다 검색 결과 상위 다섯 개 안에 정답 문서가 들어 있는지 비교하면 됩니다.

모델만 바꾸고 기존 벡터를 그대로 두는 경우

새 임베딩 모델로 질문만 벡터로 바꾸고 저장소의 문서 벡터는 예전 모델로 만든 것을 그대로 두면, 서로 다른 기준으로 매긴 숫자를 비교하게 됩니다. 차원 수가 같으면 오류 메시지 없이 검색 결과만 엉뚱해져서 원인을 찾기 어렵습니다. 모델을 교체할 때는 전체 재색인을 일정에 넣고, 벡터마다 어떤 모델로 만들었는지 기록해 둡니다.

답변만 평가하고 검색 결과는 확인하지 않는 경우

RAG 품질을 볼 때 최종 답변만 채점하면, 틀린 답이 검색 단계에서 생긴 문제인지 답변 모델에서 생긴 문제인지 구분하기 어렵습니다. 질문마다 검색 단계에서 어떤 문서 조각을 골랐는지 기록에 남겨 두면, 임베딩 모델을 바꿀지 문서를 정리할지 판단하기가 쉬워집니다.

하이퍼이지의 접근

하이퍼이지는 Skein OS로 사내 문서를 AI에 연결할 때, 임베딩 검색만으로 찾기 어려운 정보를 온톨로지로 따로 정리합니다. 현장에서 부르는 제품명과 약어를 Knowledge Dictionary로 온톨로지의 업무 대상에 연결해 두면, 부서마다 다르게 부르는 이름도 같은 대상으로 찾고 품번이나 규정 번호는 정리된 데이터에서 정확히 조회합니다. 임베딩 검색은 규정 해설이나 보고서처럼 뜻으로 찾아야 하는 문서에 씁니다. 폐쇄망 고객 환경에서는 임베딩 모델도 답변 모델과 함께 기관 안에서 운영하는 구성을 기본으로 검토합니다.

임베딩 모델 자체를 개발하는 일은 하이퍼이지가 맡는 범위가 아닙니다. 기관 문서와 업무 용어를 정리해 어떤 임베딩 모델을 쓰더라도 맞는 문서를 찾을 수 있게 하고, 모델을 교체할 때 다시 평가할 기준을 남기는 일을 맡습니다.

자주 묻는 질문

임베딩 모델과 LLM은 같은 모델인가요?

다른 모델입니다. LLM은 문장을 만들어 내는 모델이고, 임베딩 모델은 글을 벡터로 바꾸는 일만 합니다. RAG에서는 임베딩 모델로 문서를 고르고, LLM이 그 문서를 바탕으로 답을 씁니다.

임베딩 모델을 운영하려면 GPU가 꼭 있어야 하나요?

모델 크기와 문서 양에 따라 다릅니다. 수억 파라미터급 경량 모델은 CPU에서도 실행되는 경우가 많지만, 처음 전체 문서를 색인할 때는 시간이 오래 걸립니다. 문서가 많다면 첫 색인만 GPU 장비에서 하고, 이후 새 문서와 질문은 CPU에서 처리하는 방식도 검토해볼 수 있습니다.

한국어 문서에는 어떤 임베딩 모델이 맞을까요?

모든 기관에 맞는 하나의 모델은 없습니다. 같은 모델도 문서 종류와 용어에 따라 결과가 달라집니다. 라이선스와 실행 환경으로 후보를 두세 개로 좁힌 뒤, 기관의 실제 질문으로 비교해 고르면 됩니다.

정리

임베딩 모델은 RAG에서 답변 모델에 넘길 문서를 고르는 부품입니다. 폐쇄망 기관이라면 라이선스와 실행 환경으로 후보를 좁히고, 기관의 실제 질문으로 한국어 검색 품질을 확인한 뒤 고르는 편이 나중에 모델을 교체하고 전체 문서를 다시 색인하는 일을 줄이는 방법입니다.