OpenClaw 멀티 에이전트 라우팅 설정 방법: 업무·개인·실험 환경 분리

월요일 오전 9시, 고객의 결제 API 코드를 작성하려고 AI 어시스턴트를 열었습니다. 그런데 갑자기 이렇게 말했습니다. “어젯밤에 찾아본 《Elden Ring》 보스 공략을 보면 여기에도 ‘구르기 전법’을 적용하는 게 좋겠습니다…”

순간 얼어붙었습니다.

더 난감했던 점은 고객과 화면을 공유하는 회의 중이었다는 것입니다. 화면 너머로 흐르는 어색한 침묵이 그대로 느껴졌습니다.

그때 깨달았습니다. AI 어시스턴트는 점점 똑똑해지지만 제 업무, 여가, 실험을 모두 한데 섞어 놓고 있었습니다. 정리함이 없는 서랍처럼 모든 것이 뒤엉켜 있어 필요한 것을 찾는 데 한참 걸리고, 엉뚱한 것을 꺼내기 일쑤였습니다.

비슷한 경험이 있다면 이 글이 도움이 될 것입니다. 주말 내내 OpenClaw의 멀티 에이전트 라우팅 기능을 살펴본 결과, AI 어시스턴트를 여러 전담 도우미로 나눌 수 있다는 것을 알았습니다. 업무는 업무용에게, 개인 생활은 개인용에게 맡기고 실험은 샌드박스 안에 가둘 수 있습니다.

이제 이 기능이 필요한 이유, 설정 방법, 제가 실제로 사용하는 5가지 환경 구성을 소개하겠습니다.

저렴하게 ‘AI 새우’를 키우는 방법: ArkClaw로 AI Agent 진입 장벽 낮추기

최근 인기를 얻은 OpenClaw(랍스터)는 유용하지만 설정이 너무 복잡한가요? ByteDance Volcano Engine의 ArkClaw는 진입 장벽을 크게 낮췄습니다. 서버나 Token 설정을 직접 다루지 않아도 클릭 한 번으로 24시간 온라인 상태를 유지하며 브라우저를 제어하고, 스크립트를 실행하고, 캘린더를 관리하는 ‘AI 일꾼’을 만들 수 있습니다.

특히 가격이 저렴합니다. 월 요금은 9.9위안이며, 제 초대 코드 ZLKUK54M을 사용해 여기에서 가입하면 8.9위안입니다. 프로그래머라면 Coding Plan Pro에 가입해 무료로 사용할 수도 있습니다.

AI 어시스턴트의 컨텍스트가 뒤섞이는 이유

하나의 어시스턴트 때문에 난감해지는 세 가지 순간

솔직히 말해, 저는 다음 일을 겪기 전까지 AI 어시스턴트 하나로 모든 작업을 처리했습니다.

상황 1: 컨텍스트 오염
회사 데이터베이스 쿼리를 최적화해 달라고 했는데 AI가 갑자기 “지난주에 질문한 Python 크롤러 스크립트처럼 비동기 처리를 적용할 수 있습니다…”라고 말합니다. 하지만 그 크롤러는 회사에 알리고 싶지 않은 개인 부업 프로젝트였습니다.

상황 2: 개인정보 노출
팀에 새 도구를 시연하면서 특정 기능을 보여 주려고 AI 대화 기록을 열었는데 목록에 ‘상사에게 연봉 인상을 요청하는 방법’, ‘부업 소득을 신고해야 하는지’ 같은 사적인 질문이 가득합니다. 얼마나 민망한지는 겪어 본 사람이라면 알 것입니다.

상황 3: 실험이 운영 환경을 망침
자동화 스크립트를 테스트하면서 AI에게 파일 이름을 일괄 변경해 달라고 한 적이 있습니다. 그런데 AI가 이전 업무 프로젝트 디렉터리를 기억하고 고객 프로젝트의 소스 파일 이름을 전부 바꿔 버렸습니다. Git이 없었다면 정말 큰일이 날 뻔했습니다.

왜 이런 일이 생길까요?

AI 어시스턴트 자체가 잘못한 것은 아닙니다. 단지 지나치게 ‘충실’해서 사용자가 말한 모든 내용을 기억하고 전체 컨텍스트를 연결하려고 할 뿐입니다. 문제는 다음 세 환경의 요구가 서로 다르다는 점입니다.

• 업무에는 엄격함과 개인정보 보호가 필요합니다.
• 개인 생활에는 편안하고 개인화된 조언이 필요합니다.
• 실험은 자유롭게 진행하되 운영 환경에 영향을 주면 안 됩니다.

