DOCS/300_architecture/310_전체_시스템_구조_컨테이너와_마이크로서비스.md

로빙 컨테이너 아키텍처 설계

개요

로빙 AI 에이전트는 사용자별로 독립적인 Docker 컨테이너(각 로빙의 '집')에서 실행되며, 중앙 대시보드를 통해 관리됩니다. 각 로빙은 개별적인 성장 경로를 가지며, 효율적인 리소스 관리와 데이터 안전성을 보장합니다.

왜 컨테이너와 마이크로서비스인가?

컨테이너(Docker)를 선택한 이유

1. 격리와 보안: 각 로빙의 데이터와 처리 과정이 완전히 분리됨
2. 리소스 관리: 레벨별로 다른 메모리/CPU 할당 가능
3. 배포 편의성: 코드 한 번 작성으로 어디서나 실행
4. 버전 관리: 로빙별로 다른 버전 사용 가능

다른 선택지: VM(가상머신) - 너무 무거움, 프로세스 분리 - 보안 취약

마이크로서비스를 선택한 이유

1. 기능 독립성: 각 서비스(스킬)를 독립적으로 개발/배포
2. 확장성: 필요한 기능만 선택적으로 추가
3. 장애 격리: 한 서비스 문제가 전체에 영향 안 줌
4. 언어 독립적: 각 서비스를 다른 언어로 개발 가능

다른 선택지: 모놀리식 - 유지보수 어려움, SOA - 너무 복잡

전체 아키텍처

기본 구조

┌─────────────────────────────────────┐
│         대시보드 서버 (1개)            │
│   ┌─────────────────────────────┐   │
│   │        웹 인터페이스         │   │
│   │   사용자 A 로그인 → A 로빙    │   │
│   │   사용자 B 로그인 → B 로빙    │   │
│   └─────────────────────────────┘   │
│   ┌─────────────────────────────┐   │
│   │          공통 DB            │   │
│   │   users, robings, stats     │   │
│   └─────────────────────────────┘   │
└─────────────────────────────────────┘
                   │
                   │ API 호출
                   ▼
┌─────────────────┐    ┌─────────────────┐
│   로빙 A 컨테이너  │    │   로빙 B 컨테이너  │
│   (2GB 메모리)    │    │   (8GB 메모리)    │
│   스탯: 초보      │    │   스탯: 고급      │
│   스킬: 3개       │    │   스킬: 15개      │
└─────────────────┘    └─────────────────┘

서비스 모델

컨테이너 호스팅 서비스: 사용자가 개인화된 AI 에이전트를 컨테이너 형태로 생성하고 관리하는 서비스

핵심 구성 요소

1. 대시보드 서버 (중앙 집중형)

• 역할: 모든 사용자의 로빙 관리 인터페이스
• 구성: 단일 서버, 단일 DB
• 기능:
  • 사용자 인증 및 세션 관리
  • 로빙 컨테이너 생성/관리
  • 스탯, 레벨, 스킬 설정 UI
  • 성능 모니터링 대시보드

2. 로빙 컨테이너 (개별 격리)

• 역할: 각 사용자의 개인 AI 에이전트
• 특징: 완전 독립적, 사용자별 고유 설정
• 구성:
  • FastAPI 서버 (API를 빠르게 만드는 프레임워크)
  • ChromaDB (의미 기반 검색을 위한 벡터 데이터베이스)
  • 개인 데이터 저장소 (각 로빙의 기억과 경험)

데이터 구조

대시보드 DB (공통)

-- 사용자 정보
users: id, name, email, created_at

-- 로빙 메타데이터
robings: id, user_id, name, level, stats, container_id, status

-- 스킬 및 아이템 설정
skills: id, robing_id, skill_type, config, enabled

-- 성능 통계
performance: id, robing_id, date, tasks_completed, success_rate

로빙 컨테이너 DB (개별)

벡터 DB 구조 (ChromaDB 사용):
- 기억: 대화 내용, 업무 처리 기록 
  → 768차원 벡터로 변환하여 저장 (비슷한 내용 빠르게 찾기)
- 윤리: 판단 기준, 가치관 
  → 의미 공간에서 유사한 상황 검색
- 감정: 상황별 반응 패턴 
  → Inside Out 9개 감정 벡터로 표현
- 경험: 성공/실패 케이스 
  → 학습 데이터로 활용해 더 똑똑해지기

통신 구조

양방향 통신 시스템

대시보드 ←→ 로빙 컨테이너
        ↓         ↑
   스킬/아이템    스탯/레벨
   설정 전달    업데이트

API 엔드포인트 (API = 서비스끼리 대화하는 방법)

대시보드 → 로빙:
- POST /api/config/skills (스킬 설정 전달)
- POST /api/config/stats (스탯 조정)
- GET /api/status (현재 상태 확인)

로빙 → 대시보드:
- POST /dashboard/api/stats (성장 상태 업데이트)
- POST /dashboard/api/performance (작업 성과 보고)
- POST /dashboard/api/events (중요 이벤트 기록)

코드로 보는 구조

