[전문가 기고] SQL의 종말: AI 시대의 데이터베이스, 벡터 DB

SQL(Structured Query Language)에 익숙하신 분, 꽤 많으실 거라고 생각합니다. 저도 제 첫 직장에서 개발자로 업무를 익히고 배우던 당시, SQL 공부를 했던 기억이 나는데요. ^.^;

지난 수십년 간, SELECT * FROM WHERE 라는 구조는 바로 ‘데이터베이스에 대한 질의 방법’을 말 그대로 ‘대표’하는 것이었습니다. 보고용 시스템이든, 재무 분석 시스템이든, 사용자 행동 분석 시스템이든, 정말 엄청나게 다양한 용처에서 ‘데이터를 정밀하게 다루기 위해서’ 구조화된 SQL을 사용하는 건 너무 자연스러운 것이었습니다.

한 때, ‘안티 SQL 혁명’을 외쳤던 NoSQL조차도, 결국 SQL 지원을 하면서 SQL이 사실상 대체 불가능한 위치에 있다는 점이 다시 한 번 확인되기도 했죠.

그런데, 이런 의문을 혹시 가져본 적은 없으세요? 바로, ‘지난 50년 이상 컴퓨터가 사람의 언어를 이해하게끔 가르쳐 왔는데, 그런데 왜 여전히 사람이 컴퓨터의 언어를 사용해야 할까?’ 하는 의문이요.

이제 AI 시대가 본격화되면서, 그런 의문에 대한 대답으로 SQL이 점차 쇠퇴할 거라는 의견을 피력하는 전문가들이 많이 보입니다. 물론, 레거시 시스템에서까지 SQL을 들어내겠다는 뜻은 아니죠. 하지만 현대적인 AI 애플리케이션에서는, SQL이 그 힘을 점차 읽어가고 있는 것도 사실인 것 같습니다.

AI 혁명은, 단순히 소프트웨어를 구축하는 방식을 바꾸는 것에 그치지 않고, SQL 그 자체를 (일종의) 구식 기법으로 만들고 있는데, 대부분의 개발자들은 아직도 JOIN 최적화 같은 기법에 몰두하느라 이걸 눈치채지 못하고 있나 싶기도 합니다.

오늘 튜링 포스트 코리아의 ‘전문가 기고’ 글은, Zilliz의 엔지니어링 VP로 일하고 있는 James Luan이 바라보는 데이터베이스의 미래, 그리고 왜 SQL이 과거의 유산이 될 수 밖에 없는지에 대한 생각을 담은 기고문입니다.

‘자연어’: AI 데이터베이스를 위한 새로운 인터페이스

앞으로, 데이터베이스 안에 데이터를 추가하거나 이미 있는 데이터를 확인하고, 수정하는 등의 작업을 잘 한다는 건 ‘더 SQL을 잘 한다’는 것과는 전혀 다른 의미가 될 겁니다. 거꾸로, 우리가 지금까지 공부하고 사용해 온 SQL 문법을 완전히 버리는 것에 가깝습니다.

복잡한 SQL 쿼리를 가지고 씨름하는 대신, 그냥 이렇게 말하면 됩니다:

“지난 분기 우리 회사의 상위 고객과 최근 구매 행동이 가장 유사한 사용자를 찾아줘.”

그러면, 시스템은 사용자의 의도를 이해하고, 아래와 같은 판단을 자동으로 수행합니다:

• 구조화된 테이블을 조회해야 할지, 아니면 사용자에 대한 임베딩 간의 벡터 유사도 검색을 수행해야 할지?

• 외부 API를 호출해서 데이터를 보강할 필요가 있을지?

• 어떤 방식으로 결과를 정렬하고 필터링해야 할지?

이 모든 과정이 자동으로 처리되고, 문법, 디버깅 등의 고민을 하지 않아도 됩니다.

즉, 당신이 더 이상 데이터베이스 ‘프로그래머’가 아니라, 지능형 데이터 시스템과 대화하는 사용자가 된다는 뜻입니다.

