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

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

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

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

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

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

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

## 전체 아키텍처

### 서버 구성
| 서버 | IP | 역할 | 주요 서비스 |
|------|-----|------|------------|
| 51123 | 192.168.0.100 | 메인 서버 | Gitea, nginx, auth-server, PostgreSQL |
| 51124 | 192.168.219.52 | 로빙/스킬 서버 | rb8001, rb10508_micro, skill-email, ChromaDB |

### 기본 구조
```
┌─────────────────────────────────────┐
│      51123 서버 (메인 서버)           │
│   ┌─────────────────────────────┐   │
│   │    프론트엔드 (3000)         │   │
│   │    Gateway (8100)           │   │  
│   │    auth-server (9000)       │   │
│   │    robeing-monitor (9024)   │   │
│   └─────────────────────────────┘   │
│   ┌─────────────────────────────┐   │
│   │     PostgreSQL (5432)       │   │
│   │   main_db (구 auth_db)      │   │
│   └─────────────────────────────┘   │
└─────────────────────────────────────┘
                   │
                   │ SSH/API 통신
                   ▼
┌─────────────────────────────────────┐
│      51124 서버 (로빙/스킬)           │
│   ┌─────────────────────────────┐   │
│   │    rb8001 (8001)            │   │
│   │    rb10508_micro (10508)    │   │
│   │    skill-email (8501)       │   │
│   │    skill-news (8505)        │   │
│   └─────────────────────────────┘   │
│   ┌─────────────────────────────┐   │
│   │     ChromaDB (8000)         │   │
│   └─────────────────────────────┘   │
└─────────────────────────────────────┘
```

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

## 핵심 구성 요소

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

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

## 데이터 구조

### main_db (PostgreSQL - 51123)
```sql
-- 사용자 정보
users: id(UUID), username, email, name, created_at

-- Gmail 토큰 (아이템)
gmail_token: id, user_id, email, is_equipped, equipped_to

-- Gmail 감사 로그
gmail_audit_logs: id, user_id, robeing_id, action, created_at

-- 로빙 통계
robeing_stats: id, user_id, robeing_id, level, experience

-- 로빙 전용 스키마
robeing.contacts: id, robeing_id, name, email, phone
robeing.conversations: id, robeing_id, user_message, robeing_response
```

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

## 통신 구조

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

### 서비스 포트 매핑

#### 51123 서버 포트
| 포트 | 서비스 | 용도 |
|------|--------|------|
| 3000 | Gitea | Git 저장소 |
| 3001 | frontend-base | 프론트엔드 |
| 8100 | robeing-gateway | API Gateway (프록시) |
| 9000 | auth-server | OAuth 인증 |
| 9024 | robeing-monitor | Gmail 아이템 관리 |
| 5432 | PostgreSQL | main_db |

#### 51124 서버 포트
| 포트 | 서비스 | 용도 |
|------|--------|------|
| 8001 | rb8001 | 프로덕션 로빙 |
| 10508 | rb10508_micro | 테스트 로빙 |
| 10408 | rb10408_test | 개발 로빙 |
| 8501 | skill-email | Gmail 스킬 |
| 8505 | skill-news | 뉴스 스킬 |
| 8000 | ChromaDB | 벡터 DB |

### API 엔드포인트
```
Gateway → 로빙:
- POST /api/robeing/chat (대화 요청)
- POST /api/robeing/email/send (이메일 발송)
- GET /api/items/gmail/status (아이템 상태)

로빙 → Gateway:
- Headers: X-User-Id (UUID)
- POST /api/stats/update (경험치 업데이트)
- POST /api/events/log (이벤트 기록)
```

## 코드로 보는 구조

```python
# 로빙 컨테이너 생성 코드 (주석 설명 강화)
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
```

## Gateway 프록시 패턴

### JWT 인증 및 UUID 변환
```
사용자 요청 (JWT with username)
     ↓
Gateway (8100)
     ├─ JWT 검증 (내부)
     ├─ username → UUID 변환 (DB 조회)
     └─ X-User-Id 헤더 추가
          ↓
백엔드 서비스 (UUID 기반 처리)
```

### UUID 체계
- **일반 사용자**: uuid4() 랜덤 생성
- **Slack 사용자**: 51123 매핑 API를 통해 slack_user_mapping 테이블에서 UUID 조회
- **Namespace**: 6ba7b810-9dad-11d1-80b4-00c04fd430c8

## 리소스 효율성 관리

### 수면/각성 시스템
```
활성 상태: 풀 리소스 컨테이너
     ↓ (비활성 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  
**업데이트**: 2025-08-21  
**작성자**: 로빙 개발팀  
**버전**: 2.0  
**상태**: 구현 중