diff --git a/00_프로젝트_종합_v2.md b/00_프로젝트_종합_v2.md
index 3c2e8f4..8cdb00b 100644
--- a/00_프로젝트_종합_v2.md
+++ b/00_프로젝트_종합_v2.md
@@ -207,6 +207,7 @@ LV.3 (매니저) → 간단한 응대 자동화
### 아키텍처
- [컨테이너 아키텍처 설계](./docs/architecture/로빙_컨테이너_아키텍처_설계.md)
- [마이크로서비스 설계](./docs/architecture/skillhub_architecture.md)
+- [프론트엔드 GUI 공유 아키텍처](./docs/architecture/250729_프론트엔드GUI공유아키텍처.md)
### 철학 및 개념
- [AI Agent 차별화 방안](./docs/philosophy/AI agent 차별화 방안 제안.md)
@@ -217,10 +218,11 @@ LV.3 (매니저) → 간단한 응대 자동화
- [스탯 성장 설계](./docs/philosophy/robeing_stats_growth_design.md)
### 트러블슈팅
-- [최신 이슈 및 해결](./docs/troubleshooting/)
+- [최신 이슈 및 해결](./troubleshooting/)
---
**문서 생성일**: 2025-07-01
-**최종 업데이트**: 2025-07-21
-**버전**: 2.0 (아키텍처 현실화, 마이크로서비스 전환 반영)
\ No newline at end of file
+**최종 업데이트**: 2025-07-29
+**버전**: 2.1
+**수정 내용**: 관련 문서 링크 업데이트 (GUI 공유 아키텍처 추가, 트러블슈팅 경로 수정)
\ No newline at end of file
diff --git a/docs/architecture/00_아키텍쳐.md b/docs/architecture/00_아키텍쳐.md
index f8291c2..16f54a4 100755
--- a/docs/architecture/00_아키텍쳐.md
+++ b/docs/architecture/00_아키텍쳐.md
@@ -87,14 +87,14 @@ API 키 관리의 복잡성과 보안 리스크를 해결하기 위해, OAuth와
- **중앙화된 관리**: 모든 API 사용량과 과금 내역을 단일 대시보드에서 투명하게 관리하고 통제할 수 있습니다.
- **법적 준수**: API 제공사의 서비스 약관(TOS)을 준수하는 '사용자를 대신한 안전한 호출 대행' 모델을 지향하여 신뢰성을 확보합니다.
-## 5. UI/UX 아키텍처: 정보의 연결성과 사용자 맞춤 경험
+## 5. UI/UX 아키텍처: 게임형 인터페이스와 GUI 공유 시스템
-프론트엔드는 단순히 정보를 보여주는 것을 넘어, 사용자가 데이터와 상호작용하며 인사이트를 발견하는 경험을 제공하는 것을 목표로 합니다. 옵시디언(Obsidian)의 장점을 벤치마킹하여 다음과 같은 아키텍처를 구성합니다.
+프론트엔드는 모바일 게임 스타일의 직관적이고 재미있는 인터페이스를 통해 로빙과의 상호작용을 극대화합니다.
-- **정보의 연결성 시각화**: 스타트업, 투자자, 기술, 뉴스 등 다양한 정보 개체 간의 연결을 보여주는 **그래프 뷰**(Graph View)를 핵심 기능으로 제공합니다. 이를 위해 D3.js, React Flow, Vis.js 등의 라이브러리를 활용합니다.
-- **유연한 레이아웃**: 사용자가 드래그 앤 드롭으로 자신만의 대시보드를 구성할 수 있도록 **모듈화된 UI 컴포넌트**로 설계합니다.
-- **강력한 검색 및 질의**: AI 에이전트와 직접 대화하는 **채팅 인터페이스**와 함께, Dataview 플러그인처럼 메타데이터 기반의 정교한 데이터 질의가 가능한 인터페이스를 제공합니다.
-- **확장성**: 장기적으로 커뮤니티가 직접 기능을 추가하거나 테마를 변경할 수 있는 **플러그인 아키텍처**의 기반을 마련합니다.
+- **게임 스타일 UI**: React 18 + TypeScript + Vite 기반으로 Merge Restaurant 같은 모바일 게임 UI를 구현합니다. Framer Motion과 Lottie를 활용한 풍부한 애니메이션으로 재미있는 경험을 제공합니다.
+- **캐릭터 대시보드**: 로빙의 레벨, 스탯(기억/연산/반응/공감/통솔), 감정 상태, 스킬 목록을 시각적으로 표현합니다. 레벨업 시 화려한 이펙트와 보상 애니메이션을 제공합니다.
+- **3분할 레이아웃**: 데스크톱에서는 GUI 화면 | 채팅창 | 상태창의 3분할 구조를, 모바일에서는 슬라이드 전환 방식을 채택하여 효율적인 정보 표시를 구현합니다.
+- **GUI 공유 시스템**: 로빙이 컨테이너에서 실행하는 GUI 애플리케이션을 사용자에게 단계적으로 공유합니다 (Lv.1-4 스크린샷 → Lv.5-9 반응형 스크린샷 → Lv.10-14 영상 → Lv.15-19 읽기 전용 VNC → Lv.20 완전 제어).
## 6. 기억 관리 아키텍처: 다학문적 통합 프레임워크
@@ -125,3 +125,8 @@ API 키 관리의 복잡성과 보안 리스크를 해결하기 위해, OAuth와
+## 7. 부록
+
+---
+**최종 수정**: 2025-07-29
+**수정 내용**: UI/UX 아키텍처 섹션을 현재 프로젝트 방향(게임 스타일 UI, GUI 공유 시스템)에 맞게 업데이트
diff --git a/docs/architecture/250729_프론트엔드GUI공유아키텍처.md b/docs/architecture/250729_프론트엔드GUI공유아키텍처.md
new file mode 100644
index 0000000..a8f73b2
--- /dev/null
+++ b/docs/architecture/250729_프론트엔드GUI공유아키텍처.md
@@ -0,0 +1,165 @@
+# 프론트엔드 GUI 공유 아키텍처
+
+## 개요
+로빙이 컨테이너 내부에서 실행하는 GUI 애플리케이션을 외부 사용자에게 단계적으로 공유하는 아키텍처. 레벨 기반 권한 시스템과 연동하여 스크린샷부터 완전 제어까지 점진적으로 기능을 해금한다.
+
+## 1. GUI 공유 기술 스택
+
+### 1.1 기본 구성
+- **Xvfb**: 가상 디스플레이 서버 (GUI 애플리케이션 실행 환경)
+- **x11vnc**: VNC 서버 (Xvfb 화면을 스트리밍)
+- **noVNC**: HTML5 기반 VNC 뷰어 (웹 브라우저에서 접속 가능)
+- **websockify**: WebSocket-TCP 프록시 (noVNC 연결용)
+
+### 1.2 전체 흐름
+```
+[로빙 컨테이너 내부]
+ ├─ GUI 앱 (브라우저, 로그뷰어, Office 등)
+ ├─ Xvfb (가상 디스플레이)
+ ├─ x11vnc (VNC 스트리밍)
+ └─ noVNC (웹소켓 서버)
+
+[외부 사용자]
+ └─ 웹 브라우저 → https://ro-being.com/view-session/abc123
+```
+
+## 2. 레벨별 단계적 해금 시스템
+
+| 레벨 | 기능 | 구현 방식 | 리소스 사용량 |
+|------|------|-----------|---------------|
+| Lv.1~4 | 정적 스크린샷 | page.screenshot() → Slack DM | 300-400MB |
+| Lv.5~9 | 반응형 스크린샷 | 버튼 클릭시 새 이미지 | 300-400MB |
+| Lv.10~14 | 저프레임 영상 | page.video() + ffmpeg | 500-700MB |
+| Lv.15~19 | 읽기 전용 VNC | noVNC 뷰어 (조작 불가) | 800MB-1GB |
+| Lv.20 | 완전 제어 | VNC + 마우스/키보드 허용 | 1GB+ |
+
+### 2.1 플래그 기반 스킬 관리
+```json
+{
+ "gui_share": {
+ "level_required": 1,
+ "mode": "screenshot",
+ "upgrade_path": [
+ { "level": 5, "mode": "interactive_screenshot" },
+ { "level": 10, "mode": "video_stream" },
+ { "level": 15, "mode": "vnc_readonly" },
+ { "level": 20, "mode": "vnc_control" }
+ ]
+ }
+}
+```
+
+## 3. 리소스 최적화 전략
+
+### 3.1 경량 브라우저 대안
+- **qutebrowser**: Qt 기반 초경량 브라우저 (150-300MB)
+- **surf**: suckless 계열 최소 브라우저 (100MB 미만)
+- **headless-chromium**: 스크린샷/영상만 필요시 (100MB)
+
+### 3.2 컨테이너 의존성 관리
+| 목적 | 필수 패키지 | 용량 |
+|------|-------------|------|
+| 스크린샷 | playwright, libx11, fonts | 300-500MB |
+| 영상 스트리밍 | + ffmpeg, webm tools | +200MB |
+| VNC 공유 | + Xvfb, x11vnc, noVNC | +300MB |
+| GUI 제어 도구 | + xdotool, wmctrl | +50MB |
+
+### 3.3 최적화 방안
+- 세션 수명 제한 (5-10분)
+- 독립 스킬 컨테이너 분리 (skill-gui-viewer)
+- 멀티 스테이지 빌드
+- idle 상태시 리소스 해제
+
+## 4. SaaS에서 독립 GUI로의 확장
+
+### 4.1 단계별 도구 확장
+| 레벨 | 도구 유형 | 예시 |
+|------|-----------|------|
+| Lv.1~4 | SaaS API | Gmail, Notion, Slack |
+| Lv.5~9 | SaaS 웹 UI | Google Docs, Figma |
+| Lv.10~14 | 브라우저 자동화 | Playwright로 SaaS 조작 |
+| Lv.15~19 | 독립 GUI 앱 | PDF 리더, 로그 뷰어 |
+| Lv.20 | 복잡한 도구 | LibreOffice, 터미널 도구 |
+
+### 4.2 GUI 프레임 최적화
+- 창 관리자 없이 Xvfb 직접 실행
+- xdotool로 불필요한 UI 요소 숨김
+- 이미지 크롭으로 콘텐츠 영역만 추출
+
+## 5. 사용자 인터페이스 설계
+
+### 5.1 웹 인터페이스 구성 (3분할)
+```
+┌─────────────┬─────────────┬─────────────┐
+│ GUI 화면 │ 채팅창 │ 상태창 │
+│ (공유 화면) │ (대화 기록) │ (스탯/레벨) │
+└─────────────┴─────────────┴─────────────┘
+```
+
+### 5.2 모바일 대응
+- 슬라이드 전환 방식 (스와이프 제스처)
+- CSS scroll-snap 또는 React 캐러셀
+- 반응형 레이아웃 자동 전환
+
+### 5.3 기술 스택 옵션
+
+#### React 기반 (권장)
+- **장점**: 컴포넌트 기반, 상태 관리 용이, 생태계 풍부
+- **UI 라이브러리**: Framer Motion, Lottie, Three.js
+- **게임풍 UI**: CSS 애니메이션 + Canvas 활용
+
+#### Rails 기반
+- **장점**: 빠른 개발, Hotwire로 실시간 업데이트
+- **단점**: GUI 스트리밍과 느슨한 통합, 복잡한 UI 표현 한계
+- **구현**: iframe으로 VNC 임베드, Turbo Streams로 상태 갱신
+
+## 6. 보안 및 접근 제어
+
+### 6.1 인증 방식
+- 일회용 토큰 + 만료 시간 (10분)
+- UUID 기반 비공개 URL
+- Slack DM으로만 URL 전달
+
+### 6.2 권한 관리
+- 레벨 기반 기능 제한
+- 읽기 전용 vs 완전 제어 구분
+- 세션별 격리 (컨테이너 분리)
+
+## 7. 구현 로드맵
+
+### Phase 1: 기본 스크린샷 공유 (Lv.1~4)
+- Playwright headless 스크린샷
+- Slack DM 이미지 전송
+- 주기적 캡처 (3-5초)
+
+### Phase 2: 영상 스트리밍 (Lv.10~14)
+- ffmpeg 기반 인코딩
+- HLS 또는 WebM 스트리밍
+- 1-2fps 저프레임 영상
+
+### Phase 3: VNC 기반 실시간 공유 (Lv.15~20)
+- Xvfb + x11vnc 구성
+- noVNC 웹 뷰어 통합
+- 단계적 조작 권한 부여
+
+## 8. 예상 과제 및 해결 방안
+
+### 8.1 리소스 관리
+- **문제**: 멀티 세션시 메모리/CPU 급증
+- **해결**: 세션 제한, 타임아웃, 독립 컨테이너
+
+### 8.2 네트워크 지연
+- **문제**: VNC 스트리밍 딜레이
+- **해결**: 압축 설정, 지역별 엣지 서버
+
+### 8.3 모바일 최적화
+- **문제**: 작은 화면에서 GUI 가독성
+- **해결**: 반응형 줌, 주요 영역 포커싱
+
+## 9. 결론
+로빙의 GUI 공유 시스템은 신뢰 기반 점진적 권한 확대를 통해 단순 관찰에서 완전 제어까지 발전한다. 기술적으로는 Xvfb/VNC/noVNC 조합으로 구현 가능하며, 레벨 시스템과 연동하여 자원 효율성과 보안을 동시에 달성할 수 있다.
+
+---
+**작성일**: 2025-07-29
+**작성자**: happybell80 & Claude
+**문서 유형**: 아키텍처 설계
\ No newline at end of file
diff --git a/docs/architecture/server-architecture.md b/docs/architecture/server-architecture.md
index 799bdc9..8545fca 100644
--- a/docs/architecture/server-architecture.md
+++ b/docs/architecture/server-architecture.md
@@ -14,6 +14,11 @@
│ │ (80/443) │ │ (3000) │ │ (8000) │ │
│ └─────┬───────┘ └──────┬───────┘ └───────────────┘ │
│ │ │ │
+│ ┌─────────────┐ ┌──────────────┐ │
+│ │ auth-server │ │ PostgreSQL │ │
+│ │ (9000) │ │ (5432) │ │
+│ └─────────────┘ └──────────────┘ │
+│ │ │ │
│ │ ┌───────┴──────┐ ┌──────────────┐ │
│ │ │ Actions │ │ Log Storage │ │
│ │ │ Runner │ │/mnt/hdd/logs │ │
@@ -36,10 +41,7 @@
│ │ (8501) │ │ (8505) │ │ (8000) │ │
│ └─────────────┘ └─────────────┘ └──────────────┘ │
│ │
-│ ┌────────────────────────────────────────────────┐ │
-│ │ PostgreSQL Database │ │
-│ │ (5432) │ │
-│ └────────────────────────────────────────────────┘ │
+│ │
└─────────────────────────────────────────────────────────┘
```
@@ -51,6 +53,8 @@
| nginx | 80/443 | ro-being.com | 리버스 프록시 |
| Gitea | 3000 | git.ro-being.com | Git 저장소 |
| frontend-base | 8000 | /admin/* | 관리자 대시보드 |
+| auth-server | 9000 | /auth/* | OAuth 인증 서비스 |
+| PostgreSQL | 5432 | - | 데이터베이스 (호스트) |
### 51124 서버
| 서비스 | 포트 | nginx 경로 | 용도 |
@@ -100,4 +104,8 @@
3. **SSL/TLS**
- Let's Encrypt 인증서
- - 자동 갱신 설정
\ No newline at end of file
+ - 자동 갱신 설정
+
+---
+**최종 수정**: 2025-07-29
+**수정 내용**: 서버 구조 변경 반영 (auth-server와 PostgreSQL이 51123 서버에 추가, PostgreSQL은 51124에서 제거)
\ No newline at end of file
diff --git a/docs/implementation/01_MVP 단계_ 자세한 계획.md b/docs/implementation/01_MVP 단계_ 자세한 계획.md
index 8405a40..33cdea6 100755
--- a/docs/implementation/01_MVP 단계_ 자세한 계획.md
+++ b/docs/implementation/01_MVP 단계_ 자세한 계획.md
@@ -51,9 +51,9 @@ tags: AI, 에이전트, MVP, 데이터수집, 밸류에이션, 시계열, Postgr
- 테이블: 스타트업 정보, 펀딩 이력, 메타데이터, 사용자 쿼리, 에이전트 로그.
- ~~블록체인: 검증 이력 및 토큰 거래 기록(Ethereum 또는 Hyperledger 기반)~~.
- **API 개발**: REST API로 CRUD 기능 제공, 에이전트 및 UI 연동.
-- **채팅 UI**: 웹 기반 채팅 인터페이스(React, Tailwind CSS), 예: "A 스타트업 최근 밸류에이션 알려줘" 등이 질의 지원.
-- **결과값**: A 기업의 개요(대표, 서비스, 밸류에이션 시계열 차트 등)
-- **인터페이스** : 옵시디언 형식의 프론트엔드 _[[005 사용툴정리/옵시디언 기능구현 개요|참고]]
+- **채팅 UI**: 게임 스타일 UI (React 18, TypeScript, Vite, shadcn/ui), Merge Restaurant 같은 모바일 게임 인터페이스
+- **결과값**: 로빙 캐릭터 대시보드 (레벨, 스탯, 감정 상태, 스킬 목록)
+- **인터페이스**: 3분할 레이아웃 (GUI 화면 | 채팅창 | 상태창), 모바일은 슬라이드 전환
~~### 3.4 토큰 이코노미 기초 구현
@@ -96,7 +96,7 @@ tags: AI, 에이전트, MVP, 데이터수집, 밸류에이션, 시계열, Postgr
- **[[김종태]]**: PM, 밸류에이션 알고리즘 개발. 에이전트 자동화 구조.
- **[[황한용]]**: 인프라, 백엔드 및 데이터 파이프라인 총괄.
- **[[희재]]**: 에이전트 아키텍처 및 LLM 파이프라인 설계 총괄.
-- Devin : 채팅 UI 및 대시보드 프론트엔드 구현.
+- **프론트엔드 개발**: 게임 스타일 UI 구현 (React + Framer Motion + Lottie)
- **[[강일신]]**(옵션): PM, 프로젝트 관리.
## 7. 리스크 및 대응
@@ -104,4 +104,8 @@ tags: AI, 에이전트, MVP, 데이터수집, 밸류에이션, 시계열, Postgr
- **리스크**: 데이터 소스 부족, 에이전트 처리 속도 저하
- **대응**
- [[../../00 files/0 startups/크런치베이스_Crunchbase|크런치베이스_Crunchbase]], [[경쟁사/혁신의숲|혁신의숲]], [[경쟁사/더브이씨|더브이씨]] API 및 공개 데이터 활용.
- - Kubernetes 스케일링으로 처리량 확보.
\ No newline at end of file
+ - Kubernetes 스케일링으로 처리량 확보.
+
+---
+**최종 수정**: 2025-07-29
+**수정 내용**: 프론트엔드 섹션을 현재 프로젝트 방향(게임 스타일 UI, 로빙 캐릭터 대시보드)에 맞게 업데이트
\ No newline at end of file
diff --git a/docs/implementation/prd.md b/docs/implementation/prd.md
index b53ed69..e4b4ae7 100755
--- a/docs/implementation/prd.md
+++ b/docs/implementation/prd.md
@@ -85,4 +85,8 @@
# Appendix
- **기술 스택**: FastAPI, PostgreSQL, Chroma, LangChain, OpenAI API, Slack API, PyMuPDF
- **핵심 메트릭**: 응답 정확도, 처리 속도, 사용자 만족도, 기억 정확도
-- **성공 지표**: 일일 활성 사용, 스킬 사용 빈도, 피드백 점수, 레벨업 달성률
\ No newline at end of file
+- **성공 지표**: 일일 활성 사용, 스킬 사용 빈도, 피드백 점수, 레벨업 달성률
+
+---
+**최종 업데이트**: 2025-07-29
+**수정 내용**: 문서 형식 정리
\ No newline at end of file
diff --git a/docs/setups/Traefix+DockerSwarm+SlackOath.md b/docs/setups/Traefix+DockerSwarm+SlackOath.md
deleted file mode 100644
index c1040f0..0000000
--- a/docs/setups/Traefix+DockerSwarm+SlackOath.md
+++ /dev/null
@@ -1,69 +0,0 @@
-# Traefik + Docker Swarm + Slack OAuth 구조 정리
-
-## 1. 구성요약
-
-### 조합 목적
-
-* **Traefik**: 동적 리버스 프록시, SSL 자동 발급, 라우팅 자동화
-* **Docker Swarm**: 컨테이너 오케스트레이션, 서비스 자동 배포·복구
-* **Slack OAuth**: 사용자 인증 및 API 호출을 위한 토큰 발급
-
-### 기본 흐름
-
-```
-사용자 ↔ Traefik ↔ FastAPI (컨테이너) ↔ Slack API
- ↕
- PostgreSQL (토큰 저장)
-```
-
----
-
-## 2. 각 조합 비교 요약
-
-| 조합 | 구성도 | 주요 용도 | 장점 | 단점 |
-| -------------------------- | ------------------------------ | -------------- | ---------------- | --------------- |
-| **Nginx + Traefik** | Nginx(외부) → Traefik(내부) → 컨테이너 | 고급 라우팅/보안 분리 | 복잡한 역할 분리 가능 | 설정 이중화, 구조 복잡 |
-| **Nginx + Docker Swarm** | Nginx → Swarm 서비스로 프록시 | 단순 구조, 테스트용 | 익숙함, 설정 간단 | 자동 라우팅/SSL 불가 |
-| **Traefik + Docker Swarm** | Traefik → Swarm 서비스 자동 인식 | 자동 SSL, 무중단 배포 | 설정 자동화, 라벨 기반 운영 | 학습 필요, 초기 설정 요구 |
-
-→ **추천 조합**: Traefik + Docker Swarm
-
----
-
-## 3. Slack OAuth 대응 여부
-
-| 항목 | 설명 | 가능 여부 |
-| --------------- | ------------------------------------------ | ----- |
-| 컨테이너 교체 시 토큰 유지 | Swarm은 컨테이너를 자동으로 교체할 수 있음 | O |
-| Traefik 라우팅 지속성 | 서비스 이름 기준으로 자동 감지/연결 | O |
-| Slack 인증 콜백 유지 | `/auth/slack/callback` 같은 경로 고정 가능 | O |
-| OAuth 토큰 저장 방식 | DB(PostgreSQL), Redis, JSON 파일 등 외부 저장소 활용 | O |
-
-→ 핵심: **토큰을 컨테이너 외부에 저장하는 설계 필요**
-
----
-
-## 4. 권장 저장 방식
-
-| 방식 | 설명 | 비고 |
-| -------------------- | ---------------- | ----------- |
-| Supabase/PostgreSQL | 토큰 안전 저장 + 조회 간편 | **추천** |
-| Redis | 캐시 + TTL 관리 | OK (단기 보관용) |
-| JSON + Docker volume | 간단한 테스트용 | 실운영 비추천 |
-| .env 환경변수 | 초기값 용도로만 사용 | **보안 취약** |
-
----
-
-## 5. 운영 전략 요약
-
-* Traefik으로 **SSL 자동 관리 + 서비스 라우팅 자동화**
-* Docker Swarm으로 **컨테이너 동적 배포 + 재시작 자동 처리**
-* Slack OAuth 토큰은 **PostgreSQL 등 외부 DB에 저장**하여 지속성 확보
-
----
-
-## 6. 결론
-
-* Traefik + Swarm 구조는 Slack OAuth 토큰의 지속성과 확장성 모두 확보 가능
-* 구조적으로 무중단 배포, 컨테이너 재시작, 스케일 아웃에 유리
-* 단, Slack 인증 토큰은 반드시 **컨테이너 외부에 저장**해야 함
diff --git a/docs/setups/ngrok-test-guide.md b/docs/setups/ngrok-test-guide.md
deleted file mode 100644
index 9d55855..0000000
--- a/docs/setups/ngrok-test-guide.md
+++ /dev/null
@@ -1,76 +0,0 @@
-# ngrok을 통한 Slack 직접 연동 테스트
-
-## 🚀 현재 상태
-✅ ngrok 터널 생성 완료: `https://dc5c-59-9-195-150.ngrok-free.app`
-✅ FastAPI 서버 실행 중
-✅ Slack 토큰 설정 완료
-
-## 📋 Slack 앱 설정 (필수)
-
-### Event Subscriptions 설정
-1. https://api.slack.com/apps 에서 로빙 앱 선택
-2. "Event Subscriptions" → "Enable Events" 활성화
-3. Request URL: `https://dc5c-59-9-195-150.ngrok-free.app/api/slack/events`
-4. Bot events 추가:
- - `app_mention`
- - `message.channels`
- - `message.im`
- - `message.groups`
- - `message.mpim`
-5. "Save Changes" 및 필요시 앱 재설치
-
-## 🧪 테스트 시나리오
-
-### 1. 봇 초대
-```
-/invite @Roving
-```
-
-### 2. 직접 메시지
-```
-안녕하세요 로빙!
-```
-
-### 3. 멘션 테스트
-```
-@Roving 오늘 할 일을 정리해주세요
-```
-
-### 4. DM 테스트
-봇과 직접 1:1 대화
-
-## 📊 예상 응답
-현재 테스트 모드에서는 다음과 같은 응답을 받게 됩니다:
-```
-안녕하세요! 테스트 모드에서 실행 중입니다. 메시지를 받았습니다: '[사용자 메시지]'
-```
-
-## 🔍 로그 모니터링
-서버 로그에서 다음 메시지들을 확인할 수 있습니다:
-- Slack 이벤트 수신
-- 메시지 처리 과정
-- AI 서비스 응답
-
-## 🐛 문제 해결
-
-### URL 검증 실패
-- ngrok URL이 정확한지 확인
-- `/api/slack/events` 경로 포함 여부 확인
-
-### 봇이 응답하지 않음
-- Event Subscriptions 설정 확인
-- 봇 권한 확인
-- 로그에서 에러 메시지 확인
-
-### 권한 오류
-- Bot Token Scopes 재확인
-- 앱 재설치 시도
-
-## 📱 실시간 모니터링
-ngrok 웹 인터페이스에서 실시간 요청 확인:
-http://localhost:4040
-
-## 🎯 다음 단계
-1. Slack 설정 완료 후 메시지 테스트
-2. OpenAI API 키 설정하여 실제 AI 응답 활성화
-3. 고급 기능 구현 (요약, 액션 추출, 기억 시스템)
\ No newline at end of file
diff --git a/docs/skills-stats/pptx_파일_구조분석_및_HTML_변환_가능성.md b/docs/skills-stats/pptx_파일_구조분석_및_HTML_변환_가능성.md
deleted file mode 100755
index 4a5f652..0000000
--- a/docs/skills-stats/pptx_파일_구조분석_및_HTML_변환_가능성.md
+++ /dev/null
@@ -1,150 +0,0 @@
-# PPTX 파일 구조분석 및 HTML 변환 가능성 분석
-
-## 개요
-PowerPoint 파일(pptx)의 구조적 분석과 HTML 변환 가능성에 대한 기술적 고찰
-
-## 1. PPTX 파일이 구조분석이 어려운 이유
-
-### 1.1 근본적인 문제점
-- **시각 요소 중심의 비정형 데이터**: 구조화된 문서가 아닌 시각적 배치 위주
-- **디자인과 논리 구조의 분리**: 논리적 구조보다는 디자인 우선으로 설계됨
-- **의미 표준화 불가능**: 같은 내용도 다양한 방식으로 표현 가능
-
-### 1.2 구체적 한계
-- 텍스트 블록의 목적(제목, 본문, 각주 등) 명시 없음
-- 동일한 의미라도 구현 형태 다양화
-- 이미지, 표, 그래프 등 비구조 데이터 혼재
-- 사용자별 디자인 방식 차이
-
-## 2. PPTX 파일 내부 구조
-
-### 2.1 기본 구조 (ZIP 압축 파일)
-```
-presentation.pptx
-├── ppt/
-│ ├── media/ # 이미지 저장 위치 (.png, .jpg 등)
-│ ├── slides/ # 슬라이드 내용 (XML)
-│ │ ├── slide1.xml
-│ │ ├── slide2.xml
-│ ├── slideLayouts/
-│ ├── slideMasters/
-│ └── charts/
-├── _rels/ # 관계 정보
-├── docProps/
-└── [Content_Types].xml
-```
-
-### 2.2 이미지 저장 방식
-- **위치**: `ppt/media/` 폴더에 개별 파일로 저장
-- **형태**: 원본 이미지 파일 그대로 (image1.png, image2.jpeg 등)
-- **연결**: 슬라이드 XML에서 ID로 참조 (``)
-- **매핑**: `_rels` 폴더에서 ID와 실제 파일 경로 매핑
-
-## 3. 압축 해제 방법
-
-### 3.1 GUI 방식
-- 확장자를 `.pptx`에서 `.zip`으로 변경
-- 일반 압축 해제 도구 사용 (7-Zip, WinRAR 등)
-
-### 3.2 명령줄 방식
-```bash
-# Linux/macOS
-unzip presentation.pptx -d extracted_pptx
-
-# Windows PowerShell
-Expand-Archive -Path presentation.pptx -DestinationPath extracted_pptx
-```
-
-### 3.3 Python 방식
-```python
-import zipfile
-
-with zipfile.ZipFile('presentation.pptx', 'r') as zip_ref:
- zip_ref.extractall('extracted_pptx')
-```
-
-## 4. 구조 분석의 현실적 접근
-
-### 4.1 제목/본문 구분의 중요성
-- **목적별 중요도**:
- - 슬라이드 요약/구조화: 매우 중요
- - IR 문서 자동 해석: 핵심 요소
- - LLM 응답 개선: 컨텍스트 구성에 필수
- - 웹 문서 변환: HTML 태그 매핑에 필요
-
-### 4.2 인간 vs AI 구조 인식
-| 구분 | 인간 | AI 시스템 |
-|------|------|-----------|
-| 추론 방식 | 직관적 판단 | 근거 기반 분석 |
-| 오류 처리 | 맥락으로 보정 | 명확한 기준 필요 |
-| 판단 근거 | 시각적 경험 | 폰트, 위치, XML 태그 |
-
-## 5. HTML 변환 가능성
-
-### 5.1 기본 수준 변환 (실용적)
-- **난이도**: 낮음
-- **방법**: 텍스트/이미지 추출 후 HTML 태그 매핑
-- **결과**:
- ```html
-
- 팀 소개
- 홍길동: CTO, 전직 네이버, AI 12년 경력
- 
-
- ```
-
-### 5.2 고급 수준 변환 (복잡)
-- **난이도**: 높음
-- **요구사항**:
- - 레이아웃 유지하면서 HTML/CSS 재현
- - 반복 구조 템플릿화
- - 전환 효과 및 계층 구조 시각화
- - 반응형 디자인 적용
-
-### 5.3 의미 기반 변환 (최고 수준)
-- **난이도**: 매우 높음
-- **필요 기술**:
- - 논리 흐름 분석
- - 시각 구조 해석
- - 컴포넌트 단위 인식
- - LLM/Vision 모델 활용
-
-## 6. 실용적 구현 방안
-
-### 6.1 도구 및 라이브러리
-- **python-pptx**: 기본 텍스트/이미지 추출
-- **unoconv**: LibreOffice 기반 변환
-- **Aspose**: 상용 변환 라이브러리
-- **Apache POI**: Java 기반 처리
-
-### 6.2 단계별 접근
-1. **Phase 1**: 기본 텍스트/이미지 추출
-2. **Phase 2**: 제목/본문 구분 (폰트 크기, 위치 기반)
-3. **Phase 3**: 슬라이드 논리 구조 분석
-4. **Phase 4**: 의미 기반 HTML 변환
-
-### 6.3 현실적 절충안
-- 완벽한 의미 분석보다는 "어느 정도 추론 가능한 수준"
-- 사용자 피드백을 통한 점진적 개선
-- 특정 도메인(IR, 교육 등) 특화 접근
-
-## 7. 결론
-
-### 7.1 핵심 인사이트
-- PPTX 구조 분석은 **불가능하지 않으나 완전 자동화는 어려움**
-- **기본 수준의 HTML 변환은 충분히 실용적**
-- **목적과 범위 정의가 핵심**
-
-### 7.2 권장사항
-- 단순 문서 변환용: 즉시 구현 가능
-- 의미 기반 분석: 단계적 접근 필요
-- 특정 용도 특화: 도메인별 최적화 고려
-
-### 7.3 로빙 프로젝트 적용 방안
-- PoC 단계: 슬라이드별 제목/내용 구조 기반 요약
-- 발전 단계: GPT + Vision 모델 활용한 의미 분석
-- 완성 단계: 사용자 맞춤형 구조 학습 시스템
-
----
-
-*이 문서는 ChatGPT와의 대화를 기반으로 작성되었으며, PPTX 파일 처리 스킬 개발의 기술적 근거로 활용됩니다.*
\ No newline at end of file
diff --git a/docs/skills-stats/외부도구_아이템화_및_스마트폰_오버레이_활용방안.md b/docs/skills-stats/외부도구_아이템화_및_스마트폰_오버레이_활용방안.md
index bc52865..d56702d 100755
--- a/docs/skills-stats/외부도구_아이템화_및_스마트폰_오버레이_활용방안.md
+++ b/docs/skills-stats/외부도구_아이템화_및_스마트폰_오버레이_활용방안.md
@@ -28,36 +28,10 @@
| 외부 도구 | Notion, Slack, Zoom 등 | 토큰 기반 권한 제어 |
| 프리미엄 모델 | GPT-4 등 | 호출량 기반 과금 및 제한 |
-### 2.2 젠스파크(GenSpark) 연동
-
-#### 2.2.1 서비스 특성
-- AI 코드 생성 및 실시간 결과 실행 플랫폼
-- 웹 기반 코드 에디터 + 실행 환경 제공
-
-#### 2.2.2 로빙 연동 조건
-- **API 접근**: 젠스파크 공식 API 또는 웹 자동화 인터페이스 필요
-- **워크플로우**:
- 1. 로빙에서 코딩 요청 수신
- 2. 젠스파크로 스크립트 실행
- 3. 결과를 Slack/Notion으로 반환
-- **기술적 구현**:
- - 공식 API 미제공 시 Playwright 등 UI 자동화 활용
- - 실행 결과, 코드, 로그의 구조화된 반환
-
-### 2.3 리플릿(Replit) 연동
-
-#### 2.3.1 서비스 특성
-- 웹 기반 인터프리터 및 공유 가능한 코드 환경
-- 다양한 프로그래밍 언어 지원
-- 협업 기능 및 배포 환경 제공
-
-#### 2.3.2 활용 방식
-- **API 활용**: 리플릿 API 또는 템플릿 복제 링크 사용
-- **워크플로우**:
- 1. 사용자 입력 또는 Slack 대화를 코드로 변환
- 2. 리플릿에 코드 업로드 및 실행
- 3. 실행 링크 또는 결과를 Slack에 반환
-- **권한 관리**: 개인 토큰 또는 OAuth 인증으로 사용자 계정 연결
+### 2.2 외부 코드 실행 도구 연동
+- **주요 서비스**: GenSpark, Replit 등
+- **통합 방식**: API 또는 웹 자동화
+- **활용**: 코드 실행 요청 → 외부 도구 실행 → 결과 반환
## 3. 기술적 구현 방안
@@ -159,4 +133,7 @@
---
-*이 문서는 ChatGPT와의 대화를 기반으로 작성되었으며, 로빙의 외부 도구 아이템화 전략 수립에 활용됩니다.*
\ No newline at end of file
+*이 문서는 ChatGPT와의 대화를 기반으로 작성되었으며, 로빙의 외부 도구 아이템화 전략 수립에 활용됩니다.*
+
+**최종 수정**: 2025-07-29
+**수정 내용**: 외부 도구별 상세 설명을 간소화하여 핵심 내용만 유지
\ No newline at end of file
diff --git a/troubleshooting/250729_happybell80_프론트엔드재설계.md b/troubleshooting/250729_happybell80_프론트엔드재설계.md
new file mode 100644
index 0000000..369d535
--- /dev/null
+++ b/troubleshooting/250729_happybell80_프론트엔드재설계.md
@@ -0,0 +1,121 @@
+# 프론트엔드 재설계 및 GUI 공유 아키텍처 논의
+
+**날짜**: 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. **점진적 확장이 핵심**
+ - 한번에 모든 기능을 구현하지 말고 레벨별로 해금
+ - 리소스 사용량도 점진적으로 증가
+
+---
+**작성 완료**: 2025-07-29 19:35
\ No newline at end of file