# 프론트엔드 재설계, auth-server 구축 및 rb8001 배포 복구

**날짜**: 2025-07-29  
**작업자**: happybell80 & Claude  
**관련 프로젝트**: frontend-customer, 로빙 GUI 공유 시스템

## 오후 6시 7분

### 세션 시작 문제

Claude가 세션 시작 시 규칙을 제대로 따르지 않음. CLAUDE.md 재확인 후 규칙 준수.

**교훈**: 
- 세션 시작 시 항상 CLAUDE.md 규칙 재확인 필요
- 간결한 응답 원칙 준수

## 오후 6시 30분  

### 프론트엔드 커스터머 대대적 개편 계획

**목표**: 
- 기존 React 기반 frontend-customer를 모바일 게임 UI처럼 개편
- Merge Restaurant 스타일의 인터페이스 적용

**현재 상태 분석**:
1. 프로젝트 구조
   - React 18 + TypeScript + Vite
   - Tailwind CSS + shadcn/ui
   - 2가지 뷰 모드: 관리 대시보드, 캐릭터 대시보드

2. 발견된 문제
   - @shared/schema import 존재하지만 실제 파일 없음
   - 이미지 경로 하드코딩
   - API URL 환경변수 미사용

**DOCS 문서 검토**:
- PERSONOS 프로토콜: 감정 공명, 상호기억 시스템
- 외부도구 아이템화 방안
- PRD: 3개월 MVP 계획

## 오후 7시 00분

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

**핵심 개념**: 로빙이 컨테이너에서 실행하는 모든 GUI를 사용자가 웹으로 볼 수 있게 함

**기술 스택**:
1. VNC/noVNC 방식 (선택)
   - Xvfb + x11vnc + noVNC
   - Slack 인증 불필요
   - 리소스: 300MB~1GB

2. 레벨별 단계적 해금
   - Lv.1-4: 스크린샷 (300-400MB)
   - Lv.5-9: 반응형 스크린샷
   - Lv.10-14: 영상 스트리밍 (500-700MB)
   - Lv.15-19: 읽기 전용 VNC (800MB-1GB)
   - Lv.20: 완전 제어 VNC (1GB+)

**리소스 최적화**:
- qutebrowser, surf 등 경량 브라우저 사용
- 세션 수명 제한
- 독립 스킬 컨테이너 분리

## 오후 7시 20분

### SaaS에서 독립 GUI로의 확장 전략

**철학**: 초기에는 SaaS API만 사용하다가 레벨업하면서 독립 GUI 도구 해금

**단계별 확장**:
- Lv.1-4: Gmail, Notion API
- Lv.5-9: Google Docs, Figma API
- Lv.10-14: Playwright로 SaaS 화면 공유
- Lv.15-19: PDF 리더, 로그 뷰어 등 독립 앱
- Lv.20: LibreOffice, 터미널 도구

**GUI 프레임 최적화**:
- 창 관리자 없이 Xvfb 직접 실행
- xdotool로 불필요한 UI 제거
- 이미지 크롭으로 콘텐츠만 추출

## 오후 7시 30분

### 웹 인터페이스 3분할 설계

**데스크톱**: GUI 화면 | 채팅창 | 상태창 (가로 3분할)
**모바일**: 슬라이드 전환 방식

**기술 스택 비교**:
1. React 기반 (권장)
   - 게임풍 UI 구현 용이
   - Framer Motion, Lottie 활용
   
2. Rails 기반
   - 빠른 개발 가능
   - GUI 스트리밍과 통합 어려움
   - 복잡한 UI 표현 한계

**결론**: React + 애니메이션 라이브러리로 게임 스타일 UI 구현

## 교훈

1. **GUI 공유는 리소스와 신뢰의 트레이드오프**
   - 레벨이 낮을 때는 최소한의 리소스로 관찰만
   - 신뢰가 쌓이면 더 많은 리소스를 투자해 제어 권한 부여