이미 이런 장면은 공상과학 영화의 한 장면이 아니죠. 기술 및 시장조사 기관인 가트너는, 2026년까지 대부분의 기업에서 자연어를 기본 쿼리 인터페이스로 채택하게 될 것이고, SQL이 ‘필수적인 기술’에서 ‘선택적인 기술’로 변화하게 될 거라고 이야기하고 있습니다.

그리고, 그런 방향으로의 변화는 이미 시작되었죠:

• 문법의 장벽 제거: 필드명, 테이블 관계, 쿼리 최적화 등은 이제 ‘시스템의 몫’입니다.

• 비정형 데이터에 친화적으로 진화: 이미지, 오디오, 텍스트가 마치 이전의 숫자나 문자열같이 데이터베이스의 ‘직접적인 쿼리 대상’이 됩니다.

• 접근성의 민주화: 운영팀, 프로덕트 매니저, 분석가도 마치 시니어 엔지니어가 하듯이 데이터를 직접 조회할 수 있습니다.

자연어는 겉으로 드러나는 ‘표면’일 뿐, 진짜 핵심은 ‘AI 에이전트’

그렇지만, ‘자연어로 쿼리를 한다’는 것는 빙산의 일각이고 표면에 드러나는 결과적인 현상에 불과합니다. 진짜 이 과정의 혁신은, 사람처럼 데이터를 이해하고 판단하는 AI 에이전트라고 봐야 합니다.

사람의 언어를 이해하는 것이 1단계라면, 사용자가 무엇을 원하는지 파악하고 효율적으로 실행하는 것이 진짜 필요한 그 다음 단계겠죠.

그런 역할을 하는 ‘AI 에이전트’는, 데이터베이스의 ‘두뇌’로서 아래와 같은 일을 합니다:

🤔 의도 이해: 어떤 필드, 데이터베이스, 인덱스가 필요한지 판단
⚙️ 전략 선택: 구조적 필터링, 벡터 유사도, 하이브리드 방식 중에서 선택
📦 기능 조율: API 실행, 서비스 호출, 시스템 간 쿼리를 조정
🧾 지능적 출력: 사용자가 이해하고 즉시 활용할 수 있는 결과를 반환

실제로 이런 작업이 이루어지는 모습은, 너무나도 간단합니다: 오픈소스로 제공되는 Milvus 벡터 데이터베이스에서 비교적 복잡하다고 할 수 있는 유사도 검색을 하고 싶다면, 그냥 이 한 줄로 끝납니다:

results = collection.search(query_vector, top_k=10, filter="is_active == true") 

한 줄이죠. JOIN도 없고, 서브쿼리도 없고, 성능 튜닝을 할 필요도 없습니다. 전통적 필터는 정확히 일치하느냐 하는 조건을 체크하는 반면에, 벡터 데이터베이스는 의미 기반의 유사도를 처리하죠. 더 빠르고, 더 간단하고, 사용자의 의도를 이해합니다.

이렇게 ‘API를 호출하는 것 같이’ 접근하는 방식은, 거대 언어모델의 Function Calling 기능하고도 자연스럽게 통합되어서, 더 빠른 실행, 더 적은 오류, 더 쉬운 통합을 가능하게 해 줍니다.

AI 시대에 SQL이 무너질 수 밖에 없는 이유

다들 잘 아시다시피, SQL은 ‘구조화된 세상’이라는 개념을 전제로 설계되었습니다. 그런데, AI 기술이 주도하는 미래는 비정형의 데이터, 의미의 이해, 지능형 검색이 핵심입니다 — 문제는, 이런 모든 요소는 SQL로서는 어떻게 다룰 수 있는 방법이 없다는 거죠.

