AI 에이전트 메모리를 SQL 하나로 구축하기: TiDB로 벡터·키워드·트랜잭션 통합

핵심 메시지

• AI 에이전트는 폭발적 부하, 대규모 동시성, 끊임없는 맥락 회상이라는 세 가지 이유로 기존 앱과 다르게 데이터베이스를 사용한다.
• 흔한 방식은 일반 DB, 벡터 DB, 검색 엔진에 ETL 접착 계층까지 세 개 이상을 운영하는 것이라 비용·장애·데이터 불일치 문제가 생긴다.
• TiDB는 분산 SQL 데이터베이스로, MySQL 호환에 트랜잭션·분석·벡터·전문 검색을 한 테이블에서 처리한다.
• 데모에서는 삽입 시 자동 임베딩, 의미 검색, 키워드 검색, RRF 기반 하이브리드 검색, 여러 테이블에 걸친 ACID 트랜잭션을 SQL만으로 보여 준다.
• 스케일 투 제로, 데이터베이스 브랜칭, 자원 제어로 에이전트 워크로드에 맞게 비용과 확장을 최적화한다.

쉽게 이해하기

핑캡(PingCAP)의 솔루션 엔지니어가 AI 에이전트의 기억(메모리)을 오직 SQL만으로 구축하는 방법을 TiDB로 시연한다. 발표는 에이전트가 왜 데이터베이스를 다르게 쓰는지에서 출발한다. 워크로드가 폭발적으로 몰렸다 비었다 하고, 수백만 개 에이전트가 각자 상태를 갖고 동시에 돌며, 매 단계마다 직전 맥락을 회상해야 한다는 세 가지가 핵심이다.

오늘날 많은 팀이 쓰는 방식은 채팅 기록·계정을 담는 일반 DB, 의미 검색용 임베딩을 담는 벡터 DB, 정확한 단어 매칭을 위한 검색 엔진, 그리고 이 셋을 동기화하는 ETL·메시지 버스·크론 잡 같은 '접착 계층'을 함께 운영하는 것이다. 결국 데이터베이스 세 개, 청구서 세 개, 고장 날 곳 세 개가 생기고 데이터는 늘 어긋난다.

발표자는 에이전트 환경에서 이 구조가 깨지는 네 가지 지점을 짚는다. 벡터 인덱스가 본 DB보다 몇 초 뒤처져 낡은 정보를 읽는 '오래된 데이터', 방금 쓴 주문을 곧바로 조회하면 아직 반영이 안 돼 '주문이 없다'고 답하는 '쓰기 후 읽기' 문제, 환불 처리 도중 이메일 서비스가 죽어 상태가 어긋나는 '부분 쓰기', 그리고 에이전트 수에 시스템 수를 곱한 만큼 폭증하는 '커넥션 팬아웃'이다.

TiDB는 노드를 추가해 수평 확장하는 분산 SQL 데이터베이스이며, MySQL과 호환돼 기존 드라이버·ORM·도구를 그대로 쓸 수 있다. 트랜잭션·분석·벡터 검색·전문 검색을 같은 데이터베이스에서 처리하고, 매니폴드·핀터레스트·디파이 등 실제 프로덕션에서 쓰인다고 소개한다.

데모는 하나의 테이블로 진행된다. 1,536차원 벡터를 담는 임베딩 컬럼을 '생성 컬럼'으로 두어, 행이 삽입될 때마다 embed_text 함수가 애저 오픈AI 배포를 호출해 파이썬 파이프라인 없이 임베딩을 자동 생성·저장한다. 이어 의미 검색, 전문(키워드) 검색, 두 검색을 RRF(상호 순위 융합)로 결합한 하이브리드 검색, 그리고 여러 테이블에 걸친 ACID 트랜잭션을 차례로 보여 준다. 발표자는 스케일 투 제로, 밀리초 단위 데이터베이스 브랜칭, 자원 제어 같은 특성으로 에이전트 워크로드에 맞춰 비용과 확장을 최적화한다고 정리한다.

주요 인사이트

• 에이전트 메모리를 위해 DB 세 개와 접착 계층을 유지하면 비용·장애·데이터 불일치가 스케일에서 한꺼번에 터진다.
• 벡터 인덱스 지연으로 인한 오래된 데이터와 '쓰기 후 읽기' 문제는 에이전트가 실시간으로 상태를 회상해야 하기에 특히 치명적이다.
• 삽입 시 embed_text 함수로 임베딩을 자동 생성하면 별도 파이썬 파이프라인 없이 텍스트만 넣어도 벡터가 채워진다.
• 진짜 하이브리드 검색은 벡터 검색과 키워드 검색을 각각 돌린 뒤 RRF로 순위를 융합하는 것으로, 두 검색에서 모두 높은 행이 상위에 온다.
• 스케일 투 제로와 데이터베이스 브랜칭 덕분에 유휴 에이전트는 비용이 들지 않고 에이전트마다 격리된 작업 공간을 밀리초 만에 얻는다.

자주 묻는 질문

관련 AI 소식