임베딩

검색은 오랫동안 글자를 맞춰 보는 일이었습니다. 사용자가 적은 단어가 문서에 그대로 들어 있으면 찾아 주고 없으면 못 찾았습니다. 그래서 "환불 언제 돼요" 라고 물은 사람은 "결제 취소 처리 기간" 이라는 제목의 문서를 끝내 만나지 못했습니다. 같은 것을 묻고 있는데 겹치는 글자가 하나도 없었기 때문입니다.

페이지덱의 고객 문의 창구가 그랬습니다. 도움말 문서가 이미 백 편 넘게 있었는데도 같은 질문이 매일 수아에게 들어왔습니다. 문서가 없어서가 아니라 사용자가 쓰는 말과 문서에 적힌 말이 달랐던 겁니다. 사람이 "탈퇴" 라고 치면 "계정 삭제" 문서가 안 나왔고, "요금제 내리기" 라고 치면 "다운그레이드" 문서가 안 나왔습니다.

이 문제를 글자가 아니라 뜻으로 풀려면 뜻을 비교할 수 있는 형태로 바꿔야 했습니다. 컴퓨터가 두 문장의 가까움을 직접 재려면 결국 숫자여야 합니다. 임베딩은 그 변환입니다. 문장을 숫자 목록 하나로 바꾸되, 뜻이 비슷한 문장끼리는 숫자도 비슷하게 나오도록 학습된 모델이 그 변환을 맡습니다.

문장을 전용 모델에 넣으면 정해진 길이의 숫자 목록이 나옵니다. 길이는 모델마다 다르고 수백에서 수천 개 사이입니다. 1536개짜리 모델이라면 "환불 언제 돼요" 도 숫자 1536개, "결제 취소 처리 기간" 도 숫자 1536개로 나옵니다. 길이가 같으니 두 목록을 자리마다 견줘 얼마나 닮았는지 하나의 점수로 계산할 수 있습니다.

숫자 하나하나에는 사람이 읽을 수 있는 뜻이 없습니다. 3번째 값이 0.42 인 이유를 설명할 수 있는 사람은 없고, 의미가 있는 건 두 목록 사이의 거리뿐입니다. 각 문장에 지도 위의 좌표를 하나씩 찍어 둔 것에 가깝습니다. 좌표 값 자체를 읽는 대신 어느 좌표가 어느 좌표 옆에 있는지를 봅니다.

실제로 쓰는 순서는 넷입니다.

1. 자료를 조각으로 나눕니다. 문서 한 편을 통째로 넣으면 여러 주제가 섞여 좌표가 어중간한 자리에 찍히므로, 보통 문단이나 몇백 토큰 단위로 자릅니다. 토큰은 모델이 글을 쪼개 다루는 최소 단위입니다.
2. 조각마다 임베딩을 계산합니다. 문서 백 편이 조각 이천 개가 되면 숫자 목록 이천 개가 나옵니다.
3. 그 목록들을 검색할 수 있는 형태로 저장합니다. 이 일을 맡는 저장소가 벡터 데이터베이스입니다.
4. 질문이 들어오면 질문도 같은 모델로 임베딩한 뒤, 저장된 것 중 가장 가까운 조각 몇 개를 꺼냅니다.

지켜야 할 규칙이 하나 있습니다. 비교는 같은 모델로 만든 숫자끼리만 뜻이 있습니다. 모델 A 로 만든 좌표와 모델 B 로 만든 좌표는 아예 다른 지도 위의 점이라 거리를 재도 의미가 없습니다. 그래서 임베딩 모델을 바꾸면 저장해 둔 것을 전부 다시 계산해야 합니다.

가장 많이 쓰이는 자리는 RAG입니다. 모델에게 사내 문서를 알려 주려고 질문과 관련된 대목을 먼저 찾아 지시문에 붙여 주는 방식인데, 그 찾는 단계가 임베딩 비교로 이뤄집니다. 사내 검색과 고객 문의 자동 답변이 대개 이 구조입니다.

그 밖에 셋이 더 있습니다.

