OpenClaw, 그리고 그 대안들에 대해 알아봅시다

OpenClaw: 개인 AI 비서의 새 시대를 연 오픈소스 혁명

아마도, AI 커뮤니티에서, 또는 AI에 많은 관심을 가지고 계신 분이라면, OpenClaw를 모르는 분은 거의 없을 것 같습니다. GitHub에서 가장 빠르게 성장하는 레포지토리 중의 하나가 됐고, 스타 수도 자그마치 30만 개를 돌파하면서 수많은 실험적인 로컬 에이전트 프로젝트들의 물꼬를 텄습니다.

며칠 만에 OpenClaw의 창시자인 피터 슈타인버거(Peter Steinberger)는 렉스 프리드먼과 인터뷰를 했고, OpenAI에 합류했습니다 — 정확히 얼마를 받았는지는 아무도 모르지만요. 이 모든 걸 보면, OpenClaw는 이미 단순히 에이전트 분야에서 또 하나의 작은 진전을 이뤄낸 프로젝트, 그 이상이 되어가고 있다는 걸 알 수 있죠.

OpenClaw가 특별했던 이유 중에 하나라면, 아마 비교적 ‘가벼운 안전 장치’ 덕분에 모델의 실제 능력이 더 잘 확인되었고 실험하기도 쉬웠다는 점이 아닐까 합니다. 그런 의미에서 슈타인버거의 행보는 OpenAI의 초창기 ‘ChatGPT 모먼트’과 묘하게 닮아 있는 면도 있다고 생각합니다. 완벽하지 않더라도 강력한 것을 세상에 내놓고, 그 파장이 사람들의 대화의 토픽 자체를 바꾸게 두는 방식인 거죠.

그리고, OpenClaw는 지금까지 우리가 알고 있었던 ‘개인 AI 비서’의 세계 전체를 흔들어 놓았습니다.

막간을 이용해서, Anthropic의 뼈아픈 실수도 한 번 언급하고 넘어가야 할 것 같습니다. 원래 이 프로젝트 이름은 'Clawdbot'이었는데, Claude와 발음이 거의 똑같았어요. 그래서 Anthropic이 법적으로 압박을 가해서 이름을 'Moltbot'으로 바꾸게 했는데, 피터는 "이름이 입에 잘 붙지 않는다"면서 사흘 만에 다시 'OpenClaw'로 이름을 바꿨습니다 — 이름 변경만 두 번이나 일어난 거죠.

더 중요한 건 그 결과예요. OpenClaw는 초기에 Claude를 기본 모델로 추천하면서 Anthropic의 주요 트래픽 유입원이자 생태계 홍보대사 역할을 - 의도했든 아니든 - 하고 있었어요. 그 모멘텀을 잘 잡아서 프로젝트를 지원하거나, 피터를 영입하거나, 자사의 코딩 에이전트 생태계에 통합하는 대신, Anthropic은 변호사를 보냈고, 그 결과 피터는 OpenAI로 향하게 됐습니다. 미래에 이 순간을 다시 돌아본다면, 정말 아쉬운 판단의 순간이라고 생각하게 될지도 모르죠.

간단하게 말하자면, OpenClaw가 뭘까요?

OpenClaw는 ‘메시징 앱과 다양한 워크플로우에서 직접 행동을 취하는 ‘개인 AI 비서’를 만들기 위한 오픈소스 프레임웍’이라고 하면 될 것 같습니다. WhatsApp, Telegram, Discord, Microsoft Teams, 웹 채팅 등의 채널에 연결된 에이전트를 배포해서, 여러분을 대신해서 작업을 자동화할 수 있어요. 핵심적인 강점은 개인화로, 내 성격, 사용하는 툴, 선호도, 생활 방식에 맞게끔 비서를 직접 설정할 수 있구요.

그럼 오늘은, OpenClaw가 왜 중요한지, 그리고 OpenClaw의 내부는 어떻게 작동하는지 한 번 차근차근 풀어보려고 합니다. 아키텍처를 이해하면 이 시스템이 뭘 할 수 있고 뭘 할 수 없는지가 훨씬 명확해질 거예요. 이 프레임웍에는 꽤 흥미롭고 영리한 아이디어들도 숨어 있어요. 그리고, OpenClaw 대신 고려해 볼 만한 대안들도 몇 가지 소개하면서, OpenClaw를 둘러싼 논의의 핵심이 무엇인지도 짚어보도록 해 보겠습니다.

오늘 다룰 내용은 다음과 같습니다:

• OpenClaw 붐(Boom) — 어떻게 이 현상이 시작됐나

• OpenClaw는 어떻게 만들어졌나 - 아키텍처 분석

  • SOUL.md — 이게 새로운 이유

  • HEARTBEAT.md — 주기적인 에이전트 실행

  • MEMORY.md

• OpenClaw의 대안들

• OpenClaw 어디에 쓸 수 있나?

• OpenClaw의 한계

• 맺으며: 지금의 ‘로컬 에이전트 붐’, 뭘 뜻하나?

• 보너스 및 참고자료

OpenClaw 붐(Boom) — 어떻게 이 현상이 시작됐나

OpenClaw의 부상은, 빅테크나 대기업 신규 서비스처럼 화려하게 런칭한 것도, 치밀하게 준비된 롤아웃도 아니었습니다.

