인터뷰 | “정확한 결과만으로는 부족하다” 구글 클라우드 DB 총괄이 전망한 생성형 AI 이후의 데이터베이스

생성형 AI에 대응하기 위해 데이터베이스는 어떻게 변화해야 하며, 데이터베이스는 LLM과 어떤 방식으로 통합돼야 할까. 이 질문은 세일레시 크리슈나무르티가 수년간 고민해온 핵심 주제다. 크리슈나무르티는 구글 클라우드의 데이터베이스 엔지니어링 부문 부사장으로, 구글 클라우드는 물론 구글 검색과 유튜브를 포함한 모든 구글 서비스의 데이터베이스 팀을 이끌고 있다. 또한 생성형 AI와 구글의 제미나이 모델을 데이터베이스 관리에 적용하는 프로그램도 총괄하고 있다.

파운드리 산하 언론사 인포월드는 최근 크리슈나무르티와 만나 데이터베이스와 LLM을 결합하는 과정에서의 기술적 과제, 자연어를 SQL로 변환하는 데 따르는 어려움, 이에 대한 구글 클라우드 데이터베이스 팀의 대응 전략, 그리고 생성형 AI 애플리케이션과 사용자의 요구에 맞춰 데이터베이스가 어떻게 진화하고 있는지에 대해 이야기를 나눴다.

Q: LLM과 운영 데이터 사이의 단절 문제를 이야기해보자. 이 간극을 어떻게 해소할 수 있을까.
A: LLM은 이미 방대한 세계 지식을 보유하고 있다. 기업 입장에서 보면 이를 기업 내부 데이터와 결합하는 것이 자연스러운 수순이다. 문서 코퍼스를 대상으로 한 정보 검색 문제는 비교적 다루기 쉽다. 하지만 문서를 넘어 데이터베이스에 저장된 데이터를 꺼내 문서 형태로 만들고, 이를 다시 검색 엔진에 전달해야 하는 단계부터 난도가 급격히 높아진다.

데이터는 강력한 권한 관리가 적용돼 있으며 반드시 보안이 보장돼야 한다. 데이터 유출과 접근 통제는 항상 고려 대상이다. 이 데이터는 비즈니스 핵심 애플리케이션의 중심에 있지만, 동시에 계속 변화한다. 데이터를 다른 코퍼스로 반복해서 추출하면 금세 최신성이 떨어진다. 접근 방식은 크게 두 가지로 볼 수 있다. 데이터베이스에서 다른 시스템으로 복제할 것인지, 아니면 데이터베이스에 연동해 직접 접근할 것인지의 문제다.

Q: 연동과 복제라는 두 가지 접근 방식은 어떻게 이해해야 할까.
A: 어느 수준에서 보면 연동과 복제는 서로 대응되는 개념이다. 둘 중 무엇을 선택할지는 어디에 적용하느냐에 따라 달라진다. 최근에는 데이터가 어디에 존재하는지에 대한 컨텍스트와 스키마, 데이터 표현 정보를 활용해 LLM이나 외부 오케스트레이션 메커니즘이 실시간으로 데이터 소스를 질의하고 답을 제공하는 방식이 늘고 있다. 이는 데이터베이스에만 국한된 흐름이 아니라 다양한 독점 시스템 전반에서 나타나는 메타 트렌드다.

슬랙은 이런 간극을 API로 메우는 대표적인 사례다. 다만 데이터베이스의 경우에는 여러 과제가 따른다. 업계 전반이 데이터베이스에 대해 매우 제한적인 접근만 허용하는 마이크로서비스 구조를 만들어왔기 때문이다. 이런 마이크로서비스를 그대로 LLM에 연결하면, LLM이 볼 수 있는 것은 극히 제한된 데이터 창에 불과하다.

보안 문제도 크다. 애플리케이션은 보통 시스템 인증 계정을 통해 데이터베이스에 연결된다. 반면 기업 사용자는 제미나이 포 엔터프라이즈 같은 서비스에 로그인한 사용자다. 사용자가 데이터베이스에 접근하려 할 때, 에이전트가 사용하는 시스템 인증 계정과 실제 사용자의 정체성이 다르기 때문에 보안을 정확히 맞추는 일이 쉽지 않다. 이런 문제들이 현장에서 자주 마주치는 과제다. 그렇다면 이 간극을 어떻게 메울 것인가. 우리에게도 이는 매우 중요한 문제이며, 해결하기 위한 여러 해법을 준비하고 있다.

