에이전트 다섯개가 한 서버에 산다 — OpenClaw가 에이전트마다 격리된 워크스페이스를 한 화면에서 점검하는 방법

개인용 AI 어시스턴트를 한 대의 서버에 올려 두고 쓰다 보면 욕심이 생긴다. 가족 단톡방에 답하는 에이전트, 업무 슬랙에서 코드를 거드는 에이전트, 텔레그램으로 알림만 쏘는 에이전트 — 성격도 권한도 다른 여러 "에이전트"를 한 서버에서 같이 굴리고 싶어진다. OpenClaw(오픈소스 개인 AI 어시스턴트 게이트웨이)는 이걸 멀티 에이전트(multi-agent, 한 프로세스 안에서 서로 격리된 여러 AI 인격을 동시에 운영하는 구조)로 푼다. 그런데 에이전트가 늘어나는 순간 새 골칫거리가 따라온다. "지금 이 에이전트는 어떤 도구를 쓸 수 있더라? 페르소나 파일은 어디 있지? 어느 채널에 연결돼 있지?" 이걸 매번 설정 파일을 뒤져서 확인해야 한다면 에이전트 다섯개는 곧 관리 불능이 된다.

OpenClaw의 브라우저 관제 화면인 Control UI에는 이 문제를 정면으로 겨눈 Agents(에이전트) 메뉴가 있다. 에이전트 하나를 고르면 그 에이전트가 쓰는 도구·스킬·채널·예약 작업(cron)·정체성 파일·설정을 한 화면에서 점검하고 손볼 수 있다. 이 글은 "왜 이런 메뉴가 필요했나 → 정확히 어떤 문제를 푸나 → OpenClaw가 어떤 구조로 풀었나 → 그래서 무엇이 좋아지나"의 흐름으로, 한 게이트웨이에서 여러 격리된 에이전트를 운영하는 환경을 한 화면으로 통제한다는 발상을 풀어 본다. 근거는 OpenClaw 공식 문서의 멀티 에이전트 라우팅 문서와 Control UI 문서다.

배경 — "에이전트 하나"가 사실은 통째로 격리된 두뇌다

먼저 OpenClaw에서 에이전트(agent)가 무엇인지부터 좁혀야 한다. 보통 "AI 에이전트"라고 하면 막연히 "스스로 일하는 에이전트" 정도로 들리지만, OpenClaw 문서는 에이전트를 훨씬 구체적으로 정의한다. 에이전트 하나는 자기만의 워크스페이스·상태 디렉터리·세션 저장소를 가진, 완전히 격리된 하나의 두뇌다. 풀어 쓰면 이렇다.

• 워크스페이스(workspace) — 그 에이전트가 다루는 파일들과 페르소나 규칙이 담긴 디렉터리. 정체성 파일(SOUL.md·AGENTS.md·USER.md)과 로컬 노트가 여기 산다. 이 파일들이 "이 에이전트는 누구이고 어떻게 말하는가"를 정한다.
• 상태 디렉터리(agentDir) — 인증 프로필(auth profile, 어떤 모델·계정으로 로그인했는지 담은 자격증명), 모델 레지스트리, 에이전트별 설정이 들어가는 디스크 위치. 경로는 ~/.openclaw/agents/<agentId>/agent/ 형태다.
• 세션 저장소(session store) — 대화 기록과 라우팅 상태. ~/.openclaw/agents/<agentId>/sessions에 따로 쌓인다.

여기서 핵심은 인증 프로필이 에이전트별이라는 점이다. 각 에이전트는 자기 상태 디렉터리의 per-agent SQLite 저장소(openclaw-agent.sqlite)에 인증 프로필을 격리해 둔다. 즉 업무 에이전트가 회사 계정으로 로그인했어도 가족 에이전트는 그 토큰을 공유하지 않는다. 에이전트마다 별도의 전화번호·계정·인격·대화 기록을 갖고, 명시적으로 열어 주지 않는 한 서로 끼어들지 않는다(no cross-talk). 문서의 표현을 빌리면 이건 "여러 사람이 한 게이트웨이 서버를 공유하면서도 각자의 AI 두뇌와 데이터를 격리해서 쓰는" 그림이다.

