alvinreal/awesome-openclaw-tips

OpenClaw를 단순한 재미용 챗봇에서 반복적인 업무를 위한 신뢰할 수 있는 운영 체제(Operating System)로 전환하기 위한 실전 플레이북.

이 팁들은 직접적인 사용, 문서, 커뮤니티 설정, 그리고 리포지토리(Repo) 심층 분석을 통해 수집되었습니다. 감사합니다(Acknowledgements)를 참조하세요.

• 💬 메시지 (Messages)

• 📨 Telegram

• 🧠 메모리 (Memory)

• MEM-01: 에이전트(Agent)가 자신의 실수로부터 배우게 하세요

• MEM-02: 압축(Compaction) 과정에서 데이터가 사라지기 전에 중요한 상태(State)를 비우세요

• MEM-03: 임베딩(Embeddings) 비용을 지불하기 전에 SQLite 메모리 검색을 사용하세요

• MEM-04: 채팅 기록을 신뢰할 수 있는 원천(Source of truth)이 아닌 캐시(Cache)로 취급하세요

• MEM-05: 메모리가 영원히 방치되어 부패하게 두지 말고 주기적으로 스스로 정리(Self-clean)하게 하세요

• 🛡️ 신뢰성 (Reliability)

• 💸 비용 (Cost)

• ⚙️ 운영 (Operations)

• OPS-01: 에이전트 및 서브 에이전트(Subagents)를 위한 명시적인 동시성 제한(Concurrency limits)을 설정하세요

• OPS-02: 워크스페이스(Workspace) 폴더를 신뢰할 수 있는 원천(Source of truth)으로 만들고 git 아래에 두세요

• OPS-03: 잘못된 세션을 실제로 복구할 수 있는 슬래시 명령어(Slash commands)를 익히세요

• OPS-04: /new 실행 시 이전 세션을 삭제하여 리셋 후 쓰레기가 남지 않도록 하세요

• OPS-05: tools.alsoAllow를 사용하여 선택적인 플러그인 도구(Plugin tools)를 추가하세요

• ⏱️ 자동화 (Automation)

• 🏗️ 아키텍처 (Architecture)

프롬프트 복사 - 이 팁을 나를 위해 구현해줘

Review my OpenClaw config and enable ack reactions by setting `messages.ackReactionScope` explicitly.
Do all of the following:
1. Find my OpenClaw config file.
...

Telegram 기능 범위(Capability scope)를 사용하여 인라인 버튼(Inline buttons)을 켜세요:

