🎬 I built my own OpenClaw that does EVERYTHING for me (but safer)

▶️ 유튜브

• 원본 링크: https://youtu.be/8Nk9IWhW2Ck?si=UrabUN7IaTzdUUWv

🖼️ 4컷 인포그래픽

💡 한 줄 결론

개인 AI 비서는 거대한 올인원 프레임워크를 통째로 도입하기보다, 메모리·하트비트·채널 어댑터·스킬만 분해해 직접 통제 가능한 구조로 재조립할 때 보안·비용·운영 예측 가능성에서 더 큰 투자 가치를 만든다. 특히 정액제 모델과 사람이 읽을 수 있는 파일 기반 메모리를 결합하면, 비서는 소비성 도구가 아니라 운영 가능한 개인 AI OS로 진화한다.

📌 핵심 요점

1. OpenClaw의 본질적 자산은 제품 전체가 아니라 메모리, 하트비트, 채널 어댑터, 스킬이라는 네 개의 추상화에 있으며, 발표자는 이 조합만 가져와 별도 시스템으로 재구성했다.
2. 보안 측면에서는 원클릭 원격 코드 실행, 평문 자격 증명 노출, 악성 스킬 유통 사례가 겹치며, 개인 디지털 자산을 맡기기엔 공급망 리스크가 지나치게 크다고 본다.
3. 비용 측면에서는 하트비트와 긴 대화 이력을 포함한 반복 호출이 토큰 청구를 폭증시키므로, 종량제 기반 구조는 개인 비서의 장기 운영 모델로 불안정하다는 판단이 핵심 전제다.
4. 대안 구조는 마크다운 파일과 SQLite 검색 인덱스를 중심에 두고, Telegram 같은 단일 채널부터 붙인 뒤, 필요할 때만 개입하는 하트비트와 선택형 스킬을 얹는 방식으로 운영 가시성을 높인다.
5. 같은 기억을 공유하는 채널 어댑터와 업무 스킬, 나아가 전문 에이전트 계층까지 확장하면, 이 구조는 단순 챗봇이 아니라 개인과 팀의 작업 흐름을 통합하는 운영체제로 발전할 수 있다.

🧠 상세 요약

1) 배경과 문제 정의

이 영상의 출발점은 “기억하고 먼저 연락하는 개인 AI 비서”라는 비전은 매력적이지만, 실제 운영 단계에서는 보안 사고, 공급망 리스크, 종량제 비용 폭증, 대형 코드베이스의 불투명성이 동시에 문제로 터진다는 점이다. 그래서 판단 포인트는 기능의 화려함이 아니라, 개인이 직접 이해하고 감사할 수 있는 구조로 다시 만들 수 있느냐에 맞춰진다.

2) 섹션별 상세 정리

1. OpenClaw의 매력과 동시에 드러난 위험 신호 [00:00]

• 발표자는 OpenClaw가 매우 빠르게 성장한 오픈소스 프로젝트이며, 여러 채널에서 사용자를 기억하고 먼저 연락하는 AI 비서 비전 자체는 강력하다고 인정한다.
• 그러나 연구자들이 짧은 시간 안에 인스턴스를 장악한 사례, 보안팀의 강한 경고, 악성 스킬 유통, 월 수백~수천 달러 수준의 과금 사례를 함께 제시하며 “아이디어는 좋지만 그대로 쓰기엔 위험하다”는 문제의식을 세운다.

2. 제품 전체가 아니라 핵심 추상화만 가져오겠다는 선택 [00:57]

• 발표자는 OpenClaw를 그대로 포크하거나 확장하는 대신, 진짜 가치가 있는 구조만 추려 직접 재구축하겠다고 선언한다.
• 여기서 핵심은 기능 복제가 아니라 메모리, 하트비트, 채널 어댑터, 스킬이라는 작동 원리를 분해해 자기 통제 아래 다시 조립하는 것이다.

3. OpenClaw의 진짜 힘은 네 가지 구조에 있다 [01:28]

• 발표자는 창시자에 대한 공로를 인정하면서도, 제품의 본질적 강점은 플랫폼 수나 외형이 아니라 네 가지 내부 구조에 있다고 정리한다.
• 즉, 개인 AI 시스템의 경쟁우위는 “어떤 모델을 붙였는가”보다 “기억·주기 실행·채널 연결·기능 확장”을 어떻게 엮는가에서 나온다는 관점을 제시한다.