다이어그램 설명. 이 그림은 게이트웨이 하나가 두 개의 에이전트를 떠받치되, 각 에이전트가 워크스페이스·상태 디렉터리·세션 저장소를 따로 갖는다는 걸 보여준다. 위에서 아래로 읽으면 "프로세스 하나 → 에이전트들 → 에이전트마다 세 갈래의 격리된 자산"으로 갈라진다. 이 구조의 핵심은 가운데 줄의 상태 디렉터리에 인증 프로필이 들어 있다는 점이다 — 가족용과 업무용이 같은 토큰을 공유하지 않는 이유가 여기 있다. 놓치기 쉬운 함정: 이 격리는 "디폴트 작업 디렉터리"일 뿐 강제 샌드박스가 아니다. 상대 경로는 워크스페이스 안에서 풀리지만, 절대 경로를 쓰면 샌드박스를 켜지 않은 한 다른 위치까지 닿을 수 있다. 진짜 차단을 원하면 별도로 샌드박스를 켜야 한다.

그래서 무슨 가치인가. 에이전트 하나가 "예쁜 챗봇 인스턴스"가 아니라 파일·자격증명·기억까지 통째로 분리된 독립 인격이라는 점이, 뒤에 나올 모든 점검 항목의 전제가 된다. 점검할 게 많은 이유가 바로 이 풍부한 격리에서 나온다.

핵심 문제 — 에이전트가 늘면 "이 에이전트가 지금 뭘 할 수 있는지"가 안 보인다

에이전트가 통째로 격리된 두뇌라는 건 강력하지만, 동시에 운영자가 추적해야 할 표면(surface)이 에이전트 수만큼 늘어난다는 뜻이다. 에이전트 하나를 안전하게 굴리려면 적어도 다음을 동시에 알고 있어야 한다.

• 이 에이전트에 허용된 도구(tool)는 무엇인가 — exec(셸 명령 실행)·write(파일 쓰기)·browser 같은 기능 권한. OpenClaw는 에이전트별로 tools.allow/tools.deny 목록을 둘 수 있다.
• 어떤 스킬(skill)이 로딩되는가 — 스킬은 절차·워크플로우를 담은 확장. 각 에이전트 워크스페이스 + 공유 루트(~/.openclaw/skills)에서 로딩된 뒤, 설정된 허용 목록(allowlist)으로 걸러진다.
• 어느 채널(channel)·계정에 연결돼 있는가 — 디스코드 에이전트 토큰, 텔레그램 에이전트, 왓츠앱 번호 등. 인바운드 메시지가 이 에이전트로 흘러오는 통로다.
• 이 에이전트로 도는 cron(예약 작업)은 무엇인가 — 정해진 시각에 자동 실행되는 작업.
• 코어 파일(정체성)은 어떻게 적혀 있는가 — 페르소나·말투·사용자 정보를 정의하는 SOUL.md·AGENTS.md·USER.md.

이걸 설정 파일과 디스크를 직접 뒤져서 확인한다고 상상해 보자. 도구 권한은 openclaw.json의 agents.list[].tools에 있고, 스킬 허용 목록은 또 다른 키에, 채널 바인딩(binding, 채널 계정을 어느 에이전트로 보낼지 정하는 라우팅 규칙)은 bindings 배열에, cron은 별도 영역에, 정체성 파일은 각 워크스페이스 디렉터리에 흩어져 있다. 에이전트가 다섯이면 다섯 개의 워크스페이스 디렉터리 × 다섯 갈래의 설정 키를 머릿속에서 교차해야 한다. 잘못 보면 사고가 난다 — 업무 에이전트에 막아 둔 줄 알았던 exec가 실은 열려 있어서, 그 에이전트가 연결된 슬랙에서 누군가 셸 명령을 흘려 넣는 식이다.

