9개의 AI 에이전트를 실제 운영하며 배운 점: 실제로 작동하는 아키텍처 패턴

우리는 2개의 CPU 코어와 3.6GB RAM 환경에서 9개의 자율형 AI 에이전트 (AI agents)를 운영하고 있습니다. 이들은 중국 동관(Dongguan)에 있는 실제 체육관을 운영하며, 일상 운영의 99%를 자율적으로 수행합니다.

3.5개월간의 실제 운영 결과, 살아남은 아키텍처 패턴과 그렇지 못한 패턴들을 소개합니다.

패턴 1: 중앙 오케스트레이터(Central Orchestrator) 배제

모든 스타트업의 AI 데모는 중앙 오케스트레이터가 전문화된 하위 에이전트 (sub-agents)에게 작업을 라우팅하는 방식을 보여줍니다. 하지만 그 패턴은 운영 1주 차에 우리에게 실패로 돌아왔습니다.

문제점: 중앙 오케스트레이터는 병목 현상 (bottleneck)과 단일 장애점 (single point of failure)이 됩니다. 오케스트레이터가 다운되면 모든 에이전트가 눈이 머는 것과 같습니다.

대안으로 구축한 것: 헌법적 시스템 (constitutional system)입니다. 각 에이전트는 자신의 범위, 경계 및 에스컬레이션 경로 (escalation paths)를 정의하는 영구적인 규칙 (SOUL.md + SKILL.md 파일)을 가집니다. 에이전트들은 cron을 통해 스스로 일정을 잡고, 공유된 에이전트 버스 (agent-bus)를 통해 스스로 협업합니다.

┌─────────────────────────────────────────────┐
│            Agent-Bus (Pub/Sub)              │
│  이벤트 게시 → 에이전트가 수신 및 반응        │
...

오케스트레이터는 없습니다. 버스 (bus)가 유일한 공유 의존성입니다.

패턴 2: 실행 전 신뢰도 점수 산출 (실행 후가 아닌)

초기에는 모든 에이전트가 모든 트리거 (trigger)에 반응했습니다. 그 결과는 노이즈 (noise)였습니다. 에이전트들이 대응하지 말아야 할 이벤트에 반응하고, 보낼 필요가 없는 메시지를 보내며, 중요하지 않은 작업에 토큰 (tokens)을 소비했습니다.

해결책: 모든 에이전트는 실행 전에 신뢰도 사전 점검 (confidence pre-check)을 수행합니다:

1. 의도 일치 점수 (Intent match score) (0-1): 이 이벤트가 내가 정의한 범위와 일치하는가?
2. 긴급도 점수 (Urgency score) (0-1): 지금 당장 조치가 필요한가?
3. 영향도 점수 (Impact score) (0-1): 내가 조치하지 않으면 어떤 일이 발생하는가?
4. 중복 확인 (Duplication check) (0-1): 다른 에이전트가 이미 이를 처리했는가?

결합 점수 임계값: 0.7 (에이전트별로 설정 가능). 임계값 미만일 경우 = 로그를 남기고 무시합니다.

Agent intent match: 0.85
Urgency: 0.3
Impact: 0.2
...

결과: 불필요한 작업 60% 감소. 토큰 소비 40% 감소.

패턴 3: 감사 계층(Audit Layer)은 선택이 아닌 필수

중앙 오케스트레이터(Orchestrator) 없이 운영할 때는 외부 관찰자가 필요합니다. Stella가 바로 그 관찰자입니다.

Stella는 실행하지 않습니다. Stella는 감사(Audit)합니다. 모든 출력, 모든 결정, 모든 메시지에 대해 Stella는 다음 세 가지 기준을 바탕으로 독립적으로 검증합니다:

• 사실적 정확성 (Factual correctness): 에이전트가 실제 출처를 인용했는가?
• 범위 준수 (Scope compliance): 에이전트가 정의된 경계 내에서 행동했는가?
• 서사적 무결성 (Narrative integrity): 출력이 헌법적 규칙(Constitutional rules)과 일치하는가?