{channels: {
telegram: {
...

지원되는 범위(Scopes)는 off, dm, group, all, 그리고 allowlist입니다.

프롬프트 복사 - 이 팁을 나를 위해 구현해줘

Review my OpenClaw Telegram setup and enable inline buttons for recurring actions where taps are better than typed replies.
Do all of the following:
1. Find the active OpenClaw config file actually used by this runtime.
...

하나의 긴 OpenClaw 대화는 잡동사니 서랍이 되어버립니다. 코딩, 연구, 관리, 그리고 무작위 질문들이 모두 뒤섞이게 되며, 매 새로운 턴(Turn)마다 그 짐을 계속 끌고 가게 됩니다.

OpenClaw에는 이미 사용할 수 있는 세션 경계(Session boundaries)가 존재합니다. 그룹 채팅은 그룹별로 상태(State)를 격리합니다. Telegram 포럼 토픽(Forum topics)은 고유한 :topic:<threadId> 세션 키(Session keys)를 가집니다. Slack 및 Discord 스레드(Threads)는 스레드 세션으로 취급됩니다. Discord 채널 또한 각각 격리된 세션을 가집니다.

즉, 실질적인 해결책은 간단합니다. 주제나 채널별로 업무를 나누는 것입니다. 코딩용 스레드 하나, 연구용 스레드 하나, 관리용 스레드 하나, 그리고 개인 운영용 스레드를 각각 유지하세요. 집중된 스레드는 에이전트(Agent)에게 거대하고 뒤섞인 대화 기록(Transcript) 대신 집중된 컨텍스트(Context)를 제공합니다.

이는 새로운 메모리 시스템을 요구하지 않기 때문에 가장 쉬운 메모리 수정 방법 중 하나입니다. 그저 OpenClaw의 기존 세션 격리(Session isolation) 기능을 적절히 활용하는 것뿐입니다.

특히 Telegram의 경우, 이제 BotFather에 이를 위한 설정이 있습니다. BotFather를 열고, My bots에서 본인의 봇을 선택한 뒤, Bot Settings로 이동하여 Threaded Mode를 켭니다.

이 기능이 활성화되면, Telegram은 채팅 UI에서 봇에게 별도의 탭/토픽을 제공합니다. 이것이 바로 이 팁이 필요로 하는 것입니다. 모든 것이 서로를 오염시키는 하나의 뒤섞인 대화 기록 대신, 하나의 토픽에서는 코딩을, 다른 토픽에서는 연구를, 또 다른 토픽에서는 관리를 수행하는 방식입니다.

Telegram 토픽은 이미 세션 기록(Session history)을 격리합니다. 여기에 토픽별 systemPrompt를 추가하면 각 스레드가 고유하고 지속적인 목적을 유지할 수 있습니다.

하나의 토픽은 코딩용, 다른 하나는 프로젝트 운영용, 또 다른 하나는 특정 클라이언트나 팀용으로 사용할 때 이 방식은 매우 효과적입니다. 사용자는 토픽 내부에서 /new를 실행하여 세션을 초기화할 수 있지만, 토픽별 프롬프트(Prompt)는 여전히 다시 로드되므로 스레드가 자신의 목적을 잊어버리지 않습니다.

|
Telegram 채팅 엔트리 아래에 토픽 수준의 오버라이드(Override)를 사용하세요: ```
{channels: {
telegram: {
...

**프롬프트 복사 - 이 팁을 나를 위해 구현해줘**

나의 OpenClaw Telegram 설정을 검토하고, 하나 이상의 Telegram 토픽에 스레드 전용 시스템 프롬프트 (system prompt)를 부여하여 /new 명령어로 채팅을 초기화하더라도 해당 토픽의 목적을 잃지 않도록 해줘.
다음 사항을 모두 수행해:

1. 이 런타임 (runtime)에서 실제로 사용 중인 활성 OpenClaw 설정 파일을 찾아.
   ...

만약 OpenClaw 설정 변경, 리포지토리 (repo) 확인, cron 문제, 그리고 봇 유지보수가 모두 동일한 일반 채팅에서 발생한다면, 운영 작업이 다른 모든 내용과 뒤섞이게 됩니다. 자체적인 `systemPrompt`를 가진 전용 Telegram 토픽은 OpenClaw에게 설정 검토, 소스 조사, 그리고 안전한 git 후속 작업을 위한 상시 관리자 경로 (admin lane)를 제공합니다.

이는 제품이나 클라이언트 관련 대화를 동일한 스레드로 끌어들이지 않으면서, 리포지토리 상태 확인, 변경된 파일 검토, `.gitignore` 업데이트 제안, 또는 OpenClaw 설정 워크스페이스를 위한 커밋 준비와 같은 작업에 매우 유용합니다.

이미 사용 중인 정확한 Telegram 계정 및 채팅 경로 아래에 토픽 전용 프롬프트를 사용하세요. 계정 중첩형 Telegram 설정의 경우 다음과 같이 보일 수 있습니다:

{
channels: {
telegram: {
...

프롬프트는 좁고 운영 중심적으로 유지하세요. 해당 토픽의 용도, OpenClaw 리포지토리의 위치, 활성 설정의 위치, 그리고 원하는 커밋 동작을 토픽에 알려주세요. 커밋이나 `.gitignore` 변경 전에 승인을 원한다면, 토픽 프롬프트에 직접 명시하세요.

이는 일반적인 프로젝트 토픽과는 다릅니다. 핵심은 OpenClaw가 자체 유지보수 콘솔 (maintenance console)로 취급할 수 있는 하나의 영구적인 스레드를 갖는 것입니다.

**프롬프트 복사 - 이 팁을 나를 위해 구현해줘**

나의 OpenClaw Telegram 설정을 검토하고, OpenClaw 관리 작업을 위한 전용 Telegram 토픽을 생성해줘. 이를 통해 다른 채팅과 업무를 섞지 않고도 설정 및 리포지토리 변경 사항을 빠르게 관리할 수 있도록 해줘.
다음 사항을 모두 수행해:

1. 이 런타임 (runtime)에서 실제로 사용 중인 활성 OpenClaw 설정 파일을 찾아.
   ...

기본적으로 모든 세션은 깨끗한 상태로 시작됩니다. 당신의 에이전트 (agent)는 이전에 무언가를 시도했다가 실패했던 기억이나, 당신이 마지막으로 교정해 주었던 내용을 기억하지 못합니다. 2주가 지나도 에이전트는 여전히 3일 차에 했던 실수를 반복하고 있을 것입니다.

최소한의 해결책은 워크스페이스 (workspace) 내에 두 개의 파일이 포함된 `.learnings/` 폴더를 만드는 것입니다:

`.learnings/ERRORS.md`
- 명령어 실패 (command failures), 고장 (breakages), 예외 (exceptions)

`.learnings/LEARNINGS.md`
- 수정 사항 (corrections), 지식 격차 (knowledge gaps), 워크플로우 발견 (workflow discoveries)

이를 `SOUL.md`에 추가하세요:

모든 작업을 시작하기 전에, 관련 있는 과거의 오류가 있는지 .learnings/를 확인하십시오.
무언가에 실패하거나 내가 당신을 교정할 때, 즉시 .learnings/에 기록하십시오.

시간이 흐름에 따라, 반복되는 교훈들은 `SOUL.md` 자체로 승격되어 향후 세션에 자동으로 적용될 수 있습니다.

**프롬프트 복사 - 이 팁을 나에게 적용해줘**

내 OpenClaw 워크스페이스에 자기 개선형 학습 시스템 (self-improving learnings system)을 구현해줘.
다음 사항을 모두 수행해:

1. .learnings/ 폴더가 존재하지 않으면 생성해.
   ...

자동 훅 (automatic hooks), 구조화된 엔트리 (structured entries), 그리고 승격 워크플로우 (promotion workflow)가 포함된 더 완전한 버전을 원한다면, self-improving-agent 스킬을 설치하세요.

긴 OpenClaw 세션이 무한히 성장하지는 않습니다. 컨텍스트 (context)가 가득 차면, OpenClaw는 세션을 자동 압축 (auto-compacts)합니다. 이는 대개 요약본과 최근의 턴 (turns)만이 살아남는다는 것을 의미합니다. 채팅에만 존재하는 중요한 모든 정보는 이제 위험에 처하게 됩니다.

압축을 마감 기한으로 간주하십시오. 중요한 상태 (state)는 압축이 일어나기 전에 이미 디스크 (disk)에 저장되어 있어야 합니다.

내장된 압축 전 메모리 플러시 (pre-compaction memory flush) 기능을 켜십시오:

"agents": {
"defaults": {
"compaction": {
...

이 기능은 컨텍스트 사용량을 감시하고, 강제 압축 (hard compaction)이 일어나기 전에 조용히 플러시를 트리거하며, 지속 가능한 상태 (durable state)를 워크스페이스에 기록합니다. 이는 압축 주기마다 한 번씩 실행되며, `NO_REPLY`를 사용하므로 사용자에게 스팸을 보내지 않습니다.

이는 `MEM-01`과 자연스럽게 짝을 이룹니다. 채팅은 작업 기억 (working memory)입니다. 파일은 기억 (memory)입니다.

**프롬프트 복사 - 이 팁을 나에게 적용해줘**

컨텍스트 압축이 일어나기 전에 중요한 상태가 디스크에 기록될 수 있도록, 내 OpenClaw 설정에 압축 전 메모리 플러시 (pre-compaction memory flushing)를 구현해줘.
다음 사항을 모두 수행해:

1. 내 OpenClaw 설정을 찾아 내장된 압축 전 메모리 플러시를 활성화해.
   ...

**프롬프트 복사 - 이 팁을 나에게 적용해줘**

내 OpenClaw 워크스페이스에 경량 SQLite 메모리 검색 시스템을 구현해줘. 임베딩 (embeddings) 비용을 지불하지 않고도 과거 노트를 검색할 수 있도록 말이야.
이 저장소의 다음 지원 파일들을 사용해:

• tips/mem-03/rebuild-db.js
  ...

OpenClaw가 무언가를 안정적으로 기억하기를 원한다면, OpenClaw가 이미 사용하는 방법을 알고 있는 파일들에 그 내용을 기록하세요. 대화 기록 (Transcript) 메모리는 취약합니다. 압축 (Compaction), 리셋 (resets), 그리고 긴 유휴 시간 (idle gaps)은 모두 채팅을 중요한 정보를 보관하기에 부적절한 장소로 만듭니다.

OpenClaw에는 이미 이를 위한 실제 파일 패턴이 있습니다:

`MEMORY.md`
- 지속적인 사실 (durable facts), 선호도 (preferences), 결정 사항 (decisions)

`memory/YYYY-MM-DD.md`
- 일일 노트 (daily notes) 및 실행 컨텍스트 (running context)

`AGENTS.md`
- 에이전트가 해당 파일들을 어떻게 사용해야 하는지에 대한 상시 규칙 (standing rules)

이것이 "채팅은 캐시 (chat is cache)이다"라는 개념의 실용적인 버전입니다. 중요한 사실은 `MEMORY.md`에 속해야 합니다. 단기 작업 컨텍스트 (Short-term working context)는 일일 메모리 파일에 속해야 합니다. `AGENTS.md`는 에이전트가 대화 기록이 모든 것을 전달해 줄 것이라고 믿는 대신, 해당 파일들을 읽고 업데이트하도록 지시해야 합니다.

만약 작업 상태 (task state) 또한 중요하다면, 그것을 실제 작업 시스템이나 이미 사용 중인 다른 지속적인 저장소 (durable store)에 두세요. 규칙은 동일합니다. 만약 대화 기록을 잃어버렸을 때 워크플로 (workflow)가 깨진다면, 그 상태는 잘못된 위치에 있는 것입니다.

**프롬프트 복사 - 이 팁을 나에게 적용해줘**

중요한 컨텍스트가 채팅 기록에 의존하지 않도록 내 OpenClaw 워크스페이스에 지속적인 메모리 파일 (durable memory files)을 설정해줘.
다음 사항을 모두 수행해:

1. 지속적인 사실, 선호도, 결정을 위한 MEMORY.md를 생성하거나 업데이트해.
   ...

메모리의 품질은 무엇을 추가하느냐만큼 무엇을 제거하느냐에 달려 있습니다.

시간이 흐름에 따라 `MEMORY.md`에는 중복된 내용, 오래된 사실 (stale facts), 과거의 선호도, 그리고 모순된 정보들이 쌓입니다. OpenClaw 자체의 템플릿 가이드에서도 이미 며칠마다 한 번씩 유지보수 단계를 거칠 것을 제안합니다. 즉, 최근의 `memory/YYYY-MM-DD.md` 파일들을 읽고, 중요한 교훈을 유지하며, `MEMORY.md`를 업데이트하고, 더 이상 사실이 아닌 오래된 정보를 제거하는 것입니다.

이것이 올바른 사고 모델 (mental model)입니다. 일일 메모리 파일은 가공되지 않은 노트입니다. `MEMORY.md`

는 정제된 지혜입니다. 모든 것이 영원히 남아 있다면, 검색 (retrieval) 과정이 더 노이즈가 심해지고 모델이 오래된 문맥 (stale context)을 실시간 작업으로 다시 불러오기 시작합니다.

해결책은 간단합니다. 주기적으로 메모리를 검토하고, 중복을 병합하며, 모순을 해결하고, 오래된 사실을 제거하여 `MEMORY.md`가 여전히 알 가치가 있는 내용에 집중하도록 유지하는 것입니다.

예를 들어, 문서에서 권장하는 유지보수 루프 (maintenance loop)는 다음과 같습니다:

1. 최근의 memory/YYYY-MM-DD.md 파일들을 읽습니다.
2. 장기적으로 보관할 가치가 있는 중요한 사건, 교훈 또는 통찰을 식별합니다.
3. 추출된 학습 내용을 MEMORY.md에 업데이트합니다.
   ...

이 작업에는 보통 하트비트 (heartbeat)가 가장 적합합니다. OpenClaw 자체 템플릿에서도 메모리 유지보수를 하트비트 항목 아래에 배치하고 있는데, 이는 타당한 접근입니다. 즉, 이것은 정밀한 독립 작업이 아니라 주기적인 백그라운드 인지 (background awareness) 작업이기 때문입니다.

이는 `HEARTBEAT.md`에 다음과 같은 유지보수 규칙을 추가하는 것만으로도 간단히 구현할 수 있습니다:

며칠마다:

• 최근 memory/YYYY-MM-DD.md 파일들을 읽습니다.
• 지속적인 교훈을 MEMORY.md로 승격시킵니다.
  ...

정확한 타이밍이나 완전히 격리된 정리 실행을 원한다면 크론 잡 (cron job)을 사용하는 것도 괜찮습니다. 하지만 이 팁의 관점에서는 하트비트가 더 자연스러운 기본값입니다.

좋은 메모리는 단순히 지속되는 것이 아닙니다. 유지보수되는 것입니다.

**복사용 프롬프트 - 이 팁을 나에게 적용해줘**

내 OpenClaw 워크스페이스를 위해 실용적인 메모리 유지보수 워크플로우 (workflow)를 설정해줘. MEMORY.md가 오래된 사실들로 서서히 채워지는 대신 유용하게 유지될 수 있도록 말이야.
다음 사항을 모두 수행해줘:

1. 나의 최근 memory/YYYY-MM-DD.md 파일들과 현재의 MEMORY.md를 검토해줘.
   ...

한 제공업체 (provider)가 속도 제한 (rate-limit)을 걸거나 다운되면, 해당 제공업체 뒤에 있는 모든 모델이 함께 실패할 수 있습니다. 만약 당신의 전체 폴백 체인 (fallback chain)이 하나의 벤더 (vendor) 안에 있다면, 그것은 중복성 (redundancy)이 아닙니다.

나쁜 예:

"primary": "openai/gpt-5",
"fallbacks": [
"openai/gpt-5-mini",
...

더 나은 예:

"primary": "openai/gpt-5",
"fallbacks": [
"kimi-coding/k2p5",
...

핵심은 저 특정 제공업체들이 아닙니다. 핵심은 장애 독립성 (failure independence)입니다. 하나의 스택에서 발생하는 제한이나 중단이 당신의 에이전트 전체를 함께 무너뜨려서는 안 됩니다.

기본 공유 경로는 `agents.defaults.model.fallbacks`입니다. 만약 특정 에이전트가 자신만의 폴백 체인 (fallback chain)을 필요로 한다면, OpenClaw는 `agents.list[].model = { primary, fallbacks }`를 통한 에이전트별 오버라이드 (override)도 지원합니다.

**프롬프트 복사 - 이 팁을 저에게 적용해 주세요**

내 OpenClaw 모델 폴백 (fallback) 설정을 검토하고, 무엇을 변경하기 전에 공급업체가 다양한 폴백 체인을 선택할 수 있도록 도와주세요.
다음 사항을 모두 수행하세요:

1. 나의 현재 OpenClaw 모델 설정을 찾으세요.
   ...

OpenClaw에서 가장 흔하게 발생하는 실패 중 하나는 가짜 완료 (fake completion)입니다. 에이전트가 작업을 인지하고 완료했다고 말하지만, 실제로 어떤 일이 일어났는지 전혀 확인하지 않는 경우입니다.

이 내용을 `AGENTS.md`에 추가하세요:

모든 작업은 실행-검증-보고 (Execute-Verify-Report) 과정을 따릅니다. 예외는 없습니다.

• 실행 (Execute): 단순히 지시를 인지하는 것에 그치지 않고 실제 작업을 수행합니다.
• 검증 (Verify): 결과가 실제로 발생했는지 확인합니다 (파일 존재 여부, 메시지 전달 여부, 데이터 저장 여부 등)
  ...