Skip to content

대규모 데이터 시스템에서 검색과 인덱싱이 핵심이 되는 이유

핵심 요약

대규모 데이터 시스템의 핵심 문제는 단순히 데이터를 많이 저장하는 것이 아니라, 필요한 데이터를 제한된 시간 안에 정확하거나 충분히 유용한 방식으로 찾아내는 것이다. 데이터가 작을 때는 전체를 순차적으로 훑는 방식도 가능하지만, 데이터가 수억 건, 수십억 건, 또는 그 이상으로 커지면 전체 탐색은 비용상 실용적이지 않다. 이때 인덱스는 데이터를 직접 모두 읽지 않고도 후보 범위를 빠르게 줄이는 접근 구조로 작동한다.

빅데이터 시스템에서 인덱싱은 매우 중요하지만, 전체 문제를 인덱스 하나로만 설명하면 구조가 단순화된다. 실제 시스템은 인덱스, 파티셔닝, 정렬, 압축, 캐싱, 쿼리 최적화, 분산 실행, 메타데이터 관리, 접근 권한 관리가 결합된 복합 구조다. Elasticsearch 같은 검색엔진은 역색인(inverted index)을 중심으로 빠른 전문 검색을 수행하고, PostgreSQL 같은 관계형 데이터베이스는 B-tree, Hash, GIN, GiST, BRIN 같은 다양한 인덱스를 사용한다. Hadoop과 Spark는 인덱스 기술이라기보다 대용량 데이터를 저장·분산처리·분석하는 실행 기반에 가깝다.

AI 메모리 시스템도 같은 문제를 반복한다. 모델이 기억해야 할 정보가 많아질수록 모든 기록을 프롬프트에 넣는 방식은 불가능해지고, 필요한 기억을 검색해서 불러오는 구조가 필요해진다. 이때 임베딩(embedding), 벡터 인덱스(vector index), 최근접 이웃 검색(nearest neighbor search), 메타데이터 필터링, 재순위화(reranking)가 결합된다. 따라서 AI 메모리는 단순한 “기억 저장소”가 아니라 데이터베이스, 정보검색, 벡터 검색, 추론 시스템이 결합된 검색 중심 아키텍처로 이해하는 편이 정확하다.

문제의식

데이터 시스템을 처음 생각할 때 사람들은 흔히 “어디에 저장할 것인가”를 먼저 떠올린다. 파일에 저장할 것인지, 데이터베이스에 저장할 것인지, 클라우드 스토리지에 저장할 것인지가 중요한 문제처럼 보인다. 이 질문은 필요하지만 충분하지 않다. 실제 운영 환경에서 더 어려운 질문은 “필요한 순간에 어떤 데이터를 어떻게 찾을 것인가”이다.

예를 들어 데이터가 100개라면 하나씩 확인해도 된다. 데이터가 1억 개라면 매번 처음부터 끝까지 확인하는 방식은 대부분의 실시간 서비스에서 사용할 수 없다. 검색 요청이 한 번뿐이라면 느린 처리를 감수할 수 있지만, 검색 요청이 초당 수천 번, 수만 번 발생한다면 전체 탐색은 시스템 전체를 마비시킨다. 그래서 대규모 시스템은 저장된 데이터를 그대로 쌓아두는 데서 멈추지 않고, 접근 경로를 별도로 설계한다.

이 접근 경로가 넓은 의미의 인덱스다. 인덱스는 원본 데이터의 축약된 지도이자, 검색 공간을 줄이기 위한 계산 구조다. 책 뒤의 색인이 본문 전체를 다시 읽지 않고도 특정 주제를 찾게 해주듯, 데이터베이스 인덱스는 테이블 전체를 스캔하지 않고도 조건에 맞는 행의 위치를 빠르게 좁힌다. 검색엔진의 역색인은 단어에서 문서로 이동하게 만들고, 벡터 인덱스는 의미적으로 가까운 항목을 빠르게 찾도록 만든다.

개념의 정의

인덱스(index)는 원본 데이터를 빠르게 찾기 위해 별도로 만든 보조 데이터 구조다. 원본 데이터 자체가 목적지라면, 인덱스는 목적지까지 가는 길을 담은 지도에 가깝다. 인덱스가 없으면 시스템은 조건을 만족하는 데이터를 찾기 위해 전체 데이터를 순차적으로 확인해야 한다. 이것을 전체 스캔(full scan) 또는 순차 탐색이라고 부른다.

