[LLM Agent Patterns] Day 3: 에이전트 메모리 시스템 - 단기·장기 메모리 설계

서론: 에이전트가 “기억”한다는 것의 의미

LLM은 기본적으로 무상태(stateless)다. 이전 대화를 컨텍스트로 전달하지 않으면 기억하지 못한다. 에이전트가 긴 작업을 수행하거나 여러 세션에 걸쳐 동작하려면 명시적인 메모리 시스템이 필요하다.

1. 메모리 유형 분류

유형	저장 위치	지속성	역할
단기 메모리	컨텍스트 윈도우	세션 내	현재 대화/작업 히스토리
에피소드 메모리	외부 저장소	영구	과거 대화 요약 및 경험
의미 메모리	벡터 DB	영구	사실·지식 검색 (RAG)
절차 메모리	시스템 프롬프트/파인튜닝	모델 내장	행동 방식·스타일

대부분의 프로덕션 에이전트는 단기 + 에피소드 메모리 조합으로 시작하면 충분하다.

2. 단기 메모리 관리

단기 메모리는 컨텍스트 윈도우에 담긴 대화 히스토리다. 컨텍스트 한계에 가까워지면 전략적으로 압축해야 한다.

2.1 슬라이딩 윈도우

가장 오래된 메시지를 제거하고 최신 N개만 유지한다.

[msg1, msg2, msg3, msg4, msg5] → 윈도우 크기 3 → [msg3, msg4, msg5]

단순하지만 중요한 초기 지시 사항이 잘릴 수 있다.

2.2 요약 압축

일정 주기로 과거 메시지를 LLM으로 요약하고, 요약본으로 교체한다.

[Summary of msg1-10] + [msg11, msg12, msg13]

정보 손실이 있지만 핵심을 유지하면서 컨텍스트를 줄인다.

2.3 중요도 기반 필터링

모든 메시지를 동등하게 취급하지 않는다.

• 시스템 지시, 목표, 제약 → 항상 유지
• 중간 추론 단계 → 요약 가능
• 최종 결과와 오류 → 유지

3. 장기(에피소드) 메모리 설계

세션이 끝난 후에도 기억해야 할 정보를 외부에 저장한다.

세션 종료
  └─ 메모리 추출 (LLM이 기억할 사실 선별)
  └─ 구조화·요약
  └─ 외부 저장소에 기록 (벡터 DB + 메타데이터)

새 세션 시작
  └─ 사용자 ID로 관련 메모리 검색
  └─ 시스템 프롬프트 또는 컨텍스트에 주입

3.1 저장할 정보 선별 기준

• 사용자가 명시적으로 밝힌 선호·제약
• 반복적으로 등장하는 패턴
• 중요한 결정과 그 이유
• 오류 경험 (같은 실수를 반복하지 않기 위해)

모든 것을 저장하면 검색 품질이 낮아진다. 선별이 중요하다.

4. 메모리 검색 설계

현재 컨텍스트 (현재 대화 요약)
  └─ 임베딩 생성
  └─ 벡터 DB 유사도 검색
  └─ 상위 K개 메모리 회수
  └─ 시스템 프롬프트에 주입

회수된 메모리가 현재 작업과 관련이 없을 수 있다. 관련성 임계값을 설정해 낮은 유사도 결과는 제외한다.

5. 메모리 오염 방지

잘못된 정보가 장기 메모리에 저장되면 에이전트 동작에 지속적으로 영향을 준다.

• 메모리 저장 전 사실 검증 단계 추가
• 메모리에 신뢰도 점수와 출처 태깅
• 오래된 메모리의 주기적 갱신 또는 만료
• 사용자가 메모리를 명시적으로 수정·삭제할 수 있는 인터페이스

6. 운영 관측 지표

• 메모리 검색 히트율 (관련 메모리가 실제로 도움이 됐는지)
• 평균 검색 응답 시간
• 메모리 저장소 크기 증가율
• 메모리 오염 사례 탐지 건수

7. Day 3 체크리스트

1. 단기 메모리 압축 전략(슬라이딩 윈도우 또는 요약)을 구현했다.
2. 중요도 기반으로 유지할 메시지 유형을 정의했다.
3. 장기 메모리 저장 기준을 명시하고 선별 로직을 구현했다.
4. 메모리에 신뢰도 점수와 만료 정책을 적용했다.

다음 글 예고

Day 4에서는 툴 사용 안전성을 다룬다. 에이전트가 외부 시스템에 접근할 때의 권한 최소화, 에러 처리, 되돌릴 수 없는 작업에 대한 Human-in-the-Loop 설계를 살펴본다.