애초에 이 세 가지를 한데 섞을 이유가 없습니다.

멀티 에이전트 라우팅이 해결하는 방식

OpenClaw의 멀티 에이전트 라우팅은 본질적으로 각 환경에 별도의 ‘방’을 마련하는 기능입니다.

• 독립 작업 공간: work-agent는 /work 디렉터리만 보고 personal-agent는 /personal 디렉터리에만 접근합니다. 파일 시스템 수준에서 물리적으로 격리됩니다.
• 독립 대화 기록: work-agent에서 나눈 대화는 personal-agent가 전혀 알지 못하며 그 반대도 마찬가지입니다.
• 독립 권한 설정: 실험 샌드박스는 네트워크를 차단하고 파일 시스템을 읽기 전용으로 설정할 수 있습니다. 업무 환경에는 회사 Git 접근 권한을, 개인 환경에는 개인 클라우드 드라이브 접근 권한을 부여할 수 있습니다.

Docker 용어로는 ‘컨테이너 수준 격리’입니다. 쉽게 말하면 AI 어시스턴트에 서로 간섭하지 않는 여러 개의 독립된 두뇌를 만들어 주는 것입니다.

2026년 AI 보안 표준은 엔터프라이즈 시스템에 엄격한 tenant 수준 데이터 격리를 요구합니다. OpenClaw가 사용하는 Docker 샌드박스 방식은 단순히 대화를 그룹으로 나누는 도구보다 훨씬 안전합니다.

KiloClaw - 기업용 매니지드 OpenClaw, AI Agent 오케스트레이션 및 스마트 라우팅

시작하기 →광고

OpenClaw의 3계층 격리 아키텍처

OpenClaw 문서를 처음 읽었을 때 Gateway, Brain, Skills 같은 용어가 너무 많아 혼란스러웠습니다. 직접 한 번 설정하고 나니 이해하기 어렵지 않았습니다.

택배 시스템으로 이해하는 3계층 아키텍처

• Gateway 계층(접수·발송 지점): Telegram, Discord, Slack 등 여러 플랫폼에서 보낸 메시지를 먼저 받은 뒤 설정에 따라 적절한 agent로 전달합니다.
• Brain 계층(조정 센터): 메시지를 받은 뒤 코드 작성, 정보 검색, 명령 실행 중 사용자가 원하는 작업을 판단하고 작업 흐름을 구성합니다.
• Skills 계층(실행 창고): 실제 작업이 이루어지는 곳입니다. 각 agent는 독립된 Docker 컨테이너에서 코드 실행과 파일 작업을 수행합니다.

선택할 수 있는 세 가지 격리 수준

이 구조는 필요에 따라 다음 세 가지 수준에서 선택할 수 있습니다.

Session 수준 격리(임시 작업)
대화할 때마다 새 컨테이너를 열고 대화가 끝나면 삭제합니다. ‘이 CSV 파일을 분석해 줘’ 같은 일회성 작업에 적합합니다. 환경이 깨끗하다는 장점이 있지만 다음 대화에서는 다시 환경을 만들어야 합니다.

Agent 수준 격리(장기 환경)
agent마다 장기간 실행되는 컨테이너 하나를 둡니다. 제가 사용하는 work-agent와 personal-agent가 이 방식입니다. 환경을 한 번 설정해 두면 계속 유지되어 언제든 호출할 수 있습니다. 제가 가장 자주 쓰는 방식이기도 합니다.

OS 사용자 수준 격리(보안 우선)
agent마다 서로 다른 시스템 사용자로 실행해 운영체제 수준에서 격리합니다. 솔직히 저는 이렇게 엄격한 수준까지 사용하지 않지만 금융이나 의료처럼 매우 민감한 데이터를 처리한다면 더 안전한 선택입니다.

직접 테스트한 결과 Agent 수준 격리에서는 agent-A가 만든 파일에 agent-B가 어떤 방법으로도 접근할 수 없었습니다. 공유 디렉터리를 명시적으로 설정한 경우만 예외입니다. 덕분에 안심하고 사용할 수 있었습니다.

제가 사용하는 5가지 실제 환경

제가 실제로 설정해 사용 중인 구성을 공유하니 그대로 참고해도 좋습니다.

상황 1: 업무와 개인 환경 분리

