온톨로지와 메모리 시스템 (6/13) — 좋은 에이전트 메모리 아키텍처는 어떻게 생겼나
메모리 이야기를 하면 많은 사람이 검색 품질이나 장기 기억부터 떠올린다. 물론 중요하다. 하지만 더 근본적인 문제는 따로 있다. 무엇을 어디에 두고, 언제 불러오고, 무엇을 장기 자산으로 승격할 것인가. 좋은 에이전트 메모리 아키텍처는 많이 저장하는 구조가 아니라, 저장·로드·승격 규칙이 분리된 구조에 가깝다.
핵심 요약
- 작업 상태, 세션 복구, 장기 지식은 같은 메모리가 아니다.
- 좋은 메모리 구조는 저장량보다 로드 규칙이 먼저다.
- 메모리 승격 규칙이 없으면 저장소는 금방 오염된다.
- schema, provenance, retention이 없으면 메모리는 기능이 아니라 오염원이 된다.
1. memory architecture를 검색 품질 문제로만 보면 놓치는 것
메모리를 검색 품질로만 보면 "더 잘 찾는가"에만 집중하게 된다. 하지만 운영에서는 그보다 먼저 봐야 할 것이 있다.
- 이 정보는 지금 필요한가
- 이 정보는 다음 세션도 필요한가
- 이 정보는 장기 자산이 될 가치가 있는가
- 이 정보는 잘못됐을 때 누가 수정하는가
즉 메모리 아키텍처는 검색보다 먼저 수명과 위치의 문제다.
2. 작업 상태, 세션 복구, 장기 지식은 같은 메모리가 아니다
메모리를 한 덩어리로 보면 금방 혼란스러워진다. 실무에서는 최소한 세 층으로 나누는 편이 좋다.
| 메모리 층 | 예시 | 수명 |
|---|---|---|
| 작업 상태 | 현재 목표, 체크포인트, 다음 행동 | 짧음 |
| 세션 복구 | handoff, session note, 미검증 항목 | 중간 |
| 장기 지식 | 반복 규칙, taxonomy, 실패 교훈, 운영 원칙 | 김 |
이 구분이 없으면 작업 메모가 장기 기억처럼 쌓이고, 장기 자산이 대화 이력에 묻힌다.
3. 좋은 메모리 구조는 저장보다 로드 규칙이 먼저다
많이 저장하는 것보다 더 중요한 건 언제 무엇을 활성 컨텍스트로 올릴지다.
로드 규칙이 없으면:
- 중요한 규칙이 묻힌다
- 불필요한 과거 문맥이 계속 따라온다
- 오래된 정보가 현재 규칙처럼 보인다
- 컨텍스트 비용이 커진다
좋은 로드 규칙은 보통 아래를 묻는다.
- 지금 목표에 직접 필요한가
- 현재 결정에 영향을 주는가
- 오래됐지만 아직 유효한가
- 출처와 신뢰도를 확인할 수 있는가
4. 무엇을 즉시 컨텍스트에 넣고 무엇을 외부에 둘 것인가
항상 보여야 하는 메모리와 필요할 때만 불러와야 하는 메모리는 다르다.
| 즉시 컨텍스트 | 외부 메모리 |
|---|---|
| 역할, 금지사항, 현재 목표 | 긴 참고 자료 |
| 현재 작업의 핵심 제약 | 과거 session note |
| 지금 당장 적용할 규칙 | 장기 지식 저장소 |
이 구분이 없으면 메모리는 편의 기능이 아니라, 컨텍스트 오염 경로가 된다.
5. 메모리 승격 규칙이 없으면 저장소는 금방 오염된다
메모리의 가장 큰 문제는 저장 용량이 아니라 승격 기준 부재다.
아무 정보나 장기 메모리로 올리면:
- 오래된 임시 판단이 영구 규칙처럼 남고
- 잘못된 정보가 반복 재사용되고
- 같은 내용의 중복 메모가 쌓이고
- 메모리 신뢰도가 떨어진다
좋은 승격 규칙은 보통 이렇게 묻는다.
- 이 정보는 반복해서 재사용될 가능성이 있는가
- 이 정보는 특정 세션이 아니라 여러 작업에 적용되는가
- 출처가 명확한가
- 사람이 나중에 수정·삭제할 수 있는가
6. schema, provenance, retention이 왜 구조의 핵심인가
메모리가 운영 자산이 되려면 적어도 세 가지가 필요하다.
| 요소 | 뜻 |
|---|---|
| schema | 어떤 필드로 저장되는가 |
| provenance | 어디서 왔는가 |
| retention | 언제 유지/삭제되는가 |
이 셋이 없으면 메모리는 쌓일수록 더 덜 믿을 만해진다.
7. memory ownership과 memory architecture가 만나는 지점
메모리 소유권은 "누가 메모리를 우리 자산으로 본 것인가"의 문제이고, 메모리 아키텍처는 "그 자산을 어떤 구조로 유지할 것인가"의 문제다.
둘은 분리되지만 연결된다.
- ownership이 없으면 architecture가 플랫폼 내부 기능으로 잠길 수 있다
- architecture가 없으면 ownership은 선언만 있고 실제 구조가 없다
즉 좋은 메모리 시스템은 소유권과 구조가 같이 있어야 한다.
8. 플랫폼 메모리 위에서도 팀이 직접 가져야 할 설계 권한
플랫폼이 메모리 기능을 제공하는 것은 편하다. 하지만 팀은 여전히 아래를 직접 가져야 한다.
- 어떤 메모리를 장기로 승격할지
- 어떤 메모리를 삭제할지
- 어떤 출처 정보를 남길지
- 어떤 로드 규칙을 적용할지
즉 메모리를 어디에 저장하느냐보다, 어떤 규칙으로 운영하느냐가 더 중요하다.
9. 결론: 좋은 메모리 아키텍처는 더 많이 저장하지 않고, 더 선명하게 구분한다
좋은 메모리 구조는 모든 걸 저장하려 하지 않는다. 대신 아래를 더 선명하게 가른다.
- 지금 필요한 것과 나중에 불러올 것
- 일회성 상태와 장기 자산
- 저장과 로드
- 메모리와 컨텍스트
결국 메모리 아키텍처의 핵심은 양이 아니라 구분 규칙이다.
함께 읽으면 좋은 글
- 장시간 에이전트 운영에서는 memory보다 handoff 설계가 먼저다
- Managed Agents 시대에도 팀이 직접 가져야 하는 것: 메모리, 권한, 로그, 평가의 소유권
- 좋은 에이전트 런타임은 어떻게 생겼나: 컨텍스트, 도구, 상태, 경계, 관측의 5계층
참고 자료
- Anthropic, Manage Claude's memory
- Anthropic, Managed Agents,
2026-04-08
시리즈 전체 안내: 시리즈 목차
댓글
댓글 쓰기