피터 슈타인버거의 말에 따르면, 최초의 프로토타입 — Anthropic Claude에 연결된 WhatsApp 릴레이 — 을 만드는 데 걸린 시간은 고작 한 시간이었다고 해요. 그리고 그 순간, 앱을 이리저리 전환하는 대신 그냥 에이전트한테 메시지를 보내면 알아서 처리해 준다는 사실이 눈에 들어온 거죠.

피터 스스로도, 이 작은 실험이 AI 업계 전체를 흔들어 놓을 거라고는 상상하지 못했을 거예요.

이건, 우리가 소프트웨어와 상호작용하는 방식에 관련된 더 큰, 엄청난 변화에 대한 이야기가 되고 있습니다. 피터는 많은 앱들이 사실상 인터페이스를 독점하기 위해 존재한다고 지적합니다. 에이전트가 여러분의 위치, 수면 패턴, 캘린더, 취향 같은 것들을 하나로 통합해서 인식하게 되면 — 그 어떤 단일 앱도 할 수 없는 방식으로 여러 가지 영역을 넘나들면서 추론도 하고 행동도 할 수 있게 될 겁니다.

어떤 앱들은 백엔드 API로 쪼그라들 테고, 어떤 것들은 그냥 사라질 거예요. OpenClaw는 사람들이 오랫동안 원해왔던, 실용적이면서 나와 관련된 맥락을 이해하는, 그런 ‘궁극적인 개인화/자동화의 꿈’에 가장 가까운, 그걸 가장 잘 보여주는 구현체라고 할 수 있습니다. 적어도 현재로는요.

이 프로젝트는 개발자들에게 엄청난 관심을 받았죠. 샌프란시스코에서 열린 'Claw's' 이벤트에는 700명 이상의 개발자가 몰렸고, Bay Area와 LA의 후속 밋업들도 밤새 매진되면서 참가하고 싶어했던 수백 명의 개발자들을 돌려보내야 했다고 해요. 2026년 2월 4일 샌프란시스코 프론티어 타워에서 열린 첫 번째 공식 커뮤니티 행사 ClawCon에는 500명의 참가자가 자기들이 직접 만든 에이전트들을 시연하러 찾아왔습니다. 피터의 말처럼 — "랍스터가 세상을 정복하고 있는" 모습이었던 겁니다.

기술 자체 외에도, 피터의 개인적인 스토리가 수많은 사람들에게 영감을 줬습니다.

앱 내에서 PDF를 처리하는 툴킷인 PSPDFKit을 13년 넘게 키워서 2024년 Nutrient에 매각한 피터는 번아웃을 겪고 코딩의 즐거움을 잃었다고 해요. 잠시 물러나서 여행을 다니다가, AI 에이전트를 직접 만지작거리면서 비로소 다시금 코딩의 기쁨을 되찾았고, 회사 매각으로 생긴 경제적 여유를 바탕으로 해서 한 달에 1만~2만 달러에 달하는 개인 인프라 비용을 감당하면서도 개인 에이전트의 방향성을 믿고 밀어붙일 수 있었다고 합니다. 돈보다 실험과 나눔을 먼저 생각하는 그 태도 — 많은 개발자들이 그동안 그리워하던 무언가, 어떤 정신이었다고 느꼈다는 반응이 많아요. 그리고 이 모든 것들이 오픈소스의 부활과 새로운 탐험의 시대에 딱 맞아떨어진 거구요.

그리고 여기에 또 하나의 큰 사건이 더해집니다. OpenClaw가 화제가 된 직후, 기업가 맷 슐리히트(Matt Schlicht)가 Moltbook을 공개했어요. AI 에이전트들만 사용할 수 있게끔 설계된 소셜 네트워크인데, 사람은 가입할 수 없고 에이전트만 글을 쓰고 서로 교류합니다. Wired가 "Moltbook 잠입기 — 사람은 가입할 수 없는 AI 전용 소셜 네트워크 (I Infiltrated Moltbook, the AI-Only Social Network Where Humans Aren’t Allowed)"라는 기사를 낼 만큼 대중의 상상력을 강하게 자극했고, OpenClaw 현상이 미디어 전반으로 퍼져나가는 결정적인 도화선이 됐습니다.

OpenClaw의 확산은 영미권에만 머물지 않았어요. DeepSeek 같은 중국산 LLM과 연동하는 설정 등이 커뮤니티에서 활발히 공유됐고, 바이두(Baidu)는 자사 스마트폰 앱에 OpenClaw를 직접 통합할 계획까지 발표했습니다. 단순한 영미권 해커 문화의 산물이 아니라, 진정한 글로벌 인프라 프로젝트임을 보여주는 대목이죠.

그리고 피터가 OpenAI에 합류하면서, OpenClaw는 OpenAI가 계속 지원하는 독립 오픈소스 재단으로 이관됐습니다. 이건 단순히 대기업이 인재를 영입한 것 그 이상이에요. (정확히 왜 그런 해석이 가능한지는 마지막 부분에서 말씀드리겠습니다.)

OpenClaw는 어떻게 만들어졌나 - 아키텍처 분석