4. 메모리·하트비트·채널 어댑터·스킬의 기본 작동 원리 [02:00]

• 메모리는 마크다운 파일과 경량 SQL 검색을 조합해 성격, 사용자 정보, 장기 기억, 일일 로그를 사람이 직접 읽고 수정할 수 있게 만든다.
• 하트비트는 주기적으로 최근 맥락을 읽고 정말 말할 가치가 있을 때만 개입하며, 채널 어댑터는 여러 플랫폼에서 같은 기억을 공유하게 하고, 스킬은 Gmail·캘린더·브라우저 자동화 같은 외부 기능을 붙이는 확장층이 된다.

5. 그대로 쓰지 않는 이유: 보안, 비용, 통제 가능성 [03:22]

• 보안 측면에서는 원격 코드 실행과 평문 자격 증명, 악성 스킬 사례가 결합될 경우 개인 비서가 곧바로 침해 지점이 될 수 있다는 점을 강하게 비판한다.
• 비용 측면에서는 하트비트와 장문 컨텍스트 호출이 누적될수록 청구가 기하급수적으로 커지고, 통제 측면에서는 거대한 코드베이스를 다 이해하지 못한 채 운영하게 된다는 점을 구조적 한계로 본다.

6. 자신이 채택한 대안 아키텍처와 비용 모델 [05:00]

• 새로운 구조는 하나의 “제2의 두뇌”를 중심 허브로 두고, 그 위에 메모리, Telegram 어댑터, 하트비트, 스킬을 얹는 단순한 형태다.
• 발표자는 Anthropic Max 같은 정액제를 활용하면 하트비트·검색·문서 생성이 반복돼도 비용 상한을 예측할 수 있어, 종량제보다 운영 안정성이 높아진다고 주장한다.

7. 빌드 방식: 참조 저장소는 설계도, 실제 시스템은 별도 구현 [06:58]

• 구현은 Claude Code나 Cursor 같은 코딩 에이전트 환경에서 진행하며, OpenClaw 저장소는 복사 대상이 아니라 분석용 참조 자료로만 둔다.
• 작업 폴더와 참조 저장소를 분리함으로써 “좋은 구조는 흡수하되, 복잡성과 위험은 함께 들여오지 않는다”는 원칙을 유지한다.

8. 메모리 시스템 재구축과 파일 기반 투명성 [09:11]

• soul.md, user.md, memory.md, agent.md, 일일 로그 폴더, SQLite 인덱스를 생성해 기억 구조를 파일 중심으로 만든다.
• 이 설계의 핵심은 검색 성능은 SQL로 확보하면서도, 실제 기억은 모두 사람이 열어보고 수정할 수 있는 마크다운으로 유지해 블랙박스를 최소화하는 데 있다.

9. Telegram 어댑터와 Claude CLI 기반 연결 방식 [11:31]

• 첫 채널은 Telegram으로 시작하며, 봇 토큰과 개인 사용자 ID를 이용해 자신에게만 응답하는 좁은 인터페이스를 만든다.
• 특히 API 키 기반 SDK 대신 Claude CLI를 하위 프로세스로 호출하는 방식으로 바꿔, 기존 정액제 구독을 활용하고 비밀키 관리 부담도 줄이는 방향을 택한다.

10. 사용자 정보 자동 반영과 하트비트 운영 원칙 [14:11]

• 사용자가 자기소개를 보내면 user.md가 업데이트되며, 시스템은 이를 장기적으로 축적되는 사용자 맥락으로 활용한다.
• 하트비트는 30분마다 최근 기록을 읽고 “지금 알릴 중요한 것이 있는가”라는 단일 질문으로 개입 여부를 판단하며, 중복 알림 방지와 디버그 로그를 통해 운영 흔적을 남긴다.

11. 첫 번째 스킬: 웹 검색 기능의 추가 [16:03]

