happybell80
0252dd1a7f
192.168.219.45 → 192.168.0.100 일괄 변경 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
12 KiB
12 KiB
로빙 컨테이너 아키텍처 설계
개요
로빙 AI 에이전트는 사용자별로 독립적인 Docker 컨테이너(각 로빙의 '집')에서 실행되며, 중앙 대시보드를 통해 관리됩니다. 각 로빙은 개별적인 성장 경로를 가지며, 효율적인 리소스 관리와 데이터 안전성을 보장합니다.
왜 컨테이너와 마이크로서비스인가?
컨테이너(Docker)를 선택한 이유
- 격리와 보안: 각 로빙의 데이터와 처리 과정이 완전히 분리됨
- 리소스 관리: 레벨별로 다른 메모리/CPU 할당 가능
- 배포 편의성: 코드 한 번 작성으로 어디서나 실행
- 버전 관리: 로빙별로 다른 버전 사용 가능
다른 선택지: VM(가상머신) - 너무 무거움, 프로세스 분리 - 보안 취약
마이크로서비스를 선택한 이유
- 기능 독립성: 각 서비스(스킬)를 독립적으로 개발/배포
- 확장성: 필요한 기능만 선택적으로 추가
- 장애 격리: 한 서비스 문제가 전체에 영향 안 줌
- 언어 독립적: 각 서비스를 다른 언어로 개발 가능
다른 선택지: 모놀리식 - 유지보수 어려움, 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)
-- 사용자 정보
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 (이벤트 기록)
코드로 보는 구조
# 로빙 컨테이너 생성 코드 (주석 설명 강화)
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
상태: 구현 중