fos-blog/study
01 / 홈02 / 카테고리03 / 시리즈
01 / 홈02 / 카테고리03 / 시리즈

카테고리

  • AI 페이지로 이동
    • RAG 페이지로 이동
    • langgraph 페이지로 이동
    • agents.md
    • BMAD Method — AI 에이전트로 애자일 개발하는 방법론
    • Claude Code 메모리: CLAUDE.md와 .claude/rules를 규칙으로 쓰는 법
    • Claude Code의 Skill 시스템 - 개발자를 위한 AI 자동화의 새로운 차원
    • Claude Code를 5주 더 쓴 결과 — 스킬·CLAUDE.md를 키워가는 방식
    • Claude Code를 11일 동안 쓴 결과 — 데이터로 본 나의 사용 패턴
    • Claude Code 멀티 에이전트 — Teams
    • AI 에이전트와 디자인의 새 컨벤션 — DESIGN.md, Google Stitch, Claude Design
    • Docling — IBM Research 의 문서 파싱 toolkit 상세 정리
    • 하네스 엔지니어링 실전 — 4인 에이전트 팀으로 코딩 파이프라인 구축하기
    • 하네스 엔지니어링 — 오래 실행되는 AI 에이전트를 위한 설계
    • 멀티모달 LLM (Multimodal Large Language Model)
    • AI 에이전트와 함께 MVP 만들기 — dooray-cli 사례
    • OpenClaw는 context와 memory를 어떻게 관리하나 — 나만의 에이전트를 구성하는 법
    • OpenClaw vs Hermes Agent — 갈아탈까 고민하며 정리한 비교
    • 스킬 문서를 신경망처럼 학습시킨다 — Microsoft SkillOpt 분석
  • ai 페이지로 이동
    • agent 페이지로 이동
    • [초안] AI 제품 백엔드 안정성 — 지연·비용·권한·관측·도구 실패·폴백/재시도/사람 에스컬레이션
    • [초안] LLM 평가 프레임워크: 골든셋, 회귀 테스트, LLM-as-a-judge, 사람 피드백 루프
  • algorithm 페이지로 이동
    • live-coding 페이지로 이동
    • 분산 계산을 위한 알고리즘
  • apartment 페이지로 이동
    • 구리 럭키아파트 24평 인테리어 레퍼런스 모음
  • architecture 페이지로 이동
    • [초안] 시니어 백엔드를 위한 API 설계 실전 스터디 팩 — REST · 멱등성 · 페이지네이션 · 버전 전략
    • [초안] API Versioning과 Backward Compatibility: 시니어 백엔드 관점 정리
    • 캐시 설계 전략 총정리
    • [초안] CJ푸드빌 디지털 채널 면접: 슬롯 도메인 경험을 커머스 도메인 설계 능력으로 번역하기
    • [초안] 커머스 Spring 서비스에 Clean/Hexagonal Architecture를 실용적으로 적용하기
    • [초안] 커머스 도메인 모델링: 주문·재고·노출의 세 축을 분리해서 설계하기
    • 커머스 주문 상태와 데이터 정합성 기본기 — CJ푸드빌 면접 대비
    • [초안] 쿠폰/프로모션 동시성과 정합성 기본기 — 선착순·중복 사용 방지·발급/사용/복구
    • [초안] DDD와 도메인 모델링: 시니어 백엔드 관점의 전술/전략 패턴 실전 가이드
    • [초안] Decorator & Chain of Responsibility — 행동을 체인으로 조립하는 두 가지 방식
    • 디자인 패턴
    • [초안] 분산 아키텍처 완전 정복: Java 백엔드 시니어 인터뷰 대비 실전 가이드
    • [초안] 분산 트랜잭션과 Outbox 패턴 — 왜 2PC를 피하고 어떻게 대신할 것인가
    • 분산 트랜잭션
    • [초안] e-Commerce 주문·결제 도메인 모델링: 상태머신, 멱등성, Outbox/Saga 실전 정리
    • [초안] Event Sourcing과 CQRS — 상태가 아니라 변화를 저장한다는 발상
    • [초안] F&B 쿠폰·프로모션·멤버십·포인트 설계
    • [초안] F&B · e-Commerce 디지털 채널 도메인 한 장 정리 — CJ푸드빌 디지털 채널 백엔드 면접 대비
    • [초안] F&B 주문/매장/픽업 상태머신 설계 — CJ푸드빌 디지털 채널 백엔드 관점
    • [초안] F&B 이커머스 결제·환불·정산 운영 가이드
    • [초안] Hexagonal / Clean Architecture를 Spring 백엔드에 적용하기
    • [초안] 대규모 커머스 트래픽 처리 패턴 — 1,600만 고객과 올영세일을 버티는 설계
    • [초안] 레거시 JSP/jQuery 화면과 신규 API가 공존하는 백엔드 운영 전략
    • [초안] MSA 서비스 간 통신: Redis [Cache-Aside](../database/redis/cache-aside.md) × Kafka 이벤트 하이브리드 설계
    • [초안] Observability 입문: 시니어 백엔드가 장애를 탐지하고 대응하는 방식
    • [초안] Outbox / Inbox Pattern 심화 — 분산 메시징의 정합성 문제를 DB 트랜잭션으로 풀어내기
    • [초안] 결제 도메인 멱등성과 트랜잭션 재시도 기본기
    • [초안] 시니어 백엔드를 위한 Resilience 패턴 실전 가이드 — Timeout, Retry, Circuit Breaker, Bulkhead, Backpressure
    • [초안] REST API 버저닝과 모바일 앱 하위 호환성 — CJ푸드빌 디지털 채널 백엔드 관점
    • [초안] Spring Batch vs Event-Driven — 같은 비동기처럼 보이지만 전혀 다른 두 패러다임
    • [초안] Strategy Pattern — 분기문을 없애는 설계, 시니어 백엔드 인터뷰 핵심 패턴
    • [초안] 시니어 백엔드를 위한 시스템 설계 입문 스터디 팩
    • [초안] 템플릿 메서드 패턴 - 백엔드 처리 골격을 강제하는 가장 오래되고 가장 위험한 패턴
    • [초안] 대규모 트래픽 중 무중단 마이그레이션 — Feature Flag + Shadow Mode 실전
  • database 페이지로 이동
    • mysql 페이지로 이동
    • opensearch 페이지로 이동
    • redis 페이지로 이동
    • 김영한의-실전-데이터베이스-설계 페이지로 이동
    • [초안] DB Connection Pool Saturation과 Thread Pool 격리
    • 커넥션 풀 크기는 얼마나 조정해야 할까?
    • 인덱스 - DB 성능 최적화의 핵심
    • [초안] JPA N+1과 커머스 조회 모델: 주문/메뉴/쿠폰 도메인에서 살아남기
    • [초안] MyBatis 기본기 — XML Mapper, resultMap, 동적 SQL, 운영 패턴 정리
    • [초안] MyBatis와 JPA/Hibernate 트레이드오프 — 레거시 백엔드를 다루는 시니어 관점
    • 역정규화 (Denormalization)
    • 데이터 베이스 정규화
  • devops 페이지로 이동
    • docker 페이지로 이동
    • k8s 페이지로 이동
    • k8s-in-action 페이지로 이동
    • observability 페이지로 이동
    • [초안] 커머스/F&B 채널 장애 첫 5분과 관측성 기본기
    • [초안] 운영 데이터 정합성 장애 대응 — 결제 취소 누락과 중복 적재 런북
    • Envoy Proxy
    • [초안] F&B / e-Commerce 운영 장애 대응과 모니터링 — 백엔드 관점 정리
    • Graceful Shutdown
    • [초안] 시니어 백엔드를 위한 SLO와 Error Budget 기반 장애 대응
  • finance 페이지로 이동
    • industry-cycle 페이지로 이동
    • investing 페이지로 이동
  • http 페이지로 이동
    • HTTP Connection Pool
    • HTTPS는 어떻게 안전한가 — TLS, 인증서, 그리고 termination
  • interview 페이지로 이동
    • [초안] AI 서비스 팀 경험 기반 시니어 백엔드 면접 질문 뱅크 — Spring Batch RAG / gRPC graceful shutdown / 전략 패턴 / 12일 AI 웹툰 MVP
    • [초안] 커머스/F&B 면접 답변집 — 슬롯 도메인 경험을 주문·결제·쿠폰·매장 설계로 매핑하기
    • Observability — 면접 답변 프레임
    • [초안] 시니어 Java 백엔드 면접 마스터 플레이북 — 김병태
    • [초안] NSC 슬롯팀 경험 기반 질문 은행 — 도메인 모델링·동시성·성능·AI 협업
  • java 페이지로 이동
    • concurrency 페이지로 이동
    • jdbc 페이지로 이동
    • opentelemetry 페이지로 이동
    • spring 페이지로 이동
    • spring-batch 페이지로 이동
    • 더_자바_코드를_조작하는_다양한_방법 페이지로 이동
    • [초안] Java 동시성 락 정리 — 커머스 메뉴/프로모션 정책 캐시 갱신 관점
    • [초안] JVM 튜닝 실전: 메모리 구조부터 Virtual Threads, GC 튜닝, 프로파일링까지
    • Java의 로깅 환경
    • MDC (Mapped Diagnostic Context)
    • Java StampedLock — 읽기 폭주에도 쓰기가 밀리지 않는 락
    • Virtual Thread와 Project Loom
  • javascript 페이지로 이동
    • typescript 페이지로 이동
    • AbortController
    • Async Iterator와 제너레이터
    • CommonJS와 ECMAScript Modules
    • 제너레이터(Generator)
    • Http Client
    • Node 백엔드 운영 패턴 — Streams 백프레셔, pipe/pipeline, 멱등성 vs 분산 락
    • Node.js
    • npm vs pnpm — 어떤 기준으로 선택했나
    • `setImmediate()`
  • kafka 페이지로 이동
    • [초안] Kafka 기본 개념 — 토픽, 파티션, 오프셋, 복제
    • Kafka를 사용하여 **데이터 정합성**은 어떻게 유지해야 할까?
    • [초안] Kafka 실전 설계: 파티션 전략, 컨슈머 그룹, 전달 보장, 재시도, 순서 보장 트레이드오프
    • 메시지 전송 신뢰성
    • [초안] Spring Kafka 컨슈머 오프셋 커밋과 트랜잭션 정렬: AckMode, manual ack, 멱등 처리
  • linux 페이지로 이동
    • fsync — 리눅스 파일 동기화 시스템 콜
    • tmux — Terminal Multiplexer
  • network 페이지로 이동
    • L2(스위치)와 L3(라우터)의 역할 차이
    • L4와 VIP(Virtual IP Address)
    • IP Subnet
  • python 페이지로 이동
    • Python async/await — CompletableFuture·Reactor 와 다른 점, 그리고 blocking I/O 함정
    • Python 의존성 관리 — Java Maven/Gradle 사용자가 만나는 첫 충격
    • FastAPI 기초 — Spring Boot 사용자가 빠르게 익히는 법
    • GPU·CUDA·MPS 기초 — 자바 백엔드 개발자가 처음 만나는 그림
    • Multi-process GPU 워크로드 — 자바 ThreadPool 사용자가 만나는 모델 차이
    • Java 개발자를 위한 Python 심화 — OOP·데코레이터·컨텍스트 매니저
    • PyTorch 기초 — 텐서, 디바이스, 그리고 모델 로딩이 무거운 이유
    • Java 개발자를 위한 Python 문법 핵심
    • ML 서비스 성능 분석 워크플로 — 자바 백엔드 트러블슈팅과 다른 점
    • OCR 동작 원리 — Layout · Text · Post-process 3단계
    • Python 서버의 RSS 가 안 줄어드는 이유 — gc.collect 의 한계와 malloc_trim
  • rabbitmq 페이지로 이동
    • [초안] RabbitMQ Basics — 실전 백엔드 관점에서 정리하는 메시지 브로커 기본기
    • [초안] RabbitMQ vs Kafka — 백엔드 메시징 선택 기준과 실전 운영 관점
  • security 페이지로 이동
    • [초안] 시니어 백엔드를 위한 보안 / 인증 스터디 팩 — Spring Security, JWT, OAuth2, OWASP Top 10
    • [초안] Spring Security 6.x OAuth2 + JWT 상용 인증 설계 — Grant 선택, Resource Server, Refresh Rotation, 로그아웃
  • task 페이지로 이동
    • ai-service-team 페이지로 이동
    • nsc-slot 페이지로 이동
    • sb-dev-team 페이지로 이동
    • the-future-company 페이지로 이동
  • testing 페이지로 이동
    • [초안] 시니어 Java 백엔드를 위한 테스트 전략 완전 정리 — 피라미드부터 TestContainers, 마이크로벤치, Contract까지
  • travel 페이지로 이동
    • 오사카 3박 4일 일정표: 우메다 쇼핑, USJ, 난바·도톤보리, 오사카성
  • web 페이지로 이동
    • [초안] HTTP / Cookie / Session / Token 인증 기본기 — 레거시 JSP와 모바일 API가 공존하는 백엔드 관점