가장 단순한 비교는 다음과 같다.

전체 탐색: 데이터 n개를 하나씩 확인
평균적 비용: O(n)

정렬된 구조에서의 탐색: 중간값을 기준으로 범위를 반복적으로 절반씩 줄임
평균적 비용: O(log n)

해시 기반 탐색: 키를 해시 함수로 변환해 위치를 직접 찾음
평균적 비용: O(1)에 가까움

이 표현은 개념을 이해하기 위한 이상화다. 실제 시스템에서는 디스크 I/O, 메모리 접근, 네트워크 지연, 캐시 적중률, 동시성 제어, 인덱스 유지 비용, 데이터 분포, 쿼리 패턴이 성능을 결정한다. 해시 인덱스도 최악의 경우 항상 O(1)을 보장한다고 단순화하기 어렵고, B-tree도 디스크 페이지 단위의 접근 최적화가 함께 작동한다. 벡터 검색에서는 특히 “정확히 가장 가까운 것”을 찾는 문제와 “충분히 가까운 후보를 빠르게 찾는 것”이 구분된다.

따라서 인덱스의 목적은 모든 상황에서 수학적으로 완벽한 시간복잡도를 보장하는 것이 아니다. 핵심은 검색 공간을 줄이고, 시스템이 실제로 감당 가능한 비용 안에서 원하는 결과를 찾도록 만드는 것이다.

배경과 맥락

대규모 데이터 처리에서 인덱싱이 중요한 이유는 데이터 증가가 선형적으로 보이지만, 검색 비용은 시스템 요구사항과 결합되면 폭발적으로 커지기 때문이다. 데이터가 10배 늘어나는 동안 사용자 요청도 늘고, 쿼리 조건도 복잡해지며, 서비스가 허용하는 지연 시간은 오히려 짧아진다. 단순한 저장 용량의 문제가 아니라 접근 시간, 처리량, 정확도, 비용의 문제가 된다.

관계형 데이터베이스는 오래전부터 이 문제를 인덱스와 쿼리 최적화로 다루어 왔다. PostgreSQL은 B-tree, Hash, GiST, SP-GiST, GIN, BRIN 같은 여러 인덱스 유형을 제공한다. 각 인덱스는 서로 다른 데이터 형태와 쿼리 조건에 맞게 설계된다. B-tree는 범위 검색과 정렬된 키 검색에 널리 쓰이고, Hash는 동등 비교에 적합하며, GIN은 배열·문서·전문 검색 계열에서 유용하게 사용된다. BRIN은 물리적 저장 순서와 값의 상관성이 큰 대형 테이블에서 작은 인덱스로 넓은 범위를 거칠게 줄이는 데 유리하다.

검색엔진의 맥락에서는 역색인이 중심이 된다. 일반적인 문서 검색에서 사용자가 “AI memory”라는 질의를 입력했을 때 모든 문서를 처음부터 끝까지 읽는 것은 비효율적이다. 검색엔진은 문서를 토큰으로 분석한 뒤, 각 토큰이 어떤 문서에 등장하는지 미리 매핑해 둔다. 이렇게 하면 검색 방향이 “문서에서 단어를 찾기”가 아니라 “단어에서 문서 목록을 찾기”로 바뀐다. 이 전환이 전문 검색(full-text search)의 핵심이다.

빅데이터 시스템에서는 문제의 층위가 더 넓어진다. Hadoop은 HDFS를 통해 대용량 데이터를 분산 저장하고, YARN과 MapReduce를 통해 클러스터 자원과 병렬 처리를 관리한다. Spark는 대규모 데이터 처리, SQL 분석, 스트리밍, 머신러닝 작업을 하나의 실행 엔진 위에서 처리한다. 이들은 좁은 의미의 인덱스 기술만을 가리키지 않는다. Hadoop과 Spark는 데이터를 여러 노드에 나누어 저장하고, 연산을 분산시키고, 실행 계획을 최적화하는 큰 틀의 처리 기반이다. 그러므로 “빅데이터의 핵심 기술은 인덱스다”라는 말은 검색 관점에서는 맞지만, 전체 시스템 관점에서는 “인덱스와 분산 실행 구조가 결합되어야 한다”로 보완되어야 한다.

핵심 논리

대규모 데이터 시스템의 핵심 논리는 다음과 같이 정리할 수 있다.

