AI 공부 지도 F5 (ko)

단어를 숫자로 바꾼다는 게 대체 무슨 말인가

by

이 글은 「AI 공부 지도」 시리즈의 5편(F5) / 전체 20편 중
앞 편: F4 — Attention Is All You Need 해설
다음 편: F6 — 모델은 어떻게 학습하는가

0. 들어가기 전에

F1 부터 F4 까지 오시느라 수고 많으셨어요. 지금쯤이면 “Transformer 가 뭔지, attention 이 뭘 하는 건지” 는 머리에 어느 정도 자리 잡으셨을 거예요. 그런데 이 시리즈 내내 “벡터” 라는 말이 계속 나왔습니다. 단어를 벡터로 바꾼다, Q·K·V 도 벡터다, attention 은 벡터끼리 내적한다, 이런 식으로요.

이번 편은 그 “벡터” 라는 말의 뿌리를 파는 편입니다. 구체적으로는 단어나 문장을 숫자 덩어리 (벡터) 로 바꾸는 기술 — 그러니까 embedding 이요. LLM, RAG, 의미 검색, 추천 시스템, 전부 이 한 층 위에서 돌아갑니다. 이 층을 감각적으로 잡아두면 앞으로 나올 편들 (F6 학습편, F7 RAG 편, M1 retrieval layer 편 등) 이 훨씬 수월해질 거예요.

이 글의 목표는 딱 하나입니다. “왕 – 남자 + 여자 = 여왕” 이라는 이상한 뺄셈이 실제로 돌아간다 는 이야기 있잖아요. 그게 무슨 뜻인지, 어떻게 그게 가능한지, 그리고 그게 지금 우리가 쓰는 모든 AI 도구와 어떻게 연결되는지 — 끝까지 풀어보는 겁니다.

비유는 지도 한 장을 씁니다. 단어들이 널려 있는 거대한 지도를 떠올리시면 돼요. 비슷한 의미는 가까이 있고, 관계 없는 단어는 멀리 있는 지도. 이 이미지 하나만 붙들고 가시면 임베딩이 끝까지 읽힙니다.

1. 왜 컴퓨터는 “사과” 라는 단어를 그대로 못 다루나

시작점은 좀 단순한 질문이에요. 컴퓨터는 “사과” 라는 단어를 읽을 수 있나요.

글자 그대로 표시할 수는 있어요. 화면에 “사과” 를 찍는 건 그냥 픽셀 패턴의 문제니까요. 그런데 “사과” 와 “배” 가 비슷한 과일이라는 걸 컴퓨터가 계산으로 알아낼 수 있느냐 는 완전히 다른 얘기예요.

왜냐면 컴퓨터 안에서 문자열은 그냥 기호의 나열 이거든요. “사” 라는 문자 다음에 “과” 라는 문자가 붙어 있을 뿐이에요. 이 두 글자의 조합에 “빨갛고 둥글고 먹을 수 있다” 는 의미는 어디에도 안 적혀 있어요. 마찬가지로 “배” 도 그냥 문자 하나일 뿐, 사과와의 관계 같은 건 컴퓨터 입장에선 모르는 겁니다.

그래서 초창기 자연어처리 (NLP) 는 이 문제를 돌아가는 방법으로 풀었어요. “사과” 와 “배” 가 같이 나오는 문서 수를 세거나, 사전에서 두 단어의 정의가 겹치는 비율을 재거나, 사람이 직접 동의어 사전을 만들거나 했죠. 말이 많고 손이 많이 가는 일이었어요. 그리고 한계가 명확했습니다. 사전에 없는 관계는 못 잡거든요. “사과” 와 “아이폰” 의 연관성 같은 건 일반 사전엔 안 나오니까요.

문제의 핵심은 이거예요. 컴퓨터는 숫자만 잘 다룹니다. 더하고, 빼고, 곱하고, 거리 재고. 기호에 대해서는 뭘 할 수 있는 게 별로 없어요. 그렇다면 질문이 뒤집힙니다. “단어를 숫자로 바꿀 수 있다면, 그 숫자끼리 연산해서 의미를 다룰 수 있지 않을까?” 이 발상이 임베딩의 출발점입니다.

참고로 저는 처음 이걸 공부할 때 “단어를 숫자로 바꾼다” 는 말이 좀 억지스럽게 들렸어요. 단어는 의미가 있는데, 숫자로 바꾸면 그 의미가 어디로 가는 거냐 싶은 거죠. 답을 미리 말씀드리면, 숫자 하나가 아니라 숫자 수백~수천 개의 배열 (벡터) 로 바꿉니다. 그리고 그 배열 안에 의미의 여러 측면이 나눠서 담기는 구조예요. 이 얘기는 뒤에서 천천히 풀게요.

2. 첫 시도: one-hot encoding — 단어마다 독립된 슬롯

단어를 숫자로 바꾸는 가장 단순한 방법부터 볼게요. one-hot encoding 이라는 이름으로 불리는 방식이에요.

아이디어는 말 그대로 단순합니다. 어휘 사전에 있는 단어가 10만 개라고 치죠. 그러면 각 단어에 10만 칸짜리 벡터 를 하나씩 준비합니다. “사과” 라는 단어의 벡터는 17번째 칸만 1이고 나머지는 전부 0. “배” 는 2,341번째 칸만 1. “아이폰” 은 78,562번째 칸만 1. 이런 식이에요.

이 방식의 장점은 명확해요. 간단합니다. 각 단어가 자기 전용 슬롯을 하나씩 갖고 있으니까 겹칠 일이 없어요. 그리고 계산기 관점에서도 다루기 편해요.

