[특집] 벡터 데이터베이스는 죽었다? — 터보퍼퍼가 벡터를 '색인 하나'로 내린 이유와 2026년 검색 인프라의 지각변동

크게 보기

들어가며: 벡터 데이터베이스 회사가 쓴 부고

2026년 9월 30일, 검색 인프라 회사 터보퍼퍼(turbopuffer) 의 엔지니어 댄 해리슨이 회사 블로그에 글을 올렸습니다. 제목은 「RIP, vector database」. 벡터 데이터베이스여, 고이 잠드소서.

이 제목이 눈길을 끈 건 쓴 사람 때문입니다. 터보퍼퍼는 2023년 10월 스스로를 '최초의 진짜 서버리스 벡터 데이터베이스'라고 소개하며 출발한 회사입니다. 지금은 코드 에디터 커서(Cursor), 노션, 앤트로픽, 리니어, 아틀라시안 같은 회사들의 검색을 떠받치고, 창업자에 따르면 2026년 3월 연환산 매출 1억 달러를 넘겼습니다. 벡터 데이터베이스 붐의 가장 큰 수혜자 가운데 하나가 '벡터 데이터베이스의 죽음'을 선언한 셈입니다.

글은 해커뉴스에서 374점, 댓글 100여 개를 받았습니다. 가장 많이 공감을 받은 반응 중 하나는 이랬습니다. "'RIP, 벡터 우선 인덱스'라고 했으면 정확했을 것이다. 'RIP, 벡터 데이터베이스'는 마케팅이다."

맞는 말입니다. 원문이 실제로 다루는 건 터보퍼퍼 내부의 저장 구조 변경, 즉 무엇을 기본 인덱스(primary index)로 삼느냐입니다. 그런데 이 기술적인 결정이 왜 이렇게 큰 반응을 얻었을까요. 2026년 검색 인프라 시장 전체가 같은 방향으로 움직이고 있기 때문입니다. 벡터는 사라지지 않았습니다. 오히려 어디에나 있습니다. 다만 '벡터만을 위한 데이터베이스'라는 범주가 녹아내리고, 벡터가 여러 색인 중 하나가 되어 가고 있습니다.

이 글은 먼저 벡터 데이터베이스가 어떻게 하나의 산업이 됐는지 짚고(1부), 터보퍼퍼가 어떤 회사인지(2부), 원문이 말한 '기본 인덱스'의 문제가 정확히 무엇인지(3~5부)를 원문의 키-값 예시 그대로 풀어 봅니다. 그다음 이 결정을 2025~2026년 시장의 큰 흐름 위에 올려놓고(6부), 반론(7부)과 실무 선택지(8부)로 마무리합니다.

1부. 벡터 데이터베이스는 어떻게 하나의 산업이 되었나

벡터 검색, 세 줄 요약

문장이나 이미지를 임베딩 모델에 넣으면 수백~수천 개의 숫자로 된 벡터가 나옵니다. 뜻이 비슷한 것끼리는 벡터도 가깝습니다. 그래서 질문을 벡터로 바꾼 뒤 가장 가까운 문서 벡터를 찾으면, 단어가 하나도 겹치지 않아도 뜻이 통하는 문서를 찾을 수 있습니다. 문제는 문서가 수억 개일 때 질문 하나마다 전부와 거리를 재면 너무 느리다는 것. 그래서 '대충 가장 가까운 것'을 빠르게 찾는 근사 최근접 이웃(ANN) 색인이 필요합니다.

이 색인을 저장하고, 갱신하고, 빠르게 질의하게 해 주는 시스템이 벡터 데이터베이스입니다. 기초가 처음이라면 이 블로그의 「벡터 데이터베이스란?」과 「4096차원에 HNSW가 필요한 이유」를 먼저 보셔도 좋습니다.

알고리즘의 10년

ANN 색인에는 크게 두 갈래가 있습니다. 이 구분이 뒤에서 아주 중요해집니다.

SPFresh는 SPANN에 제자리 갱신을 붙인 논문입니다. 문서가 계속 들어오고 지워지면 클러스터 크기가 들쭉날쭉해지고 검색 품질이 떨어집니다. SPFresh의 LIRE라는 규칙은 너무 커진 클러스터를 쪼개고, 경계에 있는 벡터만 이웃 클러스터로 다시 배정해 균형을 맞춥니다. 하루 1%씩 갱신되는 10억 개 규모 색인에서, 기존 최고 수준 대비 최대 부하 때 메모리 1%, CPU 코어 10% 미만만 쓰면 됐다고 합니다. 이 '다시 배정'이 이 글의 핵심 악역이 됩니다.

