AI 에이전트 메모리 설계: 매번 처음부터 설명하는 챗봇에서 벗어나는 법

AI 에이전트 메모리 설계: 매번 처음부터 설명해야 하는 챗봇에서 벗어나는 법

AI 에이전트 메모리 설계의 핵심은 저장이 아니라 선별입니다. 무엇을 안 넣을지 정하는 규칙이 먼저예요. 모델을 바꿔도, 윈도우를 키워도 이 규칙이 없으면 같은 설명을 또 타이핑하게 됩니다.

같은 말을 세 번째 타이핑하고 있다면

사내 AI 도구를 켜고 "우리는 B2B SaaS고, 고객사는 제조업 중심이고, 보고서는 항상 임원용 1페이지 요약으로"를 또 입력하고 있다면, 그건 프롬프트 실력 문제가 아니라 설계 문제입니다.

원인은 싱겁습니다. 대화형 모델은 기본적으로 stateless(무상태)예요. 요청이 들어올 때마다 그 요청에 담긴 토큰만 보고 답합니다. 어제 대화는 모델 안에 남지 않고, 누군가 다시 넣어줘야 존재해요. 챗 UI가 기억하는 것처럼 보이는 건 그 UI가 이전 메시지를 매번 같이 보내주기 때문입니다.

클래스도산 원데이 클래스에서도 같은 장면이 반복됩니다. 참가자들이 막히는 지점은 모델 조작이 아니에요. 자기 업무 맥락을 세션마다 처음부터 다시 설명하는 데 앞쪽 시간을 씁니다.

AI 에이전트 메모리란 정확히 뭔가요?

에이전트가 세션 밖에 남겨두고 필요할 때 꺼내 쓰는 정보, 그게 메모리입니다. 컨텍스트 윈도우와는 층이 달라요.

컨텍스트 윈도우는 한 번의 요청에 담기는 작업대이고, 매 대화마다 비워집니다. Anthropic은 이 윈도우를 "유한한 자원"으로 보고 모델이 매 턴 쓸 수 있는 주의력에 예산이 있다고 설명해요.¹ 메모리는 그 예산 밖에 사는 영속 저장소입니다. 파일이든 데이터베이스든 벡터 인덱스든 형태는 자유고, 조건은 하나예요. 모델이 스스로 읽고 쓸 수 있어야 합니다.

UC Berkeley 연구진의 MemGPT 논문은 이 구조를 운영체제에 비유했습니다. 메인 컨텍스트는 RAM, 외부 컨텍스트는 디스크, 에이전트가 함수 호출로 둘 사이를 페이징합니다.² 기억하는 모델에서 기억을 관리하는 시스템으로 넘어가는 전환이죠.

메모리는 몇 가지로 나뉘나요?

실무에서는 세 종류로 충분합니다. 단기 메모리, 사실 기억, 경험 기억입니다.

구분	사는 곳	담는 것	갱신 방식
단기 메모리	컨텍스트 윈도우	지금 대화, 직전 도구 결과	세션 종료 시 소멸
사실 기억(장기)	파일·DB	조직 규칙, 용어, 담당자, 산출물 포맷	사람이 수정·승인
경험 기억(장기)	메모리 스트림(관찰을 시간순으로 쌓는 기록)	과거 판단, 반려 사유, 피드백	에이전트가 추가·요약

경험 기억의 교과서는 Stanford와 Google 연구진의 『Generative Agents』입니다. 에이전트 25명이 사는 가상 마을에서, 관찰을 메모리 스트림에 쌓고 검색할 때 최근성·중요도·관련성 세 점수를 합산해 꺼내고, 쌓인 기억을 주기적으로 상위 통찰로 묶어 올리는 회상(reflection)을 돌립니다.³ 세 요소 중 하나를 빼면 행동의 일관성이 떨어졌다는 실험 결과가 특히 유용해요.

컨텍스트 윈도우가 커지면 메모리 설계는 필요 없어지나요?

아니요. 입력이 길어지는 것만으로 정확도가 떨어집니다.