원본 데이터는 크다.
전체 탐색은 비싸다.
질의는 반복된다.
따라서 자주 쓰이는 접근 경로를 미리 만든다.
그 접근 경로가 인덱스다.

이 구조를 조금 더 일반화하면 데이터 시스템은 원본 데이터와 접근 구조의 이중 구조를 가진다.

Raw Data
  ↓
Storage Layer
  ↓
Index / Metadata / Partitioning Layer
  ↓
Query Planner 또는 Retrieval Engine
  ↓
Candidate Results
  ↓
Ranking / Filtering / Aggregation
  ↓
Final Result

원본 데이터는 모든 정보를 담고 있지만, 검색에 바로 적합한 형태는 아닐 수 있다. 인덱스는 원본 데이터의 특정 측면만을 추출해 검색 가능한 형태로 만든다. 예를 들어 관계형 데이터베이스의 B-tree 인덱스는 특정 컬럼의 값을 정렬된 구조로 관리한다. 역색인은 문서 안의 단어를 문서 ID 목록과 연결한다. 벡터 인덱스는 텍스트, 이미지, 음성 같은 비정형 데이터를 고차원 수치 벡터로 바꾼 뒤, 가까운 벡터를 빠르게 찾도록 구조화한다.

인덱스는 성능을 공짜로 제공하지 않는다. 읽기 성능은 좋아질 수 있지만, 쓰기 성능과 저장 비용에는 부담이 생긴다. 데이터가 삽입·수정·삭제될 때 인덱스도 함께 갱신되어야 한다. 인덱스가 너무 많으면 쓰기 비용이 증가하고, 인덱스가 부적절하면 쿼리 최적화기는 인덱스를 사용하지 않거나 오히려 느린 계획을 선택할 수 있다. 그래서 실제 설계에서는 “무엇을 인덱싱할 것인가”만큼 “무엇을 인덱싱하지 않을 것인가”도 중요하다.

이 원리는 AI 메모리 시스템에서도 그대로 반복된다. AI 에이전트가 과거 대화, 문서, 작업 로그, 코드, 사용자 선호, 외부 지식을 모두 기억해야 한다고 가정해 보자. 모든 정보를 매번 LLM의 컨텍스트 창에 넣는 방식은 토큰 비용, 지연 시간, 잡음 증가, 관련성 저하 때문에 실용적이지 않다. 따라서 시스템은 대부분의 정보를 외부 저장소에 보관하고, 현재 질문과 관련된 일부 정보만 검색해서 모델에 제공한다.

이때 AI 메모리의 핵심은 “많이 저장하는 능력”보다 “관련 기억을 정확히 불러오는 능력”이다. 저장소가 아무리 커도 검색이 부정확하면 모델은 엉뚱한 기억을 근거로 답하거나, 중요한 기억을 놓친다. 반대로 저장소가 비교적 작아도 검색·필터링·재순위화가 잘 설계되어 있으면 모델은 현재 맥락에 맞는 정보를 더 안정적으로 사용할 수 있다.

구체적 사례

1. 전화번호부와 B-tree 인덱스

전화번호부가 이름순으로 정렬되어 있으면 특정 이름을 찾기 위해 모든 페이지를 읽을 필요가 없다. 중간 지점을 기준으로 앞쪽인지 뒤쪽인지 판단하고, 범위를 계속 줄이면 된다. 이것이 이진 탐색의 직관이다. 데이터베이스의 B-tree 계열 인덱스도 이와 비슷한 문제의식에서 출발한다. 정렬된 키 구조를 유지해 특정 값, 범위, 정렬 조건을 빠르게 처리하도록 돕는다.

예를 들어 다음과 같은 고객 테이블이 있다고 하자.

SELECT *
FROM customers
WHERE email = 'user@example.com';

email 컬럼에 인덱스가 없다면 데이터베이스는 테이블 전체를 훑어야 할 수 있다. 반대로 email 컬럼에 적절한 인덱스가 있으면 데이터베이스는 인덱스에서 해당 이메일의 위치를 먼저 찾고, 필요한 행으로 이동한다. 이때 성능 향상은 데이터가 커질수록 더 중요해진다.

2. Elasticsearch와 역색인

문서 검색에서는 B-tree보다 역색인이 더 자연스럽다. 사용자가 “index architecture”를 검색한다고 하자. 검색엔진은 모든 문서를 열어 이 표현이 들어 있는지 확인하지 않는다. 사전에 문서를 분석해 다음과 같은 구조를 만들어 둔다.