그런데 단점은 훨씬 크고, 그 중 하나가 치명적입니다. 모든 단어끼리의 거리가 똑같아요.

말장난 같지만 진지한 얘기예요. “사과” 의 벡터와 “배” 의 벡터를 비교해 보면, 1이 찍힌 위치가 다를 뿐 공통된 성분은 하나도 없어요. 내적 (두 벡터를 곱해서 더한 값) 을 계산하면 0 이 나와요. “사과” 와 “아이폰” 을 비교해도 0. “사과” 와 “수학” 을 비교해도 0. 전부 0 입니다.

즉 one-hot encoding 의 세계에서는 모든 단어가 서로 무관한 독립된 점 이에요. 의미가 가까운지 먼지, 관계가 있는지 없는지, 같은 범주에 속하는지 — 전혀 담기지 않아요. 컴퓨터 입장에서는 “사과” 와 “배” 의 관계가 “사과” 와 “미적분” 의 관계와 정확히 똑같습니다.

또 하나 문제가 있어요. 어휘가 커지면 차원이 미친 듯이 커집니다. 10만 단어 = 10만 차원. 대규모 코퍼스에서는 어휘가 수백만을 넘어가는데, 단어 하나 표현하는 데 수백만 차원을 쓰는 건 말이 안 되죠. 99.99% 가 0 인 희소 벡터라 메모리도 아까워요.

그래서 이 방식은 “단어를 숫자로 바꾼다” 는 숙제는 풀었지만, “의미를 담는다” 는 본래 목적은 전혀 못 푼 거예요. 이 한계를 넘어서려면 완전히 다른 발상이 필요했습니다. 바로 다음 섹션에서 나오는 공간 비유 예요.

3. 해결: 벡터 공간에 “의미” 를 배치한다는 발상

단어 = 고차원 공간의 좌표 (2D 투영)

왕여왕국왕남자여자사과바나나오렌지자동차비행기

비슷한 의미 단어는 가까이, 관련 없는 단어는 멀리.
실제로는 수백~수천 차원이지만, 여기서는 2D로 투영.

발상을 바꿔봅시다. 단어마다 독립된 슬롯을 주는 게 아니라, 하나의 큰 공간 위에 모든 단어를 뿌려 놓는 거예요. 그리고 그 위치를 잘 잡아서, 의미가 비슷한 단어끼리는 가까이, 관계 없는 단어끼리는 멀리 놓이도록 하자는 겁니다.

지도 비유가 여기서 나와요.

세계 지도를 떠올려 보세요. 서울과 부산은 가까워요. 서울과 뉴욕은 멀죠. 도시 하나하나가 지도 위의 “점” 이고, 두 점 사이의 거리가 “얼마나 가까운가” 를 알려줘요. 이게 지리적 지도라면, 임베딩이 만드는 건 의미의 지도 예요.

임베딩 지도 위에서는:

  • “사과” 와 “배” 와 “바나나” 가 한 동네에 모여 있어요. 과일 동네죠.
  • 조금 떨어진 곳에 “자동차” 와 “비행기” 와 “기차” 가 모여 있고요. 탈것 동네예요.
  • 더 멀리엔 “행복하다” “슬프다” 같은 감정 단어들이 또 자기들끼리 뭉쳐 있고요.
  • “사과” 와 “기쁨” 은 과일 동네와 감정 동네 사이 어디쯤에 느슨하게 관련돼 있을 수 있어요.

이게 전부예요. 단어를 벡터 (좌표) 로 바꾸되, 그 좌표를 의미에 맞게 배치하자. 이 발상 하나가 one-hot encoding 의 한계를 단번에 깨버렸습니다. 왜냐면 이제 단어끼리 “얼마나 가까운지” 가 자연스럽게 숫자로 나오거든요. 좌표만 있으면 거리를 잴 수 있잖아요. 그 거리가 곧 “의미의 유사도” 가 돼요.

한 가지만 미리 짚고 가요. 우리가 떠올리는 지도는 2차원이지만 (종이 위의 x, y 좌표), 실제 임베딩이 쓰는 공간은 훨씬 고차원이에요. 수백~수천~만 차원 이요. 왜 그렇게 많은 차원을 쓰는지는 뒤에 8번 섹션에서 따로 풀게요. 일단 지금은 “고차원 지도 위에 단어들이 점으로 뿌려져 있다” 는 그림만 머리에 넣어 두세요.

그런데 여기서 자연스러운 질문이 하나 나옵니다. 그 좌표를 도대체 누가, 어떻게 정하지? 사람이 단어 수십만 개의 좌표를 일일이 찍을 수는 없잖아요. 이 질문에 대한 대답이 바로 Word2Vec 이에요.

4. 어떻게 그 “좌표” 를 찾나 — Word2Vec 의 직관

2013년에 Google 의 Tomas Mikolov 팀이 Word2Vec 이라는 방법을 발표했어요. 이 방법이 임베딩을 대중화시킨 분수령이에요. 이전에도 벡터 공간 모델 시도는 있었지만, Word2Vec 은 대규모 텍스트를 주면 좌표가 자동으로 잡힌다 는 걸 실용적인 속도로 보여줬거든요.

핵심 아이디어는 언어학에서 빌려왔어요. Distributional Hypothesis 라는 건데, 번역하면 “분포 가설” 이에요. John Rupert Firth 라는 언어학자의 유명한 말로 요약돼요.

“You shall know a word by the company it keeps.”
(한 단어는 그 주변에 오는 단어들을 보면 알 수 있다.)

