OpenClaw 메모리 설정을 중심으로 openClaw 에이전트에게 성격을 입혔다면, 이제 기억력을 줄 차례입니다. 아무리 성격이 좋아도 어제 한 이야기를 오늘 까먹는 AI라면 답답하겠죠?
OpenClaw의 메모리 시스템은 단순히 “대화 기록 저장”이 아닙니다. 계층화된 기억 구조를 설계해서, 중요한 건 항상 기억하고 사소한 건 알아서 정리하게 만드는 시스템입니다. 이번 편에서 그 구조를 완전히 파헤쳐 보겠습니다.
메모리 시스템의 전체 그림
OpenClaw의 메모리는 5개 계층으로 나뉩니다. 사람의 기억과 비슷하게 생각하시면 됩니다.
┌─────────────────────────────────────────┐
│ L1. Thin Core (항상 기억) │
│ MEMORY.md + core-rules-thin.md │
│ → 장기 규칙, 핵심 선호 │
├─────────────────────────────────────────┤
│ L2. Session Focus (지금 하는 일) │
│ context/current-task.md │
│ → 현재 작업 1개만 유지 │
├─────────────────────────────────────────┤
│ L3. Project Memory (프로젝트별 상태) │
│ context/projects/*.md │
│ → 프로젝트 목표, 진행 상태, 다음 액션 │
├─────────────────────────────────────────┤
│ L4. Daily Trace (오늘 한 일) │
│ memory/YYYY-MM-DD.md │
│ → 당일 진행, 결정, 핸드오프 │
├─────────────────────────────────────────┤
│ L5. Archive (과거 기록) │
│ context/archive/*, archive/* │
│ → 완료/비활성 상세, 필요 시만 조회 │
└─────────────────────────────────────────┘핵심 원칙은 Thin Core + On-demand입니다. 모든 걸 항상 들고 다니면 컨텍스트가 비대해지고, 에이전트가 핵심을 놓치기 시작합니다. 중요한 것만 항상 기억하고, 나머지는 필요할 때 꺼내보는 구조가 이상적입니다.
[스크린샷: 메모리 계층 다이어그램 — 피라미드 형태]
MEMORY.md — 에이전트의 장기 기억
MEMORY.md는 에이전트가 매 대화를 시작할 때마다 읽는 파일입니다. 여기에 적힌 내용은 에이전트가 “항상 알고 있는 사실”이 됩니다.
뭘 넣어야 하나?
✅ 넣어야 할 것:
- 장기적으로 반복 적용할 규칙
- 커뮤니케이션 선호 (말투, 보고 방식)
- 충돌 처리 우선순위
- 승인 기준 (장기 원칙)
- 핵심 인프라 참조 경로
❌ 넣지 말아야 할 것:
- 프로젝트별 세부 진행 상태
- 일시적인 작업 메모
- 이미 종료된 이슈
- 가격표, 상세 로그
- 다른 파일과 중복되는 내용
나쁜 예시 vs 좋은 예시
❌ 나쁜 예시 — 모든 걸 때려넣은 MEMORY.md:
## 메모리
- 2026-03-15: 서버 재시작함
- 2026-03-16: KK님이 커피 좋아한다고 함
- 2026-03-17: 블로그 글 3개 작성, SEO 키워드는 ...
- 2026-03-18: 워드프레스 플러그인 업데이트함
- 2026-03-19: 트레이딩 봇 수익률 -2.3%
- 2026-03-20: 서버 다시 재시작...
(100줄 이상 계속...)이렇게 쓰면 에이전트가 매번 불필요한 정보를 읽느라 컨텍스트를 낭비합니다. 그리고 정작 중요한 규칙이 묻혀버립니다.
✅ 좋은 예시 — 핵심 규칙만 담은 MEMORY.md:
## 1. 장기 커뮤니케이션 선호
- 항상 존댓말 사용
- 핵심부터 먼저 말한다
- 불확실한 내용은 명시적으로 밝힌다
- 명시 실행 지시가 있으면 즉시 실행, 불필요한 되묻기 금지
## 2. 승인 기준
외부 전송, 공개 게시, 설정 변경 → 명시적 승인 필요
정보 검색, 문서 정리, 분석 → 허용
## 3. 인프라 참조
- 서버 접근: context/entities/infra.md 참조
- 워크플로우: context/entities/workflows.md 참조차이가 느껴지시나요? 좋은 MEMORY.md는 “이 에이전트가 항상 지켜야 할 규칙 모음”입니다.
[스크린샷: 실제 MEMORY.md 파일 — 핵심 섹션 구조]
memory/ 폴더 — 일일 기록
memory/ 폴더에는 날짜별 파일이 쌓입니다.
memory/
├── 2026-03-28.md
├── 2026-03-29.md
├── 2026-03-30.md
└── 2026-04-01.md뭐가 기록되나?
에이전트가 하루 동안 작업한 내용 중 다음 세션에서 참고할 만한 것을 여기에 기록합니다.
## 블로그 SEO 보강 작업 완료 (2026-04-01 18:27 KST)
### 작업 내용
- 13개 블로그 글에 H2 소제목 추가 + SEO 보강
- 각 글마다: H2 4~6개, 내부링크 3개, 외부링크 1~2개
### 처리된 글
| ID | 제목 | 포커스 키워드 |
|---|---|---|
| 157 | 블로그 이전의 의미 | 블로그 이전 |
| 132 | 자동화는 완성이 아니라 유지다 | 자동화 유지 |
...일일 기록의 활용
에이전트는 새 세션을 시작할 때 어제의 기록을 참고할 수 있습니다. “어제 뭐 했더라?”를 기억하는 거죠. 이걸 통해:
- 작업 연속성 유지 (어제 하다 만 작업 이어하기)
- 결정 기록 참조 (왜 그렇게 했는지 근거)
- 실수 반복 방지 (어제 삽질한 건 다시 안 하기)
기록 기준
모든 걸 기록하면 안 됩니다. 기록할 가치가 있는 건:
- 사용자 선호/규칙 변경 — “KK님이 이런 방식을 선호한다고 하심”
- 중요 결정 — “A 대신 B 방식으로 가기로 결정”
- 다음 세션 연속성에 필수인 상태 변화 — “서버 설정을 X로 변경함”
- 반복 실수를 막는 교훈 — “이 API는 rate limit이 10/분임”
context/ 폴더 — 프로젝트별 맥락 관리
여기가 메모리 시스템의 진짜 파워가 나오는 곳입니다. 프로젝트별로 상태를 관리하면 에이전트가 각 프로젝트의 맥락을 정확히 이해합니다.
기본 구조
context/
├── current-task.md ← 지금 하고 있는 작업 (1개만!)
├── core-rules-thin.md ← 최소 운영 규칙
├── projects/
│ ├── dashboard.md ← 프로젝트 요약 보드
│ ├── blog-seo.md ← 프로젝트별 상세
│ ├── trading-bot.md
│ └── ...
├── entities/
│ ├── infra.md ← 서버/인프라 접근 정보
│ ├── workflows.md ← 자동화 워크플로우
│ └── kk-preferences.md ← 갱신형 선호 설정
└── archive/ ← 완료된 프로젝트current-task.md — “지금 뭐 하고 있어?”
이 파일은 현재 진행 중인 작업 딱 1개만 유지합니다.
# Current Task
## NOW
블로그 SEO 시리즈 4편 작성 중
## Context
- 1편 초안 완료, KK님 검토 대기
- 2편 작성 시작
## Next
- 2편 초안 완성 → KK님 검토 요청왜 1개만? 여러 개를 넣으면 에이전트가 “지금 뭘 해야 하지?”를 판단하느라 에너지를 낭비합니다. 현재 포커스는 항상 명확하게.
projects/ — 프로젝트 보드
각 프로젝트마다 상태 파일을 만듭니다.
# Blog SEO Project
- **Status:** Active
- **Last Updated:** 2026-04-01
- **Objective:** hisoka.blog SEO 최적화 및 콘텐츠 보강
## Current Phase
OpenClaw 최적화 시리즈 4편 작성
## Next Action
1편 검토 후 발행
## Completed
- 13개 기존 글 H2/내부링크/외부링크 보강 (2026-04-01)중요 규칙: Active 프로젝트는 최대 3개로 제한하세요. 그래야 에이전트가 우선순위를 명확히 판단합니다.
[스크린샷: context/projects/ 폴더 구조와 dashboard.md 예시]
entities/ — 참조 정보
자주 참조하는 정보를 별도 파일로 관리합니다.
# infra.md — 인프라 접근 정보
## OCI 서버
- SSH: ssh -i ~/.ssh/oci_key.pem ubuntu@134.xxx.xxx.xxx
- 용도: 워드프레스 호스팅, 대시보드
## 기타 서비스
- Notion: https://notion.so/...
- ...이렇게 하면 에이전트가 “서버 접속해줘”라고 할 때 매번 IP를 물어보지 않고, entities 파일을 참조합니다.
시맨틱 검색 설정 — AI가 기억을 “검색”하게 만들기
메모리 파일이 많아지면, 에이전트가 매번 전부 읽을 수 없습니다. 이때 시맨틱 검색이 빛을 발합니다. 에이전트가 질문에 관련된 기억만 골라서 꺼내보는 기능입니다.
로컬 임베딩으로 무료 설정하기
시맨틱 검색에는 “임베딩 모델”이 필요한데, 보통은 OpenAI나 Google 같은 외부 API를 씁니다. 하지만 Ollama를 쓰면 완전 무료로 로컬에서 돌릴 수 있습니다!
Step 1: Ollama 설치 (아직 없다면)
# macOS
brew install ollama
# 또는 공식 사이트에서 다운로드
# https://ollama.comStep 2: 임베딩 모델 다운로드
ollama pull nomic-embed-text274MB 정도 되는 가벼운 모델입니다. 다운로드에 1~2분.
Step 3: openclaw.json에 Ollama 설정 추가
아직 Ollama가 설정되어 있지 않다면, 모델 provider를 추가해야 합니다:
{
"models": {
"providers": {
"ollama": {
"baseUrl": "http://localhost:11434",
"api": "ollama",
"models": []
}
}
}
}Step 4: 메모리 검색 provider를 Ollama로 설정
{
"agents": {
"defaults": {
"memorySearch": {
"enabled": true,
"provider": "ollama",
"model": "nomic-embed-text",
"fallback": "none"
}
}
}
}또는 터미널에서 에이전트에게 설정을 요청해도 됩니다:
“메모리 시맨틱 검색을 Ollama nomic-embed-text로 설정해줘”
Step 5: 게이트웨이 재시작
openclaw gateway restart재시작하면 자동으로 메모리 인덱싱이 시작됩니다.
[스크린샷: openclaw status에서 Memory search 항목이 ready로 표시되는 화면]
시맨틱 검색이 동작하면?
에이전트가 이런 질문을 받았을 때:
“지난번에 서버 설정 어떻게 바꿨더라?”
기존에는 최근 대화만 참조했다면, 시맨틱 검색이 켜지면 memory/ 폴더의 과거 기록에서 “서버 설정 변경”과 관련된 내용을 자동으로 찾아서 참조합니다. 마치 AI가 일기장을 넘겨보는 것과 같습니다.
컴팩션 설정 — 대화가 길어져도 맥락 유지하기
한 세션에서 대화가 길어지면 컨텍스트 창(context window)이 부족해집니다. 이때 OpenClaw의 컴팩션 기능이 오래된 대화를 요약해서 압축합니다.
기본 설정
{
"agents": {
"defaults": {
"compaction": {
"mode": "safeguard",
"reserveTokens": 16000,
"keepRecentTokens": 8000,
"maxHistoryShare": 0.6,
"recentTurnsPreserve": 5
}
}
}
}각 항목의 의미:
reserveTokens— 새 응답 생성에 남겨둘 토큰keepRecentTokens— 최근 대화에서 보존할 토큰maxHistoryShare— 전체 컨텍스트에서 대화 이력이 차지할 최대 비율recentTurnsPreserve— 최근 N턴은 원문 그대로 보존
커스텀 컴팩션 지시
컴팩션 요약의 형식을 지정할 수도 있습니다:
{
"compaction": {
"customInstructions": "컴팩션 요약은 아래 구조로 생성하라:\n\n## Goal\n현재 목표\n\n## Progress\n완료된 작업\n\n## Next Steps\n다음 할 일\n\n## Critical Context\n파일 경로, 서버 주소 등 정확한 값"
}
}이렇게 하면 컴팩션이 일어나도 핵심 맥락(파일 경로, 서버 주소 등)이 사라지지 않습니다.
[스크린샷: 컴팩션 전후 비교 — 대화 길이 변화]
메모리 위생 관리 — 정리도 전략이다
기록 형식 표준화
기록을 남길 때 이런 형식을 따르면 나중에 찾기 쉽습니다:
## [작업명] (날짜 시간)
- **상황:** 무엇이 있었는지
- **결정:** 뭘 결정했는지
- **영향:** 어떤 변화가 생겼는지
- **다음 액션:** 다음에 뭘 해야 하는지자동 정리 팁
- LaunchAgent로 자동 정리 스케줄링
“bash # 매일 새벽 3시에 메모리 정리 스크립트 실행 # (OpenClaw 설정에서 설정 가능) “
- 오래된 daily log는 archive로
- 2주 이상 된 memory/ 파일은 자동으로 archive/로 이동
- MEMORY.md는 분기 1회 리뷰
- 더 이상 유효하지 않은 규칙 정리
- 반복되는 새 패턴 추가
프로젝트 상태 관리
Inbox → Active → (Blocked/Waiting) → Done → Archived- Active는 최대 3개 — 그래야 집중할 수 있음
- Done은 1~2주 후 Archived — 바로 치우지 말고 버퍼 기간
- Archived는 필요할 때 다시 꺼내기 가능
실전: 메모리 시스템 처음 구축하기
Day 1: 최소 설정
# 1. MEMORY.md에 핵심 규칙 3~5개 적기
nano ~/.openclaw/workspace/MEMORY.md
# 2. context/ 폴더 구조 만들기
mkdir -p ~/.openclaw/workspace/context/projects
mkdir -p ~/.openclaw/workspace/context/entities
# 3. current-task.md 생성
echo "# Current Task\n\n## NOW\n아직 없음" > ~/.openclaw/workspace/context/current-task.mdWeek 1: 관찰하기
일주일간 에이전트와 대화하면서:
- 에이전트가 까먹는 것들 → MEMORY.md에 추가
- 반복 참조하는 정보 → entities/에 파일 생성
- 진행 중인 프로젝트 → projects/에 상태 파일 생성
Month 1: 구조화하기
한 달이 지나면:
- memory/ 폴더에 일일 로그가 쌓여 있을 겁니다
- MEMORY.md가 좀 길어졌을 겁니다 → 핵심만 남기고 정리
- 시맨틱 검색 설정 → 과거 기억도 검색 가능하게
마무리 — 기억은 힘이다
메모리 시스템을 잘 설계하면 에이전트와의 대화가 누적적이 됩니다. 매번 처음부터 설명할 필요 없이, 에이전트가 맥락을 이해한 상태에서 대화가 시작됩니다.
이게 일반 챗봇과 개인 AI의 결정적 차이입니다.
핵심을 다시 정리하면:
- MEMORY.md는 가볍게 — 장기 규칙만
- memory/는 일일 기록 — 연속성 유지
- context/는 프로젝트별 — 체계적 관리
- 시맨틱 검색은 Ollama로 — 무료, 로컬
- 정리도 전략 — 쌓기만 하면 무너진다
다음 편에서는 모델 선택과 비용 최적화, 그리고 스킬 활용을 다루겠습니다. OpenClaw를 돈 아끼면서 똑똑하게 쓰는 법, 기대해주세요!
관련 글:
참고 자료:
- OpenClaw 공식 문서 — 메모리 시스템 상세
- Ollama 공식 사이트 — 로컬 모델 설치