다이어그램 설명. 이 그림은 "이 에이전트가 지금 무엇을 할 수 있는가"라는 단순한 질문 하나에 답하려면 흩어진 다섯 곳을 모아 봐야 한다는 문제를 보여준다. 맨 위의 질문에서 다섯 갈래로 퍼졌다가 맨 아래에서 다시 하나로 모이는 모양이 핵심이다 — 정보가 한군데 모여 있지 않고 설정 파일의 여러 키와 디스크의 워크스페이스 디렉터리에 분산돼 있다. 이 패턴을 그린 이유는, 격리가 강할수록(에이전트마다 별도 파일·권한·채널) 운영자가 교차 조회해야 할 지점도 그만큼 늘어난다는 트레이드오프를 드러내기 위해서다. 놓치기 쉬운 함정: 다섯 갈래 중 권한 관련(허용 도구·연결 채널) 둘만 어긋나도 "신뢰하지 않는 채널이 위험한 도구에 닿는" 사고로 이어진다. 하나만 빠뜨려도 사고라는 게 아래쪽 모이는 노드의 메시지다.

그래서 무슨 가치가 걸려 있나. 멀티 에이전트의 격리는 안전을 위한 것인데, 그 안전을 운영자가 검증하지 못하면 격리는 장식이 된다. "이 에이전트가 무엇을 할 수 있는지를 한눈에 확인할 수 있어야 한다"는 게 Agents 메뉴가 풀어야 할 진짜 문제다.

해결 방법 — 에이전트를 1급 필터로 만들고, 흩어진 점검 항목을 모은다

OpenClaw Control UI의 해법은 두 갈래다. 첫째, 에이전트 선택을 화면 전반의 필터로 끌어올린다. 둘째, 도구·스킬·채널·cron·설정처럼 원래 따로 있던 점검 패널들을 한 운영 화면에 모으고, 선택한 에이전트 기준으로 좁혀 보여준다.

에이전트 필터 — 채팅도 세션도 선택한 에이전트로 좁힌다

Control UI의 채팅 헤더에는 세션 선택기보다 앞에 에이전트 필터가 놓인다. 즉 먼저 "어떤 에이전트를 볼지" 고르고, 그다음 그 에이전트에 묶인 세션만 추려서 본다. 에이전트를 바꾸면 그 에이전트에 연결된 세션만 나타나고, 저장된 세션이 아직 없으면 그 에이전트의 메인 세션으로 떨어진다. 세션 목록은 기본적으로 설정된 에이전트 기준으로 나열되고(sessions.list), 모델·thinking·verbose 같은 세션별 설정도 그 범위 안에서 덮어쓸 수 있다(sessions.patch).

다이어그램 설명. 이 그림은 채팅 화면에서 에이전트를 고르는 순간 그 아래 모든 선택지가 그 에이전트로 좁혀지는 흐름을 보여준다. 맨 위에서 에이전트를 고르면, 세션 선택기가 그 에이전트에 묶인 세션만 보여주고, 가운데 분기에서 저장된 세션 유무에 따라 목록을 보여줄지 메인 세션으로 떨어질지가 갈린 뒤, 마지막에 세션 단위로 모델 같은 설정을 덮어쓴다. 이 순서(에이전트 → 세션 → 설정)가 핵심인 이유는, 운영자가 실수로 다른 에이전트의 대화에 손대는 걸 구조적으로 막기 때문이다 — 에이전트를 먼저 고르지 않으면 세션이 보이지 않는다. 놓치기 쉬운 함정: 저장된 세션이 없을 때 빈 화면이 아니라 메인 세션으로 떨어진다는 점이다. "세션이 없네"가 아니라 "이 에이전트의 기본 대화 줄로 들어왔다"로 읽어야 한다.

도구·채널·cron·정체성을 한 운영 화면에 모은다

Control UI는 채팅 너머의 운영 항목들을 사이드바의 전용 패널로 묶어 둔다. 문서에 정리된 것을 점검 대상별로 옮기면 이렇다.

• 채널(Channels) — 내장 채널과 플러그인 채널의 상태, QR 로그인, 채널별 설정을 본다(channels.status·web.login.*·config.patch).
• 세션(Sessions) — 설정된 에이전트의 세션을 나열하고, 오래된 미설정 세션 키에서 안전하게 폴백하며, 세션별 모델·trace 등을 덮어쓴다.
• cron(예약 작업) — 작업을 나열·추가·편집·즉시 실행·켜고 끄고, 실행 이력까지 본다(cron.*). 격리 작업은 기본적으로 "요약 알림(announce summary)"으로 결과를 보내지만, 내부 전용으로만 돌리고 싶으면 알림을 끌 수도 있다. 알림을 켜면 채널·대상 입력 칸이 나타난다.
• 스킬(Skills) — 스킬 상태를 보고, 켜고 끄고, 설치하고, API 키를 갱신한다(skills.*).
• 실행 승인(Exec approvals) — 게이트웨이/노드의 허용 목록과 exec 묻기 정책을 편집한다(exec.approvals.*). 위험한 셸 실행을 어디까지 허용할지의 안전 게이트다.

