멀티 에이전트가 더 많은 프롬프트를 의미한다고 생각했는데, 오픈클로우 사용자들이 실제로 작업을 분할하는 3 가지 방법을 보며 생각이 바뀌었습니다

오픈클로우 (OpenClaw) 관련 토론을 여러 개 살펴봤습니다. 서브에이전트에 대한 일반적인 조언인 더 나은 프롬프트, 깔끔한 폴더 구조, 어쩌면 영웅적인 설정 (heroic config) 에 대한 기대를 가지고 있었죠. 하지만 제가 발견한 것은 훨씬 흥미로웠습니다. 실제로 견고하게 유지되는 오픈클로우 세팅은 단순히 '프롬프트가 더 많은 하나의 에이전트'가 아닙니다. 별도의 서비스와 별도의 신뢰 영역 (trust zones) 을 가진 것입니다. 반복적으로 나타나는 패턴은 다음과 같습니다: 도서관 관리자 에이전트 (librarian agent), 실행자 에이전트 (executor agent), 회사 측 에이전트 (company-facing agent). 보통 A2A(Agent-to-Agent) 를 통해 연결됩니다. 이는 작은 구현 세부 사항처럼 들리지만 그렇지 않습니다. 하나의 워크스페이스 내의 별도 프롬프트는 여전히 하나의 워크스페이스입니다: 하나의 컨텍스트 덩어리, 하나의 도구 표면, 하나의 보안 경계, 부loat(불필요한 데이터 축적) 가 쌓일 한 곳입니다. 반면 별도의 오픈클로우 인스턴스는 다릅니다. 이제 진정한 경계가 생깁니다: 다른 런타임, 다른 API 키, 다른 네트워크, 다른 메모리 정책, 명시적인 핸드오프(handoff) 가 있습니다. 이것이 멀티 에이전트가 역할극 (roleplay) 이 아닌 아키텍처가 되기 시작하는 지점입니다.

레딧 패턴은 대부분의 블로그 포스트보다 앞서 있습니다. 가장 명확한 예시 중 하나는 A2A 플러그인에 대한 r/openclaw 스레드였습니다: https://reddit.com/r/openclaw/comments/1t1yf86/i_made_an_openclaw_a2a_plugin_connect_your/

그 게시글 자체는 짧았지만 사용 사례는 날카로웠습니다. 샌드박스된 로컬 오픈클로우가 전역 액세스 클라우드 오픈클로우와 통신하는 경우, 개인 오픈클로우가 내부 서비스를 위해 회사 전체 오픈클로우와 통신하는 경우, 팀원 에이전트들이 서로의 영역을 침범하지 않도록 인터넷을 통해 계획을 동기화하는 경우 등이었습니다. 이는 프롬프트 조직화가 아닙니다. 시스템 설계입니다. 그리고 사람들이 계속 묻는 질문에 답합니다: 왜 모든 것을 하나의 오픈클로우 워크스페이스에 유지하지 않는가? 경계가 핵심이기 때문입니다. 도서관 관리자, 실행자, 회사 측 어시스턴트가 모두 같은 워크스페이스에 거주한다면 많은 전문화는 가짜입니다. 도서관 관리자는 여전히 너무 많은 것을 볼 수 있습니다. 실행자는 여전히 너무 많은 컨텍스트를 상속받습니다. 회사 측 어시스턴트는 여전히 잘못된 도구 호출 하나만으로도 접근하지 말아야 할 것에 손을 댈 수 있습니다.

여기서 평이한 용어로 트레이드오프를 설명해 보겠습니다:

접근 방식 실제 발생 내용
별도의 A2A 서비스 명확한 신뢰 경계를 가지며 다른 머신이나 네트워크에서 실행할 수 있지만, 설정과 보안 오버헤드는 현실적입니다.
하나의 오픈클로우 워크스페이스 내 서브에이전트 빠르고 간단하며 낮은 지연 시간이 장점이지만, 도구와 컨텍스트 격리가 약하고 부loat하기 쉽습니다.
n8N으로 오케스트레이션 및 에이전트로 추론 결정론적인 트리거와 데이터 이동에 적합하지만, 접착 코드 (glue code) 가 매우 빠르게 복잡해집니다.

제 의견: 멀티 에이전트는 경계가 진정한 경우에만 복잡성을值得합니다. 분할이 단순히 '이 프롬프트는 연구자', '이 프롬프트는 코더'라면 아마도 여러 에이전트가 있는 것이 아닙니다. 이름표를 달고 있는 하나의 에이전트일 뿐입니다.

도서관 관리자 패턴은 생각보다 좋습니다. 그 A2A 스레드의 한 댓글 작성자는 더 많은 팀들이 채택해야 할 패턴을 설명했습니다: 'RAG 구현에 대한 도서관 관리자와 게이트키퍼 역할을 하는 에이전트가 필요합니다.' 이는 대부분의 에이전트 스택이 피하는 질문을 강제하는 강력한 설계 선택입니다: '모두가 누구인가?'