37일차 회고｜AI Memory·Redis·pgvector·MCP｜AI 오케스트레이션 개발자 국비지원

 

37일차에는 AI Agent의 Memory(메모리)를 중심으로 PostgreSQL, Redis, pgvector가 각각 어떤 데이터를 저장하고 어떻게 AI Agent의 응답에 활용되는지 배웠다.

특히 지금까지 배운 RAG, MCP, Tool에 Memory가 더해지면서 단순히 사용자의 질문에 답하는 AI와, 사용자를 기억하고 이전 상황을 활용하는 AI 서비스의 차이를 조금 더 구체적으로 이해할 수 있었다.

---

1. 오늘 배운 내용

오늘 수업은 Chapter 5의 05_memory를 중심으로 진행됐다.

수업 초반에는 지금까지 만들었던 Frontend → Backend → MCP Server 구조를 프로젝트에 적용하기 위한 기술적인 구조를 정리했다.

기존에는

"이런 서비스를 만들고 싶은데 디렉터리를 어떻게 구성하지?"

라는 방식으로 접근했다면, 이제는 반대로

"Frontend, Backend, MCP Server의 구조를 먼저 정하고 이 구조 안에 어떤 AI Agent와 Tool을 넣을 것인가?"

를 생각해야 한다는 설명이 인상적이었다.

또한 실제 서비스에서는 Frontend, Backend, MCP Server를 각각 분리하고 각각의 가상환경과 환경변수를 관리하는 것이 중요하다는 점도 다시 확인했다. 수업에서 사용하는 실습 프로젝트는 편의를 위해 하나의 환경에서 여러 요소를 다루지만, 실제 시스템을 설계할 때는 분리해서 생각해야 한다.

---

2. Memory는 단순한 대화 저장이 아니었다

오늘 가장 중요하게 배운 개념은 Memory가 모든 대화를 무조건 저장하는 기능은 아니라는 것이었다.

Memory는 필요한 정보를 저장하고 사용자가 필요할 때 조회·수정·삭제할 수 있는 상태와 선호를 관리하는 개념에 가깝다.

예를 들어 사용자가

• 특정 음식을 먹지 못한다.
• 대중교통을 선호한다.
• 조용한 숙소를 선호한다.

와 같은 정보를 가지고 있다면 이런 정보를 저장해두었다가 이후 요청에 활용할 수 있다.

수업에서는 사용자가 땅콩 알레르기가 있다는 정보를 저장해두고, 이후 맛집을 추천할 때 해당 정보를 고려하는 예시를 들었다.

이 부분을 통해 개인화된 AI 서비스에서 Memory가 왜 필요한지 이해할 수 있었다.

단순히

사용자 질문 → LLM → 답변

으로 끝나는 것이 아니라,

사용자 질문 → 관련 사용자 정보 조회 → 질문과 Memory를 함께 LLM에 전달 → 필요한 Tool 실행 → 개인화된 답변

이라는 흐름이 만들어질 수 있다는 것이다.

---

3. PostgreSQL, Redis, pgvector의 역할을 구분하기

Memory를 공부하면서 가장 중요했던 부분 중 하나는 데이터를 어디에 저장할 것인가였다.

각 저장소가 모두 데이터를 저장할 수 있지만 목적이 다르다.

PostgreSQL

장기적으로 보관해야 하는 데이터를 저장하는 DB로 사용한다.

수업에서 확인한 테이블에는 다음과 같은 것들이 있었다.

• user_memories : 사용자의 선호나 상태
• conversation_messages : 사용자와 AI 사이의 대화 기록
• agent_runs : Agent 실행 과정과 기록

특히 conversation_messages에는 user_id, session_id, 메시지 타입, 실제 메시지 내용 등을 저장할 수 있다.

Redis

Redis는 짧은 시간 동안 유지할 상태를 저장하는 용도로 설명됐다.

Redis는 TTL(Time To Live)을 설정할 수 있기 때문에 일정 시간이 지나면 데이터가 자동으로 사라지도록 만들 수 있다.

따라서 현재 진행 중인 작업이나 일시적인 세션 상태처럼 오래 보관할 필요가 없는 데이터에 적합하다.

pgvector

앞서 RAG에서 사용했던 pgvector도 다시 연결해서 생각할 수 있었다.