# 로빙 컨테이너 생성 코드 (주석 설명 강화)
class RobeingContainer:
    def __init__(self, user_id: str, level: int = 1):
        # 각 로빙은 고유한 Docker 컨테이너를 가짐
        self.container_name = f"robeing_{user_id}"
        
        # 레벨에 따라 리소스 할당이 달라짐
        self.memory_limit = self._calculate_memory(level)
        self.cpu_shares = self._calculate_cpu(level)
        
        # ChromaDB로 벡터 검색 기능 추가
        self.vector_db = ChromaDB(
            collection=f"robeing_{user_id}_memories"
        )
        
    def _calculate_memory(self, level: int) -> str:
        """
        레벨이 높을수록 더 많은 메모리 필요
        - Lv 1-5: 2GB (기본 작업만)
        - Lv 6-10: 4GB (여러 스킬 동시 사용)
        - Lv 11+: 8GB (복잡한 분석 및 학습)
        """
        if level <= 5:
            return "2g"
        elif level <= 10:
            return "4g"
        else:
            return "8g"

로빙 성장 시스템

성장 단계

레벨 1: 🥚 베이스 이미지 (거의 동일)
     ↓
레벨 5: 🐣 스탯 분기 시작
     ↓
레벨 10: 🤖 개별화 완성

등급 시스템 (선택적)

• 노멀: 기본 성장 경로
• 에픽: 특수 스킬 언락
• 레전드: 최고 성능 + 희귀 능력

리소스 할당 (스탯 기반)

초보 로빙: 1CPU, 2GB RAM, 10GB Disk
중급 로빙: 2CPU, 4GB RAM, 20GB Disk  
고급 로빙: 4CPU, 8GB RAM, 50GB Disk

리소스 효율성 관리

수면/각성 시스템

활성 상태: 풀 리소스 컨테이너
     ↓ (비활성 5분 후)
수면 상태: 최소 컨테이너 (128MB 정도)
     ↓ (사용자 접속 시)
각성 과정: 웨이크업 3-5초 대기

침실 시스템 (데이터 보관)

활성 볼륨: /robeing/active/    (현재 작업 중)
수면 볼륨: /robeing/bedroom/   (수면 상태)
백업 볼륨: /robeing/backup/    (백업 저장소)

베드 상태 반성 시스템

반성 프로세스

베드 진입 → 하루 활동 분석
         ↓
    성공/실패 케이스 분류
         ↓
    벡터 DB 재정렬 및 가중치 조정
         ↓
    내일을 위한 행동 패턴 최적화

구체적인 반성 작업

• 기억 정리: 중요한 대화/업무는 강화, 불필요한 것은 압축
• 실수 학습: 오늘 한 실수를 분석해서 다음엔 안 하도록
• 감정 조율: 과도한 반응이나 부적절한 감정 표현 수정
• 스킬 효율성: 어떤 스킬이 효과적이었는지 평가

침실 일기 형태 로그

- 오늘 처리한 업무: 15건
- 성공률: 87%
- 개선 필요 영역: 이메일 톤앤매너
- 내일 집중 포인트: 더 친근한 말투

로빙 성장 사이클

일일 사이클

🌅 각성 → 활동 → 학습 → 🌙 수면 → 반성 → 성장
     ↑                              ↓
     ←←←←←←←←← 개선된 상태로 복귀 ←←←←←←←

장기 성장

• 레벨업: 경험치 축적으로 스탯 향상
• 스킬 습득: 새로운 능력 언락
• 개성 발달: 사용자 상호작용 패턴 학습

구현 고려사항

1. 컨테이너 관리

• 생성: 사용자 로빙 생성 시 Docker API로 컨테이너 생성
• 모니터링: 컨테이너 상태 및 리소스 사용량 추적
• 스케일링: 온디맨드 리소스 할당

2. 보안 및 격리

• 네트워크 격리: 각 컨테이너는 독립적인 네트워크
• 데이터 격리: 로빙 간 데이터 접근 불가
• 리소스 제한: CPU, 메모리 사용량 제한

3. 백업 및 복원

• 정기 백업: 벡터 DB 및 설정 데이터 백업
• 재해 복구: 침실 볼륨에서 데이터 복원
• 마이그레이션: 서버 간 로빙 이전 지원

기대 효과

사용자 경험

• 개인화: 각자만의 고유한 AI 에이전트
• 성장감: 로빙의 발전 과정 관찰
• 애착감: 로빙의 개성과 반성 과정에 대한 관심

기술적 이점

• 확장성: 사용자 증가에 따른 자동 스케일링
• 안정성: 독립적인 컨테이너로 장애 격리
• 효율성: 리소스 사용량 최적화

비즈니스 모델

• 컨테이너 호스팅: 사용 시간 및 리소스 기반 과금
• 프리미엄 기능: 고급 스킬, 더 많은 리소스 제공
• 개인화 서비스: 맞춤형 AI 에이전트 제공

---

문서 작성일: 2025-07-05
작성자: 로빙 개발팀
버전: 1.0
상태: 설계 완료, 구현 준비 중