이 말을 실무 감각으로 풀어볼게요. 다음 두 문장을 보세요.

  • “고양이는 생선을 좋아한다.”
  • “강아지는 간식을 좋아한다.”

이 두 문장에서 “고양이” 와 “강아지” 는 비슷한 위치에 등장 하죠. 둘 다 동물이고, 둘 다 뭔가를 좋아한다고 나와요. 이런 식의 문맥 겹침을 수천, 수만, 수억 문장에서 쌓아 올리면 결국 “고양이” 와 “강아지” 는 거의 비슷한 맥락에서 쓰인다 는 통계가 나옵니다. 그러면 둘의 벡터를 가까이 배치하는 게 자연스러워요. 반면 “고양이” 와 “미분방정식” 은 같이 나오는 일이 거의 없겠죠. 벡터도 멀리 놓입니다.

Word2Vec 의 구체적인 훈련 방식은 두 가지가 있어요.

  • CBOW (Continuous Bag of Words): 주변 단어들을 보고 가운데 단어를 맞히는 과제. “고양이는 ___ 을 좋아한다” 에서 빈칸을 예측하는 거죠.
  • Skip-gram: 거꾸로, 가운데 단어를 보고 주변 단어들을 맞히는 과제. “생선” 을 주면 주변에 “고양이” “좋아” 가 올 확률이 높다는 식이에요.

두 방식 다 “문맥을 예측하는 과제를 풀게 시키는” 구조 예요. 그 예측을 잘 하려면 모델이 각 단어의 벡터를 잘 배치해야 하거든요. 그래서 과제 자체는 단어 맞히기인데, 부산물로 의미가 잘 배치된 벡터 공간이 튀어나오는 겁니다. 똑똑한 설계죠.

여기서 감이 오셔야 할 게 있어요. Word2Vec 은 사람이 “고양이와 강아지는 비슷해” 라고 가르쳐 준 적이 없습니다. 그냥 엄청난 양의 자연어 데이터를 주고, 빈칸 맞히기 시켰을 뿐이에요. 그런데 그 과제를 풀다 보니 모델이 스스로 “고양이” 와 “강아지” 의 벡터를 가까이 놓게 된 거예요. 의미의 구조가 통계에서 자연스럽게 떠오른 거죠.

이 자기지도학습 (self-supervised learning) 의 힘이 그 뒤 BERT, GPT 로 이어지는 모든 LLM 의 기본 동력이에요. 라벨링 없이, 그냥 “다음 단어 맞히기” 같은 과제만 시키면 모델이 언어의 구조를 알아서 배우거든요. 시작점이 바로 Word2Vec 이었던 겁니다.

5. 유명한 벡터 수학 — “왕 – 남자 + 여자 = 여왕”

자 이제 이 시리즈의 하이라이트예요. Word2Vec 이 2013년에 주목받은 결정적 에피소드가 있어요. 벡터 공간 위에서 진짜로 의미의 산수가 돌아간다 는 거였어요.

한국어로 옮기면 이렇게 돼요. 벡터를 v(단어) 로 표기할게요.

v(왕) - v(남자) + v(여자) ≈ v(여왕)

풀어 읽으면 “왕이라는 벡터에서 남자다움이라는 성분을 빼고, 여자다움을 더했더니 여왕 벡터가 나왔다” 는 얘기예요. 이게 진짜 실험적으로 확인됐어요. 그냥 근사적으로 맞는 정도가 아니라 상당히 깔끔하게 맞습니다.

처음 이 결과를 볼 때 저는 뭔가 속는 기분이었어요. “설마 이게 될까” 싶은 거죠. 수학적인 뺄셈 한 번으로 의미의 관계가 튀어나온다는 건 너무 드라마틱하잖아요. 그런데 원리를 따라가 보면 왜 되는지 자연스럽게 이해가 됩니다.

포인트는 이거예요. Word2Vec 이 단어를 벡터로 배치할 때, 의미의 여러 축을 서로 다른 방향으로 분배해서 저장 해요.

감각적으로 풀어볼게요. 고차원 공간 안에서 어떤 방향 은 “성별 축” 에 해당합니다. 그 방향으로 조금 이동하면 “남성성 → 여성성” 쪽으로 옮겨 가요. 또 다른 방향 은 “왕족성 축” 이에요. 그 방향으로 이동하면 “평민 → 왕족” 으로 옮겨갑니다. 이 축들이 사람이 미리 지정한 게 아니라 훈련 과정에서 자연스럽게 등장 해요.

그렇게 훈련되면 이런 관계가 성립합니다.

  • “왕” = (왕족성 성분 + 남성성 성분 + 기타)
  • “여왕” = (왕족성 성분 + 여성성 성분 + 기타)
  • “남자” = (평민 성분 + 남성성 성분 + 기타)
  • “여자” = (평민 성분 + 여성성 성분 + 기타)

여기서 왕 - 남자 를 하면 남성성이 서로 상쇄되고, 왕족성에서 평민 성분을 뺀 “왕족 추출물” 같은 게 남아요. 거기에 여자 를 더하면 “왕족 추출물 + 여성성 + 평민 성분” 이 되고, 이게 바로 여왕의 벡터 구성과 거의 일치하는 겁니다.

충격적인 건, 이런 “의미 축의 분해” 를 사람이 설계한 적이 없다 는 거예요. Word2Vec 은 그냥 주변 단어 예측 과제를 풀었을 뿐인데, 최적의 답을 찾다 보니 의미를 이렇게 좌표축에 얹는 구조가 튀어나왔어요. 마치 세계를 숫자로 “번역” 하는 법을 스스로 발명한 것처럼요.