Q: 앞서 언급한 해법에 대해 좀 더 구체적으로 설명해 달라. 구글은 어떤 접근을 내놓았나.
A: 목표는 운영 데이터베이스를 활성화해 에이전트 기반 애플리케이션에서 활용할 수 있도록 만드는 것이다. 이때 여러 선택지가 있는데, 가장 단순한 방식은 데이터베이스의 데이터를 LLM이 사용할 수 있도록 전달하는 도구를 제공하는 것이다.

구글은 데이터베이스용 MCP 툴박스라는 도구를 만들었다. 오픈소스로 공개됐으며, 내부적으로도 예상하지 못할 정도로 빠르게 확산됐다. 깃허브에서 1만 1,900여개의 즐겨찾기가 등록될 정도로 반응이 컸다. 이 도구는 구글의 자체 데이터베이스를 지원하는 데 그치지 않고 개방형으로 제공된다. 경쟁사 가운데서도 MCP 툴박스를 사용하겠다고 나선 곳이 적지 않다. LLM이나 LLM을 활용하는 다양한 오케스트레이션 시스템을 데이터베이스에 연결하는 매우 간편한 방법이다. 연결성과 보안 등 여러 문제를 한꺼번에 해결해 준다. 기본 제공 도구로 데이터베이스를 질의할 수 있을 뿐 아니라, 사용자가 맞춤형 도구를 추가할 수도 있다.

이 맞춤형 도구는 기본적으로 스캔 쿼리다. 특정 파라미터를 가진 템플릿 쿼리라고 보면 된다. 문제는 이 쿼리를 정확한 영어 문장으로 설명하는 일이 결코 단순하지 않다는 점이다. 엔지니어는 좋은 SQL 쿼리를 작성할 수 있지만, 이를 올바른 자연어 설명으로 풀어내는 능력은 또 다른 문제다. 이를 사람이 하거나 AI가 대신한다고 가정하면, AI는 사용자 요청에 맞는 도구를 선택하고 필요한 파라미터를 생성할 수 있다.

다만 보안 측면에서 고려할 사항은 남는다. 어떤 파라미터를 LLM이 설정할 수 있고, 어떤 것은 허용해서는 안 되는지에 대한 통제가 필요하다. 그럼에도 불구하고 이는 LLM을 운영 데이터베이스에 쉽게 연결하기 위한 가장 단순한 해법이다. 말하자면 문제를 푸는 가장 기본적인 단계다.

두 번째 접근은 자연어 설명을 바탕으로 SQL을 자동 생성하는 것이다. 맞춤형 도구를 일일이 작성하는 과정은 부담스럽지만, 이 도구들은 기존 API가 지나치게 좁아 생기는 공백을 메워준다. 새로운 API 계층을 구축하고 싶지는 않지만, 보다 근본적으로 개방된 작업을 하려면 다른 방법이 필요하다. 생성형 AI의 매력은 바로 이런 개방형 활용에 있다. 이를 위해서는 데이터베이스에 대해 보다 자유로운 형태의 쿼리를 실행할 수 있어야 하고, 동시에 보안도 확보해야 한다.

이 과정에서 핵심적으로 해결해야 할 문제는 정확성이다. 얼마나 정확한 쿼리를 생성할 수 있느냐가 핵심이다. 구글은 최근 자연어에서 SQL을 생성하는 분야 벤치마크에서 1위를 차지했다. 자연어를 SQL로 변환하는 기술은 계속해서 발전하고 있으며, 그 정확도 역시 빠르게 개선되고 있다.

Q: 자연어에서 SQL을 생성하는 정확도를 높이기 위한 요소는 무엇인가.
A: 핵심 요소는 컨텍스트다. 모델에 스키마와 메타데이터를 얼마나 충분히 전달하느냐에 따라 결과 품질이 크게 달라진다. 어떤 정보는 비교적 명확하지만, 그렇지 않은 경우도 많다. 예를 들어 이커머스 환경의 테이블을 보면 청구 주소와 배송 주소 컬럼이 따로 존재하는데, 둘 중 하나가 비어 있으면 두 주소가 동일하다고 간주하는 암묵적인 규칙이 있을 수 있다. 스키마를 설계한 사람들이 전제로 삼은 가정이다. 이런 가정을 알고 있다면 시스템에 대해 생성되는 SQL 쿼리의 정확도는 훨씬 높아진다. 이를 위해 스키마를 자동으로 추출하고, 자연어에서 SQL이 잘 동작하도록 더 풍부한 컨텍스트를 구축하는 여러 작업을 진행하고 있다.

모델 내부에서의 혁신도 병행하고 있다. 이것이 구글의 강점이다. 구글은 칩부터 인프라, 모델, 데이터베이스에 이르기까지 전 스택을 다룬다. 구글 딥마인드와 긴밀히 협력해 모델 자체의 성능을 지속적으로 개선하고 있다. 모델을 고도화하는 작업과 동시에 최적의 컨텍스트를 제공하면, 결과적으로 더 정확한 쿼리를 생성할 수 있다.

