P6-3.1 토큰 ID를 비교 가능한 좌표로 바꾸는 임베딩¶

Section ID: P6-3.1 Version: v2026.07.24

P6-2장에서는 LLM이 텍스트를 토큰(token) 단위로 읽고, 그 토큰 길이가 비용과 문맥 길이에 직접 연결된다는 점을 보았습니다. 그런데 토큰 번호만으로는 모델이 의미를 계산할 수 없으므로, 토큰은 곧 다른 수치 표현으로 바뀌어야 합니다.

토큰으로 나뉜 입력은 모델 안에서 어떤 숫자 표현으로 바뀌는가? 임베딩(embedding)은 토큰이나 문장을 모델이 계산할 수 있는 벡터(vector)로 바꾸는 표현 방식입니다.

여기서 가장 먼저 갈라야 할 것은 번호를 붙이는 일과 비교 가능한 좌표로 바꾸는 일입니다. 토큰 ID는 사전 안의 항목을 가리키는 번호이고, 임베딩 벡터는 그 항목을 다른 표현과 비교하고 계산할 수 있게 만든 좌표 표현입니다.

토큰 번호에서 벡터 표현으로¶

임베딩을 처음 읽을 때는 아래 질문을 붙잡습니다.

• 임베딩은 무엇을 위한 표현인가?
• 토큰 ID와 임베딩 벡터는 어떻게 다른가?
• 비슷한 의미가 가까워진다는 말은 어떤 직관으로 설명할 수 있는가?
• 왜 임베딩이 LLM과 검색 서비스의 공통 기반처럼 보이는가?

임베딩은 여기서 토큰이나 문장을 계산 가능한 벡터 표현으로 바꾸는 기반으로 먼저 잡습니다. 계열별 학습 배경, 빠른 검색 구조, RAG 연결은 이후 절에서 더 넓게 다루지만, 지금 필요한 출발점은 토큰 ID와 벡터 표현이 왜 다른지입니다.

임베딩은 마법 같은 의미 저장소가 아니라, 모델이 텍스트를 계산 가능한 공간에 놓는 표현 방식입니다. 핵심은 토큰 번호 자체가 의미를 담는다는 생각에서 벗어나, 이후 계산이 사용할 수 있는 벡터 표현으로 바뀐다는 점입니다.

토큰 ID와 임베딩 벡터의 구분¶

바로 앞의 P6-2장에서 토큰이 무엇인가와 길이와 비용이 왜 중요한가를 잡았다면, 이제 그 토큰이 어떻게 벡터가 되어 모델 계산과 검색으로 이어지는지를 알아야 합니다. 여기서 필요한 이해는 복잡한 수식을 먼저 외우는 것이 아니라, 토큰 ID, 임베딩 벡터, 벡터끼리의 비교 결과를 서로 다른 층위로 읽는 일입니다.

토큰 ID와 임베딩은 무엇이 다른가¶

토큰화(tokenization)가 끝나면 텍스트는 먼저 토큰 ID 같은 이산적인 번호(discrete index)로 바뀔 수 있습니다.

예를 들어:

• "AI" -> 1042
• "model" -> 3881

이 숫자 자체에는 의미가 거의 없습니다. 단지 사전(vocabulary) 안에서 항목을 가리키는 번호일 뿐입니다.

임베딩은 여기서 한 단계 더 나아갑니다. 각 토큰을 여러 숫자로 이루어진 벡터로 바꿉니다.

예를 들어 직관적으로는 다음처럼 생각할 수 있습니다.

1
2

token id 1042 -> [0.12, -0.08, 0.44, ...]
token id 3881 -> [0.09, -0.02, 0.39, ...]

즉:

• 토큰 ID는 무엇인지 가리키는 번호
• 임베딩 벡터는 계산에 쓰는 수치 표현

입니다.

왜 벡터로 바꾸는가¶

Part 5에서 본 Transformer는 토큰들 사이 관계를 계산합니다. 하지만 관계 계산은 텍스트 문자열 자체가 아니라 숫자 벡터 위에서 이루어집니다.