documents 테이블에는 벡터 컬럼이 있고, 이를 이용해 문서의 임베딩과 유사도 검색을 수행할 수 있도록 구성했다.

결국 중요한 것은 PostgreSQL, Redis, pgvector 중 무엇이 더 좋은가가 아니라 어떤 목적의 데이터를 저장하는가였다.

---

4. User ID와 Session ID가 중요한 이유

Memory를 실제 서비스에서 사용하려면 사용자 구분이 반드시 필요하다.

예를 들어 A 사용자의 선호 정보를 B 사용자가 조회할 수 있다면 문제가 된다.

그래서 사용자 데이터를 저장할 때 user_id를 기준으로 데이터를 구분해야 한다.

여기에 하나 더 필요한 것이 **session_id**다.

한 사용자가 하나의 주제만 가지고 대화하는 것이 아니기 때문이다.

예를 들어 한 사용자가

• 여행에 대한 대화
• 음식 추천에 대한 대화
• AI Agent 개발에 대한 대화

를 각각 진행할 수 있다.

이때 각각의 대화 맥락을 구분하기 위해 session_id를 사용할 수 있다. 즉 한 명의 사용자가 여러 개의 세션을 가질 수 있다는 개념을 배웠다.

이 내용을 프로젝트 관점에서 생각해보니 단순히 user_id 하나만 저장하는 것과 user_id + session_id로 사용자의 활동을 구분하는 것은 상당히 큰 차이가 있다는 것을 알게 됐다.

---

5. 대화 기록을 전부 LLM에 보내면 안 되는 이유

오늘 수업에서 개인적으로 가장 와닿았던 부분이다.

AI 서비스가 사용자의 대화를 장기간 저장한다고 가정해보자.

6개월 동안 대화를 계속 쌓았다고 해서 사용자가 새로운 질문을 할 때마다 6개월치 대화 전체를 LLM에게 전달하는 것은 비효율적이다.

토큰 사용량도 커지고, 실제 질문과 관계없는 정보까지 전달될 수 있다.

그래서 과거 대화 중 현재 질문과 관련된 내용을 찾아 사용하거나, 오래된 대화를 요약해서 관리하는 방식이 필요하다.

수업에서는 과거 대화 전체를 무작정 가져오는 것이 아니라 현재 질문과 관련성이 높은 내용을 찾아서 LLM에 전달하는 방식을 설명했다.

결국 Memory에서 중요한 것은 단순히

"얼마나 많이 저장했는가?"

가 아니라

"필요한 순간에 필요한 기억을 어떻게 찾아서 사용할 것인가?"

라는 생각이 들었다.

---

6. RAG와 Memory의 차이도 조금 더 명확해졌다

기존에는 RAG와 Memory가 둘 다 데이터를 찾아서 LLM에게 전달한다는 점 때문에 비슷하게 느껴졌다.

하지만 오늘 수업을 통해 목적이 다르다는 것을 정리할 수 있었다.

RAG는 주로 서비스에서 필요한 문서나 지식 데이터를 검색하기 위한 것이고,

Memory는 사용자와 관련된 상태, 선호, 이전 대화 등의 정보를 기억하고 활용하기 위한 것이다.

예를 들어 법률 AI Agent를 만든다면 법률 문서 자체는 RAG의 대상이 될 수 있고, 사용자가 이전에 어떤 사건이나 상담 맥락을 가지고 있었는지와 같은 정보는 Memory의 대상이 될 수 있다.

따라서 이번 미니 프로젝트를 생각할 때도 법률 문서 검색과 사용자별 Memory를 어떤 기준으로 분리할 것인지 고민해볼 필요가 있다고 느꼈다.

---

7. MCP와 Memory가 연결되는 방식

오늘은 Memory 기능을 MCP Server를 통해 제공하는 구조도 살펴봤다.

예를 들어 Memory MCP Server에서 다음과 같은 기능을 Tool 형태로 제공할 수 있다.

• Memory 저장
• Memory 조회
• 관련 Memory 검색
• Memory 삭제
• Memory 수정

Agent는 MCP Server가 제공하는 Tool 목록을 확인하고 필요한 기능을 선택해서 사용할 수 있다.