FOS-BLOG · FOOTERall systems normal·v0.1 · 2026.04.27·seoul, kr
Ffos-blog/study

개발 학습 기록을 정리하는 블로그입니다. 공부하면서 기록하고, 기록하면서 다시 배웁니다.

visitors
01site
  • Home↗
  • Posts↗
  • Categories↗
  • About↗
02policy
  • 소개/about
  • 개인정보처리방침/privacy
  • 연락처/contact
03categories
  • AI↗
  • Algorithm↗
  • DB↗
  • DevOps↗
  • Java/Spring↗
  • JS/TS↗
  • React↗
  • Next.js↗
  • System↗
04connect
  • GitHub@jon890↗
  • Source repositoryjon890/fos-study↗
  • RSS feed/rss.xml↗
  • Newsletter매주 1 회 · 한 편의 글→
© 2026 FOS Study. All posts MIT-licensed.
built with·Next.js·Tailwind v4·Geist·Pretendard·oklch
fos-blog/AI/OpenClaw는 context와 memor…
ai

OpenClaw는 context와 memory를 어떻게 관리하나 — 나만의 에이전트를 구성하는 법

OpenClaw를 쓰면서 "이 에이전트가 어제 일을 어떻게 기억하지?", "긴 대화가 쌓이면 context는 어떻게 관리되지?" 가 궁금해졌다. config 파일 몇 개만 만지면 에이전트가 살아 움직이는데, 그 안에서 무슨 일이 벌어지는지 알아야 내가 원하는 대로 길들일 수 있다. 이 글은 OpenClaw의 context·memory 관리 방식을 공식 문서...