이게 임베딩이 왜 신기한지를 말해주는 단적인 사례예요. 벡터 공간에는 의미가 기하학적 관계로 들어 있어요. 뺄셈이 “차이 추출” 이 되고, 덧셈이 “속성 부여” 가 되는 세계죠. “파리 – 프랑스 + 독일 ≈ 베를린” 같은 수도 관계도 비슷하게 잡혀요. “달리다 – 걷다 + 먹다 ≈ 뛰어먹다 (?)” 같은 동사 변형 관계도 어느 정도 잡히고요.

물론 모든 관계가 이렇게 깔끔하게 풀리는 건 아니에요. 학습 데이터에 없는 문화·도메인 관계는 흔들리고, 한국어처럼 형태소가 풍부한 언어에서는 “-은/는” 같은 조사 처리 때문에 관계가 흐려지기도 합니다. 그래도 “의미가 벡터 위에 기하학적으로 배치된다” 는 큰 그림은 수많은 후속 연구에서 재확인됐어요.

이 에피소드가 왜 중요하냐면, 지금 우리가 쓰는 LLM, RAG, 의미 검색, 추천 시스템 모두 이 “의미의 기하학” 위에서 돈다 는 걸 보여주기 때문이에요. 왕-남자+여자=여왕 이 되는 공간 감각이 바로 ChatGPT 가 맥락을 이해하는 원리의 가장 깊은 바닥에 있어요. 층이 올라갈수록 계산 방식은 복잡해지지만, 뿌리는 여기 있습니다.

6. 현대 임베딩은 “단어” 단위가 아닌 “맥락” 단위

Word2Vec 이 멋있긴 한데, 한 가지 큰 한계가 있었어요. 같은 단어는 항상 같은 벡터 예요.

예를 들어 “배” 라는 단어. 한국어에서 “배” 는 과일일 수도, 신체 부위일 수도, 선박일 수도 있어요. 그런데 Word2Vec 은 이 세 가지 의미 전부를 하나의 벡터로 때워 버려요. 문맥에 따라 구분이 안 되는 거죠. 영어로 치면 “bank” 가 은행이기도 하고 강둑이기도 한데 하나의 벡터만 있는 상황이에요.

실무에서 이건 큰 문제가 돼요. “배가 아프다” 의 배 벡터와 “배를 탔다” 의 배 벡터가 똑같으면, 의미 검색 같은 걸 만들 때 관련 없는 문서가 섞여 들어와요.

이 한계를 깬 게 2018년 이후의 contextual embedding 이에요. 대표가 BERT (2018) 예요. BERT 이후 임베딩은 같은 단어라도 문맥에 따라 다른 벡터를 출력 해요.

어떻게요? 앞 편 F4 에서 얘기한 Transformer 구조를 떠올려 보세요. Attention 이 문장 전체를 훑으면서 단어들 사이 관계를 계산해요. 그 결과로 각 단어는 주변 단어의 정보가 녹아든 벡터 로 업데이트되죠. “배가 아프다” 라고 쓰면 “배” 벡터 안에 “아프다” 가 녹아들어서 “신체 부위 느낌이 나는 배” 벡터가 나와요. “배를 탔다” 에서는 “선박 느낌이 나는 배” 벡터가 나오고요.

이게 현대 임베딩의 핵심 업그레이드예요. Word2Vec 은 단어 사전 이었고, BERT 이후는 문장 해석기 예요. 입력으로 단어 하나가 아니라 문장 (또는 긴 문서) 을 넣으면, 그 맥락 안에서의 의미가 담긴 벡터를 돌려줘요.

지금 실무에서 많이 쓰이는 임베딩 도구들은 대부분 이 계보예요.

  • OpenAI embedding API (text-embedding-3-small, text-embedding-3-large): OpenAI 가 제공하는 범용 임베딩. 문장 단위로 입력해서 벡터를 받아옵니다. 2026년 기준 RAG 구축에서 제일 많이 쓰이는 선택지 중 하나예요.
  • sentence-transformers (오픈소스): BERT 계열을 문장 임베딩용으로 튜닝한 모델들. all-MiniLM-L6-v2 같은 가벼운 모델부터 큰 multilingual 모델까지 있고, 로컬에서 돌릴 수 있어서 비용·프라이버시 면에서 유리해요.
  • BGE, E5, Cohere embed, Voyage 같은 2024~2026년 신모델들: 성능·다국어 대응·비용에서 각자 강점을 가지고 경쟁하고 있어요.

2026년 관점에서 말씀드리면, 이제 임베딩 모델은 문장 → 벡터 수준을 넘어서 긴 문서 → 벡터 까지 다뤄요. 8K 토큰, 32K 토큰 입력을 한 번에 받는 모델들이 있고, RAG 파이프라인에서 chunk 를 어떻게 자르느냐는 고민은 여전히 남지만 예전보다 여유가 많이 생겼어요. 이 얘기는 이 시리즈 후반 M1 (Retrieval Layer) 편에서 더 다루게 됩니다.

핵심만 한 문장으로 정리하면, Word2Vec 은 “단어를 벡터로”, BERT 이후 현대 임베딩은 “맥락 속 단어·문장·문서를 벡터로” 옮깁니다. 근본 발상은 같지만 해상도가 비교할 수 없이 올라간 거예요.

7. 이게 RAG·의미 검색의 뿌리

자, 여기까지 오시면 왜 “임베딩이 RAG 의 뿌리” 라는 말을 자주 듣게 되는지 감이 잡혀요.