그리고 정체성·권한·모델 같은 에이전트의 코어 설정은 Config(설정) 패널에서 ~/.openclaw/openclaw.json을 보고 고친다(config.get·config.set). 여기서 agents.list[] 아래의 워크스페이스 경로·도구 허용/거부·모델·샌드박스 모드 같은 에이전트별 설정이 모두 노출된다.

결과 — 격리는 유지하되 점검은 단일 창구로

Agents 메뉴가 만들어 낸 변화를 한 문장으로 줄이면 이렇다. 에이전트마다의 강한 격리는 그대로 두면서, 그 격리를 검증하고 운영하는 일만 한 창구로 모았다. 격리(에이전트별 워크스페이스·인증·세션)는 안전을 위한 설계이고, 단일 점검 창구는 그 안전을 운영자가 실제로 확인 가능하게 만드는 장치다. 둘은 상충하지 않고 보완한다.

구체적으로 달라지는 장면을 두 경우로 나눠 보면 차이가 또렷하다.

▲ Agents 메뉴가 없을 때 — 설정 파일·디스크를 직접 교차 조회

다이어그램 설명. 이 위쪽 흐름은 메뉴가 없을 때 운영자가 에이전트 하나의 권한을 확인하려고 거치는 직렬 경로를 보여준다. 설정 파일을 열어 도구 권한을 찾고, 다른 키들에서 스킬·채널·cron을 각각 찾고, 워크스페이스 디렉터리에서 정체성 파일을 연 다음, 그 다섯 조각을 머릿속에서 합쳐야 답이 나온다. 이 경로의 문제는 단계마다 사람이 위치를 기억해야 하고, 한 단계만 빠뜨려도 "막아 둔 줄 알았는데 열려 있던" 권한 사고로 직결된다는 점이다.

▲ Agents 메뉴가 있을 때 — 에이전트 하나로 좁힌 단일 관제 화면

다이어그램 설명. 이 아래쪽 흐름은 같은 작업을 Agents 메뉴로 했을 때의 경로다. 맨 위에서 에이전트를 한 번 고르면, 그 선택이 도구·스킬·cron 패널로 전파돼 그 에이전트 기준으로 좁혀지고, 설정 패널에서 도구 권한·모델·샌드박스 모드를 확인한 뒤, 한 화면 안에서 권한·연결·정체성이 모두 점검된다. 위쪽 흐름과 비교하면 "사람이 위치를 기억하는 일"이 "에이전트를 한 번 고르는 일"로 바뀌었다는 게 핵심 차이다 — 교차 조회의 부담을 사람에서 화면으로 옮긴 것이다. 두 다이어그램을 위아래로 견주면, 단계 수가 줄었다기보다 각 단계가 자동으로 같은 에이전트로 묶인다는 점이 달라졌음을 알 수 있다.

그래서 결국 사용자·에이전트·시스템 각각에 무엇이 좋아졌나. 사용자(운영자)는 에이전트가 다섯이든 열이든 "에이전트 하나 고르고 패널 훑기"라는 동일한 동작으로 전체를 점검한다 — 설정 파일의 키 지도를 외울 필요가 없다. 에이전트는 워크스페이스·인증·세션의 격리를 그대로 유지하므로 서로의 데이터·자격증명을 침범하지 않는다. 시스템은 격리(안전 설계)와 가시성(운영 검증)을 동시에 만족시켜, 한 게이트웨이로 여러 사람·여러 인격을 안전하게 떠받칠 수 있게 된다. 격리가 강할수록 점검 표면이 넓어진다는 멀티 에이전트의 근본 트레이드오프를, "에이전트를 1급 필터로 만든 단일 관제 화면"으로 길들인 셈이다.

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.