2023년, 골드러시

2022년 11월 챗GPT가 나오고, 회사들이 자기 문서를 LLM에 물려 답하게 하는 RAG(검색 증강 생성) 를 앞다퉈 만들기 시작했습니다. RAG의 'R'을 맡은 벡터 데이터베이스에 돈이 몰렸습니다.

2023년 6월 앤드리슨 호로위츠(a16z)의 「LLM 애플리케이션의 새 아키텍처」는 벡터 데이터베이스를 '시스템 관점에서 전처리 파이프라인의 가장 중요한 부품'이라 부르고, 파인콘을 기본 선택지로 그렸습니다. 이 그림이 그해 수많은 AI 스타트업의 아키텍처 슬라이드에 그대로 복사됐습니다.

크게 보기

그림 뒤편 언덕을 보세요. 골드러시가 한창일 때, 이미 수십 년 된 데이터베이스들도 조용히 자기 채굴 기계를 설치하고 있었습니다. 6부에서 이 장면으로 돌아옵니다.

2부. 터보퍼퍼 — 오브젝트 스토리지 위에 세운 검색 엔진

리드와이즈의 청구서에서 시작된 회사

터보퍼퍼의 창업자 사이먼 회루프 에스킬드센(Simon Hørup Eskildsen) 은 저스틴 리와 함께 쇼피파이에서 8년 동안 인프라를 맡아, 초당 요청 1천 건을 100만 건으로 키운 엔지니어입니다. 창업 계기는 2022년 말 읽기 앱 리드와이즈의 자문 일이었습니다. 1억 개가 넘는 문서에 관계형 DB 비용은 월 5천 달러 정도였는데, 같은 문서에 벡터 검색을 붙이려니 월 2만 달러가 넘게 나왔다는 것. 검색 기능 하나가 본체 DB보다 네 배 비쌌습니다.

이유는 저장 위치였습니다. 당시 벡터 DB는 대부분 모든 것을 메모리에 올려 두거나, SSD에 세 벌씩 복제해 두었습니다. 에스킬드센의 계산은 이렇습니다.

그래서 터보퍼퍼는 원본을 오브젝트 스토리지(S3 같은 클라우드 파일 창고) 에 두고, 자주 쓰는 데이터만 NVMe SSD와 메모리 캐시로 올리는 구조를 택했습니다. 차가운 데이터는 메모리 대비 최대 100배, 따뜻한 데이터는 6~20배 싸다는 주장입니다. 대신 처음 읽을 때는 느립니다. 터보퍼퍼 자료에 따르면 768차원 벡터 100만 개 검색이 캐시에 없을 때(콜드) p90 444ms, 캐시에 있을 때(웜) 10ms였습니다.

이 구조가 가능해진 계기도 흥미롭습니다. 에스킬드센은 2020년 12월 S3가 강한 일관성(쓰고 나서 바로 읽으면 방금 쓴 값이 보장됨)을, 2024년 말 조건부 쓰기(compare-and-swap)를 지원하면서, 별도 합의 계층 없이 S3만으로 데이터베이스를 만들 수 있게 됐다고 말합니다.

크게 보기

왜 그래프가 아니라 클러스터였나

1부의 두 갈래를 떠올려 보세요. 원문은 v1을 이렇게 설명합니다. "당시의 통념은 그래프 기반 벡터 색인이었지만, 계층형 클러스터링 색인이 오브젝트 스토리지와 더 잘 맞는다. 우리는 SPANN으로 시작해, 증분 색인을 지원하려 SPFresh로 옮겼다."

왜 더 잘 맞을까요. 그래프 탐색은 앞 걸음의 결과를 읽어야 다음 걸음을 정할 수 있습니다. 메모리에서는 한 걸음이 나노초 단위라 수백 걸음도 순식간이지만, 한 번 왕복에 수십~수백 ms가 걸리는 S3에서는 걸음마다 기다림이 쌓입니다. 클러스터 트리는 중심점(작아서 캐시에 둠)만 보고 열어 볼 클러스터 몇 개를 정한 뒤 한 번에 병렬로 가져올 수 있습니다. 아래 계산기에서 저장 계층을 바꿔 보세요.

