기업 경영진은 AI가 자사 비즈니스를 근본적으로 재편할 것이라는 인식을 점점 더 강하게 갖고 있다. 그러나 많은 기업이 여전히 개념 검증 단계에 머물러 있다.

맥킨지의 ‘2025년 AI 현황(State of AI)’ 보고서에 따르면, 다양한 실험은 광범위하게 이뤄지고 있지만 실제로 의미 있는 비즈니스 가치를 창출하고 있는 기업은 소수의 ‘고성과 기업’에 불과하다. 응답자 23%는 조직 내 어딘가에서 에이전틱 AI 시스템을 확장 적용하고 있다고 답했지만, AI 에이전트 활용이 전반적으로 확산됐다고 보기는 어렵다.

보스턴컨설팅그룹은 AI 도입 과정에서 발생하는 장애 요인의 약 70%가 모델이 아닌 사람과 프로세스 문제라고 분석했지만, 여전히 열악한 데이터 인프라는 프로젝트 지연의 주요 원인으로 지목되고 있다.

데이터베이스 병목 현상

많은 엔지니어링팀이 여전히 트랜잭션 애플리케이션에 최적화된 아키텍처에 의존한다. 이는 정형·비정형 데이터와 실시간 이벤트 스트림을 함께 다루는 AI 시스템에 적합하지 않다. 이러한 레거시 아키텍처는 AI 도입을 늦추는 3가지 핵심 특성을 갖고 있다. 경직된 스키마와 사일로 구조, 시대에 뒤처진 로직, 그리고 AI를 기존 시스템에 덧붙이는 방식이다.

경직된 스키마와 사일로 구조

먼저, 현재의 ERP와 CRM 시스템은 경직된 스키마를 기반으로 구축돼 있으며, 각각 분리된 사일로 형태로 운영된다. 데이터 웨어하우스, 검색 인덱스, 벡터 스토어는 서로 다른 위치에 존재하고, 각기 다른 계약과 규칙을 따른다. 데이터 모델과 API가 서로 다르기 때문에, 한 시스템의 로직을 전제로 다른 시스템에 질문을 던지려면 별도의 변환이나 동기화 과정이 필요하다. 이들 시스템은 의미나 맥락적 연관성을 이해하도록 설계되지 않았기 때문에, AI 계층은 데이터 자체를 해석하기에 앞서 먼저 조각난 요소들을 이어 붙이는 역할부터 수행해야 하는 구조다.

서로 다른 데이터 저장 시스템은 각기 다른 추상화 방식을 제공한다.

시대에 뒤처진 로직

둘째, 시스템이 하루에 한 번씩 야간 배치 방식으로만 업데이트되는 경우 데이터 변경과 시스템 반영 사이에 시간적 공백이 발생한다. 이로 인해 에이전틱 AI는 이미 달라진 현실과는 동떨어진, 하루 전 데이터를 기반으로 추론을 수행할 수 있다. 이러한 인덱스 드리프트는 장기적인 문제로 이어진다. 벡터 스토어와 검색 인덱스가 운영 시스템이나 실제 현장의 상태와 점점 맞지 않게 되기 때문이다.

보안 정책 역시 어긋날 수 있다. 원천 시스템에서 권한이나 접근 제어가 변경되더라도, 해당 내용이 AI가 캐시하거나 복사해 사용하는 데이터에는 즉시 반영되지 않을 수 있다. 오래됐거나 일관되지 않은 맥락에서 시스템이 동작하면 정확도가 떨어지고, 이는 곧 규제 준수와 신뢰성에 심각한 영향을 미친다.

AI를 기존 시스템에 덧붙이는 방식

셋째, 기존 시스템이 AI를 전제로 설계되지 않았기 때문에 AI는 종종 별도의 사이드카 형태로 추가된다. 이 과정에서 보안, 데이터 계보, 관측 기능이 각각 분리돼 운영된다. 그 결과 감사와 컴플라이언스 대응이 복잡해지고, AI는 통합된 접근·사용·행위 추적의 일부가 아니라 별도의 기능 묶음으로 취급된다. 이로 인해 운영상 사각지대가 발생한다. 사고나 데이터 유출이 발생해도 이를 감지하지 못할 가능성이 커진다. AI 사이드카가 조직의 거버넌스 프레임워크 밖에서 작동하기 때문에 보안팀은 정책 위반 여부를 파악할 수 있는 가시성을 전혀 확보하지 못하는 상황에 놓인다.