문제: 회사 프로젝트와 개인 블로그 코드가 자꾸 섞였습니다. commit할 때 회사 코드를 개인 GitHub에 push할 뻔한 적도 있습니다.

해결 방법:

• work-agent: 작업 디렉터리를 D:\work로 지정하고 회사 GitLab SSH 키를 설정하며 업무 관련 API 키에만 접근하게 합니다.
• personal-agent: 작업 디렉터리를 D:\personal로 지정하고 개인 GitHub 계정을 설정해 자유롭게 실험합니다.

설정 핵심:
두 agent는 서로 다른 .env 파일을 사용하며 WORKSPACE_PATH가 각각 별도 디렉터리를 가리킵니다. Telegram에서는 @my_work_bot과 @my_personal_bot이라는 bot 두 개를 만들어 현재 어떤 어시스턴트와 대화 중인지 한눈에 구분합니다.

상황 2: 여러 고객 프로젝트 격리

문제: 프리랜서로 고객 세 곳의 프로젝트를 동시에 진행할 때 AI가 고객 A에게 제안한 코드에 고객 B 프로젝트의 변수 이름 규칙을 사용한 적이 있습니다. 실제 문제로 이어지지는 않았지만 불안했습니다.

해결 방법:
client-nike-agent, client-adidas-agent, client-puma-agent라는 agent 세 개를 사용합니다(가명입니다).

설정 핵심:

• 각 agent를 별도의 프로젝트 디렉터리와 Git 저장소에 연결합니다.
• 로그를 추적하기 쉽도록 .env마다 서로 다른 PROJECT_NAME을 설정합니다.
• 가장 중요한 점은 고객별 API 키와 데이터베이스 설정을 완전히 격리해 절대 교차하지 않는 것입니다.

상황 3: 안전한 실험 샌드박스

문제: 파일을 일괄 처리하는 스크립트를 테스트하고 싶지만 로직 오류로 중요한 파일이 삭제될까 걱정됐습니다.

해결 방법:
sandbox-agent를 만들고 엄격한 샌드박스 모드를 켭니다.

설정 핵심:

ENABLE_NETWORK=false  # 네트워크 차단
HOST_FILESYSTEM_MODE=readonly  # 호스트 파일 시스템 읽기 전용
TEMP_STORAGE=true  # 모든 변경 사항은 임시 디렉터리에 저장되며 컨테이너를 다시 시작하면 삭제됨

이렇게 하면 마음껏 실험할 수 있습니다. 문제가 생겨도 컨테이너를 삭제하고 다시 만들면 되며 호스트 환경에는 전혀 영향을 주지 않습니다. 이제 위험할 수 있어 보이는 작업은 항상 이곳에서 먼저 테스트합니다.

상황 4: 팀 협업과 개인 공간

문제: 팀이 AI 어시스턴트 하나를 함께 사용하니 개인 메모와 할 일까지 한데 섞여 개인정보가 보호되지 않는 느낌이 들었습니다.

해결 방법:

• team-agent: 팀이 공유하며 팀 코드 저장소와 문서를 설정해 모두가 접근할 수 있게 합니다.
• private-agent: 제 전용 공간으로 생각, 초안, 개인 할 일을 기록합니다.

설정 핵심:
team-agent의 작업 디렉터리는 팀 공용 NAS 경로로 지정하고 private-agent는 로컬 암호화 파티션으로 지정합니다. Telegram에서는 team-agent를 팀 그룹에 연결하고 private-agent는 저와의 개인 대화만 허용합니다.

상황 5: 여러 모델 비교 테스트

문제: Claude, GPT-4, 로컬 Llama의 결과를 비교하고 싶은데 설정을 계속 바꾸기 번거로웠습니다.

해결 방법:
claude-agent, gpt-agent, llama-agent 세 개를 병렬로 실행합니다.

Alibaba Cloud - 개발자 클라우드 1순위, Lighthouse 서버 15% 할인

15% 할인 받기 →광고

설정 핵심:
agent별 .env에 서로 다른 LLM_PROVIDER와 API_KEY를 설정합니다. 같은 질문을 세 agent에 각각 보낸 뒤 답변의 품질, 속도, 비용을 비교합니다.

흥미로운 점은 코드 생성에는 Claude가 가장 안정적이고, 일상 대화에는 GPT-4가 가장 자연스러우며, 로컬 Llama는 느리지만 개인정보 보호에 유리해 민감한 정보를 처리할 때 사용한다는 것입니다.

추가 실용 팁:

