서론: 당신이 만드는 AI는 '어제의 일'을 기억하고 있습니까?

"대단해, 마치 인간과 대화하는 것 같아!"

처음 대규모 언어 모델 (LLM)과 대화했을 때, 많은 사람이 그렇게 느꼈을 것입니다. 하지만 그 AI 어시스턴트에게 다음 날 같은 화제를 던져보십시오. "어제 일 말인데..."라고 말입니다. 아마도 AI는 "죄송합니다, 이전 대화를 기억할 수 없습니다"라고 대답할 것입니다. 이것이 현실입니다.

현재의 AI, 특히 AI 에이전트 개발에 있어 가장 뿌리 깊고도 매력적인 과제, 그것이 바로 **「기억」**의 문제입니다. 인간처럼 대화를 거듭하고, 사용자를 이해하며, 함께 성장해 나가는 AI 에이전트. 그런 미래상을 실현하기 위해서는 세션이 끊기면 모든 것을 잊어버리는 스테이트리스 (Stateless)한 존재여서는 안 됩니다.

본 기사에서는 이 **「AI의 장기 기억」**이라는 장대한 테마에 도전합니다. 단순한 대화 로그 저장과 같은 소박한 접근 방식에서 출발하여, 왜 SQLite와 같은 기존의 파일 기반 DB로는 한계가 오는지, 그리고 벡터 검색을 이용한 RAG (Retrieval Augmented Generation)가 직면하는 과제를 파헤쳐 봅니다.

그 위에서, AI 에이전트의 "뇌"라고도 할 수 있는 장기 기억 시스템이 충족해야 할 요구사항을 정의하고, 그 해답으로서 MySQL 호환 분산 데이터베이스인 TiDB, 특히 그 Serverless 버전이 어떻게 강력한 선택지가 될 수 있는지 구체적인 아키텍처와 사상을 곁들여 철저히 해설합니다.

이것은 단순한 기술 해설이 아닙니다. AI 에이전트의 정체성을 어떻게 형성해 나갈 것인가라는, 미래의 AI 개발에 있어서의 **「사상」**을 묻는 여정이기도 합니다.

AI에서의 「기억」 계층: 단기 기억 vs 장기 기억

AI의 기억 문제를 생각할 때, 우선 「기억」을 두 가지 계층으로 나누어 이해하는 것이 필수적입니다.

단기 기억 (Short-Term Memory)

이것은 우리가 평소 LLM과 대화할 때 가장 의식하는 기억입니다. 구체적으로는 API 요청의 프롬프트 내에 포함된 대화 이력을 가리킵니다.

• 특징: 수천~수만 토큰 (컨텍스트 윈도우 (Context Window)의 크기에 의존)의 정보를 보유할 수 있음.
• 역할: 직전의 사용자와의 주고받음, Function Calling의 결과 등을 보유하여 문맥에 맞는 응답을 생성하기 위해 사용됨.
• 과제: 휘발성이라는 점. API 호출이 종료되면 그 기억은 완전히 사라집니다. 컨텍스트 윈도우의 크기에 상한이 있으며, 비용 (토큰 수)도 늘어납니다.

장기 기억 (Long-Term Memory)

이것이야말로 AI 에이전트가 진정으로 퍼스널한 존재로 진화하기 위한 열쇠입니다.

• 특징: 세션이나 시간을 초월하여 영속화되는, 외부 데이터베이스에 저장된 정보.
• 역할: 과거의 모든 대화, 사용자의 취향, 중요한 약속, 공유된 파일의 내용 등을 축적함. AI의 「개성」이나 「경험」을 형성하는 기반이 됨.
• 과제: 어떻게 효율적으로 저장하고, 그리고 필요할 때 어떻게 정확하게 추출할 것인가 (Retrieval). 이것이 본 기사의 핵심 테마입니다.

이 두 가지 기억을 어떻게 심리스 (Seamless)하게 연계하고 구분하여 사용할 것인가. 그것이 인간다운 자연스러운 대화 흐름과 지속적인 학습 능력을 가진 AI 에이전트를 구축하는 데 있어 설계의 핵심이 됩니다.

모든 것은 여기서 시작되었다: SQLite와 벡터 검색의 한계

많은 개발자가 AI 에이전트의 프로토타입을 만들 때, 우선 다음과 같은 구성으로 시작하지 않을까요?