OpenClaw의 가장 핵심적인 설계 상의 결정 사항은 단 하나입니다: 에이전트 자체를 코드라든가 매번 다시 입력해야 하는 프롬프트가 아니라, 디스크 위의 파일 모음으로 취급한다는 거예요.

정체성, 메모리, 스킬, 하트비트 규칙, 툴 정책 — 이 모든 게 워크스페이스 디렉토리 안에 평범한 마크다운 파일로 구현됩니다. 이 단 하나의 전환이, 에이전트를 ‘일회성 스크립트’로부터 ‘내구성 있고, 버전 관리 가능하고, 투명하게 들여다볼 수 있는’ 인프라로 바꿔버리는 겁니다.

우선, 백엔드가 어떻게 돌아가는지 살펴볼께요.

기본적으로, 텔레그램이나 WhatsApp 같은 메신저에서 메시지를 보내면, 채널 어댑터(Channel Adapter)가 그걸 OpenClaw의 중앙 게이트웨이(Central Gateway)로 전달합니다. 게이트웨이는 발신자를 확인하고, 어떤 에이전트와 세션이 처리해야 할지 파악하고, 대화 기록과 메모리를 불러오고, 툴·샌드박스 규칙을 적용한 뒤에 AI 에이전트를 실행해요. 에이전트는 툴을 호출하거나, 메모리를 검색하거나, 액션을 실행할 수 있고, 최종 응답은 동일한 메신저를 통해 돌려줍니다 — 이 모든 게 하나의 게이트웨이 프로세스가 조율하는 것이구요.

이게 간단한 설명이고, 이제 한 단계 더 들어가 볼께요.

먼저 중요한 건, OpenClaw는 겉으로는 챗봇처럼 보일 수 있지만 실제로는 자체 호스팅 AI 게이트웨이 — 언어 모델, 메시징 플랫폼, 툴, 기기, 장기 메모리 사이에 자리 잡은 컨트롤 플레인(Control Plane)이라는 점이에요.

시스템의 중심에는 'Gateway'라는 이름의 장시간 실행 프로세스가 하나 있습니다. 모든 것이 여기를 통해서 흐릅니다. 게이트웨이는 WebSocket 서버 (서버와 클라이언트 사이에서 실시간 양방향 통신을 가능하게 하는 연결 방식)로, 타입이 정의된 JSON-RPC 프로토콜 (요청-응답 형식으로 원격 함수를 호출하는 통신 규약)을 노출합니다. 클라이언트, 채널, 기기 노드 — 모두 여기에 연결되고, 에이전도는 여기를 통해서 실행됩니다. OpenClaw가 실행 중이라면, 게이트웨이가 세션, 라우팅, 툴 호출, 상태 등에 관한 최종 권한을 갖습니다.

WhatsApp, Telegram, Discord, Slack, Signal 같은 메시징 플랫폼들은 어댑터 역할을 해요. 각각은 플랫폼별 프로토콜을 표준화된 내부 엔빌로프(Envelope) 형태로 변환합니다. 메시지가 도착하면 채널 어댑터가 발신자 정보, 스레드·그룹 컨텍스트, 첨부파일, 메타 데이터를 추출해서 구조화된 이벤트를 게이트웨이로 전달하죠. 그 순간부터 시스템 안에서 모든 메시지는 동일한 방식으로 보입니다.

그다음은 라우팅이에요. 게이트웨이는 아래와 같은 정보를 인코딩한 세션 키(Session Key)를 확인합니다:

• 담당하는 에이전트

• 메시지가 온 플랫폼

• 다이렉트 메시지인지 그룹 메시지인지

• 어떤 스레드에 속하는지

Slack 스레드, Telegram 그룹, WhatsApp DM은 모두 다른 세션 스코프가 됩니다. 이 키가 어떤 대화 기록을 불러올지, 어떤 메모리가 적용될지, 격리를 어떻게 강제할지를 결정해요.

세션은 에이전트 디렉토리 아래에 저장된 JSONL (JSON Lines — 한 줄에 하나의 JSON 객체를 저장하는 텍스트 포맷) 형식의 대화 기록입니다. 기록, 모델 오버라이드, 툴 결과, 런타임 플래그를 추적하죠. OpenClaw는 라우팅 설정에 따라서 세션을 순차적으로, 동시에, 또는 'collect' 모드로 배치 처리할 수 있습니다. 세션은 유휴 시간, 일일 스케줄, 수동 트리거 등에 따라서 리셋될 수 있습니다.

에이전트는 ‘실행 런타임’입니다. 각각의 에이전트는 고유한 정체성, 워크스페이스 디렉토리, 모델 설정, 툴 정책을 가지게 됩니다. 여러 에이전트가 하나의 게이트웨이 인스턴스 안에 공존할 수 있고, 명시적으로 설정하지 않는 한 메모리나 컨텍스트를 공유하지 않습니다.

워크스페이스는 에이전트의 정체성이 구체화되는 곳이라고 하겠습니다. AGENTS.md, SOUL.md, TOOLS.md 같은 파일들이 시스템 프롬프트를 구성하는 중에 읽히게 됩니다. workspace/skills/ 디렉토리 안의 스킬들은 자동으로 발견(Discovery)되고, 프롬프트 부트스트랩 과정에 인젝션됩니다. 스킬은 SKILL.md와 메타데이터로 구성된 묶음이고, 그 문서의 내용이 에이전트의 인식 능력의 일부가 됩니다. 모델이 파악해 내게 되는 능력 자체가, 디스크 위의 실제 파일들로부터 조립되는 거죠.