임베딩이 필요한 이유는 다음과 같습니다.

• 숫자 연산을 할 수 있어야 하고
• 토큰들 사이 유사한 쓰임을 어느 정도 비슷한 위치에 놓을 수 있어야 하며
• attention, similarity search, classification head 같은 후속 계산으로 연결되어야 하기 때문입니다

다음처럼 이해할 수 있습니다.

임베딩은 토큰을 모델 계산이 가능한 좌표처럼 바꾸는 단계다.

비슷한 의미가 가까워진다는 말은 무슨 뜻인가¶

이 표현은 자주 들리지만 쉽게 오해됩니다.

더 안전한 설명은 다음과 같습니다.

비슷한 문맥에서 자주 쓰이거나 비슷한 역할을 하는 표현은, 학습된 임베딩 공간에서 더 가까운 벡터가 될 수 있다.

예를 들어:

• car 와 automobile
• 문서 요약 과 요약 생성

같은 표현은 완전히 동일하지 않아도 비슷한 문맥에서 쓰였다면 가까워질 수 있습니다.

하지만 이것은 절대 규칙이 아닙니다. 임베딩은 학습 데이터, 모델 구조, 목적 함수에 따라 달라집니다. 그래서 가깝다 = 의미를 완벽히 안다로 읽으면 위험합니다.

LLM과 검색에서 왜 모두 중요해 보이나¶

임베딩은 LLM 내부 계산과 검색 서비스 양쪽에서 모두 중요한 역할을 합니다.

LLM 내부¶

• 토큰을 벡터로 바꾸고
• 그 벡터를 attention과 feed-forward 계산에 사용합니다

검색과 RAG¶

• 질문과 문서를 벡터로 바꾸고
• 가까운 문서를 찾아 LLM에 다시 제공합니다

즉, 임베딩은 생성 모델의 내부 표현이면서 동시에 검색 시스템의 비교 표현이기도 합니다.

아주 단순하게 그리면¶

flowchart TD
  A["토큰 시퀀스"]
  B["임베딩 벡터"]
  C["모델 계산"]
  D["유사도 검색"]

  A --> B
  B --> C
  B --> D

이 도식에서 확인해야 할 결과는 임베딩이 최종 답을 직접 내는 기능이 아니라, 이후 유사도 검색과 표현 비교 같은 계산이 가능해지도록 입력을 벡터 공간으로 옮기는 출발점이라는 점입니다.

사례 및 예시¶

아래 도식은 이 절의 세 사례를 문자열을 그대로 읽는가보다 표현을 어떤 비교 좌표로 바꾸는가라는 공통 질문으로 다시 묶은 것입니다.

flowchart TD
  A["같은 임베딩 질문"]
  B["언어 모델<br/>어떤 토큰 관계를 계산할 수 있는가?"]
  C["검색<br/>어떤 문장이 질의 가까이에 놓이는가?"]
  D["추천<br/>어떤 항목이 비슷한 사용 패턴을 공유하는가?"]

  A --> B
  A --> C
  A --> D

이 도식에서 확인해야 할 점은 과업이 달라도 먼저 필요한 단계가 같다는 것입니다. 모두 문자열 자체를 바로 계산하는 대신, 토큰이나 문장을 비교 가능한 벡터 좌표로 옮긴 뒤 다음 계산이 시작됩니다.

사례 1. 언어 모델 내부 표현¶

사용자가 foundation model과 model card가 들어 있는 문서를 읽는 장면을 떠올려 보겠습니다. 사람은 model이라는 같은 철자를 보자마자 뜻이 이미 정해져 있다고 느끼기 쉽습니다. 하지만 실제 문맥에서는 하나는 모델 계열 전체를 가리키고, 다른 하나는 모델 설명 문서를 가리키므로 바로 옆 단어에 따라 역할이 달라집니다.