다음 단계에서 중요한 요소는 보안이다. LLM이 데이터베이스에 대해 어떤 쿼리든 실행할 수 있다면, 정보 유출을 어떻게 막을지가 가장 큰 과제가 된다. 이를 해결하기 위해 데이터베이스 내부에 파라미터화된 보안 뷰라는 기술을 구축했다. 이 기술은 필요한 보안 경계를 정의하고 보안 정책을 코드화해 적용한다. 그 결과 LLM이 어떤 쿼리를 생성하더라도, 로그인한 사용자가 접근 권한을 갖지 않은 정보는 볼 수 없도록 제어된다. 또한 정보 이론적인 관점에서도 접근 권한이 없는 데이터가 유출되지 않도록 설계돼 있다.

Q: 데이터베이스와 생성형 AI의 미래에 대해 오래 고민해온 것으로 안다. 앞으로 어디로 향하고 있다고 보나.
A: 이 부분에 대한 생각은 지난 몇 년간 많이 진화했다. 지난 50년 동안 데이터베이스, 특히 SQL 데이터베이스의 세계는 정확한 결과를 만들어내는 데 집중해 왔다. 흔히 데이터베이스의 역할은 하나라고 말해왔다. 데이터를 저장하고, 데이터를 잃지 않으며, 질문을 받으면 정확한 결과를 반환하는 것이다. 굳이 하나를 더 보태자면 안정성까지다. 정형 데이터를 다뤄왔기 때문에 모든 것은 정확성 중심이었다.

지금 가장 큰 변화는 더 이상 정형 데이터만 다루지 않는다는 점이다. 이제는 비정형 데이터도 함께 다뤄야 한다. 정형 데이터와 비정형 데이터를 결합하기 시작하면, 다음 단계에서는 정확한 결과만이 아니라 가장 관련성 높은 결과가 중요해진다. 이 지점에서 데이터베이스는 검색 엔진과 유사한 특성을 갖기 시작한다. 관련성과 순위가 중요해지고, 정보 검색 시스템에서 말하는 정밀도와 재현율 같은 개념이 핵심으로 떠오른다.

이를 가능하게 하는 중요한 요소 중 하나가 벡터 인덱싱이다. 데이터베이스에는 정형 데이터가 있지만, 그 외에도 비정형 데이터와 반정형 데이터가 존재한다. 일부 비정형 데이터는 데이터베이스의 컬럼과 행 안에 있을 수 있지만, 많은 데이터는 객체 스토리지에 저장된다. 이미지나 영상 데이터, 지리 정보, PDF 같은 것들이다. 객체 스토리지에 있어야 할 데이터는 그대로 남게 된다.

다만 고객들이 실제로 하고 있는 일은 객체 스토리지에 있는 데이터에서 벡터 임베딩을 추출해 데이터베이스와 함께 배치하는 것이다. 이렇게 하면 정형 데이터와 비정형 데이터를 결합한 질의를 할 수 있다.

이 문제를 다른 방식으로 풀려는 시도도 있었다. 예를 들어 데이터베이스와는 별도로 전용 벡터 저장소를 구축하는 방식이다. 하지만 실제 환경에서는 이런 시스템을 서로 엮어야 하기 때문에 제대로 작동시키기가 매우 어렵다. 사용자는 단순히 정보를 함께 활용하길 원한다.

대표적인 사례가 쇼핑몰 타겟(Target)이다. 타깃 온라인에 등록된 모든 상품과 관련 벡터 검색 기능이 알로이DB로 옮겨졌다. 타겟이 중요하게 본 요구사항은 이미지나 설명 기반 검색뿐 아니라 가격 정보도 함께 고려하는 것이었다. 가격 정보는 데이터베이스에 있지만 객체 스토리지에는 없다. 또한 로그인한 사용자와 가장 가까운 오프라인 매장에 해당 상품이 있는지도 중요한 요소였다.

Q: 또는 기준 거리가 16km로 설정될 수도 있겠다.
A: 그렇다. 그러면 추가적인 파라미터가 된다. 지리 정보 기반 조건, 즉 지오스페이셜 파라미터 조건이 되는 셈이다. 문제는 이런 조건들을 애플리케이션 레벨에서 하나하나 엮으려 하면 매우 어렵다는 점이다. 요청마다 각 조건의 선택도가 달라지기 때문에, 어떤 순서나 방식이 맞는지 판단하기가 쉽지 않다.