현대적인 애플리케이션은 엄청난 양의 비정형 데이터를 다룹니다 - 이런 데이터에는 언어 모델에서 생성된 텍스트 임베딩, 컴퓨터 비전 시스템의 이미지 벡터, 음성 인식에서 생성된 오디오 지문, 텍스트·이미지·메타데이터를 결합한 멀티모달 표현 등이 포함되죠.

이런 데이터는 SQL이 잘 다루게끔 만들어진, ‘행(Row)’과 ‘열(Column)’의 구조에 깔끔하게 들어맞지가 않습니다. 이런 데이터는 고차원의 의미 공간 속에 벡터로 존재하는데, SQL은 이런 개념을 다루게끔 되어 있지가 않죠.

SQL + 벡터: 보기엔 좋아 보일 수 있지만, 결과물은 별로

그래서, 전통적인 데이터베이스들도, AI 시대에 살아남기 위해서 ‘벡터’를 처리하는 기능을 고육지책으로 붙여가고 있죠. 에를 들어서, PostgreSQL 같은 경우 <-> 연산자를 도입해서 벡터 유사도 검색을 지원합니다.

SELECT *   FROM items  ORDER BY embedding <-> query_vector  LIMIT 10;

겉으로 보기에는 똑똑한 접근방법처럼 보이지만, 사실 이건 근본적으로 잘못되어 있습니다. 왜냐하면, 완전히 다른 데이터 모델에 맞춰진 SQL 파서, 쿼리 옵티마이저, 트랜잭션 시스템을 벡터 연산에 억지로 끼워넣는 것이기 때문이죠.

그 결과도 처참하다고 할 정도라고 생각해요: 실제 벤치마크 데이터를 보면, 동일한 조건에서 Milvus가 PostgreSQL + pgvector보다 쿼리 지연 시간은 60% 더 낮고, 처리량은 4.5배나 더 높습니다.

왜 성능이 이렇게 나쁘게 나올까요? 그건 바로, 전통적인 데이터베이스의 경우 불필요하게 복잡한 실행 경로를 만들게 되기 때문입니다:

• 파서 오버헤드: 벡터 쿼리가 SQL 문법 검증을 거쳐야 함

• 전통적 옵티마이저의 한계: 관계형 조인에 최적화된 쿼리 플래너는 유사도 검색에 취약함

• 저장의 비효율성: 벡터를 BLOB으로 저장하면 인코딩/디코딩이 반복적으로 발생

• 부적절한 인덱스 구조: B-tree와 LSM 구조는 고차원 유사도 검색에 전혀 적합하지 않음

관계형 DB vs. AI용 벡터 DB: 이 둘은, 철학부터 다름

관계형/SQL DB와 AI용 벡터 DB는, ‘DB’라는 같은 이름을 가졌지만 사실은 그 탄생 배경과 철학, 모든 게 다른 두 가지입니다:

SQL로 벡터 연산을 처리하려고 한다면, 그건 드라이버로 망치를 두드리는 격이라고 할 수 있습니다 - 기술적으로 불가능한 건 아니지만, 도구가 잘못되었다는 것도 확실합니다.

벡터 데이터베이스: AI를 위해 처음부터 설계된 시스템

Milvus, Zilliz Cloud와 같은 벡터 데이터베이스는 ‘벡터 기능이 추가된 SQL DB’가 아니라, AI 네이티브 애플리케이션을 위해서 처음부터 설계된 지능형 데이터 시스템입니다:

1. 네이티브 멀티모달 지원
   
   AI 애플리케이션은 텍스트만 저장하는게 아니라, 이미지, 오디오, 동영상, 복합 문서 등 다양한 형식의 데이터를 다룹니다. 벡터 DB는 ColBERT, ColPALI 같은 다중의 벡터 구조도 자연스럽게 처리합니다.

2. 에이전트에 친화적인 아키텍처
   
   거대 언어 모델은 SQL 생성보다는 Function Calling에 강하죠. 벡터 DB는 파이썬 API 기반으로 설계되어 있어서 AI 에이전트와 완벽하게 통합됩니다. 벡터 검색, 필터링, 재정렬, 의미 강조 등 복잡한 작업도 단일 함수 호출로 수행할 수 있고, 별도의 쿼리 언어 번역 계층이 필요없습니다.

