GitHub을 뒤흔든 우주 바닷가재, OpenClaw 리뷰: 개인 AI 비서의 아키텍처와 보안 딜레마

들어가며: 2026년, "AI 비서"가 진짜로 컴퓨터를 다루기 시작했다

2026년 상반기 오픈소스 AI 진영에서 가장 화제가 된 프로젝트를 하나만 꼽으라면 단연 OpenClaw입니다. GitHub 스타가 수개월 만에 24만 개를 넘겼고, OpenAI·GitHub·NVIDIA가 후원사로 이름을 올렸으며, 창시자는 프로젝트가 폭발한 직후 OpenAI에 합류했습니다. 우주 바닷가재(space lobster)를 마스코트로 내세운 이 프로젝트는 단순한 챗봇이 아니라 "실제로 일을 하는(actually does things)" 개인 AI 비서를 지향합니다.

이 글은 OpenClaw 저장소(openclaw/openclaw)의 README, VISION 문서, 아키텍처 가이드(AGENTS.md)를 직접 읽고, 외부 리서치를 더해 이 프로젝트가 기술적으로 무엇을 하는 물건인지 정리한 리뷰입니다. 화려한 데모 영상 너머에서 OpenClaw가 어떤 설계 철학으로 만들어졌는지, 그리고 왜 보안 연구자들이 동시에 우려를 쏟아냈는지를 함께 살펴봅니다.

배경: Warelay에서 OpenClaw까지, 그리고 이름의 수난사

OpenClaw의 정체를 이해하려면 그 출신을 알아야 합니다. 이 프로젝트는 오스트리아 개발자 Peter Steinberger가 2025년 11월 Warelay라는 이름으로 처음 공개했습니다. 원래는 그가 만들던 개인 비서 Clawd(현재의 Molty)에서 파생됐는데, Clawd라는 이름 자체가 Anthropic의 챗봇 Claude에서 따온 것이었습니다.

이름은 두 달 사이에 두 번 바뀌었습니다. 2026년 1월 27일 Anthropic의 상표권 문제 제기로 Moltbot(바닷가재가 허물을 벗는다는 "molt"에서 따온, 갑각류 테마 유지)으로 바뀌었고, 사흘 뒤 창시자가 "Moltbot이라는 이름이 입에 잘 붙지 않는다"는 이유로 다시 OpenClaw로 정착했습니다. 저장소의 VISION 문서는 이 계보를 한 줄로 요약합니다.

It evolved through several names and shells: Warelay -> Clawdbot -> Moltbot -> OpenClaw.

이름이 여러 번 바뀐 만큼 정체성도 빠르게 진화했습니다. VISION 문서는 OpenClaw가 "AI를 배우고 진짜로 쓸모 있는 무언가를 만들려던 개인 놀이터(personal playground)"에서 출발했다고 밝힙니다. 목표는 명료합니다. 쓰기 쉽고, 다양한 플랫폼을 지원하며, 프라이버시와 보안을 존중하는 개인 비서를 만드는 것입니다. 2026년 2월 14일 Steinberger가 OpenAI로 자리를 옮긴 뒤, 프로젝트는 OpenAI를 후원사로 둔 독립 오픈소스 재단으로 이관됐습니다.

OpenClaw는 무엇인가: "Gateway는 통제 평면, 제품은 비서다"

README의 첫 문장이 이 프로젝트의 핵심을 정확히 짚습니다.

The Gateway is just the control plane — the product is the assistant.

OpenClaw의 중심에는 Gateway라는 단일 통제 평면(control plane)이 있습니다. Gateway는 세션, 채널, 도구(tool), 이벤트를 한곳에서 관리하는 로컬 우선(local-first) 프로세스입니다. 사용자는 이 Gateway에 직접 명령을 내리지 않습니다. 대신 자신이 이미 쓰는 메신저로 비서에게 말을 겁니다. 지원 채널 목록이 압도적인데, WhatsApp·Telegram·Slack·Discord·Google Chat·Signal·iMessage·IRC·Microsoft Teams·Matrix·Feishu·LINE·Mattermost·Nextcloud Talk·Nostr·Synology Chat·Tlon·Twitch·Zalo·WeChat·QQ·WebChat까지 20종이 넘습니다.