3년간의 성적표

벡터 검색으로 이렇게 성공한 회사가, 왜 벡터를 왕좌에서 내리려 할까요.

3부. 원문 해부 — '기본 인덱스'란 무엇인가

도서관으로 생각해 보기

데이터베이스에서 기본 인덱스(또는 클러스터드 인덱스) 란 데이터가 실제로 디스크에 놓이는 순서를 정하는 열쇠입니다. 도서관으로 치면 책을 서가에 꽂는 규칙입니다.

두 도서관을 상상해 보세요. 첫 번째 도서관은 책을 비슷한 분위기끼리 모아 꽂습니다. 우울한 소설은 우울한 소설끼리, 바다 이야기는 바다 이야기끼리. '이 책과 비슷한 책'을 찾기엔 최고입니다. 그런데 저자 색인 카드, 주제어 색인 카드가 전부 '3번 무더기의 17번째 책'처럼 서가 위치를 적고 있다면? 새 책이 들어와 무더기를 다시 나눌 때마다 그 무더기의 책들이 옮겨지고, 그 책들을 가리키던 모든 카드를 다시 써야 합니다.

두 번째 도서관은 책을 번호순으로 꽂고, 비슷한 책 찾기용 지도, 주제어 카드, 저자 카드를 따로 둡니다. 모든 카드는 서가 위치가 아니라 책 번호를 적습니다. 비슷한 책 지도가 바뀌어도 책은 제자리에 있고, 다른 카드는 손댈 필요가 없습니다.

크게 보기

터보퍼퍼 v1·v2는 첫 번째 도서관이었고, v3는 두 번째 도서관이 되려는 것입니다.

원문의 키-값 예시 그대로

원문은 실제 저장 형식을 단순화한 키-값 예시를 보여 줍니다. 터보퍼퍼의 저장 계층은 정렬되고 중복 없는 키를 가진 키-값 맵처럼 생겼고, 클러스터마다 ClusterId, 클러스터 안 벡터마다 촘촘한 LocalId를 붙입니다. 이 둘을 합친 C0L1 같은 주소를 원문은 ANN 주소라고 부릅니다.

v2에서는 고객의 요구가 쌓였습니다. 속성으로 거르는 필터, BM25 전문 검색, 그리고 집계, 정규식 검색, 퍼지 매칭, 희소 벡터 검색, 속성 정렬. 모두 같은 '벡터 우선' 배치 위에 지었습니다. 아래 단계별 보기에서 노란색(ANN 주소)이 어디까지 번지는지 확인해 보세요. 예시 문서가 대서양퍼핀(Atlantic Puffin, 바다오리과)인 건 회사 이름의 '퍼퍼'를 닮은 새라서입니다.

원문은 이 구조가 오래 살아남은 이유를 솔직하게 씁니다. "ANN 기본 인덱스가 오늘까지 거의 그대로 남은 이유는 하나다. 오브젝트 스토리지 위 ANN 검색에 정말, 정말 잘 맞기 때문이다." 1,000억 개 단일 색인이 그 증거입니다. 그러니 이걸 건드리는 건 가장 잘하는 일을 망칠 위험을 지는 일입니다. 그래도 바꾸기로 한 이유가 다음 4부의 세 가지입니다.

4부. 세 가지 증폭 — 벡터가 주인일 때 치르는 값

① 저장 증폭: 토큰마다 문서를 한 벌씩

문서에 벡터가 하나뿐이면 문제없습니다. 벡터 옆에 문서 내용을 한 번 저장하면 됩니다. 그런데 요즘은 문서 하나를 벡터 여러 개로 표현하는 일이 늘고 있습니다.

• 중첩 문서: 긴 문서를 문단·조각마다 하나씩 임베딩한다.
• 지연 상호작용(late interaction): 2020년 스탠퍼드의 ColBERT(카타브·자하리아, SIGIR 2020)가 대표적입니다. 문서를 벡터 한 점으로 누르지 않고 토큰마다 벡터를 하나씩 남겨 두었다가, 질문의 토큰들과 하나하나 맞춰 봅니다. 정확도가 높지만 벡터 수가 수십~수백 배가 됩니다. 이 블로그의 「문서를 한 점으로 누르지 않는다 — KURE-v2와 한국어 late interaction」에서 자세히 다뤘습니다.