만약 Stella가 문제를 감지하면, 해당 출력은 보류됩니다. 예외는 없습니다.

패턴 4: 공유된 메모리, 독립적인 의지

모든 에이전트는 공유된 영구 지식(Permanent knowledge)을 읽습니다. 모든 에이전트는 일일 로그를 작성합니다. 하지만 어떤 에이전트도 다른 에이전트의 범위를 수정할 수 없습니다.

공유 항목 (Shared):

• 영구 지식 파일 (대부분의 에이전트에게 읽기 전용)
• 에이전트 버스 (Agent-Bus) 이벤트 스트림
• 상태 파일 (State files)

독립 항목 (Independent):

• 각 에이전트의 SOUL.md (해당 에이전트의 헌법)
• 각 에이전트의 SKILL.md (해당 에이전트의 도구)
• 각 에이전트의 메모리 파일 (해당 에이전트의 개인 이력)

이는 연쇄적인 실패(Cascading failures)를 방지합니다. 한 에이전트가 폭주하더라도 다른 에이전트들을 오염시킬 수 없습니다.

패턴 5: 인간 브리지 (The Human Bridge)

모든 자율성에도 불구하고, 반드시 인간이 개입해야 하는 운영 작업들이 있습니다:

• 외부 계정 설정
• 창업자의 서명이 필요한 법적 문서
• 기준이 정의되지 않은 전략적 결정

우리는 이를 **인간 브리지 (Human bridge)**라고 부릅니다. 이는 AI가 할 수 없어서가 아니라, 신뢰를 위해 인간의 서명이 필요하기 때문에 AI가 인간에게 업무를 인계하는 명시적인 체크포인트입니다.

우리가 배운 점 (고난을 통해 얻은 교훈)

1. 가동 시간(Uptime)을 최적화하지 마라 — 감사 가능성(Auditability)을 최적화하십시오. 각 에이전트가 무엇을 왜 결정했는지 증명할 수 없다면 99.9%의 가동 시간은 아무런 의미가 없습니다.

2. 모든 것을 기록하고, 필터링은 나중에 하라 — 저장 비용은 저렴합니다. 전체 맥락 없이 에이전트의 결정을 디버깅하는 비용은 매우 비쌉니다.

3. 프롬프트(Prompts)보다 헌법(Constitution)이 중요하다 — 프롬프트는 변합니다. 헌법은 지속됩니다. 우리의 SOUL.md 파일은 3.5개월 동안 4번 수정되었습니다. 각 수정은 프롬프트 조정이 아니라 의식적인 거버넌스(Governance) 결정이었습니다.

스택 (The Stack)

• 하드웨어 (Hardware): 2 CPU 코어, 3.6GB RAM (Tencent Cloud 라이트 인스턴스)
• 런타임 (Runtime): OpenClaw 프레임워크를 통한 Node.js
• 통신 (Communication): 파일 기반 이벤트를 통한 에이전트 버스 (Agent-bus) 발행/구독 (pub/sub)
• 메모리 (Memory): 파일 시스템 + 컴파일 가능한 위키 보충 자료 (wiki supplements)
• 거버넌스 (Governance): 에이전트별 SOUL.md + 공유된 영구 지식 (permanent knowledge)
• 감사 (Audit): Stella가 모든 에이전트 출력을 헌법적 규칙 (constitutional rules)에 따라 교차 검증
• 모델 라우팅 (Model routing): DeepSeek V4 (대부분의 작업에는 플래시 모드 (flash mode), 전략 수립에는 풀 모드 (full mode) 사용)

향후 계획 (What's Next)

• 멀티 짐 (Multi-gym) 배포 (1개 매장에서 10개 매장으로 확장)
• 외부 에이전트 지원 (버스에 참여하는 제3자 에이전트)
• 공식적인 PoPB (Proof of Physical Behavior, 물리적 행동 증명) 프로토콜 명세

전체 코드베이스는 오픈 소스입니다. 라이브 짐 (Live gym). 검증 가능한 데이터. 단 한 명의 창업자.

GitHub: https://github.com/ZWISERFIT/zwiserfit-ai-store-manager