Blog

OpenClaw (Moltbot/Clawdbot) 영구 메모리 작동 방식

Ashley Innocent

Ashley Innocent

11 February 2026

OpenClaw (Moltbot/Clawdbot) 영구 메모리 작동 방식

OpenClaw (이전 Moltbot/Clawdbot)은 에이전트 UX의 고질적인 문제점인 연속성을 해결하여 주목받고 있습니다. 대부분의 어시스턴트는 여전히 상호작용 계층에서 무상태(stateless)이므로, 세션이 재설정될 때마다 컨텍스트를 잃는 느낌을 줍니다. OpenClaw의 영구 메모리 설계는 이와 반대 방향으로 나아갑니다. 유용한 장기 상태를 유지하면서도 토큰 비용 증가와 안전하지 않은 보존을 방지합니다.

이는 하트비트 루프("저렴한 검사를 먼저, 필요할 때만 모델 사용"), nono와 같은 보안 에이전트 샌드박스, Nanobot과 같은 초경량 대안과의 비교에 대한 커뮤니티 토론에서 확인할 수 있습니다. 중심적인 엔지니어링 질문은 동일합니다:

에이전트를 느리고, 비싸며, 개인 정보 보호에 위험한 블랙박스로 만들지 않으면서도 내구성 있고 유용한 메모리를 어떻게 유지할 수 있을까요?

이 글은 OpenClaw 스타일의 영구 메모리가 프로덕션 시스템에서 일반적으로 어떻게 작동하는지, 구현 세부 사항, 장단점, 그리고 Apidog를 사용하여 메모리 API를 테스트하는 방법을 설명합니다.

버튼

OpenClaw의 메모리: 실용적인 정신 모델

시스템 수준에서 OpenClaw 메모리는 일반적으로 네 개의 계층으로 나뉩니다.

임시 컨텍스트 (프롬프트 창)
현재 대화 턴 및 도구 출력. 빠르고, 휘발성(volatile)이며, 토큰 제한적입니다.

세션 메모리 (단기)
진행 중인 작업/세션을 위한 구조화된 상태 (목표, 활성 개체, 임시 선호도).

영구 사용자 메모리 (장기)
재시작 후에도 유지될 것으로 예상되는 사실 및 선호도 (예: 선호하는 코딩 스택, 시간대, 알림 습관).

지식 메모리 (문서/작업 코퍼스)
검색을 위해 색인화된 노트, 아티팩트 및 이전 작업 산출물 (임베딩 + 메타데이터 필터).

핵심적인 세부 사항은: 모든 것이 영구적으로 저장되는 것은 아닙니다. OpenClaw는 추출 및 순위 지정을 사용하여 가치 있고 안정적인 정보만 내구성 있는 메모리가 되도록 합니다.

핵심 아키텍처: 쓰기 경로 및 읽기 경로

쓰기 경로 (메모리 생성 방식)

강력한 OpenClaw 메모리 파이프라인은 일반적으로 다음 순서를 따릅니다.

이벤트 캡처
채팅 턴, 도구 결과, 파일 편집, 캘린더 이벤트 및 작업 결과로부터 후보 신호를 수집합니다.

후보 추출
경량 추출기는 "메모리로 저장할 가치가 있는" 주장을 식별합니다. 예시 클래스:

저렴한 검증 먼저
하트비트 패턴에서 영감을 받아: 모델 추론 전에 저렴한 비용의 검사를 실행합니다.

모델 검증 (필요할 때만)
불확실성이 남아있는 경우, LLM 분류기를 호출하여 영속성 가치와 민감도 위험을 평가합니다.

정규화 + 스키마 매핑
자유 텍스트를 유형화된 메모리 레코드로 변환합니다.

충돌 정책을 통한 Upsert
최신성, 신뢰 점수 및 소스 우선순위를 사용하여 기존 레코드와 병합합니다.

감사 추가
설명 가능성 및 롤백을 위해 불변 감사 이벤트를 저장합니다.

읽기 경로 (메모리 검색 방식)

응답 시:

  1. 현재 사용자 턴 + 활성 작업 상태에서 쿼리 의도를 구축합니다.
  2. 구조화된 저장소 + 벡터 저장소에서 후보를 검색합니다.
  3. 관련성, 최신성, 신뢰도 및 정책 제약 조건에 따라 다시 순위를 매깁니다.
  4. 예산(토큰 + 대기 시간)을 적용합니다. 필요한 경우 압축합니다.
  5. 선택된 메모리를 시스템/개발자 컨텍스트에 주입합니다.

