임베딩이란? — AI가 말의 뜻을 숫자로 바꿔 기억하는 방법

• 임베딩은 글이나 이미지의 뜻을 숫자 목록으로 바꿔 놓은 것입니다. 그 숫자 목록을 벡터라고 부릅니다
• 뜻이 비슷한 말은 서로 가까운 좌표에 놓이기 때문에 글자가 하나도 겹치지 않아도 찾아낼 수 있습니다
• 키워드 검색은 글자가 겹쳐야 찾지만 임베딩은 뜻이 통하면 찾아냅니다

AI 이야기를 조금만 따라가다 보면 임베딩이라는 말이 계속 나옵니다. 영어로는 embedding, 우리말로 옮기면 끼워 넣기 정도인데 이렇게 옮겨 놓으면 오히려 더 알 수 없어집니다. 검색해 봐도 벡터니 차원이니 하는 말만 나와서 중간에 창을 닫게 됩니다.

먼저 한 줄로 정리하면 이렇습니다. 임베딩은 글의 뜻을 숫자 목록으로 바꿔 놓은 것입니다. 그 숫자 목록을 벡터라고 부르고, 벡터를 만드는 작업이나 그렇게 만들어진 결과물을 통틀어 임베딩이라고 부릅니다. 단어 하나도, 문장 하나도, 문서 한 조각도 전부 숫자 목록으로 바꿀 수 있습니다.

왜 굳이 숫자로 바꾸느냐가 이 글의 핵심입니다. 이 한 가지만 이해하면 요즘 자주 보이는 의미 검색이나 벡터 데이터베이스, RAG 같은 말이 한꺼번에 정리됩니다. 아래에서는 임베딩이 무엇인지, 왜 필요한지, 어디에 쓰이고 어디서 망가지는지를 차례로 보겠습니다.

임베딩이 정확히 무엇인가요?

임베딩은 글 한 조각을 숫자 목록 하나로 바꿔 놓은 것입니다. 예를 들어 강아지가 공을 물고 뛴다는 문장을 임베딩 모델에 넣으면 0.12, -0.45, 0.88 같은 숫자가 수백 개에서 수천 개쯤 줄지어 나옵니다. 이 숫자 줄 하나가 그 문장의 임베딩입니다.

숫자를 하나씩 들여다봐도 사람 눈에는 아무 의미가 없습니다. 임베딩에서 중요한 건 숫자 자체가 아니라 숫자 사이의 거리이기 때문입니다. 임베딩 하나만 놓고 보면 할 수 있는 게 없고, 비교할 다른 임베딩이 있어야 비로소 쓸모가 생깁니다.

만드는 방법도 생각보다 단순합니다. 임베딩 전용 모델에 글을 넣으면 벡터가 나옵니다. 우리가 대화할 때 쓰는 생성형 모델과는 역할이 다릅니다. 생성 모델은 문장을 만들어 주는 쪽이고, 임베딩 모델은 문장을 읽고 이 글의 뜻은 여기쯤 하고 자리만 알려 주는 쪽입니다.

바꿀 수 있는 건 글만이 아닙니다. 이미지도, 소리도 같은 방식으로 숫자 목록이 될 수 있습니다. 글과 이미지를 같은 좌표계 위에 함께 올려 두는 모델도 있는데, 사진 검색창에 노을 지는 바다라고 쳤을 때 그런 사진이 나오는 게 바로 이 원리입니다.

그래서 임베딩을 뜻을 담아 두는 그릇이라고 생각하면 편합니다. 원문을 그대로 저장하는 게 아니라, 그 글이 어떤 의미 자리에 놓이는지를 기록해 두는 것입니다.

컴퓨터는 왜 말을 숫자로 바꿔야 하나요?

사람은 강아지와 개가 거의 같은 말이라는 걸 그냥 압니다. 그런데 컴퓨터는 글자만 봐서는 이 둘이 비슷하다는 걸 전혀 모릅니다. 글자로 따지면 강아지와 개는 겹치는 부분이 거의 없고, 오히려 개나리 쪽이 더 비슷해 보입니다.

그럼 비슷한 말을 사전에 전부 등록해 두면 되지 않을까 싶지만, 이 방법은 금방 막힙니다. 사람이 말을 바꿔 쓰는 방식은 끝이 없습니다. 환불, 반품, 취소, 결제 취소, 돈 돌려받기까지 다 적어 두어도 내일 누군가는 또 다른 표현으로 물어봅니다.