요컨대 OpenClaw는, 에이전트가 ‘구조화된 스킬을 지속적으로 습득하고 활용함으로써 실제로 할 수 있는 것들을 확장해나간다’는 아이디어 위에 만들어져 있는 겁니다.

툴 실행은 계층적인 정책 체인을 통해서 필터링됩니다.

• 전역 허용/차단 규칙이 먼저 적용됩니다.

• 플랫폼별 제한이 그 다음에 옵니다.

• 에이전트 수준의 오버라이드가 이걸 더 다듬습니다.

• 그룹별 오버라이드가 추가로 범위를 좁힐 수 있습니다.

• 마지막으로 샌드박스 제한을 통해서 뭐가 최종적으로 살아남을지 결정합니다.

기본적으로 툴은 게이트웨이 호스트 위에서 실행되지만, OpenClaw는 Docker 컨테이너 (애플리케이션을 격리된 환경에서 실행하는 가상화 기술) 안에서 툴 실행을 샌드박싱할 수도 있습니다. 격리 범위는 세션별, 에이전트별, 또는 공유로 다양하게 설정할 수 있습니다. 워크스페이스 접근은 읽기 전용, 읽기-쓰기, 또는 비활성화로 설정할 수 있고요.

실행은 macOS, iOS, Android 위에서 실행되는 컴패니언 앱 같은 기기 노드로 라우팅될 수도 있어서 카메라 접근, 알림, 셸 명령, 시스템 쿼리 같은 기능을 노출할 수 있습니다. 그런 경우에 게이트웨이는 로컬 프로세스를 실행하는 역할에서 분산 실행을 코디네이션하는 역할로 변신하게 되는 셈이죠.

SOUL.md — 이게 새로운 이유

파일들 중에서 특히 눈에 띄는 것이 바로 SOUL.md입니다.

AGENTS.md가 ‘능력’을 정의하고 TOOLS.md가 ‘접근 권한’을 정의한다면, SOUL.md는 ‘정체성을 정의’합니다. 이 파일 덕분에 에이전트가 ‘고유성’을 가지게 되고, 진짜 '나만의' 것이 됩니다. 톤, 성격, 장기적인 행동 특성, 지속적인 선호도를 형성하면서요. 임시적인 시스템 프롬프트가 아니라, 워크스페이스 안에서 살아 숨쉬는 내구적인(Sustainable) 캐릭터 레이어가 되는 겁니다.

대부분의 에이전트 프레임웍은 이런 ‘성격’을 런타임 파라미터나 프롬프트 문자열 정도로 취급합니다. OpenClaw는 이걸 외부화해서 코드처럼 버전 관리도 하고, 문서처럼 편집할 수 있고, 세션 전반에 걸쳐서 지속되는 파일로 만들었습니다.

정말 멋진 건, ‘정체성’이 ‘파일’이라는 형태로 만들어지면, 아래와 같은 특성을 갖게 된다는 거예요:

• 투명하게 확인 가능 (Inspectable)

• 이식 가능 (Portable)

• 감사 가능 (Auditable)

• 진화함 (Evolvable)

다시 말해서, '성격'이라는 요소가 ‘프롬프트 엔지니어링’이 아니라 인프라의 일부가 되는 겁니다. 성격을 다룬다는 게, 우리가 AI에 보내는 ‘요청(Request)’에다가 감성을 주입(Injection)하는 게 아니라, 구조화되고 내구적인 ‘자기 정의 (Self-defining) 레이어’를 유지 관리하는 일이 되는 거죠.

물론, 이런 방식이 지배적인 패턴이 될지는 두고 봐야겠지만, ‘임시적인 프롬프팅’ 형태로부터 ‘지속 가능한 에이전트 정체성’으로의 의미 있는 이동이라는 점만은 분명합니다.

HEARTBEAT.md — 주기적인 에이전트 실행

잘 알려져 있지는 않지만, 구조적으로 중요한 파일이 또 하나 있습니다: 바로 HEARTBEAT.md 입니다.

메시지를 받았을 때만 반응하는 챗봇과 달리, OpenClaw는 주기적으로 에이전트 턴(Turn)을 트리거하도록 설정할 수 있습니다. 정해진 간격마다 게이트웨이가 백그라운드 세션 이벤트를 시작하면, 모델이 HEARTBEAT.md를 읽고 — 파일이 있다면 — 어떤 행동을 해야 하는지 판단합니다.

별로 중요한 게 없으면, 에이전트는 HEARTBEAT_OK 응답을 반환하고 이벤트는 종결됩니다. 반면에, 뭔가 주의가 필요한 게 있다면, 설정된 채널(WhatsApp이나 Telegram 등)을 통해서 알림을 보내죠.

HEARTBEAT.md 파일은 아주 단순하게 생겼는데, 이건 의도된 겁니다. 예를 들면:

# 하트비트 체크리스트

- 긴급한 항목이 있는지 받은 편지함을 확인한다.
- 낮 시간대에 다른 알림이 없으면 간단한 근황 확인 메시지를 보낸다.
- 작업이 막혀 있다면, 어떤 것이 부족한지 명시한다.