수업 예제에서는 사용자의 음식 관련 제한사항을 저장한 후, 이후 음식점을 추천하는 요청이 들어왔을 때 관련 Memory를 검색하고 그 결과를 LLM에 전달하는 흐름을 살펴봤다.

이 과정을 통해 MCP가 단순히 외부 API를 연결하는 역할만 하는 것이 아니라 DB와 연결해 AI가 사용자 Memory를 관리하도록 구성할 수도 있다는 점을 이해했다.

---

8. 오늘 새롭게 이해한 점

오늘 가장 크게 달라진 생각은 AI Agent의 발전이 단순히 Tool을 많이 추가하는 것만으로 이루어지는 것은 아니라는 점이다.

처음에는

LLM + Tool + MCP + RAG

정도만 연결하면 AI Agent가 상당히 발전한다고 생각했다.

하지만 실제 서비스에서는 여기에

사용자 데이터 + Memory + 대화 기록 + RAG + Tool + MCP

가 함께 연결될 수 있다.

특히 같은 질문이라도 사용자의 기존 정보에 따라 다른 답변을 제공할 수 있다는 점에서 Memory가 AI 서비스의 개인화에 중요한 역할을 한다는 것을 이해하게 됐다.

수업에서도 단순히 Tool 목록을 가져와 LLM과 연결하는 것만으로 끝나는 것이 아니라 사용자의 이전 대화와 선호를 어떻게 가져와 활용할 것인지가 중요하다고 강조했다.

---

9. 프로젝트를 준비하면서 느낀 점

37일차부터는 미니 프로젝트를 본격적으로 준비해야 하는 시점이라 기술적인 구조를 먼저 확정해야 한다는 이야기도 계속 나왔다.

특히 지금까지는 AI를 활용해서 빠르게 결과를 만들어보는 것에 집중했다면, 이제는 내가 작성하거나 AI의 도움을 받아 만든 코드가 어떤 구조로 연결되는지 이해하면서 개발해야 한다는 방향으로 바뀌고 있다는 느낌을 받았다.

프로젝트에서는 무작정 코드를 생성하기보다

Frontend → Backend → MCP Server → AI Agent → Tool/DB

가 어떻게 연결되는지를 먼저 이해하고, 그 구조 안에서 내가 맡은 기능을 구현하는 것이 중요하다고 생각했다.

---

10. 오늘의 회고

오늘은 Memory를 배우면서 AI Agent가 '기억한다'는 것이 정확히 무엇인지 조금 더 구체적으로 이해할 수 있었다.

특히 PostgreSQL은 장기 데이터, Redis는 일시적인 상태, pgvector는 벡터 기반 유사도 검색이라는 식으로 각각의 역할을 구분해서 생각하게 된 것이 좋았다.

또한 단순히 대화를 저장하는 것에서 끝나는 것이 아니라 어떤 사용자의 어떤 세션에서 발생한 데이터인지 구분하고, 현재 요청과 관련된 Memory만 선택해서 LLM에 전달하는 과정이 중요하다는 것도 알게 됐다.

아직은 Memory를 실제 프로젝트에 어떻게 적용할지, 어떤 데이터를 장기적으로 저장하고 어떤 데이터를 Redis에 둘지, 그리고 법률 Agent에서 어떤 사용자 정보를 Memory로 관리하는 것이 적절할지는 더 고민이 필요하다.

하지만 오늘 수업을 통해 적어도 "AI Agent가 사용자와의 이전 상호작용을 활용하려면 어떤 데이터 구조와 저장 전략이 필요한가"라는 질문을 생각할 수 있게 됐다는 점에서 의미 있는 하루였다.

오늘의 핵심 정리

• Memory = 모든 대화를 저장하는 것이 아니라 사용자 상태와 선호 등을 관리
• PostgreSQL = 장기적으로 관리할 사용자·대화 데이터
• Redis = TTL을 활용한 단기 상태 관리
• pgvector = 임베딩 기반 유사도 검색
• user_id + session_id = 사용자와 대화 맥락을 구분
• RAG와 Memory = 문서 지식 검색과 사용자 정보 관리라는 서로 다른 목적
• MCP = Memory 저장·조회 등의 기능을 AI Agent가 Tool로 사용할 수 있도록 연결
• AI 서비스에서는 "무엇을 저장할 것인가"뿐 아니라 "필요한 정보를 어떻게 찾아 사용할 것인가"가 중요하다