AI 어시스턴트에게 경쟁사 제품을 조사하고, 결과를 요약하고, 비교 문서를 작성하고, 팀에 이메일로 보내달라고 요청한다. 단일 에이전트가 이 각 단계를 수행할 수 있다 — 하지만 네 가지 작업 전체에 걸쳐 컨텍스트를 유지하면서 순서대로 잘 수행하는 것은 하나의 에이전트 세션이 우아하게 처리할 수 있는 한계를 밀어붙인다. 컨텍스트 윈도우가 차오른다. 에이전트가 이전 단계를 놓친다. 모델이 너무 많은 관심사를 동시에 저글링하기 때문에 최종 출력의 품질이 떨어진다.
이것이 에이전트 스웜이 해결하는 문제다. 하나의 에이전트가 모든 것을 하는 대신, 코디네이터 에이전트가 작업을 하위 작업으로 나누고 각각을 전문 에이전트에게 위임한다. 리서치 에이전트가 웹을 검색하고 구조화된 결과를 반환한다. 작성 에이전트가 그 결과를 받아 문서를 작성한다. 이메일 에이전트가 결과를 전송한다. 각 에이전트는 자체 컨테이너에서, 자체 컨텍스트 윈도우로, 하나에 집중하여 작동한다.
아이디어 자체는 새롭지 않다 — CrewAI와 AutoGen이 1년 넘게 멀티 에이전트 패턴을 탐구해왔다. NanoClaw의 접근 방식이 다른 점은 스웜의 각 에이전트가 자체 격리된 컨테이너에서 실행되어, 단일 에이전트 대화에 적용되는 보안 및 격리 보장이 멀티 에이전트 워크플로우에도 자동으로 확장된다는 것이다.
NanoClaw에서 스웜이 작동하는 방식
NanoClaw의 스웜 아키텍처는 단순한 프리미티브 위에 구축된다: 에이전트가 다른 에이전트를 생성할 수 있다. Claude Code가 컨테이너 안에서 실행될 때, 사용 가능한 도구 중 하나가 에이전트 위임이다 — 하위 작업을 설명하면 NanoClaw가 이를 처리할 새 컨테이너를 생성한다. 부모 에이전트는 자식 에이전트가 완료되면 결과를 돌려받는다.
오케스트레이션은 Claude 자체의 추론을 통해 자연스럽게 이루어진다. 워크플로우 그래프를 정의하거나 YAML 파일에서 에이전트 역할을 설정할 필요가 없다. 원하는 것을 설명하면, Claude가 직접 처리할지 일부를 하위 에이전트에게 위임할지 결정한다. 이 결정은 Claude가 복잡한 문제를 분해하는 데 뛰어난 것과 같은 추론에 기반한다 — 집중적인 주의가 도움이 될 독립적인 구성 요소가 있는 작업을 인식한다.
실제로 이것은 컨테이너 트리처럼 보인다. 루트 컨테이너가 메시지를 받고, 웹 리서치와 문서 작성이 필요하다고 판단하고, 두 개의 자식 컨테이너를 생성하고, 결과를 기다리고, 최종 응답을 합성한다. 각 자식 컨테이너는 자체 CLAUDE.md 컨텍스트, 자체 마운트된 작업 공간, 자체 도구 세트를 가진다. 리서치 에이전트는 웹 브라우징이 활성화되고, 작성 에이전트는 공유 작업 공간에 파일 쓰기 접근 권한이 있다. 어느 쪽도 상대방의 컨텍스트나 도구에 접근할 수 없다.
스웜에서 컨테이너 격리가 중요한 이유
대부분의 멀티 에이전트 프레임워크는 모든 에이전트를 같은 프로세스에서 실행한다. CrewAI의 에이전트들은 Python 런타임을 공유한다. AutoGen의 에이전트들은 대화 스레드를 공유한다. 데모에서는 작동하지만, 규모에서는 사후에 고치기 어려운 문제를 만든다.
첫 번째 문제는 피해 범위다. 스웜의 한 에이전트가 프롬프트 인젝션을 만나면 — 에이전트의 동작을 탈취하려는 악성 웹사이트 — 인젝션은 해당 단일 컨테이너에 격리된다. 부모 에이전트에 영향을 줄 수 없고, 다른 자식 에이전트의 컨텍스트에 접근할 수 없으며, 원래 사용자의 대화 기록을 읽을 수 없다. 손상된 컨테이너는 완료 시 해체되고, 부모 에이전트는 생성된 출력을 받는다(부모가 사용 전에 품질을 평가할 수 있다).
두 번째 문제는 리소스 경합이다. 공유 프로세스의 에이전트들은 같은 컨텍스트 윈도우, 같은 메모리, 같은 CPU를 놓고 경쟁한다. NanoClaw에서는 각 컨테이너가 자체 리소스를 가진다. 무거운 웹 페이지를 탐색하는 리서치 에이전트가 문서를 작성하는 작성 에이전트를 느리게 하지 않는다. 컨테이너들은 별도 스레드에서 동시에 실행되며, 호스트의 리소스 관리가 스케줄링을 처리한다.
세 번째 문제는 인증 정보 범위 지정이다. 리서치 에이전트는 웹 접근이 필요하지만 파일 쓰기 권한은 필요 없다. 파일 관리 에이전트는 디스크 접근이 필요하지만 웹 접근은 필요 없다. 공유 프로세스 프레임워크에서 이런 경계를 시행하려면 우회될 수 있는 애플리케이션 수준 권한 검사가 필요하다. NanoClaw에서 경계는 컨테이너 마운트다 — 리서치 에이전트는 쓰기 가능 경로가 컨테이너에 마운트되지 않았기 때문에 말 그대로 디스크에 쓸 수 없다.
실용적인 스웜 패턴
실제 사용에서 나타나는 패턴은 이론적 아키텍처보다 더 흥미롭다. 가장 흔한 것은 리서치-합성 패턴이다: 부모 에이전트가 질문의 다양한 측면을 조사하기 위해 3-5개의 리서치 에이전트를 병렬로 생성하고, 결과를 수집하고, 단일 에이전트가 한 번에 생성할 수 있는 것보다 더 철저한 합성된 답변을 만든다.
두 번째로 흔한 패턴은 초안-검토다. 에이전트가 초안을 작성한 다음, 비평 지시와 함께 검토 에이전트를 생성한다. 검토자의 피드백은 원래 에이전트(또는 새 작성 에이전트)에게 수정을 위해 돌아간다. 이는 단일 패스 생성보다 눈에 띄게 더 나은 출력을 만든다 — 검토 에이전트가 새로운 컨텍스트 윈도우를 가지고 있어 초안을 작성한 인지 부하 없이 평가할 수 있기 때문이다.
세 번째 패턴은 도구 전문화다. 일부 작업은 비용이 많이 들거나 위험한 도구를 필요로 한다 — 웹 브라우징, 셸 명령 실행, 파일 시스템 수정. 부모 에이전트는 이런 작업을 특정 도구 접근 권한을 가진 자식 에이전트에게 위임하여, 자체 컨텍스트를 깨끗하게 유지하고 자체 권한을 최소화할 수 있다. 부모는 파일시스템이나 네트워크를 직접 건드리지 않는다 — 자식 에이전트가 반환하는 결과만 처리한다.
스웜의 한계
스웜은 공짜가 아니다. 모든 자식 에이전트는 별도의 Claude API 호출이며, 이는 별도의 토큰 비용을 의미한다. 5개의 리서치 에이전트를 생성하는 스웜은 단일 에이전트가 모든 리서치를 하는 것보다 대략 5배 비용이 든다. 단순한 질문 — "날씨 어때?" 또는 "이 문장 번역해줘" — 에는 스웜이 순수한 오버헤드다.
지연도 누적된다. 병렬 실행에도 불구하고, 부모 에이전트는 결과를 합성하기 전에 가장 느린 자식이 완료될 때까지 기다려야 한다. 5개 에이전트 스웜에서 하나가 느린 웹사이트를 탐색하느라 30초 걸리면, 다른 4개가 아무리 빨라도 사용자는 30초 플러스 합성 시간을 기다린다.
NanoClaw는 이를 실용적으로 처리한다. Claude가 작업 복잡도에 따라 스웜 사용 여부를 결정한다 — 단순한 질문은 직접 답변하고, 복잡한 다중 파트 요청은 위임한다. 사용자가 스웜 동작을 설정하지 않는다 — 그냥 질문하면 시스템이 복잡도에 맞게 접근 방식을 조절한다. 목표는 스웜을 어디서나 사용하는 것이 아니라 — 단일 에이전트보다 진정으로 더 나은 결과를 만드는 곳에서 사용하는 것이다.
멀티 에이전트의 미래는 단일 에이전트를 대체하는 것이 아니다. 단일 에이전트가 필요할 때 도움을 요청할 수 있는 능력을 주는 것이다 — 안전하고, 격리되고, 투명한 방식으로. NanoClaw의 에이전트당 컨테이너 모델은 공유 환경에서 여러 에이전트를 실행할 때 따르는 보안 타협 없이 이를 가능하게 한다.