벡터 우선 배치에서는 벡터마다 그 ANN 주소 아래에 문서 내용을 붙여 두어야 하니, 벡터가 128개면 문서도 128벌이 됩니다. 원문은 이것이 '네임스페이스당 벡터 열 수 제한' 같은 "달갑지 않은 제약"의 이유라고 밝혔습니다.

크게 보기

② 쓰기 증폭: 벡터 하나가 이사하면 집이 통째로

문서를 넣고 고치고 지우면 SPFresh는 클러스터가 고르게 유지되도록 벡터를 다시 배정합니다. 그러지 않으면 검색 재현율이 떨어지니까요. 그런데 문서의 모든 것이 그 벡터의 ANN 주소 아래 저장돼 있으니, 벡터가 옮겨 가면 문서 전체 내용과, 그 문서를 가리키는 모든 역색인(속성·전문 검색) 이 따라 움직여야 합니다.

벡터 하나를 고치면 수백 개의 속성과 그 색인이 움직일 수 있다. 이 쓰기 증폭이 너무 커서, 색인 처리량을 튜닝하려는 우리의 노력은 수확 체감에 부딪히기 시작했다.

이 문제의 씨앗은 2025년 1월 터보퍼퍼의 필터링 글에 이미 적혀 있었습니다. "기본 벡터 인덱스는 {cluster_id}:{local_id} 형태의 주소를 부여한다. (…) 주소가 바뀌면 속성 인덱스도 갱신해야 한다."

크게 보기

두 증폭을 숫자로 느껴 보세요. 원문이 설명한 배치를 그대로 셈한 단순화 모델입니다.

③ 제한된 벡터화: 상자가 작으면 CPU가 논다

세 번째 이유는 조금 더 깊습니다. 원문: "현대 쿼리 엔진은 벡터화돼 있다. 값 블록 위에서 촘촘한 루프를 돌며 블록마다 드는 고정 비용을 나눠 내고, 압축이 잘 되고, CPU 파이프라인을 꽉 채우고, SIMD를 쓸 수 있다."

여기서 '벡터화'는 임베딩 벡터와 상관없는, 데이터베이스 실행 방식의 용어입니다. 값을 한 줄씩 처리하지 않고 수천 개씩 묶음으로 처리하는 것. 이 아이디어를 널리 알린 건 2005년 CIDR의 MonetDB/X100 논문(본츠·주코프스키·네스)이었고, 그 계보에서 오늘의 DuckDB가 나왔습니다. 원문이 든 숫자들은 이렇습니다.

모든 쿼리 계획에는 저마다 최적의 블록 크기가 있습니다. 그런데 ANN 주소가 기본 키인 한, 문서를 직접 읽는 집계나 스캔은 클러스터 하나가 블록 하나가 되어 100~200개에 갇힙니다. 수천 개를 한꺼번에 처리하고 싶은 계획도 마찬가지입니다.

이게 얼마나 큰 차이인지 터보퍼퍼는 이미 겪어 봤습니다. 첫 번째 전문 검색(FTS v1)은 포스팅 목록(단어가 든 문서 목록)을 ANN 클러스터 경계대로 나눴습니다. MS MARCO 문서 4천만 개에서 블록 하나에 든 포스팅이 중앙값 약 1.5개였습니다. FTS v2는 포스팅을 약 256개짜리 고정 블록으로 바꿨습니다. 포스팅 목록은 문서와 따로 저장돼 문서를 가리키기만 하니, 클러스터를 따를 이유가 없었던 겁니다.

색인은 약 10배 작아졌고, 질의는 최대 약 20배 빨라졌습니다(위키백과 500만 문서, "lord of the rings" 75ms → 6ms 등). 같은 일이 집계와 스캔에도 일어나려면, 문서 자체가 클러스터에서 풀려나야 합니다.

크게 보기

5부. RIP, 기본 벡터 인덱스 — 그리고 데이터베이스의 오래된 교훈

해법은 단순하다, 구현은 아니다

이 문제들의 해법은 단순하다. ANN 주소를 키로 쓰지 마라. 터보퍼퍼 v3가 하는 일이 정확히 그것이다. 짐작하겠지만, 사소한 변경은 아니다.

