Similarity Search까지 이해하고 나면 자연스럽게 이런 의문이 생긴다. “그럼 이걸 데이터가 엄청 많을 때도 그대로 쓸 수 있는 걸까?” 나도 처음에는 그냥 벡터끼리 하나씩 비교하면 되는 줄 알았다. 그런데 데이터가 많아지는 순간, 이 방식이 현실적으로 불가능하다는 걸 금방 알게 된다. 이 문제를 해결하기 위해 등장한 개념이 바로 ANN이다.
왜 ‘정확한’ 검색이 아니라 ‘근사’ 검색이 필요할까
가장 단순한 방법은 모든 데이터를 하나씩 비교해서 가장 가까운 벡터를 찾는 것이다. 이걸 정확한 최근접 탐색(Exact Nearest Neighbor)이라고 한다. 문제는 이 방식이 너무 느리다는 점이다.
예를 들어 데이터가 100개면 괜찮지만, 100만 개, 1000만 개로 늘어나면 비교해야 하는 횟수가 기하급수적으로 늘어난다. 실제 서비스에서는 이 정도 규모가 흔하기 때문에, 이 방식은 사실상 사용할 수 없다.
나도 처음에는 “컴퓨터가 빠르니까 괜찮지 않나?”라고 생각했는데, 조금만 계산해보니까 바로 이해가 됐다. 모든 데이터를 다 비교하는 방식은 정확하긴 하지만, 속도가 너무 느려서 실시간 서비스에는 맞지 않는다.
그래서 나온 개념이 ANN이다. 정확히 100% 가장 가까운 것을 찾는 대신, “충분히 비슷한 것”을 훨씬 빠르게 찾는 방식이다. 즉, 약간의 정확도를 포기하고 속도를 얻는 구조다.
ANN은 어떻게 빠르게 검색할 수 있을까
ANN의 핵심은 데이터를 효율적으로 ‘정리’해놓는 데 있다. 단순히 벡터를 쌓아두는 것이 아니라, 비슷한 것들끼리 묶거나 구조를 만들어서 탐색 범위를 줄인다.
대표적인 방식 중 하나가 그래프 기반 구조다. 벡터들을 서로 연결해서 네트워크처럼 만들고, 가까운 것들끼리 연결해두는 방식이다. 이렇게 해두면 전체를 다 볼 필요 없이, 현재 위치에서 가까운 노드들만 따라가면서 탐색할 수 있다.
또 다른 방식은 공간을 나누는 방법이다. 벡터 공간을 여러 구역으로 나누고, 질문 벡터가 들어오면 해당 구역 주변만 집중적으로 탐색하는 방식이다.
이걸 처음 이해했을 때 느낌이 좀 흥미로웠다. 완벽하게 찾으려고 하지 않고, “대충 이 근처일 것 같다”는 방향으로 접근한다는 점이 사람의 직관이랑 비슷하게 느껴졌다.
그래서 ANN은 단순한 알고리즘이라기보다, 속도를 위해 구조를 바꾼 설계라고 보는 게 더 맞는 것 같다.
RAG와 벡터 DB에서 ANN이 중요한 이유
RAG 구조를 생각해보면, 질문이 들어올 때마다 관련 문서를 빠르게 찾아야 한다. 이때 벡터 데이터베이스가 사용하는 핵심 기술이 바로 ANN이다.
만약 ANN이 없다면, 매번 모든 문서를 하나씩 비교해야 한다. 그렇게 되면 응답 속도가 느려지고, 실제 서비스에서는 사용할 수 없는 수준이 된다.
나도 이 부분을 이해하고 나서야 “왜 벡터 DB가 따로 존재하는지” 납득이 됐다. 단순히 데이터를 저장하는 게 아니라, 이 ANN 기반 검색을 효율적으로 수행하기 위한 구조였던 것이다.
특히 직접 테스트해봤을 때, 데이터가 많아져도 속도가 크게 느려지지 않는 걸 보고 꽤 인상 깊었다. 완벽하게 가장 가까운 결과는 아닐 수도 있지만, 실제로 사용하기에는 충분히 정확했다.
결국 중요한 건 “완벽한 정답”이 아니라 “빠르고 충분히 좋은 결과”라는 걸 이 개념을 통해 이해하게 됐다.
한 줄로 정리하면 ANN은 모든 데이터를 비교하지 않고도 빠르게 ‘가장 비슷한 것’을 찾기 위해, 일부 정확도를 포기하고 속도를 극대화한 검색 방식이다.