2026.06.16·8 min read·1 views

OpenClaw를 쓰면서 "이 에이전트가 어제 일을 어떻게 기억하지?", "긴 대화가 쌓이면 context는 어떻게 관리되지?" 가 궁금해졌다. config 파일 몇 개만 만지면 에이전트가 살아 움직이는데, 그 안에서 무슨 일이 벌어지는지 알아야 내가 원하는 대로 길들일 수 있다.

이 글은 OpenClaw의 context·memory 관리 방식을 공식 문서 기준으로 정리하고, 그 위에서 나만의 에이전트를 구성하는 흐름까지 다룬다. 오래 실행되는 AI 에이전트의 설계 관점은 하네스 엔지니어링에서 더 일반적으로 다루는데, OpenClaw는 그 원칙들이 실제 제품에서 어떻게 구현됐는지 보여주는 좋은 사례다.

OpenClaw는 오픈소스 자율 AI 에이전트 프레임워크다(이전 이름 Clawdbot → Moltbot, MIT 라이선스). 채팅 앱에 붙어 사는 local-first 개인 비서로, 셸·파일·브라우저·Docker를 직접 다루고 20개가 넘는 메시징 플랫폼에 연결된다.

context와 memory는 다르다

OpenClaw 문서가 가장 먼저 못 박는 개념이 이것이다.

