이 기사에서는 TiDB를 사용하여 AI 에이전트의 「기억 기반 (Memory Infrastructure)」을 구축할 때의 설계를 정리합니다.

RAG (Retrieval-Augmented Generation)를 만드는 이야기로 넘어가면, 금방 "문서를 벡터화하여 검색합시다"라는 말로 끝나기 쉽습니다. 솔직히 그것뿐이라면 기사로 쓸 가치가 적습니다. AI 에이전트의 메모리는 검색 인덱스만이 아닙니다.

결론부터 말씀드리면, AI 에이전트의 기억은 다음 5가지로 나누어 설계하는 것이 안전합니다.

• 가공되지 않은 대화 로그 (Raw Conversation Logs)
• 요약된 단기 메모리 (Summarized Short-term Memory)
• 사용자 및 업무와 연결된 장기 메모리 (Long-term Memory tied to users/business)
• RAG용 문서/청크 (Documents/Chunks for RAG)
• 검색·답변·평가 로그 (Search, Answer, and Evaluation Logs)

TiDB와 같은 SQL 기반 데이터 기반을 사용하는 의미는 단순히 데이터를 두는 것에 있지 않습니다. 트랜잭션 (Transaction), 세컨더리 인덱스 (Secondary Index), JSON 열, 감사 (Audit), 삭제, 평가를 동일한 운영 측면에서 다룰 수 있다는 점에 있습니다.

AWS로 비유하자면, RDS에 업무 트랜잭션을 두고, DynamoDB에 세션 상태를 두며, BigQuery에 평가 로그를 흘려보내는 구성도 있습니다. TiDB로 생각할 경우에는 이것들을 어디까지 하나의 SQL 데이터 기반으로 모을 것인지, 어디서부터 검색 엔진이나 분석 기반으로 분리할 것인지를 설계하는 것이 본론입니다.

예를 들어, 사내 지식에 답하는 AI 에이전트를 가정해 봅시다.

사용자는 Slack이나 Web UI를 통해 질문합니다.

• "이 고객의 지난번 문의 내용은?"
• "이 장애의 잠정 대응책은 무엇이었지?"
• "내가 전에 요청한 견적 조건을 기억하고 있어?"

여기서 필요한 것은 문서 검색만이 아닙니다. 과거의 대화, 확정된 메모, 잊어야 할 정보, 답변의 근거, 사용자로부터의 피드백이 필요합니다.

우선 나누어야 할 것은 RAG와 메모리입니다.

RAG의 청크를 그대로 「에이전트의 기억」이라고 부르면 나중에 파탄이 납니다.

예를 들어, 사용자가 "전에 말한 조건으로"라고 말했을 때, 검색해야 할 대상은 사내 문서가 아니라 과거 대화나 확정된 메모리입니다. 반대로, 제도나 사양에 대한 설명에서는 사내 문서의 RAG가 중요해집니다.

TiDB 위에 구축한다면, 최소 구성은 다음과 같이 나눕니다.

