Laravel 벡터 검색, 이제 MariaDB 지원

Laravel 13을 통해 개발자는 MariaDB에서 네이티브 벡터 검색 쿼리를 실행할 수 있게 되었으며, PostgreSQL로 전환할 필요 없이 Laravel 생태계에 시맨틱 검색(semantic-search) 기능을 추가할 수 있습니다.

이번 새로운 지원은 기존의 PostgreSQL 전용 구현을 대체하므로, 익숙한 whereVectorSimilarTo 메서드를 이제 MariaDB 연결에서 직접 사용할 수 있습니다. 추천 엔진, 문서 유사도 도구 또는 "최근접 이웃(nearest-neighbor)" 로직에 의존하는 기능을 구축 중이라면, 이번 변화로 주요 장애물이 제거되었습니다.

이러한 변화가 중요한 이유

이전의 Laravel 쿼리 빌더는 PostgreSQL 연결만 인식하는 instanceof 테스트를 통해 벡터 검색 필요 여부를 감지했습니다. 이러한 방식은 해당 기능을 단일 드라이버에 종속시키고 코드베이스에 데이터베이스별 조건문을 산재하게 만들었습니다.

13 버전에서는 로직을 grammar 레이어로 이동시키고 두 가지 드라이버 전용 메서드를 추가했습니다:

  • supportsVectorDistance() – 현재 연결이 벡터 거리를 계산할 수 있는지 Laravel에 알려줍니다.
  • compileVectorDistanceExpression() – 계산을 수행하는 SQL 조각(fragment)을 생성합니다.

이러한 책임을 각 드라이버에 할당함으로써, 프레임워크는 "타입 체크(type-checking)" 해킹 방식을 버리고 향후 확장을 위한 길을 열었습니다. 이제 다른 데이터베이스를 지원하려면 조건문 블록을 흩뿌리는 대신 몇 가지 드라이버 메서드만 구현하면 됩니다.

MariaDB는 네이티브 함수를 지원하지만, MySQL은 지원하지 않습니다

MariaDB에는 네이티브 벡터 함수가 포함되어 있습니다. 표준 MySQL은 AI 확장을 추가하는 특화된 클라우드 서비스를 사용하지 않는 한 이러한 함수가 없습니다.

Laravel은 의도적으로 PHP 측에서의 유사도 계산을 피합니다. PHP에서 벡터를 계산하면 페이지네이션(pagination)이 깨지고 경고 없이 앱 속도가 느려질 수 있기 때문입니다. 드라이버가 작업을 처리할 수 없을 때 에러를 발생시키는 것이 더 안전한 실패 모드(failure mode)를 제공합니다.

MySQL 사용자가 지금 할 수 있는 일

현재 스택이 일반 MySQL을 사용 중이라면, 다음과 같은 세 가지 현실적인 경로가 있습니다:

  1. MariaDB로 마이그레이션 – 대부분의 MySQL 워크로드에 대해 즉시 교체 가능한 대안이며, 동일한 생태계를 유지하면서 네이티브 벡터 지원을 제공합니다.
  2. 전용 검색 서비스 추가 – 유사도 쿼리만을 위해 MySQL과 함께 가벼운 PostgreSQL 인스턴스를 실행합니다.
  3. 사용하지 않기 – 많은 애플리케이션에서 시맨틱 검색은 선택 사항입니다. 이점보다 운영 비용이 더 크다면 MySQL을 그대로 유지하는 것이 실용적인 선택일 수 있습니다.

각 옵션은 운영 복잡성, 지연 시간(latency), 유지 관리 오버헤드 측면에서 트레이드오프(trade-off)가 있습니다. 결정은 벡터 검색이 제품의 가치 제안(value proposition)에 얼마나 핵심적인지에 달려 있습니다.

API 설계를 위한 교훈

이번 Laravel의 변화는 더 넓은 설계 원칙을 보여줍니다. 즉, 핵심 로직 전체에 데이터베이스별 체크를 뿌려두지 말라는 것입니다. 특정 엔진의 기능에 의존하는 기능이 있다면, 해당 의존성을 드라이버 인터페이스 뒤로 캡슐화하십시오. 새로운 grammar 기반 접근 방식은 바로 그렇게 함으로써, 핵심 쿼리 빌더를 다시 수정하지 않고도 프레임워크가 향후 확장될 수 있도록 준비합니다.

자체 패키지를 구축하는 개발자들은 이 점에 주목해야 합니다. 서비스 레이어 내부에서 데이터베이스 유형에 대한 instanceof 체크를 발견한다면, 해당 책임을 드라이버나 전용 어댑터로 옮기십시오. 이는 공개 API를 깔끔하게 유지하고 코드를 미래 지향적으로 만들어 줍니다.