"Context is not the same thing as 'memory': memory can be stored on disk and reloaded later; context is what's inside the model's current window."

  • memory — 디스크에 저장되고 나중에 다시 로드되는 영속 상태. 파일로 남는다.
  • context — 지금 이 순간 모델 윈도우 안에 들어 있는 것. 매 호출마다 조립된다.

둘을 헷갈리면 "왜 기억은 하는데 지금 대화에선 모르지?" 같은 혼란이 생긴다. memory에 저장돼 있어도 그게 context로 주입되지 않으면 모델은 그 순간 그걸 못 본다. 이 구분이 아래 모든 동작의 바탕이다.

memory — 디스크에 저장된 것만 기억한다

OpenClaw의 메모리는 화려한 벡터 DB가 아니라 plain Markdown 파일이다. 기본 경로는 에이전트 workspace(~/.openclaw/workspace) 안이고, 설계 원칙은 단순하다.

시스템은 "디스크에 저장된 것만 기억하고, 숨은 상태는 없다(no hidden state)."

메모리 파일은 역할별로 나뉜다.

파일역할로드 시점
MEMORY.md장기 기억 — 영속적 사실·선호·결정모든 DM 세션 시작 시 자동
memory/YYYY-MM-DD.md일일 노트 — 진행 중 맥락·관찰 (append-only)오늘·어제 노트 자동
DREAMS.md (선택)Dream Diary — dreaming sweep 요약선택적