CREATE TABLE conversation_turns (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
tenant_id VARCHAR(64) NOT NULL,
...

실제로는 벡터 검색이나 전문 검색 (Full-text Search) 구성에 따라 추가 테이블이 필요하게 됩니다. 다만, 처음부터 전부를 하나의 테이블에 밀어 넣지 않는 것이 좋습니다.

이 부분을 애매하게 처리하면, AI 기반은 금방 「무엇이든 들어있는 정체불명의 DB」가 됩니다.

TiDB를 사용한다면, 적어도 「업무상의 사실」, 「사용자 단위의 기억」, 「검색·답변 로그」는 SQL로 추적할 수 있는 형태로 만들어 두고 싶습니다. 반대로, 거대한 임베딩 벡터 (Embedding Vector) 자체를 어떻게 보유할지는 이용하는 TiDB Cloud의 기능이나 외부 검색 기반의 선정에 맞춰 결정합니다. 검증되지 않은 성능을 과장해서 쓸 필요는 없습니다.

AI 에이전트의 로그는 편리하지만 위험하기도 합니다.

대화에는 개인정보, 고객 정보, 내부 사정, 아직 확정되지 않은 판단이 포함됩니다. 따라서 "전부 저장해서 나중에 AI에게 먹인다"는 방식은 조잡합니다.

최소한 다음을 설계합니다.

• tenant_id로 조직을 분리
• user_id로 액세스 제어(Access Control)가 가능하도록 함
• session_id로 대화 단위를 추적할 수 있도록 함
• 보관 기간을 결정
• 삭제 요청에 대응할 수 있도록 함
• 가공되지 않은 로그와 요약 메모리를 분리
• CloudTrail과 같은 감사 로그 (Audit Log) 발상으로, 누가 무엇을 참조했는지 남김

가공되지 않은 로그는 일정 기간이 지나면 삭제하고, 필요한 정보만 요약 메모리로 승격시키는 설계가 현실적입니다.

AI 에이전트에게 장기 기억을 갖게 하려면, 「무엇을 기억할까」보다 「왜 기억했는가」를 남겨야 합니다.

예를 들어 다음과 같은 메모리입니다.

{
"memory_type": "user_preference",
"summary": "사용자는 답변에 구현 예시와 운용상의 주의사항을 포함하는 것을 선호함",
...

source_turn_ids가 있으면 나중에 "왜 이 메모가 존재하는가"를 확인할 수 있습니다. 이는 감사(Audit)뿐만 아니라 오기억(Mis-memory)을 수정하는 데에도 효과적입니다.

반대로 근거 없는 메모는 위험합니다. AI가 한 번 착각하여 저장한 정보를 다음번 이후에도 사실로서 계속 사용하게 됩니다. 이것이 메모 기능의 무서운 점입니다.

RAG는 "검색하여 LLM에 전달하는 것"만으로는 부족합니다.

저는 다음과 같은 흐름으로 나눕니다.

user query
-> query rewrite
-> policy check
...

query rewrite에서는 대화문을 검색하기 쉬운 형태로 만듭니다.

예를 들어 "아까 그 요금 이야기"는 그대로 검색하면 성능이 약합니다. 최근 대화로부터 "TiDB Cloud의 요금 플랜 비교" 등으로 보정합니다.

단, 보정된 쿼리도 retrieval_logs에 남깁니다. 나중에 답변 품질을 조사할 때, 사용자의 원래 질문만 봐서는 원인을 알 수 없기 때문입니다.

TiDB Cloud나 TiDB를 사용하는 가치가 잘 나타나는 부분은 AI 기능 그 자체보다 운영 측면입니다.

• 대화 로그와 업무 데이터를 SQL로 추적할 수 있음
• 여러 테이블을 트랜잭션(Transaction)으로 업데이트할 수 있음
• tenant_id / user_id 단위로 액세스 제어(Access Control)를 설계하기 쉬움
• retrieval_logs와 feedback을 분석하기 쉬움
• 메모 삭제나 정정을 SQL로 구현하기 쉬움
• 스케일 아웃(Scale-out) 시 단일 노드 DB보다 대안이 있음
• RDS 같은 업무용 DB의 견고함과 BigQuery 같은 분석 요구 사이를 어디까지 좁힐 수 있을지 판단할 수 있음

물론 모든 작은 RAG 애플리케이션에 TiDB가 필요한 것은 아닙니다. PoC라면 SQLite나 PostgreSQL로 시작해도 좋습니다.

하지만 AI 에이전트를 업무에서 지속적으로 운용하려면, 나중에 필요해지는 것은 화려한 생성 기능이 아니라 로그, 감사, 삭제, 평가입니다. 이 부분을 처음부터 테이블로 설계해 두는 것은 의미가 있습니다.

AI 메모리 설계에서 가장 놓치기 쉬운 것은 "잊는 방법"입니다.

기억은 많아질수록 좋은 것이 아닙니다.

• 오래된 프로젝트 정보
• 만료된 가격 조건
• 이미 수정된 사용자 희망 사항
• 일시적인 트러블 대응
• 개인정보를 포함한 대화

이것들을 영원히 기억하는 에이전트는 똑똑한 것이 아니라 위험한 것입니다.

memory_summaries에는 expires_at을 갖게 합니다. 나아가 중요도가 낮고 참조되지 않는 메모는 정기적으로 삭제하거나 재요약합니다.

DELETE FROM memory_summaries
WHERE expires_at IS NOT NULL
AND expires_at < NOW();

사소해 보이지만, 이런 처리가 없는 메모 기능은 시간이 지날수록 노이즈 제조기가 됩니다.

답변이 틀렸을 때, "LLM이 잘못했다"로 끝내면 개선할 수 없습니다.

봐야 할 것은 분해된 로그입니다.

• query rewrite가 잘못되었는가
• retrieval이 빗나갔는가
• rerank가 틀렸는가
• 올바른 문서는 가져왔으나 답변 생성 과정에서 무너졌는가
• 애초에 문서가 오래되었는가

retrieval_logs와 feedback을 남겨두면 나중에 원인을 추적할 수 있습니다.

{
"query": "이전 계약 조건은?",
"rewritten_query": "고객A 2026년 4월 계약 조건 지불 사이트",
...

이 정도의 입도로 남아 있으면 개선은 상당히 현실적이 됩니다.

TiDB로 AI 에이전트의 기억 기반을 만든다면, RAG만 보고 있어서는 부족합니다.

설계해야 하는 것은 검색 인덱스가 아니라 기억의 라이프사이클(Lifecycle)입니다.

• 원시 로그와 요약 메모를 분리할 것
• 장기 메모에는 중요도, 근거, 기한을 부여할 것
• RAG와 사용자 기억을 섞지 말 것
• retrieval_logs와 feedback을 남길 것
• 삭제, 정정, 감사를 처음부터 설계할 것
• RDS, DynamoDB, BigQuery, 전용 검색 기반과의 경계를 결정할 것
• 모든 것을 기억하는 것이 아니라, 잊는 메커니즘을 넣을 것

TiDB와 같은 데이터 기반은 AI의 답변을 화려하게 만들기 위한 것만이 아닙니다. 오히려 AI 에이전트를 업무에서 망가뜨리지 않고 운용하기 위한 토대입니다.

AI 시대의 데이터 기반에서 중요한 것은 저장량이 아닙니다. 무엇을 근거로 기억하고, 언제 잊으며, 어떻게 검증할 수 있는가입니다. 거기까지 설계해야 비로소 AI 에이전트의 메모리는 실용품이 됩니다.