별도의 벡터 인덱스를 사용해 먼저 조회하면 상위 10개 결과를 얻을 수 있다. 이후 일반 데이터베이스에 가서 다른 조건을 모두 적용하면 결과가 하나도 남지 않을 수 있다. 이는 비즈니스에 도움이 되지 않는다. 타깃은 사용자가 클릭하고 실제로 구매로 이어질 수 있는 결과를 제공해야 하기 때문이다. 반대로 데이터베이스를 먼저 조회하면, 최근접 이웃 기반 벡터 검색과 결합하기에는 결과가 너무 많아질 수도 있다.

그래서 여러 인덱스를 하나의 시스템 안에서 함께 활용하는 방식을 찾았다. 이를 위해 적응형 필터 벡터 검색이라는 기술을 구축했다. 여러 인덱스 탐색을 결합해 항상 가장 짧은 시간 안에, 가장 높은 품질의 결과를 제공할 수 있도록 했다. 타깃닷컴에서의 성과는 상당했다. 검색 결과가 전혀 없는 페이지 수를 50% 줄였고, 비즈니스 성과는 약 20% 개선됐다.

개인적으로도 매우 인상적인 경험이었다. 그동안 정확한 결과에만 집중해온 이 업계의 세계가 바뀌었다는 점을 보여주는 사례였기 때문이다. 이제는 과거 구글 검색에서 맞춤법 교정을 만들던 방식으로 돌아가고 있다. 지금은 당연하게 쓰이지만, 20~25년 전에는 반복적인 개선을 거쳐 점점 나아진 결과였다. 새로운 유형의 애플리케이션을 만드는 사람들은 앞으로도 끊임없이 반복하고, 계속 개선해야 한다는 사고방식을 갖게 될 것이라고 본다.

Q: 이 지점에서 그동안 이야기해온 AI 네이티브 데이터베이스 개념으로 이어지는 것 같다. 구글이 보는 AI 네이티브 데이터베이스란 무엇인가.
A: 구글이 생각하는 AI 네이티브 데이터베이스는 벡터 검색, 전체 텍스트 검색, 그리고 다양한 정형 검색을 하나의 시스템에서 결합하는 하이브리드 검색 구조를 갖춘 데이터베이스다. 멀티모달 데이터베이스도 함께 등장하고 있다. 예를 들어 구글의 스패너는 데이터에 대해 그래프 인터페이스를 제공한다.

사용자의 기대치는 근본적으로 달라졌다. 더 이상 정확한 결과만을 묻지 않는다. 훨씬 범용적인 질문을 던지며, 모든 데이터가 함께 작동하길 원한다. 이를 위해 데이터를 연결하고 의미 있는 결과를 제공해 달라는 요구가 커지고 있다.

AI 검색은 AI 네이티브 데이터베이스의 핵심 요소다. 또 다른 중요한 요소는 AI 기능이다. LLM 기술을 데이터베이스 내부에 직접 적용해 질문할 수 있는 기능을 도입하고 있다. 예를 들어 데이터베이스 컬럼에 이미 저장된 값이나 필드, 텍스트를 대상으로 특정 작업을 수행할 수 있는 AI라는 SQL 함수를 제공하고 있다. 사용자가 관심 있는 브랜드 가운데 미국 브랜드만을 묻는 질문도 가능해진다.

데이터베이스는 정형 정보를 저장하지만, 그 안에는 중요한 텍스트 정보도 매우 많다. 이런 정보까지 포괄적으로 활용할 수 있도록 풍부한 기본 기능을 제공하는 것이 AI 네이티브 데이터베이스의 방향이다.

앞서 언급한 자연어 검색은 애플리케이션을 한층 풍부하게 만들었다. 이는 데이터베이스와도 잘 맞는다. 사람들이 자연어로 데이터베이스에 질문하기 때문이다. AI 네이티브 데이터베이스를 활용하면 그 결과의 품질과 가치는 더욱 높아진다.

다시 처음 질문으로 돌아가 보면, 가장 단순한 출발점은 기존과 유사한 형태의 맞춤형 도구다. 다만 애플리케이션을 작은 도구 단위로 분해해 쿼리를 실행하고, 이를 AI 에이전트와 연결했다는 점이 다르다. 이것이 첫 단계다.

다음 단계는 미리 예상하지 못한 질문을 던질 수 있도록 하는 것이다. 이를 위해서는 정확성과 보안이 필수다. 이 두 가지 측면에서 상당한 진전을 이뤘다. 아직 완전히 해결됐다고 말할 수는 없지만, 지금까지의 성과에 대해서는 매우 고무적으로 보고 있다. 마지막 단계는 데이터베이스 자체가 더 지능적으로 진화해, 다양한 유형의 데이터를 스스로 처리할 수 있게 되는 것이다.
dl-ciokorea@foundryco.com