[AI] Embedding부터 VectorDB까지, Week2 학습 내용 정리

 

 

[AI] LLM 학습 노트 공개 - Transformer부터 RAG까지, 그리고 운영 가능한 AI 시스템을 향해

 

ㅁ 들어가며

Week 2에서는 Embedding부터 VectorDB까지,
  RAG 시스템의 검색 품질을 결정하는 핵심 요소들을 하나씩 정리해 왔다.

 

처음에는 단순히
  “임베딩을 만들고, 벡터 검색을 하면 되겠지”라고 생각했다.

 

하지만 실제로 파고들어 보니 전혀 아니었다.

Embedding
   → Chunking
   → Vector Similarity
   → ANN(HNSW)
   → VectorDB 구조와 튜닝

 

이 모든 요소가 하나의 검색 파이프라인으로 연결되어 있었고,
   어느 하나라도 잘못 설계되면 RAG 품질은 바로 무너졌다.

 

이번 글에서는
  그동안 쪼개서 정리했던 내용을 다시 묶어,

  Week 2: Embedding & Vector Database를 총체적으로 어떻게 이해하게 되었는지
정리해 보려고 한다.

 

ㅁ Week 2의 출발점: “의미를 어떻게 저장할 것인가”

Week 2의 시작은 아주 단순한 질문이었다.

Transformer가 만들어낸 ‘의미’를
우리는 어디에, 어떤 형태로 저장해야 할까?

이 질문에 대한 답으로 가장 먼저 정리한 글이 아래였다.

• [AI] Embedding 기초 — Transformer가 만든 의미를 저장하는 방법

 

이 글에서 정리한 핵심은 이것이다.

• 임베딩은 단순한 숫자 배열이 아니다
• 문장, 문단, 문서의 의미 좌표다
• VectorDB는 이 좌표를 저장하고 탐색하는 시스템이다

 

즉,
RAG에서 검색이란 “문서를 찾는 행위”가 아니라
  의미 공간에서 가까운 좌표를 찾는 문제였다.

 이것은 마치 우리가 생각을 할 때에 그 흐름이 어느 주제와 가깝다고 느끼는 것을 의미 공간으로 표현한다.

 

ㅁ Chunking: VectorDB 성능은 여기서 이미 결정된다

Embedding을 이해하고 나니,
  다음 질문은 자연스럽게 이어졌다.

그럼, 무엇을 하나의 벡터로 만들 것인가?

 

이 질문이 바로 Chunking 문제다.

이를 정리한 글이 다음이다.

• [AI] Chunking Strategy — 청크 전략과 크기 최적화, RAG 품질의 출발점

이 과정을 통해 확실히 느낀 점은 하나였다.

Chunking은 전처리가 아니라 Retriever 설계 그 자체다.

• Chunk가 너무 작으면 → 의미는 정확하지만 맥락이 깨지고
• Chunk가 너무 크면 → 맥락은 좋지만 검색 정확도가 떨어진다

즉,
Chunking은 Recall과 Context 품질 사이의 첫 번째 트레이드오프였다.

 

ㅁ Vector Similarity: “가장 중요한 수학”

Chunk를 만들고 벡터를 저장했다면, 이제 남은 질문은 이것이다.

“가깝다”는 걸 어떻게 정의할 것인가?

 

이를 다룬 글이 다음이다.

• [AI] Vector Similarity — RAG에서 ‘가장 중요한 수학’

Cosine, Dot Product, L2 Distance는 모두 “두 벡터가 얼마나 비슷한가”를 재는 방법이지만,

"무엇을 기준으로 비슷하다고 판단하느냐"가 다르다.

 

Cosine Similarity는 벡터의 방향만 본다. 길이는 무시하고, 같은 방향을 향하면 비슷하다고 본다.

그래서 문서 길이가 다르더라도 의미만 비교하고 싶을 때 적합하다.

 

Dot Product는 방향과 함께 벡터의 크기까지 반영한다. 같은 방향이면서 크기가 클수록 점수가 커지기 때문에, 의미 유사성과 동시에 “강도”나 “중요도”까지 포함한 비교에 가깝다.

 

반면 L2 Distance는 완전히 다른 관점이다. 두 벡터 사이의 물리적인 거리를 잰다. 좌표 공간에서 얼마나 멀리 떨어져 있는지를 보는 방식이라, 값의 스케일에 매우 민감하다.

 