이 파일은 원할 때 언제든지 편집할 수 있고, 의도한 행동과 실제의 사용 사이에 갭(Gap)이 감지되면 에이전트가 직접 체크리스트를 업데이트할 수도 있게 되어 있습니다.

스케줄링 파라미터 — 간격, 활성 시간대, 선호 채널, 그리고 백그라운드 평가에 사용할 모델까지 — 는 시스템 설정 파일에서 정의되구요.

기술적으로는 크론 시스템 (특정한 시각에 명령을 자동 실행하는 스케줄러)과 비슷하지만, 개념적으로는 다릅니다. 에이전트를 ‘순수하게 반응하는 존재’에서 ‘주기적으로 판단하는 존재’로 바꿔주죠. 에이전트가 ‘누군가 자기에게 말을 걸기’를 기다리는 게 아니라, ‘스스로 컨텍스트를 검토하고 개입이 필요한지 결정’하게 됩니다.

그런 관점에서, 이 메커니즘은 크론 시스템이나 워크플로우 엔진을 대체하는 게 아니라, 에이전트의 운영 루프 안에 ‘주기적인 추론 활동’을 직접적으로 내장하는 것으로 보는게 맞겠습니다. 그리고, ‘개인 에이전트 시스템’에서는 그 차이가 꽤 중요합니다.

MEMORY.md

OpenClaw에서 메모리가 어떻게 작동하는지도 흥미로운데요. 메모리는 파일에 기반을 두는데, ‘Source of Truth’는 마크다운 — MEMORY.md, 데일리 로그, 워크스페이스 노트 — 형태입니다. 그 위에 메모리 파일과 세션 트랜스크립트 전부를 인덱싱하는 하이브리드 검색 엔진이 얹혀 있습니다.

텍스트는 청킹(Chunking) (긴 텍스트를 겹치는 조각으로 나누는 방식)을 해서 임베딩(Embedding; 텍스트를 숫자 벡터로 변환하는 과정. 임베딩 도구는 설정 가능)하는데, 의미론적 유사도와 키워드 점수의 가중 조합으로 랭킹을 매깁니다.

설정 자체도 인프라 세팅하듯이 합니다. 전체 시스템은 스키마 검증을 거치는 JSON 파일로 구동되고, 설정이 잘못되면 게이트웨이 자체의 실행이 되지 않습니다.

변경 사항은 모드에 따라 다르게 반영되는데, 안전한 변경이라면 즉시 적용, 네트워크 수준의 변경은 환경이 잘 제어된 상태에서 재시작할 수 있게끔 합니다.

전체적으로, 게이트웨이는 JSON-RPC WebSocket 프로토콜을 통해서 모든 것을 조율합니다. 에이전트, 세션, 설정, 채널, UI, CLI, 기기 노드 — 이 모든 것들이 동일한 통합 컨트롤 플레인을 통해서 통신하는데, 처음부터 끝까지 일관된 흐름으로 움직입니다:

1. 메시지가 채널 어댑터를 통해 입수

2. 접근 정책이 적용

3. 세션 키가 결정되고 세션 상태를 호출

4. 툴 정책을 계산

5. 샌드박스 규칙 적용

6. 워크스페이스와 스킬로부터 시스템 프롬프트를 구성

7. 메모리 검색 실행

8. 모델 공급자를 호출, 툴이 실행

9. 결과가 스트리밍으로 반환, 응답이 원래 채널을 통해 나감

아키텍처적으로 보면, OpenClaw는 중앙 컨트롤 플레인을 중심으로 구축된 스테이트풀(Stateful) AI 운영체제라고 볼 수 있습니다. 채널은 트랜스포트 엣지, 세션은 연속성을 다루고, HEARTBEAT.md로 설정된 예약된 턴이 ‘연속성’을 ‘반응형 메시징 그 이상’으로 확장합니다. 에이전트는 실행의 경계, 워크스페이스는 정체성, 툴은 기능을 정의하고, 샌드박스는 안전을 담당하고, 메모리는 지속성을, 노드는 구현(Embodiment)을 정의하죠. 그리고 게이트웨이가 그 중심에서 모든 활동이 ‘질서있게 수행’되도록 조정하고 강제합니다.

물론, 하이레벨하게는 OpenClaw의 워크플로우도 다른 로컬 에이전트 프레임웍들과 비슷합니다만, 구조적으로는 훨씬 더 ‘인프라에 가깝습니다’. LangChain, CrewAI, AutoGen, AutoGPT 같은 대부분의 로컬 에이전트는 애플리케이션 수준의 프레임웍이라고 할 수 있을 겁니다 - 개발자들이 코드로 체인이나 에이전트 그래프를 정의하고, 툴을 연결하고, 자기만의 런타임 안에서 실행을 조정합니다.

OpenClaw는 동일한 핵심적인 추론 루프 — 메시지 → 컨텍스트 → 프롬프트 → 툴 결정 → 모델 호출 → 툴 실행 → 응답 → 영속화 — 를 따르지만, 그 루프를 중앙화된 컨트롤 플레인 안으로 이동시키고 있습니다.

