RAG 스택은 왜 자꾸 세 조각으로 갈라지는가
대다수 RAG 서비스는 원본을 담는 운영DB, 임베딩을 담는 전용 벡터DB, 키워드 매칭을 담당하는 검색엔진의 세 컴포넌트로 벌어져 있습니다. 각 조각이 별도 스키마와 별도 색인 주기를 가지므로 하나의 문서가 바뀔 때마다 세 곳을 따로 갱신해야 하고, 이 지점에서 운영 비용과 장애 표면이 함께 커집니다. Databricks가 Data + AI Summit 2026(6월 15~18일)에서 공개한 Lakebase Search 베타는 이 세 조각을 Postgres 한 엔진 안으로 접는다는 각도에서 주목할 만합니다.
압축이 바꾸는 것: RAM 상수에서 스토리지 변수로
Lakebase Search는 RaBitQ 기반 32배 압축으로, 1억 벡터 인덱스를 위해 기존에 약 300GB RAM이 필요하던 것을 10GB 미만에 수용하고 10억 개 이상의 벡터까지 지원합니다. 함께 제공되는 lakebase_text 확장은 GIN을 대체하는 오브젝트 스토리지 최적화 인덱스와 네이티브 BM25를 제공합니다. 두 확장이 같은 엔진에서 돌기 때문에 벡터 유사도와 키워드 점수를 RRF로 결합한 하이브리드 검색이 단일 SQL 한 문장으로 동작하며, 타입은 표준 pgvector와 tsvector를 그대로 써서 Postgres 호환이 100% 유지됩니다.
통합할지 말지: 3-스택을 접기 전에 세우는 기준
통합은 컴포넌트 수를 줄이는 일이지, 검색 품질을 자동으로 올려 주는 일이 아닙니다. 먼저 무엇을 없애서 무엇을 얻는지를 수치로 고정해야 판단이 섭니다. 목표 지표는 세 축으로 잡습니다. 인덱스가 점유하는 RAM·스토리지 비용, 원본과 인덱스 사이의 동기화 지연, 그리고 하이브리드 검색과 단일 검색의 정답 포함률(recall@k)입니다. 출발선 예시로는 1억 벡터 기준 인덱스 상주 메모리 10GB 미만, 원본-인덱스 동기화 지연 p95 5초 이내, recall@10에서 하이브리드가 벡터 단독 대비 최소 +5%p를 확보하는 값을 두고, 이 표를 통합 전후로 같은 칸에 채워 비교합니다.
합격선을 세웠다면 실패 패턴부터 역산합니다. 세 조각 구조의 가장 흔한 사고는 운영DB와 벡터DB 사이의 동기화 드리프트로, 원본은 갱신됐는데 임베딩이 뒤늦게 따라와 stale 검색 결과가 나가는 경우입니다. 두 번째는 컴포넌트별 장애 도미노로, 검색엔진 한 조각이 죽으면 하이브리드 랭킹 전체가 무너지는 연쇄입니다. 세 번째는 RAM 기반 인덱스의 비용 폭증으로, 벡터 수가 늘수록 상주 메모리가 선형으로 불어나 어느 순간 인프라 예산을 압도합니다.
복구 관점에서 단일 엔진 통합의 이점은 동기화 경로 자체가 사라진다는 데 있습니다. 원본과 인덱스가 같은 트랜잭션 안에 있으면 드리프트가 구조적으로 발생하지 않으므로, stale 결과의 원인 추적을 컴포넌트 간 배치 지연이 아니라 SQL 한 곳에서 끝낼 수 있습니다. 다만 통합 전에는 반드시 롤백 경로를 남겨, 하이브리드 SQL의 랭킹이 기존 스택보다 열화되면 이전 검색엔진 라우팅으로 되돌릴 수 있게 이중 운영 구간을 둡니다.
운영 체크리스트는 마이그레이션 순서로 씁니다. 먼저 읽기 경로를 그림자로 복제해 하이브리드 SQL의 recall@k를 프로덕션 트래픽으로 오프라인 비교하고, 다음으로 쓰기 경로를 이중 기록해 동기화 지연이 사라지는지 확인한 뒤, 마지막에 읽기 트래픽을 5%→25%→100%로 승급하며 각 단계에서 recall과 지연을 관측합니다. 통합 전 부하 테스트에는 최대 벡터 수에서의 상주 메모리, 색인 재구축 소요 시간, 동시 쓰기 중의 BM25 색인 지연, RRF 결합 시의 p95 질의 지연을 필수 항목으로 넣습니다. pgvector를 이미 운영 중인 팀이라면 타입이 그대로 유지되므로, 데이터 재적재 없이 확장만 추가하는 무마이그레이션 경로로 하이브리드부터 얹어 검증하는 편이 위험을 낮춥니다.
지속 개선은 recall 회귀를 주기로 잡습니다. 하이브리드가 벡터 단독을 못 이기는 질의 유형을 매주 상위부터 모아 RRF 가중과 BM25 파라미터를 조정하고, 통합으로 없앤 컴포넌트 수와 절감한 인덱스 비용을 릴리스 노트에 분리해 남깁니다. 조각을 줄였는데도 recall이나 비용 곡선이 개선되지 않는다면, 통합이 아니라 이름만 바꾼 재배치에 머물러 있다는 신호입니다.
한눈에 보는 통합 판단 포인트
3종 스택을 Postgres 하나로 접는 결정은 검색 기법이 아니라 인프라 구성 요소 수의 문제입니다. RaBitQ 32배 압축으로 RAM 상수를 스토리지 변수로 바꾸고, 동기화 드리프트라는 장애 원인을 단일 트랜잭션으로 소거하며, recall@k·상주 메모리·동기화 지연의 합격선을 통합 전후 같은 표에 채워 비교하고, pgvector 팀은 무마이그레이션 확장 경로로 하이브리드부터 검증하면 컴포넌트 수와 TCO를 함께 줄일 수 있습니다.
참고 링크
Announcing Lakebase Search: agent-native retrieval built into Lakebase Postgres — Databricks Blog