직관적으로 말하면,

  Cosine은 “같은 방향을 보고 있나”,

  Dot은 “같은 방향 + 얼마나 세게인가”,

  L2는 “서로 얼마나 떨어져 있나”를 묻는 질문이다.

 

RAG나 VectorDB에서 Cosine이 많이 쓰이는 이유는,

  우리가 보통 의미의 방향을 비교하고 싶지,

  문장의 길이나 벡터 크기 자체를 비교하고 싶은 경우는 드물기 때문이다.

 

Cosine, Dot Product, L2 Distance를 정리하면서

한 가지 중요한 사실을 깨달았다.

• 대부분의 임베딩 모델은 방향 정보가 핵심이다
• RAG 검색에서는 크기보다 의미 방향이 중요하다
• 그래서 Cosine Similarity가 사실상 표준처럼 쓰인다

그리고 더 중요한 결론은 이것이었다.

임베딩이 L2 정규화되어 있다면
Cosine, Dot Product, L2 Distance는 거의 같은 의미를 가진다.

 

즉,
  모델 학습 방식과 메트릭 선택은 분리해서 볼 수 없다.

 

ㅁ ANN과 HNSW: 정확한 검색은 불가능하다

Vector Similarity를 이해하고 나니
  또 하나의 현실적인 벽을 마주하게 된다.

벡터가 수백만 개라면,
매번 정확한 최근접 탐색이 가능할까?

 

대답은 명확하다.

불가능하다.

 

그래서 등장하는 개념이 ANN(Approximate Nearest Neighbor)이고,
그중 실무에서 가장 많이 쓰이는 구조가 HNSW다.

 

이를 정리한 글이 다음이다.

• [AI] HNSW — ANN부터 파라미터 튜닝까지, RAG 검색 성능의 진짜 핵심

이 글을 통해 관점이 완전히 바뀌었다.

• VectorDB 검색은 정확한 검색이 아니다
• 항상 Recall과 Latency의 트레이드오프 위에 있다
• ef, M 같은 파라미터는 “옵션”이 아니라 품질 레버다

즉,
  RAG에서 “검색이 느리다 / 잘 못 찾는다”는 문제는
  대부분 HNSW 튜닝 문제로 귀결된다.

 

ㅁ VectorDB: 검색 엔진이 아니라 “의미 인프라”

여기까지 이해하고 나서야
  비로소 VectorDB를 제대로 바라볼 수 있게 되었다.

 

이를 Weaviate를 기준으로 정리한 글이 다음이다.

• [AI] Weaviate Usage — VectorDB를 ‘검색 엔진’이 아니라 ‘의미 저장소’로 쓰는 법

이 글을 쓰면서 확신하게 된 점은 이것이다.

VectorDB는 데이터베이스라기보다
의미 공간을 유지·탐색하는 인프라에 가깝다.

• 벡터는 파생 데이터다
• 원본 문서가 SSOT(Source of Truth)다
• 재임베딩과 재인덱싱은 언제든 가능해야 한다

즉,
  VectorDB는 RAG 파이프라인에서
  후보 생성기(Retriever) 역할을 맡는다.

 

ㅁ 그래서, RAG용 VectorDB 튜닝이 왜 중요한가

Week 2를 통해 Embedding부터 VectorDB까지의 흐름을 정리하며 한 가지 결론에 도달했다.

 

RAG 품질은
  모델, Embedding, Prompt보다
  Retriever 설계에서 가장 크게 갈린다.

  그리고 Retriever의 품질은 결국 다음 요소들로 수렴한다.

• 문서를 어떻게 나누는가 (Chunking 전략)
• 의미를 어떻게 비교하는가 (Similarity 메트릭)
• 얼마나 정밀하게 탐색하는가 (ANN / HNSW 파라미터)
• 이를 어떤 기준으로 운영하는가 (VectorDB 인덱스와 튜닝 전략)

즉, VectorDB는 단순한 저장소가 아니라
  RAG 검색 품질을 결정하는 핵심 설계 영역이다.

  그리고 RAG용 VectorDB 튜닝은 ‘옵션’이 아니라 필수 설계 영역이다.

이 결론을 바탕으로 실제 RAG 환경에서 VectorDB를 어떻게 튜닝하고 운영해야 하는지를
[AI] RAG용 VectorDB 튜닝에 정리하였다.