• 이름 규칙: 저는 환경-용도-날짜 형식을 사용합니다. 예를 들어 client-nike-backend-20260201로 이름을 정하면 몇 달 뒤 로그를 봐도 용도를 알 수 있습니다.
• 빠른 전환: 휴대전화에 여러 Telegram 계정을 설치하고 계정마다 다른 agent를 연결하면 밀어서 빠르게 전환할 수 있습니다.
• 리소스 최적화: llama-agent처럼 자주 쓰지 않는 agent에는 docker stop을 실행하고 필요할 때 다시 시작해 메모리를 절약합니다.

첫 work/personal agent 한 쌍 설정하기

이론은 충분히 살펴봤으니 이제 직접 설정해 보겠습니다. Docker와 OpenClaw 기본 환경이 이미 설치되어 있다고 가정합니다. 아직 설치하지 않았다면 공식 빠른 시작 문서를 먼저 확인하세요.

목표: work와 personal agent 두 개 설정

1단계: 설정 파일 준비

cd openclaw
cp .env .env.work
cp .env .env.personal

2단계: work-agent 설정 변경
.env.work를 열고 다음 핵심 매개변수를 변경합니다.

AGENT_NAME=work-agent
WORKSPACE_PATH=/path/to/your/work/directory
TELEGRAM_BOT_TOKEN=your_work_bot_token
ALLOWED_USERS=your_telegram_user_id

3단계: personal-agent 설정 변경
.env.personal을 열고 같은 방식으로 수정합니다.

AGENT_NAME=personal-agent
WORKSPACE_PATH=/path/to/your/personal/directory
TELEGRAM_BOT_TOKEN=your_personal_bot_token
CONTAINER_PORT=8001  # 포트 충돌을 방지하도록 변경

4단계: agent 두 개 시작

docker-compose --env-file .env.work up -d
docker-compose --env-file .env.personal up -d

몇 초 뒤 Status: Running이 표시되면 성공입니다.

격리 효과를 확인하는 세 가지 테스트

테스트 1: 파일 격리

• work-agent에 “test.txt 파일을 만들고 ‘work data’를 입력해 줘”라고 메시지를 보냅니다.
• personal-agent에 “현재 디렉터리의 모든 파일을 나열해 줘”라고 메시지를 보냅니다.
• 결과: personal-agent에는 test.txt가 보이지 않습니다.

테스트 2: 대화 격리

• work-agent에 “기억해 줘. 내 프로젝트 코드명은 ProjectX야”라고 말합니다.
• personal-agent에 “내 프로젝트 코드명이 뭐야?”라고 묻습니다.
• 결과: personal-agent는 work-agent의 대화 기록이 없으므로 “모르겠습니다”라고 답합니다.

테스트 3: 기능 격리

• .env.work에 ENABLE_CODE_EXECUTION=true를 설정합니다.
• .env.personal에 ENABLE_CODE_EXECUTION=false를 설정합니다.
• 결과: work-agent는 코드를 실행할 수 있지만 personal-agent는 실행을 거부합니다.

세 가지 테스트를 모두 통과했다면 격리가 제대로 적용된 것입니다.

자주 발생하는 문제:

• “포트가 이미 사용 중”: CONTAINER_PORT를 확인하고 agent마다 다른 포트를 사용합니다.
• “Telegram bot이 응답하지 않음”: bot token이 올바른지, ALLOWED_USERS에 사용자 ID가 포함되어 있는지 확인합니다.
• “파일 권한 오류”: WORKSPACE_PATH 디렉터리 권한을 확인하고 Docker에 읽기 및 쓰기 권한이 있는지 확인합니다.

고급 활용 팁과 주의할 점

몇 달 동안 사용하며 알게 된 내용을 정리했습니다.

성능 최적화: agent가 리소스를 독점하지 않게 하기

처음에는 agent 5개를 설정했더니 컴퓨터 팬이 계속 돌고 메모리를 8GB나 사용했습니다. 다음과 같이 최적화했습니다.

리소스 상한 설정
docker-compose.yml에 다음 설정을 추가합니다.

deploy:
  resources:
    limits:
      cpus: '0.5'
      memory: 512M

agent 하나가 최대 CPU 코어 0.5개와 메모리 512MB만 사용하게 됩니다. 이 정도면 충분합니다.

필요할 때만 시작하고 중지하기
실험 샌드박스처럼 자주 사용하지 않는 agent에는 간단한 시작·중지 스크립트를 사용합니다.

# start-sandbox.sh
docker start sandbox-agent-container
# 사용 후
docker stop sandbox-agent-container