그래서 나온 방법이 뜻 자체에 자리를 주는 것입니다. 지도 위의 점을 떠올리면 쉽습니다. 서울과 인천은 가깝고 부산은 멉니다. 지도에 좌표가 찍혀 있으면 가까운지 먼지를 눈대중이 아니라 계산으로 잴 수 있습니다.

임베딩이 하는 일이 딱 이것입니다. 뜻이 비슷한 말은 가까운 자리에, 관계없는 말은 먼 자리에 놓이도록 숫자를 붙여 줍니다. 그러면 강아지와 개는 바로 옆에 앉고, 강아지와 세금 신고는 한참 떨어져 앉습니다. 글자가 아니라 의미로 자리가 정해진다는 점이 전부입니다.

다만 실제 좌표는 가로세로 두 개가 아니라 수백에서 수천 개의 축으로 되어 있습니다. 이 숫자를 차원이라고 부르는데, 차원이 많아야 말의 미묘한 차이까지 담을 수 있기 때문입니다. 사람이 그림으로 그릴 수는 없지만, 가까운 것끼리 모인다는 원리는 2차원 지도와 똑같습니다.

각 축이 무슨 뜻인지는 사람이 정해 준 것이 아닙니다. 모델이 엄청난 양의 글을 읽으면서 비슷한 자리에 쓰이는 말끼리 가깝게 놓이도록 스스로 정리한 결과입니다. 그래서 3번째 축이 무엇을 뜻하는지는 아무도 모릅니다. 알 필요도 없습니다.

거리를 재는 방법은 여러 가지인데 실무에서는 보통 코사인 유사도라는 값을 씁니다. 두 좌표가 같은 방향을 보고 있는지를 0에서 1 사이 점수로 알려 주는 값입니다. 중요한 건 이름이 아니라, 비슷하다는 느낌이 이제 숫자 하나로 나온다는 점입니다.

뜻이 비슷한 말은 좌표 위에서도 가까운 자리에 놓입니다.글자가 아니라 뜻을 기준으로 앉을 자리를 정해 두는 작업입니다.

키워드 검색과는 무엇이 다른가요?

우리가 오래 써 온 검색은 글자가 겹쳐야 찾아 주는 방식입니다. 검색창에 넣은 단어가 문서 안에 그대로 들어 있어야 결과에 나옵니다. 빠르고 정확하지만, 같은 뜻을 다른 말로 적어 놓은 문서는 그냥 지나쳐 버립니다.

고객센터에서 흔히 벌어지는 일이 이것입니다. 손님은 환불 어떻게 해요라고 물었는데 안내 문서 제목은 반품 절차 안내라고 되어 있습니다. 겹치는 글자가 한 글자도 없으니 키워드 검색은 이 문서를 찾지 못합니다.

임베딩을 쓰면 이야기가 달라집니다. 질문도 문서도 같은 방식으로 좌표로 바꿔 두면, 이 두 문장은 뜻이 거의 같으니 좌표상으로 아주 가까운 자리에 놓입니다. 그래서 글자가 겹치지 않아도 반품 절차 안내가 제일 먼저 올라옵니다. 이것을 의미 검색이라고 부릅니다.

반대로 임베딩이 약한 자리도 분명합니다. 정확히 일치해야 하는 말이 그렇습니다. 제품 모델명, 사번, 주문번호, 오류 코드 같은 것들은 한 글자만 달라도 다른 것인데 임베딩은 이런 문자열을 비슷한 모양으로 뭉뚱그려 버리기 쉽습니다.

그래서 실무에서는 둘을 같이 쓰는 구성이 흔합니다. 글자로 찾는 검색과 뜻으로 찾는 검색을 동시에 돌린 다음 점수를 합쳐서 순위를 매기는 방식입니다. 돌려 말한 질문은 임베딩이 잡고, 정확한 이름은 키워드가 잡으니 서로 빈 곳을 메워 줍니다.

임베딩은 실제로 어디에 쓰이나요?

가장 많이 언급되는 자리는 RAG의 검색 단계입니다. AI에게 사내 문서를 근거로 답하게 만들려면 질문에 맞는 문서 조각을 먼저 찾아와야 하는데, 그 찾기를 임베딩이 맡습니다. 문서를 미리 조각내 좌표로 저장해 두고, 질문이 들어오면 가까운 조각을 꺼내 오는 식입니다.

