무슨 일이 있었나요?
벡터 검색 엔진을 만드는 회사 turbopuffer가 'RIP, vector database(벡터 데이터베이스여, 편히 잠들라)'라는 제목의 글을 올렸어요. 벡터 검색으로 사업을 하는 회사가 직접 '벡터 데이터베이스'라는 이름에 부고를 띄운 셈이라 꽤 의미심장하죠.
2023년 ChatGPT 열풍과 함께 벡터 데이터베이스는 AI 인프라 필수품처럼 떠올랐어요. Pinecone, Weaviate, Qdrant, Milvus, Chroma 같은 전문 업체들이 큰 투자를 받았고, RAG를 하려면 벡터 DB부터 깔아야 한다는 게 거의 공식이었죠. 그런데 몇 년이 지난 지금, 독립된 제품 분야로서의 벡터 데이터베이스는 수명을 다했다는 이야기가 나온 거예요.
먼저, 벡터 데이터베이스가 뭐였죠?
간단히 짚고 갈게요. AI 모델은 문장이나 이미지를 임베딩(embedding)이라는 숫자 배열로 바꿀 수 있어요. 예를 들어 '강아지 사료 추천'과 '반려견 먹이 뭐가 좋아요'는 단어는 다르지만 의미가 비슷해서, 숫자로 바꾸면 서로 가까운 자리에 놓여요. 지도 위에 의미가 비슷한 문장들이 모여 사는 동네가 생긴다고 생각하면 돼요.
벡터 데이터베이스는 이 숫자 배열을 저장해두고, 질문이 들어오면 가장 가까운 이웃을 빠르게 찾아주는 데 특화된 데이터베이스예요. 수억 개 중에서 정확히 가장 가까운 걸 찾으려면 너무 느리니까, 정확도를 조금 내주고 속도를 얻는 ANN(근사 최근접 이웃) 인덱스가 핵심 기술이었어요.
왜 '죽었다'는 걸까?
제목이 가리키는 메시지를 한마디로 줄이면 벡터는 기능이지, 제품 분야가 아니다에 가까워요. 여기엔 몇 가지 흐름이 겹쳐 있어요.
첫째, 거의 모든 데이터베이스가 벡터를 지원하게 됐어요. PostgreSQL에는 pgvector가 있고, MongoDB, Elasticsearch, Redis, AWS S3까지 벡터 저장과 검색 기능을 붙였어요. 벡터를 저장하고 검색할 수 있다는 것만으로는 더 이상 차별점이 안 되는 거죠.
둘째, 벡터 검색만으로는 좋은 검색 결과를 내기 어렵다는 게 드러났어요. 실제 서비스를 운영해보면 의미 기반 검색만으로는 부족할 때가 많아요. 제품 코드나 고유명사처럼 정확히 그 단어를 찾아야 할 때는 오래된 키워드 검색(BM25 같은 전문 검색)이 더 잘하거든요. 그래서 요즘은 벡터 검색과 키워드 검색을 섞는 하이브리드 검색, 권한이나 날짜로 거르는 필터링, 결과 순서를 다시 매기는 리랭킹까지 합쳐야 제대로 된 검색이 나와요. 이건 벡터 DB보다는 검색 엔진이 하는 일에 가깝죠.
셋째, AI 에이전트가 검색하는 방식이 바뀌었어요. 예전 RAG는 질문 한 번에 검색 한 번이었다면, 요즘 에이전트는 키워드를 바꿔가며 여러 번 검색하고 grep 같은 정확 매칭도 섞어 써요. 코딩 에이전트에서는 임베딩 대신 grep으로 코드를 찾는 게 오히려 잘 통한다는 경험담이 많아진 것도 같은 흐름이에요. 검색 요청의 양과 패턴이 달라지면, 그걸 받쳐줄 인프라에 대한 요구도 달라질 수밖에 없어요.
turbopuffer는 어떤 회사인가요?
turbopuffer의 아키텍처를 보면 이런 주장이 왜 나왔는지 감이 와요. turbopuffer는 데이터를 기본적으로 오브젝트 스토리지(S3처럼 저렴한 파일 저장소)에 두고, 자주 쓰는 데이터만 SSD와 메모리에 캐시하는 구조예요. 메모리 위주로 설계된 초기 벡터 DB들과 달리, 저장 비용을 크게 낮추는 대신 한동안 안 쓰던 데이터를 처음 조회할 때는 조금 느려지는 트레이드오프를 골랐어요. 또 벡터 검색과 전문(full-text) 검색을 함께 지원하는 방향으로 만들어졌고요. Cursor나 Notion처럼 고객마다 커다란 인덱스를 따로 다뤄야 하는 서비스들이 고객으로 알려져 있어요.
즉 turbopuffer 스스로도 벡터 DB가 아니라 저렴하고 확장성 있는 검색 엔진으로 자리 잡으려는 거예요. 그래서 이 글은 일종의 정체성 선언으로 읽을 수 있어요.
한국 개발자에게 주는 시사점
이제 막 RAG를 시작하는 팀이라면 굳이 전용 벡터 DB부터 도입하지 않아도 될 수 있어요. 이미 PostgreSQL을 쓰고 있다면 pgvector로 시작해보고, 데이터가 수천만 건 단위로 커지거나 성능 한계가 보일 때 전문 솔루션을 검토해도 늦지 않아요.
한국어 서비스라면 하이브리드 검색이 특히 중요해요. 한국어는 조사와 어미 변화가 많아서, 형태소 분석 기반 키워드 검색과 의미 기반 검색이 서로의 약점을 잘 메워주거든요. 임베딩 모델 하나만 믿기보다 처음부터 키워드 검색을 함께 섞는 구조를 고려해보세요.
그리고 어떤 DB를 쓸지보다 검색 품질을 어떻게 측정할지에 시간을 더 쓰는 게 좋아요. 평가 데이터셋을 만들어두면 나중에 어떤 기술로 바꾸든 실제로 나아졌는지 숫자로 확인할 수 있으니까요.
마무리
한줄 정리: 벡터 검색은 사라지는 게 아니라 모든 곳에 스며들었고, 이제 경쟁은 벡터 DB가 아니라 좋은 검색을 누가 만드느냐로 옮겨가고 있어요.
여러분 팀은 RAG나 검색 기능에 어떤 저장소를 쓰고 있나요? 전용 벡터 DB를 도입했다가 pgvector 같은 범용 DB로 돌아왔거나, 그 반대로 옮겨간 경험이 있다면 공유해주세요!
🔗 출처: Hacker News