RAG (Retrieval-Augmented Generation) 는 LLM 에 외부 문서를 덧붙여서 답변하게 하는 구조예요. 예를 들어 “우리 회사 휴가 규정이 어떻게 되죠?” 라고 물으면, 먼저 사내 문서에서 관련 부분을 찾아 와서 (retrieval), 그걸 LLM 에 같이 넣어서 답변을 만들게 (generation) 하는 거예요.

이 과정에서 “관련 부분을 찾아온다” 는 단계가 어떻게 돌아갈까요. 옛날 방식으로는 키워드 매칭 이었어요. “휴가” 라는 글자가 들어간 문서를 검색해서 가져오는 거요. 이건 한계가 명확해요. 사용자가 “쉬는 날 규칙” 이라고 물으면, “휴가” 로 쓰여 있는 문서를 못 찾아요. 글자가 안 겹치니까요.

임베딩이 이 문제를 깨버립니다. 흐름은 이렇게 됩니다.

  1. 사내 문서들을 적당한 크기로 잘라서 (chunking), 각 조각을 임베딩 모델에 넣어 벡터로 변환한다. 이 벡터들을 벡터 DB (Pinecone, Weaviate, Chroma, pgvector 등) 에 저장한다.
  2. 사용자가 질문을 하면, 그 질문도 같은 임베딩 모델에 넣어 벡터로 변환한다.
  3. 질문 벡터와 거리가 가까운 문서 벡터를 상위 몇 개 (top-k) 꺼낸다. 거리 측정은 대개 코사인 유사도 를 쓴다.
  4. 그 문서들을 LLM 에 같이 넣어서 답을 만들게 한다.

여기서 중요한 건 “거리가 가까운” 을 판단하는 기준이 키워드가 아니라 의미 라는 거예요. 질문의 “쉬는 날 규칙” 이라는 벡터는 사내 문서의 “휴가 규정” 이라는 벡터와 의미적으로 가까운 곳에 놓여 있어요. 글자는 안 겹치지만 의미가 겹치니까요. 이게 의미 검색 (semantic search) 이에요.

저는 이 순간이 AI 검색의 패러다임 전환점이라고 생각해요. 검색이 키워드 매칭이 아니라 의미 매칭으로 바뀐 순간. 이게 지금 ChatGPT 의 “Talk to your data”, Claude 의 Projects, Perplexity 의 AI 검색, Notion AI 의 Q&A 등 거의 모든 현대 AI 도구의 밑바닥에 깔려 있어요.

실무적 관점에서 하나 덧붙이면, 이 원리를 이해하는 것과 이해하지 않는 것의 차이가 RAG 를 만들 때 크게 드러나요. 예를 들어 “왜 내 RAG 가 엉뚱한 문서를 끌어오지?” 라는 문제의 원인은 대부분 (a) 임베딩 모델이 도메인에 안 맞거나, (b) chunk 를 너무 크게 or 작게 잘랐거나, (c) 질문 자체가 여러 의도를 섞고 있어서 벡터가 애매한 지점에 찍히거나 — 이 중 하나예요. 이 세 가지를 의심할 줄 알면 디버깅이 빠르게 풀립니다.

8. 벡터 차원 수는 왜 높나

앞에서 지도 비유를 할 때 “실제로는 수백~수천 차원이다” 라고 말하고 넘어갔잖아요. 여기서 조금 더 들어가 볼게요.

구체적인 숫자부터 말씀드리면:

  • Word2Vec 계열: 보통 100~300 차원
  • BERT base: 768 차원
  • OpenAI text-embedding-3-small: 1,536 차원 (감소 가능)
  • OpenAI text-embedding-3-large: 3,072 차원
  • GPT-3 모델 내부의 임베딩 차원 (hidden size): 12,288 차원

사람의 직관으로는 3차원 공간이 한계예요. x, y, z 까지는 상상이 되잖아요. 4차원 이상은 우리 시각으론 그릴 수 없어요. 그런데 기계는 차원이 몇 개든 똑같은 방식으로 거리를 계산 합니다. 각 차원의 좌표 차이를 제곱해서 더하고 루트를 씌우는 거리 공식에 차원 수 제한이 없거든요. 그래서 사람 눈엔 부담스러워도 기계 입장에선 아무 문제 없어요.

차원이 많을수록 뭐가 좋냐 하면, 미세한 의미 구분이 가능 해져요.

감각적인 설명을 해볼게요. 차원 하나는 “의미의 한 축” 에 해당한다고 봐요 (정확히는 축들이 얽혀 있지만, 감각적으론 이렇게 이해해도 돼요). 2차원 평면 위에서는 “성별” 축과 “연령” 축만 구분할 수 있어요. 남자·여자, 어린이·어른 정도의 큰 구분이죠. 근데 차원이 1,000개 있으면, 성별·연령·직업·감정·시간·장소·형식성·긍정성 등등 수없이 많은 축을 동시에 담을 수 있어요. 그 많은 축에 걸쳐 단어를 배치하면 훨씬 미세한 의미 차이까지 구분할 수 있게 돼요.

“사과 (과일)” 와 “사과 (사죄)” 가 한 평면 위에 있다면 구분이 안 될 수 있지만, 1,000 차원 공간에서는 “과일성 축” 에 잡힌 사과 (과일) 와 “행위성 축” 에 잡힌 사과 (사죄) 가 명확히 다른 지역에 놓여요.