Chroma 연구팀은 18개 모델에 같은 과제를 주고 입력 길이만 늘려가며 측정했고, 길이가 늘어나는 것만으로 성능이 균일하지 않게 저하되는 현상을 보고했습니다. 여기 "context rot"이라는 이름이 붙었어요.⁴ 그보다 앞선 『Lost in the Middle』은 답에 필요한 문서가 입력의 중간에 놓일 때 성능이 꺾이고, 일부 설정에서는 문서를 아예 주지 않은 경우보다 낮은 점수가 나왔다는 것까지 보여줬습니다.⁵

보충. 200K 윈도우가 "200K만큼 기억한다"는 뜻은 아니에요. 담을 수 있는 양과 실제로 주의를 주는 양은 다른 숫자입니다.

그래서 승부는 선별에서 갈립니다. 다 넣는 시스템은 쓸수록 느려지고, 쓸수록 틀립니다.

클래스도산 기억 3층 구조

저장소를 고르기 전에 기억을 세 층으로 쪼개고, 층마다 수정 권한을 다르게 두세요.

층	담는 것	수정 권한	폐기 기준
1층 정체성	회사·제품 정의, 금지 표현, 산출물 형식	사람만 수정, 에이전트는 읽기 전용	분량 1페이지 초과 시 덜어내기
2층 사실	담당자, 진행 과제, 지난 결정사항	에이전트 쓰기 허용, 항목마다 기록 날짜 필수	날짜 기준으로 재확인·갱신
3층 경험	반려된 방식, 선호하지 않은 톤, 피드백	에이전트가 추가·요약	참조된 적 없는 항목은 폐기

2층에서 날짜를 생략하면 작년 담당자가 올해 보고서에 그대로 등장합니다. 날짜 없는 사실은 1년 뒤의 거짓말이에요.

이 구조의 효용은 사고 대응에서 드러납니다. 말투가 틀렸으면 1층, 정보가 낡았으면 2층, 같은 실수를 반복하면 3층. 열어볼 파일이 바로 정해집니다.

파일·검색·요약 중 뭐부터 써야 하나요?

파일부터입니다. 규칙과 맥락이 수십 줄 수준이면 마크다운 파일이 가장 빠르고 고치기 쉬워요.

건수가 늘어 전부 읽는 비용이 커지면 검색 기반(RAG, Retrieval-Augmented Generation)을 얹습니다. 질의와 관련된 조각만 꺼내 쓰는 방식이고, 대신 검색이 틀리면 답도 같이 틀려요. 상담이나 프로젝트처럼 세션이 길게 이어지면 지난 세션을 압축해 넘기는 요약 계층을 더합니다. 압축 과정에서 숫자와 단서가 빠지니, 요약본과 원문 링크를 함께 남기세요.

셋 중 하나를 고르는 문제가 아닙니다. Anthropic은 에이전트 설계에서 복잡한 프레임워크보다 단순하고 조합 가능한 패턴부터 시작하라고 권하는데,⁶ 메모리도 같아요. 첫 주에 벡터 DB를 세우는 팀보다 파일 열 장으로 시작한 팀이 먼저 결과를 봅니다.

메모리 설계, 뭘 먼저 확인해야 하나요?

도구 선정이 아니라, 사람이 매번 다시 입력하는 문장을 2주간 수집하는 일부터 하세요.

실무자 다섯 명의 프롬프트를 모아 놓으면 중복 문장이 눈에 보입니다. 그 중복이 1층 후보예요. 목록 없이 벡터 DB를 먼저 깔면 무엇을 넣어야 하는지 모르는 빈 창고가 생깁니다.

그다음 세 가지를 정하면 1차 설계가 끝나요.

정할 것	기준	비어 있으면
권한	층별 읽기·쓰기 주체를 1·2·3층 각각에 명시	에이전트가 정체성 기억을 덮어씀
수명	항목마다 기록 날짜와 재확인 주기 부여	낡은 사실이 최신 보고서에 섞임
점검 경로	오답 시 열어볼 파일과 담당자를 1곳으로 지정	"얘가 왜 이러는지 모르겠다"에서 도구가 버려짐

한눈 요약

