임베딩 · 벡터 DB
Embedding / Vector Database
임베딩이란?
- 의미를 숫자 벡터로(임베딩)
- 비슷한 것 빠르게 찾는 벡터DB
- RAG의 핵심 부품
임베딩을 붙이면 달라지는 건 검색 결과 화면이 아니라 운영 담당자가 하던 일의 종류입니다. 기존 키워드 검색에서는 문서 안에 '연차'라는 글자가 실제로 박혀 있어야 걸렸기 때문에, 담당자가 '휴가=연차=유급휴가' 같은 동의어 규칙을 몇 년씩 손으로 쌓아야 했습니다. 이제는 직원이 묻는 말 그대로 던져도 걸립니다. 대신 왜 이 문서가 1등으로 올라왔는지 설명하기 어려워진다는 대가가 따릅니다. 순위의 근거가 사람이 짠 규칙이 아니라 좌표 사이의 거리이기 때문입니다.
숫자로 감을 잡으면 이렇습니다. 임베딩 차원은 보통 768~3,072차원이고, 문서는 300~800자 단위로 자르되 앞뒤를 10~15% 겹치게 둬서 문장이 잘려 의미가 끊기는 걸 막습니다. 현장에서 벡터 검색만 단독으로 쓰는 경우는 드물고, 키워드 검색(BM25)과 함께 돌린 뒤 합치는 하이브리드 검색이 기본값에 가깝습니다. 제품코드·계약번호·조문 번호처럼 글자가 정확히 맞아야 하는 값에서는 벡터가 오히려 약하기 때문입니다. 여기에 부서·연도 같은 메타데이터 필터를 걸고, 상위 20건을 리랭커로 5건까지 좁혀 AI에게 넘기는 구성이 흔합니다.
가장 흔한 오해는 '벡터 DB만 깔면 검색이 똑똑해진다'입니다. 벡터 DB는 질문과 관련이 없어도 가장 가까운 것을 반드시 내놓는 구조라, 유사도 0.82 같은 점수는 정답 보증이 아닙니다. 커트라인을 두지 않으면 엉뚱한 조각이 근거로 붙어 그럴듯한 오답이 나옵니다. 또 임베딩 모델을 교체하면 기존 벡터와 좌표계가 달라져 전체를 다시 색인해야 하는데, 이걸 모르고 모델만 바꿨다가 검색 품질이 통째로 무너지는 사고가 잦습니다. 개정·폐기된 문서의 벡터를 지우지 않는 것도 마찬가지입니다. 작년에 없앤 규정이 오늘의 답변 근거로 인용되고, 권한 필터를 안 걸면 열람권 없는 문서 조각까지 답변에 섞여 나옵니다.
단어를 의미가 담긴 벡터로 바꾸는 임베딩은 2013년 구글이 공개한 word2vec으로 대중화됐고, 이후 문장 임베딩과 벡터 데이터베이스로 발전해 RAG의 뼈대가 됐습니다.
가상의 사례로 살펴보겠습니다. 산업용 밸브를 만드는 A사는 임직원 420명, 연매출 980억 규모입니다. 기술영업팀이 고객사 문의에 답하려면 15년치 사양서·시공 사례 PDF 3,800건을 뒤져야 했고, 한 건당 평균 40분이 걸렸습니다. 제품코드를 정확히 알아야만 검색이 되는 구조라, 신입 사원은 아예 선배에게 물어보는 쪽을 택했습니다.
- 기술영업팀 김 차장이 6개월치 검색 실패 로그 200건을 뽑아 보니, '고온 라인에 쓰는 개스킷 뭐 쓰나요' 같은 구어체 질문이 78%였고 그 대부분이 결과 0건이었습니다.
- 정보시스템팀 박 과장이 PDF 3,800건을 600자 단위로 자르고 100자씩 겹치게 해 약 4만 2천 개 조각으로 임베딩한 뒤 벡터 DB에 올렸습니다.
- 첫 테스트에서 2016년 단종 카탈로그가 상위에 뜨자 영업본부장이 "이거 팔지도 않는 제품인데요"라고 지적해, 문서연도와 제품군 메타데이터 필터를 붙였습니다.
- 'V-40S' 같은 코드 검색이 자꾸 뒤로 밀려 키워드 검색을 함께 돌리는 하이브리드 방식으로 바꾸고, 상위 20건을 리랭커로 5건까지 좁혀 답변 근거로 넘겼습니다.
- 규정 개정분을 주 1회 재색인하는 담당자를 지정한 뒤, 3개월째 문의 1건당 자료 탐색 시간이 40분에서 7분으로 줄었고 선배에게 되묻는 사내 문의는 월 60건에서 18건으로 떨어졌습니다.