다만 차원이 많은 게 무조건 좋은 건 아니에요. 트레이드오프가 있어요.

  • 계산 비용: 차원이 늘면 벡터 연산 (내적, 거리 계산) 이 비례해서 느려져요. RAG 에서 수백만 개 문서 벡터와 질문 벡터를 매번 비교한다고 하면, 차원이 10배면 시간·비용도 10배 가까이 듭니다.
  • 저장 비용: 벡터 DB 가 많은 디스크를 먹어요. 1,000만 문서 × 3,072 차원 × 4 byte = 약 122GB 정도. 스타트업 규모에선 만만치 않아요.
  • 효율 감소 구간: 어느 지점 이상에서는 차원을 더 늘려도 품질 향상이 거의 없어요. 연구상으로 task 에 따라 다르지만, 일반적으로 1,000~4,000 차원 사이에서 대부분의 수익이 실현된다고 봐요.

그래서 최근에는 Matryoshka Embedding 같은 기법도 등장했어요. 하나의 임베딩을 훈련해 두면, 필요에 따라 앞부분 N 차원만 잘라 써도 품질이 유지되는 방식이에요. 정확도가 필요할 땐 3,072 차원 전부 쓰고, 빠른 검색이 필요할 땐 앞 256 차원만 쓰는 식이죠. OpenAI text-embedding-3 계열이 이 구조를 지원해요.

실무 결론은 이래요. 그냥 제일 큰 차원을 고르지 말고, 정확도·속도·비용의 교집합을 보고 결정하세요. 작은 코퍼스면 768~1,536 차원으로 충분하고, 정밀도가 중요한 대규모 retrieval 이면 3,072 차원을 고려하고요. 고차원이 “좋다” 가 아니라 “용도에 맞다” 가 맞는 표현이에요.

9. 실무에서 쓸 때 주의점

임베딩이 작동하는 원리는 위에서 쭉 풀었고, 이제 실제로 쓸 때 발에 걸리기 쉬운 지점들을 정리해 볼게요. 저도 처음 RAG 만들 때 몇 번 삽질한 부분들이에요.

(a) 모델마다 임베딩 공간이 다릅니다

이게 가장 중요한 함정이에요. OpenAI 임베딩으로 만든 벡터와 BERT 로 만든 벡터를 같은 공간에서 비교하면 안 됩니다. 숫자로는 둘 다 1,536 차원 혹은 768 차원 벡터이지만, 각 차원이 의미하는 축이 완전히 달라요. 모델마다 훈련 데이터·아키텍처·목적함수가 달라서, 같은 “사과” 라도 OpenAI 공간과 BERT 공간에서 전혀 다른 위치에 찍혀요.

실제로 이렇게 실수하는 케이스가 있어요. DB 에 들어 있는 문서 벡터는 예전에 OpenAI text-embedding-ada-002 로 만들었는데, 쿼리를 새로 text-embedding-3-small 로 만들어서 비교하는 경우. 두 모델은 차원도 같고 OpenAI 가 만든 건데도 서로 호환이 안 돼요. 검색 결과가 완전히 이상해집니다.

원칙은 하나예요. 문서와 쿼리는 반드시 같은 임베딩 모델로 만든 벡터여야 한다. 이걸 “embedding space consistency” 라고 불러요. 이 규칙만 지켜도 RAG 디버깅의 절반은 날아가요.

(b) 임베딩 모델을 바꾸면 DB 전체 재계산

(a) 의 연장선인데, 더 실무적인 고통이에요. 만약 프로젝트 중간에 “더 좋은 임베딩 모델로 업그레이드하자” 는 결정이 나면, 기존에 저장해 둔 모든 문서 벡터를 재계산 해야 해요. 수백만 개 문서가 있으면 재계산 비용이 상당합니다. 시간도 오래 걸리고, API 비용도 쌓여요.

그래서 실무 설계 팁:

  • 초기에 임베딩 모델을 신중하게 고른다 (벤치마크 확인 + 샘플 데이터로 테스트)
  • 모델 마이그레이션 절차를 미리 설계해 둔다 (점진적 업그레이드, dual-write, fallback)
  • 가능하면 모델 버전을 벡터 메타데이터에 함께 저장한다

저는 개인적으로 처음 RAG 을 만들 땐 비싼 대형 모델보다 가벼운 오픈소스 모델 (sentence-transformers 계열) 로 시작하는 걸 추천해요. 비용이 거의 0 이고, 품질도 꽤 좋아서 초기에 뭘 해야 하는지 감을 잡기 좋거든요. 규모가 커질 때 대형 API 로 옮기면 돼요.

(c) 한국어 vs 영어 품질 차이

이건 한국어 사용자 입장에서 중요한 포인트예요. 많은 임베딩 모델이 영어 데이터 비중이 압도적 이라서, 한국어 성능이 영어보다 떨어집니다. 대표적으로:

  • 같은 의미의 영어 문장은 잘 묶는데, 한국어 문장은 덜 묶여요.
  • 한국어 조사 (“-은/는/이/가”) 때문에 미묘한 변이가 생겨도 벡터가 흔들립니다.
  • 기술 용어·외래어 (“코드”, “데이터”) 는 한국어 맥락에서도 영어 기준으로 처리되는 경우가 있어요.

다행히 2024년 이후 한국어·다국어 대응 임베딩이 많이 나오고 있어요. multilingual-e5, bge-m3, jina-embeddings-v2-ko, Voyage multilingual 등. 한국어 중심 프로젝트라면 이런 multilingual 모델이나 한국어 특화 모델을 먼저 벤치마크해 보시길 권해요. 영어 벤치마크 상위 모델이 자동으로 한국어에서 좋진 않습니다.

(d) chunk 크기 전략

