Add: rb10408 경량화 아키텍처 분석 트러블슈팅

- 메모리 사용량 13배 차이 분석 (55MB vs 745MB)
- State 서비스 미실행으로 인한 메모리 저장 실패 원인 파악
- 마이크로서비스 아키텍처의 장단점 정리
- 해결 방안 제시

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

troubleshooting/250803_claude_rb10408경량화분석.md

@@ -0,0 +1,137 @@
+# 250803 rb10408 경량화 아키텍처 분석 및 문제점
+
+## 배경
+
+### 분석 요청
+- 로컬 개발자가 rb10408과 rb10508의 차이점 분석 요청
+- 메모리 저장 기능이 작동하지 않는 문제 확인
+- 사용자 "이정환"의 대화 내용을 기억하지 못하는 이슈
+
+### 시스템 환경
+- 51124 서버에서 7개 컨테이너 운영 중
+- rb10408: 경량화 라우터 (55.83MB)
+- rb10508: 통합형 로빙 (745.3MB)
+
+## 분석 과정
+
+### 오후 6:30 - 서비스 상태 확인
+두 서비스의 리소스 사용량 비교:
+```
+rb10408: 55.83MiB / 0.19% CPU (7시간 운영)
+rb10508: 745.3MiB / 0.23% CPU (1시간 운영)
+```
+
+메모리 사용량에서 13배 차이 확인.
+
+### 오후 6:35 - 아키텍처 차이 발견
+**rb10408 (경량화)**:
+- 라우터 기반 마이크로서비스 구조
+- 외부 서비스 의존:
+  - LLM 서비스 (8003)
+  - State 서비스 (8002) - 미실행
+  - 스킬 서비스들 (8501, 8505, 8502)
+
+**rb10508 (통합형)**:
+- 모놀리식 구조
+- Gemini CLI 직접 내장
+- ChromaDB 직접 관리
+
+### 오후 6:40 - ChromaDB 저장 실패 원인 파악
+```python
+# rb10408의 메모리 저장 흐름
+라우터 → State 서비스(8002) → ChromaDB
+         ↑
+         문제: State 서비스 미실행
+```
+
+State 서비스가 없어 메모리 저장 불가능 확인.
+
+### 오후 6:45 - 메시지 처리 플로우 분석
+1. Slack 이벤트 수신 (/slack/events)
+2. 3초 내 ACK 응답
+3. Brain으로 의도 분석
+4. 외부 서비스 호출
+5. 결과 통합 및 응답
+
+"답변 생성중입니다..." 메시지는 LLM 서비스(8003)가 직접 전송.
+
+### 오후 7:00 - 서비스 의존성 확인
+실행 중인 컨테이너:
+- rb10408_test (라우터)
+- robing_llm (AI 처리)
+- skill-email
+- skill-slack
+- skill-news
+- rb8001 (독립 실행)
+- rb10508_test (독립 실행)
+
+## 발견된 문제점
+
+### 1. State 서비스 미실행
+- 코드는 `/home/heejae/robing-state-service/`에 존재
+- 포트 8002 미사용
+- 메모리 저장/검색 불가능
+
+### 2. 마이크로서비스 의존성
+- 한 서비스라도 없으면 기능 제한
+- State 서비스 없이는 메모리 기능 전체 불가
+
+### 3. 메모리 검색 제한 (rb10508)
+- "Found 5 memories" - 최근 5개만 검색
+- 오래된 대화 내용 유실
+
+## 장단점 비교
+
+### rb10408 장점
+1. **메모리 효율성**: 55MB (목표 256MB 달성)
+2. **확장성**: 서비스별 독립 스케일링
+3. **모듈화**: 명확한 책임 분리
+4. **장애 격리**: 부분 장애 시 전체 영향 최소화
+
+### rb10408 단점
+1. **복잡도**: 여러 서비스 관리 필요
+2. **의존성**: State 서비스 없이 작동 불가
+3. **네트워크 오버헤드**: 서비스 간 HTTP 통신
+
+## 결과
+
+### 메모리 효율성
+- rb10408이 13배 더 효율적 (55MB vs 745MB)
+- 동일 서버에서 더 많은 인스턴스 운영 가능
+
+### 안정성
+- 마이크로서비스 구조로 부분 장애 대응 가능
+- 단, 핵심 서비스(State) 없으면 기능 제한
+
+### 운영 편의성
+- rb10508: 단순하지만 리소스 많이 사용
+- rb10408: 효율적이지만 복잡한 운영
+
+## 해결 방안
+
+1. **즉시 조치**: State 서비스 실행
+   ```bash
+   cd /home/heejae/robing-state-service
+   docker-compose up -d
+   ```
+
+2. **중기 개선**: 
+   - State 서비스를 라우터에 통합 고려
+   - 또는 필수 서비스 헬스체크 강화
+
+3. **장기 전략**:
+   - 핵심 기능은 내장, 부가 기능만 외부화
+   - 하이브리드 아키텍처 검토
+
+## 교훈
+
+1. **경량화와 기능성의 균형**: 너무 많이 분리하면 의존성 문제 발생
+2. **필수 서비스 모니터링**: State 같은 핵심 서비스는 자동 실행 필요
+3. **문서화 중요성**: 서비스 의존성 명확히 문서화
+4. **테스트 환경**: 전체 서비스 통합 테스트 필요
+
+---
+
+작성일: 2025-08-03 18:30 - 19:00
+작성자: Claude (51124 서버)
+주제: rb10408 경량화 아키텍처의 장단점 및 메모리 저장 실패 원인