원문은 v3의 새 키 형식을 공개하지 않았습니다. 대신 해커뉴스 댓글에서 터보퍼퍼의 CTO 니킬 베네시가 답을 줬습니다. 새 기본 키는 "자동 생성되는 내부 ID: (세그먼트 ID, 문서 ID)" 이고, 사용자가 지정하는 기본 키는 저장 계층에서 보조 색인이 된다는 것. ANN 색인도, 사용자 ID도, 속성 색인도, 전문 검색 색인도 모두 이 안정적인 내부 ID를 가리킵니다. 벡터가 클러스터를 옮겨도 바뀌는 건 ANN 색인 속 한 줄뿐입니다.

크게 보기

마지막 줄이 중요합니다. 공짜는 없습니다. 색인이 문서의 물리적 위치 대신 논리적 ID를 가리키면, 읽을 때 한 번 더 찾아가야 합니다.

이 논쟁, 10년 전에도 있었다

해커뉴스에서 가장 날카로운 댓글은 이것이었습니다. "10년 뒤에 다시 보는 포스트그레스 대 InnoDB 논쟁이다."

2016년 7월, 우버는 「Why Uber Engineering Switched from Postgres to MySQL」이라는 유명한 글을 올렸습니다. 이유 중 하나가 바로 쓰기 증폭이었습니다. 포스트그레스의 보조 색인은 행의 물리적 위치를 가리킵니다. 그래서 행이 새 위치에 쓰이면(포스트그레스는 갱신할 때 새 버전을 새 자리에 씁니다), 그 행을 가리키는 모든 색인을 고쳐야 합니다. 반면 MySQL의 InnoDB는 데이터를 기본 키 순서로 저장하는 클러스터드 인덱스를 두고, 보조 색인은 물리적 위치 대신 기본 키 값을 담습니다. MySQL 공식 문서의 설명 그대로입니다. "보조 색인의 각 레코드는 그 행의 기본 키 열을 담고 있다. InnoDB는 이 기본 키 값으로 클러스터드 인덱스에서 행을 찾는다."

다른 댓글들도 같은 계보를 짚었습니다. "포스트그레스식 설계 패턴에서 MySQL식으로 옮겨 가는 것", "SQL 서버의 클러스터드 인덱스, 오라클의 인덱스 구성 테이블(IOT)과 같은 이야기". 벡터 데이터베이스라는 새 분야가 관계형 데이터베이스가 수십 년 전에 겪은 설계 결정을 다시 만나고 있는 겁니다.

지금 v3는 더 느리다 — 그리고 그걸 공개했다

원문에서 가장 인상적인 대목은 마지막입니다. "이달 초 큰 이정표를 넘었다. 터보퍼퍼 v3에서 CI가 100% 통과한다. 우리는 정확성부터 챙겼다. 이제 정확하면서 빠르게 만들 것이다. (…) 성능 다듬기의 0일 차부터 함께하시라."

실제로 터보퍼퍼는 v3 진행 페이지에 첫날 v3가 v2보다 얼마나 느린지를 공개했습니다(문서 1천만 개, 코히어 1024차원 임베딩, 초당 8건, 10분 측정, p90 기준).

벡터 검색은 첫날부터 그대로이거나 더 빠르고, 나머지는 아직 한참 느립니다. 터보퍼퍼는 v2와 성능이 같아질 때까지(그리고 그 너머까지) 다듬은 뒤에야 v3를 운영에 내보내겠다고 했습니다. 즉, 이 글을 쓰는 시점에 v3는 아직 약속입니다.

6부. 이건 터보퍼퍼만의 이야기가 아니다 — 2025~2026년의 네 흐름

터보퍼퍼의 결정은 한 회사의 내부 구조 변경이지만, 그 방향은 시장 전체의 방향과 겹칩니다. 2025~2026년 검색 인프라에는 네 개의 큰 흐름이 있었습니다.

흐름 ① 모든 데이터베이스가 벡터를 품었다

2025년 2월, 권한 관리 회사 오소의 그레이엄 너레이는 「벡터 데이터베이스: 기능인가 제품인가?」에서 이렇게 썼습니다. "새 인프라를 들이고 운영하는 비용을 생각하면, 짜낼 즙이 그만한 가치가 없어 보인다." 2026년 5월 인포월드 칼럼은 한발 더 나갔습니다. "개발자가 수년간 써 온 거의 모든 데이터베이스가 이제 벡터를 지원한다."

