OpenClaw 메모리 설계: 규칙·프로젝트 상태·일일 기록을 나누는 법

OpenClaw가 예전 결정을 반복하거나 이미 끝난 일을 다시 제안한다면, 기억의 양보다 저장 위치와 상태 갱신부터 살펴보세요. 이 글은 장기 규칙·프로젝트 상태·일일 기록을 나누고, 서로 다른 기억이 나왔을 때 판단할 기준을 정리합니다.

2026년 4월 1일 저는 OpenClaw를 운영하며 장기 규칙, 현재 작업, 프로젝트 상태, 일일 기록, 보관 자료를 서로 다른 층으로 나눴습니다. 이 글은 그 개인 운영 구조에서 얻은 기준을 다시 정리한 것입니다. OpenClaw의 공식 기본 폴더나 현재 버전의 필수 설정을 설명하는 문서는 아닙니다.

기억의 목적부터 다섯 층으로 나눴습니다

항상 적용할 장기 규칙
  ├─ 지금 수행 중인 작업
  ├─ 프로젝트별 상태와 다음 행동
  ├─ 날짜별 작업 흔적
  └─ 완료되었거나 드물게 찾는 보관 자료

핵심은 모든 파일을 항상 읽히지 않는 것입니다. 매번 적용해야 하는 최소 규칙만 얇게 유지하고, 프로젝트 상세와 과거 기록은 필요할 때 검색하거나 열도록 했습니다. 이 구조는 당시 제가 만든 운영 방식이며 실제 폴더 이름은 환경에 맞게 바꿀 수 있습니다.

장기 기억에는 사실보다 적용 조건을 적습니다

장기 파일은 에이전트가 매번 참고할 가능성이 높기 때문에 짧아야 합니다. “존댓말 사용”, “외부 공개 전 승인 확인”, “불확실하면 확인 범위를 표시”처럼 여러 작업에 반복 적용되는 기준이 적합합니다.

• 넣을 것: 장기 선호, 승인 기준, 충돌 시 우선순위, 다른 문서의 위치
• 빼둘 것: 하루짜리 할 일, 오래된 오류 로그, 프로젝트별 세부 상태, 자주 바뀌는 가격과 수치
• 금지할 것: 비밀번호, 토큰, 복구 코드, 그대로 실행 가능한 민감한 접속 정보

서버 주소 같은 운영 정보가 필요하더라도 장기 규칙에 직접 복사하기보다 접근이 제한된 별도 저장소를 참조하게 하는 편이 낫습니다. 기억 파일은 편리하지만 비밀 저장소를 대신하지 않습니다.

프로젝트 상태는 결론과 근거를 함께 남깁니다

“완료”라는 한 단어만 남기면 다음 세션에서 무엇을 확인했는지 알 수 없습니다. 당시에는 프로젝트별 파일에 현재 단계와 다음 행동을 적었고, 지금 다시 본다면 확인한 환경과 근거도 함께 두는 것이 더 안전합니다.

프로젝트:
현재 상태:
확인한 환경과 시각:
근거:
아직 확인하지 못한 범위:
다음 행동과 담당:

현재 작업 파일에는 여러 프로젝트를 동시에 넣지 않고, 실제로 다음에 수행할 하나의 작업을 중심으로 유지했습니다. 숫자 제한 자체가 정답은 아니지만, 작업 전환 때 오래된 목표를 지우는 규칙은 필요했습니다.

일일 기록은 원문 로그가 아니라 핸드오프입니다

날짜별 기록에는 대화 전문보다 다음 세션에서 이어갈 때 필요한 내용을 남겼습니다. 결정한 이유, 실제로 바뀐 상태, 실패한 접근과 다음 시도처럼 반복 작업을 줄이는 정보가 우선입니다.

• 오늘 실제로 확인한 결과
• 결정과 그 근거
• 다음 작업자가 시작할 위치
• 남은 위험과 미확인 항목
• 장기 규칙이나 프로젝트 보드로 옮겨야 할 내용

반대로 단순 인사, 이미 다른 문서에 있는 내용, 다시 쓸 가능성이 낮은 출력 전체를 계속 복사하면 검색 결과가 오염될 수 있습니다.

같은 프로젝트가 “완료”와 “진행 중”으로 검색된다면

최신 날짜의 메모를 무조건 정답으로 삼지 않는 것이 좋습니다. 나중에 작성된 요약이 오래된 상태를 복사했을 수도 있으므로, 기록 날짜와 실제 확인 시각을 따로 보고 근거가 무엇인지 확인합니다.

1. 프로젝트 상태를 관리하는 기준 문서를 먼저 엽니다.
2. 서로 다른 결론의 확인 시각, 대상 환경, 완료 범위를 비교합니다. 테스트 완료와 운영 반영 완료는 별개로 적습니다.
3. 현 상태를 읽기 전용으로 확인할 수 있으면 근거를 보강합니다. 접근할 수 없다면 “마지막 확인 상태”로 표시합니다.
4. 새 근거로 기준 문서를 갱신하고 일일 기록에는 변경 이유와 기준 문서 위치만 남깁니다. 과거 기록은 당시 사실이라는 맥락을 유지합니다.

이 문제는 AI 기억과 프로젝트 보드가 다를 때의 기준과 이어집니다. 반면 기준 문서는 맞는데 검색 결과에서 빠진다면 저장 구조와 검색 품질을 분리해 살펴보세요. 메모리 임베딩 실무 질의 비교 기록처럼 실제 질문과 정답 문서를 짝지어 점검하되, 과거 비교 결과를 현재 모델의 우열로 일반화하지 않습니다.

인계 문장을 고치는 실제 사례: “ERP 복구 완료”

