OpenClaw 뜯어보기: 39만 스타 오픈소스가 로컬을 고집하는 이유

2025년 11월에 Peter Steinberger가 주말 프로젝트로 시작한 저장소가 있다. 올해 1월 말에 갑자기 터져서 며칠 만에 9천 스타에서 6만 스타가 됐고, 지금은 38만 9천 스타, 8만 1천 포크, 커밋 9만 2천 개. GitHub 역사상 가장 빨리 큰 프로젝트라는 말이 과장이 아니다. OpenClaw 이야기다.

이 정도 숫자가 붙으면 보통 "또 AI 래퍼겠지" 하고 넘기게 되는데, README와 구조를 며칠 들여다보니 생각보다 오래된 원칙을 고집하는 프로젝트였다. 그 원칙이 왜 지금 먹혔는지가 궁금해서 정리한다.

무엇인가

한 줄로는 "내 컴퓨터에서 도는 AI 비서"다. 차이는 어디서 만나느냐에 있다. WhatsApp, Telegram, Slack, Discord, Google Chat, Signal, iMessage 등 20개가 넘는 채널에서 원래 쓰던 메신저 그대로 대화한다. macOS, iOS, Android, Windows, Linux용 앱이 따로 있고, 설치 스크립트가 Node 런타임까지 알아서 깔아준다. 요구 사항이 Node 24.16 이상 또는 26.1 이상인 걸 보면 최신 런타임 기능을 꽤 적극적으로 쓰는 것 같다.

핵심 문장은 이거다. "State, memory, and credentials live on your hardware." 상태, 기억, 자격 증명이 전부 내 하드웨어에 있다. 유료 티어도, 호스팅 서비스도 없다. MIT 라이선스고, 독립 비영리 재단(OpenClaw Foundation)이 핵심 팀을 고용하고 릴리스에 서명한다.

구조: 게이트웨이 하나에 다 걸린다

구성은 네 덩어리다.

Gateway: 세션, 도구, 이벤트, 채널 연결을 관리하는 로컬 컨트롤 플레인. 사실상 이 프로젝트의 전부다.
Channels: 메신저별 어댑터. 새 메신저를 붙이는 건 어댑터 하나 추가하는 일이다.
Tools & Skills: 에이전트가 실제로 뭔가를 하게 만드는 확장 지점.
Companion Apps: 음성, 캔버스, 카메라, 화면, 기기 로컬 동작을 담당하는 플랫폼별 앱.

내가 인상 깊게 본 건 보안 모델을 한 문장으로 못 박아둔 점이다. "trusted gateway, untrusted execution, deterministic policy." 게이트웨이는 신뢰하고, 실행은 불신하고, 정책은 결정적으로. 풀어 쓰면 이렇다. 무엇을 할지 결정하는 곳(게이트웨이)과 실제로 실행하는 곳을 분리하고, 실행 쪽은 언제든 이상한 짓을 할 수 있다고 가정하며, 허용 여부는 모델의 기분이 아니라 미리 정한 규칙이 정한다.

DM이 가능한 채널은 페어링 승인을 거쳐야 하고, 텔레메트리는 하루 한 번 버전 확인이 전부다. 기능 통계는 옵트인이다. 요즘 프로젝트치고는 보수적인 선택인데, 이 보수성이 이 프로젝트의 정체성이다.

왜 지금 로컬 퍼스트가 먹혔나

내 생각에는 세 가지가 겹쳤다.

첫째, SaaS 피로. 비서 하나 쓰려고 계정 만들고 결제 붙이고 데이터 넘기는 일에 다들 지쳤다. 둘째, 올여름 에이전트 사고들 이후 "내 자격 증명이 어디 있는가"가 갑자기 현실적인 질문이 됐다. 셋째, 메신저에서 만난다는 결정. 새 앱을 열게 만드는 순간 절반은 떨어져 나간다. 이미 열려 있는 창에 들어오는 게 이긴다.

이 셋 중에 기술적으로 어려운 건 하나도 없다. 그런데 셋을 동시에, 타협 없이 밀어붙인 프로젝트가 없었다. 바이럴은 기능이 아니라 태도에서 온 것 같다.

내 코드에 가져올 것

정책을 코드가 아니라 데이터로. "결정적 정책"이라는 말은, 허용 목록이 조건문 속에 흩어져 있으면 안 된다는 뜻이다. 내 서비스에서도 에이전트에 주는 권한을 설정 파일 한 곳에 모아두는 게 맞다.
실행은 항상 불신. 모델이 만든 명령을 실행하는 프로세스는 별도 권한, 별도 네트워크로. 이건 OpenClaw가 아니라 20년 된 원칙인데, AI가 들어오니 다시 새것처럼 보인다.
채널 어댑터 패턴. 입력이 어디서 오든 게이트웨이는 같은 이벤트를 받는다. 봇을 여러 메신저에 붙일 일이 있으면 이 구조를 그대로 쓰면 된다.

걱정되는 것

스킬 생태계다. 커뮤니티가 만든 스킬이 내 메신저와 내 자격 증명 옆에서 돈다. 재단이 릴리스에 서명하는 이유가 여기 있을 텐데, 서명은 재단 릴리스에만 붙지 서드파티 스킬에는 안 붙는다. 결국 사용자가 뭘 설치하는지 스스로 알아야 한다. 이건 npm이 겪은 공급망 문제를 그대로 다시 겪을 가능성이 크다.

그래도 방향은 맞다고 본다. 다음 주말에 직접 설치해서 게이트웨이 코드부터 읽어볼 생각이다. 특히 정책이 실제로 어디서 평가되는지, 그게 정말 "결정적"인지 확인하고 싶다.