“임베딩이 뭔데? 문서에 임베딩 한다고 써 있는데 번역인가요?” “벡터 데이터베이스? 데이터베이스는 아는데 벡터가 붙으면 뭐가 달라지는 거예요?” “ChatGPT한테 오늘 뉴스 물어봤더니 작년 일을 진지하게 답하더라고요. 최신 모델인데 왜 그래요?” — 뉴스, 도구 홈페이지, 개발자 문서 어디서나 이 단어들이 튀어나옵니다. 그런데 이름은 수없이 들어도 정작 “그래서 그게 무슨 뜻이고, 내가 쓸 때 무슨 상관인데?”를 한 줄로 설명하지 못하는 분이 훨씬 많습니다. 문제는 이 세 단어가 AI가 ‘기억’을 다루는 방식의 뼈대라는 겁니다. 임베딩을 모르면 문서 검색이 왜 “키워드가 아닌 의미로” 되는지 이해할 수 없고, 벡터 DB를 모르면 RAG가 왜 “관련 문서를 찾을 수 있는지”를 놓치며, 지식 절단을 모르면 최신 정보를 물어놓고 엉뚱한 답을 받아도 원인을 가릴 수 없습니다.
요약 (TL;DR): 임베딩 · 벡터 DB · 지식 절단 핵심 요약 임베딩은 텍스트의 의미를 컴퓨터가 계산할 수 있는 숫자 배열로 바꾸는 변환으로, NotebookLM이 올린 PDF의 내용을 이해하고 질문에 답하는 것이 이 변환의 결과입니다. 벡터 데이터베이스는 그 숫자 배열들을 저장해 두고 비슷한 의미를 가진 것을 빠르게 찾아주는 창고라, Notion에서 키워드가 정확히 안 맞아도 관련 페이지가 검색되는 이유가 여기 있습니다 — 일반 DB와 같다고 생각하면 검색 품질 차이를 이해하지 못합니다. 지식 절단은 모델이 학습한 데이터의 마지막 시점으로, 그 이후의 사건·정보는 모델이 모르기 때문에 최신 뉴스를 물으면 작년 정보로 답하거나 지어냅니다. “최신 모델이니까 최신 정보도 알겠지”가 가장 흔한 잘못된 기대입니다.
이 글은 5분 안에 읽고 AI가 기억을 저장하고 찾는 세 단어 — 임베딩 · 벡터 데이터베이스 · 지식 절단을 정리합니다. 각 용어마다 “그래서 내 화면·결정에서 무슨 상관인가”를 NotebookLM·Notion·Gemini 같은 화면에서 직접 확인하는 방식으로 풀고, 흔히 빠지는 오해와 한계도 짚습니다. 도구 사용법이 아니라 개념을 먼저 잡는 글입니다.
왜 “기억”인가? 우리 블로그의 2편 프롬프트·RAG·파인튜닝에서 RAG의 뼈대를 잠깐 소개했지만, 그 RAG가 돌아가는 엔진이 바로 이번 세 단어입니다. 5편 파라미터·어텐션·스트리밍이 모델이 답을 ‘만드는’ 과정을 다뤘다면, 이 글은 모델이 ‘기억을 저장하고 꺼내는’ 과정을 다룹니다 — ‘AI 용어 사전’ 시리즈의 여섯 번째 글입니다.
임베딩·벡터 데이터베이스·지식 절단은 각각 무슨 뜻일까?
이 섹션에서 배우는 것: 세 단어를 한 줄씩 먼저 훑고, 각각이 내 화면·판단에서 어떻게 나타나는지 보기.
| 용어 | 한 줄 정의 | 내 화면에서는 | 이걸 모르면 생기는 일 |
|---|---|---|---|
| 임베딩 | 텍스트(단어·문장)의 의미를 컴퓨터가 계산할 수 있는 숫자 배열로 바꾸는 변환 | NotebookLM이 올린 PDF의 내용을 이해하고 질문에 답하는 것 | ”AI가 내 문서를 읽는다”는 말의 진짜 의미를 놓침 |
| 벡터 데이터베이스 | 임베딩으로 만든 숫자 배열들을 저장하고, 비슷한 의미를 가진 것을 빠르게 찾아주는 창고 | Notion에서 키워드가 정확히 안 맞아도 관련 페이지가 검색되는 것 | 일반 DB와 벡터 DB를 같다고 생각하고 검색 품질 차이를 이해 못 함 |
| 지식 절단 | 모델이 학습한 데이터의 마지막 시점 — 그 이후의 사건·정보는 모델이 모름 | 최신 뉴스를 물어봤는데 작년 정보로 답하거나 지어내는 것 | ”최신 모델이니까 최신 정보도 알겠지”라는 잘못된 기대를 함 |
⚠️ 각 모델의 정확한 지식 절단 시점, 임베딩 모델의 종류, 벡터 DB 제품의 기능은 플랫폼·버전마다 다르고 자주 바뀝니다. 이 글은 2026년 8월 기준의 개념 설명이며, 정확한 수치와 최신 지원 현황은 각 사 공식 문서에서 확인하세요. 출처: OpenAI 임베딩 가이드, Google NotebookLM, Pinecone, Hugging Face
용어 1: 임베딩(Embedding) — “텍스트를 숫자로? 왜?”
이 섹션에서 배우는 것: 임베딩이 ‘텍스트의 의미를 숫자 배열로 바꾸어 컴퓨터가 계산할 수 있게 만드는 변환’이라는 것, 그리고 그게 왜 문서 검색과 RAG의 출발점인지.
임베딩은 텍스트의 의미를 컴퓨터가 계산할 수 있는 숫자 배열로 바꾸는 작업입니다. 예를 들어 “사과는 달다”가 포함된 문장과 “달은 지구의 위성”이 포함된 문장은 사람이 보기에는 전혀 다른 주제이지만, 그 내용을 임베딩으로 바꾸면 각각의 숫자 배열이 생깁니다. 중요한 것은 의미가 비슷한 문장은 비슷한 숫자 배열을 받는다는 점입니다. “좋은 영화”와 “재밌는 영화”는 사람이 보기에는 다른 표현이지만 의미상 가까운 말이면 임베딩 공간에서도 가까운 위치에 숫자 배열을 배정합니다. 이렇게 의미를 숫자의 거리로 바꾸면, 컴퓨터는 “이 두 문장이 의미상 얼마나 가까운가”를 수학적으로 계산할 수 있게 됩니다. OpenAI는 이 임베딩 변환을 API로 제공하며, OpenAI 임베딩 가이드에서 동작 방식을 자세히 볼 수 있습니다.
notebooklm.google.com 홈페이지
이게 일상에서 체감되는 순간은 이렇습니다. Google NotebookLM에 PDF를 올리면, NotebookLM은 그 문서의 내용을 임베딩으로 변환하여 저장합니다. 그러면 키워드를 정확히 입력하지 않아도 “이 문서에서 비용 안전을 다루는 부분을 찾아줄”이라고 물어보면, 의미상 관련된 단락을 찾아 답을 만들어 제공합니다. 이게 바로 임베딩이 출발하는 2편에서 다룬 RAG의 첫 단계입니다. 여기서 조심할 오해가 있습니다. 임베딩은 번역이 아닙니다. 번역은 한 언어의 문장을 다른 언어의 문장으로 바꾸는 것이고, 임베딩은 언어와 상관없이 의미를 숫자 배열로 바꾸는 것입니다. 도구들은 임베딩을 이용해 의미 검색을 하지, 언어 번역을 하지 않습니다 — 언어 번역 도구가 필요하면 AI 번역 도구 비교 (2026)를 참고하세요.
5분 안에 직접 확인하기
- notebooklm.google.com 에서 사용해 보고 싶은 문서(PDF, 텍스트)를 올립니다. 올린 후 문서 제목에 없는 단어로 질문을 해보세요 — 키워드가 없어도 답이 나온다면 임베딩이 의미로 검색하고 있는 것입니다.
- huggingface.co 에서 ‘embeddings’를 검색해 보면, 여러 임베딩 모델이 공개되어 있습니다. 각 모델의 설명에서 ‘의미를 벡터로 변환’이라는 표현이 이 단어의 정의임을 확인합니다.
- 매일 쓰는 메일이나 메모 앱에서 기능 단위로 “유사한 메모 추천”이 드는 경험이 있다면, 그 추천이 키워드가 아닌 의미 유사도로 작동하는 것이며, 이게 임베딩 기반의 의미 검색입니다.
잘 안 되는 경우
- 개인정보가 포함된 문서를 임베딩 기반 서비스에 올리는 경우: 임베딩으로 변환된 문서는 서비스의 저장소에 남을 수 있으며, 각 서비스의 데이터 활용 정책에 따라 외부에 노출될 위험이 있습니다. 민감한 정보가 포함된 문서는 서비스 약관을 먼저 확인하고, 개인정보 보호가 보장되지 않으면 올리지 않는 것이 안전합니다.
- 임베딩 품질이 낮은 모델을 쓰는 경우: 같은 “임베딩”이라는 이름이어도 모델마다 의미를 숫자로 바꾸는 정확도가 다릅니다. 품질이 낮으면 비슷한 의미를 전혀 다른 숫자 배열로 만들어 검색 결과가 엉뚱해질 수 있으며, 이는 도구 선택과 모델 버전에 달려 있습니다.
임베딩으로 의미를 숫자로 바꾸었다면, 그 숫자를 어디에 어떻게 저장하고 찾을까? 그다음이 두 번째 단어입니다.
용어 2: 벡터 데이터베이스(Vector DB) — “DB는 아는데, 벡터 DB는 뭔가요?”
이 섹션에서 배우는 것: 벡터 데이터베이스가 ‘임베딩으로 만든 숫자 배열을 저장하고 비슷한 것을 찾아주는 창고’라는 것, 일반 DB와 뭐가 다른지.
벡터 데이터베이스는 임베딩으로 만들어진 숫자 배열(벡터)들을 저장하고, “이 숫자 배열과 가장 비슷한 것은?”이라는 질문에 빠르게 답해주는 특수 데이터베이스입니다. 일반 데이터베이스(MySQL, PostgreSQL 등)는 정확한 키워드 매칭으로 검색합니다 — “제목에 ‘AI’가 들어간 행을 찾아줘”처럼요. 반면 벡터 DB는 **“이 질문의 의미와 가장 비슷한 문서를 찾아줘”**라는, 키워드가 아닌 의미 기반 검색에 특화되어 있습니다. 예를 들어 “직원이 퇴사할 때 주의사항”이라는 질문이 들어오면, 일반 DB는 ‘퇴사’라는 단어가 포함된 행만 찾지만, 벡터 DB는 ‘근무 종료’, ‘이직’, ‘퇴직금’ 같은 의미상 가까운 문서도 함께 찾아줍니다. Pinecone, Chroma 같은 전용 벡터 DB 제품이 이 역할을 전문적으로 수행하며, Pinecone 공식 사이트에서 구조를 확인할 수 있습니다.
notion.so 홈페이지
일상에서 벡터 DB가 작동하는 모습은 Notion의 검색에서 체감할 수 있습니다. Notion에서 정확한 페이지 제목이나 키워드를 기억하지 못해도, 비슷한 의미의 단어로 검색하면 관련 페이지가 나옵니다. 이것이 가능한 이유는 Notion이 페이지 내용을 임베딩으로 변환하여 벡터 DB에 저장하고, 검색어와 의미상 가장 가까운 페이지를 찾아주기 때문입니다. 여기서 핵심은 벡터 DB가 일반 DB를 ‘대체’하는 것이 아니라는 점입니다. 두 데이터베이스는 용도가 다릅니다. 정확한 레코드 조회(주문 번호, 사용자 ID)는 일반 DB가 빠르고 정확하며, 의미 기반 유사도 검색은 벡터 DB가 전문입니다. 많은 서비스가 두 가지를 함께 씁니다 — Notion AI 지식 관리 (2026)에서 이 구조가 실제 도구에서 어떻게 나타나는지 볼 수 있습니다.
5분 안에 직접 확인하기
- notion.so 에서 비슷한 주제의 페이지를 두 개 만들고, 서로 다른 단어로 같은 의미를 적어보세요. 그런 다음 한쪽 페이지의 단어를 검색해 보면, 정확한 키워드가 아닌데도 다른 페이지가 결과에 나오는지 확인할 수 있습니다.
- pinecone.io 의 문서를 읽어보면, “vector search”와 “keyword search”를 구분해서 설명하는 것을 볼 수 있습니다. 이 구분이 벡터 DB와 일반 DB의 차이입니다.
- 회사 위키나 문서 관리 도구에서 “내가 쓴 적 없는 단어로 검색했는데 내 문서가 나온 적이 있다면”, 그 도구가 벡터 DB(또는 의미 검색)를 사용하고 있다는 뜻입니다. 이 경험을 의식적으로 떠올려 보세요.
잘 안 되는 경우
- 벡터 DB를 일반 DB처럼 쓰려고 하는 경우: 벡터 DB는 의미 유사도 검색에 특화되어 있지, 정확한 레코드 조회나 트랜잭션 처리에 적합하지 않습니다. “주문 번호로 조회” 같은 작업은 일반 DB가 훨씬 빠르고 정확하며, 용도를 혼동하면 성능과 정확성 모두 떨어집니다.
- 저장된 데이터가 많아지면 검색 속도가 느려지는 경우: 벡터 DB는 데이터 양이 늘어날수록 유사도 계산 비용이 커집니다. 수백만 건 이상에서는 인덱싱 전략(HNSW 등)에 따라 속도와 정확도의 균형이 달라지며, 이는 제품 선택과 설정 튜닝의 영역입니다.
벡터 DB가 “저장하고 찾는 창고”라면, 마지막 단어는 모델이 원래 아는 지식의 한계를 가리킵니다. 임베딩과 벡터 DB는 바로 이 한계를 보완하기 위해 쓰입니다.
용어 3: 지식 절단(Knowledge Cutoff) — “오늘 뉴스를 왜 모르지?”
이 섹션에서 배우는 것: 지식 절단이 ‘모델이 학습을 멈춘 시점’이라는 것, 그래서 최신 모델이라도 최신 정보를 모를 수 있는 이유. 그리고 이 한계를 RAG가 어떻게 보완하는지.
지식 절단은 모델이 학습한 데이터의 마지막 시점을 뜻합니다. AI 모델은 특정 시점까지의 텍스트를 학습하여 만들어지는데, 그 시점 이후의 사건·뉴스·정보는 학습하지 않았으므로 모릅니다. 예를 들어 모델의 지식 절단이 2025년 1월이라면, 2025년 6월에 일어난 일에 대해서는 학습한 적이 없으므로 답을 하지 못하거나, 최악의 경우 그럴듯하게 지어냅니다 — 이것이 1편에서 다룬 환각과 이어지는 지식 절단의 위험입니다. ChatGPT, Gemini, Claude 모두 각자 다른 지식 절단 시점을 가지며, 그 시점은 버전이 올라갈 때마다 달라집니다. 정확한 시점은 각사 공식 문서에서 확인해야 하며 — OpenAI 도큐먼트, Google AI 개발자 문서, Anthropic 문서 — 뉴스나 블로그에서 “이 모델의 지식 절단은 언제다”라고 단정하는 정보는 버전에 따라 이미 틀릴 수 있습니다.
gemini.google.com 홈페이지
여기서 자주 빠지는 오해가 있습니다. “최신 모델이니까 최신 정보도 알 것이다”라는 기대입니다. 모델이 ‘최신’이라는 것은 구조·성능이 개선되었다는 뜻이지, 학습 데이터가 ‘오늘’까지라는 뜻이 아닙니다. 다만 최근 많은 서비스가 웹 검색 기능을 추가하여 이 한계를 보완하고 있습니다 — ChatGPT의 검색 기능, Gemini의 실시간 정보 연동이 그 예입니다. 하지만 이는 모델이 ‘알아서’ 아는 것이 아니라, 검색 결과를 컨텍스트에 끌어와 답을 만드는 구조이며, 이 구조의 뼈대가 바로 2편의 RAG입니다. 즉 임베딩과 벡터 DB는 지식 절단이라는 근본적 한계를 보완하는 핵심 도구입니다. 모델이 모르는 최신 정보를 외부에서 찾아와 답에 끼워 넣는 것이죠. AI 리서치 도구 (2026)에서 이 검색 보완이 실제로 어떻게 도와주는지 볼 수 있습니다.
5분 안에 직접 확인하기
- gemini.google.com 이나 chatgpt.com 에서 “오늘 날짜의 주요 뉴스”를 물어보세요. 검색 기능이 꺼져 있으면 작년 정보로 답하거나 “최근 정보를 모른다”고 답합니다. 이것이 지식 절단입니다.
- 같은 질문을 검색 기능을 켜고 다시 해보세요. 답이 달라진다면, 그것은 모델이 새로 학습한 것이 아니라 검색 결과를 끌어온 것입니다. 모델의 지식과 검색 보완은 다른 층위의 작업입니다.
- 모델이 답한 내용에 “이 사건은 언제 일어났나?”를 확인해 보세요. 최근 사건인데 자신감 있게 답한다면, 그 출처가 검색인지 학습인지를 가리는 감각이 지식 절단을 이해하는 핵심입니다.
잘 안 되는 경우
- 지식 절단 이후의 의료·법률·금융 정보를 맹신하는 경우: 모델이 학습하지 않은 최신 규정·약관·처방 지침에 대해 답할 때, 모델은 그럴듯하게 지어낼 수 있습니다. 최신 정보가 중요한 결정(투자, 진료, 계약)에는 모델의 답을 단정하지 말고 공식 출처를 반드시 교차 확인하세요.
- 검색 기능이 켜져 있다고 완벽하다고 기대하는 경우: 검색 보완(RAG)은 결과 품질이 검색 결과의 질에 달려 있습니다. 검색이 잘못된 문서를 가져오면 답도 틀리며, 출처를 확인하지 않으면 잘못된 정보를 확신하게 됩니다. 검색 기능이 있다고 지식 절단의 위험이 사라지는 것이 아닙니다.
⚠️ 모델의 정확한 지식 절단 시점은 버전마다 다르고 공식적으로 명시되지 않는 경우도 많습니다. “이 모델은 무조건 OOO년까지만 안다”고 단정하지 말고, 최신 정보는 항상 공식 출처에서 확인하세요.
세 단어가 이어지는 한 흐름
이 섹션에서 배우는 것: 임베딩·벡터 DB·지식 절단이 각각 따로 놀지 않고 “기억을 만들고 저장하고 보완하는” 한 흐름으로 연결된다는 것.
이 세 단어는 사실 하나의 흐름을 다른 각도에서 본 것입니다. 텍스트의 의미를 숫자로 바꾸어(임베딩) 저장하고(벡터 DB), 모델이 원래 모르는 최신 정보를 그 저장소에서 찾아 보완합니다(지식 절단의 해법). 즉 “의미를 숫자로 → 숫자를 창고에 → 창고에서 빼내어 모르는 것을 채운다”의 한 줄입니다. 이 흐름을 한 번 그려두면, NotebookLM이 왜 내 문서를 읽고 답하는지, Notion 검색이 왜 키워드가 아닌 의미로 되는지, 최신 모델이 왜 오늘 뉴스를 모르는지가 한 번에 정리됩니다.
| 흐름 단계 | 이번 글의 단어 | 하는 일 | 결과가 나타나는 곳 |
|---|---|---|---|
| 변환 | 임베딩 | 텍스트의 의미를 숫자 배열로 바꾸어 계산 가능하게 만듦 | 문서의 내용을 “이해”하고 질문에 답하는 모습 |
| 저장 · 검색 | 벡터 DB | 숫자 배열을 저장하고 비슷한 의미를 가진 것을 찾아줌 | 키워드가 아니어도 관련 문서를 찾아주는 검색 |
| 한계 보완 | 지식 절단 | 모델이 학습을 멈춘 시점 이후의 정보를 외부에서 채움 | RAG로 최신 정보에 답하거나, 검색 없이는 못 답하는 모습 |
이 표를 2편의 RAG 설명과 겹쳐 보면 재미있습니다. 2편이 RAG를 “외부 지식을 끌어오는 방법”으로 소개했다면, 이번 편은 그 RAG가 “왜 작동하는지”를 세 단어로 풀었습니다. 임베딩이 변환이고, 벡터 DB가 창고이고, 지식 절단이 이 둘이 필요한 이유입니다. 세 단어를 합치면 RAG라는 단어의 무게가 한결 가벼워집니다.
자주 묻는 질문 3가지
Q. 임베딩과 RAG는 같은 건가요? 아닙니다. 임베딩은 텍스트의 의미를 숫자로 바꾸는 ‘변환 작업’이고, RAG는 그 임베딩을 포함해 외부 지식을 찾아와 답을 만드는 ‘전체 과정’입니다. 임베딩은 RAG의 첫 단계입니다. 자세한 배경은 2편 프롬프트·RAG·파인튜닝을 참고하세요.
Q. 벡터 DB가 일반 데이터베이스를 대체하나요? 아닙니다. 용도가 다릅니다. 일반 DB는 정확한 키워드 매칭과 트랜잭션에 강하고, 벡터 DB는 의미 유사도 검색에 특화되어 있습니다. 많은 서비스가 두 종류를 함께 사용합니다. Notion AI 지식 관리 (2026)에서 이 구조를 볼 수 있습니다.
Q. 모델에 웹 검색 기능이 있으면 지식 절단 문제가 없어지나요? 완전히 없어지지는 않습니다. 검색 기능은 외부에서 최신 정보를 끌어와 답에 반영하지만, 검색 결과의 질과 출처 신뢰성에 따라 답이 달라집니다. 검색이 잘못된 정보를 가져오면 답도 틀립니다. “검색 기능이 있으니 무조건 최신 정보를 안다”는 기대는 위험합니다. Google AI 개발자 문서에서 각 모델의 검색 연동 방식을 확인할 수 있습니다.
요약
세 단어를 한 문장씩만 기억해도 AI가 기억을 다루는 방식이 그림으로 잡힙니다.
- 임베딩 → 텍스트의 의미를 숫자 배열로 바꾸는 변환. “AI가 내 문서를 이해한다”는 말의 출발점.
- 벡터 데이터베이스 → 숫자 배열을 저장하고 비슷한 의미를 찾아주는 창고. 키워드가 아닌 의미로 검색하는 이유.
- 지식 절단 → 모델이 학습을 멈춘 시점. “최신 모델인데 최신 뉴스를 모른다”는 현상의 원인.
세 단어를 “의미를 숫자로 → 창고에 저장 → 모르는 것을 채운다”의 한 줄로 묶어두면, RAG와 문서 검색의 원리가 한눈에 들어옵니다. 이번 주에는 한 가지만 해 보세요 — NotebookLM이나 Notion에서 검색을 할 때, “이 결과가 키워드로 나온 건가, 의미로 나온 건가?”를 한 번 떠올리는 것입니다. 그 작은 질문 하나가 도구가 작동하는 방식을 다르게 보이게 합니다. 다음 글에서는 “지도학습 · 비지도학습 · 강화학습, AI가 어떻게 배우는가”를 이어서 풀 예정입니다.