이러한 문제는 랜드(RAND) 연구소의 보고서에서도 확인된다. 해당 보고서는 기업들이 AI를 신뢰할 수 있는 수준으로 운영하기 위해 필요한 데이터 품질, 데이터 계보, 접근 제어, 배포 인프라를 과소평가하는 경향이 있다고 지적한다. 이는 AI 프로젝트 실패의 근본 원인으로 작용하며, 성공적인 도입을 가로막는 요인으로 반복해서 나타나고 있다.

전통적인 데이터 경계를 허무는 에이전틱 AI

전통적인 데이터베이스 스택은 경계가 명확하다는 전제를 깔고 있다. 온라인 트랜잭션 처리(OLTP)는 여기, 온라인 분석 처리(OLAP)는 저기, 검색은 또 다른 곳이라는 식이다. 그러나 에이전틱 AI 활용례는 이런 경계를 무너뜨린다. 에이전트는 지속적인 읽기·쓰기 상호작용과 실시간 트리거가 필요하기 때문에, 검색 증강 생성(RAG)은 텍스트·벡터·그래프 관계를 가로지르는 저지연 조인을 일관된 보안 정책 아래에서 수행할 수 있어야 한다. 데이터를 별도 인덱스와 스토어로 옮겨 담는 레거시 패턴은 지연과 중복을 키우고, 위험도 크게 높인다.

흐름은 점점 한 방향으로 모이고 있다. 의미 기반 검색과 정책을 운영 데이터에 더 가까이 붙이는 것이다. 그래서 클라우드 플랫폼은 이제 운영 스토어에 벡터 검색과 하이브리드 검색을 연결하는 방식을 채택하고 있다. 몽고DB의 아틀라스 벡터 검색(Atlas Vector Search), 데이터브릭스의 모자이크 AI 벡터 검색(Mosaic AI Vector Search), 오픈서치의 뉴럴·벡터 검색(Neural/Vector Search)이 대표적인 사례다. 포스트그레스 커뮤니티가 pgvector 같은 확장으로 기능을 보강하는 이유도 여기에 있다.

다만 이런 ‘덧붙이는’ 방식이 네이티브 아키텍처와는 거리가 있으며, 고유의 문제도 함께 따른다는 점을 업계는 이미 경험으로 알고 있다. 이에 대응해 AI 네이티브 데이터베이스라는 새로운 흐름이 등장했고, 이런 간극을 메울 잠재력을 갖고 있다는 평가가 나온다.

그렇다면 엔지니어링팀은 AI 에이전트를 대비해 시스템을 어떤 기술적 단계로 준비할 수 있을까? 그리고 지금 시점에서 선택할 수 있는 옵션은 무엇일까?

AI와 에이전트를 위한 데이터 계층 준비

하나의 데이터베이스에서 다른 데이터베이스로 이전하는 작업은 결코 쉽지 않다. 구조적으로 복잡하고 위험 부담이 크며, 비용도 상당히 많이 든다. 명확한 비용 절감 효과가 있는 경우는 예외지만, 대규모 기업이 이미 특정 데이터베이스 스택에 깊이 의존하고 있다면 당장 이를 전환할 가능성은 크지 않다.

다만 그린필드 방식으로 시작하는 AI 네이티브 프로젝트라면 이야기가 다르다. 이 경우에는 보다 의도적으로 접근할 필요가 있으며, 에이전틱 시스템이 요구하는 특성을 이해하는 데이터베이스 모델을 선택하는 것이 중요하다. 에이전틱 시스템은 계획을 수립하고 도구를 호출하며, 상태를 다시 기록하고 여러 서비스 간 조정을 수행한다. 이를 위해서는 다음과 같은 조건이 필요하다.