반대로 system이나 architecture처럼 철자는 다른데도 비슷한 설명 문맥에 함께 등장하는 표현도 있을 수 있습니다. 문자열만 붙잡으면 이런 관계를 수치 계산으로 다루기 어렵습니다. 모델은 토큰을 임베딩 벡터로 바꿔 같은 문맥에서 함께 나타나는 정도, 다른 토큰과의 거리, attention 계산에 필요한 비교 기준을 만들고 나서야 다음 단계를 진행합니다.

여기서 바뀌는 기준은 단어를 읽는다에서 단어를 계산 가능한 좌표에 놓는다로 이동합니다. 모델은 단어를 사전 뜻풀이처럼 고정해 읽기보다, 어떤 문맥에서 무엇과 함께 쓰였는지를 바탕으로 계산 가능한 좌표에 놓습니다. 그래서 model처럼 같은 철자라도 주변 단서가 다르면 다른 관계 안에 놓일 수 있고, 반대로 철자가 달라도 같은 설명 흐름에 자주 함께 나오면 더 가까운 좌표로 모일 수 있습니다.

같은 단어/다른 단어라도 문맥에 따라 비교 기준이 달라집니다.

이 표가 바로잡는 오해는 철자가 같으면 의미도 계산상 거의 같다는 기대입니다. 임베딩은 표면 철자보다 문맥 속 관계를 더 직접적인 비교 기준으로 만듭니다.

이 사례에서 닫을 판단은 분명합니다. 토큰 ID는 같은 문자열을 가리킬 수 있지만, 이후 계산은 주변 문맥과 함께 만들어진 벡터 관계 위에서 이어집니다.

사례 2. 문장 검색¶

사용자가 프롬프트의 한계는 무엇인가라고 묻는데 문서에는 프롬프트만으로 사실성을 보장할 수 있는가라고 적혀 있을 수 있습니다. 사람은 보통 같은 단어가 반복되어야 같은 주제라고 느끼기 쉽습니다. 그래서 문자열 일치만 쓰면 질문에 없는 단어가 많은 문서는 뒤로 밀리기 쉽습니다.

하지만 이 두 문장은 모두 프롬프트만으로 충분한가라는 같은 문제 장면을 다루고 있습니다. 여기서 바뀌는 기준은 단어가 똑같이 보이는가보다, 같은 설명 흐름과 문제 장면을 가리키는가를 비교하는 쪽입니다. 임베딩 기반 검색은 질문과 문서를 같은 벡터 공간에 놓아 표면 단어가 달라도 비슷한 방향의 문장을 가깝게 찾게 만듭니다. 임베딩 기반 검색이 필요한 이유는 단어를 더 많이 외우기 위해서가 아니라, 질문과 문서가 같은 문제 장면을 가리키는지를 더 직접 비교하기 위해서입니다.

같은 검색 장면도 기준에 따라 후보가 달라집니다.

이 사례에서 중요한 기준은 같은 단어가 있나와 같은 문제를 말하나를 분리해서 보는 일입니다. 문장 검색에서 임베딩이 중요한 이유는 이 두 가지가 실제로 자주 어긋나기 때문입니다.

이 사례에서 닫을 판단은 검색 결과의 의미입니다. 가까운 벡터 후보는 정답 확정이 아니라, 같은 문제 장면을 다룰 가능성이 있는 1차 후보입니다. 이 후보를 어떻게 검증하고 근거로 붙일지는 뒤의 벡터 검색과 RAG 절에서 다시 봅니다.

사례 3. 추천과 유사도 비교¶

동영상 서비스에서 비슷한 강의를 추천하고 싶다고 해 보겠습니다. 사람은 제목에 같은 단어가 많으면 비슷한 강의라고 판단하기 쉽습니다. 하지만 제목이 둘 다 입문이어도 하나는 수식 중심, 다른 하나는 실습 중심일 수 있고, 반대로 제목은 달라도 시청자가 실제로는 같은 유형의 강의를 이어서 볼 수 있습니다.

