🎬 I Optimized My OpenClaw to be 10X Smarter (prompts included)

▶️ 유튜브

• 원본 링크: https://youtu.be/vP4kxn5653Y?si=cyP5LX2IMUELWBvT

🖼️ 4컷 인포그래픽

💡 한 줄 결론

OpenClaw 운영 효율을 끌어올리는 핵심은 지침을 늘리는 게 아니라 워크스페이스, 스킬, 메모리, cron, 서브 에이전트의 경계를 분리해 필요한 정보만 필요한 순간에 불러오게 만드는 것이다. 이 구조가 잡히면 토큰 비용, 보안 리스크, 컨텍스트 오염을 함께 낮추면서 장기 운영 안정성까지 확보할 수 있다.

📌 핵심 요점

1. 반복 작업 지침을 워크스페이스 파일에 계속 누적하면 일반 대화나 음성 상호작용 때도 무관한 정보가 상시 로드돼 비용이 늘고 응답 집중도가 떨어진다.
2. 감사 프롬프트로 워크스페이스를 정기 점검하면 중복 규칙, 구식 지침, 장황한 문장, 스킬로 분리해야 할 내용을 체계적으로 걷어낼 수 있다.
3. 스킬은 작업 직후 생성하고 실제 결과물 피드백으로 계속 갱신해야 성능이 누적 개선되며, 이 반복 루프가 에이전트의 실질적 작업 품질을 끌어올린다.
4. 주간 시스템 감사, 2시간 단위 GitHub 백업, 일일 보안 점검·자동 수정, API 키·사용량 점검, 메타 cron까지 구성하면 장애 복구력과 운영 안정성이 크게 높아진다.
5. 메인 에이전트를 오케스트레이터로 제한하고 Docker 기반 서브 에이전트가 실제 실행과 온라인 조사를 맡게 하면 프롬프트 인젝션 피해 범위, 메인 컨텍스트 오염, 작업 병목을 동시에 줄일 수 있다.

🧠 상세 요약

1) 배경과 문제 정의

문제의 출발점은 OpenClaw가 시간이 갈수록 “지능이 낮아진다”기보다, 관련 없는 지침이 계속 쌓여 컨텍스트가 비대해지고 운영 경계가 무너진다는 데 있다. 이 영상은 무엇을 어디에 저장하고, 어떤 작업을 어떤 실행 주체에 맡겨야 장기적으로 더 싸고 안전하게 운영되는지를 보여준다.

2) 섹션별 상세 정리

1. 빠른 최적화 팁의 방향 제시 [00:00]

• 발표자는 OpenClaw가 기대만큼 똑똑하게 작동하지 않거나 데이터 사용량이 과할 때 바로 적용할 수 있는 실전 팁을 제시하겠다고 한다.
• 목표는 복잡한 기술 자랑이 아니라, 짧은 시간 안에 성능·안전성·비용 구조를 함께 개선하는 운영 습관을 만드는 데 있다.

2. 초보자들이 가장 먼저 만드는 구조적 문제 [00:40]

• 많은 사용자가 특정 작업을 반복시키면서도 그 작업을 위한 별도 스킬을 만들지 않아, 관련 지침을 전부 워크스페이스 파일에 밀어 넣는다.
• 이렇게 쌓인 지침은 이후 전혀 다른 대화에서도 반복 참조돼 불필요한 컨텍스트 로드가 상시 발생한다.

3. 유튜브 썸네일 사례로 본 컨텍스트 오염 [01:01]

• 발표자도 초기에 유튜브 썸네일 제작 지침을 워크스페이스에 과도하게 넣어 둔 경험이 있었다고 말한다.
• 그 결과 다른 주제를 다룰 때도 썸네일 관련 정보가 계속 따라붙었고, 이것이 속도 저하와 품질 저하를 동시에 일으키는 대표 사례가 됐다.

4. 감사 프롬프트로 불필요한 지침을 걷어내는 방식 [01:18]

• 발표자는 워크스페이스 전체를 검사해 일반 대화와 무관한 내용, 사실상 스킬로 옮겨야 할 내용, 오래된 항목, 중복, 장황한 문장을 찾아내는 감사 프롬프트를 만들었다고 설명한다.
• 이 감사는 단순 리뷰가 아니라 이동·저장·로그 생성까지 포함하는 정리 절차로 설계돼 있어, 워크스페이스를 운영 가능한 상태로 되돌리는 데 초점이 있다.

5. 스킬 분리가 곧 비용 절감과 집중도 향상으로 연결된다 [01:34]

• 썸네일 제작처럼 특정 상황에서만 필요한 지식은 별도 스킬로 분리해야, 실제 해당 작업을 할 때만 로드된다.
• 이렇게 하면 평소 상호작용에서 불러오는 텍스트 양이 줄고, 에이전트는 현재 작업과 직접 관련된 규칙만 따라 더 선명하게 반응할 수 있다.

6. 스킬은 한 번 만드는 문서가 아니라 피드백 루프의 저장소다 [02:40]