• 단순한 대화 창이 아닌, 지속성과 검색 기능을 갖춘 장기 메모리
• 에이전트가 수행한 업데이트를 신뢰할 수 있도록 하는 안정적인 트랜잭션
• UI와 다른 에이전트를 동기화할 수 있도록 구독과 스트림을 지원하는 이벤트 기반 반응성
• 저수준 보안, 데이터 계보, 감사, 개인정보 식별 정보 보호를 포함한 강력한 거버넌스

주요 프레임워크 역시 이러한 데이터 요구사항을 강조하고 있다. 랭그래프(LangGraph)와 오토젠(AutoGen)은 데이터베이스 기반의 지속형 메모리를 추가했고, 엔비디아와 마이크로소프트의 레퍼런스 아키텍처는 에이전트 팩토리에서 데이터 커넥터, 관측성, 보안을 핵심 요소로 삼고 있다. 오라클은 최근 데이터베이스 릴리스에서 에이전트 도구를 코어 기능으로 포함시켰다. 이는 모델의 문제가 아니라 상태, 메모리, 정책의 문제라는 점을 분명히 보여준다.

AI를 위해 데이터 계층을 다시 구축할 때 ‘제대로 된’ 모습은 다음과 같다.

1. 먼저 적응성을 중심에 둔 설계가 필요하다. 관계형, 문서, 그래프, 시계열, 벡터 등 혼합 데이터에 대한 1급 지원과 유연한 스키마를 제공해, AI가 취약한 ETL 과정에 발목 잡히지 않고 엔티티, 관계, 의미를 자연스럽게 추론할 수 있어야 한다.
2. 다음으로 개방성을 명확히 선택해야 한다. 표준 인터페이스와 개방형 포맷, 오픈소스 참여는 팀이 최적의 임베딩 모델과 재정렬 도구, 거버넌스 체계를 조합할 수 있게 해준다. 업체 종속을 피할 수 있다는 점도 중요한 이점이다.
3. 마지막으로 조합 가능성을 받아들여야 한다. 실시간 구독과 스트림, 데이터에 가까운 위치에서 실행되는 함수, 통합된 보안 체계를 기본으로 구축해 검색, 추론, 실행이 하나의 신뢰 가능한 단일 데이터 원천을 기준으로 이뤄지도록 해야 한다.

어떤 모델이 사용례에 적합한가?

모든 조직은 서로 다른 워크로드에 최적화된 여러 데이터베이스를 함께 사용하고 있다. 대개는 오픈소스 데이터베이스 조합이다. 예를 들어 마이SQL과 포스트그레스는 트랜잭션 데이터를 처리하고, 몽고DB와 카우치베이스는 동적인 애플리케이션 데이터에 적합한 문서 스토리지를 제공한다. 이런 데이터베이스 조합은 사용 시나리오에 따라 적합한 도구를 선택하는 폴리글롯 퍼시스턴스 계층을 이룬다.

기업은 자사 요구에 맞는 데이터베이스 조합을 구축하는 데 막대한 투자를 해왔다. 그렇다면 기존 스택에 AI를 어떻게 접목할 수 있을까? 이 접근법이 과연 적절한 선택일까? 대안은 무엇이며, 에이전틱 AI를 도입하기 위해 기업은 데이터베이스 전면 재설계를 감수해야 하는 상황에 놓인 것일까?

벡터·하이브리드 검색을 통합한 운영 스토어

몽고DB 아틀라스, 데이터브릭스 모자이크 AI, 오픈서치는 근사 최근접 탐색과 하이브리드 검색을 데이터 가까이에 배치해 동기화 드리프트를 줄이는 접근을 취하고 있다. 포스트그레스는 SQL 표준화를 추진하는 팀을 위해 pgvector를 제공한다. 오라클 데이터베이스 23ai와 26ai는 네이티브 벡터 검색과 에이전트 빌더를 RDBMS 코어에 통합하며, 데이터 계층이 AI를 인식하는 방향으로 진화하고 있음을 보여준다.