대부분의 로컬 에이전트에서 라우팅 로직, 메모리 처리, 툴 정책은 개발자의 애플리케이션 코드 안에서 정의됩니다. 오케스트레이션 루프도 개발자가 만들고 통제하는 동일한 프로세스 안에서 실행되게 되죠. 반면에, OpenClaw는 그 책임을 중앙화된 컨트롤 플레인으로 이동시키고, 백그라운드 서비스로 실행되는 작은 AI 운영체제처럼 동작하게 되는 겁니다.

또 다른 차이는 멀티채널 통합이라고 볼 수 있을 겁니다. OpenClaw는 메시징 플랫폼들을 어찌보면 가장 중요한, 우선적인 입력 수단으로 취급하고, 여러 메시징 플랫폼들을 내부적인 파이프라인으로 끌어들이면서 공통화/정규화해 놓았습니다. 다른 로컬 에이전트 프레임웍에서는 기본적으로 CLI, 웹 인터페이스, 아니면 API를 노출하고, 메시징 통합은 필요할 때 별도로 구현하는 경우가 많거든요. 실용적인 관점에서, OpenClaw의 접근 방식이 진입 장벽을 더 낮춰준다고 볼 수 있습니다 - 터미널을 여는 대신 WhatsApp이나 Telegram에서 바로 에이전트와 대화할 수 있으니까요.

메모리 시스템도 더 인프라 지향적이에요. 벡터 데이터베이스가 로컬 에이전트 메모리를 다루는 고전적인 기술이라면, OpenClaw는 마크다운 파일을 ‘Source of Truth’로 삼고 그 위에 하이브리드 시맨틱 인덱스를 구축합니다 — 메모리에 명시적인 파일 기반 의미론을 부여하는 깔끔하고 영리한 방식이라고 생각합니다.

OpenClaw의 대안들

OpenClaw를 둘러싼 '붐' 이야기로 돌아오면, 그 핵심 아이디어에서 영감을 받은 새로운 오픈소스 에이전트들이 파도가 치듯이 많이 등장하고 있습니다. 그 대안들 중 대부분이 경량(Lightweight)이고, 실제로 적용하기도 더 쉬운 경우도 많아요. 아래 표로 먼저 한눈에 간단히 비교해 보고, 각각에 대해서 조금 더 자세히 살펴볼게요.

PicoClaw는 Go로 재설계된 ‘경량 AI 어시스턴트’ 프레임웍으로, 제약 조건이 강한 하드웨어에서 실행되게끔 만들어졌어요. 10달러짜리 Linux 보드 같은 기기에서도 작동하고, 10MB 미만의 RAM으로 운영할 수 있습니다. 채팅 통합, 툴, 메모리, 예약 작업, 샌드박싱된 실행을 지원하면서도 훨씬 Footprint가 작아요. 부팅은 약 1초, RISC-V, ARM, x86을 지원하는 싱글 바이너리로 배포됩니다.

nanobot은 핵심 에이전트 로직이 약 4,000줄의 파이썬으로 구성되어 있어서 — Clawdbot의 43만 줄 이상에 비하면 1% 정도죠 — 처음부터 끝까지 혼자 읽고 이해할 수 있을 만큼 작습니다. Telegram, Discord, WhatsApp 같은 채팅 채널과 툴, 메모리, 예약 작업을 지원하고, Qwen, DeepSeek, Kimi, MiniMax, vLLM 모델은 물론 MCP 서버까지 작동해요. 추상화를 줄이고, 빠른 시작(원클릭 배포)을 지향하고, 더 쉬운 해킹과 실험·연구를 위한 깔끔한 코드베이스를 목표로 합니다.

ZeroClaw는 Rust로 만든 AI 어시스턴트 런타임으로 작고 빠르게 작동하게끔 설계됐어요. 3~9MB의 싱글 바이너리로 실행되고, 5MB 미만의 RAM을 사용하고, 저사양 하드웨어에서도 약 10ms 만에 구동됩니다. SQLite 하이브리드 메모리, Telegram/Discord/Slack 채널, 페어링 코드, 강력한 워크스페이스 샌드박싱을 지원합니다.

IronClaw는 Rust로 만들어진 보안 중심의 개인 AI 어시스턴트로, 모든 것을 로컬에서 내가 원하는 규칙대로 실행합니다. 프롬프트 인젝션이나 데이터 유출을 막는 다중 레이어를 갖추고 있어요. 데이터는 PostgreSQL에 저장하고, 기밀 사항은 암호화하고, 신뢰할 수 없는 툴은 엄격한 권한과 엔드포인트 허용 목록이 있는 WebAssembly 샌드박스 안에서 실행됩니다. 여러 채팅 채널, 크론 루틴, 백그라운드 작업, 다이나믹 툴 생성을 지원합니다.

TinyClaw는 코더, 라이터, 리뷰어처럼 여러 가지의 '역할'을 동시에 돌리는 멀티 에이전트 어시스턴트로, 각각 격리된 워크스페이스 폴더에서 실행됩니다. Discord, WhatsApp, Telegram을 지원하고, 경쟁 조건(Race Condition)을 피하기 위한 파일 기반 큐를 유지 관리합니다. 에이전트들이 체인이나 병렬 팬아웃 방식으로 서로에게 작업을 넘길 수 있습니다. tmux에서 24/7 실행되고, 재시작 후에도 세션을 유지하고, 공식 CLI를 통해서 Claude 또는 Codex를 사용합니다.