3. 의미 기반의 지능을 내장
   
   벡터 DB는 단순히 주어진 명령을 실행하는 게 아니라, 사용자의 의도를 이해합니다. AI 애플리케이션 및 에이전트와 함께 동작하면서 ‘키워드 매치’를 넘어서 진짜 의미 기반 검색을 수행합니다. ‘무엇을 어떻게 쿼리할지’뿐 아니라, ‘당신이 진짜 찾고자 하는 것이 무엇인지’를 파악한다는 거죠.

4. 속도뿐 아니라 ‘관련성(Relevance)’에 최적화
   
   거대 언어 모델처럼, 벡터 DB는 ‘속도’와 ‘의미적인 정확성’ 간의 균형을 중요하게 생각합니다. 메타데이터 필터링, 하이브리드 검색, 재정렬 알고리즘 등을 통해서 실제로 가치 있는 콘텐츠를 찾아냅니다.

데이터베이스의 미래는 ‘대화형’

벡터 데이터베이스는 우리가 데이터와 상호작용하는 방식을 근본적으로 바꾸고 있습니다.

이들은 관계형 DB를 대체하려는 게 아니라, AI 워크로드를 위해서 완전히 새로운 문제에 최적화된 시스템입니다. 마치 거대 언어 모델이 기존의 규칙 기반 시스템을 단순히 ‘업그레이드’하는 게 아니라, 인간-기계 상호작용의 방식 자체를 재정의한 것과 같은 거죠.

마찬가지로, 벡터 DB 역시 ‘정보를 찾고 사용하는 방식을 재정의’하고 있는 겁니다. ‘기계가 읽기 위해 만든 언어’에서 ‘인간의 의도를 이해하는 시스템’으로 이동하는 그 철학의 중심에 있는게 바로 벡터 DB인 거죠. 그렇게, 데이터베이스는 이제 단순하게 ‘쿼리를 실행하는 기계’를 넘어서, 맥락을 이해하고 인사이트를 능동적으로 제공하는 지능형 에이전트의 일부로 진화하고 있습니다.

오늘날 AI 애플리케이션을 구축하는 개발자들, 더 이상 SQL을 쓰고 싶어하지 않습니다. 필요한 것을 설명하면, 그 다음은 지능형 시스템이 알아서 수행해 주길 원하는 겁니다.

진짜 AI 데이터베이스를 써보고 싶다면?

이제 AI 애플리케이션을 본격적으로 개발, 도입하는 조직이라든지, 아니면 관계 데이터베이스의 확장 기능으로 추가된 기능을 사용해서 AI 애플리케이션을 개발했던 조직이라면, 더 늦기 전에 진짜 AI 애플리케이션을 확장성있게 지원하게끔 설계된 네이티브 벡터 데이터베이스를 테스트, 활용해야 할 겁니다.

Milvus나 Zilliz Cloud 외에도, Pinecone, Weaviate 등 다양한 네이티브 벡터 데이터베이스가 많은 고개들로부터 좋은 평가를 받고 있습니다.

저희 Zilliz도 AI 애플리케이션을 만들고자 하는 고개들에게 단순히 인프라를 제공하는 데서 그치지 않고, AI 스타트업과 기업 고객이 차세대의 AI 리더로 도약하는 데 기여하는 핵심 파트너가 되고자 노력하고 있으니, 관심있는 개발자 커뮤니티, 기업, 스타트업들의 많은 관심을 바랍니다.

*Zilliz의 엔지니어링 VP인 James Luan이 작성한 이 글의 원문은 이 곳에 게재되어 있습니다.

읽어주셔서 감사합니다. 재미있게 보셨다면 친구와 동료 분들에게도 뉴스레터를 추천해 주세요.