index        → 문서 1, 문서 3, 문서 8, ...
architecture → 문서 2, 문서 3, 문서 9, ...
memory       → 문서 4, 문서 8, 문서 10, ...

사용자 질의가 들어오면 검색엔진은 질의의 토큰을 분석하고, 해당 토큰이 등장하는 문서 목록을 빠르게 가져온다. 이후 단어 빈도, 문서 길이, 필드 중요도, 최신성, 사용자 조건 같은 요소를 반영해 결과를 순위화한다. 이 구조는 검색 문제를 “모든 문서를 검사하는 문제”에서 “토큰별 후보 목록을 결합하고 순위화하는 문제”로 바꾼다.

3. Hadoop과 Spark의 위치

Hadoop과 Spark는 인덱스만으로 설명하기 어렵다. Hadoop의 HDFS는 데이터를 여러 노드에 분산 저장하고, MapReduce는 큰 작업을 작은 작업으로 나누어 병렬 처리한다. YARN은 클러스터 자원과 작업 실행을 관리한다. Spark는 배치 처리, 스트리밍, SQL, 머신러닝 작업을 위한 통합 실행 엔진으로 사용된다.

따라서 다음과 같이 구분하는 편이 정확하다.

인덱스: 데이터를 빨리 찾기 위한 접근 구조
Hadoop: 대규모 데이터를 분산 저장·처리하기 위한 생태계
Spark: 대규모 데이터 분석과 연산을 위한 분산 실행 엔진
Elasticsearch: 역색인을 중심으로 한 검색엔진
관계형 DB: 트랜잭션, 쿼리, 인덱스, 제약조건, 최적화를 결합한 데이터 관리 시스템

대규모 분석 작업에서는 인덱스가 없더라도 전체 데이터를 병렬로 처리할 수 있다. 반대로 실시간 검색 서비스에서는 분산 처리만으로는 충분하지 않고, 질의에 맞는 인덱스와 랭킹 구조가 필요하다. 두 계열은 경쟁 관계라기보다 서로 다른 병목을 해결하는 기술이다.

4. AI 메모리와 벡터 인덱스

AI 메모리 시스템에서는 텍스트를 그대로 검색하는 것만으로 부족할 때가 많다. 사용자가 “지난번에 말한 데이터 접근 문제”라고 물었을 때, 과거 기록에 “인덱싱이 핵심이다”라는 표현은 있어도 “데이터 접근 문제”라는 정확한 단어가 없을 수 있다. 키워드 기반 검색은 표현이 다르면 놓칠 수 있다.

그래서 AI 시스템은 텍스트를 임베딩 벡터로 변환한다. 임베딩은 문장이나 문서의 의미적 특성을 수치 공간의 좌표로 표현한 것이다. 의미가 가까운 문장들은 벡터 공간에서도 가깝게 배치되도록 학습된다. 이 구조를 사용하면 “검색”, “접근”, “retrieval”, “indexing”처럼 표현은 달라도 의미적으로 연결된 항목을 후보로 찾을 수 있다.

기본 흐름은 다음과 같다.

문서 또는 기억 조각
  ↓
Embedding Model
  ↓
Vector Representation
  ↓
Vector Index
  ↓
Nearest Neighbor Search
  ↓
Top-k Candidate Memories
  ↓
Metadata Filtering / Reranking
  ↓
LLM Context

FAISS는 밀집 벡터의 유사도 검색과 클러스터링을 위한 대표적 라이브러리다. ScaNN은 Google Research가 발표한 대규모 벡터 유사도 검색 기술로, 검색 공간 가지치기와 양자화 같은 방식을 사용한다. HNSW는 그래프 기반 근사 최근접 이웃 검색 방식으로, 다층 그래프를 통해 가까운 후보를 탐색한다. 이들 기술은 모두 전체 벡터를 매번 비교하는 무차별 대입 검색을 피하고, 높은 재현율과 낮은 지연 시간 사이의 균형을 맞추려는 시도다.

주요 쟁점과 반론

“대규모 데이터 시스템의 핵심은 인덱스다”라는 말은 검색 중심의 설명으로는 매우 강력하다. 하지만 이 명제는 세 가지 방식으로 보완되어야 한다.