1. 비슷한 것 묶기 — 중복 문의나 중복 이슈를 찾아냅니다. 제목이 달라도 같은 얘기면 좌표가 붙어 있어 한 덩어리로 모입니다.
2. 자동 분류 — 들어온 문의를 결제, 계정, 버그처럼 미리 정한 갈래에 넣습니다. 갈래마다 대표 문장을 임베딩해 두고 새 문의가 어느 쪽에 가까운지 봅니다.
3. 추천 — 지금 보고 있는 항목과 좌표가 가까운 항목을 다음에 보여 줍니다.

한계도 분명합니다. 뜻이 반대인 문장이 가깝게 나오는 일이 흔합니다. "환불 가능합니다" 와 "환불 불가합니다" 는 다루는 주제가 같아서 좌표가 붙어 있고, 거리만 보면 어느 쪽이 답인지 가려내지 못합니다. 고유명사와 숫자도 약합니다. 주문 번호나 오류 코드처럼 글자가 정확히 맞아야 하는 검색은 글자를 맞춰 보는 옛 방식이 낫습니다. 20250917-0042 라는 번호를 넣었을 때 뜻으로 재는 쪽은 비슷하게 생긴 다른 번호들을 함께 올려 줍니다. 그래서 실제 제품은 둘을 함께 돌려 놓고 결과를 합치는 경우가 많습니다.

"검색이 안 걸리는 건 문서가 없어서가 아니라 임베딩을 다시 안 해서예요."

문서를 고쳤는데 그 조각의 숫자를 다시 계산하지 않아 옛 내용으로 검색되고 있다는 뜻입니다.

"임베딩 모델 바꾸면 기존 벡터 전부 다시 돌려야 합니다."

모델을 바꾸는 일이 설정 한 줄이 아니라 전체 재계산 작업이라는 경고입니다.

"이건 임베딩으로는 안 잡혀요. 주문 번호는 키워드 검색으로 가시죠."

정확히 일치해야 하는 검색에는 뜻으로 재는 방식이 맞지 않다는 판단입니다.

페이지덱에서는 태오가 도움말 문서 조각의 임베딩을 매일 새벽에 다시 계산하도록 걸어 두었습니다. 수아가 문서를 고치면 다음 날 아침부터 새 내용으로 검색됩니다. 처음에는 주 1회로 잡았다가, 요금제 개편 안내를 고친 날 하루 종일 옛 안내가 검색되는 일이 생겨 주기를 줄였습니다. 문서를 고치는 사람과 숫자를 다시 계산하는 일정이 따로 놀면 이런 어긋남이 계속 생깁니다.

지현은 이 숫자를 직접 보지 않습니다. 대신 자주 들어온 질문 스무 개를 넣어 알맞은 문서가 위쪽에 나오는지만 확인합니다. 임베딩 자체는 사람이 읽고 판단할 수 있는 대상이 아니라서, 점검은 언제나 결과로 합니다.

임베딩을 검색 기능 자체로 아는 경우가 많습니다. "임베딩 붙이면 검색 되는 거죠" 라는 말이 나오는 이유인데, 임베딩은 문장을 숫자로 바꾸는 변환일 뿐 찾아 주는 일은 하지 않습니다. 실제 검색이 되려면 그 숫자를 저장하고 가까운 것을 빠르게 꺼내 주는 저장소가 따로 있어야 하고, 조각 내는 방식과 몇 개를 꺼낼지도 정해야 합니다. 변환만 붙여 두고 검색이 되기를 기다리면 아무 일도 일어나지 않습니다.

숫자가 나왔으니 한 번 만들면 끝이라고 보는 것도 흔합니다. 문서가 고정돼 있으면 그래 보입니다. 하지만 원본 문서가 바뀌면 그 조각의 숫자는 옛 내용을 가리킨 채 남아 있고, 모델을 바꾸면 전부 쓸모가 없어집니다. 다시 계산하는 일정을 처음부터 정해 두지 않으면 반년 뒤에 아무도 손대지 않은 옛 안내가 검색 결과 맨 위에 올라옵니다.