• 사용자와의 대화 이력을 SQLite와 같은 파일 기반 데이터베이스에 저장한다.
• 대화 텍스트를 OpenAI의 Embedding API 등으로 벡터화 (Embedding)한다.
• FAISS나 ChromaDB와 같은 라이브러리를 사용하여 생성된 벡터를 로컬 인덱스 파일에 저장한다.
• 사용자의 새로운 질문과 관련된 과거의 대화를 벡터 검색으로 찾아내어 프롬프트에 주입한다 (RAG).

이 구성은 수중에 빠르게 테스트해 볼 수 있는 훌륭한 첫걸음입니다. 하지만 실운용을 염두에 두는 순간, 이 심플한 아키텍처는 여러 가지 엄격한 현실에 직면합니다.

왜 SQLite로는 어려워졌는가?

확장성(Scalability)의 벽: SQLite는 서버리스 함수(Vercel, AWS Lambda 등)와 같은 스테이트리스(Stateless) 환경과 치명적으로 상성이 좋지 않습니다. 동시에 여러 쓰기 작업이 발생하면 락(Lock)이 빈번하게 발생하여 성능이 급격히 저하됩니다. 사용자가 1명에서 10명, 100명으로 늘어남에 따라 이 문제는 더욱 뚜렷해집니다.

데이터 관리의 번거로움: 데이터베이스 파일과 벡터 인덱스(Vector Index) 파일이 별도로 존재하기 때문에 백업, 복구(Restore), 일관성 보장과 같은 운영 태스크가 갑자기 복잡해집니다.

고급 쿼리(Query)의 어려움: "사용자 ID가 A이고, 1주일 이내에 나누었던 '프로젝트 X'에 관한 대화"와 같이, 구조화된 데이터(메타데이터)와 벡터 데이터를 조합한 검색(하이브리드 검색, Hybrid Search)을 효율적으로 수행하기가 어렵습니다.

단순한 RAG의 함정

벡터 검색은 마법이 아닙니다. 단순히 과거의 모든 대화 로그에서 유사한 벡터를 가져오는 것만으로는 기대하는 수준의 "문맥에 맞는 기억"을 불러낼 수 없습니다.

• 노이즈 문제: 과거의 무의미한 대화나, 단어만 비슷할 뿐 문맥은 전혀 다른 정보가 검색 결과 상위에 나타나 오히려 LLM의 응답 정확도를 떨어뜨릴 수 있습니다.
• 시간성 결여: AI에게 "언제 발생한 정보인가"는 매우 중요합니다. "어제의 약속"과 "1년 전의 잡담"은 그 가중치가 완전히 다릅니다. 단순한 코사인 유사도(Cosine Similarity) 검색으로는 이러한 시간적 중요도를 고려할 수 없습니다.

이 "일단 돌아가기만 하는" 구성의 한계야말로 차세대 AI 데이터 기반을 고민하는 출발점이 됩니다.

AI의 뇌를 설계하다: 이상적인 장기 기억 시스템의 요구사항

SQLite에서의 실패로부터 배워야 할 점은, AI 에이전트의 장기 기억 시스템이 단순한 "데이터 저장소"가 아니라 그 자체로 지능(Intelligence)을 가져야 한다는 것입니다. 여기서는 이상적인 시스템의 요구사항을 정의합니다.

• 통합 데이터 스토어 (Unified Data Store): 대화 이력, 사용자 프로필과 같은 **구조화된 데이터(Structured Data)**와 그 텍스트의 의미를 포착하는 **임베딩 벡터(Embedding Vector)**를 단일 데이터베이스 내에서 심리스(Seamless)하게 다룰 수 있어야 합니다. 데이터의 일관성과 관리의 단순함이 중요합니다. 더 이상 DB 파일과 인덱스 파일 간의 동기화 오류로 고민하고 싶지 않을 것입니다.

• 무한한 확장성 (Scalability): 사용자 수나 데이터량의 증가에 따라 성능이 선형적으로 향상되는 **수평적 확장성(Horizontal Scalability)**을 갖추어야 합니다. 인프라 걱정 없이 애플리케이션 로직에만 집중할 수 있어야 합니다.

• 고급 검색 능력 (Advanced Retrieval):

  • 하이브리드 검색 (Hybrid Search): 빠른 벡터 검색은 물론, 사용자 ID나 타임스탬프와 같은 메타데이터 필터링, 나아가 키워드 검색(예: BM25)을 조합하여 검색 정확도를 극한까지 높일 수 있어야 합니다.
  • 시간적 고려: "최근 정보를 우선한다"와 같은 시간 감쇠(Time Decay) 개념을 쿼리 레벨에서 구현할 수 있어야 합니다.