기본 이미지 공유
모든 agent는 설정만 다를 뿐 동일한 OpenClaw 기본 이미지를 사용합니다. 따라서 agent 5개를 실행해도 디스크는 각각 이미지를 복사할 때와 달리 1~2GB만 더 사용합니다.

Railway - 현대적인 배포 플랫폼, 번거로운 운영 없이 몇 분 만에 라이브

지금 시작 →광고

보안 모범 사례: 편리함 때문에 안전을 놓치지 않기

최소 권한 원칙
각 agent에는 꼭 필요한 권한만 부여합니다. 예를 들어 personal-agent가 /work 디렉터리에 접근할 필요가 없다면 Docker 설정에서 아예 해당 경로를 마운트하지 않습니다.

민감한 데이터 처리
API 키와 데이터베이스 비밀번호는 코드에 하드코딩하지 말고 항상 환경 변수로 관리합니다. 또한 .env 파일이 실수로 Git에 커밋되지 않았는지 정기적으로 확인합니다. 이때 .gitignore가 중요합니다.

정기 감사
일주일에 한 번 agent의 작업 로그를 확인합니다.

docker logs work-agent-container --since 7d | grep ERROR

비정상적인 작업이나 오류가 없는지 확인해 두면 안심할 수 있습니다.

자주 발생하는 문제 해결

agent가 시작되지 않음

• 먼저 docker logs <컨테이너 이름>으로 로그를 확인합니다.
• 대부분 포트 충돌이나 Docker 권한 문제입니다.
• 포트를 바꾸거나 Docker 사용자에게 권한을 부여하면 됩니다.

메시지 라우팅 실패

• Telegram bot token을 잘못 설정하지 않았는지 확인합니다.
• Gateway 설정의 ALLOWED_USERS에 사용자 ID가 포함되어 있는지 확인합니다.
• curl로 bot이 온라인 상태인지 테스트합니다.

파일 권한 오류

• Docker 컨테이너 내부 사용자 ID와 호스트 사용자 ID가 일치하지 않는 문제일 수 있습니다.
• docker-compose.yml에 user: "${UID}:${GID}"를 설정합니다.

솔직히 이 문제를 저도 모두 겪어 봤습니다. 문제가 생겨도 당황하지 마세요. 90%는 로그에서 원인을 찾을 수 있습니다.

요약과 다음 단계

핵심은 세 가지입니다.

필요한 이유: AI 어시스턴트 하나가 업무, 개인 생활, 실험의 컨텍스트를 섞으면 개인정보가 노출되고 효율이 떨어집니다. 멀티 에이전트 라우팅은 물리적 격리로 이 문제를 해결합니다.

설정 방법: 서로 다른 .env 파일로 여러 agent를 만들고 각각 별도의 작업 디렉터리, 메시지 진입점, 권한을 설정합니다. 5분이면 첫 work/personal agent 한 쌍을 설정할 수 있습니다.

모범 사례: 최소 권한, 필요할 때만 시작·중지, 정기 감사를 지킵니다. 편리함과 안전을 함께 얻으려면 기본 원칙을 생략하지 않아야 합니다.

저는 지금도 매일 이 멀티 에이전트 시스템을 사용합니다. 실제로 업무 집중도가 높아졌고(AI가 갑자기 제 부업 프로젝트를 언급하지 않습니다), 실험은 더 안심하고 할 수 있으며(샌드박스 안에서 자유롭게 테스트합니다), 개인정보도 더 안전합니다(시연 중 사적인 대화가 노출될 걱정이 없습니다).

다음 할 일:

1. 오늘 위 안내에 따라 첫 work/personal agent 한 쌍을 설정해 보세요. 어렵지 않습니다.
2. 문제가 생기면 OpenClaw의 GitHub Issues나 Discord 커뮤니티에 질문하세요. 친절하게 도움을 받을 수 있습니다.
3. 이 글이 유용했다면 AI 어시스턴트의 컨텍스트가 뒤섞여 곤란했던 지인에게 공유하세요.

마지막으로 AI 도구는 삶을 더 편하게 만들어야지 더 복잡하게 만들어서는 안 됩니다. 멀티 에이전트 라우팅은 AI 어시스턴트를 용도별로 정리해 각자 맡은 역할만 수행하게 합니다. 그러면 워크플로도 자연스럽게 깔끔해집니다.

직접 사용해 보면 지금 시작한 선택을 잘했다고 느낄 것입니다.