DOCS/ideas/250807_서비스_재구조화_계획.md

서비스 재구조화 계획 - API 게이트웨이 및 모니터링 분리

작성일: 2025-08-07
작성자: happybell80 & Claude
상태: 계획 단계

현재 문제점

1. 복잡한 연결 구조

• frontend-customer와 로빙 직접 연결 부재
• /api/assistant/{id} 엔드포인트 미구현
• 어떤 사용자가 어떤 로빙과 연결되는지 결정 로직 없음

2. 인증 흐름 불완전

• auth-server에서 인증 → frontend로 토큰 전달 경로 없음
• 로빙이 사용자 인증 정보 받는 방법 없음
• OAuth 콜백 후 frontend로 돌아가는 로직 부재

3. 데이터베이스 분산

• PostgreSQL (auth-server) - users, workspaces
• ChromaDB (51124) - 벡터 메모리
• SQLite (각 로빙) - 로컬 데이터
• user_id 동기화 문제

4. 서비스 역할 혼재

• frontend-base가 admin UI + 백엔드 역할 혼재
• 모니터링과 라우팅이 분리되지 않음

현재 서버 구조

51123 서버 (메인 서버)

├── frontend-customer (https://ro-being.com/)
│   └── React 정적 파일, nginx 직접 서빙
├── frontend-base:8000 (https://ro-being.com/admin)
│   └── 관리자 대시보드 + 백엔드
├── auth-server (https://auth.ro-being.com)
│   └── OAuth 인증, PostgreSQL DB
└── nginx (리버스 프록시, SSL)

51124 서버 (로빙/스킬 서버)

├── 로빙 컨테이너
│   ├── rb8001:8001 (프로덕션)
│   ├── rb10508_test:10508 (테스트)
│   └── rb10408_test:10408 (테스트)
├── 스킬 서비스
│   ├── skill-email:8501
│   ├── skill-news:8502
│   └── skill-embedding:8015
└── ChromaDB (벡터 DB)

제안하는 새 구조

1단계: 서비스 분리

robing-gateway (구 frontend-base 일부)

• 위치: 51123 서버
• 포트: 8000 (기존 유지)
• 역할:
  • API 게이트웨이 (사용자 요청 → 로빙 라우팅)
  • 인증 체크 (auth-server 연동)
  • 사용자-로빙 매핑 (메모리 캐시)
  • 캐시 관리: 로그인 시 추가, 로그아웃 시 제거

robing-control (구 frontend-base 일부)

• 위치: 51123 서버
• 포트: 9023
• 역할:
  • 전체 시스템 모니터링 통합
  • admin 대시보드 UI 제공
  • 23서버 프로세스 직접 체크
  • 24서버 상태는 API로 조회
  • 향후 간단한 관제 기능 추가 가능

robing-monitor (신규)

• 위치: 51124 서버
• 포트: 9024
• 역할:
  • 24서버 로컬 모니터링
  • 로빙 상태 체크
  • 스킬 서비스 상태
  • 리소스 사용량 수집
  • API로 정보 제공

2단계: 인증 흐름 개선

sequenceDiagram
    participant U as User
    participant F as Frontend
    participant G as Gateway
    participant A as Auth
    participant R as Robing

    U->>F: 로그인 클릭
    F->>G: /api/auth/login
    G->>A: OAuth 시작
    A->>U: Google OAuth
    U->>A: 인증 완료
    A->>G: 토큰 + user_id
    G->>F: 로그인 성공 (user_id)
    F->>U: 로그인 완료
    
    U->>F: 채팅 입력
    F->>G: /api/chat (user_id 포함)
    Note over G: 메모리 캐시 확인<br/>없으면 DB 조회 후 캐싱
    G->>R: 프록시 (port 8001)
    R->>G: 응답
    G->>F: 응답
    F->>U: 표시

수정된 흐름 설명:

1. 로그인 완료 후 Frontend는 user_id만 알면 됨
2. 모든 API 요청에 user_id 포함 (JWT 토큰 또는 헤더)
3. Gateway가 메모리 캐시 확인 (대부분 여기서 처리)
   • 캐시 hit: 즉시 라우팅
   • 캐시 miss: DB 조회 후 캐싱
4. Gateway가 적절한 로빙으로 프록시
5. Frontend는 로빙 포트를 전혀 알 필요 없음

3단계: 데이터베이스 통합

단기 계획

• auth-server PostgreSQL을 메인 DB로 사용
• user_id를 모든 서비스에서 통일
• user_id → robing_port 매핑 테이블 관리

장기 계획

• 로빙별 SQLite → PostgreSQL 마이그레이션
• 중앙 집중식 데이터 관리

4단계: API 설계

robing-gateway API

POST /api/auth/login        # 로그인 시작
GET  /api/auth/callback     # OAuth 콜백
POST /api/auth/logout       # 로그아웃
GET  /api/auth/status       # 인증 상태

POST /api/chat              # 채팅 (자동 라우팅)
GET  /api/robing/info       # 할당된 로빙 정보

robing-control API

GET  /admin                 # 대시보드 UI
GET  /api/monitor/overview  # 전체 시스템 상태
GET  /api/monitor/23        # 23서버 상태
GET  /api/monitor/24        # 24서버 상태 (robing-monitor 호출)
POST /api/control/restart   # 서비스 재시작 (향후)

robing-monitor API

GET  /api/status/robings    # 로빙 상태
GET  /api/status/skills     # 스킬 상태  
GET  /api/status/resources  # 리소스 사용량
GET  /api/health            # 헬스체크

구현 우선순위

Phase 1

1. robing-gateway 기본 구조 생성
2. 인증 흐름 연결
3. 단순 라우팅 (모든 사용자 → rb10508_test)

Phase 2

1. robing-monitor 구현
2. robing-control 분리
3. 모니터링 대시보드 연결

Phase 3

1. 사용자-로빙 매핑 로직
2. 워크스페이스 기반 할당
3. 로빙 포트 자동 할당

Phase 4 (선택)

1. 간단한 관제 기능
2. DB 통합
3. 성능 최적화

기대 효과

1. 명확한 책임 분리

   • 각 서비스가 단일 역할만 수행
   • 유지보수 용이

2. 독립적 배포

   • 서비스별 독립 배포 가능
   • 장애 격리

3. 확장성

   • 로빙 추가 시 gateway만 수정
   • 모니터링 기능 점진적 확장

4. 보안 강화

   • 중앙 집중식 인증
   • 로빙 직접 접근 차단

리스크 및 대응

1. 개발 복잡도

   • 리스크: 서비스 분리로 인한 복잡도
   • 대응: Phase별 점진적 구현

2. 기존 서비스 중단

   • 리스크: 마이그레이션 중 서비스 중단
   • 대응: 병렬 운영 후 전환

3. 복잡도 증가

   • 리스크: 서비스 개수 증가
   • 대응: 명확한 문서화, 자동화 도구

다음 단계

1. 팀 리뷰 및 승인
2. 상세 API 스펙 작성
3. 개발 환경 구성
4. Phase 1 구현 시작

---

참고사항

• 이 계획은 초안이며, 구현 과정에서 수정될 수 있음
• 기존 frontend-base의 코드를 최대한 재활용
• 서버팀과 사전 협의 필요 (포트, 도메인 등)