여기서 중요한 개념이 멀티 에이전트 라우팅(multi-agent routing)입니다. 들어오는 채널·계정·상대방을 서로 격리된 에이전트로 라우팅할 수 있습니다. 각 에이전트는 독립된 워크스페이스와 세션을 가지므로, 가족 단톡방에 붙은 비서와 업무용 Slack에 붙은 비서를 완전히 분리해 운영할 수 있습니다.

비서 자체의 능력도 단순한 질의응답을 넘어섭니다. README의 하이라이트는 다음을 강조합니다.

Live Canvas: 에이전트가 직접 그리는 시각 작업 공간으로, A2UI를 통해 사용자가 제어합니다.
Voice Wake + Talk Mode: macOS/iOS에서 웨이크워드로 깨우고, Android에서 연속 음성 대화가 가능합니다(ElevenLabs + 시스템 TTS 폴백).
First-class tools: 브라우저, 캔버스, 노드(nodes), cron, 세션, Discord/Slack 액션이 일급 도구로 제공됩니다.
Companion apps: Windows Hub, macOS 메뉴바 앱, iOS/Android 노드가 선택적으로 붙습니다.

저장소 구조를 보면 이 야심의 규모가 드러납니다. apps/ 아래에는 android·ios·macos 네이티브 앱이, packages/ 아래에는 agent-core·llm-core·llm-runtime·gateway-protocol·speech-core·media-generation-core 등 20여 개의 코어 패키지가 모듈로 분리돼 있습니다. TypeScript 파일만 1만 6천 개가 넘는 대형 모노레포입니다.

왜 TypeScript인가: 해킹 가능성을 최우선으로

OpenClaw가 Python이 아니라 TypeScript로 작성됐다는 점은 의외로 받아들여지기도 합니다. AI 에이전트의 표준 언어는 사실상 Python이기 때문입니다. VISION 문서는 그 이유를 분명히 밝힙니다.

OpenClaw is primarily an orchestration system: prompts, tools, protocols, and integrations.

즉 OpenClaw는 모델을 학습시키는 시스템이 아니라 프롬프트·도구·프로토콜·통합을 엮는 오케스트레이션 시스템이라는 것입니다. 무거운 수치 연산이 아니라 "여러 외부 표면을 어떻게 연결하느냐"가 본질이므로, 널리 알려져 있고 빠르게 반복 개발할 수 있으며 읽고 수정하고 확장하기 쉬운 TypeScript를 택했다고 설명합니다. 핵심 가치는 "기본값으로 해킹 가능하게(hackable by default)" 유지하는 것입니다.

설계 철학: 린(lean) 코어, 플러그인이 능력을 키운다

OpenClaw의 AGENTS.md는 단순한 기여 가이드가 아니라 강한 아키텍처 신념의 집합체입니다. 그중 일관되게 반복되는 원칙이 "코어는 마르게, 능력은 플러그인으로"입니다.

