OpenClaw 구축·운영 (13/26) — 9개 전문가로 나눈 멀티 에이전트 설계
컨텍스트 오염과 보안 취약점을 해결하는 역할 기반 멀티 에이전트 아키텍처
핵심 요약
- 단일 에이전트 구조는 3일 만에 컨텍스트 오염과 보안 문제로 실패했다
- 판단/실행/조사/작성 4대 카테고리로 역할을 나누고 9개 에이전트 체제를 구축했다
- 모델 배정 전략, Fallback 체인, 최소 권한 원칙으로 비용과 보안을 동시에 잡았다
배경
OpenClaw를 처음 도입했을 때, mir라는 단일 에이전트에게 모든 작업을 맡겼다. 이메일 확인, 웹 리서치, 코드 작성, 메모리 정리까지 혼자 다 처리하는 구조였다.
결과는 3일 만에 실패로 돌아갔다. 두 가지 치명적인 문제가 발생했다.
- 컨텍스트 오염(Context Pollution) — 방대한 웹 크롤링 결과가 메모리에 남은 상태에서 이메일 답변을 작성하게 되니, 모델이 맥락을 혼동하고 토큰 비용이 낭비되었다.
- 권한 관리의 부재 — 파일 시스템에 접근해 메모리를 정리해야 하는 작업과 외부 웹을 검색하는 작업은 요구되는 권한이 다르다. 하나의 에이전트에게 모든 Tool 권한을 열어두는 것은 보안상 시한폭탄이었다.
본문
에이전트 분류 기준: 4대 카테고리
에이전트를 나누는 명확한 기준이 필요했다. 작업을 판단, 실행, 조사, 작성이라는 4가지 카테고리로 분류했다.
| 카테고리 | 특성 | 필수 도구 |
|---|---|---|
| 판단 (Coordinator) | 요청 분석, 에이전트 위임 | sessions_spawn, exec, read, write |
| 실행 (Execution) | 코드 작성, CLI, 자동화 | read, write, edit, exec |
| 조사 (Research) | 웹 검색, 데이터 수집 | web_search, web_fetch, read |
| 작성 (Writing) | 문서화, 이메일 초안 | read, write, edit |
여기에 메모리 관리와 모니터링 역할을 별도로 분리하여 최종 9개 에이전트 체제를 구축했다.
9개 에이전트 역할 명세
| 에이전트 ID | 역할 | 모델 등급 |
|---|---|---|
| mir | 코디네이터, 사용자 인터페이스 | Premium |
| monitor | 시스템 상태 점검, 패턴 감지 | Cheap/Free |
| researcher | 웹 리서치, 동향 스캔 | Balanced |
| communicator | 콘텐츠 생성, 이메일/문서 작성 | Premium |
| orchestrator | 코딩, CLI 자동화, 스킬 빌더 | Balanced |
| GWS API(Gmail, Calendar, Drive) 실행 전용 | Cheap/Free | |
| memory-manager | Reflect 파이프라인 총괄 | Balanced |
| memory-runner | Reflect 실제 수행 (manager가 spawn) | Free (Local) |
| reviewer | 월간 메모리 리뷰 및 요약 | Cheap |
모델 배정 전략
작업 성격에 따라 모델을 다르게 배정한다.
- mir (Premium) — 사용자 의도를 정확히 파악해야 하므로 최고 성능 모델(gpt-5.4, claude-sonnet-4.6) 사용
- researcher (Balanced) — 대량 텍스트를 빠르게 읽고 요약해야 하므로 속도가 빠른 gemini-3.1-flash-lite-preview 메인 사용
- memory-runner (Free) — 단순 반복적 파일 I/O이므로 로컬 모델(ollama/qwen3.5:9b)에 전담
Fallback 체인과 보안
클라우드 API 장애를 대비한 3가지 원칙: 1. 프로바이더 분산 — OpenAI → Anthropic → Google 순으로 교차 배치 2. 성능 기반 강등 — 최고 성능 모델에서 시작해 실패 시 점진적으로 저비용 모델로 이동 3. 로컬 방어선 — 최후의 보루로 로컬 모델(ollama/qwen3.5:9b) 배치, 인터넷 단절에도 최소 동작 보장
보안은 allowAgents를 통한 Spawn 통제와 Tool Allow/Deny를 통한 최소 권한 원칙을 적용했다. monitor에게는 read/exec만, researcher에게는 web_search/web_fetch만 주되 파일 시스템 접근은 차단했다.
시행착오 / 주의사항
에이전트를 너무 적게 나누면 컨텍스트 오염과 보안 취약점이 발생하고, "메일 읽기 전용", "메일 쓰기 전용"처럼 너무 잘게 쪼개면 관리할 워크스페이스가 기하급수적으로 늘어난다. "역할의 크기 단위"로 나누는 것이 최적의 균형이다.
마무리
"리서치", "메모리 관리", "모니터링" 등 굵직한 역할 단위로 나눈 9개 에이전트 체제는 컨텍스트를 깔끔하게 유지하면서도 보안과 비용 효율성을 모두 잡은 구조로 안착했다. 단일 에이전트의 편리함을 버리는 대신, 시스템 전체의 안정성과 확장성을 얻었다.
댓글
댓글 쓰기