4월 4일 ERP 워처 장애 기록를 한 줄로 “복구 완료”라고 저장하면 다음 작업자는 입력 자동화까지 가능하다고 오해할 수 있습니다. 당시 확인한 것은 pythonw 변경 뒤 워처 생존이 안정됐다는 관찰이고, UIA 창 검색은 여전히 0개였습니다.

이 경우 프로젝트 상태에는 “워처 생존 안정 관찰, ERP 창 접근 미해결”을 적고, 근거에는 2026-04-04 기록과 실행 경로를 연결하는 편이 정확합니다. 다음 행동은 창 탐색의 사용자·세션 대조입니다. 일일 기록에는 그날 변경한 이유를 남기되, 이후 작성한 요약의 날짜를 새 실행 확인일로 바꾸지 않습니다.

이 예시는 원문 장애 기록을 메모리 구조에 맞게 옮기는 편집 예시입니다. 프로젝트 보드를 실제로 수정하거나 현재 ERP 상태를 확인한 결과는 아닙니다.

시맨틱 검색은 정확한 사실 저장을 대체하지 않습니다

기록이 많아지면 키워드 검색과 시맨틱 검색을 함께 고려할 수 있습니다. 당시에는 로컬 임베딩 모델을 이용해 관련 기억을 찾는 구성을 사용했습니다. 다만 모델 이름, 설정 키, 게이트웨이 명령은 버전에 따라 달라질 수 있어 과거 값을 그대로 적용하지 않습니다.

검색 품질은 “관련 결과가 나왔다”만으로 판단하지 않습니다. 정답 문서가 상위에 있는지, 날짜나 숫자가 원문과 같은지, 오래된 결론보다 최신 상태가 우선되는지 확인해야 합니다. 시맨틱 검색은 후보를 찾고, 최종 답변은 원문 근거를 읽어 만드는 구조가 안전합니다.

정기 메모리 점검

장기 규칙의 중복·종료 항목을 제거하고, 현재 목표와 프로젝트 확인 시각·근거를 점검합니다. 일일 기록의 중요한 결정은 기준 문서로 옮기고, 검색에 반복 노출되는 잘못된 기억은 수정하거나 보관합니다. 일반 메모리 파일에 민감한 값이 들어가지 않았는지도 확인합니다.

운영 기록: 연결 성공에서 핵심 기억 선별까지

2026-04-02 기록: Qdrant 차원 불일치와 첫 저장·검색

OpenMemory 셀프호스팅을 시작할 때 Docker Desktop의 남은 프로세스 문제를 해결한 뒤 Ollama 로컬 구성으로 진행했다. Qdrant 쪽은 1536차원을 기대했지만 연결 모델에 맞춰 768차원으로 바꿔야 했고 memory.py를 패치했다. mcporter를 통한 OpenClaw MCP 연결과 기억 저장·검색 테스트가 통과했다고 남겼다. 이 차원은 당시 구성값이며 다른 모델에 그대로 적용할 값이 아니다.

목표는 ChatGPT·Claude·OpenClaw의 기억 공유였지만, 공개 기록에는 테스트 문장·전체 로그나 ChatGPT·Claude 각각의 연결 결과가 없다. 따라서 확인한 끝점은 OpenClaw의 저장·검색 첫 연결이다. 같은 날 Tailscale SSH로 Windows 노트북에 연결했으나 이는 작업 위임 통로이지 기억 동기화 증거가 아니다. 노트북에서 이미 사용하던 봇을 Mac mini에도 등록했다가 이중 폴링 충돌로 판단해 되돌린 일도 있어, 연결을 추가하는 것만으로 공유가 완성되지는 않았다.

2026-04-09 기록: 새 파일과 인덱스 중심의 팀 규칙

소카와 Claude Code가 함께 쓰는 메모리는 기존 토픽에 계속 append하지 않고 새 Markdown 파일을 만든 다음 MEMORY.md에는 링크만 추가하기로 했다. 기존 파일 수정이 꼭 필요하면 전체를 UTF-8로 다시 쓰는 방식을 팀 규칙으로 택했다. 이는 특정 제품의 필수 설정이나 append가 인코딩 오류를 일으킨다는 실험 결과가 아니다. 작업 방식을 일관되게 유지하기 위한 당시의 선택이다.

2026-05-02 기록: 모든 dreaming 후보를 MEMORY로 올리지 않기

승인된 압축 제안을 반영하면서 가벼운 dreaming 후보는 즉시 핵심 기억으로 승격하지 않기로 했다. 먼저 deep/rem 요약과 vault/openclaw-memory/dream-knowledge.md의 wiki anchor를 쓰고, vault/openclaw-memory/index.md에서 필요한 heading만 찾아 여는 방식이다. 반복 운영 결정은 decision-log.md 또는 프로젝트 SSOT에 먼저 남긴다.

MEMORY 승격은 세션을 넘어 필요하고, 안정적이며, 반복 재사용되는 조건을 모두 만족할 때로 제한했다. 핵심에 올리지 않는 것은 기록을 버리는 것과 다르다. 이날 reports/inbox·bridge/inbox 등에 새 항목이 없었다는 점검은 해당 경로의 관찰일 뿐 모든 워커 정상의 증거가 아니며, 압축 기준 반영이 검색 성능 향상을 수치로 입증한 것도 아니다.

대표 사례 기준일: 2026-04-01. 통합 게시 기록: 2026-04-02~2026-05-02. 2026-09-03 재구성, 2026-09-10 판단 절차 보완. 개인 운영 구조이며 OpenClaw 공식 기본 폴더·설정 규격을 검증한 문서는 아닙니다.

편집: 2026-09-13. 기존 기록의 구조를 정리한 것으로 새 실행·성능 시험이나 현재 서비스 상태 확인을 뜻하지 않습니다.