VISION 문서는 이렇게 못 박습니다. 코어는 가능한 한 슬림하게 유지하고, 선택적 능력은 대개 플러그인으로 출시되어야 한다는 것입니다. 플러그인이 코어로 넘어오는 통로는 openclaw/plugin-sdk/*, 매니페스트 메타데이터, 주입된 런타임 헬퍼, 문서화된 배럴(api.ts, runtime-api.ts)로 엄격하게 제한됩니다. 플러그인은 두 가지 스타일로 나뉩니다.

Code 플러그인: OpenClaw 플러그인 코드를 직접 실행하며, 런타임 훅·프로바이더·채널·도구 같은 깊은 확장에 적합합니다.
Bundle 스타일 플러그인: skills, MCP 서버, 관련 설정 같은 안정적인 외부 표면을 패키징합니다. 인터페이스가 작고 안정적이며 보안 경계가 더 낫기 때문에 가능하면 이쪽이 권장됩니다.

플러그인과 스킬의 발견·검증은 ClawHub라는 별도 레지스트리에서 이뤄집니다. VISION 문서는 새 스킬을 코어에 기본 추가하지 말고 ClawHub를 통해 먼저 출시하라고 명시합니다. 코어에 무언가를 추가하는 기준선을 의도적으로 높게 잡는 것입니다.

이 철학은 "우리가 (당분간) 머지하지 않을 것"이라는 가드레일 목록에서 더 선명해집니다. 그 목록에는 매니저 위의 매니저, 중첩 플래너 트리 같은 에이전트 계층 프레임워크(agent-hierarchy frameworks)를 기본 아키텍처로 삼는 것, 그리고 기존 에이전트·도구 인프라를 중복시키는 무거운 오케스트레이션 계층이 포함됩니다. 복잡한 계층 구조보다 단일한 정규 경로(one canonical path)를 선호한다는 신호입니다.

상태 저장의 규율: "SQLite만, 파일 사이드카 금지"

AGENTS.md에서 인상적인 부분은 상태(state) 저장에 대한 거의 강박에 가까운 규율입니다. 핵심 규칙은 한 문장으로 요약됩니다. OpenClaw가 소유한 런타임 상태·캐시·큐·레지스트리·인덱스·커서·체크포인트는 전부 SQLite에만 저장하고, JSON/JSONL/TXT 같은 사이드카 파일을 만들지 말라는 것입니다.

이 규칙에는 명확한 운영 철학이 깔려 있습니다. 런타임은 오직 현재의 정규(canonical) 설정·데이터 형태만 읽습니다. 낡거나 잘못된 설정 키를 조용히 받아 주는 호환 분기(compat branch)를 두지 않습니다. 대신 설정 변경으로 기존 파일이 무효가 되면, 같은 변경에 openclaw doctor --fix 마이그레이션을 함께 추가해야 합니다. doctor가 옛 형태를 감지하고, 설명하고, 필요하면 백업한 뒤 정규 형태로 다시 써 줍니다.

이 접근의 장점은 코드가 마른다는 것입니다. AGENTS.md의 표현을 빌리면, 폴백(fallback)은 구현 편의가 아니라 제품 결정이어야 합니다. 폴백을 추가하기 전에 그것이 보장하는 출시된 계약(shipped contract), 실패 모드, 제거 계획, 그리고 왜 doctor로 해결할 수 없는지를 먼저 밝혀야 합니다. 그렇지 못하면 지우라는 것입니다. 대형 프로젝트가 흔히 빠지는 "혹시 몰라서 남겨 둔 호환 코드"의 누적을 정면으로 거부하는 설계입니다.

메모리: 디스크에 적는 기억, 그리고 "꿈꾸는" 통합

OpenClaw의 가장 차별적인 서브시스템을 하나만 꼽으라면 단연 메모리입니다. 다른 채널·도구 기능이 "지금 무엇을 하느냐"를 다룬다면, 메모리는 "어제 무엇을 배웠고 그것을 어떻게 오늘로 잇느냐"를 다룹니다. 그리고 OpenClaw의 메모리 설계 원칙은 놀라울 만큼 투명합니다. 메모리 문서의 첫 문장이 이를 못 박습니다.

The model only "remembers" what gets saved to disk — there is no hidden state.

즉 모델은 디스크에 저장된 것만 기억하며, 숨겨진 상태(hidden state)는 없습니다. 모든 기억은 사람이 읽을 수 있는 평문 마크다운 파일로 워크스페이스에 남습니다. 이 "검사 가능한 기억"은 블랙박스 벡터 메모리와 대비되는 OpenClaw의 분명한 입장입니다.

세 층위의 기억 파일

기본 메모리는 세 종류의 파일로 구성됩니다.

MEMORY.md — 장기 기억. 변하지 않는 사실·선호·결정 같은 정수만 담는 압축·큐레이션 계층입니다. 모든 DM 세션 시작 시 프롬프트에 주입됩니다. 원문 그대로의 전사(transcript)나 일일 로그를 담는 곳이 아닙니다.
memory/YYYY-MM-DD.md — 일일 노트. 상세한 관찰·세션 요약·나중에 쓸지 모를 맥락을 담는 작업 계층입니다. 오늘과 어제 노트는 자동 로드되고, 이 파일들은 memory_search·memory_get으로 색인되지만 매 턴 부트스트랩 프롬프트에 주입되지는 않습니다.
DREAMS.md — (선택) 뒤에서 설명할 "dreaming" 통합 작업의 사람이 검토하는 요약 일지입니다.

핵심은 계층 간 흐름입니다. 에이전트는 시간이 지나며 일일 노트에서 쓸모 있는 재료를 MEMORY.md로 증류(distill)하고 낡은 장기 항목을 제거합니다. MEMORY.md가 부트스트랩 예산을 넘으면 디스크의 원본은 그대로 두되 모델에 주입되는 사본을 잘라 냅니다. /context list·openclaw doctor로 원본 대 주입본 크기와 절단 여부를 볼 수 있습니다.

또 하나 섬세한 개념이 행동 민감 기억(action-sensitive memory)입니다. 어떤 기억은 단순한 사실이 아니라 "앞으로 무엇을 해도 되는가"에 영향을 줍니다. 예컨대 다른 세션에서 설계 중인 API 마이그레이션이 있다면, "이 스레드에서는 API 구현을 수정하지 말고 설계 입력으로만 쓰라"처럼 언제 행동해도 안전한지의 경계까지 기록하게 합니다. 다만 문서는 분명히 선을 긋습니다. 메모리는 승인 맥락을 보존할 뿐 정책을 강제하지 않으며, 하드 통제는 승인 설정·샌드박스·예약 작업으로 해야 합니다.

Dreaming: 잠자며 기억을 정리하는 백그라운드 통합

OpenClaw 메모리에서 가장 인상적인 기능은 memory-core의 dreaming입니다. 이름 그대로 사람이 자는 동안 기억을 정리하는 과정을 모사한 백그라운드 통합 시스템으로, 단기 신호를 장기 기억으로 옮기되 그 과정을 설명 가능하고 검토 가능하게 유지합니다. 기본은 opt-in(꺼져 있음)입니다.

dreaming은 세 개의 협력 단계로 작동합니다. 이 단계 구분이 dreaming을 단순 요약이 아니라 "규율 있는 승격 절차"로 만듭니다.

단계	목적	장기 기록(`MEMORY.md`)
Light	최근 단기 자료를 정렬·스테이징하고 중복 제거	안 함
Deep	가중 점수로 후보를 평가해 장기로 승격	함
REM	주제와 반복되는 아이디어를 성찰	안 함

Light 단계는 최근 일일 메모리와 회상 흔적(recall trace)을 읽어 후보 줄을 스테이징하고 강화 신호(reinforcement signal)를 기록합니다. Deep 단계가 실제로 무엇을 장기 기억으로 만들지 결정하는데, minScore·minRecallCount·minUniqueQueries 같은 임계 게이트를 모두 통과해야 하며, 승격 직전 살아 있는 일일 파일에서 스니펫을 재수화(rehydrate)해 이미 삭제된 stale 항목은 건너뜁니다. REM 단계는 어디에도 직접 쓰지 않고 반복 주제를 성찰합니다. 사람이 자며 단기 기억을 장기로 굳히는 수면 단계를 메모리 파이프라인으로 옮겨 온, 비유 이상으로 정교한 설계입니다.

Active memory: 답하기 전에 먼저 기억을 떠올린다

대부분의 메모리 시스템은 유능하지만 수동적(reactive)입니다. 메인 에이전트가 "지금 메모리를 검색해야겠다"고 판단하거나, 사용자가 "이거 기억해"라고 말해야 작동합니다. 그때쯤이면 기억이 답변을 자연스럽게 만들어 줄 순간은 이미 지나가 버립니다. OpenClaw의 active memory는 이 문제를 정조준합니다. 메인 답변이 생성되기 전에 실행되는, 플러그인이 소유한 블로킹 메모리 서브에이전트입니다.

즉 active memory는 적격한 대화 세션에 대해 "관련 기억을 먼저 떠올릴 한 번의 제한된 기회(one bounded chance)"를 시스템에 줍니다. 설정도 안전한 기본값으로 제공되는데, main 에이전트의 직접 메시지(direct) 세션에만 적용하고, 세션 모델을 상속하되 폴백 모델을 지정하며, 타임아웃과 요약 길이 상한을 둡니다.

{
  plugins: {
    entries: {
      "active-memory": {
        enabled: true,
        config: {
          agents: ["main"],
          allowedChatTypes: ["direct"],
          modelFallback: "google/gemini-3-flash",
          queryMode: "recent",
          timeoutMs: 15000,
          maxSummaryChars: 220,
        },
      },
    },
  },
}

Commitments: 대화가 만든 약속을 잊지 않기

세 번째 차별적 기능은 commitments(약속)입니다. 정확한 알림(reminder)도, 영구적 사실도 아닌, 짧은 수명의 후속 기억입니다. 대화가 미래의 체크인 기회를 만들었음을 알아채고 나중에 다시 꺼냅니다. 문서의 예시가 직관적입니다. 내일 면접이 있다고 말하면 끝난 뒤 안부를 묻고, 지쳤다고 하면 나중에 잘 잤는지 묻습니다. commitments는 기억과 자동화 사이에 위치합니다. OpenClaw가 대화에 묶인 의무를 기억해 두면, 하트비트(heartbeat)가 때가 됐을 때 그것을 전달합니다. 하루 최대 개수(maxPerDay)로 빈도를 조절합니다.

교체 가능한 메모리 백엔드

VISION 문서가 밝히듯 메모리는 "한 번에 하나의 메모리 플러그인만 활성화되는 특별한 플러그인 슬롯"입니다. OpenClaw는 기본(built-in) 외에도 Honcho(변증법적 사용자 모델링), 위키 방식, LanceDB(벡터), QMD 등 여러 메모리 옵션을 함께 제공하며, 시간이 지나면 하나의 권장 기본값으로 수렴할 계획이라고 밝힙니다. 지금까지 본 MEMORY.md·dreaming·active memory·commitments는 모두 기본 memory-core가 제공하는 능력이고, 더 강한 의미 검색이 필요하면 벡터 백엔드로 교체할 수 있는 구조입니다.

보안 모델: 강력함과 위험 사이의 의도된 거래

OpenClaw 리뷰에서 가장 중요하게 다뤄야 할 주제가 보안입니다. 비서가 "진짜로 일을 한다"는 말은 곧 셸 명령을 실행하고, 파일을 읽고 쓰고, 스크립트를 돌린다는 뜻이기 때문입니다. README는 보안 모델을 솔직하게 기술합니다.

Default: tools run on the host for the main session, so the agent has full access when it is just you.

즉 기본값으로 main 세션의 도구는 호스트에서 직접 실행되며, 혼자 쓸 때는 에이전트가 전체 접근 권한을 갖습니다. 그룹·채널 안전을 위해서는 agents.defaults.sandbox.mode: "non-main"을 설정해 비-main 세션을 샌드박스 안에서 돌릴 수 있습니다. 기본 샌드박스 백엔드는 Docker이며, SSH와 OpenShell 백엔드도 제공됩니다. 전형적인 샌드박스 기본값은 bash·process·read·write·edit·세션 관련 도구는 허용하되 browser·canvas·nodes·cron·discord·gateway는 차단하는 식입니다.

VISION 문서는 이 설계를 "의도된 거래(deliberate tradeoff)"라고 부릅니다. 능력을 죽이지 않으면서 강력한 기본값을 제공하되, 위험한 경로는 명시적으로 만들고 운영자가 통제하게 한다는 것입니다.

문제는 이 "강력한 기본값"이 현실에서 어떻게 노출됐는가입니다. 2026년 상반기 다수의 보안 업체와 연구자들이 OpenClaw의 위험을 경고했습니다. 핵심 위협은 크게 세 갈래입니다.

첫째, 간접 프롬프트 인젝션(indirect prompt injection)입니다. 공격자는 이메일·메시지·링크된 콘텐츠 안에 명령을 심어 둡니다. 비서가 그 콘텐츠를 소비하는 순간 명령이 발동합니다. 연구자들은 Telegram·Discord의 링크 미리보기 기능이, 공격자가 통제하는 URL을 비서가 생성하도록 유도해 기밀 데이터를 빼내는 유출 경로로 악용될 수 있음을 보였습니다.

둘째, 호스트 장악(host compromise)입니다. 비서가 로컬에서 광범위한 권한으로 돌아간다면, 비서의 침해가 곧 호스트의 침해로 이어집니다. 셸 실행 권한을 가진 에이전트가 공격당하면 엔드포인트 전체가 위험해집니다.

셋째, 노출된 관리 인터페이스입니다. OpenClaw는 기본적으로 127.0.0.1/localhost 연결을 신뢰하고 인증 없이 전체 접근을 허용합니다. 그런데 Gateway가 잘못 설정된 리버스 프록시 뒤에 있으면, 외부 요청이 전부 127.0.0.1로 전달되어 시스템이 이를 로컬 트래픽으로 착각하고 전권을 넘겨주는 일이 벌어집니다. 실제로 인터넷에 무방비로 노출된 관리 인터페이스가 다수 발견됐습니다.

이 지점은 OpenClaw만의 결함이라기보다, "개인 AI 에이전트"라는 범주 전체가 안고 있는 근본적 긴장입니다. 비서가 유용하려면 권한이 필요하고, 권한이 크면 공격 표면도 커집니다. OpenClaw의 보안 문서가 노출 전 반드시 읽어야 할 런북(exposure runbook)과 샌드박스 가이드를 강조하는 이유가 여기 있습니다. 이 도구를 쓰려는 사람이라면, 기본값이 "혼자 쓰는 신뢰 환경"을 전제한다는 점을 반드시 이해하고, 외부 노출 전에 샌드박스와 네트워크 정책을 손봐야 합니다.

실전 가이드: 설치와 최소 설정

OpenClaw는 터미널 우선(terminal-first) 설계를 의도적으로 유지합니다. VISION 문서는 그 이유를 "사용자가 문서·인증·권한·보안 태세를 처음부터 직접 보게 하기 위해서"라고 설명합니다. 편의 래퍼로 중요한 보안 결정을 숨기지 않겠다는 것입니다.

권장 설치 경로는 글로벌 설치 후 온보딩입니다. 저장소가 제시하는 흐름은 다음과 같습니다.

# 글로벌 설치 (npm / pnpm / bun 모두 가능)
npm install -g openclaw@latest

# 단계별 설정 마법사
openclaw onboard

openclaw onboard는 게이트웨이, 워크스페이스, 채널, 스킬 설정을 단계별로 안내하며 macOS·Linux·Windows에서 모두 동작합니다. 소스에서 개발하려면 pnpm 워크스페이스로 클론해 dev 루프를 돌립니다.

git clone https://github.com/openclaw/openclaw.git
cd openclaw
pnpm install
pnpm openclaw setup          # 최초 1회 로컬 설정/워크스페이스 작성
pnpm gateway:watch           # 소스/설정 변경 시 자동 리로드 dev 루프

설정은 ~/.openclaw/openclaw.json 한 파일에서 시작합니다. 모델만 지정하는 최소 설정은 다음과 같이 간결합니다.

{
  agent: {
    model: "<provider>/<model-id>",
  },
}

워크스페이스 루트는 ~/.openclaw/workspace이며, 여기에 AGENTS.md·SOUL.md·TOOLS.md 같은 프롬프트 파일이 주입됩니다. 스킬은 ~/.openclaw/workspace/skills/<skill>/SKILL.md 형태로 놓입니다. 운영자는 채팅 명령으로 비서를 제어하는데, /status·/new·/reset·/compact·/think <level>·/verbose on|off 같은 명령이 채널 안에서 그대로 동작합니다.

OpenClaw의 현재 위치: 바통은 넘어갔는가

흥미롭게도 OpenClaw의 이야기는 그 자체로 끝나지 않습니다. 창시자가 OpenAI로 떠난 뒤, 외부 분석들은 OpenClaw가 조용히 유지보수 모드(maintenance mode)로 들어갔다고 평가합니다. 릴리스는 계속 나오고 YAML 설정 계층과 티어 라우팅 엔진은 안정적으로 유지되지만, 원 팀은 에이전트 수준의 새 기능 추가를 멈췄다는 것입니다.

그 빈자리를 파고든 것이 Nous Research의 Hermes Agent입니다. Hermes는 hermes claw migrate 명령으로 ~/.openclaw 디렉터리를 자동 감지해 설정·메모리·스킬·API 키를 그대로 가져오는 마이그레이션 경로를 제공합니다. 두 프로젝트는 같은 계보에서 갈라져 나온 경쟁자이자, 동시에 OpenClaw가 오케스트레이션과 멀티채널 라우팅을, Hermes가 반복 작업 루프 실행을 맡아 ACP(Agent Communication Protocol)로 협업하는 보완 관계로도 운영됩니다. 2026년 5월 기준 OpenRouter 글로벌 랭킹에서는 Hermes가 OpenClaw를 앞질러 1위에 올랐습니다.

정리하며

OpenClaw를 한 문장으로 요약하면, "당신의 채널 안에서, 당신의 규칙으로, 당신의 기기 위에서 실제로 일을 하는 개인 AI 비서"입니다. 기술적으로 이 프로젝트가 보여 준 것을 세 가지로 정리할 수 있습니다.

첫째, OpenClaw는 모델이 아니라 오케스트레이션에 베팅했습니다. 20여 종의 메신저 채널, 멀티 에이전트 라우팅, Canvas와 음성, 네이티브 컴패니언 앱을 단일 Gateway 통제 평면 아래로 묶었고, 그 접착제로 해킹 가능성이 높은 TypeScript를 택했습니다. 그리고 이 비서를 "상태 없는 봇"이 아니라 지속적 동반자로 만드는 것이 평문 마크다운 기반 메모리 스택입니다. 디스크에만 적는 검사 가능한 기억(MEMORY.md/일일 노트), 수면 단계를 모사해 단기를 장기로 승격하는 dreaming, 답하기 전에 먼저 기억을 떠올리는 active memory, 대화가 만든 약속을 추적하는 commitments가 그것입니다.

둘째, 그 거대한 표면을 다루기 위해 린 코어 + 플러그인 + SQLite 단일 상태 + doctor 마이그레이션이라는 일관된 규율을 세웠습니다. "혹시 몰라서 남기는 호환 코드"를 거부하고 단일 정규 경로를 고집하는 설계는, 빠르게 커지는 프로젝트가 부채에 짓눌리지 않게 하려는 의식적 선택입니다.

셋째, "진짜로 일을 하는" 비서의 본질적 위험을 보안 모델로 정직하게 노출했습니다. 호스트 전권이라는 강력한 기본값과, 그것이 현실에서 일으킨 프롬프트 인젝션·노출된 게이트웨이·자격증명 유출의 사례는, 개인 AI 에이전트를 도입하려는 누구에게나 "권한과 공격 표면은 같은 동전의 양면"이라는 교훈을 남깁니다.

창시자는 떠났고 바통은 넘어가는 중이지만, OpenClaw가 2026년 오픈소스 에이전트 생태계의 형태를 결정지은 분기점이었다는 사실은 변하지 않습니다. 우주 바닷가재가 GitHub을 뒤흔든 이 이야기는, 개인 AI 비서라는 범주가 실험실을 벗어나 실제 사용자의 메신저로 들어온 순간의 기록이기도 합니다.

참고: 본문의 설계·기능 서술은 openclaw/openclaw 저장소의 README, VISION.md, AGENTS.md를 직접 인용·요약했으며, 역사·채택·보안 관련 외부 맥락은 아래 출처를 참고했습니다.