에이전트는 두 도구로 메모리에 접근한다.

  • memory_search — 의미·키워드 검색
  • memory_get — 파일·라인 직접 접근

MEMORY.md가 너무 커져서 bootstrap 예산을 넘으면, 디스크 파일은 그대로 두고 context에 주입되는 사본만 잘라낸다(truncate). 기억 자체는 보존되지만 지금 윈도우에 다 들어가지 못할 뿐이다. 잘렸는지는 /context list나 openclaw doctor로 확인한다. context와 memory의 분리가 여기서도 그대로 나타난다.

context window 조립과 compaction

매 모델 호출마다 context는 다음을 조립해서 만든다.

  • 시스템 프롬프트 — 도구 목록·스키마(JSON, 윈도우에 카운트됨), 스킬 목록(이름+설명만), workspace 메타데이터
  • workspace bootstrap 파일 — AGENTS.md, SOUL.md, TOOLS.md, IDENTITY.md, USER.md, HEARTBEAT.md 등
  • 대화 레이어 — 현재 세션의 메시지, 도구 호출·결과, 첨부

bootstrap 파일에는 주입 상한이 걸려 있다.

  • 파일당 bootstrapMaxChars — 기본 20,000자
  • 전체 bootstrapTotalMaxChars — 기본 60,000자

핵심은 스킬 본문이 on-demand로만 로드된다는 점이다. 시스템 프롬프트에는 스킬의 이름과 설명만 들어가고, SKILL.md 전문은 그 스킬이 필요할 때만 읽힌다. 이 progressive disclosure 덕에 스킬을 수십 개 등록해도 평소 context가 가볍게 유지된다.

대화가 길어지면 /compact 명령이 오래된 이력을 요약 항목으로 압축한다. 최근 메시지는 그대로 두고, 디스크의 전체 이력은 보존한 채 윈도우 공간만 비운다.

여기에 안전장치가 하나 붙어 있다. compaction 직전에 OpenClaw는 보이지 않는 턴(silent turn)을 한 번 돌려, 에이전트에게 "중요한 맥락을 메모리 파일에 저장하라"고 상기시킨다. 요약 과정에서 맥락이 날아가기 전에 디스크로 한 번 흘려보내는 것이다(memory flush). context는 휘발성, memory는 영속이라는 설계가 압축 시점에 둘을 잇는 방식이다.

context가 지금 무엇으로 차 있는지는 명령으로 들여다볼 수 있다.

  • /status — 윈도우 충만도, 세션 설정
  • /context list — 주입된 파일과 대략적 토큰 수
  • /context detail — 파일·도구 스키마·스킬별 분해
  • /context map — context 기여자를 treemap으로

SOUL.md — 에이전트의 목소리

memory가 "무엇을 아는가"라면, SOUL.md는 "어떻게 말하는가"다.

"SOUL.md is where your agent's voice lives."

이 파일은 일반 세션에 주입되어 모든 응답의 톤에 직접 영향을 준다. 문서가 권하는 내용은 다음과 같다.

  • 톤과 커뮤니케이션 스타일
  • 표명된 의견, 간결함 선호, 유머 접근 방식
  • 경계와 제약, 기본 직설성 수준