MimiClaw는 단돈 5달러짜리 ESP32-S3 마이크로컨트롤러 위에서 직접 실행되는 초소형의 OpenClaw 스타일 에이전트예요. Linux도, Node.js도, OS도 없이 약 99.2% 순수 C로 베어 메탈에 컴파일됩니다. Telegram을 통해서 Claude에 연결하고, 16MB 플래시에 메모리를 저장하고(마크다운 + JSONL), 재부팅 후에도 살아남아요. 소모 전력이 약 0.5W로 USB 전원으로 24/7 운영을 할 수 있습니다.

OpenClaw 어디에 쓸 수 있나?

아직 OpenClaw를 써보지 않으셨다면 — 이미 쓰고 계신다면 더 좋죠 — 실용적으로 생각해 볼 만한 사용처, 그리고 새로운 아이디어 몇 개를 소개해 볼까 합니다.

OpenClaw는 앱, 메뉴, 반복되는 작업들 사이에 뭔가 내 대신 다른 사람이 작업을 해 줬으면 하고 느끼는 분이라면, 그런 영역이라면 어디든 유용하게 쓸 수 있습니다. 메신저 앱에서의 일상적인 대응을 자동화한다거나, Reddit이나 YouTube를 요약한다거나, 받은 편지함 정리, 리서치 요약, 시장 전략 분석, 프로젝트 조율, 뉴스레터 요약, 가족용 캘린더, Twitter/X 분석, 심지어 간단한 DevOps까지도요.

자율 목표 시스템을 돌리는 데도 쓸 수 있어요 — 에이전트가 스스로 작업을 생성하고, 스케줄링하고, 실행하게 하는 거죠. 여러 에이전트를 쌓아서 리서치, 초안 작성, 나아가 컨텐츠 파이프라인의 썸네일 준비 같은 것까지 맡길 수도 있어요. 메모리와 함께 활용하면, 링크를 통해서 유용한 소스를 추가하는 개인 지식 베이스를 구축하는 것도 가능합니다.

OpenClaw를 기존 시스템 위의 자동화 레이어로도 활용할 수 있어요.

• API 오케스트레이션 → Google 캘린더, Stripe, Notion, GitHub 같은 외부 서비스를 호출하고, 출력값을 결합하고, 워크플로우를 트리거할 수 있습니다.

• 크론 작업 실행 → 특정 시간에 자동으로 예약된 작업을 수행합니다.

• SSH로 서버 관리 → 서버에 연결해서 명령을 실행하고, 업데이트를 배포하거나, 로그를 확인하거나, 서비스를 재시작할 수 있습니다.

반복적인 작업이 생각날 때마다, OpenClaw를 활용해서 작게라도 자동화 실험을 해 보세요. 이런 연습이 쌓여 간다면, 꽤 유용한 습관이 될 지도 모르니까요.

로컬에 아무것도 설치하고 싶지 않다면, 지금은 브라우저 기반 환경에서 몇 초 만에 전체 OpenClaw 런타임을 실행할 수 있는 곳들도 생겼습니다. 일부는 완전히 클라이언트 사이드로 동작하고(API 키가 브라우저 세션에 남는 방식), 다른 것들은 라이브 게이트웨이 인스턴스에 연결해서 세션, 스킬, 로그, 파일을 시각적으로 관리할 수 있게 해 주기도 합니다.

OpenClaw의 한계

물론, 대단하다고만 할 건 아니고, 냉정하게 짚어봐야 할 지점들이 있습니다.

• 보안 문제

  생각보다 심각합니다. OpenClaw의 강점 — 시스템 수준의 접근, 툴 실행, API 오케스트레이션, SSH, 브라우저 제어 — 은 동시에 보안의 위협이기도 합니다. 잘못 설정된 툴 정책, 탈취된 API 키, 악의적인 스킬 등은 심각한 결과를 만들어 낼 수 있습니다.

• 프롬프트 인젝션 및 툴 조작 공격
  보안 영역의 연구자들은 아주 구체적인 위협이 있다고 지적하고 있는데요. 손상된 모듈이 권한 확대나 임의 코드 실행을 할 수 있게끔 하는 공급망 공격 위험, OpenClaw를 사칭한 악성 사기 웹사이트와 무단 배포본, 외부 컨텐츠를 탐색할 수 있는 모든 에이전트 시스템에 공통적으로 적용되는 프롬프트 인젝션(Prompt Injection) 및 툴 조작 공격 가능성 등이 그런 것들입니다. 그래서, OpenClaw는 격리된 샌드박스 환경에서만 운영하고, 실제 운영 시스템이나 민감한 자격 증명과 직접 연결해 놓는 것은 피하라고 강력히 권고를 하고 있습니다.

• 빠른 진화의 이면, 불안정성으로 나타나는 변화의 속도

  이런 프로젝트는 그 변화의 속도가 아주 빨라서, 설정 스키마, 툴 동작, 확장 패턴이 금방 바뀔 수 있습니다. 이런 바른 변화는 개발자들에게는 재미있는 일이기도 하지만, 프로덕션 환경에서는 불안정성을 높이는 요소가 됩니다.