사실 이게 RAG 품질의 숨은 절반을 차지해요. 임베딩 모델이 아무리 좋아도, chunk 를 엉뚱하게 자르면 retrieval 이 엉킵니다.

  • 너무 큰 chunk (예: 5,000 자) → 하나의 벡터 안에 여러 주제가 섞여서 의미가 뿌얘짐
  • 너무 작은 chunk (예: 50 자) → 맥락이 없어서 의미를 잡지 못함
  • 적정선 (대개 200~1,000 자 근처, 도메인에 따라 다름) → 한 조각이 한 주제에 집중되도록

문서 구조에 따라 단락 단위·문장 단위·슬라이딩 윈도우 등 다양한 전략이 있어요. 임베딩 품질에 문제가 생겼을 때 모델을 바꾸기 전에 chunk 전략을 먼저 의심 하는 습관을 들이시면 실무에서 시간이 많이 절약됩니다.

10. Tokenizer 와 embedding 의 관계 (보너스)

마지막으로 짧게, 자주 헷갈리는 세 층의 구분을 깔끔하게 정리하고 끝낼게요. 단어, 토큰, 임베딩 벡터 이 셋은 다릅니다.

흐름은 이래요.

원문 문자열 → (tokenizer) → 토큰 ID → (embedding) → 벡터
  • 단어 는 사람이 보는 언어 단위. “임베딩” 은 한 단어.
  • 토큰 은 모델이 보는 단위. 단어 하나가 토큰 하나가 아닐 수 있어요. 한국어에서는 “임베딩” 이 임, 베, 딩 처럼 나눠질 수도 있고, 영어에서는 unbelievable 이 un, believ, able 로 쪼개질 수도 있어요. Tokenizer 가 이 분할 규칙을 결정합니다. BPE, WordPiece, SentencePiece 같은 알고리즘이 쓰여요.
  • 임베딩 벡터 는 각 토큰에 할당된 숫자 배열. 모델 안에서는 토큰이 ID 로 표현되고, 그 ID 에 해당하는 벡터를 “embedding matrix” 에서 꺼내 씁니다.

즉 임베딩의 입력은 단어가 아니라 토큰 이에요. 먼저 tokenizer 가 문자열을 토큰으로 쪼개고, 그 토큰 ID 로 embedding matrix 를 조회해서 벡터가 나오는 거죠.

이 구분이 실무에서 왜 중요하냐면, “토큰 수 = 비용” 구조 때문이에요. OpenAI, Anthropic 모두 API 비용이 토큰 수에 비례합니다. 한국어는 영어보다 토큰화 효율이 떨어져서 같은 정보를 담는 데 토큰이 1.5~2배 쓰여요. 즉 한국어 RAG 은 영어 RAG 보다 토큰 비용이 체감적으로 더 큽니다. 이걸 모르고 설계하면 청구서에서 놀라요.

또 하나. Tokenizer 가 다른 두 모델은 임베딩 공간이 더 갈라져 있을 가능성 이 높아요. 토큰 분할 방식부터 다르면 벡터의 의미도 달라지거든요. 섹션 9 에서 말한 “모델마다 공간이 다르다” 는 규칙이 여기서 한 번 더 강조됩니다.

그러니까 임베딩을 공부하실 땐 이 세 층을 머리 속에서 분리 해 두세요. “단어 ≠ 토큰 ≠ 임베딩 벡터”. 이 구분만 깨끗해져도 RAG, 프롬프트 엔지니어링, fine-tuning 관련 문서가 훨씬 잘 읽혀요.

11. 한 장의 지도로 정리

여기까지 오시느라 고생 많으셨어요. 한 번 정리하면 이렇게 돼요.

  • 컴퓨터는 숫자만 다룰 줄 아는데, 문자열엔 의미가 직접 담겨 있지 않아요. 그래서 단어를 숫자로 바꾸는 작업이 필요 합니다.
  • One-hot encoding 은 단어에 독립된 슬롯을 주지만, 의미 관계는 전혀 담기지 않아요. 모든 단어가 서로 무관해져요.
  • 발상의 전환은 고차원 공간 위에 단어를 점으로 뿌리고, 의미가 가까운 단어끼리 가까이 배치하자 는 것이었어요. 이게 임베딩의 핵심 아이디어입니다. 비유하면 의미의 지도 한 장을 그리는 거예요.
  • Word2Vec (2013) 이 대규모 데이터로 이 좌표를 자동으로 찾아내는 방법을 보여줬어요. 주변 단어 예측이라는 과제를 풀게 하니 의미 공간이 자연스럽게 등장했어요.
  • 그 결과 “왕 – 남자 + 여자 = 여왕” 같은 벡터 수학이 실제로 돌아간다는 게 확인됐고, 이게 임베딩이 주목받은 결정적 에피소드예요.
  • BERT (2018) 이후 임베딩은 문맥 단위 로 진화했어요. 같은 단어도 맥락에 따라 다른 벡터가 나와요. OpenAI embedding API, sentence-transformers, BGE, E5 같은 게 그 계보예요.
  • 이 구조가 RAG, 의미 검색, 추천 시스템, AI 검색 엔진의 뿌리 입니다. 검색이 키워드 매칭이 아니라 의미 매칭이 되는 순간이 바로 여기서 열려요.
  • 실무에서는 모델 간 호환 불가, 모델 교체 시 재계산 부담, 한국어 품질 차이, chunk 전략 네 가지를 특히 조심하세요.
  • 토큰 ≠ 단어 ≠ 임베딩 벡터. 이 세 층은 분리해서 생각해야 합니다.

