AI VIDEO BRIEFING
SQL 벡터 인덱스 정리 — 갱신 가능한 인덱스와 반복 필터링으로 달라진 벡터 검색 방식
마이크로소프트 Data Exposed에서 소개한 SQL 벡터 인덱스 개선 사항을 정리했다. 인덱스 빌드 속도, 데이터 변경 시 자동 반영되는 업데이트 지원, 조건 필터를 함께 적용하는 반복 필터링이 핵심이다.

핵심 메시지
쉽게 이해하기
마이크로소프트의 Data Exposed 에피소드에서 애나 호프먼과 밥 워드가 SQL의 벡터 인덱싱이 처음 공개된 이후 무엇이 달라졌는지를 짚는다. 출발점은 벡터 거리 계산 함수였고, 이는 사실상 데이터를 전부 훑는 방식이었다. 이후 DiskANN 기술을 이용해 벡터 인덱스를 만들었지만, 팀은 첫 공개 시점부터 개선의 여지를 알고 있었고 우선 고객이 써보게 한 뒤 세 가지를 손봤다고 설명한다.
첫째는 속도다. 인덱스의 포맷을 바꿔 빌드가 눈에 띄게 빨라졌는데, 여기에는 벡터를 압축하는 양자화 기법이 쓰였다. 디스크 사용량은 늘어나지만 검색과 인덱스 생성 속도에서 얻는 이득이 크다는 설명이다. 둘째는 갱신 가능 여부다. 예전 인덱스는 한 번 만들면 갱신할 수 없었으나, 컬럼스토어에서 했던 것과 비슷하게 이제는 테이블에 삽입·수정·삭제가 일어나면 백그라운드에서 인덱스가 따라 바뀐다.
셋째가 검색 방식의 변화다. 이전에는 벡터 검색으로 결과를 먼저 찾은 뒤 WHERE 조건을 적용했기 때문에 조건에 맞는 결과를 놓치는 사후 필터링 문제가 있었다. 새로 도입된 반복 필터링은 조건과 벡터 검색을 함께 적용해 원하는 결과를 돌려준다. 이 동작을 부르는 문법이 TOP WITH APPROXIMATE이며, 현재는 공개 미리보기 단계로 정식 출시까지 더 개선될 예정이라고 밝힌다.
시연에서는 대출 회사 웹사이트를 예로 자연어 검색을 붙인다. Azure OpenAI의 텍스트 임베딩 모델을 데이터베이스 안에 외부 모델로 정의해두고, 임베딩을 생성해 테이블에 넣은 뒤 벡터 인덱스를 만든다. 검색은 저장 프로시저로 감싸 프롬프트를 입력으로 받고, 먼저 프롬프트의 임베딩을 만든 다음 TOP WITH APPROXIMATE 구문으로 조건과 벡터 검색을 함께 수행하는 흐름이다.
운영 측면의 선택지도 함께 소개된다. Hyperscale의 명명된 복제본은 읽기 전용 복제본이면서 별도의 데이터베이스 이름으로 접근할 필요가 없고, 서버리스를 포함해 주 복제본과 다른 vCore 구성을 가질 수 있다. 데이터 변경은 주 복제본에서 처리되고 인덱스도 그쪽에서 갱신되지만, 실제 벡터 검색 부하는 복제본으로 넘길 수 있다는 것이 시연의 요지다.
주요 인사이트
- 인덱스를 갱신할 수 있게 된 변화는 편의 기능이 아니라 운영 방식의 전환이다. 데이터가 바뀔 때마다 인덱스를 다시 만들 필요가 없어지면서 벡터 검색을 상시 갱신되는 업무 데이터 위에 얹을 수 있게 된다.
- 사후 필터링에서 반복 필터링으로의 변경은 정확도 문제를 다룬다. 벡터 유사도로 뽑은 상위 결과에 조건을 나중에 적용하면 조건에 맞는 항목이 상위권 밖에 있을 때 통째로 사라진다.
- 양자화는 디스크 사용량과 속도를 맞바꾸는 선택이다. 저장 공간이 늘어나는 대신 인덱스 생성과 검색이 빨라지는 구조라, 용량보다 응답 속도가 중요한 워크로드에 유리하다.
- 벡터 자료형의 차원 한도는 1998이지만, 반정밀도인 float16을 쓰면 그보다 큰 차원의 임베딩 모델도 수용할 수 있다.
- 임베딩 모델을 데이터베이스 밖의 애플리케이션이 아니라 데이터베이스 안의 외부 모델 정의로 두면, 임베딩 생성부터 검색까지를 SQL 안에서 이어붙일 수 있다.
자주 묻는 질문
반복 필터링은 기존 방식과 무엇이 다른가?
예전에는 벡터 검색을 먼저 실행해 유사한 결과를 찾은 다음 WHERE 조건을 적용했다. 이 사후 필터링 방식에서는 조건에 맞는 항목이 벡터 검색 상위 결과에 들지 못하면 결과에서 빠져버린다. 반복 필터링은 WHERE 조건과 벡터 검색을 함께 적용해 조건을 만족하는 올바른 결과를 돌려준다. 현재 공개 미리보기 단계이며 정식 출시까지 더 개선될 예정이다.
데이터가 바뀌면 벡터 인덱스를 다시 만들어야 하나?
이제는 그럴 필요가 없다. 초기 벡터 인덱스는 갱신이 불가능했지만, 컬럼스토어에서 적용했던 방식과 비슷하게 갱신 가능한 인덱스로 바뀌었다. 벡터 인덱스가 있는 테이블에 삽입·수정·삭제가 일어나면 백그라운드에서 인덱스가 자동으로 반영된다. 시연에서도 주 복제본에 새 행을 넣고 임베딩을 생성한 뒤 같은 질의를 다시 실행해 새 결과가 나오는 것을 보여준다.
명명된 복제본을 벡터 검색에 쓰는 이유는 무엇인가?
벡터 검색 부하를 주 복제본에서 분리하기 위해서다. Hyperscale의 명명된 복제본은 읽기 전용 복제본이지만 읽기 목적을 지정하거나 별도의 데이터베이스 이름으로 접속할 필요가 없고, 서버리스를 포함해 더 작거나 더 큰 vCore 구성을 따로 가져갈 수 있다. 데이터 변경과 인덱스 갱신은 주 복제본에서 이루어지고 검색만 복제본에서 수행하는 구성이 가능하다.
원문과 출처
이 글은 원본 영상의 자막을 바탕으로 한국어 독자를 위해 요약했습니다. 전체 맥락과 최신 정보는 원문에서 확인하세요.
YouTube 원본 영상 보기 ↗