• 저비용 및 운영 용이성 (Cost-Effectiveness & Operability): 특히 스타트업이나 개인 개발자에게 비용은 생존 문제입니다. 관대한 무료 티어(Free Tier)가 있고 사용량에 따라 비용을 최적화할 수 있는 **서버리스 아키텍처(Serverless Architecture)**가 바람직합니다. 또한 백업과 스케일링이 자동화된 매니지드 서비스(Managed Service)여야 합니다.

사상으로서의 MCP (Model-Controller-Periphery)

여기서 AI 에이전트 아키텍처에 관한 "사상"을 언급해 두겠습니다.

복잡한 AI 에이전트는 **MCP (Model-Controller-Periphery)**라는 개념으로 정리할 수 있습니다.

• Model (모델): LLM 본체. 사고와 추론을 담당하는 "뇌".
• Controller (컨트롤러): 에이전트의 실행 루프. Model의 지시를 받아 어떤 도구(Periphery)를 사용할지 판단하고 실행하는 "신경계".
• Periphery (주변 장치): 도구와 API, 그리고 기억 장치. Model이나 Controller가 이용하는 "손발" 또는 "외부 기억".

우리가 설계하고자 하는 장기 기억 시스템은 이 Periphery(주변 장치)의 핵심입니다. 강력하고 유연한 기억 장치를 가짐으로써, Controller는 더욱 고도화된 판단을 내릴 수 있게 되고, Model은 더욱 풍부한 컨텍스트 (Context)를 바탕으로 사고할 수 있게 됩니다.

해답편: TiDB Serverless가 AI의 기억 문제를 어떻게 해결하는가

앞 장에서 정의한 이상적인 요구사항. 이를 놀라울 정도로 높은 수준으로 충족하는 것이 바로 TiDB Serverless입니다.

TiDB는 MySQL과 높은 호환성을 가진 오픈 소스 분산 데이터베이스입니다. 온프레미스(On-premise)에서도 클라우드에서도 동작하지만, 특히 TiDB Cloud가 제공하는 Serverless Tier는 AI 에이전트 개발에 혁명을 가져올 잠재력을 품고 있습니다.

왜 TiDB Serverless가 최적해인가?

• 네이티브 (Native) vector 타입 지원 및 통합 관리 - 이것이 가장 큰 게임 체인저입니다. TiDB에서는 테이블의 컬럼으로서 VECTOR 타입을 네이티브하게 지원합니다. 이를 통해 다음과 같이 직관적이고 아름다운 테이블 설계가 가능해집니다.

CREATE TABLE conversations ( id BIGINT PRIMARY KEY AUTO_RANDOM, user_id VARCHAR(255) NOT NULL, message TEXT NOT NULL, message_embedding VECTOR<FLOAT>(1536), created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, INDEX (user_id, created_at) );

• 대화 텍스트(message)와 그 벡터 표현(message_embedding)이 동일한 레코드 내에 공존합니다. 이를 통해 구조화 데이터와 벡터 데이터의 완전한 통합이 실현됩니다. 데이터 추가 또한 익숙한 INSERT 문 하나로 해결됩니다.

• 하이브리드 검색이 SQL로 완결 - 벡터 검색 전용 인덱스(IVF_FLAT)와 기존의 B-Tree 인덱스를 동일한 테이블에 생성할 수 있습니다. 이를 통해 "A님의 최근 1주일간의 대화 중에서, 오늘의 질문과 가장 관련성이 높은 것"을 찾는 것과 같은 고도화된 하이브리드 검색을 단 하나의 SQL 쿼리로 실행할 수 있습니다.

SELECT id, message, L2_DISTANCE(message_embedding, ${query_embedding}) AS distance FROM conversations WHERE user_id = 'user_A' AND created_at >= NOW() - INTERVAL 7 DAY ORDER BY distance LIMIT 5;

• 무한한 수평 확장성(Horizontal Scalability)과 MySQL 호환성 - TiDB는 내부적으로 데이터를 자동으로 샤딩(Sharding)하며, 부하에 따라 스케일 아웃(Scale-out)합니다. 개발자는 단일 거대 MySQL 데이터베이스를 다루는 느낌으로 확장성의 혜택을 누릴 수 있습니다. MySQL 호환이기 때문에 기존의 모든 언어 드라이버, ORM (Prisma, GORM, SQLAlchemy 등)을 그대로 이용할 수 있어 학습 비용이 최소화됩니다.