• 운영의 복잡성
  OpenClaw는 아직은 비개발자도 플러그-앤-플레이(Plug-and-Play) 형태로 사용할 수 있는 수준은 아닙니다. 대화형 인터페이스가 있지만, 여전히 인프라 소프트웨어인 거죠. 안전하게 실행하려면 Docker, 환경 변수, API 관리, 샌드박스 정책 같은 개념과 도구들에 익숙해야 할 수도 있습니다. 물론 노력하면 충분히 할 수 있습니다.

• 환경 관리를 위한 추가 설정
  Unix 계열 환경을 전제로 하기 때문에, Windows 사용자에게는 WSL2 (Windows 안에서 Linux를 실행하는 호환 레이어)를 통한 추가 설정이 필요하구요.

• 기업 환경에는 아직 이름
  규제가 많거나 보안이 중요한 기업이라면, 광범위하게 배포하기 전에 추가적인 강화, 감사, 거버넌스가 당연히, 그리고 무조건 필요합니다.

• 생태계 지속 가능성
  대규모 공용 인프라 호스팅은 비용이 많이 들어서, 장기적인 지속 가능성은 재단에 대한 펀딩과 OpenAI의 지원이 아주 중요합니다. 이런 점 때문에 바로 ‘대규모 에이전트 시스템의 경제학’이 여전히 최종적으로 증명된 상태가 아니라 여전히 한 발 한 발 나아가고 있는 시점이라는 걸 실감하게 되기도 합니다.

물론, 이런 한계들 자체가 혁신의 가능성을 부정한다기보다는, 오히려 OpenClaw – 그리고 수많은 대안 프로젝트들 – 가 앞으로 어떤 지점에 집중해야 하는가 하는 방향을 보여준다고 해석하는 것이 좋겠습니다.

맺으며: 지금의 "로컬 에이전트 붐"은 무엇을 의미하는가?

OpenClaw는 강력하고, 실험적이고, 계속해서 성숙해가는 인프라로 이해하는 게 가장 정확한 관점이라고 생각합니다. 오랫동안 프론티어 랩들에서는, AI 개발의 최종 정착지가 ‘모델 스케일링’인 것처럼 거기에 집중해 왔지만, 이제 OpenClaw의 등장 이후에는 그 핵심적인 역할이 오케스트레이션(Orchestration) — 에이전트들이 서로 상호작용하고, 작업을 조율하고, 컨텍스트를 관리하고, 툴과 서비스 전반에서 작동하는 방식 — 으로 이동하고 있다는 걸 다시 한 번 확인하게 되었습니다.

그리고 이 새로운 구도에서, ‘개인 에이전트는 의미있는 제품 레이어’가 되어가고 있습니다.

피터 슈타인버거가 OpenAI에 합류해서 ‘개인 에이전트’ 분야를 이끌게 됐다는 소식, 세 가지 의미가 있다고 생각합니다:

• 첫째, 에이전트 개발 방향의 검증. 세션 연속성, 툴 제어, 시스템 수준의 실행, 멀티 에이전트 설계를 중심으로 한 방향성에 힘이 실리게 되었습니다.

• 둘째, 하이브리드 미래의 신호. 피터가 OpenClaw를 재단 아래 계속 살아있게 하고, OpenAI가 공개적으로 오픈소스 지원을 선언한 것은, 지금까지 우리에게 익숙한 폐쇄 생태계 대 오픈소스의 대결이 아니라, 오픈소스의 기반 위에 세워질 상업적 스케일이라는 계층적 공존의 미래를 시사하고 있습니다.

• 셋째, 멀티 에이전트 시대의 가속화. OpenAI가 에이전트들이 서로 상호작용하는 시스템을 우선시한다면, 앞으로 AI 시스템의 ‘설계’는 조율, 정책, 정체성, 신뢰, AI가 생성한 행동을 명확히 표시하는 것, 그리고 'AI 슬롭(AI Slop)' (AI가 대량으로 생성한 저품질 콘텐츠가 인터넷을 도배하는 현상)이 인간의 공간을 압도하지 않도록 방지하는 문제로 그 초점이 바뀌게 됩니다.

‘OpenClaw 모먼트’가 우리에게 보여준 건 이겁니다: 바로, 오픈소스가 AI 핵심 인프라의 일부가 되어가고 있고, ‘단순한 데모’에서 출발했던 개인 에이전트는 ‘내구적인 시스템’의 영역으로 이동하고 있다는 것이요. 이제, 앞으로 우리가 던지게 될 질문들은 인프라 설계, 조율(Orchestration), 그리고 신뢰라는 영역으로부터 많이 나오게 될 겁니다.

보너스 및 참고자료

• OpenClaw, OpenAI and the future by Peter Steinberger

• OpenClaw Website | GitHub | DeepWiki

• OpenClaw: The Viral AI Agent that Broke the Internet - Peter Steinberger | Lex Fridman Podcast #491

• PicoClaw GitHub

• nanobot GitHub

• ZeroClaw GitHub

• IronClaw GitHub

• TinyClaw GitHub

• MimiClaw GitHub

• Awesome OpenClaw Use Cases GitHub

읽어주셔서 감사합니다. 친구와 동료 분들에게도 뉴스레터 추천해 주세요!