반대로 담지 말라는 것도 분명하다 — 인생 이야기, 변경 이력, 보안 정책 덤프, "분위기만 잔뜩 늘어놓은 글(wall of vibes)". 설계 철학은 한 줄로 압축된다.

"Short beats long. Sharp beats vague."

주의할 점 — SOUL.md에는 강제된 고정 스키마가 없다. 커뮤니티 템플릿들이 "Core Identity / Responsibilities / Communication Style ..." 같은 섹션 구조를 쓰지만, 그건 관례이지 규칙이 아니다. 정확히 말하면 SOUL.md는 자유 형식 Markdown으로 쓰는 행동 규칙 모음이다. 이 점은 CLAUDE.md를 규칙으로 쓰는 법에서 다루는 "규칙 파일을 주입한다"는 발상과 같은 계열이다.

AgentSkill — 스킬이 곧 능력 단위

OpenClaw에서 에이전트에 능력을 더하는 단위가 스킬이다. 각 스킬은 SKILL.md(YAML frontmatter + Markdown 본문)를 담은 디렉터리다.

frontmatter의 핵심 필드:

  • 필수 — name(슬래시 커맨드·allowlist 키), description
  • 선택 — user-invocable(기본 true), command-dispatch, metadata(requires.env/requires.bins 같은 게이팅)

스킬도 메모리처럼 progressive disclosure를 따른다. 시작 시 각 스킬의 이름과 설명만 로드하고, 작업이 그 설명에 매칭될 때만 전문을 읽는다. 스킬 하나의 평소 토큰 오버헤드는 24토큰 남짓에 불과하다. 이 구조는 Claude Code의 Skill 시스템과 사실상 같은 발상이고, 포맷도 Claude Code·Cursor 컨벤션과 호환된다.

스킬은 6계층 우선순위로 탐색된다.

우선순위소스경로
1Workspace skills<workspace>/skills
2Project agent skills<workspace>/.agents/skills
3Personal agent skills~/.agents/skills
4Managed/local skills~/.openclaw/skills
5Bundled skills설치 시 동봉
6Extra directoriesskills.load.extraDirs + 플러그인

같은 이름이 여러 곳에 있으면 최상위 우선순위가 이긴다. 스킬은 ClawHub 레지스트리에서 설치할 수도 있다.

bash
openclaw skills install <slug>              # workspace 설치
openclaw skills install <slug> --global     # 모든 에이전트
openclaw skills install git:owner/repo@ref  # Git 소스
openclaw skills verify <slug>               # 보안 스캔

ClawHub 설치는 보안 스캔을 거친다 — frontmatter가 선언한 비밀(requires.env 등)과 실제 코드가 참조하는 비밀이 일치하는지 검사해 불일치를 표시한다.

Gateway와 heartbeat

지금까지가 "한 번의 대화"를 구성하는 요소였다면, Gateway는 그것들을 항상 켜진 프로세스로 묶는다.

Gateway는 단일 장기 실행 Node.js 프로세스다(기본 포트 18789). macOS는 launchd, Linux는 systemd user 서비스로 데몬화하길 권한다. 담당하는 일은 채널 연결, 세션 상태, 에이전트 루프, 모델 호출, 도구 실행, 메모리 영속화까지 전부다.

내부는 대략 다섯 서브시스템으로 나뉜다.

  • Channel adapters — 플랫폼별 인바운드 메시지를 정규화 (WhatsApp은 Baileys, Telegram은 grammY 등)
  • Session manager — 발신자 신원 해소. DM은 main 세션으로, 그룹 채팅은 자체 세션으로
  • Queue — 세션별 실행을 직렬화
  • Agent runtime — context 조립 → 모델 호출 → 도구 실행 → 결과 피드백을 완료까지 반복
  • Control plane — WebSocket API