제목 문자열만 비교하면 이런 차이를 놓쳐 추천이 어긋나기 쉽습니다. 여기서 바뀌는 기준은 제목 글자 수를 세는 것보다, 실제 소비 흐름과 강의 성격을 같은 비교 좌표계에 함께 올려 보는 쪽입니다. 이때 강의 설명, 시청 패턴, 썸네일 특징 같은 정보를 임베딩 공간에 함께 올리면 서로 다른 신호를 한 비교 좌표계에서 다룰 수 있습니다.

그 결과 추천기는 글자만 비슷한 강의보다 실제로 함께 소비되는 강의를 더 앞에 둘 수 있습니다. 이 사례에서 확인해야 할 결과는 제목 단어 일치보다 실제 학습 흐름이 비슷한 강의가 추천 상단에 더 모이는가입니다.

세 사례를 표현 좌표 관점으로 다시 묶으면 다음과 같습니다.

이 사례에서 닫을 판단도 같습니다. 임베딩은 추천의 최종 정답이 아니라 후보를 좁히는 표현 기반이고, 후보는 이후 필터와 정책 판단으로 다시 걸러집니다.

번호, 좌표, 비교 결과 구분하기¶

이 절을 읽은 뒤에는 아직 복잡한 벡터 수식을 몰라도, 아래처럼 지금 내가 보고 있는 것이 번호인가, 좌표인가, 비교 결과인가를 먼저 구분해 보는 예제를 따라갈 수 있습니다.

이 표에서 중요한 것은 정답 수치를 미리 맞히는 일이 아닙니다. 먼저 필요한 것은 번호를 보는가, 표현 좌표를 보는가, 후보 비교 결과를 보는가를 구분하는 일입니다.

여기서 자주 섞이는 층위도 바로 이 세 가지입니다.

• 토큰 ID를 보면 이미 의미 비교가 시작됐다고 느끼기 쉽습니다.
• 임베딩 벡터를 보면 너무 내부 값 같아서 그냥 지나치기 쉽습니다.
• 가깝다는 결과를 보면 곧 정답이라고 받아들이기 쉽습니다.

의미와 거리, RAG와 벡터 검색 설명을 읽으려면 이 세 층위를 먼저 나눠 볼 수 있어야 합니다.

연습 및 예제¶

이 연습의 목표는 토큰 ID는 단지 번호이고, 실제 비교는 임베딩 벡터 위에서 일어난다는 점을 구분해 보는 것입니다. 먼저 Python으로 ID 순서와 벡터 거리 순서가 달라지는 장면을 확인하고, 이어서 같은 값을 손으로 다시 읽습니다.

예제. ID 순서와 벡터 거리 순서 비교하기¶

이 예제는 실제 LLM 임베딩을 학습하는 코드가 아닙니다. 대신 numpy 배열로 작은 표현 표를 만들고, 항목 ID의 숫자 순서와 질의 벡터(query vector)에 가까운 순서가 어떻게 다른지 봅니다. 직접 조작할 값은 query_vector와 embeddings입니다. 값을 바꾸면 거리 순서와 가장 가까운 표현 항목이 달라집니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

# 토큰 ID 숫자 순서와 임베딩 벡터 거리 순서가 다르다는 점을 확인하는 예제입니다.
import numpy as np

token_ids = {
    "prompt_limit_phrase": 1042,
    "factuality_risk_phrase": 3881,
    "vector_search_phrase": 2210,
}

# 조작 변수: 표현 벡터나 query_vector를 바꾸면 가까운 항목 순서가 달라집니다.
embeddings = {
    "prompt_limit_phrase": np.array([0.12, -0.08, 0.44]),
    "factuality_risk_phrase": np.array([0.09, -0.02, 0.39]),
    "vector_search_phrase": np.array([-0.30, 0.11, 0.15]),
}
query_vector = np.array([0.10, -0.01, 0.41])

def squared_distance(a, b):
    return float(np.sum((a - b) ** 2))

id_order = sorted(token_ids.items(), key=lambda item: item[1])
distance_order = sorted(
    (
        (name, token_ids[name], squared_distance(query_vector, vector))
        for name, vector in embeddings.items()
    ),
    key=lambda item: item[2],
)