• 발표자는 “방금 한 작업을 스킬로 만들어 달라”는 방식으로 즉시 스킬을 생성하거나, 작업 최적 절차를 함께 정한 뒤 그 내용을 스킬화하라고 권한다.
• 중요한 건 결과가 마음에 들지 않을 때 직접 수정한 다음, 그 수정 의도를 다시 스킬에 반영하게 만들어 다음 작업의 기준점으로 축적하는 것이다.

7. 워크스페이스·스킬·메모리 경계를 규칙으로 강제해야 한다 [03:32]

• 발표자는 agents.md에 새 내용을 기록하기 전에 그것이 워크스페이스, 스킬, 메모리 중 어디에 속해야 하는지 먼저 판단하라는 규칙을 넣었다고 말한다.
• 이 판단 단계를 명문화하면 에이전트가 편한 곳에 아무 정보나 쌓는 일을 줄일 수 있고, 시간이 지나도 구조가 무너지지 않는다.

8. 주기적 시스템 감사가 장기 운영 품질을 지킨다 [03:51]

• 매주 시스템 감사 cron을 돌려 워크스페이스 비대화를 다시 정리하면, 한 번 깨끗하게 만든 구조가 시간이 지나며 다시 무너지는 문제를 막을 수 있다.
• 발표자는 이 방식으로 워크스페이스 파일 크기를 최소 60% 줄였고, 그 결과 확장성과 유지관리성이 좋아졌다고 설명한다.

9. 운영 안정성을 높이는 cron 묶음 [04:24]

• 2시간마다 GitHub 백업을 실행하면 장치 장애나 VPS 이전 상황에서도 최근 상태를 기준으로 빠르게 복구할 수 있다.
• 매일 보안 감사와 자동 수정 cron을 나눠 돌리면 취약점 점검과 수정이 루틴화되고, API 키·권한·도구 연결·사용량 이상치 확인 cron은 숨은 장애와 비용 폭주를 조기에 잡는 안전장치가 된다.
• 여기에 다른 cron의 성공 여부를 확인하는 메타 cron까지 두면 자동화 체계 자체의 신뢰도를 감시할 수 있다.

10. Docker 서브 에이전트와 오케스트레이터 구조의 의미 [06:41]

• 발표자는 서브 에이전트를 Docker 컨테이너 안에서 실행해 민감한 로컬 환경과 작업 실행 환경을 분리하는 보안 구성을 추천한다.
• 메인 에이전트는 직접 실행자가 아니라 오케스트레이터로만 남고, 실제 작업과 온라인 조사는 서브 에이전트가 맡게 해 프롬프트 인젝션 위험, 메인 환경 오염, 병목을 함께 줄인다.
• 핵심은 “필요할 때 가끔 서브 에이전트를 부르는 것”이 아니라, 모든 작업이 기본적으로 이 격리 구조를 거치도록 프롬프트와 설정으로 강제하는 데 있다.

✅ 액션 아이템

• 현재 워크스페이스 파일을 전수 점검해 일반 대화와 무관한 작업 지침을 추출하고, 썸네일 제작·배포·리서치·문서 작성처럼 반복 작업별 스킬 후보를 먼저 분류한다.
• 최근 2주간 3회 이상 반복된 작업을 기준으로, 작업 종료 직후 “방금 수행한 절차 + 수정 피드백”을 스킬에 반영하는 후처리 루프를 만든다.
• AGENTS 규칙에 “새 지침 기록 전 워크스페이스/스킬/메모리 저장 위치를 먼저 판정한다”는 체크 단계를 추가해 컨텍스트 오염을 사전에 차단한다.
• 주 1회 워크스페이스 감사 cron, 일 1회 보안 감사 및 자동 수정 cron, 일 1회 API 키·권한·사용량 점검 cron, 일 1회 메타 cron을 분리해 운영 대시보드처럼 관리한다.
• 2시간 단위 Git 원격 백업을 구성한 뒤, 별도 장치나 테스트 디렉터리에서 실제 복원 리허설을 1회 수행해 백업이 저장만 되는지, 복구까지 가능한지 검증한다.

❓ 열린 질문

• 워크스페이스 파일 60% 축소가 실제로 응답 지연, 토큰 비용, 작업 성공률에 각각 얼마나 개선을 가져왔는지 계량 지표로도 확인됐는가?
• 모든 작업을 서브 에이전트로 강제할 때 짧은 단발 작업에서 발생하는 오버헤드는 어느 수준이며, 어떤 작업까지 강제 격리하는 것이 비용 대비 합리적인가?
• API 키·사용량 점검 cron은 어떤 임계치와 에러 패턴을 기준으로 무한 루프나 비용 폭주를 탐지하며, 오탐을 줄이기 위한 보정 규칙이 있는가?
• 피드백 기반 스킬 업데이트가 특정 사용자 취향에 과도하게 맞춰져 일반 작업 재현성을 해치는 시점은 어떻게 판별하고 분리 관리할 것인가?