온톨로지와 메모리 시스템 (6/13) — 좋은 에이전트 메모리 아키텍처는 어떻게 생겼나

메모리 이야기를 하면 많은 사람이 검색 품질이나 장기 기억부터 떠올린다. 물론 중요하다. 하지만 더 근본적인 문제는 따로 있다. 무엇을 어디에 두고, 언제 불러오고, 무엇을 장기 자산으로 승격할 것인가. 좋은 에이전트 메모리 아키텍처는 많이 저장하는 구조가 아니라, 저장·로드·승격 규칙이 분리된 구조에 가깝다.


핵심 요약

  • 작업 상태, 세션 복구, 장기 지식은 같은 메모리가 아니다.
  • 좋은 메모리 구조는 저장량보다 로드 규칙이 먼저다.
  • 메모리 승격 규칙이 없으면 저장소는 금방 오염된다.
  • schema, provenance, retention이 없으면 메모리는 기능이 아니라 오염원이 된다.

1. memory architecture를 검색 품질 문제로만 보면 놓치는 것

메모리를 검색 품질로만 보면 "더 잘 찾는가"에만 집중하게 된다. 하지만 운영에서는 그보다 먼저 봐야 할 것이 있다.

  • 이 정보는 지금 필요한가
  • 이 정보는 다음 세션도 필요한가
  • 이 정보는 장기 자산이 될 가치가 있는가
  • 이 정보는 잘못됐을 때 누가 수정하는가

즉 메모리 아키텍처는 검색보다 먼저 수명과 위치의 문제다.

2. 작업 상태, 세션 복구, 장기 지식은 같은 메모리가 아니다

메모리를 한 덩어리로 보면 금방 혼란스러워진다. 실무에서는 최소한 세 층으로 나누는 편이 좋다.

메모리 층 예시 수명
작업 상태 현재 목표, 체크포인트, 다음 행동 짧음
세션 복구 handoff, session note, 미검증 항목 중간
장기 지식 반복 규칙, taxonomy, 실패 교훈, 운영 원칙

이 구분이 없으면 작업 메모가 장기 기억처럼 쌓이고, 장기 자산이 대화 이력에 묻힌다.

3. 좋은 메모리 구조는 저장보다 로드 규칙이 먼저다

많이 저장하는 것보다 더 중요한 건 언제 무엇을 활성 컨텍스트로 올릴지다.

로드 규칙이 없으면:

  • 중요한 규칙이 묻힌다
  • 불필요한 과거 문맥이 계속 따라온다
  • 오래된 정보가 현재 규칙처럼 보인다
  • 컨텍스트 비용이 커진다

좋은 로드 규칙은 보통 아래를 묻는다.

  1. 지금 목표에 직접 필요한가
  2. 현재 결정에 영향을 주는가
  3. 오래됐지만 아직 유효한가
  4. 출처와 신뢰도를 확인할 수 있는가

4. 무엇을 즉시 컨텍스트에 넣고 무엇을 외부에 둘 것인가

항상 보여야 하는 메모리와 필요할 때만 불러와야 하는 메모리는 다르다.

즉시 컨텍스트 외부 메모리
역할, 금지사항, 현재 목표 긴 참고 자료
현재 작업의 핵심 제약 과거 session note
지금 당장 적용할 규칙 장기 지식 저장소

이 구분이 없으면 메모리는 편의 기능이 아니라, 컨텍스트 오염 경로가 된다.

5. 메모리 승격 규칙이 없으면 저장소는 금방 오염된다

메모리의 가장 큰 문제는 저장 용량이 아니라 승격 기준 부재다.

아무 정보나 장기 메모리로 올리면:

  • 오래된 임시 판단이 영구 규칙처럼 남고
  • 잘못된 정보가 반복 재사용되고
  • 같은 내용의 중복 메모가 쌓이고
  • 메모리 신뢰도가 떨어진다

좋은 승격 규칙은 보통 이렇게 묻는다.

  • 이 정보는 반복해서 재사용될 가능성이 있는가
  • 이 정보는 특정 세션이 아니라 여러 작업에 적용되는가
  • 출처가 명확한가
  • 사람이 나중에 수정·삭제할 수 있는가

6. schema, provenance, retention이 왜 구조의 핵심인가

메모리가 운영 자산이 되려면 적어도 세 가지가 필요하다.

요소
schema 어떤 필드로 저장되는가
provenance 어디서 왔는가
retention 언제 유지/삭제되는가

이 셋이 없으면 메모리는 쌓일수록 더 덜 믿을 만해진다.

7. memory ownership과 memory architecture가 만나는 지점

메모리 소유권은 "누가 메모리를 우리 자산으로 본 것인가"의 문제이고, 메모리 아키텍처는 "그 자산을 어떤 구조로 유지할 것인가"의 문제다.

둘은 분리되지만 연결된다.

  • ownership이 없으면 architecture가 플랫폼 내부 기능으로 잠길 수 있다
  • architecture가 없으면 ownership은 선언만 있고 실제 구조가 없다

즉 좋은 메모리 시스템은 소유권과 구조가 같이 있어야 한다.

8. 플랫폼 메모리 위에서도 팀이 직접 가져야 할 설계 권한

플랫폼이 메모리 기능을 제공하는 것은 편하다. 하지만 팀은 여전히 아래를 직접 가져야 한다.

  • 어떤 메모리를 장기로 승격할지
  • 어떤 메모리를 삭제할지
  • 어떤 출처 정보를 남길지
  • 어떤 로드 규칙을 적용할지

즉 메모리를 어디에 저장하느냐보다, 어떤 규칙으로 운영하느냐가 더 중요하다.

9. 결론: 좋은 메모리 아키텍처는 더 많이 저장하지 않고, 더 선명하게 구분한다

좋은 메모리 구조는 모든 걸 저장하려 하지 않는다. 대신 아래를 더 선명하게 가른다.

  • 지금 필요한 것과 나중에 불러올 것
  • 일회성 상태와 장기 자산
  • 저장과 로드
  • 메모리와 컨텍스트

결국 메모리 아키텍처의 핵심은 양이 아니라 구분 규칙이다.

함께 읽으면 좋은 글

참고 자료

시리즈 전체 안내: 시리즈 목차

댓글

이 블로그의 인기 게시물

"LLM 핵심 학습 (1/6) — 기본: 토큰화·임베딩·어텐션·위치 인코딩"

"LLM 핵심 학습 (2/6) — 파인튜닝: LoRA·QLoRA·증류·Adapter"

"ML 기초 학습 (1/9) — 머신러닝과 sklearn: 학습의 좌표계"