print("ID order:")
for name, token_id in id_order:
    print(name, token_id)

print("\nVector distance order:")
for name, token_id, distance in distance_order:
    print(name, "token_id=", token_id, "distance=", round(distance, 3))

실행 결과 예시는 다음과 같습니다.

1
2
3
4
5
6
7
8
9

ID order:
prompt_limit_phrase 1042
vector_search_phrase 2210
factuality_risk_phrase 3881

Vector distance order:
factuality_risk_phrase token_id= 3881 distance= 0.001
prompt_limit_phrase token_id= 1042 distance= 0.006
vector_search_phrase token_id= 2210 distance= 0.242

이 출력에서 봐야 할 값은 ID order와 Vector distance order가 다르다는 점입니다. ID가 가장 작은 항목은 prompt_limit_phrase이지만, 질의 벡터와 가장 가까운 항목은 factuality_risk_phrase입니다. 따라서 토큰 ID는 식별용 번호이고, 임베딩 벡터는 이후 거리 비교에 쓰이는 좌표 표현입니다.

관찰할 값은 다음 세 묶음입니다.

질의 벡터는 [0.10, -0.01, 0.41]이라고 가정합니다. 거리값은 질의 벡터와 각 표현 벡터가 얼마나 가까운지 보여 주기 위해 미리 계산해 둔 설명용 값입니다. 지금 중요한 것은 거리 공식을 외우는 일이 아니라, ID 숫자의 크기와 벡터 공간에서의 가까움이 서로 다른 판단이라는 점입니다.

거리 기준으로 표현 항목을 정렬하면 다음과 같습니다.

이 표에서 바로 확인할 개념은 하나입니다. 임베딩을 사용한 비교는 토큰 ID 일치나 ID 크기 비교가 아니라, 벡터 공간에서의 거리와 방향을 기준으로 가까운 항목을 고릅니다.

표현 공간에서 보이는 거리 차이¶

앞의 예시는 임베딩을 학습하는 절차가 아니라, 번호를 붙이는 일과 비교 가능한 수치 표현으로 바꾸는 일이 다르다는 점을 가장 짧게 보여 주는 장면입니다. 마지막으로 아래 세 질문에 답하며 층위를 고정합니다. 질문마다 먼저 스스로 답한 뒤, 바로 아래 해설과 비교합니다.

해설: 토큰 ID는 항목을 가리키는 번호입니다. 숫자 1042가 3881보다 작거나 크다는 사실만으로 두 표현 항목의 의미가 더 가깝다고 말할 수 없습니다. 임베딩 벡터는 비교 가능한 좌표 표현이므로 질의 벡터와의 거리를 계산할 수 있습니다. 가까운 항목 순서는 정답 확정이 아니라 다음 검색, 근거 확인, 생성 단계로 넘길 1차 후보 선정 결과입니다.

즉, 이 절의 닫힘은 임베딩이 벡터다를 외우는 데 있지 않고, 번호, 좌표, 후보 비교를 각각 다른 층위로 읽을 수 있게 되는 데 있습니다. 여기서 읽어야 할 핵심은 1042와 3881의 숫자 차이 자체는 아무 뜻이 없지만, 벡터 공간에서는 질의와 factuality_risk_phrase가 vector_search_phrase보다 더 가깝다는 비교가 가능해진다는 점입니다. ID는 식별용이라면, 임베딩은 이후 유사도 비교와 문맥 계산을 가능하게 하는 표현 공간의 출발점입니다.

연습 1. ID 크기와 의미 거리 분리하기¶

관찰값:

먼저 스스로 답해 봅니다.

• 3881이 1042보다 크다는 사실은 factuality_risk_phrase가 더 중요하거나 더 멀다는 뜻인가?
• ID 숫자만 보고 어느 표현 항목이 질의와 더 가까운지 말할 수 있는가?