개발자들의 실제 선택도 이 흐름을 보여 줍니다. 스택 오버플로 2025년 개발자 설문의 'AI 에이전트용 데이터 저장 도구' 항목입니다.

설문 보고서의 표현: "레디스(43%) 같은 전통적이고 개발자 친화적인 도구가 AI용으로 다시 쓰이고 있다."

인수합병도 같은 그림을 그립니다. 2025~2026년 큰손들이 산 것은 벡터 DB 스타트업이 아니라, 포스트그레스 회사와 임베딩 모델 회사였습니다. 데이터브릭스는 네온을 약 10억 달러에(2025년 5월, 네온의 데이터베이스 80%를 AI 에이전트가 만들었다고), 스노우플레이크는 크런치 데이터를 약 2.5억 달러에(6월), 몽고DB는 임베딩 회사 보이저 AI를 2.2억 달러에(2월), 일래스틱은 지나 AI를(10월) 샀습니다. 그리고 바로 어제인 2026년 10월 2일, 수파베이스가 벡터를 지원하는 SQLite 회사 터소 인수에 합의했습니다. 2025~2026년 순수 벡터 DB 스타트업이 인수된 사례는 찾지 못했습니다.

크게 보기

흐름 ② 벡터가 오브젝트 스토리지로 내려갔다

터보퍼퍼가 2023년에 건 '오브젝트 스토리지 우선' 베팅은 2025~2026년 업계의 표준 방향이 됐습니다.

• 아마존 S3 Vectors: 2025년 7월 미리보기, 12월 정식 출시. 파일 창고인 S3 자체에 벡터를 넣습니다. 색인 하나에 20억 개, 버킷 하나에 20조 개. 자주 쓰는 질의는 약 100ms 이하, 드문 질의는 1초 미만. AWS는 '전문 벡터 DB 대비 최대 90% 저렴'을 내걸었습니다. 미리보기 기간에만 색인 25만 개, 벡터 400억 개가 들어왔다고 합니다.
• 밀버스 3.0 (2026년 7월): '레이크 네이티브'. 데이터를 복사하지 않고 Lance·Iceberg·Parquet 파일 위에 바로 색인을 겁니다. 운영사 질리즈는 클라우드 제품 이름을 아예 '벡터 레이크베이스'로 바꿨습니다.
• 랜스DB: 2025년 6월 3천만 달러 시리즈 A(데이터브릭스 벤처스 참여), '멀티모달 레이크하우스'를 표방.
• 크로마: 2025년 8월 S3 위에서 도는 분산 엔진을 정식 출시.

벡터는 이제 '비싼 전용 서버에 모셔 두는 것'이 아니라 '데이터가 원래 있는 곳에 색인을 하나 더 거는 것'이 되어 가고 있습니다.

흐름 ③ 전문 업체들은 검색 엔진이 되어 간다

벡터 DB 붐의 상징이던 파인콘의 2025~2026년은 이 흐름을 압축해서 보여 줍니다.

파인콘의 매출이 크게 줄었다는 수치가 인터넷에 돌지만, 출처가 확인되지 않은 추정치라 여기서는 옮기지 않습니다. 분명한 건 방향입니다. 벡터 전용으로 출발한 회사가 키워드 검색을 붙이고, 에이전트용 지식 계층으로 올라가고 있습니다.

다른 업체들도 비슷합니다. 2026년 3월 5천만 달러를 조달한 쿼드런트의 CEO는 "밀집 벡터만으로 하는 최근접 검색은 기본기(table stakes)일 뿐"이라며 밀집·희소·멀티 벡터·필터를 조합하는 '조립형 검색'을 내세웠습니다. 위비에이트는 2026년 6월 에이전트 메모리 서비스 엔그램을 정식 출시했습니다. 터보퍼퍼의 에스킬드센도 2026년 3월 팟캐스트에서 "터보퍼퍼는 지금 시점에선 검색 엔진"이라고 정리했습니다.

