OpenClaw가 예전 결정을 반복하거나 이미 끝난 일을 다시 제안한다면, 기억의 양보다 저장 위치와 상태 갱신부터 살펴보세요. 이 글은 장기 규칙·프로젝트 상태·일일 기록을 나누고, 서로 다른 기억이 나왔을 때 판단할 기준을 정리합니다.
2026년 4월 1일 저는 OpenClaw를 운영하며 장기 규칙, 현재 작업, 프로젝트 상태, 일일 기록, 보관 자료를 서로 다른 층으로 나눴습니다. 이 글은 그 개인 운영 구조에서 얻은 기준을 다시 정리한 것입니다. OpenClaw의 공식 기본 폴더나 현재 버전의 필수 설정을 설명하는 문서는 아닙니다.
기억의 목적부터 다섯 층으로 나눴습니다
항상 적용할 장기 규칙
├─ 지금 수행 중인 작업
├─ 프로젝트별 상태와 다음 행동
├─ 날짜별 작업 흔적
└─ 완료되었거나 드물게 찾는 보관 자료핵심은 모든 파일을 항상 읽히지 않는 것입니다. 매번 적용해야 하는 최소 규칙만 얇게 유지하고, 프로젝트 상세와 과거 기록은 필요할 때 검색하거나 열도록 했습니다. 이 구조는 당시 제가 만든 운영 방식이며 실제 폴더 이름은 환경에 맞게 바꿀 수 있습니다.
| 기억 층 | 남길 내용 | 갱신 시점 |
|---|---|---|
| 장기 규칙 | 말투, 승인 경계, 반복 적용할 원칙 | 원칙이 바뀔 때 |
| 현재 작업 | 지금 목표, 진행 상태, 바로 다음 행동 | 작업 전환 때 |
| 프로젝트 상태 | 목표, 결정, 확인 근거, 남은 일 | 의미 있는 변화 때 |
| 일일 기록 | 그날의 결정과 다음 세션에 필요한 흔적 | 작업 종료 때 |
| 보관 자료 | 완료된 상세, 과거 로그, 드문 참조 | 활성 범위에서 빠질 때 |
장기 기억에는 사실보다 적용 조건을 적습니다
장기 파일은 에이전트가 매번 참고할 가능성이 높기 때문에 짧아야 합니다. “존댓말 사용”, “외부 공개 전 승인 확인”, “불확실하면 확인 범위를 표시”처럼 여러 작업에 반복 적용되는 기준이 적합합니다.
- 넣을 것: 장기 선호, 승인 기준, 충돌 시 우선순위, 다른 문서의 위치
- 빼둘 것: 하루짜리 할 일, 오래된 오류 로그, 프로젝트별 세부 상태, 자주 바뀌는 가격과 수치
- 금지할 것: 비밀번호, 토큰, 복구 코드, 그대로 실행 가능한 민감한 접속 정보
서버 주소 같은 운영 정보가 필요하더라도 장기 규칙에 직접 복사하기보다 접근이 제한된 별도 저장소를 참조하게 하는 편이 낫습니다. 기억 파일은 편리하지만 비밀 저장소를 대신하지 않습니다.
프로젝트 상태는 결론과 근거를 함께 남깁니다
“완료”라는 한 단어만 남기면 다음 세션에서 무엇을 확인했는지 알 수 없습니다. 당시에는 프로젝트별 파일에 현재 단계와 다음 행동을 적었고, 지금 다시 본다면 확인한 환경과 근거도 함께 두는 것이 더 안전합니다.
프로젝트:
현재 상태:
확인한 환경과 시각:
근거:
아직 확인하지 못한 범위:
다음 행동과 담당:현재 작업 파일에는 여러 프로젝트를 동시에 넣지 않고, 실제로 다음에 수행할 하나의 작업을 중심으로 유지했습니다. 숫자 제한 자체가 정답은 아니지만, 작업 전환 때 오래된 목표를 지우는 규칙은 필요했습니다.
일일 기록은 원문 로그가 아니라 핸드오프입니다
날짜별 기록에는 대화 전문보다 다음 세션에서 이어갈 때 필요한 내용을 남겼습니다. 결정한 이유, 실제로 바뀐 상태, 실패한 접근과 다음 시도처럼 반복 작업을 줄이는 정보가 우선입니다.
- 오늘 실제로 확인한 결과
- 결정과 그 근거
- 다음 작업자가 시작할 위치
- 남은 위험과 미확인 항목
- 장기 규칙이나 프로젝트 보드로 옮겨야 할 내용
반대로 단순 인사, 이미 다른 문서에 있는 내용, 다시 쓸 가능성이 낮은 출력 전체를 계속 복사하면 검색 결과가 오염될 수 있습니다.
같은 프로젝트가 “완료”와 “진행 중”으로 검색된다면
최신 날짜의 메모를 무조건 정답으로 삼지 않는 것이 좋습니다. 나중에 작성된 요약이 오래된 상태를 복사했을 수도 있으므로, 기록 날짜와 실제 확인 시각을 따로 보고 근거가 무엇인지 확인합니다.
- 프로젝트 상태를 관리하는 기준 문서를 먼저 엽니다.
- 서로 다른 결론의 확인 시각, 대상 환경, 완료 범위를 비교합니다. 테스트 완료와 운영 반영 완료는 별개로 적습니다.
- 현 상태를 읽기 전용으로 확인할 수 있으면 근거를 보강합니다. 접근할 수 없다면 “마지막 확인 상태”로 표시합니다.
- 새 근거로 기준 문서를 갱신하고 일일 기록에는 변경 이유와 기준 문서 위치만 남깁니다. 과거 기록은 당시 사실이라는 맥락을 유지합니다.
이 문제는 AI 기억과 프로젝트 보드가 다를 때의 기준과 이어집니다. 반면 기준 문서는 맞는데 검색 결과에서 빠진다면 저장 구조와 검색 품질을 분리해 살펴보세요. 메모리 임베딩 실무 질의 비교 기록처럼 실제 질문과 정답 문서를 짝지어 점검하되, 과거 비교 결과를 현재 모델의 우열로 일반화하지 않습니다.
시맨틱 검색은 정확한 사실 저장을 대체하지 않습니다
기록이 많아지면 키워드 검색과 시맨틱 검색을 함께 고려할 수 있습니다. 당시에는 로컬 임베딩 모델을 이용해 관련 기억을 찾는 구성을 사용했습니다. 다만 모델 이름, 설정 키, 게이트웨이 명령은 버전에 따라 달라질 수 있어 과거 값을 그대로 적용하지 않습니다.
검색 품질은 “관련 결과가 나왔다”만으로 판단하지 않습니다. 정답 문서가 상위에 있는지, 날짜나 숫자가 원문과 같은지, 오래된 결론보다 최신 상태가 우선되는지 확인해야 합니다. 시맨틱 검색은 후보를 찾고, 최종 답변은 원문 근거를 읽어 만드는 구조가 안전합니다.
정기적으로 수행할 메모리 위생 점검
- 장기 규칙에서 중복과 종료된 항목을 제거합니다.
- 현재 작업이 실제 진행 중인 목표와 같은지 확인합니다.
- 프로젝트 상태의 확인 시각과 근거가 오래되지 않았는지 봅니다.
- 일일 기록의 중요한 결정을 프로젝트 파일로 승격합니다.
- 검색 결과에 자주 나타나는 잘못된 기억을 수정하거나 보관합니다.
- 민감한 값이 일반 메모리 파일에 들어가지 않았는지 점검합니다.
좋은 기억 시스템은 많이 저장하는 시스템이 아니라, 다음 작업에 필요한 근거를 적절한 위치에서 찾게 하는 시스템에 가깝습니다. 층을 나누는 목적도 파일을 늘리는 데 있지 않습니다. 항상 읽을 것과 필요할 때 찾을 것을 구분하는 데 있습니다.
사례 기준일: 2026-04-01. 개인 OpenClaw 운영 기록을 바탕으로 2026-09-03에 재구성했습니다. 현재 제품 버전의 폴더 구조, 설정 키, 명령 동작은 이 글에서 재검증하지 않았습니다.
편집 보완: 2026-09-10. 기존 사례와 작성·재편집 날짜를 유지하며 판단 절차와 관련 글을 보강했습니다. 이 날짜는 새 설치·성능 시험 또는 현재 운영 상태 확인을 뜻하지 않습니다.