해설: 그렇지 않습니다. 1042와 3881은 사전이나 저장소 안의 항목 번호일 뿐이므로, 두 수의 크기 차이로 의미 관계를 판단할 수 없습니다. 3881 - 1042 = 2839라는 계산은 가능하지만, 그 값은 두 표현 항목이 질의와 얼마나 비슷한지를 말해 주지 않습니다. 이 연습에서 먼저 분리해야 할 것은 계산할 수 있는 숫자처럼 보인다와 의미 비교에 쓸 수 있는 좌표다가 같지 않다는 점입니다.

연습 2. 벡터 거리 직접 비교하기¶

관찰값:

먼저 스스로 답해 봅니다.

• 가장 가까운 항목은 무엇인가?
• 가장 먼 항목은 무엇인가?
• 이 판단은 ID가 아니라 어떤 값을 기준으로 했는가?

해설: 가장 가까운 항목은 거리값이 가장 작은 factuality_risk_phrase입니다. 가장 먼 항목은 거리값이 가장 큰 vector_search_phrase입니다. 여기서 비교 기준은 ID가 아니라 질의 벡터와 표현 벡터 사이의 거리입니다. 따라서 prompt_limit_phrase의 ID 1042가 가장 작아도, 이 예시의 벡터 공간에서는 factuality_risk_phrase가 질의에 더 가까운 항목이 됩니다. 이것이 임베딩을 비교 가능한 좌표 표현으로 읽어야 하는 이유입니다.

연습 3. 가까운 항목을 정답으로 오해하지 않기¶

관찰값:

먼저 스스로 답해 봅니다.

• 1순위 항목은 곧 정답인가?
• 가까운 항목을 바로 답변에 써도 되는가?
• 이 결과는 다음 단계에서 무엇으로 써야 하는가?

해설: 1순위 항목은 정답 확정이 아닙니다. factuality_risk_phrase가 질의 벡터에 가장 가까워도, 실제 질문에 답할 근거가 충분한지, 사용자가 물은 범위와 맞는지는 별도로 확인해야 합니다. 따라서 이 결과는 바로 답이 아니라 먼저 검토할 후보 목록으로 써야 합니다. 임베딩 관점은 정답 판정기가 아니라, 번호로는 불가능했던 후보 비교를 가능하게 하는 표현 기반입니다.

배경으로만 짚으면¶

임베딩은 LLM 시대에만 등장한 개념이 아닙니다. 자연어 처리에서는 오래전부터 단어를 분산 표현(distributed representation)으로 바꾸는 연구가 이어졌고, word2vec 같은 연구가 비슷한 문맥의 단어는 비슷한 벡터가 될 수 있다는 감각을 널리 퍼뜨렸습니다.

LLM 시대에는 이 개념이 더 넓어졌습니다.

• 단어뿐 아니라 토큰, 문장, 문서가 임베딩 대상이 되었고
• 생성 모델 내부 표현과 검색 서비스의 표현이 더 직접 연결되었기 때문입니다

체크리스트¶

• 임베딩을 계산이 가능한 좌표 표현이라는 말로 다시 설명할 수 있는가?
• 토큰 ID와 임베딩 벡터가 맡는 역할 차이를 구분할 수 있는가?
• 벡터를 만든 뒤에는 무엇을 기준으로 가깝다고 볼 것인가라는 질문이 이어진다는 점을 설명할 수 있는가?

출처와 참고 자료¶

• Yoshua Bengio et al., A Neural Probabilistic Language Model, Journal of Machine Learning Research, 2003, 확인 날짜: 2026-07-19. 단어의 distributed representation을 학습해 언어 모델 일반화에 쓰는 배경 근거로 사용했다.
• Tomas Mikolov et al., Efficient Estimation of Word Representations in Vector Space, arXiv, 2013, 확인 날짜: 2026-07-19. word2vec 계열의 dense word vector와 문맥 기반 표현 학습 배경 근거로 사용했다.
• Daniel Jurafsky, James H. Martin, Speech and Language Processing, 3rd ed. draft, online manuscript released January 6, 2026, 확인 날짜: 2026-07-19. 임베딩, 벡터 표현, 언어 모델 입력 설명의 일반 NLP 배경 근거로 사용했다.