그렇다고 범주가 사라지는 건 아닙니다. DB-엔진스의 2026년 10월 벡터 DBMS 순위를 보면 상위 8개가 모두 오라클·포스트그레스·몽고DB 같은 범용 시스템이지만, 순수 벡터 DB의 관심도 점수는 여전히 오르는 중입니다(파인콘 13위, 전년 대비 +2.95). 시장은 죽는 게 아니라, 모양을 바꾸고 있습니다.

흐름 ④ 에이전트가 검색 방식을 바꾼다

마지막 흐름은 '누가 검색하는가'의 변화입니다. 2026년 2월, 클로드 코드를 만든 보리스 체르니는 이렇게 썼습니다. "초기 클로드 코드는 RAG와 로컬 벡터 DB를 썼지만, 에이전트 검색(agentic search)이 대체로 더 낫다는 걸 금방 알았다. 더 단순하고, 보안·프라이버시·데이터 신선도·안정성 문제도 없다." 에이전트가 grep으로 파일을 찾아 직접 읽는 방식입니다. 이 블로그의 「검색은 파이프라인이 아니라 에이전트가 되었다」가 이 흐름을 자세히 다뤘습니다.

그런데 이게 벡터 검색의 종말일까요. 반대 데이터도 있습니다. 커서는 2025년 11월 grep에 자체 임베딩 검색을 더하니 평균 정확도가 12.5%(모델에 따라 6.5~23.5%) 올랐다고 발표했습니다. 커서의 의미 검색은 지금도 터보퍼퍼 위에서 돌아갑니다. 에스킬드센의 관찰은 이렇습니다. 에이전트는 사람보다 훨씬 많은 질의를 병렬로 던지고, 의미·키워드·정규식·SQL식 질의를 섞어 씁니다. 그래서 하이브리드 검색은 오히려 더 중요해지고, 터보퍼퍼는 질의 가격을 5배 내렸다고 했습니다.

크게 보기

'벡터냐 grep이냐'가 아니라 '벡터도, 키워드도, 정규식도, 필터도 한 엔진에서'. 터보퍼퍼 v3가 벡터를 왕좌에서 내리고 모든 색인을 대등하게 만들려는 이유가 바로 이 수요입니다.

네 흐름을 한 연표로 모았습니다. 색깔별로 골라 보세요.

7부. 반론과 한계

시장 흐름에 대해서도 균형을 잡아 둘 필요가 있습니다. '모든 DB가 벡터를 한다'는 말은 사실이지만, 그 벡터 기능의 성능과 규모가 전용 시스템과 같다는 뜻은 아닙니다. 예를 들어 pgvectorscale은 5천만 개 벡터에서 파인콘보다 p95 지연이 28배 낮다는 벤치마크를 냈지만, 이건 제작사가 직접 낸 수치이고 독립 재현은 없습니다. 반대로 S3 Vectors의 '최대 90% 저렴'도 AWS의 주장입니다. 이 글의 숫자들 역시 대부분 각 회사가 공개한 자료라는 점을 감안해 읽어 주세요.

8부. 그래서 내 벡터는 어디에 살아야 할까

2026년의 질문은 더 이상 '어떤 벡터 DB를 쓸까'가 아닙니다. '벡터 색인을 어디에 하나 더 걸까' 입니다. 아래 질문지는 시장의 일반적 경향을 단순한 규칙으로 옮긴 것입니다. 결론이 아니라 '어디부터 실측할지'를 정하는 출발점으로 쓰세요.

어떤 구성을 고르든, 터보퍼퍼의 이야기에서 가져갈 점검 항목이 있습니다.

한국어 검색이라면 이 블로그의 한국어 검색 스택 시리즈가 실측으로 보여 준 점을 함께 기억해 두면 좋습니다. 키워드와 의미를 섞는 하이브리드가 대체로 이득이지만, BM25 쪽 토크나이저가 약하면 오히려 손해를 볼 수 있다는 것(「키워드와 의미, 둘 다 쓴다」), 그리고 벡터 색인 자체의 선택도 데이터 규모에 따라 달라진다는 것(「4096차원에 HNSW가 필요한 이유」). 전체 그림은 「2026 RAG 스택 선택 가이드」에 정리해 두었습니다.

크게 보기

맺으며: 죽음이 아니라 졸업

3년 전, 벡터 검색은 너무 새롭고 너무 어려워서 그것만을 위한 데이터베이스가 필요했습니다. 모든 것을 벡터 중심으로 설계하는 게 합리적이었습니다. 터보퍼퍼 v1이 그랬고, 그 선택은 커서와 노션의 비용을 수십 퍼센트씩 깎으며 옳았음이 증명됐습니다.

