임베딩
한 줄 정의
단어나 문장의 뜻을 숫자 여러 개로 바꿔 놓은 것
1. 비유로 이해하기
지도 위의 좌표를 떠올리면 된다.
서울과 인천은 좌표가 가깝고, 부산은 멀다. 두 도시를 가 본 적이 없어도 좌표 숫자만 비교하면 어디가 가까운지 알 수 있다. 지도가 하는 일이 그것이다. 장소를 숫자 두 개로 바꿔 놓아서, 거리를 계산으로 구할 수 있게 만든다.
임베딩은 뜻에 좌표를 붙이는 일이다.
사과 → [0.8, 0.2, 0.9, ...] ┐
배 → [0.7, 0.3, 0.9, ...] ┘ 좌표가 가깝다
자동차 → [0.1, 0.9, 0.1, ...] 멀리 떨어져 있다
실제 임베딩은 좌표가 두 개가 아니라 768개, 1536개, 3072개쯤 된다. 지도가 2차원이라면, 뜻의 지도는 수백 차원인 셈이다.
그리고 이 좌표계에서는 신기한 일이 벌어진다. 좌표끼리 더하고 빼면 뜻도 더해지고 빠진다.
왕 − 남자 + 여자 ≈ 여왕
서울 − 한국 + 일본 ≈ 도쿄
숫자 안에 뜻이 담겨 있다는 증거다.
2. 왜 필요한가
컴퓨터는 “사과”라는 글자를 봐도 그게 “배”와 비슷하고 “자동차”와 다르다는 걸 모른다. 글자는 그냥 부호이기 때문이다. 숫자로 바꿔 놓아야 계산으로 비교할 수 있게 된다.
의미로 검색한다
데이터베이스에서 하는 검색은 글자가 정확히 같아야 찾아진다. “고양이”로 검색하면 “냥이”도 “반려묘”도 안 나온다.
임베딩 검색은 뜻으로 찾는다.
질문: "우리 회사 휴가 며칠이야?"
↓ 임베딩으로 변환
↓ 좌표가 가까운 문서 찾기
찾은 문서: "연차 규정: 입사 1년 후 15일 부여"
← "휴가"라는 단어가 한 번도 안 나오는데 찾아냈다
이 방식을 의미 검색(semantic search)이라고 하고, 이걸로 문서를 찾아 답하는 구조를 RAG(검색 증강 생성)라고 부른다.
에이전트에서 쓰이는 곳
| 용도 | 설명 |
|---|---|
| 문서 검색 (RAG) | 회사 문서에서 관련된 부분만 찾아 모델에 전달 |
| 장기 기억 | 과거 대화를 저장해 두고 관련된 것만 꺼내 온다 |
| 도구 선택 | 도구가 100개면 다 넣을 수 없으니 관련된 몇 개만 골라 넣는다 |
| 중복 제거 | 비슷한 내용인지 판단한다 |
코드로 보면
# 미리: 문서들을 임베딩으로 바꿔 저장 (한 번만)
for doc in documents:
vec = embed(doc) # 문장 → 숫자 1536개
vector_db.save(doc, vec)
# 질문이 올 때마다
q_vec = embed("휴가 며칠?") # 질문도 같은 방식으로 숫자화
results = vector_db.search(q_vec, top_k=3) # 가까운 문서 3개
# 찾은 문서를 모델에게 같이 건네준다
answer = call_model(f"참고자료: {results}\n\n질문: 휴가 며칠?")
“가깝다”를 계산하는 방법은 코사인 유사도를 주로 쓴다. 두 좌표가 같은 방향을 가리키는지 재는 방법이고, 결과는 -1(정반대)에서 1(똑같음) 사이로 나온다.
임베딩을 저장하는 전용 창고를 벡터 데이터베이스라고 한다. Pinecone, Chroma, Qdrant 같은 것들이다. SQLite에도 확장 기능을 붙이면 벡터 검색이 되기 때문에, 처음 만들 때는 SQLite 하나로 충분한 경우가 많다.
3. 어디서 만났나
이 용어는 수업에서 정식으로 다루기 전에 따로 정리한 것이다.
다만 6회차에 임베딩이 왜 필요한지를 정확히 보여 주는 자리가 있었다. 데이터베이스에서 WHERE user = '민수' 같은 검색은 글자가 딱 맞아야 찾아진다. 이 한계가 곧 임베딩이 필요한 이유다.
6회차 — 데이터베이스, 서비스의 기억을 어디에 어떤 모양으로 둘까
4. 헷갈리는 개념
| 이 용어 | 비슷하지만 다른 것 | 차이 |
|---|---|---|
| 임베딩 | 벡터 | 벡터는 그릇의 모양(숫자 한 줄), 임베딩은 그 그릇에 담긴 뜻이다 |
| 임베딩 | 토큰 | 토큰은 글자를 자른 조각. 임베딩은 그 조각에 붙이는 숫자 좌표 |
| 임베딩 | RAG | 임베딩은 재료, RAG는 그 재료로 문서를 찾아 답하는 구조 |
| 임베딩 | 웹의 임베드 | 유튜브 영상을 블로그에 삽입하는 것도 embed다. 뿌리는 같다 — “다른 곳에 끼워 넣는다” |
5. 많이들 오해하는 지점
ㄱ. “임베딩이랑 벡터가 같은 말 아닌가”
거의 같이 쓰이지만 층이 다르다.
- 벡터 — 숫자를 한 줄로 늘어놓은 그릇의 모양
- 임베딩 — 그 그릇에 뜻을 담아 놓은 것
모든 임베딩은 벡터다. 하지만 모든 벡터가 임베딩은 아니다. 키·몸무게·나이를 늘어놓은 [172, 65, 30]도 벡터지만 임베딩은 아니다. 학습을 통해 뜻이 좌표로 배치된 것만 임베딩이다.
ㄴ. “숫자 칸마다 무슨 뜻인지 정해져 있겠지”
3번째 숫자가 ‘단맛’, 7번째가 ‘크기’ 같은 식으로 정해져 있다고 생각하기 쉽다. 그렇지 않다. 각 숫자가 무슨 뜻인지는 아무도 모른다. 사람이 정한 게 아니라 AI가 학습으로 알아낸 배치라서, 열어 봐도 읽히지 않는다.
우리가 아는 건 결과뿐이다. 뜻이 비슷하면 좌표가 가깝게 배치된다는 것.
ㄷ. “임베딩을 쓰면 검색이 정확해진다”
가장 값비싼 오해다. 임베딩 검색은 뜻이 비슷한 걸 찾아 주지, 정확한 걸 찾아 주지 않는다.
주문번호 A-20260913, 날짜, 사람 이름, 상품 코드처럼 딱 맞아야 하는 것은 오히려 기존 방식이 낫다. “A-20260913” 근처에 “A-20260914”가 있으면 임베딩 검색은 그것도 비슷하다고 가져온다.
그래서 실무에서는 둘을 섞어 쓴다. 정확히 일치해야 하는 건 데이터베이스에, 뜻으로 찾아야 하는 건 임베딩에 맡기는 식이다.