첫째, 모든 대규모 데이터 문제가 검색 문제는 아니다. 로그 전체를 집계하거나, 모델 학습을 위해 거대한 데이터셋을 순차적으로 읽거나, 배치 분석을 수행하는 경우에는 전체 스캔이 합리적일 수 있다. 이때 중요한 것은 인덱스보다 분산 처리, 데이터 지역성, 파일 포맷, 압축, 병렬 실행, 장애 복구일 수 있다.

둘째, 인덱스는 쿼리 패턴에 의존한다. 어떤 컬럼에 인덱스를 만들지, 어떤 토큰화 방식을 쓸지, 어떤 거리 함수를 사용할지, 어떤 메타데이터를 필터링할지는 사용자가 실제로 어떤 질문을 하는지에 따라 달라진다. 잘못 만든 인덱스는 저장 공간만 차지하고 쿼리 성능에는 별 도움이 되지 않는다.

셋째, AI 메모리에서 “의미 검색”은 정확 검색보다 더 애매하다. 일반 데이터베이스에서 id = 1234라는 조건은 참과 거짓이 분명하다. 반면 벡터 검색에서 “이 문서가 현재 질문과 의미적으로 관련 있는가”는 정도의 문제다. 임베딩 모델의 품질, 청크 분할 방식, 거리 함수, 벡터 차원, 후보 개수, 메타데이터 필터, 재순위화 모델이 모두 결과에 영향을 준다.

따라서 AI 메모리 시스템은 단순히 벡터 DB를 붙인다고 완성되지 않는다. 실제로는 다음 조건을 함께 설계해야 한다.

무엇을 기억할 것인가
어떤 단위로 쪼갤 것인가
어떤 메타데이터를 붙일 것인가
어떤 임베딩 모델을 쓸 것인가
어떤 인덱스 구조를 쓸 것인가
얼마나 많은 후보를 가져올 것인가
검색 결과를 어떻게 재순위화할 것인가
오래된 기억과 최신 기억의 충돌을 어떻게 처리할 것인가
틀린 기억을 어떻게 삭제하거나 수정할 것인가

이 지점에서 AI 메모리 문제는 전통적 데이터베이스 문제와 닮았지만 완전히 같지는 않다. 전통적 데이터베이스는 정합성, 트랜잭션, 정확 질의가 중요하고, AI 메모리는 관련성, 맥락성, 의미 유사성, 추론 적합성이 중요하다. 두 영역은 점점 결합되고 있지만, 평가 기준은 다르다.

오해와 한계

가장 흔한 오해는 “인덱스가 있으면 검색은 거의 공짜가 된다”는 생각이다. 인덱스는 검색 비용을 크게 줄일 수 있지만, 저장 비용과 갱신 비용을 발생시킨다. 데이터가 자주 바뀌는 시스템에서는 인덱스 유지가 큰 부담이 될 수 있다. 또한 인덱스가 많아질수록 쿼리 최적화가 복잡해지고, 잘못된 통계 정보는 비효율적인 실행 계획으로 이어질 수 있다.

두 번째 오해는 “O(log n) 또는 O(1)이면 모든 문제가 해결된다”는 생각이다. 시간복잡도 표기는 알고리즘의 성장률을 이해하는 데 유용하지만, 실제 대규모 시스템에서는 상수항, 메모리 계층, 디스크 접근, 네트워크 왕복, 직렬화 비용, 분산 환경의 꼬리 지연이 성능을 크게 좌우한다. 특히 벡터 검색에서는 고차원 공간의 특성 때문에 전통적 저차원 인덱스의 직관이 그대로 적용되지 않는다.

세 번째 오해는 “AI 메모리는 벡터 검색이면 충분하다”는 생각이다. 벡터 검색은 의미적으로 비슷한 후보를 찾는 데 강하지만, 숫자 조건, 날짜 조건, 권한 조건, 정확한 ID 조건, 최신성 조건은 별도의 메타데이터 필터나 구조화 검색이 필요하다. 예를 들어 “2026년 3월 이후에 작성된 문서 중 계약 관련 내용”을 찾는다면 의미 검색만으로는 부족하고, 날짜·문서 유형·권한·작성자 같은 구조화 정보가 함께 필요하다.