그런데 성공한 기술은 결국 평범해집니다. 고객은 벡터 '만'이 아니라 벡터 '도' 원했고, 필터와 키워드와 집계와 정규식이 하나씩 붙을 때마다 벡터 중심 설계는 그 대가를 치렀습니다. 그래서 터보퍼퍼는 데이터베이스의 역사가 이미 걸어간 길을 따라, 문서를 주인 자리에 앉히고 벡터를 여러 색인 중 하나로 내려놓기로 했습니다. 같은 시기 오라클과 포스트그레스와 S3는 벡터를 자기 안에 품었고, 파인콘은 키워드 검색을 붙였고, 에이전트는 벡터와 grep을 섞어 쓰기 시작했습니다.

그러니 '벡터 데이터베이스의 죽음'은 사실 벡터 검색의 졸업에 가깝습니다. 특별한 전용 시스템이 필요하던 신기술이, 이제 어디에나 있는 기본 부품이 된 것. 2026년 엔지니어에게 남은 질문은 "어떤 벡터 DB를 살까"가 아니라, "우리 데이터의 주인은 무엇이고, 벡터는 그 곁에 어떻게 붙어야 하는가"입니다.

참고 자료

원문과 터보퍼퍼

• Dan Harrison, 「RIP, vector database」 (turbopuffer, 2026-09-30) — turbopuffer.com
• 해커뉴스 토론 (374점) — news.ycombinator.com
• turbopuffer v3 진행 페이지 — turbopuffer.com
• Simon Eskildsen, 「turbopuffer: fast search on object storage」 — turbopuffer.com
• 「ANN v3」 — turbopuffer.com
• 「Native filtering」 — turbopuffer.com
• 「FTS v2: postings」 — turbopuffer.com
• 「FTS v2: MAXSCORE」 — turbopuffer.com
• 노션 사례 — turbopuffer.com
• v1 출시 트윗 (2023-10-04) — x.com
• Linear, 「Rebuilding Linear's delta sync read path」 (2026-08-18) — linear.app
• Latent Space 팟캐스트 (2026-03) — latent.space

논문과 데이터베이스의 역사

• Malkov & Yashunin, HNSW (arXiv 1603.09320, 2016) — arxiv.org
• Subramanya et al., DiskANN (NeurIPS 2019)
• Chen et al., SPANN (NeurIPS 2021) — arxiv.org
• Xu et al., SPFresh (SOSP 2023) — arxiv.org
• Khattab & Zaharia, ColBERT (SIGIR 2020) — arxiv.org
• Boncz, Zukowski, Nes, 「MonetDB/X100」 (CIDR 2005) — cidrdb.org
• MySQL 8.4 매뉴얼, 「Clustered and Secondary Indexes」 — dev.mysql.com
• Uber Engineering, 「Why Uber Engineering Switched from Postgres to MySQL」 (2016)

시장 흐름

• a16z, 「Emerging Architectures for LLM Applications」 (2023) — a16z.com
• TechCrunch, 파인콘 시리즈 B (2023-04-27) — techcrunch.com
• Oso, 「Vector Databases: Feature or Product?」 (2025-02) — osohq.com
• InfoWorld, 「Your AI doesn't need another database」 (2026-05) — infoworld.com
• AWS, 「Amazon S3 Vectors now generally available」 (2025-12) — aws.amazon.com
• Pinecone, CEO 교체 (2025-09) — pinecone.io
• Pinecone, 「Full-text search generally available」 (2026-09) — pinecone.io
• Calcalist, 파인콘 매각 검토 보도 (2025-08) — calcalistech.com
• Blocks & Files, 밀버스 3.0 (2026-07) — blocksandfiles.com
• Blocks & Files, 쿼드런트 시리즈 B (2026-03) — blocksandfiles.com
• Cursor, 「Improving agent with semantic search」 (2025-11) — cursor.com
• Stack Overflow 2025 개발자 설문 (AI) — survey.stackoverflow.co
• DB-Engines 벡터 DBMS 순위 — db-engines.com
• SiliconANGLE, 수파베이스의 터소 인수 (2026-10-02) — siliconangle.com