그리고 OpenClaw를 단순 챗봇과 구분 짓는 기능이 heartbeat다. Gateway 데몬은 주기적으로 에이전트를 깨워 능동적으로 일하게 한다.

  • 기본 간격은 30분 (Anthropic OAuth/토큰 인증이 감지되면 1시간)
  • 매 tick마다 에이전트는 "Read HEARTBEAT.md if it exists. Follow it strictly." 프롬프트를 받는다
  • HEARTBEAT.md는 workspace의 선택적 체크리스트 — 30분마다 고려해도 안전할 만큼 작고 안정적인 것만 담는다
  • 처리할 게 없으면 HEARTBEAT_OK로 끝나고, 있으면 알림을 보낸다

heartbeat 설정의 주요 키:

  • heartbeat.every — 간격 (기본 30m, 0m이면 비활성)
  • heartbeat.target — 알림 라우팅 대상 (none/last/명시 채널)
  • heartbeat.directPolicy — DM 전달 허용 여부
  • isolatedSession: true — 매 heartbeat를 이력 없는 fresh 세션으로 (토큰 약 100K → 2~5K로 절감)
  • activeHours — 지정 시간대 밖에서는 heartbeat skip

여기서도 메모리·context 분리가 그대로 쓰인다. isolatedSession을 켜면 heartbeat는 과거 대화 이력 없이 fresh 세션으로 돌아 토큰을 아끼는데, 그래도 MEMORY.md는 세션 시작 시 로드되므로 "기억은 유지하되 대화 맥락은 비운" 상태로 점검만 수행한다. 영속 memory와 휘발 context를 분리해 둔 덕에 가능한 최적화다.

나만의 에이전트를 구성하는 흐름

OpenClaw의 슬로건은 "Write a SOUL.md, run a command, your agent is live"다. config-first라 Python도, 체인도, 그래프도 없다.

설치와 온보딩:

bash
# 설치 (Node 22.19+ 권장)
curl -fsSL https://openclaw.ai/install.sh | bash
 
# 온보딩 — 모델 provider 선택, API 키, Gateway 설정 (약 2분)
openclaw onboard --install-daemon
 
# Gateway 상태 확인 (포트 18789)
openclaw gateway status
 
# 대시보드
openclaw dashboard        # http://127.0.0.1:18789/

그다음 config-first 흐름은 이렇게 이어진다.

  1. SOUL.md 작성 — workspace에 톤·의견·경계를 담는다. 없으면 기본 비서로 동작한다.
  2. 스킬 추가 — openclaw skills install <slug>로 ClawHub에서 가져오거나, <workspace>/skills/<name>/SKILL.md를 직접 쓴다. 에이전트별 노출은 agents.list[].skills로 제어한다.
  3. 메모리·heartbeat — MEMORY.md와 일일 노트는 에이전트가 채워가고, 능동 동작이 필요하면 HEARTBEAT.md 체크리스트를 둔다.
  4. 설정 파일 — ~/.openclaw/openclaw.json(JSON5). 주요 키는 agents(모델·스킬·sandbox), channels, gateway, session, bindings(멀티 에이전트 라우팅), cron, hooks. 모델은 agents.defaults.model.primary에 "anthropic/claude-sonnet-4-6"처럼 provider/model 형식으로 지정한다.

디렉터리 레이아웃은 단일 에이전트와 멀티 에이전트가 다르다는 점만 기억하면 된다.

단일 에이전트(기본):

plaintext
~/.openclaw/
├── openclaw.json          # JSON5 설정
├── .env
└── workspace/
    ├── SOUL.md, AGENTS.md, TOOLS.md, USER.md ...
    ├── MEMORY.md
    ├── memory/YYYY-MM-DD.md
    └── skills/<name>/SKILL.md

멀티 에이전트일 때는 에이전트마다 상태가 분리된다 — 세션 이력은 ~/.openclaw/agents/<agentId>/sessions, 인증은 같은 디렉터리 하위로 격리된다.

정리

OpenClaw의 memory·context 설계는 벡터 DB 같은 무거운 인프라 없이 plain Markdown 파일과 명확한 개념 구분만으로 굴러간다. memory와 context를 갈라 둔 덕에 "기억은 하지만 지금은 모르는" 상황이 설명되고, progressive disclosure로 스킬·메모리를 평소엔 가볍게 두며, compaction 직전 memory flush로 압축 시점의 맥락 손실을 막는다.