이 방식은 단일 데이터 도구에만 의존하는 단순한 AI 프로젝트에는 잘 맞는다. 몽고DB만 쓰거나, 오픈서치만 사용하거나, 포스트그레스만 활용하는 경우가 이에 해당한다. 그러나 현실의 엔터프라이즈 AI 시스템과 에이전트는 대체로 여러 데이터 소스와 도구에 의존한다. 다양한 데이터베이스 전반에 걸쳐 데이터를 검색하고 가져오는 일은 여전히 쉽지 않다. 여러 데이터 모델을 함께 지원하고, 이들 전반을 대상으로 네이티브 검색을 수행할 수 있는 단일 저장소에 데이터를 보관할 수 있다면, 팀은 데이터에 내재된 힘을 보다 효과적으로 활용해 AI 시스템을 구축할 수 있다.

목적에 맞게 설계된 벡터 데이터베이스

파인콘, 위비에이트, 밀버스는 벡터 처리 규모와 지연 시간에 초점을 맞춘 데이터베이스다. 많은 기업은 대규모로 특화된 검색이 필요할 때 이들 시스템을 운영 데이터베이스와 함께 사용한다. 임베딩과 벡터 검색이 핵심이면서, 고성능과 고급 벡터 기능이 요구되는 대규모 워크로드라면 매우 효과적인 선택이다. 다만 별도의 데이터베이스 시스템을 추가로 관리하고 운영해야 한다는 점은 분명한 부담으로 남는다.

멀티모델 데이터베이스

이러한 수렴 흐름을 보여주는 구체적인 사례 중 하나가 서리얼DB(SurrealDB)다. 서리얼DB는 관계형, 문서, 그래프, 벡터 데이터를 하나의 엔진에서 다루는 오픈소스 멀티모델 데이터베이스다. ACID 트랜잭션과 행 단위 권한 제어, 실시간 구독을 위한 라이브 쿼리를 함께 제공한다. AI 워크로드 측면에서는 기업 거버넌스 정책을 집행하는 동일한 엔진에서 벡터 검색과 하이브리드 검색을 지원하며, LIVE SELECT(실시간 쿼리 구독)와 변경 피드 같은 이벤트 기반 기능을 통해 별도의 메시지 브로커 없이도 에이전트와 UI를 실시간으로 동기화할 수 있다.

이 접근법은 기록 시스템, 의미 인덱스, 이벤트 스트림 사이에서 발생하는 구성 요소 수를 줄여준다는 점에서 많은 팀에 실질적인 이점을 제공한다.

오늘날 AI 통합의 현실, 앞으로 나아가야 할 방향

전통적인 환경에서 AI를 활용하려 하면 상당한 불편함이 따른다. 엔지니어링팀은 동일한 데이터가 여러 사본으로 존재하는 상황을 자주 마주하게 되고, 이는 데이터 드리프트와 접근 제어 목록의 불일치로 이어진다. 임베딩 갱신 주기와 인덱스 재구성 작업은 지연 시간 급증과 품질 저하를 유발한다. 여기에 채팅, 검색, 실행 단계마다 서로 다른 정책 엔진이 적용되면서 감사 공백이 생긴다.

AI를 전제로 한 데이터 계층이 갖춰진다면 상황은 달라진다. 엔티티, 관계, 임베딩을 하나의 저장소에 함께 보관하고, 단일한 정책 모델로 이를 질의할 수 있다. 변경 사항을 야간 배치가 아닌 실시간 구독을 통해 에이전트 메모리에 즉시 반영할 수도 있다. 행 단위 보안과 데이터 계보를 소스 단계에서 강제함으로써, 모든 검색과 활용이 기본적으로 규정을 준수하도록 만들 수 있다.

이는 가상의 이야기만은 아니다. 공개된 사례를 보면 데이터 확산을 줄였을 때 실제 성과가 나타난다는 점이 확인된다. 라이브스폰서는 관계형 데이터와 문서 데이터를 통합해 로열티 엔진을 재구축했고, 쿼리 시간을 20초에서 7밀리초로 줄였다. 어스파이어 컴프스는 백엔드 구성 요소를 통합한 뒤 8시간 만에 사용자 70만 명 규모로 확장하는 데 성공했다. 이 밖에도 많은 기업이 데이터 통합과 AI 대응 역량 측면에서 의미 있는 개선 효과를 보고하고 있다.

