오케스트레이터 없이 2개의 CPU 코어에서 9개의 자율 에이전트가 체육관을 운영하는 방법

태그: opensource, ai, architecture, scaling

대부분의 멀티 에이전트 시스템 (multi-agent systems)은 중앙 오케스트레이터 (orchestrator) — 즉, 어떤 에이전트가 무엇을, 언제, 어떤 리소스를 사용하여 수행할지 결정하는 하나의 컨트롤러를 필요로 합니다.

우리의 시스템에는 그것이 없습니다.

누구의 통제도 없이 9개의 자율 에이전트가 어떻게 체육관 운영을 조율하는지 소개합니다.

오케스트레이터 문제 (The Orchestrator Problem)

모든 오케스트레이터는 단일 장애점 (single point of failure)입니다. 오케스트레이터가 다운되면 모든 에이전트가 대기합니다. 오케스트레이터가 느려지면 모든 에이전트가 대기열 (queue)에 쌓입니다. 오케스트레이터가 잘못된 결정을 내리면 모든 에이전트가 그 결정을 물려받습니다.

업계의 해결책: 오케스트레이터를 더 크게, 더 빠르게, 더 중복화(redundant)하는 것입니다. 더 많은 서버, 더 많은 비용, 더 많은 복잡성을 초래합니다.

우리의 해결책: 오케스트레이터를 두지 않는 것입니다.

헌법 > 오케스트레이터 (Constitution > Orchestrator)

중앙 컨트롤러 대신, 각 에이전트는 명문화된 헌법 (constitution) 내에서 작동합니다. 이 헌법은 다음을 정의하는 규칙 세트입니다:

1. 도메인 (Domain): 이 에이전트가 책임지는 것 (그리고 해서는 안 되는 것)
2. 트리거 (Trigger): 어떤 조건이 이 에이전트를 활성화하는가
3. 에스컬레이션 (Escalation): 이 에이전트가 언제 다른 에이전트나 인간에게 업무를 넘겨야 하는가
4. 감사 (Audit): Stella (독립 감사 에이전트)가 이 에이전트의 출력을 어떻게 검증할 수 있는가

어떤 에이전트도 헌법을 무시할 수 없습니다. Shuyu (사령관)는 Stella의 감사를 뒤집을 수 없습니다. Zeus (자본 에이전트)는 매장 운영을 작성할 수 없습니다. Momo (매장 브레인)는 자본 내러티브를 수정할 수 없습니다.

이것은 코드로 강제되는 것이 아닙니다. 실제 헌법이 작동하는 방식과 마찬가지로 거버넌스 (governance)에 의해 강제됩니다. 모든 위반 사항은 기록되며 Stella에 의해 발견될 수 있습니다.

실제 적용되는 세 가지 레이어 (The Three Layers in Practice)

Momo 레이어 (항상 작동): 얼굴 체크인, 운동 기록, 스케줄링, 결제를 처리합니다. 두 가지 제품이 있습니다: Saros (B2B 매장 OS)와 Melody (B2C 대사 코치). 인터넷이 끊겨도 Momo는 오프라인 상태를 유지합니다 — 체크인 정보는 엣지 (edge)에서 캐싱됩니다.

KinTwin Layer (edge-triggered, 엣지 트리거 방식): 행동 기록의 검증이 필요할 때 활성화됩니다. 저전력 하드웨어에서 컴퓨터 비전 추론 (computer vision inference)을 실행합니다 (GPU 불필요). 검증된 기록은 사용자의 DID에 서명됩니다. 만약 KinTwin이 검증할 수 없는 경우(조명 불량, 카메라 가려짐 등), 해당 기록은 무시되는 것이 아니라 플래그(flag) 처리됩니다.

Global Ops Layer (event-driven, 이벤트 기반 방식): 검증된 행동 기록이 수익화 파이프라인 (monetization pipeline)에 진입하면 Zeus 프로토콜이 활성화됩니다. Stella는 정기적인 감사 주기 (audit cycle)에 따라 활성화됩니다 — 그녀는 결코 잠들지 않으며, 모든 에이전트의 출력 창을 감사합니다.

왜 2개의 코어로 충분한가

세 가지 설계 제약 조건이 리소스 사용량을 최소한으로 유지합니다:

1. 시분할 에이전트 (Time-multiplexed agents): 오직 2~3개의 에이전트만이 동시에 활성화됩니다. 나머지는 트리거될 때까지 휴면 상태로 유지됩니다. 이는 단순한 최적화가 아니라, 실제 체육관의 스케줄링 원리와 동일합니다.

2. 엣지 우선 처리 (Edge-first processing): 컴퓨터 비전 추론 (computer vision inference)은 클라우드가 아닌 체육관 현장에서 발생합니다. 클라우드 VM은 조정 (coordination), 거버넌스 (governance), 그리고 수익화 (monetization) — 즉, 가벼운 워크로드 (lightweight workloads)만을 처리합니다.

3. 헌법적 라우팅 (Constitutional routing): 트리거 이벤트가 도착하면, 라우팅 레이어 (routing layer), 메시지 큐 (message queue), 또는 로드 밸런서 (load balancer) 없이도 헌법 (constitution)이 어떤 에이전트가 이를 처리할지 결정합니다. 이벤트는 정확히 있어야 할 곳으로 전달됩니다.

결과

34일간의 프로덕션 업타임 (production uptime). 하나의 물리적 체육관. 9개의 에이전트. 2개의 CPU 코어. 3.6GB RAM.

오케스트레이터 (orchestrator) 없음. Kubernetes 없음. 메시지 큐 (message queue) 없음.

오직 헌법 (constitution), 몇 가지 설계 제약 조건, 그리고 자신의 업무를 알고 있는 에이전트들뿐입니다.

🔗 GitHub: https://github.com/ZWISERFIT
🔗 이전 글: 9 AI Agents, 2 CPU Cores, One Gym: The 3-Layer Architecture

Dev.to 시리즈: build-in-public | 우리의 듀얼 채널 콘텐츠 파이프라인 2일 차