나만의 에이전트를 만든다는 건 결국 이 네 가지를 직접 정하는 일이다 — 무엇을 기억할지(MEMORY.md), 어떤 목소리로 말할지(SOUL.md), 무슨 능력을 가질지(skills), 언제 스스로 움직일지(HEARTBEAT.md). 같은 발상을 학습 가능한 산출물로 끌고 가는 흐름은 SkillOpt 분석에서 이어진다.

다른 선택지인 Hermes Agent와의 비교는 OpenClaw vs Hermes Agent에서 다룬다.

참고 링크

  • OpenClaw 공식 문서 — Context
  • OpenClaw 공식 문서 — Memory
  • OpenClaw 공식 문서 — SOUL
  • OpenClaw 공식 문서 — Skills
  • OpenClaw 공식 문서 — Gateway Configuration
  • OpenClaw 공식 문서 — Heartbeat
  • OpenClaw 공식 문서 — Multi-agent
  • awesome-openclaw-agents — SOUL.md 템플릿 모음
  • How OpenClaw Works — 아키텍처 해설 (Milvus Blog)
on this page
  • 01context와 memory는 다르다
  • 02memory — 디스크에 저장된 것만 기억한다
  • 03context window 조립과 compaction
  • 04SOUL.md — 에이전트의 목소리
  • 05AgentSkill — 스킬이 곧 능력 단위
  • 06Gateway와 heartbeat
  • 07나만의 에이전트를 구성하는 흐름
  • 08정리
  • 09참고 링크

이런 글도

  • 벡터 검색 알고리즘 — kNN에서 HNSW까지
    임베딩으로 텍스트를 벡터로 바꾸고 나면, "질문 벡터와 가장 가까운 문서 벡터"를 찾아야 한다. 이 글은 그 검색을 담당하는 알고리즘을 kNN(개념) → 왜 느린가 → ANN → HNSW(실전 표준) 순서로 정리한다. - kNN(k-Nearest Neighbors) = 어떤 벡터(쿼리)와 가장 가까운 k개의 이웃 벡터를 찾는 알고리즘 - 예를 들어 - 문서...
    🤖 ai
    ai
    2026.06.16
  • OpenClaw vs Hermes Agent — 갈아탈까 고민하며 정리한 비교
    지금 나는 OpenClaw로 개인 에이전트를 돌리고 있다. 잘 동작하지만, 에이전트를 여러 개 구성하고 그 위에 제대로 된 화면을 얹는 그림을 그리다 보니 Hermes Agent가 자꾸 눈에 들어온다. 갈아탈지 말지를 결정하기 전에, 두 프레임워크가 메모리·구성·UI·자기개선에서 실제로 무엇이 다른지 공식 문서 기준으로 정리했다. OpenClaw 자체의 내...
    🤖 ai
    ai
    2026.06.16
  • 스킬 문서를 신경망처럼 학습시킨다 — Microsoft SkillOpt 분석
    나는 Claude Code 위에서 30개가 넘는 개인 스킬(skill)을 운영한다. 블로그 글 작성, 이력서 갱신, 주간보고, 사내 결재 자동화 같은 반복 워크플로우를 각각 SKILL.md 한 장으로 정의해두고 쓴다. 이 스킬들은 시간이 지나면서 점점 커진다. 한 번 실수하면 "이런 함정이 있더라"를 문서에 적어두고, 다음에 같은 실수를 피하는 식이다. 그...
    🤖 ai
    ai
    2026.06.12
  • Claude Code 메모리: CLAUDE.md와 .claude/rules를 규칙으로 쓰는 법
    진행 기간: 2026.06 Claude Code로 한 레포를 오래 다루다 보면 "매번 같은 걸 다시 설명하는" 순간이 온다. PR 본문은 이렇게 써라, Dooray 업무 제목은 이 형식이다, 한국어로 풀어 써라. 이걸 어디에 적어둬야 Claude가 실제로 지키는지 — 그게 이 글의 주제다. 나는 그동안 이런 규칙을 프로젝트 안 .claude/skills/s...
    🤖 ai
    ai
    2026.06.08

댓글 (0)