F6 에서는 이제 모델이 실제로 어떻게 이런 벡터 공간을 “학습” 하는가 를 다룰 거예요. Loss, gradient descent, backpropagation 같은 말이 나오지만, 오늘처럼 비유 먼저 끌고 갈게요. 많은 것이 이 편과 이어져요. 임베딩이 “결과물” 이라면, F6 는 그 결과물을 만드는 “과정” 이에요.

한 문장 닫음: 임베딩은 단어·문장·문서를 “의미의 지도” 위의 좌표로 옮기는 일이고, 그 지도 위에서 거리는 의미의 유사도가 되며, 덧셈·뺄셈은 의미의 연산이 된다. 지금 우리가 쓰는 거의 모든 AI 검색·RAG·추천이 이 한 장의 지도 위에서 돌아가고 있다.

다음 읽기

  • F6 — 모델은 어떻게 학습하는가 [준비 중]
  • F7 — 프롬프트 엔지니어링의 원리 [준비 중]
  • M1 — Retrieval Layer 가 왜 필요한가 [준비 중]

시리즈 처음부터: F1 — LLM 이란 무엇인가 · F2 — Transformer 는 무엇을 했나 · F3 — 딥러닝이 그냥 큰 계산인 이유 · F4 — Attention Is All You Need 해설

자주 묻는 질문 (FAQ)

Q1. 임베딩이랑 LLM 은 같은 건가요?

다릅니다. 임베딩은 입력을 벡터로 바꾸는 변환기 이고, LLM 은 그 벡터들을 입력으로 받아 다음 토큰을 예측하는 생성기 예요. 순서로 보면 문자열 → 토큰화 → 임베딩 → Transformer 층들 → 다음 토큰 확률 이고, 임베딩은 이 파이프라인의 입구에 해당합니다. LLM 내부에도 자체 임베딩 레이어가 있고, 별도의 임베딩 API (OpenAI embeddings 처럼 벡터만 돌려주는 것) 는 그 레이어를 독립적으로 쓸 수 있게 만든 제품이에요. LLM 이 아주 크고 정교한 기계라면, 임베딩 API 는 그 기계의 한 부품만 꺼내서 쓸 수 있게 한 거죠.

Q2. 왜 임베딩 품질이 RAG 품질의 절반밖에 결정 못 하나요?

RAG 품질은 (a) chunk 를 어떻게 잘랐나, (b) 어떤 임베딩 모델을 썼나, (c) 어떤 distance metric 을 썼나, (d) top-k 몇 개를 LLM 에 넣었나, (e) re-ranker 를 썼나, (f) LLM 이 결과를 어떻게 종합했나 — 이렇게 여러 레이어에서 결정됩니다. 임베딩은 이 중 한 축이에요. 가장 큰 축 중 하나이지만 유일한 축은 아니죠. 그래서 “임베딩 모델만 최신 걸로 바꿔도 RAG 가 좋아져요” 는 종종 사실이 아니에요. 전체 파이프라인을 관점으로 디버깅하셔야 해요. 이 시리즈 M1 편에서 retrieval layer 전체를 본격적으로 다룰 예정입니다.

Q3. 지금 당장 임베딩을 실험해 보려면 뭘 쓰는 게 좋을까요?

비용 0 원으로 시작하려면 Python 의 sentence-transformers 라이브러리를 쓰세요. pip install sentence-transformers 한 줄이면 설치되고, all-MiniLM-L6-v2 같은 작은 모델을 로딩해서 문장 몇 개를 벡터로 바꿔 보면 “아, 이게 벡터구나” 감각이 순식간에 잡혀요. 벡터 두 개의 코사인 유사도를 직접 찍어 보시면 “왕 – 남자 + 여자” 비슷한 장난도 해보실 수 있어요. 그 다음 단계로 OpenAI embedding API 를 써서 품질 차이를 비교해 보시거나, pgvector·Chroma 같은 가벼운 벡터 DB 로 미니 RAG 를 만들어 보시면 이 글의 내용이 손에 붙어요.

뉴스레터 구독 안내

매주 월요일, AI·LLM·에이전트 관련 실무 정리를 한 통씩 보내드립니다. 「AI 공부 지도」 시리즈도 이 뉴스레터에서 새 편이 공개될 때마다 먼저 안내드려요. 기술 해설을 차분히 쌓아가고 싶으시면 구독해 주세요.

뉴스레터 구독하기

시리즈 안내 (AI 공부 지도 · 전 20편)
– F1: LLM 이란 무엇인가
– F2: Transformer 는 무엇을 했나
– F3: 딥러닝이 그냥 큰 계산인 이유
– F4: Attention Is All You Need 해설
– F5: Embedding — 단어를 숫자로 바꾸는 이유 (현재 글)
– F6: 모델은 어떻게 학습하는가
– F7: 프롬프트 엔지니어링의 원리
– M1: Retrieval Layer 가 왜 필요한가
– (이하 20편까지)

📍 AI 공부 지도 — 8/29편
이 글은 AI의 기초부터 Meta-Harness·응용 비교까지 순서대로 읽는 29편 시리즈의 8편입니다.
📚 전체 지도 보기

💡 이 편의 한 줄 요약

“왕 – 남자 + 여자 = 여왕”이라는 이상한 벡터 뺄셈이 왜 작동하는지, 단어를 고차원 지도의 좌표로 옮기는 embedding을 풀어낸다.

소스 리스트

著者: 바이브코딩 태일러 (VibeCoding Tailor) — Lovable公式アンバサダー. AI·バイブコーディング専門メディアshuntailor.net運営.
本シリーズ “AI 공부 지도” 22편은 위키 자료와 공식 논문·공식 문서를 근거로 정리한 체계적 학습 커리큘럼입니다.

Post Views: 40
JAKO