ivada-infra/DOCS
3
0
Fork 0
Code Issues 1 Pull Requests 5 Actions Packages Projects Releases Wiki Activity

docs: 프론트엔드 및 서버 아키텍처 문서 업데이트

Browse Source 
- 프론트엔드 게임 스타일 UI 방향 반영
- GUI 공유 아키텍처 문서 추가
- 서버 구조 변경 반영 (51123/51124 역할 분리)
- 불필요한 구식 문서 제거
This commit is contained in:
happybell80 2025-07-29 19:59:56 +09:00
parent b756c9a616
commit cc0bc34fd5
11 changed files with 337 additions and 346 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
00_프로젝트_종합_v2.md
View File

@ -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 (아키텍처 현실화, 마이크로서비스 전환 반영)
**최종 업데이트**: 2025-07-29
**버전**: 2.1
**수정 내용**: 관련 문서 링크 업데이트 (GUI 공유 아키텍처 추가, 트러블슈팅 경로 수정)

17
docs/architecture/00_아키텍쳐.md
View File

@ -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 공유 시스템)에 맞게 업데이트

165
docs/architecture/250729_프론트엔드GUI공유아키텍처.md Normal file
View File

@ -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
**문서 유형**: 아키텍처 설계

18
docs/architecture/server-architecture.md
View File

@ -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 인증서
- 자동 갱신 설정
- 자동 갱신 설정
---
**최종 수정**: 2025-07-29
**수정 내용**: 서버 구조 변경 반영 (auth-server와 PostgreSQL이 51123 서버에 추가, PostgreSQL은 51124에서 제거)

14
docs/implementation/01_MVP 단계_ 자세한 계획.md
View File

@ -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 스케일링으로 처리량 확보.
- Kubernetes 스케일링으로 처리량 확보.
---
**최종 수정**: 2025-07-29
**수정 내용**: 프론트엔드 섹션을 현재 프로젝트 방향(게임 스타일 UI, 로빙 캐릭터 대시보드)에 맞게 업데이트

6
docs/implementation/prd.md
View File

@ -85,4 +85,8 @@
# Appendix
- **기술 스택**: FastAPI, PostgreSQL, Chroma, LangChain, OpenAI API, Slack API, PyMuPDF
- **핵심 메트릭**: 응답 정확도, 처리 속도, 사용자 만족도, 기억 정확도
- **성공 지표**: 일일 활성 사용, 스킬 사용 빈도, 피드백 점수, 레벨업 달성률
- **성공 지표**: 일일 활성 사용, 스킬 사용 빈도, 피드백 점수, 레벨업 달성률
---
**최종 업데이트**: 2025-07-29
**수정 내용**: 문서 형식 정리

69
docs/setups/Traefix+DockerSwarm+SlackOath.md
View File

@ -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 인증 토큰은 반드시 **컨테이너 외부에 저장**해야 함

76
docs/setups/ngrok-test-guide.md
View File

@ -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. 고급 기능 구현 (요약, 액션 추출, 기억 시스템)

150
docs/skills-stats/pptx_파일_구조분석_및_HTML_변환_가능성.md
View File

@ -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로 참조 (`<a:blip r:embed="rId5"/>`)
- **매핑**: `_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
<section class="slide">
<h1>팀 소개</h1>
<p>홍길동: CTO, 전직 네이버, AI 12년 경력</p>
<img src="media/image1.jpg" />
</section>
```
### 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 파일 처리 스킬 개발의 기술적 근거로 활용됩니다.*

39
docs/skills-stats/외부도구_아이템화_및_스마트폰_오버레이_활용방안.md
View File

@ -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와의 대화를 기반으로 작성되었으며, 로빙의 외부 도구 아이템화 전략 수립에 활용됩니다.*
*이 문서는 ChatGPT와의 대화를 기반으로 작성되었으며, 로빙의 외부 도구 아이템화 전략 수립에 활용됩니다.*
**최종 수정**: 2025-07-29
**수정 내용**: 외부 도구별 상세 설명을 간소화하여 핵심 내용만 유지

121
troubleshooting/250729_happybell80_프론트엔드재설계.md Normal file
View File

@ -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