이 분할은 중요합니다: 쓰기 경로는 품질과 안전을 최적화하고; 읽기 경로는 관련성과 속도를 최적화합니다.

데이터 모델: 메모리 레코드에 포함되어야 할 내용

실용적인 메모리 엔티티는 종종 다음과 같습니다:

{
  "memory_id": "mem_8f3c...",
  "user_id": "usr_123",
  "type": "preference",
  "key": "editor.theme",
  "value": "dark",
  "confidence": 0.91,
  "source": {
    "kind": "chat_turn",
    "ref": "msg_9981",
    "observed_at": "2026-01-10T09:20:11Z"
  },
  "sensitivity": "low",
  "ttl": null,
  "last_confirmed_at": "2026-01-10T09:20:11Z",
  "version": 4,
  "embedding_ref": "vec_77ad...",
  "created_at": "2026-01-01T10:00:00Z",
  "updated_at": "2026-01-10T09:20:11Z"
}

중요 필드:

저장 전략: 다중 저장소 설계

OpenClaw 메모리는 일반적으로 여러 저장소의 이점을 얻습니다:

왜 하나의 저장소가 아닐까요? 워크로드가 다르기 때문입니다:

일반적인 패턴은 다음과 같습니다: SQL에 기록하고, 비동기적으로 임베딩한 다음, embedding_ref를 통해 연결합니다.

하트비트 및 메모리 최신성

하트비트 모델은 최근 OpenClaw 논의에서 가장 실용적인 아이디어 중 하나입니다.

지속적으로 무거운 추론을 실행하는 대신, 주기적인 루프는 다음을 수행합니다:

  1. 저렴한 활성 상태 확인
  2. 오래된 메모리 감지
  3. 이상 징후 발생 시에만 비싼 모델 검사를 트리거합니다.

하트비트 작업 예시:

이 아키텍처는 품질을 유지하면서 비용을 크게 절감합니다. 또한 예측 가능한 스케줄링 경계를 생성하여 관찰 가능성(observability) 및 SLO 관리에 도움이 됩니다.

검색 순위: 관련성만으로는 부족하다

강력한 OpenClaw 검색기는 임베딩 유사성 이상으로 점수를 매겨야 합니다:

최종 점수 = 의미론적_관련성 × w1 + 최신성 × w2 + 신뢰도 × w3 + 소스_신뢰도 × w4 − 정책_벌점

여기서:

처리해야 할 엣지 케이스: 높은 관련성을 가진 두 개의 충돌하는 메모리.
해결책: 둘 다 불확실성 주석과 함께 포함하거나, 명확화 질문을 트리거합니다.

안전 경계: 보존, 동의 및 샌드박싱

영구 메모리는 공격 표면입니다. 안전 장치가 필요합니다:

명시적 정책을 가진 메모리 클래스

사용자에게 보이는 메모리 제어

범위 지정 실행 샌드박스메모리를 보안 도구 실행과 연결합니다 (nono와 같은 에이전트 샌드박스 프로젝트에서 논의된 바와 같이). 메모리는 암묵적으로 광범위한 도구 권한을 부여해서는 안 됩니다.

프롬프트 주입 저항검증 없이 원시 외부 지침을 신뢰할 수 있는 사용자 선호도로 영구 저장해서는 안 됩니다.

암호화 + 접근 로깅저장 시 암호화하고, 민감한 메모리 업데이트에 서명하며, 읽기/쓰기 감사 추적을 유지합니다.

구현 청사진 (참조 API)

일반적인 메모리 서비스 엔드포인트:

Apidog로 OpenClaw 메모리 API 테스트하기

메모리 시스템은 미묘한 방식으로 실패할 수 있습니다: 오래된 상태, 경쟁 조건, 정책 유출, 순위 회귀. 이것이 바로 Apidog가 자연스럽게 들어맞는 지점입니다.

Apidog를 사용하면 설계, 디버깅, 자동화된 테스트, 목업 및 문서를 하나의 워크플로우로 유지할 수 있습니다.

1) 계약 먼저 설계

OpenAPI 스키마 우선 워크플로우를 사용하여 메모리 엔드포인트와 제약 조건(열거형 타입, 민감도 수준, TTL 규칙)을 정의하세요. 이는 에이전트 로직과 메모리 백엔드 간의 불일치를 방지합니다.