• 특정 키워드가 들어오면 검색을 수행하고, 결과를 Claude가 출처와 함께 요약해 다시 Telegram으로 보내는 흐름을 구현한다.
• 이 장면은 스킬이 거대한 마켓플레이스에 의존하지 않아도, 필요한 업무 기능을 자연어 지시만으로 로컬 구조 안에 빠르게 증설할 수 있음을 보여준다.

12. 문서 생성과 일일 브리핑으로 이어지는 실무형 확장 [17:04]

• 검색 결과를 바탕으로 문서를 실제 파일로 저장하게 만들고, 파일 경로와 미리보기를 함께 반환하도록 구성해 로컬 문서 워크플로와 연결한다.
• 이어서 하트비트에 오전 9시 브리핑 규칙을 추가해 정기 정보 전달과 예외 알림을 함께 운영하며, 비서가 단순 질의응답을 넘어 능동적 운영 도구가 되는 모습을 보여준다.

13. 어댑터 확장, 스킬 공유, 전문 에이전트 계층 [19:06]

• Telegram만 붙여도 구조는 성립하지만, 동일한 기억을 공유하는 상태로 WhatsApp, Slack, Discord, iMessage 같은 채널을 추가하면 멀티채널 개인 비서로 확장된다.
• 더 나아가 이메일, 캘린더, CRM, 콘텐츠, 재무 역할을 맡는 전문 에이전트를 동일 메모리 위에 얹으면, 시스템은 하나의 채팅봇이 아니라 업무 운영체제로 변한다.

14. 결론: 프레임워크보다 통제 가능한 개인 AI OS [21:15]

• 발표자는 복잡한 프레임워크를 익히지 않아도, 설계 원리와 코딩 에이전트만 있으면 자신에게 맞는 개인 비서 시스템을 직접 만들 수 있다고 정리한다.
• 결국 이 영상의 메시지는 “완성품을 쓰는 소비자”보다 “핵심 구조를 통제하는 운영자”가 되는 쪽이 장기적으로 더 안전하고 경제적이라는 데 있다.

✅ 액션 아이템

• 현재 운영 중인 AI 자동화 스택을 메모리, 주기 실행, 채널 어댑터, 외부 스킬 네 계층으로 분해해서 적고, 각 계층별로 외부 의존성과 비밀정보 보관 위치를 함께 점검한다.
• 최소 프로토타입을 만들 때는 soul.md, user.md, memory.md, agent.md와 SQLite 검색 인덱스만 먼저 구성하고, 벡터DB나 멀티에이전트 오케스트레이션은 2차 실험으로 뒤로 미룬다.
• 첫 채널은 Telegram이나 Discord 한 개만 선택해 붙이고, 허용 사용자 ID 제한, 로그 저장 위치, 실패 시 응답 경로, 자격 증명 저장 방식까지 포함한 배포 전 보안 체크리스트를 만든다.
• 하트비트 도입 전에는 “무엇을 읽는지”, “개입 여부를 판단하는 단일 질문이 무엇인지”, “중복 알림을 몇 시간 막을지”, “어떤 로그를 남길지”를 정책 파일로 먼저 고정한다.
• 최근 30일 에이전트 사용량을 기준으로 종량제 호출 비용을 하트비트, 검색 요약, 문서 생성, 일반 대화로 나눠 집계한 뒤, 정액제 전환 시 손익분기점이 어디인지 계산한다.

❓ 열린 질문

• 정액제 Claude CLI 기반 구조는 개인 단위에선 예측 가능성이 높지만, 멀티채널·멀티에이전트로 확장될 때도 종량제 대비 총소유비용 우위를 유지할 수 있을까?
• 마크다운+SQLite 메모리 구조가 투명성은 높여도, 장기 누적 시 검색 품질 저하와 상충 정보 정리를 어떤 규칙으로 통제해야 실제 운영성이 유지될까?
• 발표자는 공급망 리스크를 비판했지만, Claude Code가 생성한 코드와 추가 스크립트에 대해서는 어떤 수준의 코드 감사와 권한 분리가 있어야 같은 문제를 반복하지 않을까?
• 하트비트 판단을 단일 LLM 질문에 맡길 때, 중요한 알림을 놓치는 오류와 사소한 알림을 남발하는 오류 중 어느 쪽이 더 큰 비용을 만들며, 이를 어떤 운영 지표로 튜닝해야 할까?