두 번째는 추천입니다. 지금 읽고 있는 글과 좌표가 가까운 글을 골라 아래에 붙여 주면 그것이 관련 글 추천이 됩니다. 사람이 태그를 일일이 달지 않아도 되고, 태그가 없는 옛날 글까지 자동으로 엮인다는 게 장점입니다.

세 번째는 중복 문서 찾기입니다. 표현만 조금 바꿔 놓은 문서는 글자 비교로는 다른 문서로 보이지만 좌표로 보면 거의 같은 자리에 겹쳐 있습니다. 중복 문의를 묶거나 같은 공지가 여러 벌 쌓인 것을 정리할 때 자주 씁니다.

네 번째는 분류입니다. 들어온 문의가 배송 문제인지 결제 문제인지 환불 문제인지를 미리 만들어 둔 기준 문장들과의 거리로 자동 판정할 수 있습니다.

여기서 자연스럽게 나오는 질문이 벡터 데이터베이스가 왜 따로 있느냐는 것입니다. 이유는 속도입니다. 문서 조각이 수백만 개면 좌표도 수백만 개인데, 매번 전부와 거리를 재 보면 답하기 전에 한참을 기다려야 합니다.

그래서 벡터 데이터베이스는 좌표들을 미리 이웃끼리 묶어 정리해 두고, 대충 이 근처만 뒤지면 된다는 식으로 후보를 확 줄여서 찾습니다. 완벽한 정답 대신 거의 정답을 아주 빠르게 돌려주는 쪽을 택한 저장소라고 보면 됩니다.

임베딩을 쓸 때 조심할 점은 무엇인가요?

첫 번째는 꼭 기억해야 하는데, 임베딩 모델마다 좌표계가 완전히 다릅니다. A 모델로 만든 벡터와 B 모델로 만든 벡터는 숫자 개수가 같아도 비교하면 안 됩니다. 같은 지도처럼 생겼지만 기준점이 다른 지도라, 거리를 재 봐야 아무 의미가 없습니다.

그래서 모델을 바꾸면 저장해 둔 임베딩을 전부 다시 만들어야 합니다. 문서가 수십만 건이면 시간도 비용도 만만치 않으니, 처음에 어떤 모델을 쓸지 정하는 일이 생각보다 중요합니다. 한국어 문서가 많다면 한국어를 제대로 다루는 모델인지도 미리 확인하는 편이 좋습니다.

두 번째는 문서를 어떻게 쪼개느냐입니다. 임베딩은 글 한 덩어리를 좌표 하나로 요약하는 일이라, 덩어리가 너무 크면 여러 주제가 뒤섞여 어중간한 자리에 놓입니다. 반대로 너무 잘게 자르면 앞뒤 맥락이 끊겨서 찾아와도 무슨 말인지 알 수 없게 됩니다.

정답이 정해져 있지는 않아서 보통 문서 성격에 맞춰 실험으로 정합니다. 항목별로 끊기는 매뉴얼과 줄글로 이어지는 보고서는 알맞은 크기가 다르고, 조각끼리 조금씩 겹치게 잘라서 맥락이 끊기는 것을 줄이는 방법도 자주 씁니다.

세 번째가 가장 헷갈리는 부분인데, 뜻이 가깝다는 것과 사실이 맞다는 것은 전혀 다른 말입니다. 이 상품은 환불이 됩니다와 이 상품은 환불이 안 됩니다는 의미가 정반대인데도 좌표상으로는 아주 가까이 붙어 있습니다. 쓰인 단어와 문장 구조가 거의 같기 때문입니다.

그래서 임베딩만 믿고 답을 만들면 정반대 내용을 근거랍시고 가져오는 일이 생깁니다. 중요한 판단에 쓰는 시스템이라면 찾아온 조각을 한 번 더 걸러 주는 단계를 두거나, 사람이 원문을 확인할 수 있게 출처를 같이 보여 주는 편이 안전합니다.

같이 보면 좋은 글

• RAG란? — 임베딩이 실제로 쓰이는 자리
• 토큰이란? — 글을 조각내는 또 다른 단위
• 컨텍스트 윈도우란? — 찾아온 걸 붙일 자리
• AI·테크 용어사전 전체 목록

다음 용어는 벡터 데이터베이스를 따로 떼어 정리하겠습니다. 이 글에서 가까운 좌표를 빨리 찾아 주는 저장소라고만 하고 넘어간 부분인데, 어떤 방식으로 후보를 줄이는지와 언제 굳이 전용 저장소가 필요한지까지 한 편을 들여 보겠습니다.