에이전트 기억 아키텍처 (Agent Memory Architecture)
AI 에이전트가 정보를 저장·유지·승격하는 3단계 기억 구조. 대화 맥락(휘발) → 메모리 파일(반영구) → 시스템 파일(영구)의 계층으로, 중요도에 따라 정보가 승격된다. RAG 대신 Full-context Loading을 택하는 이유와 Prompt Caching을 통한 비용 최적화도 포함한다. 핵심 원칙: “대화는 휘발되지만, 파일은 남는다.”
기억의 3단계 구조
┌─────────────────────────────────────────┐
│ 3단계: 시스템 파일 (영구) │
│ AGENTS.md, MEMORY.md │
│ → 매 대화 자동 로딩, 절대 안 까먹음 │
│ → 컴팩션 대상이 아님 │
├─────────────────────────────────────────┤
│ 2단계: 메모리 파일 (반영구) │
│ memory/YYYY-MM-DD.md │
│ → 세션 간 공유, 파일로 보존 │
│ → 필요 시 수동으로 읽기 │
├─────────────────────────────────────────┤
│ 1단계: 대화 맥락 (휘발) │
│ 세션 내 대화 히스토리 │
│ → 컴팩션 대상, 세션 종료 시 위험 │
│ → 기억 보존 시 파일로 승격 필요 │
└─────────────────────────────────────────┘
(출처: bbojjak-openclaw-memory-architecture-lesson08)
1단계: 대화 맥락 — 휘발성 기억
현재 세션에서 주고받은 대화 내용. 특성:
- 컨텍스트 윈도우가 꽉 차면 컴팩션으로 요약 압축됨 (agent-session-architecture 참조)
- 세션이 닫히면 접근 불가 (다음 세션에서 읽을 수 없음)
- 가장 빠르게 접근 가능하지만 가장 취약
2단계: 메모리 파일 — 반영구 기억
memory/2026-03-06.md처럼 날짜별 일일 기록 파일. 특성:
- 세션이 닫혀도 파일은 남아있음
- 다른 세션에서 파일을 읽으면 맥락 복원 가능
- 에이전트가 직접 기록하거나 사용자 요청으로 기록
- 수동으로 읽어야 하므로 자동 적용은 아님
3단계: 시스템 파일 — 영구 기억
AGENTS.md, MEMORY.md처럼 매 대화마다 자동 로딩되는 파일. 특성:
- agent-runtime-architecture의 시스템 프롬프트 자동 조립 레이어에서 주입
- 컴팩션 대상이 아님 — 컨텍스트 윈도우가 꽉 차도 원본 유지
- 어떤 세션에서든 항상 적용됨
- 절대 규칙(agent-error-learning-loop)이 이 3단계에 저장돼 영구 적용됨
기억 승격 전략
Hermes 운영 사례에서는 “충분한 개인 맥락을 넣고 반복 작업을 맡기는 시간”이 품질 복리로 돌아온다고 설명한다. 이는 기억 아키텍처가 단순 저장소가 아니라 브리핑·SNS 초안·오류 감지 같은 자동화 결과의 개인화 품질을 개선하는 피드백 자산이라는 점을 보여준다. (출처: yt-WXka6bp1aYw-헤르메스-에이전트-20분-총정리)
추가로 z2zlife 영상은 “대화 기록 전체를 배낭처럼 들고 다니는 것”과 “사용자 핵심 프로필만 가볍게 주입하는 것”을 대비한다. 이 비유는 장기 기억 설계의 핵심이 모든 로그 보존이 아니라 반복 품질에 영향을 주는 선호·맥락을 선별해 주입하는 데 있음을 설명한다. (출처: yt-GsMB3SHHlzI-Hermes-Agent-완벽-구축-가이드)
대화에서 중요한 것 발견 (1단계)
↓ 즉시 기록
memory/ 일일 파일에 기록 (2단계)
↓ 핵심이라면
MEMORY.md 또는 AGENTS.md에 반영 (3단계)
실전 명령어: “이거 MEMORY.md에 추가해줘” — 대화 맥락(1단계)에서 영구 기억(3단계)으로 즉시 승격.
컴팩션과 기억 보호
agent-session-architecture의 컴팩션 메커니즘에 대응하는 기억 보호 전략:
| 보호 계층 | 방법 | 보장 수준 |
|---|---|---|
| 1차 보호 | 시스템 파일에 저장 | 완전 보장 (컴팩션 대상 외) |
| 2차 보호 | memory/ 파일에 기록 | 파일 삭제 전까지 보장 |
| 취약 구간 | 1단계 대화 맥락만 의존 | 컴팩션 시 디테일 손실 가능 |
비유: 칠판(대화)은 꽉 차면 지움 → 노트(memory/)에 옮기면 안전 → 교실 벽(AGENTS.md)에 붙이면 매일 확인 가능.
Full-context Loading vs RAG
에이전트 기억의 대안적 접근법 비교:
| 기준 | Full-context Loading | RAG |
|---|---|---|
| 적합 규모 | ~10개 문서 | 수백~수천 개 문서 |
| 검색 누락 | 없음 (전체 포함) | 유사도 검색 오류 가능 |
| 구축 복잡도 | 없음 | 벡터 DB + 임베딩 파이프라인 필요 |
| 응답 정확성 | 높음 (문맥 완전) | 검색 품질에 의존 |
| 비용 | 토큰 비용 (Prompt Caching으로 완화) | 검색 인프라 비용 |
선택 기준: 에이전트 운영 파일이 ~10개 수준이면 Full-context Loading이 최선. 기업 지식 베이스(수천 페이지)라면 RAG가 필요.
기존 rag 개념과 대비: LLM Wiki도 RAG 대신 index-first-retrieval(인덱스 파일을 먼저 읽고 탐색) 방식을 사용한다 — Full-context Loading과 유사한 철학.
Prompt Caching — 시스템 프롬프트 비용 최적화
Anthropic API 레벨의 비용 최적화 메커니즘:
시스템 프롬프트 (변경 적음) → 캐시 적중 → 90% 비용 절감
대화 히스토리 (매번 변경) → 캐시 미적중 → 일반 요금
최적 구조: 시스템 프롬프트(잘 안 바뀌는 것)를 컨텍스트 앞에, 대화(매번 바뀌는 것)를 뒤에 배치. 에이전트 런타임(agent-runtime-architecture)이 자동으로 이 배치를 유지.
사용자가 별도 설정할 필요 없음 — 런타임이 자동 최적화.
적용 조건: Anthropic API의 Prompt Caching은 캐시 TTL(5분)이 있으므로, 같은 시스템 프롬프트로 5분 내 재요청 시 캐시 적중.
세션 생애주기와 기억 통합
agent-session-architecture의 세션 생애주기에 기억 관점을 추가:
1. 세션 탄생 → 3단계 시스템 파일 자동 로딩 (6개 파일)
2. 대화 축적 → 1단계 맥락 누적
3. 컴팩션 → 1단계 일부 요약 압축
4. 기억의 전이 → 중요 내용을 2단계 파일로 기록
5. 세션 종료 → 파일(2,3단계)만 생존
6. 다음 세션 → 시스템 파일 자동 로딩 + 필요 시 memory/ 수동 읽기
실전 운영 팁
Tip
3가지 습관이 에이전트 기억을 최대한 활용한다.
- “이거 MEMORY.md에 추가해줘” — 중요 결정 즉시 영구 승격
- 채널 분리 — 주제별 세션 분리로 컨텍스트 오염 방지 (각 세션 컴팩션 빈도 감소)
- 시스템 파일 관리 — 반복 중요 정보는 AGENTS.md에 저장 (절대 안 까먹음)
능동적 compact — 토큰 최적화 관점
자동 컴팩션(95%)은 맥락 유실 위험이 있다. 실전 운영 규칙: (출처: bbojjak-openclaw-token-optimization-lesson16)
- 10만 토큰 → 능동적으로 compact 실행
- 15만 토큰 → memory/ 파일에 중요 내용 기록 후 세션 정리
이 규칙을 AGENTS.md에 넣으면 에이전트가 스스로 모니터링하고 실행한다. → agent-token-optimization 참조.
Lore형 의사결정 기억 사례
yt-autopus-adk-16agent-framework-2026의 Lore 메커니즘은 기억 3단계 중 2→3단계 승격을 운영 규칙으로 강제하는 사례다.
- 코드 저장 시 Why / Decision / Alternatives 자동 기록
- 90일 재검토 리마인드로 장기 의사결정 품질 관리
- “일주일 전 내가 왜 이렇게 짰는지”를 팀 지식처럼 복원
이는 단순 로그 보관이 아니라, 결정 근거를 재사용 가능한 시스템 기억으로 승격하는 패턴으로 볼 수 있다.
프레임워크별 메모리 아키텍처 비교 (OpenClaw vs Hermes)
(출처: openclaw-hermes-comparison-session)
| 항목 | OpenClaw | hermes-agent |
|---|---|---|
| 기본 저장소 | Markdown 파일 (무제한) | MEMORY.md(2,200자) + USER.md(1,375자) |
| 검색엔진 | Builtin BM25+벡터 / QMD | 외부 프로바이더 경유 |
| Active Memory | ✅ 응답 전 자동 주입 | ❌ 없음 |
| 외부 메모리 | Honcho 공식 플러그인 | 8종 중 1개 선택 (싱글셀렉트) |
| Compaction flush | ✅ 자동 실행 | ❌ |
| 사용자 모델링 | Honcho 깊은 통합 | Honcho 선택 가능 |
Active Memory — OpenClaw 독자 기능
Hermes Agent에 없는 메커니즘. 메인 응답 생성 전에 실행되는 선택적 블로킹 메모리 서브에이전트. 대부분의 메모리 시스템이 “반응적”인 반면, Active Memory는 프리액티브(proactive) 구조다.
사용자 메시지 수신
↓
Active Memory 서브에이전트 실행 (블로킹, 메인 응답 전)
↓
과거 메모리 검색 → 관련 내용 있으면 숨겨진 컨텍스트로 주입
↓
메인 에이전트가 그 컨텍스트를 포함하여 응답 생성
쿼리 모드 3가지: message(최신 메시지만, 가장 빠름) / recent(최신 + 대화 꼬리, 균형) / full(전체 대화, 최고품질)
Hermes 외부 메모리 프로바이더
honcho가 가장 기능이 넓음. 단순 키워드 저장(순수 내장 메모리)과의 핵심 차이:
- 자동 팩트 추출: Deriver 백그라운드 워커가 각 응답 후 자동 동기화
- 의미론적 검색: 말이 달라도 관련 메모리 검색
- Dreaming: 비활성 시 백그라운드 추론 지속
- 컨텍스트 무제한: 검색으로 필요한 것만 주입 (내장 ~1,300토큰 한계 극복)
관련 개념
- agent-session-architecture — 컴팩션 메커니즘 + 세션 수명 (기억의 1단계 기반)
- agent-workspace-structure — memory/ 폴더 + 시스템 파일 물리 구조
- agent-error-learning-loop — AGENTS.md 절대 규칙 = 3단계 영구 기억으로 보장
- agent-runtime-architecture — 시스템 프롬프트 자동 조립 + Prompt Caching 레이어
- rag — RAG vs Full-context Loading 비교 (소규모 에이전트 vs 기업 규모)
- agent-token-optimization — 능동적 compact 전략; 대화 히스토리 = 4위 소비처
소스
- bbojjak-openclaw-memory-architecture-lesson08
- bbojjak-openclaw-token-optimization-lesson16 (능동적 compact 운영 기준)
- yt-autopus-adk-16agent-framework-2026 (Lore 기억 시스템: Why/Decision/Alternatives + 90일 재검토)
- openclaw-hermes-comparison-session (Active Memory + Hermes 8종 외부 프로바이더 상세)