네 번째 오해는 “많이 저장할수록 좋은 메모리 시스템이 된다”는 생각이다. AI 시스템에서 기억이 너무 많으면 검색 후보가 늘어나고, 오래되거나 부정확한 정보가 섞이며, 모델이 현재 질문과 무관한 정보를 근거로 삼을 위험이 커진다. 좋은 메모리 시스템은 저장량이 큰 시스템이 아니라, 보존·삭제·요약·검색·검증의 기준이 명확한 시스템이다.

설명의 한계도 있다. 이 글은 인덱싱과 AI 메모리의 구조적 유사성을 설명하는 데 초점을 둔다. 실제 시스템 구현에서는 데이터 규모, 지연 시간 목표, 일관성 요구사항, 업데이트 빈도, 비용 제약, 보안 정책, 모델 종류에 따라 설계가 크게 달라진다. 또한 ANN 알고리즘의 성능은 데이터 분포와 하드웨어에 민감하므로, 특정 알고리즘이 모든 상황에서 최선이라고 일반화하기 어렵다.

정리

대규모 데이터 시스템에서 저장은 출발점이고, 검색은 운영의 핵심이다. 데이터가 커질수록 문제는 “얼마나 많이 보관할 수 있는가”에서 “필요한 데이터를 얼마나 빠르고 정확하게 찾을 수 있는가”로 이동한다. 인덱스는 이 문제에 대한 가장 오래되고 강력한 해법 중 하나다.

다만 현실의 빅데이터 시스템은 인덱스만으로 구성되지 않는다. 관계형 데이터베이스는 인덱스와 쿼리 최적화를 결합하고, 검색엔진은 역색인과 랭킹을 결합하며, Hadoop과 Spark는 분산 저장과 병렬 실행을 통해 대규모 처리를 가능하게 한다. AI 메모리 시스템은 여기에 임베딩과 벡터 검색을 더해 의미 기반 검색을 수행한다.

따라서 원문의 핵심 문장은 다음과 같이 보완할 수 있다.

대규모 데이터 시스템의 핵심은 단순 저장이 아니라 접근 구조의 설계다.
그 중심에 인덱싱이 있으며, 실제 시스템에서는 인덱스가 파티셔닝, 분산 처리, 쿼리 최적화, 캐싱, 랭킹, 메타데이터 필터링과 결합된다.
AI 메모리 시스템도 같은 문제를 갖는다.
모든 기억을 모델에 넣는 것이 아니라, 필요한 기억을 검색해 현재 추론에 투입하는 구조가 핵심이다.

이 관점에서 AI 메모리는 신비한 장기 기억이 아니라 검색 가능한 외부 데이터 시스템에 가깝다. 좋은 AI 메모리의 품질은 저장 용량보다 검색 정확도, 맥락 적합성, 갱신 가능성, 오류 정정 능력에 의해 결정된다.

참고자료

  • PostgreSQL Global Development Group, “PostgreSQL Documentation: Index Types,” PostgreSQL Documentation, 확인일 2026-05-06.
  • Elastic, “How full-text search works,” Elastic Docs, 확인일 2026-05-06.
  • Elastic, “What is an Elasticsearch index?,” Elastic Blog, 2023, 확인일 2026-05-06.
  • Apache Software Foundation, “Apache Hadoop,” Apache Hadoop 공식 사이트, 확인일 2026-05-06.
  • Apache Software Foundation, “Apache Hadoop YARN,” Apache Hadoop Documentation, 확인일 2026-05-06.
  • Apache Software Foundation, “Apache Spark: Unified Engine for large-scale data analytics,” Apache Spark 공식 사이트, 확인일 2026-05-06.
  • Apache Software Foundation, “Overview - Spark Documentation,” Apache Spark Documentation, 확인일 2026-05-06.
  • Meta AI Research, “Faiss Documentation,” Faiss 공식 문서, 확인일 2026-05-06.
  • Meta AI Research, “facebookresearch/faiss,” GitHub Repository, 확인일 2026-05-06.
  • Google Research, “Announcing ScaNN: Efficient Vector Similarity Search,” Google Research Blog, 2020.
  • Google Research, “google-research/scann,” GitHub Repository, 확인일 2026-05-06.
  • Google Cloud, “Vector Search overview,” Vertex AI Documentation, 확인일 2026-05-06.
  • Malkov, Yu. A. and Yashunin, D. A., “Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs,” arXiv:1603.09320, 2016.
  • Zaharia, Matei et al., “Apache Spark: A Unified Engine for Big Data Processing,” Communications of the ACM, Vol. 59, No. 11, 2016.