2. **SaaS 우선, GUI는 보조**
   - 대부분의 작업은 API로 해결 가능
   - GUI 공유는 투명성과 신뢰 구축용

3. **기술 스택은 목적에 맞게**
   - 게임풍 UI가 목표라면 React가 Rails보다 적합
   - 하지만 핵심 기능은 기존 스택 유지 가능

4. **점진적 확장이 핵심**
   - 한번에 모든 기능을 구현하지 말고 레벨별로 해금
   - 리소스 사용량도 점진적으로 증가

## 오후 8시 00분

### 서버 구조 변경 및 auth-server 설정 수정

**서버팀 메시지 내용**:
- 51123 서버: nginx, Gitea, frontend-base, auth-server, PostgreSQL
- 51124 서버: 로빙 서비스들, 스킬 서비스들, ChromaDB
- PostgreSQL은 51123 서버 호스트에서 실행 중
- auth-server Docker 컨테이너가 호스트 PostgreSQL 연결 불가 문제

**해결 작업**:
1. auth-server의 docker-compose.yml 수정
   - DATABASE_URL 기본값을 `host.docker.internal` 사용하도록 변경
   - 이미 extra_hosts 설정은 있었음

2. 서버 아키텍처 문서 업데이트
   - server-architecture.md에 변경된 서버 구조 반영
   - auth-server와 PostgreSQL이 51123에 추가된 것 문서화

**실수 및 교훈**:
- Git 작업 시 디렉토리 구조 실수 반복
  - ivada는 git 저장소가 아님, 각 하위 폴더가 개별 저장소
  - cd 명령 전 현재 위치 확인 필수
- CLAUDE.md에 디렉토리 구조 주의사항 추가함

## 오후 8시 10분

### 51123 서버 서비스 정리 및 auth-server 실행

**서버 관리 작업** (admin@51123):

1. **서비스 이전 작업**:
   - 51123에서 실행 중이던 서비스들 중지 및 제거:
     - skill-email → 51124로 이전
     - rb8001 → 51124로 이전  
     - hj_rb10408_test → 51124로 이전
   - Docker 이미지도 정리 완료

2. **auth-server 실행 문제 해결**:
   - 문제: Docker 컨테이너에서 localhost가 호스트 PostgreSQL에 연결 불가
   - 원인: 컨테이너 내부의 localhost는 컨테이너 자신을 가리킴
   - 해결 과정:
     - docker-compose.yml에 host.docker.internal 설정 추가 (로컬 개발자 수행)
     - .env 파일의 DATABASE_URL도 host.docker.internal로 수정 (서버에서 직접 수정)
   - 결과: auth-server 포트 9000에서 정상 실행 중

3. **최종 51123 서버 상태**:
   - nginx (80/443) ✅
   - Gitea (3000) ✅
   - frontend-base (8000) ✅
   - auth-server (9000) ✅
   - PostgreSQL (5432) ✅
   - Actions Runner ✅

**교훈**:
- Docker 네트워킹: 컨테이너에서 호스트 서비스 접근 시 localhost 대신 host.docker.internal 사용
- .env 파일은 gitignore에 있어 서버에서 직접 수정 필요
- PostgreSQL은 이미 호스트에서 실행 중이므로 컨테이너 추가 불필요

## 오후 9시 00분

### auth-server 심층 분석 및 문서화

**배경**: auth-server의 상태와 데이터베이스 스키마를 체계적으로 분석하고 전체 아키텍처 문서에 반영

**작업 내용**:

1. **auth-server 운영 상태 검토**:
   - 컨테이너 정상 실행 확인 (포트 9000, healthy 상태)
   - nginx를 통한 https://auth.ro-being.com 프록시 설정 확인
   - JWT/OAuth 키 관리 상태 점검

2. **PostgreSQL main_db 스키마 분석**:
   - `company` 테이블: 회사별 서브도메인 관리 (2개 회사 등록)
   - `slack_workspaces` 테이블: Slack 봇 토큰 관리 (2개 워크스페이스 활성)
   - 멀티테넌트 B2B SaaS 구조 확인