2) 메모리 동작에 대한 시나리오 테스트 구축

다음과 같은 자동화된 테스트 시나리오를 생성하세요:

3) 순위 출력에 시각적 어설션 사용

상태 코드만 확인하는 대신, 순위가 매겨진 필드와 점수 순서를 어설션하세요. 메모리 버그는 종종 "올바른 응답, 잘못된 우선순위"에 숨어 있습니다.

4) 종속 도구 모의(Mock) 생성

업스트림 신호(캘린더/작업 도구)에 대해 스마트 목업 응답을 사용하여 추출 경로를 확정적으로 재현할 수 있습니다.

5) CI/CD 품질 게이트 추가

메모리 점수 매기기 또는 정책 변경 시마다 회귀 테스트 스위트를 실행하세요. 순위 품질이 떨어지거나 정책 검사가 실패하면 배포를 차단하세요.

6) 내부 메모리 API 문서 자동 생성

영구 메모리는 백엔드, QA, 보안 및 제품 팀과 관련됩니다. 대화형 문서는 조율 오버헤드를 줄이고 예상되는 동작을 신속하게 명확히 합니다.

일반적인 실패 모드 및 디버깅 방법

1. 메모리 비대화

증상: 몇 주에 걸쳐 지연 시간과 토큰 사용량이 증가합니다.
해결책: TTL 기본값, 압축 작업, 더 엄격한 추출 임계값.

2. 선호도 변경 반복

증상: 어시스턴트가 충돌하는 사용자 선호도 사이를 오갑니다.
해결책: 영향이 큰 업데이트에 대한 확인을 요구하고; 안정적인 메모리를 교체하기 전에 히스테리시스를 추가합니다.

3. 은밀한 정책 위반

증상: 민감한 데이터가 검색 컨텍스트에 나타납니다.
해결책: 영구 저장 전과 검색 전에 정책 엔진을 적용하고; 레드팀 테스트를 추가합니다.

4. 검색 관련성 부족

증상: 의미론적으로 유사하지만 작업과 관련 없는 메모리가 컨텍스트를 지배합니다.
해결책: 작업 인지 재순위 지정 기능과 메타데이터 필터링을 늘립니다.

5. 동시 쓰기 경쟁

증상: 여러 작업자가 동일한 사용자 스트림을 처리할 때 업데이트가 손실됩니다.
해결책: 낙관적 잠금(version), 확정적 병합 키, 멱등성 토큰.

OpenClaw vs 경량 대안: 메모리 장단점 요약

Nanobot과 같은 프로젝트는 타당한 장단점을 보여줍니다: 작은 시스템은 더 빠르고 이해하기 쉽지만, 종종 내구성 있는 개인화 깊이를 희생합니다.

OpenClaw의 가치 제안은 시간 경과에 따른 더 강력한 연속성과 에이전트 유용성입니다. 그 대가는 더 많은 복잡성입니다:

사용 사례가 단기 자동화라면 경량 방식이 더 유리할 수 있습니다. 복합적으로 작용하는 장기적인 어시스턴트 동작이 필요하다면, 영구 메모리 아키텍처는 엔지니어링 투자를 할 가치가 있습니다.

핵심 요점

OpenClaw 영구 메모리는 다음 세 가지 원칙이 균형을 이룰 때 작동합니다:

  1. 선택적 영구 저장 (적게 저장하고, 더 잘 저장하기)
  2. 비용 인지 오케스트레이션 (저렴한 검사 먼저, 필요할 때 모델 호출)
  3. 정책 우선 안전 (동의, 보존 제어, 감사 가능한 접근)

메모리를 프롬프트 트릭이 아닌 일류 서브시스템으로 다루세요. 계약을 정의하고, 순위 동작을 테스트하며, 정책 게이트를 시행하고, 시간 경과에 따른 변화를 관찰하세요.

이 스택을 구현한다면, Apidog는 메모리 API를 표준화하고, 시나리오 기반 회귀 테스트를 실행하며, 업스트림 도구를 모의(mock)하고, 동일한 진실의 원천으로부터 내부 문서를 게시하는 데 도움을 줍니다. 신용 카드 없이 무료로 사용해보고, 프로덕션 사용자에게 도달하기 전에 메모리 서비스를 검증하세요.

버튼

Apidog에서 API 설계-첫 번째 연습

API를 더 쉽게 구축하고 사용하는 방법을 발견하세요

무료 회원가입다운로드