• 압도적인 가성비 - TiDB Serverless에는 매우 관대한 무료 티어(Free Tier)가 마련되어 있어, 프로토타이핑이나 소규모 운영이라면 완전히 무료로 시작하는 것이 가능합니다. 요청이 없는 시간에는 컴퓨팅 리소스가 제로(0)로 스케일 다운(Scale-down)되므로, 고정비를 걱정할 필요 없이 사용한 만큼만 지불하면 됩니다.

실운영에서 발견한 과제와 RAG 최적화의 고된 세계

TiDB Serverless라는 강력한 무기를 손에 넣었다고 해서 싸움이 끝나는 것은 아닙니다. 오히려 여기서부터가 진정한 RAG 최적화, 즉 AI의 기억을 "키워나가는" 프로세스의 시작입니다.

과제 1: 검색 노이즈와의 싸움

Time-weighted Decay (시간 가중 감쇠): 단순한 벡터 검색(Vector Search)에서는 1년 전의 관련성이 높아 보이는(것처럼 보이는) 대화가 어제의 중요한 대화보다 상위에 노출될 수 있습니다. 이를 방지하기 위해 쿼리(Query)나 애플리케이션 로직에서 "새로운 정보일수록 가중치를 높게 설정"하는 알고리즘을 구현합니다. SQL의 CASE 문이나 애플리케이션 측에서의 스코어 재계산 등이 유효합니다. -
요약을 통한 기억의 계층화: 모든 생 로그(Raw Log)를 검색 대상으로 삼는 것이 아니라, 정기적으로(예: 하루의 끝에) 대화를 LLM에 요약하게 하여 그 **"요약의 벡터"**를 별도로 저장합니다. 먼저 요약을 검색하고, 관련 기간이 특정되면 그다음 해당 기간의 생 로그를 상세히 검색하는 계층적 접근 방식이 정밀도 향상으로 이어집니다.

과제 2: 멈추지 않는 Embedding 비용

대화가 늘어날수록 Embedding API 호출 비용이 선형적으로 증가합니다. 이 또한 심각한 문제입니다.

Selective Embedding (선택적 Embedding): 모든 대화를 벡터화하는 것을 중단합니다. "이것은 나중에 떠올릴 가치가 있는 중요한 정보인가?"를 LLM 스스로 판단하게 하여, true라고 판단된 정보만을 Embedding하여 DB에 저장하는 것입니다. 이를 통해 API 호출 수와 DB 스토리지 크기를 대폭 절감할 수 있습니다.

요약: AI는 "잊기" 때문에, "기억"을 설계해야 한다

본 기사에서는 AI 에이전트의 "잘 잊어버리는" 문제를 해결하기 위한 데이터 기반 아키텍처와 사상에 대해 탐구해 왔습니다.

• 단순한 SQLite 구성의 한계에서 출발하여,
• AI의 장기 기억 시스템이 충족해야 할 요구사항(통합, 확장성, 고도화된 검색, 저비용)을 정의하고,
• 그 해답으로서 TiDB Serverless가 얼마나 강력한지를 구체적으로 보여주었습니다.
• 그리고 도구만으로는 해결할 수 없는, RAG 최적화라는 고되고도 중요한 실전 테크닉을 다루었습니다.

AI 에이전트의 기억을 설계하는 것은 단순한 데이터 관리가 아닙니다. 그것은 "AI의 정체성"을 우리 개발자들이 어떻게 정의하고 키워나갈 것인가라는 철학적인 질문이기도 합니다.

무엇을 기억하게 하고, 무엇을 잊게 할 것인가. 어떤 정보를 중요하다고 판단하게 할 것인가. 그 하나하나의 선택이 AI의 행동, 개성, 그리고 능력을 형성해 나갑니다. TiDB와 같은 확장 가능한 통합 데이터 기반은 이를 위한 시행착오를 뒷받침하는 강력한 캔버스가 됩니다.

앞으로의 AI 개발자는 단순히 모델을 파인튜닝(Fine-tuning)하는 것을 넘어, AI의 "기억"이라는 장대한 테마와 마주하는 아키텍트가 되어야 합니다. 당신의 도전이 세상을 더욱 개인화되고, 더욱 지능적인 것으로 만들어 갈 것입니다.

자, 당신의 AI에 지워지지 않는 기억을 구현해 보지 않겠습니까?