3. **문서화 작업**:
   - `auth-server-database-schema.md` 신규 생성
   - `00_아키텍쳐.md`에 auth-server 섹션 추가
   - `로빙_아키텍쳐_설계_경량.md` 인증 관련 섹션 업데이트
   - 중복 내용 제거하고 링크 연결 방식 적용

**핵심 발견사항**:
- auth-server는 개별 사용자 인증이 아닌 **회사별 Slack 봇 관리** 특화 시스템
- 사용자 테이블 없이 JWT/세션 기반으로 인증 처리
- OAuth 토큰은 파일 시스템에 저장하여 다른 로빙 서비스와 공유
- 로빙 프로젝트 특성상 토큰 공유가 필수적인 구조

**실수 교정**:
- 일반적인 보안 가이드(chmod 600) 제안했지만, 로빙 서비스간 토큰 공유 필요성 간과
- CLAUDE.md에 "프로젝트 맥락 고려 필수" 규칙 추가하여 재발 방지

**최종 결과**:
- auth-server 완전 문서화 및 아키텍처 문서 통합 완료
- 로빙 생태계에서 auth-server 역할 명확화
- 멀티테넌트 B2B 인증 허브로서의 정체성 확립

## 오후 9시 45분

### rb8001 서비스 중지 문제 해결

**배경**: 24 서버팀으로부터 rb8001 서비스가 중지 상태라는 보고 접수

**문제 진단 과정**:

1. **초기 진단**:
   - rb8001 컨테이너 실행되지 않음
   - 8001 포트 사용 없음
   - 로그 API에서 빈 결과 반환

2. **코드 검토 및 수정**:
   - `docker-compose.yml`: rb10508_micro와 동일한 구조로 수정
     - `network_mode: host` 적용
     - `SKILL_EMAIL_URL` 환경변수 추가
     - logs 볼륨 마운트 방식 통일
   - `requirements.txt` 최적화: `sentence-transformers`, `torch` 제거 (1GB+ 절약)
   - `JWT_SECRET_KEY` 실제 값으로 업데이트
   - Gitea Actions를 51124 서버 SSH 배포 방식으로 변경

3. **Sequential Thinking을 통한 정확한 문제 진단**:
   - 초기에는 docker-compose 버전 문제로 추정
   - 실제 문제는 **LOG_LEVEL 대소문자 문제**로 판명
   - `LOG_LEVEL=INFO` (대문자) → uvicorn이 소문자 요구
   - `KeyError: 'INFO'` 오류 발생

**해결 작업**:

1. **코드 수정**:
   - `run.py`: `log_level=get_env("LOG_LEVEL", "info").lower()` 추가
   - `.env`: `LOG_LEVEL=INFO` → `LOG_LEVEL=info` 변경

2. **배포 완료**:
   - git push → Gitea Actions 자동 실행
   - 51124 서버에 정상 배포 완료

**최종 결과**:
- ✅ rb8001 컨테이너: Up (healthy)
- ✅ uvicorn 정상 실행
- ✅ health check: `{"status":"healthy"}`
- ✅ nginx 프록시: `https://ro-being.com/rb8001/health` 정상 응답
- ✅ 포트 8001 정상 서비스

**교훈**:

1. **Sequential Thinking의 중요성**:
   - 초기 추정과 실제 문제가 다를 수 있음
   - 체계적 분석을 통해 정확한 원인 파악 필요

2. **환경변수 대소문자 주의**:
   - uvicorn LOG_LEVEL은 소문자만 허용
   - 방어적 프로그래밍으로 `.lower()` 적용 권장

3. **rb10508_micro와 rb8001 구조 통일**:
   - 성공한 설정을 다른 서비스에 적용하는 것이 효과적
   - docker-compose.yml, requirements.txt 일관성 중요

4. **배포 파이프라인 검증**:
   - 코드 수정 → git push → Actions → 배포 → 서비스 확인까지 전체 플로우 점검 필요

---
**작성 완료**: 2025-07-29 21:45