1. 메모리는 세션 밖 저장소, 컨텍스트 윈도우는 매번 비워지는 작업대입니다.
2. 종류는 단기·사실·경험 세 가지로 끊으면 실무에 충분합니다.
3. 윈도우를 키워도 선별은 남습니다. context rot과 중간 위치 손실이 측정됐습니다.
4. 기억을 3층으로 쪼개고 층마다 수정 권한과 폐기 기준을 다르게 둡니다.
5. 파일로 시작하고, 건수가 늘면 검색, 세션이 길어지면 요약을 얹습니다.

메모리 설계를 미루면 비용은 조용히 쌓입니다. 같은 맥락을 하루 다섯 번 재입력하는 조직은 AI를 도입한 게 아니라, 사람이 AI의 기억 장치를 대신하고 있는 상태예요. 메모리 파일 한 장을 직접 만들어 보려면 클래스도산 클로드 바이브 코딩 원데이 클래스(5시간, 결과물 1개 완성)에서 시작해 보세요.

자주 묻는 질문

Q. 컨텍스트 윈도우가 더 커지면 메모리 설계가 필요 없어지나요? A. 아니에요. 입력 길이가 늘어나는 것만으로 성능이 저하되는 context rot이 18개 모델에서 측정됐고,⁴ 같은 정보도 입력 중간에 묻히면 활용도가 떨어집니다.⁵ 윈도우 크기는 선별 작업을 없애주지 않습니다.

Q. 벡터 DB부터 도입해야 하나요? A. 대부분은 아닙니다. 규칙과 맥락이 수십 줄이면 파일 기반으로 충분하고, 문서 건수가 많아 전부 읽는 비용이 커질 때 검색을 얹으면 됩니다. 단순하고 조합 가능한 패턴부터 시작하는 쪽이 유리해요.⁶

Q. 에이전트가 스스로 기억을 쓰게 해도 안전한가요? A. 층을 나누면 괜찮습니다. 1층 정체성 기억은 읽기 전용으로 잠그고, 2·3층만 쓰기 권한을 엽니다. MemGPT처럼 에이전트가 메모리를 직접 관리하는 구조도 읽고 쓰는 경로가 함수로 명시돼 있어요.²

Q. 오래된 기억은 어떻게 정리하나요? A. 모든 항목에 기록 시점을 남기고, 참조되지 않은 항목은 주기적으로 요약하거나 버리세요. 최근성·중요도·관련성으로 점수를 매겨 꺼내는 방식이 검증된 출발점입니다.³

출처

Footnotes

1. Anthropic, 『Effective context engineering for AI agents』(2025) — 컨텍스트 윈도우를 유한한 주의력 예산으로 보는 관점과 외부 메모리 설계 원칙. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents ↩

2. Packer et al., 『MemGPT: Towards LLMs as Operating Systems』, arXiv:2310.08560 (2023) — 메인 컨텍스트와 외부 컨텍스트를 계층화하고 에이전트가 페이징하는 설계. https://arxiv.org/abs/2310.08560 ↩ ↩²

3. Park et al., 『Generative Agents: Interactive Simulacra of Human Behavior』, arXiv:2304.03442 (2023) — 에이전트 25명 환경, 메모리 스트림과 최근성·중요도·관련성 기반 검색, 회상(reflection) 메커니즘. https://arxiv.org/abs/2304.03442 ↩ ↩²

4. Chroma Research, 『Context Rot: How Increasing Input Tokens Impacts LLM Performance』(2025) — 18개 모델에서 입력 길이 증가에 따른 성능 저하를 측정. https://research.trychroma.com/context-rot ↩ ↩²

5. Liu et al., 『Lost in the Middle: How Language Models Use Long Contexts』, arXiv:2307.03172 (2023/TACL 2024) — 관련 정보가 입력 중간에 위치할 때의 성능 저하. https://arxiv.org/abs/2307.03172 ↩ ↩²

6. Anthropic, 『Building effective agents』(2024-12) — 복잡한 프레임워크보다 단순하고 조합 가능한 패턴을 우선하라는 설계 원칙. https://www.anthropic.com/engineering/building-effective-agents ↩ ↩²