최근 국내에서도 프론티어 모델 기반 서비스를 전사적으로 도입하는 사례가 하나둘 나타나고 있습니다. AI 투자에 적극적인 기업을 중심으로 AX 전략을 최우선 과제로 삼아 에이전틱 AI를 실제 업무에 적용하려는 움직임도 빨라지는 분위기입니다. 이처럼 AX의 구체적인 모습이 드러날수록 다시 중요성이 부각되는 것이 있습니다. 바로 데이터입니다.
아무리 성능이 뛰어난 모델과에이전트를 도입해도 필요한 데이터에 제때 접근하지 못하거나 데이터의 의미를 정확히 이해하지 못하면 실제 업무 성과로 이어지기어렵습니다. 데이터 없는 AX는 사상누각이라는 이야기가 다시 나오는 이유입니다. 특히 에이전틱 AI는 기존의 분석 시스템보다 데이터를 훨씬 더 직접적이고 실시간으로 활용합니다. 보고서를 만들기 위해 데이터를 모으는 수준을 넘어 주문과 재고, 고객 상태를 확인하고 다음 행동까지 결정해야 하기 때문입니다. 이 과정에서 기존 데이터 아키텍처가안고 있던 지연, 단절, 보안 문제가 더욱 분명하게 드러납니다.
관련해 이번 포스팅에서는 AX 시대의 요구에 맞춰 진화하고 있는 AI 네이티브 데이터베이스를 왜 주목해야 하는지 살펴보겠습니다. AlloyDB와 Spanner를 통해 기존 데이터 아키텍처의 한계를 어떻게 줄이고 에이전트가 신뢰할 수 있는 데이터 기반을 어떻게 마련할수 있는지 알아보겠습니다.
기존 데이터 아키텍처가 한계를 드러내는 이유
기업의 데이터는 운영 데이터베이스, 데이터 웨어하우스, 문서 저장소처럼 여러 시스템에 흩어져 있습니다. 사람이 보고서를 만들 때는 필요한 데이터를 모아 정리하는 데 시간이 다소 걸려도 업무를 진행할 수 있었습니다. 그러나 에이전트가 실시간으로 주문과 재고, 고객 상태를 확인하고 다음 작업까지 수행해야 한다면 상황은 달라집니다.
기존 구조에서는 데이터를 별도의 AI 시스템으로 옮기는 동안 원본 데이터가 계속 바뀔 수 있습니다. 에이전트가 오래된 복사본을 참조하면 현재의 재고나 계약 상태와 다른 판단을 내릴 수 있습니다. 또한 데이터베이스의 컬럼과 값에 담긴 비즈니스 의미를 충분히 이해하지 못하면, 문법적으로는 맞는 질의를 만들더라도 업무적으로는 잘못된 답을 내놓을 수 있습니다.
보안과 거버넌스도 다시 설계해야 합니다. 원본 데이터베이스에서 적용하던 접근 권한과 테넌트 분리를 벡터 저장소나 별도의 AI 계층에 다시 구현해야 하기 때문입니다. 데이터 사본이 늘어날수록 어떤 시스템에 어떤 민감 정보가 있는지 파악하는 일도 어려워집니다. 결국 에이전틱 AI가 요구하는 것은 단순히 더 많은 데이터가 아닙니다. 최신 상태를 유지하면서도 데이터의 의미와 관계, 접근 권한까지 함께 보존하는 기반이 필요합니다. AI 네이티브 데이터베이스는 이러한 요구에 맞춰 검색과 분석, AI 처리를 데이터베이스 가까이에서 수행하는 방향으로 진화하고 있습니다. 그렇다면 구글 클라우드의 AI 네이티브 데이터베이스는 기존 구조의 한계를 어떻게 넘어설까요?
AlloyDB는 AI 검색과 분석을 어떻게 데이터베이스 안으로 가져오는가?
AlloyDB는 PostgreSQL 호환성을 유지하면서 관계형 데이터와 벡터 검색, 전체 텍스트 검색, 분석 기능을 함께 제공합니다. 기존PostgreSQL 애플리케이션을 운영하는 조직이 개발 경험과 애플리케이션 구조를 크게 바꾸지 않고 AI 기능을 확장할 수 있다는 점이 특징입니다.
검색을 예로 들어보겠습니다. 키워드 검색은 정확한 상품명과 규격을 찾는 데 강하지만 사용자가 표현한 의도와 맥락을 놓칠 수 있습니다. 반면에 벡터 검색은 의미가 비슷한 결과를 찾는 데 유리하지만 가격, 재고, 규격처럼 정확한 조건을 충분히 반영하지 못할 수 있습니다. AlloyDB는 두 방식을 결합한 하이브리드 검색을 SQL 안에서 구현할 수 있습니다.
예를 들어 사용자가 ‘여름 휴양지에서 입기 편한 셔츠’를 찾는다면 키워드가 정확히 일치하는 상품만 검색하는 데서 그치지 않습니다. 벡터 검색으로 린넨이나 면처럼 의도에 맞는 소재를 찾고 관계형 필터로 가격과 재고, 사이즈 같은 조건을 함께 적용할 수 있습니다. 검색을 위해 관계형 데이터와 벡터 데이터를 서로 다른 시스템에 나눠 저장할 필요가 줄어드는 것입니다.
AI 함수를 활용하면 검색 결과의 순위를 다시 정하거나 텍스트를 요약하고 감성을 분석할 수도 있습니다. 시계열 데이터에는 TimesFM 기반 예측 기능을 적용해 과거 데이터를 바탕으로 향후 수요를 전망할 수 있습니다. 애플리케이션이 데이터를 여러 서비스로 옮기지 않고 데이터베이스의 질의 흐름 안에서 검색과 분석, AI 처리를 이어갈 수 있다는 의미입니다.
온프레미스나 다른 클라우드에서 같은 기능을 활용해야 하는 조직은 AlloyDB Omni도 검토할 수 있습니다. 데이터 주권과 규제, 기존 인프라와의 연계 때문에 모든 데이터를 퍼블릭 클라우드로 옮기기 어려운 경우에도 AI 네이티브 데이터베이스를 적용할 수 있는 선택지를 넓혀 줍니다. 살펴본 바와 같이 AlloyDB가 PostgreSQL 기반 워크로드에 AI 검색과 분석을 결합하는 데 강점이 있다면 Spanner는 더 큰 규모와 복잡한 관계를 다뤄야 하는 환경에 초점을 맞춥니다.
Spanner는 대규모 AI 애플리케이션에 어떤 기반을 제공하는가?
Spanner는 글로벌 트랜잭션 처리와 수평 확장, 높은 가용성을 제공하는 데이터베이스입니다. 여기에 전체 텍스트 검색과 벡터 검색, 그래프 기능을 결합해 대규모 서비스의 운영 데이터와 AI 검색을 같은 기반에서 다룰 수 있도록 확장하고 있습니다.
특히 그래프 기능은 데이터 사이의 관계를 에이전트에게 제공하는 데 유용합니다. 벡터 검색은 의미가 비슷한 문서를 찾을 수 있지만 고객과 계약, 상품, 조직 사이에 이미 정의된 명확한 관계까지 항상 정확히 표현하지는 못합니다. Spanner Graph는 관계형 데이터 위에 그래프 모델을 정의해 별도의 데이터 복사 없이 이러한 연결 구조를 탐색할 수 있도록 합니다.
예를 들어 특정 고객과 관련된 계약, 주문, 상담 기록을 찾는다고 가정해 보겠습니다. 벡터 검색으로 의미가 비슷한 문서와 기록을 찾은 뒤 그래프를 따라 해당 고객과 실제로 연결된 계약과 담당 조직, 상품 정보를 확장해 확인할 수 있습니다. 에이전트가 단순히 비슷한 정보를 찾는 데서 그치지 않고, 기업이 이미 알고 있는 관계를 바탕으로 맥락을 넓힐 수 있는 것입니다.
검색 인덱스가 원본 데이터와 트랜잭션 일관성을 유지한다는 점도 중요합니다. 에이전트가 데이터를 변경한 직후 다시 검색해도 최신 상태를 확인할 수 있습니다. 읽기와 쓰기를 여러 단계로 이어가는 에이전트 워크플로우에서는 이전 상태의 데이터가 검색 결과에 남아 있으면 다음 행동까지 잘못 이어질 수 있습니다. Spanner는 이러한 데이터 지연으로 인한 오류를 줄이는 데 도움을 줍니다.
정리하자면 AlloyDB와 Spanner는 서로 다른 환경을 겨냥하지만 공통된 방향을 보여줍니다. 데이터를 별도의 AI 시스템으로 계속 복사하기보다, 운영 데이터 가까이에서 검색과 분석, 관계 탐색을 수행하도록 만드는 것입니다. 이는 에이전트가 더 많은 데이터를 사용하는 차원을 넘어, 최신 상태와 업무 맥락을 함께 이해하도록 만드는 기반이라고 볼 수 있습니다.
AI 네이티브 데이터 기반을 만들고 싶다면?
그렇다면 기업은 AI 네이티브 데이터 기반을 어떻게 준비해야 할까요? AI 네이티브 데이터베이스로의 전환은 제품을 바꾸는 일에서 끝나지 않습니다. 어떤 데이터를 데이터베이스 안에서 검색하고 분석할지, 어떤 작업은 외부 모델과 연결할지, 에이전트가 어떤 권한으로 접근할지 함께 정해야 합니다.
모든 데이터를 한 번에 옮기기보다 검색과 추천, 상담, 운영 분석처럼 효과를 확인하기 쉬운 업무부터 시작하는 편이 현실적입니다. 대표 질의와 기대 결과를 정하고, 하이브리드 검색과 그래프, AI 함수가 실제 업무 정확도와 비용에 어떤 영향을 주는지 검증해야 합니다.에이전트가 참조할 비즈니스 의미와 접근 권한도 이 단계에서 함께 설계해야 합니다.
메가존소프트는 현재 데이터베이스와 AI 애플리케이션 구조를 분석해 AlloyDB와 Spanner 적용이 적합한 업무를 제안할 수 있습니다. 더 자세한 내용이 궁금하다면 메가존소프트 문의 포털을 통해 상담을 남겨 주세요.