AI 대응 아키텍처를 위한 원칙

AI 프로젝트가 멈추는 이유는 모델의 성능이 ‘충분하지 않아서’가 아니다. 야심에 비해 데이터 아키텍처가 따라오지 못하기 때문이다. 파일럿 단계에서 실제 수익으로 가장 빠르게 전환하는 길은, 검색·추론·실행이 하나의 통제된 실시간 단일 데이터 원천을 기준으로 이뤄지도록 데이터베이스 계층을 현대화하는 데 있다. 에이전틱 AI가 잠재력을 온전히 발휘하려면 몇 가지 필수적인 고려 사항이 전제돼야 한다.

• 검색과 관계 중심의 설계 : 그래프, 벡터, 키워드를 동등한 1급 요소로 다뤄야 한다. 지식 그래프와 RAG를 결합하는 방식은 설명 가능하고, 데이터 계보를 인식하는 답변을 제공하는 표준적인 접근으로 자리 잡고 있다.
• 상태·정책·연산의 공존 : 임베딩은 기록 시스템과 가까운 위치에 두고, 역할 기반 접근 제어와 행 단위 보안 같은 정책을 데이터베이스 내부로 밀어 넣어 데이터 이동 단계를 최소화해야 한다.
• 지속 가능한 메모리 확보 : 에이전트는 지속적으로 저장되는 메모리와 재개 가능한 워크플로우를 필요로 한다. 이는 랭그래프와 오토젠 같은 프레임워크, 그리고 엔비디아와 마이크로소프트가 제시하는 엔터프라이즈 ‘AI 팩토리’ 설계에서 핵심 요소로 다뤄진다.
• 개방형 빌딩 블록 우선 : pgvector, 위비에이트, 밀버스, 오픈서치 같은 오픈소스 옵션은 업체 종속 위험을 낮추고 학습 곡선을 단축한다. 특히 개방형 운영 데이터베이스와 함께 사용할 때 효과가 크다.

환경을 제대로 준비하는 일도 중요하다. 이를 위해서는 몇 가지 실질적인 단계부터 점검해야 한다.

우선 병목 지점부터 점검해야 한다. 애플리케이션과 벡터 스토어, 정책 계층 사이에 존재하는 불필요한 데이터 이동 경로를 하나씩 정리하고, 실제로 필요 없는 단계는 과감히 제거하는 작업이 출발점이다. 다음으로 통합된 AI 인지형 데이터 계층을 도입해야 한다. 기존 플랫폼을 진화시키든, 서리얼DB 같은 통합 엔진을 채택하든, 사일로를 해소하고 의미, 관계, 상태를 한곳에 모아야 한다.

마지막으로 비즈니스 영향을 밀리초와 비용 단위로 측정해야 한다. 지연 시간, 정확도, 생산성의 변화를 관찰하는 것이 중요하다. 실제 현장에서는 10밀리초 미만의 검색 지연과 스택 단순화가 기능 출시 속도와 비용 절감으로 이어지는 사례가 확인되고 있다. 라이브스폰서, 어스파이어, 그리고 버라이즌·삼성·텐센트 협업 사례 등 서리얼DB 고객의 공개 사례는 데이터 계층을 단순화했을 때 기술적 성과와 조직적 효과가 동시에 나타난다는 점을 보여준다.

데이터베이스는 전통적인 소프트웨어 애플리케이션에서 언제나 핵심 역할을 했다. 에이전틱 AI가 부상하면서 데이터베이스의 역할 역시 변화하고 있다. 이제 데이터베이스는 신뢰할 수 있는 에이전틱 시스템의 중심에서 ‘에이전틱 메모리’를 담당해야 한다. 질문은 에이전트를 위해 데이터를 다시 설계할 것인가가 아니라, 의사결정 속도를 끌어올리기 위해 에이전트에 필요한 메모리를 얼마나 빠르게 갖추느냐에 있다.
dl-itworldkorea@foundryco.com