SQL 서버 벡터 검색 실전: DiskANN 인덱스, 하이브리드 검색, RAG 구성법

핵심 메시지

• 벡터 데이터 타입은 정식 출시됐고 벡터 인덱스와 관련 함수는 미리 보기 단계로, 기존 SQL 서버 데이터베이스에 새 시스템을 만들지 않고 의미 검색을 붙일 수 있다.
• SQL 서버가 제공하는 벡터 인덱스는 DiskANN 하나이며, 쿼리에 WITH APPROXIMATE를 붙여야 근사 검색이 동작하고 붙이지 않으면 전수 비교인 KNN이 쓰인다.
• 근사 검색은 그래프를 영역으로 나눠 훑기 때문에 경계 근처의 정답을 놓칠 수 있고, 100건 중 4건을 놓치면 재현율은 96%가 된다.
• 2026년 3월 Azure SQL Database에 반영된 개선으로 필터 조건을 그래프 탐색 중에 적용하고 삽입·수정·삭제가 인덱스에 즉시 반영되지만, SQL Server 2025에는 아직 들어가지 않았다.
• 의미 검색과 BM25 기반 전문 검색을 상호 순위 융합(RRF)으로 합치는 하이브리드 검색이 브랜드명 같은 고유 표현과 뉘앙스를 동시에 잡아 준다.

쉽게 이해하기

마이크로소프트 SQL 팀의 애나 호프먼이 개발자 대상 세션에서 'SQL 서버 안의 벡터 검색'을 처음부터 끝까지 시연했다. 출발점은 임베딩 자체가 아니라 현실적인 제약이다. 이미 티켓 시스템이나 사내 지식베이스가 SQL 서버 위에서 돌고 있고 보안 경계도 그대로 유지해야 하는 조직이라면, 벡터 전용 데이터베이스를 새로 도입하는 대신 기존 데이터베이스에 벡터 열을 하나 더 붙이는 편이 낫다는 것이다.

기본 개념은 좌표 비유로 설명됐다. 임베딩은 1,500개 안팎의 숫자로 이뤄진 고차원 좌표이고, 두 벡터의 거리(주로 코사인 거리)가 가까울수록 의미가 비슷하다고 본다. 문제는 KNN 방식이 검색어 하나당 테이블의 모든 행과 거리를 계산한다는 점이다. 500만 행이면 500만 번이다. 그래서 그래프를 미리 영역으로 나눠 두고 질의점이 속한 영역만 훑는 근사 최근접 이웃(ANN) 방식이 필요해지며, SQL 서버에서 이 역할을 하는 것이 DiskANN 인덱스다. 대신 영역 경계 바로 바깥에 있던 더 가까운 항목은 계산조차 되지 않아 결과에서 빠질 수 있고, 이 손실을 KNN 결과와 비교해 재현율로 측정한다.

실무에서 걸림돌이 됐던 두 가지는 최근 개선으로 해소되는 중이다. 예전에는 벡터 검색으로 상위 20건을 뽑은 뒤 방 개수나 학군 같은 조건으로 걸러야 해서, 20건을 원하면 1,000건을 과다 조회해 놓고 필터 뒤에 몇 건이 남을지 기대하는 식이었다. 또 데이터가 바뀔 때마다 인덱스를 통째로 다시 만들어야 했고 규모에 따라 몇 시간이 걸리기도 했다. 2026년 3월 Azure SQL Database에 들어간 반복적 필터링은 조건을 그래프 탐색 도중에 적용하고, 삽입·수정·삭제가 인덱스에 비동기로 즉시 반영된다. 발표자는 이 개선이 SQL Server 2025에는 아직 적용되지 않았고, 언제 내보낼지 우선순위를 정하기 위해 현장 피드백을 받고 싶다고 밝혔다.

검색 품질을 끌어올리는 방법으로는 하이브리드 검색이 제시됐다. '속이 편한 그린마운틴 블렌드' 같은 질의에서 벡터 검색만 쓰면 커피와 무관한 소화 관련 후기가 섞이고, 전문 검색만 쓰면 브랜드명과 겹치는 녹차가 딸려 온다. 두 순위를 상호 순위 융합으로 합치면 양쪽에 모두 등장한 항목이 높은 점수를 받아 한쪽만의 오류가 걸러진다. 관련도가 더 중요하면 외부 REST 호출로 재순위 모델을 부르는 선택지도 있다.

마지막 시나리오는 이력서 PDF에 대한 RAG였다. 문서에서 텍스트를 뽑아 500토큰 단위로 청크를 나누고, 각 청크의 임베딩을 저장한 뒤 벡터 검색으로 후보를 찾고, 연차·지역·전형 단계 같은 관계형 열과 조인해 좁힌다. 마지막에는 데이터베이스 안의 저장 프로시저가 외부 REST 호출로 LLM을 불러 '어떤 후보가 클라우드 데이터 플랫폼 경험이 있는가' 같은 질문에 근거와 함께 답하게 만든다. 임베딩 생성 모델은 클라우드뿐 아니라 같은 장비나 사내 네트워크에 둘 수도 있어, 데이터를 외부로 내보내지 않는 구성도 가능하다.

주요 인사이트

• '벡터 데이터베이스를 따로 둘 것인가'라는 질문에 발표자는 상황에 따라 다르다고 답했다. 여러 곳에서 데이터를 끌어모아야 하면 전용 검색 서비스가, 비교·필터 대상이 이미 같은 데이터베이스 안에 있으면 SQL 내부 벡터 검색이 유리하다는 기준이다.
• 재현율은 추상적인 지표가 아니라 직접 측정할 수 있다. 같은 질의를 KNN과 근사 검색으로 각각 돌려 결과가 얼마나 겹치는지 세어 보면 자기 데이터에서의 손실률이 나온다.
• 청크를 나눌지 말지는 문서 길이가 좌우한다. 긴 문서를 임베딩 하나로 뭉치면 의미가 평균으로 뭉개져 어떤 질의에도 어중간하게 걸리므로, 문서 안 어느 대목이 관련 있는지까지 찾으려면 청킹이 필요하다.
• 임베딩 최신화는 별도 설계 과제다. 원본 데이터가 바뀌면 임베딩도 다시 만들어야 하는데, 지금은 트리거와 외부 호출 조합이 현실적이고 장기적으로는 변경 이벤트 스트리밍 쪽으로 가는 방향이라고 소개됐다.
• 이미 내부에서 쓰이고 있다는 점도 언급됐다. Dynamics 365 Business Central과 마이크로소프트 퀀텀의 소재 검색이 이 기능을 실제 운영에 쓰는 사례로 제시됐다.

자주 묻는 질문

관련 AI 소식