임베딩부터 시작해서 벡터 데이터베이스, Similarity Search, ANN, 그리고 HNSW까지 하나씩 보면 이해는 되는데, 막상 전체 흐름을 한 번에 설명하려고 하면 막히는 순간이 있다. 나도 처음에 그랬다. 각각은 알겠는데, “그래서 이게 다 어떻게 연결되는 거지?”라는 느낌이 계속 남았다.
그래서 이번에는 RAG 구조를 처음부터 끝까지 한 번에 정리해보려고 한다. 이 흐름만 제대로 이해하면, 요즘 대부분의 AI 서비스가 어떻게 돌아가는지 감이 확 잡힌다.
임베딩은 모든 것의 시작이다 (텍스트를 의미로 바꾸는 과정)
RAG의 출발점은 항상 임베딩이다. 우리가 사용하는 문장이나 문서를 그대로 두면 컴퓨터는 의미를 이해할 수 없다. 그래서 텍스트를 숫자 벡터로 바꾸는 과정이 필요하다.
예를 들어 문서를 저장할 때:
- 단순 텍스트로 저장하는 것이 아니라
- 임베딩 모델을 통해 벡터로 변환해서 저장한다
이 과정이 중요한 이유는 이후 모든 검색이 “의미 기반”으로 이루어지기 때문이다. 나도 처음에는 그냥 키워드 검색이랑 뭐가 다른 건지 잘 몰랐는데, 직접 비교해보니까 차이가 확 느껴졌다.
단어가 조금 달라도 의미가 비슷하면 찾아주는 게 굉장히 자연스럽게 느껴졌다. 이걸 보고 나서 “아 이게 AI가 이해하는 방식이구나”라는 생각이 들었다.
벡터 DB와 HNSW는 ‘빠르게 찾기’ 위한 핵심 구조다
임베딩으로 데이터를 바꿨다고 끝이 아니다. 이제 중요한 건 “이걸 어떻게 빠르게 찾느냐”다. 여기서 벡터 데이터베이스와 ANN, 그리고 HNSW가 등장한다.
기본적으로 Similarity Search는 벡터 간의 유사도를 계산해서 가장 비슷한 데이터를 찾는다. 하지만 데이터가 많아지면 모든 벡터를 비교하는 것은 현실적으로 불가능하다.
그래서 ANN이라는 개념이 나오고, 그 대표적인 알고리즘이 HNSW다. 이 구조는 벡터들을 그래프로 연결하고, 계층적으로 탐색하면서 빠르게 가까운 값을 찾아간다.
처음에는 이 부분이 가장 어려웠다. 왜 굳이 이렇게 복잡한 구조를 쓰는지 이해가 안 됐는데, 데이터가 많아지는 상황을 생각해보니까 자연스럽게 납득이 됐다.
특히 직접 검색 속도를 비교해보면 차이가 확 난다. 이걸 경험하고 나서야 “이게 없으면 RAG 자체가 성립이 안 되겠구나”라는 느낌이 들었다.
RAG는 ‘검색 + 생성’을 결합한 구조다
이제 마지막 단계다. RAG는 단순히 데이터를 찾는 것이 아니라, 그 데이터를 기반으로 답변을 생성하는 구조다.
전체 흐름을 정리하면 이렇게 된다.
문서 임베딩 → 벡터 DB 저장 → 질문 임베딩 → 유사도 검색(HNSW) → 관련 문서 추출 → AI에게 전달 → 답변 생성
이 과정을 한 번에 이해하고 나니까, 지금까지 배운 내용이 전부 연결되는 느낌이 들었다.
특히 인상 깊었던 건 AI가 “모르는 걸 찾아서 말하는 구조”라는 점이다. 예전에는 AI가 모든 걸 알고 있어야 한다고 생각했는데, 지금은 오히려 필요한 정보를 잘 가져오는 게 더 중요해진 느낌이다.
개인적으로도 이 구조를 이해하고 나서 AI를 보는 시선이 조금 바뀌었다. 단순히 질문하면 답해주는 도구가 아니라, 정보를 찾아서 정리해주는 시스템에 가깝다는 느낌이 들었다.
한 줄로 정리하면 RAG는 임베딩으로 의미를 이해하고, 벡터 DB와 HNSW로 빠르게 검색한 뒤, 그 정보를 기반으로 AI가 답변을 생성하는 구조다.