OpenClaw 공식 문서를 읽다 보면 이 프로젝트의 깊이는 단순 채널 연결보다 agent 운영 구조에서 더 뚜렷하게 드러납니다.
특히 중요한 축을 꼽으면
이 세 가지가 빠지지 않습니다.
이 문서에서는
를 차근차근 정리해보겠습니다.
---
공식 multi-agent 문서를 보면 agent는 단순 설정 하나가 아닙니다.
하나의 agent는 자기만의
를 갖는 분리된 brain에 가깝습니다.
그래서 multi-agent도 별명 여러 개를 붙이는 기능이라기보다, 기억, 설정, 세션, 성격이 나뉜 assistant 여러 명을 한 Gateway에서 함께 운영하는 구조로 이해하는 편이 더 정확합니다.
---
공식 agent-workspace 문서에서 workspace는 agent의 home으로 설명됩니다.
실제로 하는 역할을 보면
그래서 workspace는 단순 폴더가 아니라, OpenClaw assistant의 정체성이 축적되는 장소에 가깝습니다.
---
공식 문서 기준 핵심 파일은 아래와 같습니다.
이 구조를 보면 OpenClaw는 assistant의 문맥을 세션 기록 안에만 두지 않습니다. 오히려 파일 기반 운영 체계로 끌어올린다는 느낌이 강합니다.
이 점이 꽤 중요합니다. “대화를 얼마나 오래 이어가느냐”보다 “어떤 파일 구조로 기억을 관리하느냐”가 assistant 품질에 직접 연결되기 때문입니다.
---
공식 memory 문서에서 가장 핵심적인 문장은 이겁니다.
> OpenClaw memory is plain Markdown in the agent workspace.
이 한 줄이 의미하는 건 꽤 분명합니다. 기억의 source of truth가 모델 내부 어딘가에 있는 게 아니라, workspace 안의 파일이라는 뜻입니다.
그래서 OpenClaw에서 memory는 “잘 기억해줘”에 가까운 추상적 개념이 아니라, 실제로 기록되고 읽히고 검색되는 운영 데이터에 더 가깝습니다.
이 구조 덕분에 기억이 세션 안쪽에 갇히지 않고, assistant 운영의 일부가 됩니다.
---
공식 문서 기준 OpenClaw 메모리는 크게 두 층입니다.
이렇게 보면 OpenClaw는 short-term running context와 long-term curated context를 분리해서 다루는 편입니다.
---
많은 assistant 시스템은 세션이 길어질수록 기억 구조가 흐려집니다.
OpenClaw는 공식 문서 차원에서부터
를 같이 엮어두고 있습니다.
그래서 기억을 “모델이 알아서 잘 간직하겠지”에 맡기지 않고, 기록하고, 정리하고, 다시 검색하는 흐름으로 바꿔놓습니다. 운영 관점에서는 이 차이가 생각보다 큽니다.
---
공식 memory 문서에는 pre-compaction memory flush가 나옵니다.
세션이 compact되기 전에
이건 꽤 현실적인 설계입니다. assistant를 오래 굴릴수록 문제는 “한때 좋았던 문맥이 사라지는 것”인데, OpenClaw는 그 지점을 시스템 차원에서 미리 의식하고 있기 때문입니다.
---
공식 문서를 보면 multi-agent는 각 agent가 완전히 분리된 workspace와 state를 가지는 구조입니다.
그래서 이런 경우에 특히 유용합니다.
핵심은 하나의 assistant를 계속 비대하게 키우는 게 아니라, 역할과 기억을 나눠 충돌을 줄이는 것에 있습니다.
---
문서에 나온 설명을 정리해보면 각 agent는 자기만의
를 가질 수 있습니다.
그래서 multi-agent는 단지 “모델 여러 개를 쓴다”는 뜻이 아닙니다. 오히려 세계관과 기억이 다른 독립 assistant 여러 개를 운영하는 방식에 더 가깝습니다.
이 시각으로 봐야 OpenClaw의 multi-agent가 왜 단순 멀티 프로필보다 훨씬 깊은 개념인지 이해가 됩니다.
---
OpenClaw는 binding을 통해 inbound를 특정 agent에 라우팅합니다.
문서상 기준 예를 보면
같은 항목이 나옵니다.
결국 어떤 메시지가 어느 brain으로 가야 하는지를 deterministic하게 정한다는 뜻입니다. 특히 multi-user, multi-channel 환경에서는 이 라우팅 규칙이 품질과 안전성에 직접 영향을 줍니다.
---
공식 agent-workspace 문서에는 중요한 경고도 있습니다.
workspace는 기본 cwd이긴 하지만 hard sandbox는 아닙니다.
이 말은
는 뜻입니다.
그래서 workspace를 기억과 운영의 집으로 보되, 보안 경계까지 자동으로 해결해주는 건 아니라는 점을 같이 봐야 합니다.
---
- main
- research
- ops
처음부터 agent를 여러 개 만드는 것보다, 하나를 먼저 잘 운영한 뒤 분리하는 편이 훨씬 기준이 명확해집니다.
---
OpenClaw를 단순 설치법으로만 다루면 차별점이 생각보다 약하게 보일 수 있습니다.
하지만 multi-agent, workspace, memory로 들어가면 결이 확 달라집니다.
좋은 프레이밍은 대체로 이런 쪽입니다.
이런 관점은 콘텐츠로 옮겨도 훨씬 깊이 있고, 단테랩스 톤과도 잘 맞습니다.
---
OpenClaw의 multi-agent, workspace, memory 구조는 assistant를 일회성 대화 도구가 아니라 지속적으로 운영되는 존재로 다루게 해주는 핵심 설계입니다.
그래서 OpenClaw를 제대로 이해하려면 채널만 볼 게 아니라, workspace, memory, routing, isolation까지 함께 봐야 전체 그림이 보입니다.
---