AI 에이전트를 만들다 보면 가장 자주 헷갈리는 지점이 있습니다. 지금 대화에서만 잠깐 들고 있을 정보와, 다음 대화에도 남겨둘 정보, 필요할 때마다 문서에서 다시 찾아와야 할 정보를 한 바구니에 넣어버리는 순간 구조가 금방 무거워집니다.
메모리 설계의 핵심은 더 많이 저장하는 데 있지 않습니다. 세션 기억은 현재 대화를 이어가기 위한 정보, 장기 기억은 다음 세션에도 유지할 사용자 정보, RAG는 필요할 때 외부 문서를 다시 찾아오는 방식으로 나눠 보면 구조가 한결 단순해집니다. 무엇을 기억할지보다 무엇은 기억하지 말아야 하는지를 먼저 정하는 편이 운영이 훨씬 안정적입니다.
AI 에이전트 메모리 설계는 왜 나눠서 봐야 할까
에이전트가 답을 만들 때 사용하는 정보는 성격이 서로 다릅니다. 현재 대화 흐름을 이어가기 위한 정보, 사용자 선호처럼 오래 유지해야 할 정보, 사내 문서나 정책처럼 매번 다시 조회해야 할 정보는 저장 방식도 달라야 합니다. 이 구분이 없으면 오래 남길 필요 없는 대화 로그가 쌓이거나, 반대로 매번 최신 문서를 봐야 할 내용을 낡은 기억으로 처리하게 됩니다.
| 구분 | 무엇을 담나 | 언제 쓰나 | 대표 예시 |
|---|---|---|---|
| 세션 기억 | 현재 대화의 맥락, 방금 정한 조건, 직전 도구 실행 결과 | 한 번의 작업 흐름을 이어갈 때 | 표 형식 요청, 비교 조건, 직전 검색 결과 |
| 장기 기억 | 사용자 선호, 고정 프로필, 반복되는 업무 습관 | 다음 세션에서도 개인화가 필요할 때 | 선호 언어, 보고서 형식, 자주 쓰는 팀 규칙 |
| RAG | 문서, 정책, 매뉴얼, 최신 사내 지식처럼 외부 근거가 필요한 자료 | 질문이 들어올 때마다 관련 자료를 찾아 넣을 때 | 인사 규정, 상품 설명서, 계약 템플릿, 기술 문서 |
출처: Google Cloud Documentation
세션 기억은 현재 작업을 끊기지 않게 이어주는 층입니다
세션 기억은 말 그대로 지금 진행 중인 대화의 작업 메모에 가깝습니다. 사용자가 방금 준 조건, 이전 단계에서 고른 옵션, 직전 도구 호출 결과를 이어붙여 다음 행동을 자연스럽게 만들 때 필요합니다. 다만 세션이 길어질수록 문맥이 비대해질 수 있으므로, 모든 로그를 끝없이 붙이는 방식보다 현재 작업에 필요한 핵심만 남기는 편이 좋습니다.
장기 기억은 개인화에 필요한 것만 남기는 층입니다
장기 기억은 다음 대화에서도 다시 써야 할 정보에만 쓰는 편이 안전합니다. 예를 들어 답변 언어, 회의 요약 형식, 보고서에서 먼저 볼 항목처럼 반복 사용되는 정보는 세션이 바뀌어도 유용합니다. 반면 일회성 요청이나 민감한 원문 대화까지 장기 기억으로 저장하면 품질보다 관리 부담이 더 커집니다.
RAG는 기억이 아니라 필요할 때 불러오는 근거층입니다
RAG는 자주 바뀌거나 근거 확인이 중요한 지식을 다룰 때 특히 유용합니다. 사내 규정집, 제품 문서, 표준 운영 절차처럼 원문 출처가 중요한 자료는 메모리로 오래 들고 있기보다 질문 시점에 다시 검색해서 넣는 방식이 더 잘 맞습니다. 그래서 RAG는 에이전트가 무언가를 오래 저장한다기보다, 답변할 때 맞는 자료를 찾아와 근거를 붙이는 방식으로 이해하는 편이 정확합니다.
무엇을 어디에 넣어야 할까
실무에서는 저장 위치를 정보의 성격으로 나누면 판단이 빨라집니다. 오래 유지해야 하는 사용자 특성인지, 최신 근거가 필요한 업무 지식인지, 아니면 지금 대화 안에서만 잠깐 쓰고 버릴 정보인지부터 구분하면 됩니다.
사용자 선호와 반복 규칙은 장기 기억 후보입니다
선호 언어, 보고서 형식, 승인 문구 스타일, 자주 선택하는 부서나 프로젝트 코드처럼 반복 사용되는 정보는 장기 기억 후보입니다. 다만 저장 전에 다음 세션에도 계속 유효한지, 사용자에게 실제 이득이 있는지, 민감도는 어떤지까지 함께 보는 편이 좋습니다. 저장 가치가 약한 정보는 장기 기억에 넣지 않는 쪽이 더 낫습니다.
문서·정책·지식베이스는 RAG로 분리하는 편이 안정적입니다
규정집, 위키, 도움말, 제품 스펙, 계약서 양식처럼 문서가 자주 바뀌는 영역은 RAG로 두는 편이 좋습니다. 이런 정보는 오래 기억하는 순간 갱신 문제와 출처 문제를 동시에 안게 됩니다. 반대로 RAG로 분리해두면 최신 문서 기준으로 찾아오고, 어떤 문서를 근거로 썼는지도 함께 다루기 쉬워집니다.
도구 결과와 실시간 상태는 세션 기억으로 짧게 다루는 편이 좋습니다
주문 상태 조회, 승인 요청 결과, 캘린더 일정 확인처럼 외부 시스템에서 막 읽어온 값은 우선 세션 기억에서 짧게 다루는 편이 안전합니다. 이 값들은 현재 작업에는 중요하지만, 다음 대화까지 오래 저장해야 할 정보는 아닐 수 있기 때문입니다. 외부 시스템과 연결되는 구조까지 함께 정리하려면 MCP란 무엇인가: AI 에이전트와 외부 도구 연결 구조 쉽게 설명을 같이 보면 설계 기준을 잡기 좋습니다.
실무에서 자주 생기는 설계 실수
첫째, 장기 기억을 만능 저장소처럼 쓰는 경우입니다. 사용자 선호와 사내 문서를 한곳에 섞어 넣으면 검색과 정제 규칙이 뒤엉킵니다. 장기 기억은 개인화, RAG는 근거 문서라는 선을 유지하는 편이 운영이 쉽습니다.
둘째, 세션 로그를 그대로 무한 보관하는 경우입니다. 길어진 대화 전체를 매번 다 넣으면 비용과 지연이 커지고, 실제로 중요한 정보가 묻히기 쉽습니다. 세션 요약이나 핵심 상태값만 남기도록 축약 규칙을 두는 편이 좋습니다.
셋째, 자주 바뀌는 사실을 기억으로 고정하는 경우입니다. 가격, 정책, 재고, 조직도처럼 변동성이 있는 정보는 기억보다 조회가 더 안전합니다. 시간이 지나면 틀릴 가능성이 높은 값은 저장보다 재확인이 기본입니다.
넷째, 보안과 권한을 메모리 뒤로 미루는 경우입니다. 어떤 정보가 저장될 수 있는지, 누가 다시 읽을 수 있는지, 승인 없이 실행하면 안 되는 작업은 무엇인지가 먼저 정리돼야 합니다. 메모리 설계는 편의성만의 문제가 아니라 접근 범위와 감사 가능성까지 함께 보는 구조 문제입니다.
처음 설계할 때 체크 순서
먼저, 이 정보가 다음 세션에도 필요한지 확인합니다. 필요 없다면 세션 기억 후보입니다.
다음으로, 사실의 원문 근거가 중요한지 봅니다. 문서 근거가 중요하거나 최신성이 핵심이면 RAG 후보입니다.
그다음, 사용자가 반복해서 얻는 이득이 있는지 따집니다. 개인화 가치가 분명하면 장기 기억 후보입니다.
마지막으로, 저장 민감도와 권한 범위를 봅니다. 민감 정보는 최소화하고, 저장하더라도 누가 읽고 수정할 수 있는지까지 분리해야 합니다. 이 단계에서 권한 검토가 빠지면 메모리 구조가 잘 짜여 있어도 운영 리스크가 커질 수 있습니다.
정리하면 이렇게 나누면 됩니다
세션 기억은 지금 대화를 이어가기 위한 작업 메모, 장기 기억은 다음 대화에도 남아야 할 사용자 중심 정보, RAG는 질문이 들어올 때마다 다시 찾아오는 외부 근거로 보면 이해가 빠릅니다. 무엇을 얼마나 많이 저장할지가 아니라, 어떤 정보가 어느 층에 있어야 가장 덜 틀리고 덜 무거우며 덜 위험한지를 먼저 보는 것이 좋은 메모리 설계의 출발점입니다.
참고자료
아래 글까지 이어서 보면 메모리 구조를 실제 설계 문서로 옮길 때 훨씬 수월합니다.
자주 묻는 질문
이 글은 AI 에이전트 메모리 구조를 이해하기 위한 일반적인 정리이며, 실제 도입 단계에서는 데이터 민감도, 로그 보관 기준, 권한 정책을 함께 검토하는 편이 안전합니다.
댓글