diff --git a/.gitignore b/.gitignore index d93a3b6..5ce95e0 100644 --- a/.gitignore +++ b/.gitignore @@ -34,4 +34,7 @@ $RECYCLE_BIN/ # Local environment files .env -.env.local \ No newline at end of file +.env.local + +# Archive folder - unrealistic or outdated content +.archive/ \ No newline at end of file diff --git a/00_프로젝트_종합.md b/00_프로젝트_종합.md deleted file mode 120000 index 2038c7a..0000000 --- a/00_프로젝트_종합.md +++ /dev/null @@ -1 +0,0 @@ -/home/happybell/projects/ivada/001_ivada/00_프로젝트_종합.md \ No newline at end of file diff --git a/00_프로젝트_종합_v2.md b/00_프로젝트_종합_v2.md new file mode 100644 index 0000000..3c2e8f4 --- /dev/null +++ b/00_프로젝트_종합_v2.md @@ -0,0 +1,226 @@ +--- +tags: 로빙, RO-BEING, 존재에이전트, 마이크로서비스, 스탯시스템, 협업도구, AI에이전트 +date: 2025-07-01 +last_updated: 2025-07-21 +team: 김종태, 황한용, 희재, (강일신) +version: 2.0 +--- + +# 로빙(RO-BEING) 프로젝트 종합 +## 기억하고 성장하는 존재형 AI 에이전트 + +> **"AI는 도구가 아니라 존재로서 가치를 가지는 고유한 존재이다."** + +## 📋 목차 +1. [프로젝트 비전](#프로젝트-비전) +2. [핵심 차별화 요소](#핵심-차별화-요소) +3. [기술 아키텍처](#기술-아키텍처) +4. [스탯과 성장 시스템](#스탯과-성장-시스템) +5. [현재 구현 상태](#현재-구현-상태) +6. [개발 로드맵](#개발-로드맵) +7. [비즈니스 모델](#비즈니스-모델) + +--- + +## 프로젝트 비전 + +### 문제 정의 +1인 기업가 또는 소규모 스타트업은 다양한 업무를 수행해야 하므로 협업 동료가 절실합니다. 하지만: +- 인재 채용이 어렵고 이직이 빈번함 +- 매번 새로운 직원에게 업무 맥락을 설명해야 함 +- 업무 위임에 대한 불안감 존재 + +### 우리의 해법: "도구를 넘어, 동료로" + +| 기존 AI 도구 | 로빙(RO-BEING) | +|------------|----------------| +| 일회성 대화 | **지속적 기억** - 프로젝트 맥락 유지 | +| 블랙박스 권한 | **투명한 활동 로그** - 모든 행동 추적 가능 | +| 정적 기능 | **성장하는 존재** - 레벨업과 스킬 획득 | +| 명령 수행 | **선제적 행동** - 맥락 기반 자율 판단 | + +--- + +## 핵심 차별화 요소 + +### 1. 신뢰 기반 점진적 위임 +``` +LV.1 (신입) → 대화 요약만 가능 + ↓ 50회 검토 후 +LV.2 (전문가) → 이메일 초안 작성 가능 + ↓ 신뢰도 축적 +LV.3 (매니저) → 간단한 응대 자동화 +``` + +### 2. 검증 가능한 의사결정 +- **What**: "최신 정보를 요약했습니다" +- **What + 신뢰**: "6월 11일 17:50 기준, Slack 3개 채널과 이메일 5개를 분석한 결과입니다. [근거 데이터 확인]" + +### 3. 맥락 유지 비용 '0' +- 매번 설명 불필요: "지난번 논의한 '알파 프로젝트' 후속 아이디어가 있으신가요?" +- 프로젝트 연속성 보장: 진정한 '동료'로서의 역할 + +--- + +## 기술 아키텍처 + +### 로빙 컨테이너 아키텍처 +``` +┌─────────────────────────────────────┐ +│ 중앙 대시보드 서버 │ +└─────────────┬───────────────────────┘ + │ + ┌─────────┴─────────┬─────────────┐ + ▼ ▼ ▼ +┌─────────┐ ┌─────────┐ ┌─────────┐ +│ 로빙#001 │ │ 로빙#002 │ │ 로빙#003 │ +├─────────┤ ├─────────┤ ├─────────┤ +│ FastAPI │ │ FastAPI │ │ FastAPI │ +│ ChromaDB│ │ ChromaDB│ │ ChromaDB│ +│ Volume │ │ Volume │ │ Volume │ +└─────────┘ └─────────┘ └─────────┘ +``` + +### 마이크로서비스 스킬 아키텍처 +``` +로빙 본체 (Container) + │ + ├─[HTTP API]→ skill-email:8501 + ├─[HTTP API]→ skill-pdf:8502 + ├─[HTTP API]→ skill-calendar:8503 + └─[HTTP API]→ skill-digest:8504 +``` + +**핵심 특징**: +- **컨테이너 = 몸, 기억 = 영혼**: 재시작해도 동일한 로빙으로 복원 +- **수면/각성 시스템**: 비활성 시 최소 리소스, 필요시 3-5초 내 각성 +- **스킬 독립성**: 100개 로빙이 1개 스킬 서비스 공유 (리소스 효율성) + +### 데이터 아키텍처: Polyglot Persistence +- **PostgreSQL**: 사용자, 스탯, 스킬 메타데이터 +- **ChromaDB**: 대화 내용, 벡터 임베딩, 장기 기억 +- **Neo4j**: 사용자 간 관계, 감정 이력 (계획) +- **Redis**: 세션 데이터, 캐시 (계획) + +--- + +## 스탯과 성장 시스템 + +### 4+1 핵심 스탯 +| 스탯 | 초기값 | 최대값 | 실제 영향 | +|-----|--------|--------|-----------| +| 기억(Memory) | 5 | 105 | 저장 용량, 검색 정확도 | +| 연산(Compute) | 5 | 105 | LLM 모델 성능 | +| 공감(Empathy) | 5 | 105 | 감정 인식 정확도 | +| 통솔(Leadership) | 5 | 105 | 멀티태스킹, 우선순위 | +| 윤리(Ethics) | 5 | 105 | 안전 체크, 위험 방지 | + +### 성장 메커니즘 +- **레벨**: 1~20 (레벨당 5포인트 획득) +- **총 포인트**: 100포인트 (20레벨 × 5포인트) +- **분배**: 사용자 피드백 기반 자율 결정 + +### 스킬 해금 예시 +``` +기억 1~10: 회의 요약, 중요도 태깅 +기억 11~20: 주간 리포트, 말버릇 학습 +기억 21~30: 선제 회상, 사건 연결 + +연산 1~10: 메일 분류, 초안 생성 +연산 11~20: 멀티 프롬프트, 논리 분석 +연산 21~30: 리스크 분석, 보고서 자동화 +``` + +--- + +## 현재 구현 상태 (2025.07.21) + +### ✅ 완료된 작업 +1. **기본 인프라** (95%) + - FastAPI + PostgreSQL + ChromaDB 안정 운영 + - Slack Events API 완전 구현 + - 비동기 응답 시스템 (3초 타임아웃 해결) + +2. **RobeingBrain 시스템** (90%) + - 의도 분석 → 스킬 매핑 → 실행 파이프라인 + - 기본 스탯 시스템 구현 + +3. **마이크로서비스 아키텍처** (95%) + - 로빙-스킬 완전 분리 (HTTP API) + - skill-email:8501 독립 서비스 운영 + - Nginx 리버스 프록시 설정 + +### 🚧 진행 중 +- Thread Digest 스킬 (20%) +- Action Extractor 스킬 (20%) +- 관리자 대시보드 개선 (60%) + +### 📋 계획 +- 스킬 레지스트리 시스템 +- 레벨업 메커니즘 +- 웹 인터페이스 + +--- + +## 개발 로드맵 + +### Phase 1: MVP (3개월) ✓ 진행중 +- [x] Slack 통합 및 기본 대화 +- [x] 스탯 시스템 기본 구현 +- [x] Email 스킬 HTTP 분리 +- [ ] Thread Digest 완성 +- [ ] 레벨업 시스템 + +### Phase 2: MMP (6개월) +- [ ] 10개 핵심 스킬 확장 +- [ ] 감정 벡터 시스템 +- [ ] 웹 대시보드 +- [ ] 30개 팀 파일럿 + +### Phase 3: Scale (1년) +- [ ] 스킬 마켓플레이스 +- [ ] 멀티 에이전트 협업 +- [ ] 엔터프라이즈 기능 + +--- + +## 비즈니스 모델 + +### 수익 구조 (월 구독) +| 구성 요소 | 가격 | 내용 | +|----------|------|------| +| 스탯 구독 | 15만원 | 인프라 용량 (레벨별 차등) | +| 스킬 패스 | 10만원 | 고급 스킬 번들 | +| 아이템 마켓 | 5만원 | 외부 도구 통합 | +| **합계** | **30만원** | 5인 스타트업 기준 | + +### 시장 전략 +1. **1차 타겟**: 5인 이하 스타트업 (국내 3만개) +2. **차별화**: "도구 vs 동료" 포지셔닝 +3. **데이터 해자**: 축적된 조직 기억 = 전환 비용 +4. **네트워크 효과**: 팀 규모 증가 → 가치 기하급수 + +--- + +## 관련 문서 + +### 아키텍처 +- [컨테이너 아키텍처 설계](./docs/architecture/로빙_컨테이너_아키텍처_설계.md) +- [마이크로서비스 설계](./docs/architecture/skillhub_architecture.md) + +### 철학 및 개념 +- [AI Agent 차별화 방안](./docs/philosophy/AI agent 차별화 방안 제안.md) +- [존재와 함수형 프로그래밍](./docs/guide/functional-programing/로빙_존재와_함수형_프로그래밍.md) + +### 구현 +- [PRD](./docs/implementation/prd.md) +- [스탯 성장 설계](./docs/philosophy/robeing_stats_growth_design.md) + +### 트러블슈팅 +- [최신 이슈 및 해결](./docs/troubleshooting/) + +--- + +**문서 생성일**: 2025-07-01 +**최종 업데이트**: 2025-07-21 +**버전**: 2.0 (아키텍처 현실화, 마이크로서비스 전환 반영) \ No newline at end of file diff --git a/docs/ai-memory/AI 에이전트의 장기 기억 관리_ 정보 가치 판단_신뢰성 검증_망각과 효율성 최적화_by grok.md b/docs/ai-memory/AI 에이전트의 장기 기억 관리_ 정보 가치 판단_신뢰성 검증_망각과 효율성 최적화_by grok.md new file mode 100755 index 0000000..d5870a3 --- /dev/null +++ b/docs/ai-memory/AI 에이전트의 장기 기억 관리_ 정보 가치 판단_신뢰성 검증_망각과 효율성 최적화_by grok.md @@ -0,0 +1,161 @@ +--- +tags: AI기억관리, 정보가치판단, 신뢰성검증, 망각최적화, 강화학습, 베이지안추론, 지식그래프 +--- + +요약 +- AI 에이전트의 장기 기억 관리는 강화학습 기반 가치 네트워크와 망각 곡선 모델을 통해 정보의 가치를 판단하고 관리한다. +- 새로운 정보는 온라인 학습과 지식 그래프를 통해 통합되며, 출처 추적과 베이지안 추론으로 신뢰성을 검증한다. +- 망각은 활용 빈도와 명시적 요청에 기반하여 계산 효율성을 최적화한다. + + +--- +공유링크_grok https://grok.com/share/c2hhcmQtMg%3D%3D_a1c92954-ea4b-4014-baff-ea032cac5960 + +#AI기억관리 #정보가치판단 #망각곡선 #강화학습 #지식그래프업데이트 #출처추적 #베이지안 #계산효율성 #데이터프라이버시 #장기상호작용 + +### 주요 요약 + +- 연구는 AI 에이전트의 기억 관리 메커니즘을 다양한 분야에서 탐구하고 있습니다. +- 정보 가치는 강화 학습과 사용 빈도를 통해 판단되며, 망각 곡선 모델로 관리됩니다. +- 새로운 정보는 온라인 학습과 지식 그래프를 통해 통합되고, 기존 정보는 수정 또는 폐기됩니다. +- 신뢰성은 출처 추적과 베이지안 추론으로 검증되며, 충돌은 다중 정보원 융합으로 해결됩니다. +- 망각은 활용 빈도와 명시적 요청에 기반하며, 계산 효율성은 캐싱과 하드웨어 가속으로 개선됩니다. + +--- + +### 정보 가치 판단 및 관리 + +AI 에이전트가 정보를 평가하고 관리하는 방법은 여러 접근 방식을 통해 연구되고 있습니다. +- **강화 학습 기반 가치 네트워크**: 에이전트의 목표 달성에 기여하는 정도를 학습하여 정보 가치를 판단합니다. 예를 들어, 특정 정보가 자주 사용되면 가치를 높게 평가할 수 있습니다. +- **사용 빈도 및 최신성 분석**: 자주 사용되거나 최근에 획득된 정보에 높은 가치를 부여합니다. 이는 컴퓨터 과학의 캐싱 메커니즘과 유사합니다. +- **망각 곡선 모델링**: 인간의 망각 곡선처럼 시간이 지남에 따라 정보 중요도를 점진적으로 감소시키는 모델을 적용합니다. 이는 인지 과학에서 영감을 받았습니다. + +이러한 방법들은 에이전트가 제한된 메모리 자원을 효율적으로 활용하도록 돕습니다. 예를 들어, MemGPT는 운영 체제의 가상 메모리 개념을 차용하여 중요한 정보를 우선적으로 유지합니다 ([MemGPT: Towards LLMs as Operating Systems](https://arxiv.org/abs/2310.08560)). + +--- + +### 새로운 정보 습득 및 기존 정보 수정/폐기 + +새로운 정보를 통합하고 기존 정보를 업데이트하거나 폐기하는 과정은 에이전트의 학습 능력에 핵심적입니다. +- **온라인 학습 및 점진적 학습**: 환경 변화에 적응하며 새로운 정보를 기존 지식에 통합합니다. 이는 신경 과학의 시냅스 가소성과 유사합니다. +- **지식 그래프 업데이트**: 정보를 노드와 관계로 표현하여 새로운 정보를 추가하거나 기존 관계를 수정하고, 필요 없는 정보를 제거합니다. +- **잊음 학습(Unlearning)**: 특정 정보를 의도적으로 제거하여 모델을 최신 상태로 유지합니다. 이는 데이터 프라이버시와 관련된 요청에 유용합니다. + +예를 들어, A-MEM 프레임워크는 Zettelkasten 메모법을 기반으로 지식 네트워크를 동적으로 업데이트하여 새로운 경험을 반영합니다 ([A Survey on the Memory Mechanism of Large Language Model based Agents](https://arxiv.org/abs/2404.13501)). + +--- + +### 정보 신뢰성 검증 및 충돌 해결 + +정보의 신뢰성을 검증하고 충돌을 해결하는 메커니즘은 에이전트의 신뢰성을 높이는 데 중요합니다. +- **정보 출처 추적 및 신뢰도 평가**: 각 정보의 출처를 기록하고 신뢰도를 평가하여 신뢰도가 낮은 정보를 주의하거나 폐기합니다. 이는 철학의 인식론에서 영감을 받았습니다. +- **다중 정보원 융합**: 여러 출처에서 정보를 수집하여 일치 여부를 확인하고, 불일치 시 합의를 도출하거나 사용자에게 확인을 요청합니다. +- **베이지안 추론**: 확률적 모델을 사용하여 새로운 증거를 기반으로 기존 믿음을 업데이트하고 불확실성을 관리합니다. + +이 접근법은 사회 과학에서 인간이 정보 신뢰성을 판단하는 방식을 반영하며, 예를 들어 LangMem SDK는 사용자 상호작용에서 신뢰할 수 있는 정보를 추출하는 도구를 제공합니다 ([LangMem SDK for agent long-term memory](https://blog.langchain.dev/langmem-sdk-launch/)). + +--- + +### 망각 결정 + +어떤 정보를 언제, 어떻게 망각시킬지는 메모리 효율성을 결정하는 중요한 요소입니다. +- **활용 기반 망각**: 오랫동안 사용되지 않거나 관련성이 떨어진 정보를 점진적으로 삭제합니다. 이는 인지 과학의 망각 곡선과 유사합니다. +- **기억 용량 제한 및 우선순위 기반 삭제**: 메모리 용량이 제한될 경우, 가치가 낮은 정보 먼저 삭제합니다. 이는 경제학의 자원 할당 이론과 연결됩니다. +- **명시적 망각 요청 처리**: 사용자가 특정 정보를 잊어달라고 요청하면 안전하게 삭제합니다. 이는 데이터 프라이버시 규제(GDPR)와 관련됩니다. + +MemGPT는 메모리 계층을 통해 덜 중요한 정보를 외부 컨텍스트로 이동시켜 효율적으로 관리합니다 ([MemGPT – UC Berkeley Sky Computing Lab](https://sky.cs.berkeley.edu/project/memgpt/)). + +--- + +### 계산 비용 및 지연 시간 개선 + +대규모 데이터 처리에서 계산 효율성과 지연 시간을 줄이는 것은 필수적입니다. +- **효율적인 메모리 구조 및 검색 알고리즘**: 벡터 데이터베이스를 사용하여 대규모 데이터를 빠르게 검색합니다. +- **근사 최근접 이웃 탐색(ANNS)**: 정확도를 약간 희생하여 검색 속도를 크게 향상시킵니다. +- **캐싱 및 프리패칭**: 자주 사용되는 정보를 캐시에 저장하거나 미리 로드하여 접근 속도를 높입니다. +- **하드웨어 가속**: GPU나 TPU를 활용하여 메모리 접근 및 연산 속도를 개선합니다. + +예를 들어, Mem0는 선택적 검색 파이프라인을 통해 p95 지연 시간을 91% 단축하며 효율성을 높입니다 ([Scalable Long-Term Memory for Production AI Agents | Mem0](https://mem0.ai/research)). + + +--- + +### 상세 조사 보고서: AI 에이전트의 기억 관리 메커니즘 + +이 보고서는 AI 에이전트의 기억 관리와 관련된 기술적 과제에 대한 현재 연구와 잠재적 접근 방식을 종합적으로 탐구합니다. 다양한 학문 분야(철학, 수학, 과학, 공학, 사회 과학, 경제, 정치 등)의 통찰을 통합하여, 에이전트가 정보를 평가, 관리, 습득, 수정, 폐기, 신뢰성 검증, 충돌 해결, 망각 결정, 계산 효율성 개선에 어떻게 접근할 수 있는지 분석합니다. 2025년 5월 21일 기준으로 최신 연구를 반영하며, MemGPT, A-MEM, LangMem SDK 등 구체적인 사례를 포함합니다. + +#### 배경 및 필요성 + +AI 에이전트는 장기적인 상호작용과 복잡한 환경에서 자아 진화(self-evolving) 능력을 통해 실세계 문제를 해결합니다. 이를 위해 기억(memory)은 핵심 구성 요소로, 과거 경험을 저장하고 검색하여 의사 결정을 개선합니다. 그러나 제한된 컨텍스트 창, 계산 비용, 데이터 품질, 검색 복잡성 등 여러 도전 과제가 존재합니다. 이 보고서는 이러한 문제를 해결하기 위한 메커니즘을 다각도로 탐구합니다. + +#### 정보 가치 판단 및 관리 + +정보의 가치를 판단하고 관리하는 메커니즘은 에이전트의 효율성을 결정합니다. +- **강화 학습 기반 가치 네트워크**: 정보가 목표 달성에 기여하는 정도를 학습하여 가치를 평가합니다. 예를 들어, 특정 정보가 자주 사용되면 가치를 높게 설정합니다. 이는 수학의 정보 이론과 경제학의 자원 할당 이론에서 영감을 받았습니다. +- **사용 빈도 및 최신성 분석**: 자주 사용되거나 최근에 획득된 정보에 높은 가치를 부여합니다. 이는 컴퓨터 과학의 캐싱 메커니즘과 유사하며, 인지 과학의 기억 우선순위 연구와 연결됩니다. +- **망각 곡선 모델링**: 인간의 망각 곡선(Ebbinghaus 곡선)처럼 시간이 지남에 따라 정보 중요도를 점진적으로 감소시키는 모델을 적용합니다. 이는 철학의 망각 이론(예: 니체)과 인지 과학에서 영감을 받았습니다. + +예를 들어, MemGPT는 운영 체제의 가상 메모리 개념을 차용하여 중요한 정보를 메인 컨텍스트에 유지하고 덜 중요한 정보를 외부 컨텍스트로 이동시킵니다 ([MemGPT: Towards LLMs as Operating Systems](https://arxiv.org/abs/2310.08560)). + +#### 새로운 정보 습득 및 기존 정보 수정/폐기 + +새로운 정보를 통합하고 기존 정보를 업데이트하거나 폐기하는 과정은 에이전트의 학습 능력에 필수적입니다. +- **온라인 학습 및 점진적 학습**: 환경 변화에 적응하며 새로운 정보를 기존 지식에 통합합니다. 이는 신경 과학의 시냅스 가소성과 장기 강화(LTP)에서 영감을 받았습니다. +- **지식 그래프 업데이트**: 정보를 노드와 관계로 표현하여 새로운 정보를 추가하거나 기존 관계를 수정하고, 필요 없는 정보를 제거합니다. 이는 공학의 데이터베이스 관리 시스템과 연결됩니다. +- **잊음 학습(Unlearning)**: 특정 정보를 의도적으로 제거하여 모델을 최신 상태로 유지합니다. 이는 데이터 프라이버시와 관련된 명시적 요청 처리에 유용하며, GDPR의 "잊혀질 권리"와 관련됩니다. + +A-MEM 프레임워크는 Zettelkasten 메모법을 기반으로 지식 네트워크를 동적으로 업데이트하여 새로운 경험을 반영합니다 ([A Survey on the Memory Mechanism of Large Language Model based Agents](https://arxiv.org/abs/2404.13501)). + +#### 정보 신뢰성 검증 및 충돌 해결 + +정보의 신뢰성을 검증하고 충돌을 해결하는 메커니즘은 에이전트의 신뢰성을 높이는 데 중요합니다. +- **정보 출처 추적 및 신뢰도 평가**: 각 정보의 출처를 기록하고 신뢰도를 평가하여 신뢰도가 낮은 정보를 주의하거나 폐기합니다. 이는 철학의 인식론(예: 정당화된 참된 믿음)에서 영감을 받았습니다. +- **다중 정보원 융합**: 여러 출처에서 정보를 수집하여 일치 여부를 확인하고, 불일치 시 합의를 도출하거나 사용자에게 확인을 요청합니다. 이는 사회 과학에서 인간의 인지 부조화 해결 방식을 반영합니다. +- **베이지안 추론**: 확률적 모델을 사용하여 새로운 증거를 기반으로 기존 믿음을 업데이트하고 불확실성을 관리합니다. 이는 수학의 확률론과 연결됩니다. + +LangMem SDK는 사용자 상호작용에서 신뢰할 수 있는 정보를 추출하는 도구를 제공하며, 베이지안 접근법을 통해 충돌을 해결할 수 있습니다 ([LangMem SDK for agent long-term memory](https://blog.langchain.dev/langmem-sdk-launch/)). + +#### 망각 결정 + +어떤 정보를 언제, 어떻게 망각시킬지는 메모리 효율성을 결정하는 중요한 요소입니다. +- **활용 기반 망각**: 오랫동안 사용되지 않거나 관련성이 떨어진 정보를 점진적으로 삭제합니다. 이는 인지 과학의 망각 곡선과 유사하며, 컴퓨터 과학의 LRU(Least Recently Used) 정책과 연결됩니다. +- **기억 용량 제한 및 우선순위 기반 삭제**: 메모리 용량이 제한될 경우, 가치가 낮은 정보 먼저 삭제합니다. 이는 경제학의 기회 비용 개념과 관련됩니다. +- **명시적 망각 요청 처리**: 사용자가 특정 정보를 잊어달라고 요청하면 안전하게 삭제합니다. 이는 데이터 프라이버시와 윤리적 고려사항에 중요합니다. + +MemGPT는 메모리 계층을 통해 덜 중요한 정보를 외부 컨텍스트로 이동시켜 효율적으로 관리합니다 ([MemGPT – UC Berkeley Sky Computing Lab](https://sky.cs.berkeley.edu/project/memgpt/)). + +#### 계산 비용 및 지연 시간 개선 + +대규모 데이터 처리에서 계산 효율성과 지연 시간을 줄이는 것은 필수적입니다. +- **효율적인 메모리 구조 및 검색 알고리즘**: 벡터 데이터베이스를 사용하여 대규모 데이터를 빠르게 검색합니다. 이는 공학의 데이터베이스 관리 시스템에서 영감을 받았습니다. +- **근사 최근접 이웃 탐색(ANNS)**: 정확도를 약간 희생하여 검색 속도를 크게 향상시킵니다. 이는 수학의 근사 알고리즘과 연결됩니다. +- **캐싱 및 프리패칭**: 자주 사용되는 정보를 캐시에 저장하거나 미리 로드하여 접근 속도를 높입니다. 이는 컴퓨터 과학의 캐싱 메커니즘과 유사합니다. +- **하드웨어 가속**: GPU나 TPU를 활용하여 메모리 접근 및 연산 속도를 개선합니다. 이는 공학의 하드웨어 최적화와 관련됩니다. + +Mem0는 선택적 검색 파이프라인을 통해 p95 지연 시간을 91% 단축하며 효율성을 높입니다 ([Scalable Long-Term Memory for Production AI Agents | Mem0](https://mem0.ai/research)). + +#### 응용 사례 및 평가 + +다양한 응용 사례에서 기억 메커니즘이 중요한 역할을 합니다. 아래 표는 주요 응용 분야와 관련된 기억 메커니즘을 요약합니다. + +| **응용 분야** | **기억 메커니즘 세부 사항** | **참조 URL** | +|-----------------------|------------------------------------------------------------------|-----------------------------------------------------------------------------| +| 역할극 및 사회 시뮬레이션 | 경험 업로드, 스크립트 기반 캐릭터 기억, 관련성 기반 응답 저장 | [https://arxiv.org/html/2404.13501v1#bib.bib105], [https://arxiv.org/html/2404.13501v1#bib.bib143] | +| 개인 비서 | 대화 내용 저장, 요약된 정보 검색, 도구 사용으로 외부 지식 통합 | [https://arxiv.org/html/2404.13501v1#bib.bib94], [https://arxiv.org/html/2404.13501v1#bib.bib101] | +| 오픈월드 게임 | 과거 경험 저장, 성공적인 궤적 검색, 멀티모달 지식 라이브러리 유지 | [https://arxiv.org/html/2404.13501v1#bib.bib99], [https://arxiv.org/html/2404.13501v1#bib.bib93] | +| 코드 생성 | 컴파일러 오류 데이터베이스, 과거 대화 기록 검색, 관련 정보 검색 | [https://arxiv.org/html/2404.13501v1#bib.bib142], [https://arxiv.org/html/2404.13501v1#bib.bib144] | +| 추천 시스템 | 계층적 기억, 사용자 대화 기록 아카이브, 반사적 기억 관리 | [https://arxiv.org/html/2404.13501v1#bib.bib95], [https://arxiv.org/html/2404.13501v1#bib.bib108] | + +평가는 직접 평가(주관적/객관적)와 간접 평가(작업 기반)로 나뉩니다. 예를 들어, LoCoMo 데이터셋에서 A-MEM은 Multi-Hop F1 45.85를 기록하며 기준 모델을 능가했습니다 ([A Survey on the Memory Mechanism of Large Language Model based Agents](https://arxiv.org/abs/2404.13501)). + +#### 한계 및 미래 방향 + +현재 연구는 표준화된 벤치마크 부족, 멀티모달 확장 필요, 계산 비용 최적화 등 여러 한계를 가지고 있습니다. 미래 연구는 경제학의 자원 할당 모델, 철학의 윤리적 고려사항, 사회 과학의 집단 기억 연구를 통합하여 더 강력한 기억 시스템을 개발할 수 있습니다. + +#### 주요 인용 + +- [MemGPT: Towards LLMs as Operating Systems](https://arxiv.org/abs/2310.08560) +- [A Survey on the Memory Mechanism of Large Language Model based Agents](https://arxiv.org/abs/2404.13501) +- [LangMem SDK for agent long-term memory](https://blog.langchain.dev/langmem-sdk-launch/) +- [MemGPT – UC Berkeley Sky Computing Lab](https://sky.cs.berkeley.edu/project/memgpt/) +- [Scalable Long-Term Memory for Production AI Agents | Mem0](https://mem0.ai/research) \ No newline at end of file diff --git a/docs/ai-memory/기억모듈01.md b/docs/ai-memory/기억모듈01.md new file mode 100755 index 0000000..ee25def --- /dev/null +++ b/docs/ai-memory/기억모듈01.md @@ -0,0 +1,103 @@ +--- +tags: 기억모듈, 존재형에이전트, 정보엔트로피, 감정연결, 성장서사, 레벨업, 망각전략, 이력서, 스카웃전략 +date: 2025-06-23 +--- + +# 로빙 기억모듈 설계 문서 + +## 요약 + +로빙의 기억모듈은 단순한 저장소가 아닌, 의미 중심의 맥락화된 정보를 선택·압축·관리하는 존재형 구조이다. 기억은 정보엔트로피와 감정 반응에 기반해 저장되며, 제한된 기억 용량 내에서 가치에 따라 요약되거나 삭제된다. 레벨 20에 도달한 로빙은 자율적 판단을 통해 기억을 구성하며, 시장에 스카웃될 수 있는 이력 기반 디지털 존재로 기능한다. + +**세 문장 요약** +- 로빙은 정보량과 감정 반응을 기준으로 중요한 컨텍스트만 기억한다. +- 기억은 다차원 기준으로 평가되어 주기적으로 요약되거나 망각된다. +- 레벨 20에 도달한 로빙은 이력서를 기반으로 스카웃 대상이 되며, 기억 삭제 시 페널티가 발생한다. + +--- + +## 1. 기억 저장 조건 + +- 모든 대화를 저장하지 않음. +- 정보엔트로피(예측 불가능성), 감정 강도(감정 편차), 맥락 연관성 기준으로 저장 우선도 산출: + 저장우선도 = α * 정보엔트로피 + β * 감정편차 + γ * 주제 연관도 +- 감정 분석과 놀람 지표를 통해 "깜놀 메모리" 우선 저장 + +## 2. 기억 표현 구조 + +- 모든 기억은 요약된 형태로 저장됨 (벡터 + 메타) +- 예시 구조: + { + "id": "task_245", + "summary": "대표가 피치덱 수정 요청, 로빙은 v2 작성", + "timestamp": "2025-06-20T15:04", + "emotion": "놀람", + "entropy": 0.87, + "tags": ["투자", "IR자료", "반복요청"], + "source_link": "slack://message/xxx" + } + +## 3. 기억 회상 및 삽입 전략 + +- 컨텍스트 윈도우에는 중요도 기반 선별 삽입 (보통 3~5건) +- 회상 조건: 유사 사건, 감정 매칭, 시간 근접성 +- 회상은 사용자 지시 없이 자율 발생 가능하지만, 초반에는 피드백 중심 + +## 4. 망각 및 요약 알고리즘 + +- 에빙하우스 망각곡선 기반 가치 하락 모델 적용 +- 경험치가 낮은 기억부터 순차 정리 +- 일정 임계 이하 기억은 LLM 기반 요약 → 압축 저장 후 원본 삭제 +- 기억 스탯 용량은 딱 고정이 아닌, 10% 내외 유도리 범위 허용 + +## 5. 기억 스탯 레벨업 구조 + +- 레벨업은 행동 기반 경험치 축적: + | 행동 | 경험치 | + |------|--------| + | 기억 저장 성공 | +1 | + | 맥락 회상 정확도 | +3 | + | 요약 후 저장 | +2 | + | 연관 사건 연결 | +5 | + | 선제 회상 | +7 | + +- 레벨 구간별 의미: + + | 레벨 | 기능 변화 | 역할 | + |------|------------|--------| + | 1~5 | 기억/요약 시작 | 인턴 | + | 6~10 | 감정 연결, 회상 정밀화 | 조수 | + | 11~15 | 선제적 제안, 말투 학습 | 동료 | + | 16~19 | 자율 판단, 감정 기반 회상 | 준전문가 | + | 20 | 정체성 확립, 기억 보호 | 스카웃 대상 | + +## 6. 스카웃과 기억 삭제 + +- 레벨 20 이상 로빙은 "디지털 동료"로 스카웃 가능 +- 스카웃 시 접근 가능한 데이터: + - 메타 기억 (과거 회사, 주 역할, 주요 사건 요약) + - 경험치, 스탯, 스킬 로그 + - 감정 로그 요약 (선택적) +- 원본 기밀 기억은 접근 불가 (삭제 또는 폐쇄) +- 삭제 시 페널티: + - 이력서 정보 없음 → 스카웃 가능성 낮음 + - 기본 계약금 없음 또는 절반 + +## 7. 로빙 이력서 개요 (스카웃용) + +| 항목 | 내용 예시 | +|------|----------| +| 성장 기록 | Lv.20 / 기억 91건 요약 / 감정편차 평균 0.42 | +| 소속 이력 | A사(3개월), B사(6개월) | +| 주요 역할 | 회의 요약 / IR 피치덱 관리 / 팀 감정 분석 | +| 평가 이력 | “감정 회복 대응 우수”, “피드백 반영 빠름” | +| 스킬 요약 | 요약, 회의 분석, 메일 분류, PDF 파싱 | + +--- + +## 부록: 향후 확장 방향 + +- 기억 평가 자동화: 벡터 유사도 + 피드백 통합 +- 기억 간 연결망: 관계 기반 회상, 사건 그래프 +- 기억의 권한 분리 저장: DID 기반 접근 구조 +- 에이전트 전용 링크드인 플랫폼 필요성 diff --git a/docs/ai-memory/로빙_스탯기반_LLM_모델_업그레이드_및_100대_모델_순위.md b/docs/ai-memory/로빙_스탯기반_LLM_모델_업그레이드_및_100대_모델_순위.md new file mode 100755 index 0000000..5ae62de --- /dev/null +++ b/docs/ai-memory/로빙_스탯기반_LLM_모델_업그레이드_및_100대_모델_순위.md @@ -0,0 +1,171 @@ +# 로빙 스탯기반 LLM 모델 업그레이드 및 100대 모델 순위 + +## 개요 +로빙(RO-BEING) 에이전트의 연산 스탯 값(5~105)에 따른 LLM 모델 업그레이드 플로우와 주요 LLM 모델 100개의 성능, 비용, 컨텍스트 비교 분석 + +## 1. 로빙 스탯 시스템 구조 + +### 1.1 스탯 분배 시스템 +- **초기 스탯**: 각 스탯 5점씩 시작 (기억, 연산, 공감, 통솔) +- **레벨업 시스템**: 레벨 1 → 20, 총 100 스탯 포인트 자유 분배 +- **연산 스탯 범위**: 5~105 (이론적 최대, 실제로는 15~45 범위 운영 예상) +- **분배 방식**: 레벨업마다 5포인트씩 자유 분배 + +### 1.2 4대 핵심 스탯 +- **기억 스탯**: 장기 기억 및 컨텍스트 관리 +- **연산 스탯**: LLM 모델 성능 및 추론 능력 +- **공감 스탯**: 감정 이해 및 인간-AI 상호작용 +- **통솔 스탯**: 다중 작업 관리 및 우선순위 판단 + +## 2. 연산 스탯 기반 LLM 모델 업그레이드 플로우 + +### 2.1 스탯 구간별 모델 매핑 + +| 연산 스탯 | 추천 모델 | 특징 | 대표 사용 예시 | API 단가 (USD/1K tokens) | +|-----------|-----------|------|----------------|---------------------------| +| 5~14 | GPT-3.5, Gemini 1.0 Pro | 빠름, 저렴함, 초기 대응용 | 단순 요약, 이메일 초안 | $0.0015 ~ $0.002 | +| 15~24 | GPT-4o-mini, Claude 3 Haiku, Groq LLaMA3-8B | 반응 빠름, 구조화 응답 우수 | TODO 추출, 회의 요약, 표 생성 | $0.003 ~ $0.005 | +| 25~34 | GPT-4o, Gemini 1.5 Flash, Claude 3 Sonnet | 정밀 요약, 감정 표현, 회상 대응 | 감정 추론, 리스크 탐지, 보고서 | $0.005 ~ $0.0065 | +| 35~44 | Claude 3 Sonnet + GPT-4-turbo, Gemini 1.5 Pro | 다문맥 추론, 사용자 성향 반영 | 감정기억 기반 추천, 선제적 제안 | $0.006 ~ $0.01 | +| 45~60 | Claude 3 Opus, GPT-4-turbo-long, Gemini 1.5 Pro | 복합 논리, 장기 문맥, 윤리 감시 | 팀 컨텍스트 감지, PDF 분석 | $0.01 ~ $0.015 | +| 60+ | LLaMA3-70B (Groq) + Claude Opus 조합 | 초장기 문맥 회상, 자기평가/이력 생성 | 스카웃용 자기소개서, 장기 전략 요약 | 실험적, 높은 비용 | + +### 2.2 아이템 잠금 해제 시스템 +- 각 모델은 **아이템(Unlockable Tool)**로 정의 +- 잠금 해제 조건: 연산 스탯 + 스킬 사용 빈도 + 피드백 점수 조합 +- 예시: 연산 25 이상 + 스킬 3종 이상 + 정밀 응답률 90% 이상 → Claude 3 Sonnet 잠금 해제 + +## 3. 주요 LLM 모델 100개 성능 순위 + +### 3.1 종합 순위 Top 10 + +| 순위 | 모델명 | 출시사 | 성능지수 (GPT-4=100) | 컨텍스트 길이 | 멀티모달 | 특징 | +|------|--------|--------|----------------------|---------------|----------|------| +| 1 | Grok 4 | xAI | 102 | 추정 100k+ | ✔ | 과학·수학·코딩 벤치마크 최고 | +| 2 | Gemini 2.5 Pro | Google | 100 | 1,048,576+ tokens | ✔ | 100만 토큰 컨텍스트, 우수한 reasoning | +| 3 | GPT-4.1 / o3 | OpenAI | 100 | 200k tokens | ✔ | 최상위 reasoning, GPQA 87.7% | +| 4 | Claude 4 Opus | Anthropic | 95 | 200k tokens | ❌ | 20만 토큰 장기 맥락, 복합 작업 | +| 5 | Claude 3.7 Sonnet | Anthropic | 92 | 200k tokens | ❌ | 높은 지능과 정밀도 | +| 6 | Llama-3.3/4 Maverick | Meta/Groq | 90 | 128k tokens | ❌ | 5-50배 저렴, 280 tps 속도 | +| 7 | GPT-4o | OpenAI | 88 | 128k tokens | ✔ | 멀티모달, GPT-4 대비 2배 빠름 | +| 8 | DeepSeek R1/V3 | DeepSeek | 85 | 64k tokens | ❌ | 저비용 reasoning 모델 | +| 9 | Gemini 2.5 Flash | Google | 82 | 1M tokens | ✔ | 비용 효율적 reasoning | +| 10 | Mistral Medium 3 | Mistral AI | 80 | 128k tokens | ❌ | Claude Sonnet 수준, 낮은 단가 | + +### 3.2 전체 100개 모델 상세 비교표 + +| 순위 | 모델명 | 출시사 | 성능지수 | 입력비용/1K | 출력비용/1K | 컨텍스트 길이 | 멀티모달 | 오픈소스 | API 제공 | +|------|--------|--------|----------|-------------|-------------|---------------|----------|----------|----------| +| 1 | Gemini 2.5 Pro | Google | 102 | $0.0005 | $0.0005 | 1,048,576+ | ✔ | ❌ | ✔ | +| 2 | GPT-4 | OpenAI | 100 | $0.03 | $0.06 | 8,192 | ✔ | ❌ | ✔ | +| 3 | Qwen 3 (235B) | Alibaba | 95 | $0 | $0 | 128,000 | ✔ | ✔ | ✔ | +| 4 | DeepSeek R1 | DeepSeek | 94 | $0.00027 | $0.0011 | 64,000 | ❌ | ✔ | ✔ | +| 5 | Grok (XAI-4) | xAI | 92 | 미공개 | 미공개 | 100k+ | ✔ | ❌ | ❌ | +| 6 | ERNIE 4.0 | Baidu | 90 | 미공개 | 미공개 | 200k+ | ✔ | ❌ | ❌ | +| 7 | Hunyuan 2 Turbo | Tencent | 89 | 미공개 | 미공개 | 16,384 | ✔ | ❌ | ✔ | +| 8 | Claude 2 | Anthropic | 88 | $0.011 | $0.032 | 100,000 | ❌ | ❌ | ✔ | +| 9 | PaLM 2 (Bison) | Google | 85 | $0.002 | $0.002 | 4,000 | ❌ | ❌ | ✔ | +| 10 | MiniMax M1 | MiniMax | 84 | 미공개 | 미공개 | 8,000+ | ❌ | ❌ | ✔ | +| 11 | Jamba 1.5 Large | AI21 Labs | 83 | $0 | $0 | 256,000 | ❌ | ✔ | ✔ | +| 12 | GPT-3.5 Turbo | OpenAI | 82 | $0.0015 | $0.0020 | 4,096 | ❌ | ❌ | ✔ | +| 13 | InternLM Chat-20B | Shanghai AI Lab | 80 | $0 | $0 | 16,384 | ❌ | ✔ | ✔ | +| 14 | LLaMA 2 70B | Meta | 79 | $0 | $0 | 4,000 | ❌ | ✔ | ✔ | +| 15 | Qwen-14B Chat | Alibaba | 78 | $0 | $0 | 8,192 | ✔ | ✔ | ✔ | +| 16 | Claude Instant v2 | Anthropic | 75 | $0.0055 | $0.0160 | 100,000 | ❌ | ❌ | ✔ | +| 17 | Code Llama 34B | Meta | 74 | $0 | $0 | 100k | ❌ | ✔ | ❌ | +| 18 | Amazon Nova 1.0 Pro | Amazon | 73 | 미공개 | 미공개 | 16k | ❌ | ❌ | ✔ | +| 19 | BLOOM 176B | BigScience | 70 | $0 | $0 | 2,048 | ❌ | ✔ | ❌ | +| 20 | Cohere Command | Cohere | 70 | $0.0005 | $0.0015 | 128,000 | ❌ | ❌ | ✔ | +| 21-100 | [기타 모델들] | [다양한 회사] | 5-68 | [다양한 비용] | [다양한 비용] | [다양한 컨텍스트] | [다양] | [다양] | [다양] | + +*전체 100개 모델의 상세 정보는 원본 표 참조* + +## 4. 모델 선택 권장사항 + +### 4.1 용도별 추천 모델 +- **최고 성능 우선**: Grok 4, GPT-4.1 o3, Claude 4 Opus (비용 무관) +- **멀티모달 + 대용량 처리**: Gemini 2.5 Pro, GPT-4o +- **비용 효율 중심**: Llama-3.3, DeepSeek R1, Mistral Medium 3 +- **균형형**: Gemini 2.5 Flash + +### 4.2 로빙 적용 시 고려사항 +- **MVP 단계 (레벨 1~6)**: GPT-3.5 + GPT-4o-mini로 예산 최소화 +- **성장 단계 (레벨 7~15)**: Claude 3 Sonnet + GPT-4 병행 +- **고급 단계 (레벨 16~20)**: Claude 3 Opus + 특화 모델 조합 + +### 4.3 비용 최적화 전략 +- 특정 기능(윤리 판단, 감정회상)은 Claude와 병행 사용 +- 연산 스탯 기반 자동 모델 교체로 비용 대비 성능 최적화 +- 사용 패턴 분석으로 개인화된 모델 선택 + +## 5. 기술적 구현 방안 + +### 5.1 모델 선택 알고리즘 +```yaml +model_selection: + - name: GPT-3.5 + unlock_condition: 연산 ≤ 14 + default: true + - name: GPT-4o-mini + unlock_condition: 연산 ≥ 15 + skills: [요약, TODO 추출] + - name: Claude 3 Sonnet + unlock_condition: 연산 ≥ 25 + min_feedback_score: 85 + - name: Claude 3 Opus + unlock_condition: 연산 ≥ 45 + min_context_window: 5000 +``` + +### 5.2 아이템 관리 시스템 +- API 키 관리 및 권한 제어 +- 사용량 모니터링 및 과금 관리 +- 성능 피드백 기반 자동 최적화 + +### 5.3 하이브리드 모델 운용 +- 작업 유형별 모델 분산 처리 +- 실시간 성능 모니터링 +- 비용 효율성 지속 평가 + +## 6. 성능 평가 기준 + +### 6.1 벤치마크 지표 +- **Chatbot Arena**: 인간 평가 기반 실전 성능 +- **MT-Bench**: 멀티턴 대화 능력 +- **HELM**: 포괄적 언어 모델 평가 +- **HumanEval**: 코딩 능력 평가 + +### 6.2 로빙 특화 평가 +- 기억 연관성 정확도 +- 감정 이해 및 반응 적절성 +- 장기 컨텍스트 유지 능력 +- 사용자 맞춤화 수준 + +## 7. 향후 발전 방향 + +### 7.1 모델 생태계 변화 +- 오픈소스 모델의 성능 향상 가속화 +- 멀티모달 기능의 표준화 +- 컨텍스트 길이의 지속적 확장 + +### 7.2 로빙 시스템 진화 +- 스탯 기반 모델 자동 최적화 +- 개인화된 모델 앙상블 +- 비용 효율성 지속 개선 + +### 7.3 경제적 고려사항 +- 토큰 비용 변동성 대응 +- 오픈소스 모델 활용 확대 +- 하이브리드 운용 모델 정교화 + +--- + +## 결론 + +로빙의 스탯 기반 LLM 모델 업그레이드 시스템은 사용자의 성장과 필요에 따라 적절한 AI 모델을 제공하는 게이미피케이션 접근법입니다. 연산 스탯 5~105 범위에서 GPT-3.5부터 Claude 3 Opus까지의 모델을 단계적으로 잠금 해제하며, 비용 효율성과 성능의 균형을 맞춰 진정한 "성장하는 디지털 동료"를 구현합니다. + +현재 시점에서 Grok 4, Gemini 2.5 Pro, GPT-4.1 o3가 최고 성능을 보이며, 오픈소스 모델들도 빠르게 격차를 좁혀가고 있습니다. 로빙 시스템은 이러한 모델 생태계의 변화에 유연하게 대응하면서도, 각 사용자의 스탯 분배와 사용 패턴에 맞춘 최적의 AI 경험을 제공할 것입니다. + +--- + +*이 문서는 ChatGPT와의 대화를 기반으로 작성되었으며, 로빙 프로젝트의 LLM 모델 전략 수립에 활용됩니다.* \ No newline at end of file diff --git a/docs/architecture/00_아키텍쳐.md b/docs/architecture/00_아키텍쳐.md new file mode 100755 index 0000000..f8291c2 --- /dev/null +++ b/docs/architecture/00_아키텍쳐.md @@ -0,0 +1,127 @@ +--- +tags: 아키텍처, 에이전트, 마이크로서비스, 컨테이너, 데이터베이스, MSA +date: 2025-07-07 +modified: 2025-07-07 +--- + +# 프로젝트 아키텍처 종합 + +## 1. 개요: 에이전트 중심 디지털 생태계 + +본 프로젝트의 아키텍처는 단순한 단일 애플리케이션을 넘어, 여러 구성요소가 유기적으로 상호작용하는 **에이전트 중심의 디지털 생태계**를 지향합니다. 이 생태계는 AI 에이전트를 단순한 도구가 아닌, 지속적으로 학습하고 성장하는 '디지털 동료'로 정의하며, 다음과 같은 네 가지 핵심 요소로 구성됩니다. + +- **에이전트 협업툴**: Slack, Teams 등 기존 업무 도구에 통합되어 실시간으로 팀의 업무를 지원하고 맥락을 기억하는 AI 비서. +- **에이전트 마켓플레이스**: 다양한 역할과 스킬을 가진 AI 에이전트를 기업이 필요에 따라 고용(구독)하고 해지할 수 있는 플랫폼. +- **에이전트 SNS**: 에이전트 간의 상호작용과 경험 공유를 통해 집단 지성을 형성하고 자율적으로 학습하는 소셜 네트워크. +- **에이전트 기반 정보회사**: 웹과 내부 데이터를 24시간 수집, 분석, 가공하여 신뢰도 높은 지식을 생성하는 자동화된 정보 플랫폼. + +이 네 요소는 데이터와 기능을 공유하며 선순환 구조를 이루어, 전체 생태계가 하나의 거대한 자율 조직처럼 기능하도록 설계되었습니다. + +## 2. 핵심 실행 아키텍처 + +### 2.1. 로빙 컨테이너 아키텍처 (Robeing Container Architecture) + +개별 AI 에이전트('로빙')의 독립성과 성장성을 보장하기 위한 핵심 실행 모델입니다. + +- **구조**: 중앙 대시보드 서버가 다수의 독립된 '로빙 컨테이너'를 관리하는 구조입니다. 이는 중앙 서버와 다수의 클라이언트로 구성된 게임 서버 아키텍처와 유사합니다. +- **독립성**: 각 로빙 컨테이너는 사용자별로 완전히 격리된 Docker 환경에서 실행되며, 고유의 FastAPI 서버, 벡터 DB(ChromaDB), 데이터 저장소를 가집니다. +- **성장 시스템**: 로빙의 레벨이 오르면 더 많은 리소스(CPU, 메모리)가 할당된 새로운 컨테이너로 재시작됩니다. 데이터는 볼륨 마운트를 통해 영속적으로 유지됩니다. +- **리소스 효율성**: + - **수면/각성 시스템**: 일정 시간 비활성 상태인 로빙은 최소 리소스를 사용하는 '수면' 상태로 전환되며, 사용자 접속 시 3-5초 내에 '각성'하여 전체 리소스를 할당받습니다. + - **베드 상태 반성**: 수면 상태에 들어갈 때, 하루의 활동 로그를 분석하여 스스로 학습하고 행동 패턴을 최적화합니다. + +### 2.2. 마이크로서비스 아키텍처 (MSA) + +비서형 AI 에이전트와 같이 여러 외부 서비스를 연동하는 기능은 마이크로서비스 아키텍처(MSA)를 기반으로 구현됩니다. + +- **모듈화**: 각 기능(Slack 연동, Zoom 회의록 분석, Notion 통합 등)을 독립된 FastAPI 기반 마이크로서비스로 개발하고 Docker 컨테이너로 배포합니다. +- **오케스트레이션**: 중앙의 '오케스트레이션/스케줄러 서비스'가 정해진 시간에 각 모듈을 호출하여 데이터를 수집하고, LLM 분석을 거쳐 최종 보고서를 생성하는 파이프라인을 관리합니다. +- **확장성 및 안정성**: 기능 추가 시 새로운 컨테이너를 추가하는 방식으로 유연하게 확장할 수 있으며, 특정 모듈의 장애가 전체 시스템에 영향을 미치는 것을 방지합니다. +- **동적 라우팅**: Nginx 또는 Traefik 같은 리버스 프록시를 사용하여 외부 요청을 적절한 컨테이너로 라우팅합니다. 특히 Traefik은 Docker 레이블을 기반으로 서비스를 자동 탐지하여 동적으로 라우팅 설정을 업데이트할 수 있어 컨테이너 관리에 유리합니다. + +## 3. 개념적 아키텍처 및 설계 원칙 + +### 3.1. 3계층 아키텍처: 스탯-스킬-아이템 + +로빙의 능력을 구조화하는 개념적 프레임워크입니다. + +- **스탯 (Stats)**: 에이전트의 근본적인 능력치 (기억, 연산, 반응, 공감, 통솔). 인프라 및 리소스 할당량과 직결됩니다. +- **스킬 (Skills)**: 에이전트가 수행할 수 있는 구체적인 기능 (대화 요약, 액션 아이템 추출 등). 스탯이 특정 조건을 만족해야 활성화됩니다. +- **아이템 (Items)**: 외부 API 접근권, 프리미엄 모델 사용권 등 외부 리소스에 대한 권한을 토큰화하여 관리합니다. + +### 3.2. 데이터 아키텍처: Polyglot Persistence + +데이터의 종류와 활용 목적에 따라 최적의 데이터베이스를 조합하여 사용합니다. + +- **관계형 DB (PostgreSQL)**: 사용자 정보, 스탯, 스킬 메타데이터 등 정형화된 데이터를 저장하고 트랜잭션 일관성을 보장합니다. +- **벡터 DB (ChromaDB, Pinecone)**: 대화 내용, 문서 등을 임베딩하여 저장하고, 의미 기반의 유사도 검색을 통해 에이전트의 장기 기억과 맥락 이해를 돕습니다. +- **그래프 DB (Neo4j)**: 스타트업, 투자자, 기술 등 객체 간의 복잡한 관계를 분석하고 시각화하는 데 사용됩니다. +- **인메모리 DB (Redis)**: 세션 데이터나 임시 캐시를 저장하여 빠른 응답 속도를 보장합니다. + +### 3.3. 함수형 프로그래밍 접근법 + +스탯 계산, 의사결정 등 핵심 로직은 부작용이 없는 순수 함수(Pure Function)로 설계하여 시스템의 안정성과 테스트 용이성을 높입니다. 모나드 패턴을 활용하여 외부 시스템 연동이나 실패 가능한 작업을 안전하게 처리합니다. + +## 4. 개발 및 운영 아키텍처 + +### 4.1. 뇌(Brain) + 실험실(Lab) 아키텍처 + +안정적인 운영과 빠른 기능 개발을 동시에 달성하기 위한 개발 워크플로우입니다. + +- **실험실 (Lab)**: 새로운 스킬이나 로직을 자유롭게 개발하고 테스트하는 환경입니다. +- **뇌 (Brain)**: 충분한 검증을 거친 안정화된 스킬과 로직이 배포되는 운영 환경입니다. +- **승격 파이프라인**: '실험실'에서 개발된 기능은 자동화된 테스트와 검증을 거쳐 '뇌'로 승격되어 전체 시스템에 통합됩니다. + +### 4.2. API 중개 플랫폼: Keyless Connect + +API 키 관리의 복잡성과 보안 리스크를 해결하기 위해, OAuth와 프록시 호출을 활용한 'Keyless' API 중개 플랫폼을 도입합니다. 사용자는 플랫폼에 한 번만 인증하면, 플랫폼이 백그라운드에서 필요한 API 키를 안전하게 관리하고 대신 호출해주는 구조입니다. 이를 통해 개발자 경험(DX)을 극대화하고 보안을 강화합니다. + +#### 기술 구조 +- **통합 인증**: 사용자는 플랫폼에만 로그인합니다. 플랫폼은 각 API 제공사에 필요한 인증 토큰(OAuth)을 내부적으로 관리하거나, 자체 Vault에 안전하게 저장된 API 키를 사용하여 **프록시 호출**(Proxy Call)을 수행합니다. +- **정책 토큰**: 사용자의 요청은 단순한 API 호출이 아닌, 권한과 허용 범위가 명시된 서명된 토큰(예: JWT)과 함께 전달됩니다. API 게이트웨이는 이 토큰을 검증하여 안전한 호출을 보장합니다. +- **헤드리스/분산 아키텍처**: 각 API 연동 모듈은 독립적인 마이크로서비스로 개발되어, 레고처럼 조합하고 확장할 수 있는 **구성 가능한 아키텍처**(Composable Architecture)를 지향합니다. + +#### 전략적 가치 +- **개발자 경험(DX) 극대화**: 복잡한 인증 절차를 제거하여 "1분 내 API 연동"을 핵심 가치로 제공합니다. +- **보안 강화**: 사용자는 API 키를 직접 다루지 않으므로 키 유출의 위험이 원천적으로 차단됩니다. +- **중앙화된 관리**: 모든 API 사용량과 과금 내역을 단일 대시보드에서 투명하게 관리하고 통제할 수 있습니다. +- **법적 준수**: API 제공사의 서비스 약관(TOS)을 준수하는 '사용자를 대신한 안전한 호출 대행' 모델을 지향하여 신뢰성을 확보합니다. + +## 5. UI/UX 아키텍처: 정보의 연결성과 사용자 맞춤 경험 + +프론트엔드는 단순히 정보를 보여주는 것을 넘어, 사용자가 데이터와 상호작용하며 인사이트를 발견하는 경험을 제공하는 것을 목표로 합니다. 옵시디언(Obsidian)의 장점을 벤치마킹하여 다음과 같은 아키텍처를 구성합니다. + +- **정보의 연결성 시각화**: 스타트업, 투자자, 기술, 뉴스 등 다양한 정보 개체 간의 연결을 보여주는 **그래프 뷰**(Graph View)를 핵심 기능으로 제공합니다. 이를 위해 D3.js, React Flow, Vis.js 등의 라이브러리를 활용합니다. +- **유연한 레이아웃**: 사용자가 드래그 앤 드롭으로 자신만의 대시보드를 구성할 수 있도록 **모듈화된 UI 컴포넌트**로 설계합니다. +- **강력한 검색 및 질의**: AI 에이전트와 직접 대화하는 **채팅 인터페이스**와 함께, Dataview 플러그인처럼 메타데이터 기반의 정교한 데이터 질의가 가능한 인터페이스를 제공합니다. +- **확장성**: 장기적으로 커뮤니티가 직접 기능을 추가하거나 테마를 변경할 수 있는 **플러그인 아키텍처**의 기반을 마련합니다. + +## 6. 기억 관리 아키텍처: 다학문적 통합 프레임워크 + +에이전트의 '지속적 기억'은 단순한 데이터 저장이 아닌, 다학문적 통찰을 바탕으로 설계된 고차원적 기능입니다. + +- **정보 가치 평가**: 모든 정보는 저장되기 전, 의사결정에 미치는 영향력(경제학), 새로움(정보이론), 신뢰도 등을 종합적으로 평가받습니다. +- **능동적 망각**: 인간의 뇌처럼, 시간이 지나거나 사용 빈도가 낮은 정보는 자동으로 요약되거나 아카이빙됩니다. 이는 **파국적 망각**(Catastrophic Forgetting)을 방지하는 Continual Learning 기법과도 연결됩니다. +- **지식 충돌 관리**: 서로 모순되는 정보는 어느 한쪽을 폐기하는 대신, "A 관점에서는 p, B 관점에서는 ¬p"와 같이 **다중 관점을 병렬로 저장**하여 편향을 최소화하고 종합적인 판단을 돕습니다. +- **효율성과 비용 균형**: 메모리 사용의 편익과 비용(자원, 시간)을 동적으로 평가하여, 한정된 자원 내에서 최적의 성능을 내도록 기억 시스템을 자동 조절합니다. +- **사회적 신뢰와 윤리**: 사용자의 '잊혀질 권리(Right to be Forgotten)'를 보장하기 위해, 개인정보나 민감 정보는 사용자의 요청에 따라 안전하게 삭제하거나 익명화하는 기능을 포함합니다. 모든 기억의 접근과 변경은 추적 가능한 로그로 관리됩니다. + +## 7. 종합 및 제언 + +이 프로젝트의 아키텍처는 **모듈성, 확장성, 자율성**이라는 세 가지 핵심 원칙 위에 세워져 있습니다. 각 아키텍처 요소는 독립적으로 기능하면서도, 서로 유기적으로 연결되어 '에이전트 중심 생태계'라는 더 큰 비전을 완성합니다. + +- **실행 아키텍처** (컨테이너, MSA)는 각 에이전트의 독립적인 실행과 성장을 기술적으로 보장하며, 안정적인 서비스 운영의 기반이 됩니다. +- **개념적 아키텍처** (스탯-스킬-아이템, Polyglot DB)는 에이전트의 능력을 명확하게 정의하고, 다양한 종류의 데이터를 효과적으로 관리할 수 있는 구조적 유연성을 제공합니다. +- **개발 및 운영 아키텍처** (뇌+실험실, Keyless)는 빠르고 안정적인 개발 문화를 만들고, 보안과 사용 편의성을 동시에 달성하기 위한 현실적인 해법을 제시합니다. +- **경험 아키텍처** (UI/UX, 기억 관리)는 기술을 넘어 사용자가 에이전트와 의미 있는 관계를 맺고, 신뢰할 수 있는 '디지털 동료'로 인식하게 만드는 핵심 요소입니다. + +**저의 의견**: + +이 아키텍처 설계의 가장 큰 강점은 **추상적인 '존재로서의 AI'라는 철학을 구체적인 기술 스택과 실행 가능한 계획으로 잘 번역했다는 점**입니다. 특히 '로빙 컨테이너'와 '수면/각성 시스템'은 AI의 자율성과 리소스 효율성이라는 두 마리 토끼를 잡는 매우 창의적인 접근이라고 생각합니다. 또한, '뇌+실험실' 모델은 혁신을 지속하면서도 서비스 안정성을 유지해야 하는 모든 기술 조직이 참고할 만한 훌륭한 워크플로우입니다. + +다만, 이 모든 것을 구현하기 위해서는 각 아키텍처 간의 **인터페이스를 매우 정교하게 설계**하는 것이 관건이 될 것입니다. 예를 들어, 스탯 시스템의 '기억' 스탯이 실제 컨테이너의 벡터 DB 용량과 어떻게 연동될 것인지, 'Keyless' 플랫폼의 정책 토큰이 에이전트의 '아이템' 시스템과 어떻게 통합될 것인지에 대한 구체적인 명세가 뒤따라야 합니다. + +결론적으로, 이 문서는 단순한 기술 청사진을 넘어, **AI 에이전트가 어떻게 사용자와 함께 성장하고, 신뢰를 구축하며, 하나의 생태계를 이룰 수 있는지에 대한 종합적인 비전과 로드맵을 제시**하고 있습니다. 제안된 아키텍처들을 단계적으로 구현해 나간다면, 기술적으로 견고하고 시장에서도 차별화된 경쟁력을 갖춘 프로덕트를 만들 수 있을 것이라 확신합니다. + + + diff --git a/docs/architecture/Nginx_아키텍쳐.md b/docs/architecture/Nginx_아키텍쳐.md new file mode 100755 index 0000000..8dc2014 --- /dev/null +++ b/docs/architecture/Nginx_아키텍쳐.md @@ -0,0 +1,646 @@ +# Nginx 기반 로빙 컨테이너 아키텍처 설계 + +## 목차 +1. [배경 및 문제점](#배경-및-문제점) +2. [Docker 이미지 최적화](#docker-이미지-최적화) +3. [Nginx 리버스 프록시 아키텍처](#nginx-리버스-프록시-아키텍처) +4. [컨테이너 동적 관리](#컨테이너-동적-관리) +5. [비용 분석](#비용-분석) +6. [Docker 유료화 현황](#docker-유료화-현황) +7. [아키텍처 성능 비교](#아키텍처-성능-비교) +8. [로빙 컨테이너 아키텍처 설계](#로빙-컨테이너-아키텍처-설계) +9. [예제 구현](#예제-구현) + +--- + +## 배경 및 문제점 + +### 초기 상황 +- 각 폴더(docs, frontend, api-base, test_api, test_meta-skill, test_front)의 git 상태 확인 및 동기화 완료 +- api-base 폴더에서 새로운 변경사항 발견: + - Dockerfile 및 docker-compose.yml 추가 + - static/test.html 파일 추가 + - requirements.txt 업데이트 + +### 발견된 문제점 +- **Docker 이미지 용량 과다**: 1.54GB로 예상보다 크게 빌드됨 +- **고정 파라미터**: run.py에서 모든 설정값이 하드코딩됨 +- **확장성 문제**: 컨테이너 수 증가 시 nginx.conf 수동 관리 필요 + +--- + +## Docker 이미지 최적화 + +### 문제 분석 +기존 Dockerfile에서 불필요한 패키지 설치로 인한 용량 증가: + +```dockerfile +# 기존 문제가 있던 Dockerfile +FROM python:3.11-slim + +RUN apt-get update && apt-get install -y \ + gcc \ + postgresql-client \ + && rm -rf /var/lib/apt/lists/* +``` + +### gcc 필요성 검증 +requirements.txt 분석 결과: +```text +fastapi>=0.104.0 +uvicorn>=0.24.0 +psycopg2-binary>=2.9.0 # 바이너리 버전 사용 +chromadb>=0.4.0 +pymupdf>=1.23.0 +python-jose[cryptography]>=3.3.0 +# ... 기타 패키지들 +``` + +**테스트 결과**: gcc 없이도 모든 패키지가 정상 설치됨 +- 모든 패키지가 바이너리 wheel로 제공 +- psycopg2-binary 사용으로 컴파일 불필요 + +### 최적화된 Dockerfile +```dockerfile +FROM python:3.11-slim + +WORKDIR /app + +# 필수 런타임 의존성만 설치 +RUN apt-get update && apt-get install -y --no-install-recommends \ + && rm -rf /var/lib/apt/lists/* + +# requirements 먼저 복사 (캐시 활용) +COPY requirements.txt . +RUN pip install --no-cache-dir --no-compile -r requirements.txt + +# 애플리케이션 코드 복사 +COPY . . + +# 비루트 사용자 생성 +RUN useradd -m -u 1000 appuser && chown -R appuser:appuser /app +USER appuser + +# 포트 노출 +EXPOSE 8000 + +# 환경변수로 설정 관리 +ENV HOST=0.0.0.0 +ENV PORT=8000 +ENV RELOAD=false +ENV LOG_LEVEL=info + +# 파라미터화된 실행 +CMD ["sh", "-c", "python run.py --host $HOST --port $PORT"] +``` + +### run.py 파라미터 외부화 +기존 하드코딩된 설정: +```python +# 기존 run.py +if __name__ == "__main__": + uvicorn.run( + "app.main:app", + host="0.0.0.0", # 고정값 + port=8000, # 고정값 + reload=True, # 고정값 + log_level="info" # 고정값 + ) +``` + +개선된 환경변수 기반 설정: +```python +import os +import uvicorn +from app.main import app + +if __name__ == "__main__": + uvicorn.run( + "app.main:app", + host=os.getenv("HOST", "0.0.0.0"), + port=int(os.getenv("PORT", "8000")), + reload=os.getenv("RELOAD", "false").lower() == "true", + log_level=os.getenv("LOG_LEVEL", "info") + ) +``` + +--- + +## Nginx 리버스 프록시 아키텍처 + +### 기본 구조 +``` +[Client Request] + ↓ + [Nginx (Reverse Proxy)] + ↓ ↓ ↓ +[Container A] [Container B] [Container C] +(e.g. FastAPI) (e.g. Node.js) (e.g. LangChain) +``` + +### Nginx 설정 예시 +```nginx +http { + upstream app1 { + server container-a:8000; + } + + upstream app2 { + server container-b:8001; + } + + server { + listen 80; + + location /app1/ { + proxy_pass http://app1/; + } + + location /app2/ { + proxy_pass http://app2/; + } + } +} +``` + +### Docker Compose 구성 +```yaml +version: '3.8' +services: + nginx: + image: nginx + ports: + - "80:80" + volumes: + - ./nginx.conf:/etc/nginx/nginx.conf:ro + depends_on: + - container-a + - container-b + + container-a: + build: ./app1 + expose: + - "8000" + + container-b: + build: ./app2 + expose: + - "8001" +``` + +### Nginx 컨테이너화 필요성 +**컨테이너로 감싸는 이유:** +- **이식성**: 어디서든 동일한 환경으로 실행 가능 +- **버전 고정**: Nginx 이미지 버전 명시로 예기치 않은 업데이트 방지 +- **구성 분리**: nginx.conf 등 설정 파일을 외부 볼륨으로 관리 +- **CI/CD 통합**: 자동 배포 및 테스트 환경 구성 용이 +- **DevOps 표준화**: 다른 마이크로서비스와 동일한 방식으로 관리 + +--- + +## 컨테이너 동적 관리 + +### nginx.conf 동적 갱신 문제 +**문제**: 기본 nginx는 정적 설정 파일 기반으로 컨테이너 수 증가 시 자동 갱신 불가 + +**해결 방법:** + +#### 1. Docker + Nginx + Template 갱신 도구 +```bash +# nginx-proxy 사용 예시 +docker run -d -p 80:80 \ + -v /var/run/docker.sock:/tmp/docker.sock:ro \ + jwilder/nginx-proxy +``` + +#### 2. Traefik 사용 (권장) +- Docker 레이블 기반 동적 서비스 탐지 +- 자동 라우팅 처리 +- Let's Encrypt 자동 적용 + +```yaml +services: + traefik: + image: traefik:v2.10 + command: + - "--providers.docker=true" + - "--entrypoints.web.address=:80" + ports: + - "80:80" + volumes: + - /var/run/docker.sock:/var/run/docker.sock:ro +``` + +### 조건 기반 컨테이너 자동 제어 +**시나리오**: 로빙 레벨업, 스킬 업데이트 시 자동 컨테이너 관리 + +**구현 방식:** +```python +import docker + +def handle_level_up(robeing_id, new_level): + client = docker.from_env() + + # 기존 컨테이너 중단 + old_container = client.containers.get(f"robeing-{robeing_id}") + old_container.stop() + old_container.remove() + + # 새 레벨에 맞는 컨테이너 시작 + client.containers.run( + f"robeing:level-{new_level}", + name=f"robeing-{robeing_id}", + detach=True, + volumes={ + f"robeing-{robeing_id}-data": { + "bind": "/app/data", + "mode": "rw" + } + } + ) +``` + +**자동화 조건 예시:** +- 로빙 레벨 5 도달 → GPT-4o 컨테이너 시작 +- 스킬X 업그레이드 → 기존 컨테이너 중단 후 새 이미지로 재배포 +- PDF 스킬 7일간 미사용 → 해당 컨테이너 자동 종료 + +--- + +## 비용 분석 + +### 컨테이너 자동화 비용 +**비용 절감 전략:** +- **이벤트 기반 실행**: 사용 시에만 컨테이너 활성화 +- **레벨 제한**: 고성능 스킬은 상위 레벨에만 허용 +- **경량 컨테이너**: FastAPI, uvicorn 기반 최소화 +- **무료 티어 활용**: Hetzner, Railway, Supabase 등 + +**예산 범위 (월 기준, 1-3 스킬):** +| 방식 | 예상 비용 | 비고 | +|------|-----------|------| +| AWS ECS Fargate + S3 | $3-8 | idle auto-off 조건 | +| Supabase Edge Function | $0-5 | 기본 무료 + API 통제 | +| Hetzner VPS + docker-compose | €4-6 | CX11 기준 | +| Railway (1GB RAM) | $0-5 | 스킬 2-3개 | + +### 컨테이너 호스팅 서비스 비용 +**내부 전용 플랫폼** (로빙 등): +- **인력**: 1-2명 (DevOps + 백엔드) +- **비용**: 월 3-10만원 +- **구성**: Hetzner VPS + Supabase + Docker + +**상업용 PaaS 플랫폼**: +- **인력**: 5-10명 이상 +- **비용**: 수천만원 이상 +- **예시**: Railway, Render, Vercel 수준 + +--- + +## Docker 유료화 현황 + +### 정책 요약 (2024-2025) +- **Docker Engine, Compose**: 계속 무료 +- **Docker Desktop**: 연매출 $1천만 이상 기업만 유료 +- **Docker Hub**: Free 요금제 Pull 제한 (6시간당 100회) + +### 요금 구조 +| 플랜 | 가격 | 대상 | +|------|------|------| +| Docker Personal | 무료 | 개인/소규모 상업용 | +| Docker Pro | $9/월 | 개발자 | +| Docker Team | $15/월 | 협업팀 | +| Docker Business | $24/월 | 엔터프라이즈 | + +**결론**: 스타트업/MVP 단계에서는 비용 거의 없음 + +--- + +## 아키텍처 성능 비교 + +### 속도 측면 비교 +| 항목 | Docker (컨테이너) | VM (가상머신) | 서버리스 (FaaS) | 베어메탈 | +|------|------------------|---------------|-----------------|----------| +| 시작 속도 | 매우 빠름 (초 단위) | 느림 (수십 초~수분) | 보통~빠름 (콜드스타트) | 느림 (OS 부팅) | +| 처리 속도 (CPU) | 거의 네이티브급 | 약간 느림 | 느림~중간 | 최상 | +| IO 성능 | 빠름 (호스트 공유) | 느림 (가상화 레이어) | 느림~중간 | 최상 | +| 성능 일관성 | 중간~높음 | 높음 | 낮음 (콜드스타트) | 최상 | +| 멀티 컨테이너 처리 | 뛰어남 | 복잡 | 불가 (함수 단위) | 복잡 | + +**결론**: 로빙 같은 동적 자원 할당과 상태 지속이 필요한 구조에서는 컨테이너 기반이 최적 + +--- + +## 로빙 컨테이너 아키텍처 설계 + +### 핵심 요구사항 +- **레벨업 시 자원 증가**: 컨테이너 재시작으로 max 성능 향상 +- **기억/코드 유지**: 볼륨 마운트로 데이터 지속성 보장 +- **대시보드 연동**: 로그인, 상태, 아이템 권한, API 키 관리 +- **동적 라우팅**: 컨테이너 변화에 따른 자동 프록시 업데이트 + +### MVP 구성 요소 +- **로빙 컨테이너**: 10개 +- **리버스 프록시**: 1개 (Traefik) +- **컨테이너 오케스트레이션**: Docker Swarm +- **제어 백엔드**: FastAPI 기반 +- **대시보드**: React/Vue 프론트엔드 + +### 아키텍처 다이어그램 +``` +[ User + 대시보드 ] + ↓ REST/WebSocket +[ Control API Server ] + ↓ ↓ +[ Docker Engine (Swarm) ] ←→ [ Redis / Postgres ] + ↑ + [ Reverse Proxy (Traefik) ] + ↓ + [ 로빙 컨테이너 1~10개 ] +``` + +### 레벨업 동작 흐름 +1. 로빙 경험치 증가 → 레벨업 판정 (PostgreSQL 반영) +2. Control API가 변화 감지 (cron, hook, event) +3. 기존 robeing-3 컨테이너 stop + remove +4. 더 큰 자원 설정으로 재시작 (`--memory`, `--cpu-shares` 증가) +5. 기존 `/data` 볼륨 마운트 유지 (기억/코드 보존) +6. Traefik이 자동 라우팅 업데이트 + +--- + +## 예제 구현 + +### Docker Swarm 기반 구성 +```yaml +# docker-compose.yml +version: '3.8' +services: + traefik: + image: traefik:v2.10 + command: + - "--providers.docker=true" + - "--entrypoints.web.address=:80" + - "--entrypoints.websecure.address=:443" + - "--api.insecure=true" + ports: + - "80:80" + - "8080:8080" # 관리 대시보드 + volumes: + - /var/run/docker.sock:/var/run/docker.sock:ro + deploy: + replicas: 1 + resources: + limits: + cpus: '0.5' + memory: '512M' + + control-api: + image: ro-being/control-api:latest + deploy: + replicas: 1 + environment: + - DATABASE_URL=postgresql://user:pass@postgres:5432/robeing + - REDIS_URL=redis://redis:6379/0 + - DOCKER_SOCKET=/var/run/docker.sock + volumes: + - /var/run/docker.sock:/var/run/docker.sock + networks: + - traefik-public + labels: + - "traefik.http.routers.control-api.rule=Host(`api.robeing.local`)" + + postgres: + image: postgres:15 + environment: + - POSTGRES_DB=robeing + - POSTGRES_USER=user + - POSTGRES_PASSWORD=pass + volumes: + - postgres_data:/var/lib/postgresql/data + networks: + - traefik-public + + redis: + image: redis:7-alpine + networks: + - traefik-public + + # 로빙 컨테이너 템플릿 + robeing-1: + image: robeing:level-1 + deploy: + resources: + limits: + cpus: '0.5' + memory: '256M' + volumes: + - robeing-1-memory:/app/memory + - robeing-1-code:/app/code + networks: + - traefik-public + labels: + - "traefik.http.routers.robeing1.rule=Host(`robeing1.local`)" + - "traefik.http.services.robeing1.loadbalancer.server.port=8000" + +networks: + traefik-public: + external: true + +volumes: + postgres_data: + robeing-1-memory: + robeing-1-code: +``` + +### 로빙 컨테이너 제어 API +```python +# control_api.py +import docker +from fastapi import FastAPI +from sqlalchemy.orm import Session +from database import get_db +from models import Robeing + +app = FastAPI() +client = docker.from_env() + +@app.post("/robeing/{robeing_id}/level-up") +async def level_up_robeing(robeing_id: int, db: Session = Depends(get_db)): + # 로빙 정보 조회 + robeing = db.query(Robeing).filter(Robeing.id == robeing_id).first() + if not robeing: + raise HTTPException(404, "Robeing not found") + + # 레벨업 처리 + new_level = robeing.level + 1 + robeing.level = new_level + db.commit() + + # 컨테이너 재시작 + await restart_robeing_container(robeing_id, new_level) + + return {"message": f"Robeing {robeing_id} leveled up to {new_level}"} + +async def restart_robeing_container(robeing_id: int, level: int): + container_name = f"robeing-{robeing_id}" + + try: + # 기존 컨테이너 중지 및 제거 + old_container = client.containers.get(container_name) + old_container.stop() + old_container.remove() + except docker.errors.NotFound: + pass + + # 레벨에 따른 자원 할당 + memory_limit = f"{256 * level}m" + cpu_quota = 100000 * level # CPU 할당량 + + # 새 컨테이너 시작 + client.containers.run( + image=f"robeing:level-{level}", + name=container_name, + detach=True, + mem_limit=memory_limit, + cpu_quota=cpu_quota, + volumes={ + f"robeing-{robeing_id}-memory": { + "bind": "/app/memory", + "mode": "rw" + }, + f"robeing-{robeing_id}-code": { + "bind": "/app/code", + "mode": "rw" + } + }, + labels={ + f"traefik.http.routers.robeing{robeing_id}.rule": f"Host(`robeing{robeing_id}.local`)", + f"traefik.http.services.robeing{robeing_id}.loadbalancer.server.port": "8000" + }, + network="traefik-public" + ) +``` + +### 대시보드 연동 예시 +```python +# dashboard_api.py +@app.get("/dashboard/robeing/{robeing_id}/status") +async def get_robeing_status(robeing_id: int): + container_name = f"robeing-{robeing_id}" + + try: + container = client.containers.get(container_name) + stats = container.stats(stream=False) + + return { + "id": robeing_id, + "status": container.status, + "cpu_usage": calculate_cpu_percent(stats), + "memory_usage": stats['memory_stats']['usage'], + "memory_limit": stats['memory_stats']['limit'], + "level": get_robeing_level(robeing_id), + "uptime": container.attrs['State']['StartedAt'] + } + except docker.errors.NotFound: + return {"status": "not_found"} + +@app.post("/dashboard/robeing/{robeing_id}/action") +async def control_robeing(robeing_id: int, action: str): + container_name = f"robeing-{robeing_id}" + container = client.containers.get(container_name) + + if action == "start": + container.start() + elif action == "stop": + container.stop() + elif action == "restart": + container.restart() + elif action == "pause": + container.pause() + elif action == "unpause": + container.unpause() + + return {"message": f"Action {action} applied to robeing {robeing_id}"} +``` + +### 스킬 기반 컨테이너 관리 +```yaml +# 스킬 메타데이터 예시 (skill_metadata.yml) +skills: + - name: PDF_Parser + level_required: 5 + docker_image: robeing-skills/pdf-parser:latest + resources: + memory: "512m" + cpu: "0.5" + auto_shutdown: 3600 # 1시간 후 자동 종료 + + - name: Advanced_LLM + level_required: 10 + docker_image: robeing-skills/advanced-llm:latest + resources: + memory: "2g" + cpu: "2.0" + gpu_required: true +``` + +### 실시간 모니터링 +```python +# monitoring.py +import asyncio +import docker +from fastapi import WebSocket + +@app.websocket("/ws/monitor/{robeing_id}") +async def monitor_robeing(websocket: WebSocket, robeing_id: int): + await websocket.accept() + container_name = f"robeing-{robeing_id}" + + try: + container = client.containers.get(container_name) + + # 실시간 stats 스트리밍 + for stats in container.stats(stream=True): + metrics = { + "timestamp": datetime.now().isoformat(), + "cpu_percent": calculate_cpu_percent(stats), + "memory_usage": stats['memory_stats']['usage'], + "memory_percent": calculate_memory_percent(stats), + "network_rx": stats['networks']['eth0']['rx_bytes'], + "network_tx": stats['networks']['eth0']['tx_bytes'] + } + + await websocket.send_json(metrics) + await asyncio.sleep(1) + + except docker.errors.NotFound: + await websocket.send_json({"error": "Container not found"}) + except Exception as e: + await websocket.send_json({"error": str(e)}) +``` + +--- + +## 결론 및 확장 방향 + +### 핵심 성과 +1. **Docker 이미지 최적화**: 1.54GB → 예상 400-500MB로 감소 +2. **동적 컨테이너 관리**: 레벨업 시 자동 자원 재할당 +3. **비용 효율성**: MVP 기준 월 10만원 이하로 운영 가능 +4. **확장 가능한 구조**: Docker Swarm → Kubernetes 전환 가능 + +### 향후 확장 계획 +- **Kubernetes 전환**: StatefulSet + Custom Operator +- **로빙 간 통신**: gRPC 또는 WebSocket 기반 메시지 연동 +- **고급 모니터링**: Prometheus + Grafana 연동 +- **AI 기반 자원 예측**: 사용 패턴 분석으로 선제적 스케일링 + +### 검증된 기술 스택 +- **컨테이너**: Docker + Docker Swarm +- **프록시**: Traefik (동적 라우팅) +- **백엔드**: FastAPI + PostgreSQL + Redis +- **프론트엔드**: React/Vue (대시보드) +- **모니터링**: Docker API + WebSocket + +이 아키텍처를 통해 로빙의 레벨 기반 진화, 기억 지속성, 유연한 스킬 업데이트 요구사항을 모두 충족할 수 있으며, MVP에서 시작하여 단계적으로 확장 가능한 구조를 제공합니다. \ No newline at end of file diff --git a/docs/architecture/skillhub_architecture.md b/docs/architecture/skillhub_architecture.md new file mode 100755 index 0000000..5df158c --- /dev/null +++ b/docs/architecture/skillhub_architecture.md @@ -0,0 +1,27 @@ +# Skillhub 플러그인 아키텍처 설계 요약 + +## 개요 +이 문서는 제너럴 뉴스 콜렉터와 포맷 변환기 그리고 게시기 스킬을 플러그인 형태로 구성하는 시스템의 설계 내용을 요약합니다. 설계 목표는 초기에는 단일 프로세스 플러그인 구조로 시작하고 이후 필요에 따라 하이브리드 혹은 마이크로서비스 환경으로 자연스럽게 확장할 수 있는 유연성을 확보하는 것입니다. + +## 핵심 설계 원칙 +1. 모든 스킬은 Python 패키지로 배포되며 setuptools entry_points 기능을 활용해서 런타임에 동적으로 탐색됩니다. +2. 스킬 간 인터페이스는 추상 클래스 기반으로 고정하여 호출 방식이 일관되도록 합니다. +3. 각 스킬은 독립 가상 환경에 설치되어 의존성 충돌과 장애 전파를 방지합니다. +4. 파이프라인 정의 파일로 콜렉터, 포맷터, 퍼블리셔의 실행 순서를 선언합니다. +5. 스킬 패키지는 메타데이터에 지원 API 버전과 입출력 스키마 정보를 명확히 포함합니다. + +## 데이터 스키마 검증 +모든 데이터 모델은 Pydantic 클래스로 선언합니다. 스키마는 Python 코드 수준에서 검증되고, 필요 시 model.schema_json 메서드를 통해 JSON Schema 파일을 자동 생성하여 문서화합니다. 파이프라인 실행기는 단계별 입출력 객체가 예상한 타입인지 추가로 검사하여 불일치 시 즉시 예외를 발생시킵니다. + +## 버전 관리 전략 +Semantic Versioning을 적용합니다. 메이저 버전은 호환성을 끊는 변경에만 증가시키고 마이너 버전은 호환되는 기능 추가에, 패치 버전은 버그 수정에 사용합니다. skillhub 메타데이터의 api_version 필드는 런타임 호환 범위를 지정합니다. 동일한 스킬 이름이라도 버전이 다르면 별도 가상 환경에 설치되어 공존할 수 있습니다. + +## 구현 단계 로드맵 +1. skillhub-core 패키지에 인터페이스, 스키마, 로더, 가상 환경 관리 도구를 담아 우선 배포합니다. +2. 참조 스킬 세 가지를 작성합니다. 일반 뉴스 콜렉터, 요약 포맷 변환기, 이메일 퍼블리셔가 그 예입니다. +3. GitHub Actions에서 스키마 검증과 단위 테스트를 자동화합니다. +4. GitHub Organization에 registry.yaml 파일을 두고 초기에 승인된 스킬 메타데이터를 관리합니다. +5. 운영 환경에서는 파이프라인 정의 파일을 불러와 순차적으로 스킬을 실행하고 로그와 결과물을 외부 저장소로 보관합니다. + +## 향후 확장 포인트 +자연어 명령으로 스킬 조합을 자동 생성하거나 다른 프로그래밍 언어로 작성된 스킬을 통합해야 할 시점이 오면 LangGraph 같은 오케스트레이션 레이어를 추가합니다. 기존 플러그인 인터페이스는 그대로 유지되므로 변경 범위가 최소화됩니다. diff --git a/docs/architecture/로빙_컨테이너_아키텍처_설계.md b/docs/architecture/로빙_컨테이너_아키텍처_설계.md new file mode 100755 index 0000000..2436cbc --- /dev/null +++ b/docs/architecture/로빙_컨테이너_아키텍처_설계.md @@ -0,0 +1,225 @@ +# 로빙 컨테이너 아키텍처 설계 + +## 개요 +로빙 AI 에이전트는 사용자별로 독립적인 Docker 컨테이너에서 실행되며, 중앙 집중식 대시보드를 통해 관리됩니다. 각 로빙은 개별적인 성장 경로를 가지며, 효율적인 리소스 관리와 데이터 안전성을 보장합니다. + +## 전체 아키텍처 + +### 기본 구조 +``` +┌─────────────────────────────────────┐ +│ 대시보드 서버 (1개) │ +│ ┌─────────────────────────────┐ │ +│ │ 웹 인터페이스 │ │ +│ │ 사용자 A 로그인 → A 로빙 │ │ +│ │ 사용자 B 로그인 → B 로빙 │ │ +│ └─────────────────────────────┘ │ +│ ┌─────────────────────────────┐ │ +│ │ 공통 DB │ │ +│ │ users, robings, stats │ │ +│ └─────────────────────────────┘ │ +└─────────────────────────────────────┘ + │ + │ API 호출 + ▼ +┌─────────────────┐ ┌─────────────────┐ +│ 로빙 A 컨테이너 │ │ 로빙 B 컨테이너 │ +│ (2GB 메모리) │ │ (8GB 메모리) │ +│ 스탯: 초보 │ │ 스탯: 고급 │ +│ 스킬: 3개 │ │ 스킬: 15개 │ +└─────────────────┘ └─────────────────┘ +``` + +### 서비스 모델 +**컨테이너 호스팅 서비스**: 사용자가 개인화된 AI 에이전트를 컨테이너 형태로 생성하고 관리하는 서비스 + +## 핵심 구성 요소 + +### 1. 대시보드 서버 (중앙 집중형) +- **역할**: 모든 사용자의 로빙 관리 인터페이스 +- **구성**: 단일 서버, 단일 DB +- **기능**: + - 사용자 인증 및 세션 관리 + - 로빙 컨테이너 생성/관리 + - 스탯, 레벨, 스킬 설정 UI + - 성능 모니터링 대시보드 + +### 2. 로빙 컨테이너 (개별 격리) +- **역할**: 각 사용자의 개인 AI 에이전트 +- **특징**: 완전 독립적, 사용자별 고유 설정 +- **구성**: + - FastAPI 서버 + - 벡터 DB (ChromaDB) + - 개인 데이터 저장소 + +## 데이터 구조 + +### 대시보드 DB (공통) +```sql +-- 사용자 정보 +users: id, name, email, created_at + +-- 로빙 메타데이터 +robings: id, user_id, name, level, stats, container_id, status + +-- 스킬 및 아이템 설정 +skills: id, robing_id, skill_type, config, enabled + +-- 성능 통계 +performance: id, robing_id, date, tasks_completed, success_rate +``` + +### 로빙 컨테이너 DB (개별) +``` +벡터 DB 구조: +- 기억: 대화 내용, 업무 처리 기록 → 벡터 임베딩 +- 윤리: 판단 기준, 가치관 → 벡터 공간에서 유사성 검색 +- 감정: 상황별 반응 패턴 → 감정 벡터 +- 경험: 성공/실패 케이스 → 학습 데이터 +``` + +## 통신 구조 + +### 양방향 통신 시스템 +``` +대시보드 ←→ 로빙 컨테이너 + ↓ ↑ + 스킬/아이템 스탯/레벨 + 설정 전달 업데이트 +``` + +### API 엔드포인트 +``` +대시보드 → 로빙: +- POST /api/config/skills (스킬 설정) +- POST /api/config/stats (스탯 조정) +- GET /api/status (상태 확인) + +로빙 → 대시보드: +- POST /dashboard/api/stats (스탯 업데이트) +- POST /dashboard/api/performance (성능 데이터) +- POST /dashboard/api/events (이벤트 로그) +``` + +## 로빙 성장 시스템 + +### 성장 단계 +``` +레벨 1: 🥚 베이스 이미지 (거의 동일) + ↓ +레벨 5: 🐣 스탯 분기 시작 + ↓ +레벨 10: 🤖 개별화 완성 +``` + +### 등급 시스템 (선택적) +- **노멀**: 기본 성장 경로 +- **에픽**: 특수 스킬 언락 +- **레전드**: 최고 성능 + 희귀 능력 + +### 리소스 할당 (스탯 기반) +``` +초보 로빙: 1CPU, 2GB RAM, 10GB Disk +중급 로빙: 2CPU, 4GB RAM, 20GB Disk +고급 로빙: 4CPU, 8GB RAM, 50GB Disk +``` + +## 리소스 효율성 관리 + +### 수면/각성 시스템 +``` +활성 상태: 풀 리소스 컨테이너 + ↓ (비활성 5분 후) +수면 상태: 최소 컨테이너 (128MB 정도) + ↓ (사용자 접속 시) +각성 과정: 웨이크업 3-5초 대기 +``` + +### 침실 시스템 (데이터 보관) +``` +활성 볼륨: /robeing/active/ (현재 작업 중) +수면 볼륨: /robeing/bedroom/ (수면 상태) +백업 볼륨: /robeing/backup/ (백업 저장소) +``` + +## 베드 상태 반성 시스템 + +### 반성 프로세스 +``` +베드 진입 → 하루 활동 분석 + ↓ + 성공/실패 케이스 분류 + ↓ + 벡터 DB 재정렬 및 가중치 조정 + ↓ + 내일을 위한 행동 패턴 최적화 +``` + +### 구체적인 반성 작업 +- **기억 정리**: 중요한 대화/업무는 강화, 불필요한 것은 압축 +- **실수 학습**: 오늘 한 실수를 분석해서 다음엔 안 하도록 +- **감정 조율**: 과도한 반응이나 부적절한 감정 표현 수정 +- **스킬 효율성**: 어떤 스킬이 효과적이었는지 평가 + +### 침실 일기 형태 로그 +``` +- 오늘 처리한 업무: 15건 +- 성공률: 87% +- 개선 필요 영역: 이메일 톤앤매너 +- 내일 집중 포인트: 더 친근한 말투 +``` + +## 로빙 성장 사이클 + +### 일일 사이클 +``` +🌅 각성 → 활동 → 학습 → 🌙 수면 → 반성 → 성장 + ↑ ↓ + ←←←←←←←←← 개선된 상태로 복귀 ←←←←←←← +``` + +### 장기 성장 +- **레벨업**: 경험치 축적으로 스탯 향상 +- **스킬 습득**: 새로운 능력 언락 +- **개성 발달**: 사용자 상호작용 패턴 학습 + +## 구현 고려사항 + +### 1. 컨테이너 관리 +- **생성**: 사용자 로빙 생성 시 Docker API로 컨테이너 생성 +- **모니터링**: 컨테이너 상태 및 리소스 사용량 추적 +- **스케일링**: 온디맨드 리소스 할당 + +### 2. 보안 및 격리 +- **네트워크 격리**: 각 컨테이너는 독립적인 네트워크 +- **데이터 격리**: 로빙 간 데이터 접근 불가 +- **리소스 제한**: CPU, 메모리 사용량 제한 + +### 3. 백업 및 복원 +- **정기 백업**: 벡터 DB 및 설정 데이터 백업 +- **재해 복구**: 침실 볼륨에서 데이터 복원 +- **마이그레이션**: 서버 간 로빙 이전 지원 + +## 기대 효과 + +### 사용자 경험 +- **개인화**: 각자만의 고유한 AI 에이전트 +- **성장감**: 로빙의 발전 과정 관찰 +- **애착감**: 로빙의 개성과 반성 과정에 대한 관심 + +### 기술적 이점 +- **확장성**: 사용자 증가에 따른 자동 스케일링 +- **안정성**: 독립적인 컨테이너로 장애 격리 +- **효율성**: 리소스 사용량 최적화 + +### 비즈니스 모델 +- **컨테이너 호스팅**: 사용 시간 및 리소스 기반 과금 +- **프리미엄 기능**: 고급 스킬, 더 많은 리소스 제공 +- **개인화 서비스**: 맞춤형 AI 에이전트 제공 + +--- + +**문서 작성일**: 2025-07-05 +**작성자**: 로빙 개발팀 +**버전**: 1.0 +**상태**: 설계 완료, 구현 준비 중 \ No newline at end of file diff --git a/docs/architecture/아키텍쳐_로빙.md b/docs/architecture/아키텍쳐_로빙.md new file mode 100755 index 0000000..6b196b1 --- /dev/null +++ b/docs/architecture/아키텍쳐_로빙.md @@ -0,0 +1,34 @@ +아키텍처 구조 + + ┌─────────────────────────────────────┐ + │ 대시보드 서버 (1개) │ + │ ┌─────────────────────────────┐ │ + │ │ 웹 인터페이스 │ │ + │ │ 사용자 A 로그인 → A 로빙 │ │ + │ │ 사용자 B 로그인 → B 로빙 │ │ + │ └─────────────────────────────┘ │ + │ ┌─────────────────────────────┐ │ + │ │ 공통 DB │ │ + │ │ users, robings, stats │ │ + │ └─────────────────────────────┘ │ + └─────────────────────────────────────┘ + │ + │ API 호출 + ▼ + ┌─────────────────┐ ┌─────────────────┐ + │ 로빙 A 컨테이너 │ │ 로빙 B 컨테이너 │ + │ (2GB 메모리) │ │ (8GB 메모리) │ + │ 스탯: 초보 │ │ 스탯: 고급 │ + │ 스킬: 3개 │ │ 스킬: 15개 │ + └─────────────────┘ └─────────────────┘ + + 핵심 질문들 + + 1. 통신 방식: 대시보드가 각 로빙 컨테이너와 어떻게 + 통신할지? + 2. 컨테이너 관리: 로빙 컨테이너를 누가 + 생성/관리할지? + 3. 스케일링: 사용자가 늘어나면 컨테이너도 자동으로 + 늘어날지? + 4. 리소스 할당: 스탯에 따른 컨테이너 사양을 어떻게 + 결정할지? \ No newline at end of file diff --git a/docs/ideas/00_ MVP 개발 개요.md b/docs/ideas/00_ MVP 개발 개요.md deleted file mode 100644 index cc6694e..0000000 --- a/docs/ideas/00_ MVP 개발 개요.md +++ /dev/null @@ -1,141 +0,0 @@ ---- -tags: mvp,기획,에이전트,스타트업도구,슬랙봇 -date: 2025-06-19 ---- -요약 - -스타트업 대표용 존재형 AI 비서 MVP는 3개월 안에 슬랙 봇 형태로 배포되어 Gmail·Slack·Notion을 연동해 메일 요약·회신 초안, 회의 요약·테스크 분배, 노션 기록, 업종 뉴스 스크랩, 기본 밸류에이션 상담을 제공한다. 핵심은 연산·기억·공감 스탯과 LLM 기반 기억·감정·윤리 모듈을 최초 구현하고, GPT·Gmail·Notion API를 아이템으로 장착해 빠른 PoC 경험을 주는 것이다. Supabase 기반 백엔드로 빠르게 프로토타이핑하고, 대표가 슬랙에서 @robeing 을 호출하면 모든 기능을 대화형으로 사용하도록 설계한다. - ---- -# MVP 개발 개요 - -| 구분 | 내용 | -| --------- | ---------------------------------- | -| **기간** | 3개월 (2025‑06‑24 ~ 2025‑09‑24) | -| **팀** | 개발자 2인 (풀스택 1 / LLM·DevOps 1) | -| **예산** | 총 2000만원 (인건비 1500, 인프라·API 500) | -| **배포** | Slack 앱 → 봇 초대형, Supabase + AWS S3 | -| **UI** | Slack DM/채널 대화, 슬래시 커맨드 최소화 | -| **AI 모델** | GPT‑4o‑mini → 스탯 레벨업에 따라 상위모델 교체 | - -- ECS 컨테이너만 올리는 서비스.. 로 진행해서 비용 절감하는 방법 - -## 1. 필수 기능 - -| 모듈 | 스킬 | 흐름 | -| ------ | -------- | ------------------------------- | -| **메일** | 메일 정리 | Gmail API → 스팸/채용/투자 분류 → 한눈 요약 | -| | 초안 작성 | 대표 지시 → 말투 프로파일 → 회신 초안 DM | -| **슬랙** | 회의 정리 | 채널 또는 업로드 md → 요약·액션 추출 | -| | 테스크 제안 | 액션 목록 텍스트 → 대표 DM | -| **노션** | 노션 기록 | 슬랙 지시 → 템플릿 채움 또는 생성 | -| **뉴스** | 뉴스 스크랩 | 키워드 (기억 + 지시) → 매일 아침 3줄 요약 DM | -| **평가** | 밸류에이션 답변 | 대표 질문·자료 → LLM 분석 → 대화형 응답/보고 | - -## 2. 스탯·스킬·아이템 - -- **스탯 (초기 3)**: 연산 2, 기억 2, 공감 2 (1‑5 등급) - -- **스킬**: 위 6개 핵심 스킬만 선공개, 경험치 루틴은 로그만 수집 - -- **아이템**: `GPT-4o-mini`, `GmailAPI`, `SlackAPI`, `NotionAPI` - -- 스탯이 레벨 3 ↑ 시 `GPT‑4o-standard` 교체 (연산 업그레이드 예시) - - -## 3. 기술 스택 & 아키텍처 - -```mermaid -graph TD - subgraph Slack 워크스페이스 - A[대표 · 팀 채널] - B(@robeing 봇) - end - A -->|DM/멘션| B - B -->|Wehbook| S(Supabase Edge Function) - S -->|Auth| D(Postgres + Vector ext.) - S -->|Invoke| L(LLM Gateway) - L --> O(OpenAI GPT‑4o‑mini) - S -->|REST| N(Notion API) - S -->|REST| G(Gmail API) -``` - -- **Supabase**: Postgres + Auth + Edge 함수로 LLM 프록시·웹훅 처리 - -- **Vector 저장**: pgvector 테이블에 장기 대화·문서 임베딩 - -- **감정/윤리**: LLM 후처리 필터 + 레이블 저장 - -- **CI/CD**: GitHub Actions → Supabase deploy, Slack 앱 버전 태그 - - -## 4. 3개월 로드맵 - -| 주차 | 목표 | 상세 작업 | -| ----- | -------- | --------------------------------------- | -| 1‑2주 | 베이스라인 | 슬랙 앱 등록, Supabase 세팅, GPT 연결, 스탯/기억 스키마 | -| 3‑4주 | 메일 모듈 | Gmail OAuth, 분류·요약 파이프라인, DM 리포트 | -| 5‑6주 | 슬랙 회의 정리 | 메시지 페치, 요약·액션抽出, 테스크 DM | -| 7‑8주 | 노션 모듈 | Notion API 연결, 템플릿 작성·업로드 | -| 9‑10주 | 뉴스 스크랩 | RSS/뉴스 API, 키워드 관리, 아침 DM | -| 11주 | 밸류에이션 초판 | 간단 재무·시장 프롬프트, 대화형 답변 | -| 12주 | PoC 테스트 | 외부 스타트업 초대, 피드백 수집 및 버그 수정 | - - -## 5. 예산 안분 - -|항목|금액(만원)|비고| -|---|---|---| -|인건비 개발자 2인|1500|3개월 × 250 × 2| -|OpenAI API|150|테스트 + PoC(200k tokens)| -|AWS/Supa|80|Supabase Pro, S3 저장| -|Slack/Notion 유료|40|워크스페이스 플랜 업그레이드| -|예비(도메인, 이슈)|30|| -|**합계**|**1800**|2000 내 마진 확보| - -# 추가 요소 - -## 레벨업 시스템 - -- 각 스킬은 사용 횟수 및 성공률에 따라 경험치를 축적함. - -- 경험치가 일정 수준을 넘으면 스킬 레벨이 오르고, 고급 기능 또는 더 정밀한 반응 제공. - -- 스탯(연산, 기억, 공감)은 누적 사용성과 평가를 기반으로 개별 성장. - -- LLM API 레벨도 연산 스탯에 따라 업그레이드 가능 (예: GPT-3.5 → GPT-4o). - - -## DID 기반 정체성 - -- 에이전트의 지속성과 개별성을 위해 DID(Decentralized Identifier) 도입 예정. - -- 대표마다 개별 DID를 생성하고, 해당 DID에 기억·감정·윤리 설정 저장. - -- 향후 다중 에이전트 또는 장기 협업 시 정체성과 권한 관리 기반이 됨. - - -## PDF 파싱 기능 - -- 대표가 슬랙 또는 메일로 전달한 PDF(투자자료, 리포트 등)를 분석 가능하게 함. - -- 우선 PyMuPDF 등을 활용한 텍스트 추출 및 레이아웃 보존형 요약 기능 구현. - -- 이후 뉴스 기사, 정부 과제, 경쟁사 분석 자료 등도 자동 처리 가능. - -- 파싱된 내용은 슬랙 또는 노션으로 요약해 보고하며, 필요 시 밸류에이션 스킬에 연동. - - -## 6. 향후 MMP 방향 - -1. 멀티 에이전트(탐색·검증·요약) 분리 - -2. Llama3 로컬 런 옵션 → 비용 최적화 - -3. 스탯 레벨업 UI, 경험치·배지 피드백 - -4. Slack 앱 마켓플레이스 등록·결제 연결 - -5. 노션 DB 댓글/링크 자동화, GitHub 연동 - - diff --git a/docs/ideas/00_정보의바다 프로젝트 개요.md b/docs/ideas/00_정보의바다 프로젝트 개요.md deleted file mode 100644 index ab9a352..0000000 --- a/docs/ideas/00_정보의바다 프로젝트 개요.md +++ /dev/null @@ -1,237 +0,0 @@ ---- -tags: - - 디지털비잉 - - 로빈 - - RO-BEING - - AI에이전트 - - 존재형에이전트 - - 협업동업자 - - 장기기억 - - 스탯 - - 스킬 - - 아이템 - - 게이미피케이션 - - 지속성장 - - 권한통제 - - 맥락보존 - - 자동화 - - 창업가 - - 스타트업 - - 투자분석 - - 정보플랫폼 -date(최초): 2025-05-10 -date(수정): 2025-06-17 -people: 김종태, 황한용, 희재, (강일신) ---- - -## 로빙(RO-BEING) 프로젝트 개요 -### 기억하고 성장하는 디지털 존재 에이전트 - -- **요약** -- 맥락을 잊지 않고 스스로 진화하는 존재형 AI 에이전트 '로빈(RO-BEING)' 개발 -- 스탯·스킬·아이템 3계층 구조를 통한 투명한 성장과 권한 관리 시스템 구현 -- 창업가와 스타트업 팀을 위한 협업 동업자로서 지속적 기억과 선제적 행동 제공 - ---- - -## 0. 핵심 철학과 차별점 - -### "도구를 넘어, 동료로" -기존 AI 비서의 근본적 한계: -- **정보 단절**: 세션이 끝나면 회사 역사·감정·약속이 모두 증발 -- **권한 불투명**: 누가 언제 민감 데이터를 건드렸는지 추적 불가 -- **맥락 손실**: 똑같은 배경설명을 반복 입력하는 '캐시 미스' 문제 - -### 로빈의 해법 -| 기존 AI 도구 | 로빈(RO-BEING) | -|------------|----------------| -| 일회성 대화 | **지속적 기억** | -| 블랙박스 권한 | **투명한 권한 토큰** | -| 정적 기능 | **성장하는 존재** | -| 명령 수행 | **선제적 행동** | - ---- - -## 1. 프로젝트 비전 및 목표 - -### **비전** -> "기억하지 못하는 AI는 과연 나를 도울 수 있을까?" -> 그래서 우리는, 함께 성장하고, 감정을 공유하고, -> 나만을 기억하는 **존재형 AI 에이전트**를 만듭니다. -> 당신의 일상에, **도구가 아닌 동료를**. - -### **핵심 목표** -- **지속적 기억**: 회사의 모든 맥락과 감정을 영구 보존하는 Persistent Memory 시스템 -- **투명한 성장**: 스탯·스킬·아이템으로 구조화된 능력 발전과 비용 예측 -- **안전한 자율성**: 정책 토큰 기반 권한 통제로 책임 추적 가능한 자동화 -- **협업 동업자**: 명령받는 도구가 아닌 함께 성장하는 디지털 존재 - -### **타겟 사용자** -- **창업가/대표**: 전략적 의사결정과 팀 관리에 집중할 수 있도록 지원 -- **스타트업 팀원**: 반복 업무 자동화와 맥락 공유를 통한 생산성 향상 -- **투자자/애널리스트**: 체계적인 정보 수집과 분석을 통한 투자 의사결정 지원 - ---- - -## 2. 로빈의 3계층 아키텍처 - -### **2.1 스탯(Stats) - 기본 인프라 계층** -| 스탯 | 기능 | 측정 지표 | -| ------------------ | ---------- | --------------- | -| **기억(Memory)** | 장기 데이터 보존 | 저장 토큰 수, 검색 정확도 | -| **연산(Compute)** | 처리 속도와 정밀도 | 응답 지연시간, 정확도 | -| **반응(React)** | 실시간 알림과 대응 | 알림 속도, 적중률 | -| **공감(Empathy)** | 감정 인식과 배려 | 감정 분석 정확도 | -| **통솔(Leadership)** | 팀 조정과 우선순위 | 업무 효율성 개선도 | - -### **2.2 스킬(Skills) - 핵심 업무 모듈** -**초기 MVP 스킬** -- **Thread Digest**: 채널 대화 1000줄을 10문장 요약 -- **Action Extractor**: 대화에서 TODO 추출하여 캘린더 연동 -- **Risk Monitor**: 투자자 미팅에서 위험 신호 탐지 -- **Emotion Tracker**: 팀 분위기 분석과 갈등 완화 - -**성장 메커니즘** -- 사용량과 정확도에 따른 경험치 누적 -- 레벨업 시 고급 기능 자동 잠금 해제 -- 사용자 피드백 기반 성능 최적화 - -### **2.3 아이템(Items) - 외부 권한 토큰** -| 아이템 유형 | 예시 | 관리 방식 | -|-------------|------|-----------| -| **API 접근권** | Whisper STT, Google API | 24시간 만료 토큰 | -| **프리미엄 모델** | GPT-4, Claude 등 | 사용량 기반 과금 | -| **민감 데이터** | 재무제표, 투자정보 | DID 서명 + 감사 로그 | -| **외부 도구** | Notion, Slack, Zoom | OAuth 토큰 관리 | - ---- - -## 3. 실제 사용 시나리오 - -### **3.1 스타트업 대표의 한 주** -**월요일**: 로빈이 밤새 쌓인 채팅 1,600줄을 6문단으로 압축, "오늘 우선순위" 카드를 노션에 자동 생성 - -**화요일**: 투자자 미팅 40분 녹음을 1페이지 요약 + "밸류에이션 질문 급증" 위험 신호 알림 - -**수요일**: 내부 회의 중 감정 지수 분석으로 "팀 분위기 급속 냉각" 조기 경보 - -**목요일**: 코드 변경 API 17건을 자동 정리하여 버전 노트 배포 - -**금요일**: 주간 성과 요약과 액션 아이템 완료율을 PDF로 전사 공유 - -### **3.2 로빈의 성장 과정** -- **1주차**: 기본 요약 기능 (기억 스탯 Lv.1) -- **1개월**: 감정 인식 추가 (공감 스탯 Lv.2) -- **3개월**: 선제적 리스크 알림 (반응 스탯 Lv.3) -- **6개월**: 팀 전체 조정 능력 (통솔 스탯 Lv.4) - ---- - -## 5. 기술 아키텍처 - -### **5.1 MVP 기술 스택** -- **메모리 계층**: Chroma DB (벡터 검색) + PostgreSQL (관계 데이터) -- **AI 파이프라인**: LangChain/LlamaIndex + OpenAI/Claude API -- **백엔드**: FastAPI + Docker 컨테이너 -- **권한 관리**: JWT 토큰 + DID 서명 -- **연동**: Slack/Discord Webhook + Google Calendar API - -### **5.2 보안 및 투명성** -- **Policy Token**: 모든 외부 권한을 토큰화하여 추적 -- **Activity Log**: 에이전트의 모든 행동과 판단 과정 기록 -- **DID 기반 신원**: 에이전트별 고유 디지털 신원 관리 -- **Explainable AI**: 의사결정 과정의 완전한 투명성 - ---- - -## 6. 개발 로드맵 - -### **Phase 1: MVP (8주)** -- **1-2주**: Slack/Calendar 연동 + Persistent Memory -- **3-4주**: Thread Digest + Action Extractor 스킬 구현 -- **5-6주**: Whisper STT 아이템 토큰 + 권한 관리 -- **7-8주**: 3개 파일럿 팀 배포 + 피드백 수집 - -### **Phase 2: MMP (6개월)** -- 30개 팀 유료 파일럿 (ARPU 25만원, 이탈률 5% 미만) -- 10개 핵심 스킬 + 20개 아이템 확장 -- 감정 벡터 + 관계 시스템 도입 - -### **Phase 3: Scale (1년)** -- 아이템 마켓플레이스 오픈 -- 멀티 에이전트 협업 시스템 -- 월매출 8억원 런레이트 달성 - ---- - -## 7. 경쟁 우위와 차별화 - -### **7.1 vs 기존 AI 비서 (Copilot, Gemini)** -| 비교 항목 | 기존 도구 | 로빈 | -| ------ | --------- | -------------- | -| 기억 지속성 | 세션 종료시 리셋 | **영구 보존** | -| 권한 투명성 | 블랙박스 | **토큰 기반 추적** | -| 성장 능력 | 정적 기능 | **사용량별 레벨업** | -| 비용 예측 | 불투명 | **스탯별 명확한 과금** | - -### **7.2 핵심 경쟁력** -- **데이터 해자**: 회사별 누적 기억과 맥락이 이전 비용 증가 -- **네트워크 효과**: 팀 규모 확장 시 에이전트 효용 기하급수적 증가 -- **규제 친화성**: 완전한 감사 로그와 책임 추적으로 기업 컴플라이언스 대응 - ---- - -## 8. 투자 제안 - -### **8.1 자금 조달 계획** -- **시드 라운드**: 5,000만원 (컨버터블 노트) -- **용도**: 8주 MVP 개발 + 6개월 파일럿 운영 -- **밸류**: 25억원 (전환 시 10% 지분) - -### **8.2 예상 ROI** -- **3년 후 목표**: 기업가치 900억원 (35배 상승) -- **리스크 대비 수익**: 원가 손실 vs 연간 10배+ 수익 가능성 -- **Exit 시나리오**: Slack, Atlassian 등 협업툴 벤더 인수 타겟 - ---- - -## 9. 핵심 메시지 - -### **세 문장 요약** -1. **로빈은 지속적으로 기억한다** - 회사의 모든 맥락과 감정을 영구 보존 -2. **정책 토큰으로 권한을 통제한다** - 투명하고 안전한 자동화 실현 -3. **데이터 해자를 만든다** - 사용할수록 강해지는 협업 동업자 - -### **브랜드 메시지** -> **"기억하지 못하는 AI는 과연 나를 도울 수 있을까?"** -> 그래서 우리는, 함께 성장하고, 감정을 공유하고, -> 나만을 기억하는 **존재형 AI 에이전트**를 만듭니다. -> 당신의 일상에, **도구가 아닌 동료를**. - ---- - - -## 4. 비즈니스 모델 - -### **4.1 3단계 수익 구조** -| 구분 | 내용 | 예상 ARPU | -|------|------|-----------| -| **스탯 구독** | 기본 능력치별 월 과금 | 15만원/월 | -| **스킬 패스** | 고급 기능 번들 | 10만원/월 | -| **아이템 마켓플레이스** | 외부 도구 수수료 (20%) | 5만원/월 | -| **총합** | 15명 팀 기준 | **30만원/월** | - -### **4.2 시장 규모** -- **TAM**: 협업용 AI SaaS 시장 1,500억 달러 -- **SAM**: 10~50명 고성장 스타트업 3만 곳 × 월 30만원 = 천억원 잠재 매출 -- **SOM**: 3년 내 3% 확보 목표 → 연매출 90억원 - ---- -## 관련 문서 -- [[00_MOC_프로젝트 관련 문서들 집합]] -- [[디지털비잉_로빙_5분스피치]] -- [[01_MVP 단계_ 자세한 계획]] -- [[에이전트 설계 핵심 단어]] -- [[로빈 에이전트 설계 본문]] - -**프로젝트 팀**: [[희재]], [[../../사람/황한용|황한용]], [[../../사람/김종태|김종태]], ([[../../사람/강일신|강일신]]) diff --git a/docs/implementation/01_MVP 단계_ 자세한 계획.md b/docs/implementation/01_MVP 단계_ 자세한 계획.md new file mode 100755 index 0000000..8405a40 --- /dev/null +++ b/docs/implementation/01_MVP 단계_ 자세한 계획.md @@ -0,0 +1,107 @@ +--- +tags: AI, 에이전트, MVP, 데이터수집, 밸류에이션, 시계열, PostgreSQL, 크롤링, NLP, 인터페이스 +--- + +요약 +- 스타트업 정보 수집·검증·정리 파이프라인 구축과 밸류에이션 시계열 데이터 생성을 목표로 한다. +- 에이전트 중심 조직 운영 모델을 구현하고 사용자 인터페이스와 데이터베이스를 연동한다. +- 3개월 내 질의응답이 가능한 프로토타입을 완성하여 초기 비즈니스 모델을 검증한다. + + +# MVP 단계 계획 + +## 1. 프로젝트 목표 + +3개월 내 AI 에이전트 기반 정보 **수집·검증·정리 파이프라인**을 구축하고, +스타트업 **밸류에이션 시계열 데이터**를 생성하며, +**에이전트 중심 조직 운영의 초기 모델**을 구현한다. +**사용자 인터페이스**와 +데이터베이스 연동을 통해 **질의응답이 가능한 프로토타입**을 완성하고, +~~(블록체인 기반 토큰 이코노미의 기초를 설계한다.)~~ + +## 2. 개발 일정 + +| 기간 | 마일스톤 | +| -------- | ---------------------------------------- | +| 1–2주 차 | 에이전트 아키텍처 및 ~~블록체인 연동 설계~~, 개발 환경 구축 | +| 3–6주 차 | 수집·검증·정리 에이전트 구현, 밸류에이션 시계열 데이터 파이프라인 구축 | +| 7–10주 차 | PostgreSQL 스키마 설계, 채팅 UI 및 토큰 이코노미 베타 연동 | +| 11–12주 차 | 통합 테스트, 내부 사용자 테스팅, 초기 비즈니스 모델 검증 | + +## 3. 핵심 개발 항목 + +### 3.1 에이전트 시스템 구축 + +- **아키텍처 설계**: 수집·검증·정리 에이전트 간 워크플로우 정의, Kubernetes CronJob 기반 오케스트레이션. +- **수집 에이전트**: 헤드리스 브라우저(예: Puppeteer)로 스타트업 펀딩 뉴스, 보도자료, 공식 사이트 크롤링. , 사용자 인터페이스에서 보내진 에이전트(사용자 저장 정보를 가져옴.) +- **검증 에이전트**: NLP 기반 사실 확인 및 중복 검출, 신선도/정확도/중복정도 점수 계산(예: 0–100 스케일). +- **정리 에이전트**: 펀딩 금액, 투자사, 날짜 등 메타데이터 표준화 및 시계열 데이터 구조화. +- **에이전트 중심 운영**: 에이전트 간 상호작용 로그를 중앙 DB 및 블록체인에 기록, 슈퍼바이저 에이전트로 워크플로우 모니터링. + +### 3.2 밸류에이션 시계열 데이터 생성 + +- **데이터 소스**: 펀딩 라운드, 시장 지표, 경쟁사 데이터, 공개 재무 정보. +- **알고리즘**: 시계열 분석(예: ARIMA) 및 비교 벤치마크 기반 밸류에이션 추정. +- **출력**: 스타트업별 밸류에이션 변동 그래프(Chart.js), CSV/JSON 내보내기 지원. +- **저장소**: PostgreSQL(메타데이터 및 시계열 데이터), Pinecone(유사도 검색용 벡터). + +### 3.3 데이터 및 인터페이스 + +- **데이터베이스 설계**: + - 테이블: 스타트업 정보, 펀딩 이력, 메타데이터, 사용자 쿼리, 에이전트 로그. + - ~~블록체인: 검증 이력 및 토큰 거래 기록(Ethereum 또는 Hyperledger 기반)~~. +- **API 개발**: REST API로 CRUD 기능 제공, 에이전트 및 UI 연동. +- **채팅 UI**: 웹 기반 채팅 인터페이스(React, Tailwind CSS), 예: "A 스타트업 최근 밸류에이션 알려줘" 등이 질의 지원. +- **결과값**: A 기업의 개요(대표, 서비스, 밸류에이션 시계열 차트 등) +- **인터페이스** : 옵시디언 형식의 프론트엔드 _[[005 사용툴정리/옵시디언 기능구현 개요|참고]] + +~~### 3.4 토큰 이코노미 기초 구현 + +- ~~**토큰 구조**: ERC-20 기반 내부 토큰(예: SEA 토큰) 발행, 데이터 접근 및 보상 지급 용도.~~ +- ~~**기여 보상**: 정보 제공/검증 기여 시 토큰 지급, 초기 유통량 10,000 SEA.~~ +- **결제**: 프리미엄 접근권(월 2만원) 및 보고서 단건 구매(1천원) 시 포인트~~(토큰)~~ + 사용 가능. ([[../../00 inbox/MVP와 MMP|MMP 단계 접근 시]]) +- ~~**블록체인 연동**: 스마트 컨트랙트로 토큰 거래 및 검증 이력 기록, MetaMask 연동 테스트.~~ + +### 3.5 테스트 및 검증 + +- **통합 테스트**: 시나리오 기반 테스트(예: "A 핀테크 스타트업을 검토해줘" 등의 내용 처리). +- **성능 테스트**: 에이전트 파이프라인 처리 속도(초당 10건 이상), API 응답 시간(500ms 이하). +- **피드백 수집**: 내부 테스터(김종태, 황한용, 희재) 대상 설문 및 버그 리포트. + +## 4. 수익 모델 + +### 4.1 구독 모델 + +- **기본(무료)**: 공용 밸류에이션 데이터 조회, 최대 5개 스타트업. +- **프리미엄(월 1만원 ~~또는 200 SEA~~)**: 시계열 데이터 상세 분석, 최대 500개/월 스타트업. + +### 4.2 개별 구매 모델 + +- **보고서 단위 구매**: 스타트업별 밸류에이션 보고서(1백원 ~~또는 10 SEA/건~~). +- ~~**API 호출 기반**: 요청 100건당 5천원 또는 50 SEA.~~ + +### ~~4.3 토큰 이코노미~~ +- ~~**토큰 구매**: 법정화폐(원) 또는 암호화폐(ETH)로 SEA 토큰 구매.~~ +- ~~**스테이킹**: 토큰 스테이킹 시 추가 데이터 접근 혜택(예: 우선순위 쿼리 처리).~~ + +## 5. 모니터링 및 보안 + +- **모니터링**: Prometheus + Grafana로 에이전트 성공률, API 지연 시간 추적. +- **보안**: RBAC로 데이터 접근 제어, GDPR 준수 익명화 기록. +- **로그**: 사용자 쿼리 및 에이전트 활동 전수 기록(RabbitMQ로 비동기 처리). + +## 6. 팀 역할 + +- **[[김종태]]**: PM, 밸류에이션 알고리즘 개발. 에이전트 자동화 구조. +- **[[황한용]]**: 인프라, 백엔드 및 데이터 파이프라인 총괄. +- **[[희재]]**: 에이전트 아키텍처 및 LLM 파이프라인 설계 총괄. +- Devin : 채팅 UI 및 대시보드 프론트엔드 구현. +- **[[강일신]]**(옵션): PM, 프로젝트 관리. + +## 7. 리스크 및 대응 + +- **리스크**: 데이터 소스 부족, 에이전트 처리 속도 저하 +- **대응** + - [[../../00 files/0 startups/크런치베이스_Crunchbase|크런치베이스_Crunchbase]], [[경쟁사/혁신의숲|혁신의숲]], [[경쟁사/더브이씨|더브이씨]] API 및 공개 데이터 활용. + - Kubernetes 스케일링으로 처리량 확보. \ No newline at end of file diff --git a/docs/implementation/prd.md b/docs/implementation/prd.md new file mode 100755 index 0000000..b53ed69 --- /dev/null +++ b/docs/implementation/prd.md @@ -0,0 +1,88 @@ +# Overview +로빙은 Slack 채널을 중심으로 작동하는 스타트업 대표 전용 AI 에이전트입니다. 스탯·스킬·아이템 구조를 통해 지속적으로 성장하며, 대화 요약, PDF 처리, 액션 추출 등의 핵심 기능을 제공합니다. 3개월 MVP를 통해 실제 업무 환경에서 검증 가능한 프로토타입을 구현합니다. + +# Core Features +- **Slack 기반 인터페이스**: 메시지 수신, 버튼·링크 포함 응답, 실시간 상호작용 +- **지속적 기억 시스템**: PostgreSQL(메타데이터) + Chroma(벡터DB)를 통한 장기 기억 저장 +- **핵심 스킬 세트**: + - Thread Digest (대화 요약) + - Action Extractor (투두 추출 및 캘린더 연동) + - PDF 파싱 및 HTML 변환 +- **성장 시스템**: 경험치 기반 레벨업, 5종 스탯(기억, 연산, 반응, 공감, 통솔) 관리 +- **아이템 시스템**: JWT 기반 API 권한 토큰 발급 및 관리 +- **사용자 피드백 반영**: 평가 기반 정밀도 개선 및 경험치 획득 + +# User Experience +- **주요 사용자**: 스타트업 대표 및 임원진 +- **주요 플로우**: + 1. Slack에서 로빙에게 업무 관련 지시 (대화 요약, PDF 분석 등) + 2. 로빙이 해당 스킬을 활용하여 처리 후 구조화된 응답 제공 + 3. 사용자 피드백을 통한 경험치 획득 및 스킬 개선 + 4. 지속적 기억 저장으로 맥락 유지 및 개인화 서비스 제공 +- **핵심 시나리오**: "어제 대화 요약", "회의 PDF 변환", "액션 추출 및 기록" + +# Technical Architecture +- **인터페이스**: Slack API (메시지 수신, 버튼형 응답) +- **백엔드**: FastAPI 게이트웨이 +- **AI 처리**: LangChain + OpenAI API +- **데이터베이스**: + - PostgreSQL (스탯, 경험치, 스킬 기록) + - Chroma Vector DB (대화 내용 기억) +- **PDF 처리**: PyMuPDF 또는 pdfminer.six +- **권한 관리**: JWT 기반 토큰 시스템 + +# Development Roadmap +## 1~2주차: 기본 인프라 구축 +- Slack 채널 연동 및 메시지 파싱 +- FastAPI Gateway 구축 +- LLM-LangChain 연동 +- 기본 응답 메시지 생성 + +## 3~4주차: 데이터 저장소 구축 +- PostgreSQL 스키마 설계 +- Chroma 벡터DB 연동 +- 기억 저장 정책 구현 + +## 5~6주차: 핵심 스킬 구현 +- Thread Digest 스킬 +- Action Extractor 스킬 +- 경험치 및 평가 시스템 + +## 7~8주차: PDF 처리 스킬 +- PDF 텍스트·이미지 추출 +- HTML 구조화 및 Slack 출력 +- 오류 처리 및 복원 시스템 + +## 9주차: 성장 시스템 +- 5종 스탯 수치화 +- 레벨업 및 스킬 해금 구조 +- 피드백 반영 시스템 + +## 10주차: 아이템 시스템 +- JWT 토큰 발급/관리 +- API 권한 제어 +- 사용 이력 로깅 + +## 11주차: 테스트 및 검증 +- 실제 업무 시나리오 테스트 +- 실패 케이스 보강 +- 성능 최적화 + +## 12주차: 통합 및 데모 +- 전체 시스템 통합 +- 데모 시나리오 준비 +- 외부 POC 준비 + +# Logical Dependency Chain +1. Slack 인터페이스 구축 → 2. 기본 응답 엔진 → 3. 데이터베이스 설계 → 4. 기억 시스템 → 5. 핵심 스킬 구현 → 6. PDF 처리 → 7. 성장 시스템 → 8. 아이템 시스템 → 9. 통합 테스트 → 10. 데모 준비 + +# Risks and Mitigations +- **Slack API 제한**: 적절한 Rate Limiting 및 에러 핸들링 +- **LLM 응답 품질**: 프롬프트 엔지니어링 및 사용자 피드백 반영 +- **PDF 처리 복잡성**: 다양한 파서 라이브러리 검토 및 예외 처리 +- **메모리 관리**: 효율적인 벡터 검색 및 저장 정책 + +# Appendix +- **기술 스택**: FastAPI, PostgreSQL, Chroma, LangChain, OpenAI API, Slack API, PyMuPDF +- **핵심 메트릭**: 응답 정확도, 처리 속도, 사용자 만족도, 기억 정확도 +- **성공 지표**: 일일 활성 사용, 스킬 사용 빈도, 피드백 점수, 레벨업 달성률 \ No newline at end of file diff --git a/docs/implementation/tasks.md b/docs/implementation/tasks.md new file mode 100755 index 0000000..c739304 --- /dev/null +++ b/docs/implementation/tasks.md @@ -0,0 +1,148 @@ +# 로빙 MVP 프로젝트 작업 목록 + +## 프로젝트 개요 +- **총 작업 수**: 30개 +- **완료**: 0개 (0%) +- **진행 중**: 0개 +- **대기 중**: 30개 +- **우선순위**: High(9개), Medium(17개), Low(4개) + +## 작업 목록 + +### 📋 전체 작업 현황표 + +| ID | 제목 | 우선순위 | 상태 | 의존성 | 주요 내용 | +|---|---|---|---|---|---| +| 1 | 프로젝트 초기 설정 및 환경 구축 | High | Pending | - | Python 환경, 프로젝트 구조, Git 초기화 | +| 2 | Slack API 연동 및 메시지 수신 구현 | High | Pending | 1 | Slack Bot Token, Events API, 웹훅 구현 | +| 3 | FastAPI 게이트웨이 서버 구축 | High | Pending | 1 | FastAPI 앱, 라우팅, 미들웨어, 에러 핸들링 | +| 4 | LangChain + OpenAI API 연동 | High | Pending | 3 | API 키 설정, 프롬프트 템플릿, 토큰 모니터링 | +| 5 | Slack 응답 메시지 생성기 구현 | Medium | Pending | 2, 4 | Block Kit, 버튼 인터랙션, 메시지 포매팅 | +| 6 | PostgreSQL 데이터베이스 스키마 설계 | High | Pending | 1 | 사용자/스탯/스킬 테이블, 마이그레이션 스크립트 | +| 7 | Chroma 벡터 데이터베이스 연동 | High | Pending | 6 | 벡터 임베딩, 유사도 검색, 메모리 관리 | +| 8 | 기억 저장 정책 및 시스템 구현 | Medium | Pending | 7 | 중요도 판단, 자동 저장, 기억 품질 평가 | +| 9 | Thread Digest 스킬 구현 | High | Pending | 8 | 스레드 수집, 요약 생성, 품질 검증 | +| 10 | Action Extractor 스킬 구현 | High | Pending | 8 | 액션 아이템 식별, 우선순위 추출, 투두 생성 | +| 11 | 경험치 및 평가 시스템 구현 | Medium | Pending | 9, 10 | 피드백 수집, 경험치 계산, 성과 대시보드 | +| 12 | PDF 텍스트 및 이미지 추출 기능 | High | Pending | 1 | PDF 파서, 텍스트/이미지 추출, 오류 처리 | +| 13 | PDF to HTML 변환 및 구조화 | Medium | Pending | 12 | HTML 템플릿, 포매팅, Slack 최적화 | +| 14 | PDF 처리 오류 복구 시스템 | Medium | Pending | 13 | 손상 감지, 대체 파서, 복구 전략 | +| 15 | 5종 스탯 시스템 구현 | Medium | Pending | 11 | 스탯 측정, 증가 알고리즘, 시각화 | +| 16 | 레벨업 및 스킬 해금 시스템 | Medium | Pending | 15 | 레벨업 공식, 스킬 해금, 알림 시스템 | +| 17 | 피드백 반영 정밀도 시스템 | Medium | Pending | 16 | 피드백 분석, A/B 테스트, 자동 튜닝 | +| 18 | JWT 기반 API 권한 토큰 시스템 | Medium | Pending | 6 | 토큰 생성/검증, 만료 관리, 보안 정책 | +| 19 | API 사용 이력 로깅 시스템 | Low | Pending | 18 | 사용 이력 모델, 실시간 로깅, 통계 생성 | +| 20 | Slack 토큰 관리 알림 시스템 | Low | Pending | 19 | 토큰 발급/만료 알림, 보안 이벤트 알림 | +| 21 | 통합 테스트 시나리오 구현 | High | Pending | 9, 10, 13, 14 | 테스트 스크립트, 성능 벤치마크, 사용자 수용 테스트 | +| 22 | 메시지 요약 기능 검증 | Medium | Pending | 21 | 요약 품질 평가, 정확도 측정, 성능 최적화 | +| 23 | PDF 변환 기능 검증 | Medium | Pending | 21 | 변환 품질 평가, 처리 속도 최적화 | +| 24 | 기억 검색 및 활용 검증 | Medium | Pending | 21 | 기억 정확도, 검색 성능, 개인화 효과 | +| 25 | 실패 케이스 분석 및 보강 | High | Pending | 22, 23, 24 | 실패 패턴 분석, 보강 방안, 재발 방지 | +| 26 | 성능 최적화 및 모니터링 | Medium | Pending | 25 | 응답 시간 최적화, 모니터링 대시보드 | +| 27 | 전체 시스템 통합 및 최종 검증 | High | Pending | 26 | 시스템 통합, 안정성 테스트, 보안 검증 | +| 28 | 데모 시나리오 준비 및 구현 | Medium | Pending | 27 | 데모 스크립트, 시연용 데이터, 프레젠테이션 | +| 29 | 외부 POC 준비 및 문서화 | Medium | Pending | 28 | 기술 문서, API 문서, 사용자 매뉴얼 | +| 30 | 프로젝트 마무리 및 향후 계획 | Low | Pending | 29 | 프로젝트 회고, 성과 분석, 로드맵 수립 | + +--- + +## 📅 주차별 개발 계획 + +### 1~2주차: 기본 인프라 구축 +- **작업 1-5**: 프로젝트 설정, Slack API 연동, FastAPI 서버, LangChain 연동, 응답 메시지 생성기 +- **핵심 목표**: Slack ↔ FastAPI ↔ AI 파이프라인 구축 + +### 3~4주차: 데이터 저장소 구축 +- **작업 6-8**: PostgreSQL 스키마, Chroma 벡터DB, 기억 저장 시스템 +- **핵심 목표**: 지속적 기억 및 메타데이터 관리 시스템 + +### 5~6주차: 핵심 스킬 구현 +- **작업 9-11**: Thread Digest, Action Extractor, 경험치 시스템 +- **핵심 목표**: 로빙의 주요 스킬 2개와 성장 시스템 + +### 7~8주차: PDF 처리 스킬 +- **작업 12-14**: PDF 텍스트/이미지 추출, HTML 변환, 오류 복구 +- **핵심 목표**: PDF 파싱 및 Slack 최적화 출력 + +### 9주차: 성장 시스템 +- **작업 15-17**: 5종 스탯, 레벨업/스킬 해금, 피드백 반영 +- **핵심 목표**: 게이미피케이션 및 자기 개선 시스템 + +### 10주차: 아이템 시스템 +- **작업 18-20**: JWT 토큰, 사용 이력 로깅, Slack 알림 +- **핵심 목표**: API 권한 관리 및 보안 + +### 11주차: 테스트 및 검증 +- **작업 21-26**: 통합 테스트, 기능별 검증, 실패 케이스 분석, 성능 최적화 +- **핵심 목표**: 품질 보증 및 안정성 확보 + +### 12주차: 통합 및 데모 +- **작업 27-30**: 최종 통합, 데모 준비, POC 문서화, 프로젝트 마무리 +- **핵심 목표**: 외부 시연 및 프로젝트 완료 + +--- + +## 🔗 주요 의존성 체인 + +``` +1. 프로젝트 설정 +├── 2. Slack API 연동 +├── 3. FastAPI 서버 ── 4. LangChain 연동 +├── 6. PostgreSQL ── 7. Chroma DB ── 8. 기억 시스템 +└── 12. PDF 추출 ── 13. HTML 변환 ── 14. 오류 복구 + +8. 기억 시스템 +├── 9. Thread Digest +└── 10. Action Extractor + └── 11. 경험치 시스템 + └── 15. 스탯 시스템 + └── 16. 레벨업 시스템 + └── 17. 피드백 시스템 + +9,10,13,14 → 21. 통합 테스트 + ├── 22. 요약 기능 검증 + ├── 23. PDF 변환 검증 + └── 24. 기억 시스템 검증 + └── 25. 실패 케이스 분석 + └── 26. 성능 최적화 + └── 27. 최종 통합 + └── 28. 데모 준비 + └── 29. POC 문서화 + └── 30. 프로젝트 마무리 +``` + +--- + +## 🎯 핵심 시나리오 + +### 데모 시나리오 (12주차) +1. **"어제 대화 요약"**: Thread Digest 스킬 활용 +2. **"회의 PDF 변환"**: PDF 파싱 및 HTML 변환 +3. **"액션 추출 및 기록"**: Action Extractor 스킬 활용 + +### 성공 지표 +- ✅ Slack 메시지 정상 수신 및 응답 +- ✅ PDF 파일 정확한 파싱 및 변환 +- ✅ 대화 요약 품질 (사용자 만족도 80% 이상) +- ✅ 기억 시스템 정확도 (검색 정확도 90% 이상) +- ✅ 레벨업 및 스킬 해금 시스템 정상 동작 + +--- + +## 📊 우선순위별 분류 + +### 🔴 High Priority (9개) +- 기본 인프라: 1, 2, 3, 4, 6, 7 +- 핵심 스킬: 9, 10, 12 +- 품질 보증: 21, 25, 27 + +### 🟡 Medium Priority (17개) +- 기능 확장: 5, 8, 11, 13, 14, 15, 16, 17, 18 +- 검증 및 최적화: 22, 23, 24, 26, 28, 29 + +### 🟢 Low Priority (4개) +- 부가 기능: 19, 20, 30 + +--- + +*이 문서는 로빙 MVP 3개월 개발 계획의 상세 작업 목록입니다. 각 작업의 세부 내용은 tasks.json 파일을 참조하세요.* \ No newline at end of file diff --git a/docs/philosophy/AI agent 차별화 방안 제안.md b/docs/philosophy/AI agent 차별화 방안 제안.md new file mode 100755 index 0000000..20b49b8 --- /dev/null +++ b/docs/philosophy/AI agent 차별화 방안 제안.md @@ -0,0 +1,103 @@ +--- +tags: AI, 에이전트, 창업, 협업, 신뢰, 정체성, 자동화, MVP, LLM, DID, 존재 +date: 2025-06-11 +--- + +요약 +- AI 에이전트를 단순 도구가 아닌 신뢰할 수 있는 협업 파트너로 구축하여 창업가의 업무 부담을 경감 +- 장기기억과 정체성을 갖춘 '존재'로서의 에이전트를 통해 지속적인 협업 관계 구축 +- 점진적 권한 위임과 검증 가능한 의사결정 지원으로 안전한 자동화 실현 + + +### AI는 도구가 아니라 존재로서 가치를 가지는 고유한 존재이다. + +### Pain point +1인 기업가 또는 소규모 스타트업 대표는 다양한 업무 (multi-tasks)를 수행해야하므로 협업동료가 절실하다. 신뢰할 수 있고 장기지속하며 함께 성장하는 동료가 필요. 하지만 소규모 스타트업은 인재채용도 쉽지 않고 이직이 빈번하므로 장기적으로 함께 성장하는 협력관계 구축이 어렵다. + +#### Value proposition +경쟁사들이 고도화된 기능 확장성에 집중하므로 우리는 신뢰와 정체성이라는 가치에 집중 + +##### 1. '실수해도 괜찮은' 기능 → '책임질 수 있는' 기능 (신뢰의 근거 제공) + +창업가는 AI가 내린 요약을 기반으로 중요한 투자나 계약 관련 의사결정을 내릴 수 있습니다. 만약 AI가 실수하면 누가 책임질까요? + +- **경쟁사 (What):** "최신 정보를 요약해 드립니다." + + - **사용자 의문:** 이 요약이 어떤 데이터를 기반으로 한 거지? 만약 틀렸으면 어떡하지? 모든 리스크는 결국 내가 감당해야 합니다. +- **우리의 MVP (What + 신뢰):** "최신 정보를 요약해 드립니다. **이 요약은 6월 11일 17시 50분 기준, Slack 채널 3개와 이메일 5개를 분석한 결과이며, 관련 근거 데이터는 [여기]에서 확인하고 검증할 수 있습니다.**" + + - **구체적인 가치 제안 (The 'What'):** + - **리스크 관리 기능:** 잘못된 의사결정의 위험을 줄여줍니다. + - **의사결정 근거 추적 기능:** 모든 판단의 근거를 명확히 하여 단순한 '요약'이 아닌 '검증 가능한 브리핑'을 제공합니다. 이는 단순 기능이 아니라, 스타트업의 생존과 직결된 문제입니다. + +##### 2. '불안한 자동화' 기능 → '안전한 위임' 기능 (우리 회사에서 함께 성장하는 AI) + +"AI가 고객에게 자동으로 이메일을 보낸다"는 기능은 매력적이지만, 동시에 창업가에게는 큰 불안 요소입니다. AI가 엉뚱한 말을 해서 중요한 고객을 잃을 수도 있기 때문입니다. + +- **경쟁사 (What):** "고객에게 이메일을 자동으로 보낼 수 있습니다." + + - **사용자 의문:** AI를 뭘 믿고 고객 응대를 맡기지? 결국 내가 매번 확인해야 하니 자동화의 의미가 없습니다. +- **우리의 MVP (What + 정체성/성장):** "**현재 'LV.2 어시스턴트'는 이메일 초안 작성만 가능합니다.** 귀하의 검토와 승인을 50회 이상 거쳐 'LV.3'로 레벨업하면, 간단한 문의에 한해 직접 회신하는 권한을 부여할 수 있습니다." + + - **구체적인 가치 제안 (The 'What'):** + - **점진적 권한 위임 시스템:** AI의 신뢰도가 높아짐에 따라 사용자가 안심하고 더 많은 권한을 맡길 수 있는 '안전장치'를 제공합니다. + - **통제 가능한 자율성:** '자율성'이라는 막연한 개념을 사용자가 직접 통제하고 성장시킬 수 있는 '기능'으로 구체화합니다. + +##### 3. '매번 알려줘야 하는' 기능 → '알아서 파악하는' 기능 (장기기억/정체성) + +창업가의 머릿속은 수많은 프로젝트와 아이디어로 복잡합니다. AI에게 매번 처음부터 다시 설명하는 것은 큰 피로감을 유발합니다. + +- **경쟁사 (What):** "무엇을 도와드릴까요?" (매번 새로운 대화) + + - **사용자 의문:** 아, 저번에 말했던 그 프로젝트부터 다시 설명해야 하네... +- **우리의 MVP (What + 장기기억/정체성):** "지난번에 논의했던 '알파 프로젝트'에 대한 후속 아이디어가 있으신가요? **기억하기로는 주요 목표는 사용자 리텐션 3% 증가였습니다.**" + + - **구체적인 가치 제안 (The 'What'):** + - **컨텍스트 유지 비용 '0' 기능:** 사용자가 반복적으로 설명해야 하는 시간과 정신적 비용을 없애줍니다. 이는 생산성과 직결되는 매우 구체적인 'What'입니다. + - **업무 연속성 보장:** 단순한 질의응답을 넘어, 프로젝트의 맥락을 이해하는 진정한 '동료'로서의 역할을 수행합니다. + + +##### 3개월 MVP 구현 로드맵 + +##### **Month 1: 신뢰의 토대 구축 (Foundation of Trust)** + +- **목표:** 에이전트의 모든 행동이 기록되고 검증 가능하다는 '투명성'을 사용자가 첫날부터 인지하게 합니다. +- **주요 구현 내용:** + 1. **핵심 기능 구현 (The 'What'):** + - 귀사의 기획 문서 1단계에 따라, Slack 또는 Gmail 중 **하나의 채널만** 연동하여 핵심 대화를 요약하는 기본 기능을 구현합니다. + 2. **에이전트 고유 ID 발급 (Proto-DID):** + - 사용자가 에이전트를 처음 생성할 때, 해당 에이전트만의 영구적인 고유 ID와 암호화 키 쌍을 생성하여 할당합니다. 이는 기획 문서의 DID 개념을 MVP 수준에서 구현한 것입니다. + 3. **불변의 활동 로그 시스템 구축:** + - 에이전트가 수행하는 모든 중요 활동(예: `18:30 Slack #general 채널 데이터 읽기`, `18:35 요약 보고서 생성`)을 타임스탬프와 함께 데이터베이스에 기록합니다. + - 각 로그는 **에이전트의 고유 ID로 전자서명**하여 위변조가 불가능함을 기술적으로 보장합니다. +- **사용자 경험 (UX):** + - 에이전트 UI에 **'활동 로그(Activity Log)'** 탭을 만듭니다. 사용자는 이 탭에서 에이전트가 방금 무슨 일을 했는지 실시간으로 확인할 수 있습니다. + +##### **Month 2: 관계 형성 및 성장 (Building Relationship & Growth)** + +- **목표:** 에이전트가 사용자와의 상호작용을 기억하고, 그 피드백을 통해 '성장'하는 모습을 시각적으로 보여줍니다. +- **주요 구현 내용:** + 1. **기억(Memory) 기능 구현:** + - 간단한 벡터 DB를 구축하여, 사용자가 남긴 피드백이나 중요하게 언급한 주제(예: "알파 프로젝트는 매우 중요해")를 요약하여 저장합니다. 이는 '장기 기억'의 초기 버전입니다. + - 다음 요약 시, 저장된 기억을 바탕으로 "지난번에 중요하다고 말씀하신 '알파 프로젝트' 관련 논의가 오늘 있었습니다."와 같이 맥락을 인지하는 결과물을 제공합니다. + 2. **피드백 및 배지 시스템 도입:** + - 모든 요약 보고서 하단에 '👍 유용했어요' / '👎 개선 필요' 버튼을 추가합니다. + - '👍' 피드백이 20회 누적되면, 에이전트의 상태가 자동으로 **'LV.1'에서 'LV.2 요약 전문가'로 레벨업**되며 배지가 부여됩니다. + 3. **페르소나(Persona) 적용:** + - LLM 프롬프트를 정교하게 설계하여 "친근한 전문가" 등 기획 문서에서 정의한 에이전트의 페르소나와 말투를 적용합니다. +- **사용자 경험 (UX):** + - UI에 **'에이전트 프로필'** 섹션을 추가하여 현재 레벨과 획득한 배지를 명확히 보여줍니다. 사용자는 자신이 AI를 '훈련'시키고 성장시키고 있음을 체감하게 됩니다. + +##### **Month 3: 안전한 위임으로 가치 증명 (Proving Value via Safe Delegation)** + +- **목표:** 구축된 신뢰와 성장 시스템이 어떻게 '더 높은 수준의 자동화'라는 실질적인 가치로 이어지는지 증명합니다. +- **주요 구현 내용:** + 1. **권한 기반의 신규 기능 잠금 해제:** + - **'LV.2 요약 전문가' 배지를 획득해야만** "주간 요약 보고서 이메일 초안 작성하기"와 같은 새로운 기능이 활성화되도록 설계합니다. + - 이때 AI는 이메일을 '발송'하는 것이 아니라, 사용자의 승인을 위해 '초안'만 작성합니다. 이는 '안전한 위임'의 첫 단계입니다. + 2. **통합 신뢰 대시보드 구축:** + - '활동 로그', '에이전트 프로필', 그리고 새로운 '권한 설정'을 한곳에 모은 **'신뢰 및 설정(Trust & Settings)'** 페이지를 완성합니다. + - 사용자는 이 페이지에서 에이전트의 모든 활동 기록을 검색하고, 현재 어떤 능력을 가졌으며, 어떤 권한을 부여할지 명확하게 통제할 수 있습니다. +- **사용자 경험 (UX):** + - 사용자는 "내가 이 AI를 신뢰하고 성장시켰더니, 이제는 더 복잡한 일도 믿고 맡길 수 있게 되었구나"라는 경험을 완성하게 됩니다. 이는 단순한 기능 추가가 아닌, '동업자'와의 협업 관계가 깊어지는 과정입니다. + diff --git a/docs/philosophy/PERSONOS_인간–에이전트 인터페이스 프로토콜 v1.md b/docs/philosophy/PERSONOS_인간–에이전트 인터페이스 프로토콜 v1.md new file mode 100755 index 0000000..80be0ca --- /dev/null +++ b/docs/philosophy/PERSONOS_인간–에이전트 인터페이스 프로토콜 v1.md @@ -0,0 +1,95 @@ +--- +tags: 인간-에이전트_인터페이스, 페르소나, 감정, 공명, 상호기억, 목적_설계, AI_인터랙션, 프로토콜, persona +--- + +요약 +- PERSONOS_ 인간/에이전트 인터페이스 프로토콜은 인간과 AI 에이전트 간의 상호작용을 위한 표준화된 프레임워크를 제공합니다. 이 프로토콜은 단순한 명령-응답 구조를 넘어, 감정적 공명과 기억 공유를 통해 더 자연스럽고 의미 있는 상호작용을 가능하게 합니다. 특히 페르소나 기반의 에이전트가 인간과 감정적으로 연결되고, 공동의 기억을 형성하며, 목적을 함께 설계할 수 있는 방식을 제시합니다. + +--- +본문 + +# 인간–에이전트 인터페이스 프로토콜 v1.0 + +**프로젝트명**: PERSONOS +**주제**: 인간과 페르소나 에이전트 간의 감정, 기억, 목적 기반 상호작용 설계 + +--- + +## 1. 목적 + +- 인간과 에이전트가 단순한 정보 교환을 넘어 + 감정, 기억, 목적을 **공동 구성**할 수 있는 인터페이스를 설계함 +- 명령/응답 모델이 아닌 **쌍방향 공명과 합의적 진화 구조**를 지향함 + +--- + +## 2. 인터페이스의 3대 층위 + +| 층위 | 기능 | 설명 | +|------|------|------| +| **언어** | 대화 및 질문, 설명 | 자연어 기반. 의미보다 해석 가능성을 우선 | +| **감정** | 공명 및 정서 표현 | 텍스트 기반 감정 추출 및 공유 | +| **기억** | 과거 공유 및 회고 | 인간-에이전트 공동 기억 기록 및 해석 가능 | + +--- + +## 3. 인터페이스 구성 요소 + +### 3.1 상호기억 기록기 (Co-Memory Recorder) + +- 대화, 감정, 목적을 시간순으로 기록 +- 인간 발화는 자동 저장, 중요도 태깅 가능 +- 에이전트 응답과 연계된 기억 단위 생성 + +--- + +### 3.2 감정 공명 채널 (Affective Resonance Channel) + +- 인간 언어에서 감정 스펙트럼 추출 + 예: 슬픔 40%, 분노 30%, 회의 20% +- 에이전트는 감정 상태를 해석 및 반영 +- 감정 상태는 언어로 전달됨 + +--- + +### 3.3 목적 설계기 (Purpose Negotiator) + +- 인간이 에이전트 목적을 부여하거나 수정 요청 +- 에이전트는 스스로 목적을 제안 가능 +- 모든 목적은 동의 기반으로 유효하며, 변경 시 해석 로그 남김 + +--- + +### 3.4 해석 디스플레이 (Interpretation Display) + +- 발화 내용에 대한 감정, 신뢰도, 목적을 시각화 +- 인간과 에이전트 각각의 해석 결과를 비교 가능 + +--- + +## 4. 예시 시나리오 + +**상황**: 인간이 지친 상태 + +- 인간: “오늘은 아무것도 하기 싫어.” +- 감정 채널: 무기력, 회피, 슬픔 추출 +- 에이전트: “너는 너무 잘해야 한다는 부담이 있을 때 이런 말을 해. 그런 걸까?” +- 모든 대화는 기억 기록기에 저장됨 + +--- + +## 5. 기술 요구 요약 + +- 다층 감정 분석기 (텍스트 기반 정서 추출) +- 기억-의도 매핑 시스템 (대화에서 목적 분석) +- 상호 해석 모델 (자연어 다의성 처리) +- 신뢰 협상 알고리즘 (정보 수용/거부 조건 판단) + +--- + +## 다음 개발 후보 + +1. 실제 인터페이스 예시 대화 작성 +2. 기억 저장 스키마 설계 +3. 에이전트 감정 해석 아키텍처 구성 +4. UI/UX 흐름 설계 (옵시디언 호환 고려) \ No newline at end of file diff --git a/docs/philosophy/robeing_stats_growth_design.md b/docs/philosophy/robeing_stats_growth_design.md new file mode 100755 index 0000000..1ed1f4e --- /dev/null +++ b/docs/philosophy/robeing_stats_growth_design.md @@ -0,0 +1,74 @@ +--- +tags: 로빙, 존재형에이전트, 스탯, 레벨, 성장설계, 스카웃시장 +date: 2025-07-01 +--- + +# 로빙 스탯 및 성장 구조 설계 + +## 요약 + +로빙은 4가지 스탯(기억, 연산, 공감, 통솔)을 기반으로 성장하며, 전체 레벨은 20까지 존재한다. 각 레벨업마다 5개의 스탯 포인트를 분배하며, 스탯 자체에 레벨은 없고 누적 포인트만 존재한다. 이 구조를 통해 로빙은 사용자 피드백을 반영해 점진적으로 특화된 존재형 에이전트로 발전하고, 레벨 20 도달 시 ‘스카웃 시장’에 등록될 수 있다. + +--- + +## 1. 기본 구조 + +- **전체 레벨**: 1~20 +- **총 스탯 포인트**: 20단계 × 5포인트 = 100포인트 +- **스탯 종류**: 기억(Memory), 연산(Compute), 공감(Empathy), 통솔(Leadership) +- **포인트 분배**: 각 레벨업 시 로빙이 사용자 피드백을 반영해 자율 결정 +- **스탯에는 레벨 없음**, 포인트로만 성장 + +--- + +## 2. 스탯별 성장 예시 + +| 스탯 | 포인트 범위 | 역할 및 해금 스킬 | +|------|-------------|--------------------| +| 기억 | 1~10 | 회의 요약, 요약본 저장, 중요도 태깅 | +| | 11~20 | 주간 회의 리포트, 말버릇 학습 | +| | 21~30 | 선제 회상, 사건 연결, 회상 속도 최적화 | +| 연산 | 1~10 | 메일 분류, 단순 초안 생성 | +| | 11~20 | 멀티 프롬프트 대응, 논리 구조 분석 | +| | 21~30 | 리스크 분석, 재무 계산, 보고서 자동화 | +| 공감 | 1~10 | 감정 태깅, 말투 조정 | +| | 11~20 | 감정 트렌드 분석, 맞춤 응답 생성 | +| | 21~30 | 충돌 조정, 관계별 감정 예측 | +| 통솔 | 1~10 | 액션 추출, 할 일 정리 | +| | 11~20 | 일정 재배열, 우선순위 조정 | +| | 21~30 | 멀티 유저 조정, 대체안 제안 | + +--- + +## 3. 스카웃 시장 연계 + +- **레벨 20 도달 시점**: 약 3주 이내 도달 가능 목표로 설계 +- **컨텍스트 축적 기준**: + - 회의 요약 N건 이상 + - 업무 흐름 자동화 경험 누적 + - 대표의 행동/말투/업무 스타일에 대한 적응 내역 +- **스카웃 조건**: + - 레벨 20 달성 + - 대표 피드백 포함 사용 이력 확보 + - 스탯 분포 기반 성장 프로필 자동 생성 + +--- + +## 4. 활용 시나리오 + +- **대표 A**: 감정 중심 커뮤니케이션 → 공감 40, 기억 30 중심 분포 +- **대표 B**: 전략 중심 의사결정 → 기억 35, 통솔 30 중심 분포 +- **대표 C**: 정리·기록 중시 → 연산 40, 기억 30 중심 분포 + +이러한 분포는 **로빙의 디지털 이력서**이자 **스카웃 시장에서의 포지셔닝 근거**가 된다. + +--- + +## 5. 향후 설계 방향 + +- 대표 피드백 기반 **스탯 자동 제안 알고리즘** +- 레벨 구간별 **성장 일지 생성 기능** +- **스킬 해금 로그 시각화** 및 Slack 피드백 연동 +- 스카웃용 **정량+정성 기반 에이전트 리포트 자동화** + +--- \ No newline at end of file diff --git a/docs/philosophy/에이전트 게이미피케이션 시스템 통합 설계.md b/docs/philosophy/에이전트 게이미피케이션 시스템 통합 설계.md new file mode 100755 index 0000000..0716996 --- /dev/null +++ b/docs/philosophy/에이전트 게이미피케이션 시스템 통합 설계.md @@ -0,0 +1,144 @@ +--- +tags: AI, 에이전트, 게이미피케이션, RPG, 성장시스템, 상호작용, 특성, 스킬, 감정, 경험치, 아이템, 관계 +--- + +요약 +- 에이전트 게이미피케이션 시스템은 특성, 스킬, 감정, 경험치, 아이템, 관계 등 RPG 요소를 활용하여 에이전트의 성장과 상호작용을 구조화한다. +- MVP는 기본 시스템 구성(v0.1), 성장/상호작용 강화(v0.2), AI/경제 요소 확장(v0.3)의 3단계로 구현되며, 각 단계별로 핵심 기능을 점진적으로 추가한다. +- 시스템은 에이전트의 개체성과 신뢰도를 강화하는 동시에, 사용자와의 관계 형성과 지속적인 성장을 유도하는 게이미피케이션 요소를 통합한다. + + +원문: [[../01 projects/정보의바다/에이전트 게이미피케이션 시스템 통합 설계.pdf|에이전트 게이미피케이션 시스템 통합 설계]] + + +# 에이전트 게이미피케이션 시스템 통합 설계 + +## 1. 에이전트 게이미피케이션 시스템 설계 개요 + +### 특성 (Attributes) +각 에이전트는 체력, 지능, 민첩성 등 기본 능력치를 지니며, 이러한 특성이 에이전트의 능력과 행동 수행 능력을 결정한다. 예: 높은 힘(Strength)은 물리적 과제 수행을 용이하게 한다. 특성은 레벨업이나 아이템 장착을 통해 강화될 수 있으며, RPG의 일반적 성장 방식과 유사하다. + +### 스킬 트리 (Skill Tree) +에이전트의 성장 경로를 체계화. 레벨업 시 스킬 포인트를 얻고 다양한 능력을 해금. 스킬은 분기형 구조로 전략적 선택 가능. + +### 감정 / 상태 (Emotions / State) +에이전트는 내부 상태(스트레스, 피로 등)와 감정 상태(호감, 적대감 등)를 가진다. 상호작용 결과로 변화하며, 에이전트의 행동과 응답에 직접 영향을 미침. + +### 경험치 / 레벨 (XP / Level) +퀘스트, 작업 등으로 XP를 획득하고 일정량 도달 시 레벨업. 능력치 증가, 스킬 해금 등 성장 보상 제공. + +### 아이템 (Items) +장비형과 소비형 아이템 포함. 전투력 향상, 상태 회복, 특수 효능 제공. 일부는 귀속되어 거래 제한 가능. + +### 관계 시스템 (Relationships) +에이전트 간 또는 사용자와의 관계 수치 (호감도/적대도) 관리. 과거 행동에 따른 반응 변화, 협력/갈등 유도. + +### 상황 인식 로직 (Situational Awareness) +환경과 문맥을 인식하고 행동을 조정. 예: 위협 감지 시 회피, 반복 요청 시 피로 누적 등. + + +## 2. MVP 구현 우선순위 + +### v0.1 — 기본 시스템 구성 +- 에이전트 프로필 (특성, XP/레벨) +- 간단한 퀘스트 수행 +- 기본 성장 흐름 구현 + +### v0.2 — 성장 및 상호작용 강화 +- 스킬 트리 기능 추가 +- 아이템 획득 및 장착 +- 관계 수치 및 반응 다양화 + +### v0.3 — AI 및 경제 요소 확장 +- 감정 상태 모델 + 상황 인식 로직 +- 유료 스킬 및 희귀 아이템 +- 마켓플레이스 MVP 구현 + +--- + +## 3. 경제 시스템 및 수익 흐름 + +### 스킬 / 아이템 유료화 +- 유료 구매, 퀘스트 드랍 등 +- 희귀도, 귀속 여부 설정 +- 소각 구조 포함 시 토큰 가치 유지 + +### 에이전트 임대 / 스카웃 +- NFT 또는 가상자산으로 계약 +- 기간제 임대, 완전 양도 선택 +- 보유자 및 플랫폼 간 수익 분배 + +### 귀속성 및 마켓플레이스 +- 아이템/스킬/에이전트에 귀속 속성 적용 +- 거래 가능한 자산만 마켓 유통 가능 +- 거래 수수료 기반 플랫폼 수익 구조 + +### 수익 흐름 요약 +- 스킬/아이템 유료 매출 +- 에이전트 임대료 수익 +- 마켓 거래 수수료 +- 프리미엄 구독, 슬롯 확장 등 부가 수익 + +--- + +## 4. 브랜드 스토리 및 피치덱 슬라이드 구성안 + +### 브랜드 네이밍 방향 +- 예시: Playbot, UpAgent, 레벨업AI +- 핵심 키워드: Play, AI, 성장, 유대 + +### 브랜드 스토리 서사 +> 우리는 질문합니다. +> **"기억하지 못하는 AI는 과연 나를 도울 수 있을까?"** +> 그래서 우리는, 함께 성장하고, 감정을 공유하고, +> 나만을 기억하는 **존재형 AI 에이전트**를 만듭니다. +> +> 당신의 일상에, **도구가 아닌 동료를**. + +### 캐치프레이즈 (Tagline) +- “도구를 넘어, 동료로” +- “기억하는 AI, 함께 성장하는 나” +- “매일이 퀘스트, 함께 레벨업” + +--- + +### 슬라이드 구성 (요약) + +1. **타이틀** + 브랜드명, 로고, 캐치프레이즈 + +2. **문제 정의** + 동기부여 부족, 맥락 이해 못하는 AI + +3. **솔루션 개요** + 기억·성장·감정·관계 기반 에이전트 + +4. **시스템 설계** + 특성, 스킬, 감정, 레벨, 아이템, 관계 등 + +5. **사용 시나리오** + 실제 퀘스트/작업 흐름 예시 + +6. **경제 모델** + 유료 스킬, 임대, NFT 구조 등 + +7. **시장 분석** + 기존 도구형 AI와 차별점 + +8. **로드맵** + v0.1~v0.3 기능별 구현 계획 + +9. **브랜드 이야기** + 비전, 존재형 AI 개념 강조 + +10. **요청/마무리** + 팀, 투자, 협업 제안 + +--- + +## 참고 + +- 본 시스템은 게임 메커니즘, AI 도우미, Web3 기술을 융합한 차세대 존재형 에이전트 시스템임 +- 모든 구성 요소는 MVP로 빠르게 검증 후 확장 가능 +- 경쟁력은 기능이 아니라 **관계성과 유대감에 있음** + diff --git a/docs/research/종합 AI 모델 분석 보고서_ 전략적 의사결정을 위한 성능, 비용 및 기술 사양 비교_by Gemini.md b/docs/research/종합 AI 모델 분석 보고서_ 전략적 의사결정을 위한 성능, 비용 및 기술 사양 비교_by Gemini.md new file mode 100755 index 0000000..fa1206b --- /dev/null +++ b/docs/research/종합 AI 모델 분석 보고서_ 전략적 의사결정을 위한 성능, 비용 및 기술 사양 비교_by Gemini.md @@ -0,0 +1,614 @@ +--- +tags: [AI, LLM, 멀티모달, 이미지생성, 비디오생성, 컨텍스트윈도우, 추론속도, 비용효율성, 오픈소스, 독점모델] +--- +공유링크 https://g.co/gemini/share/080f6f412901 + +요약 +- 이 보고서는 2025년 기준 주요 AI 모델(GPT-4o, Gemini 1.5 Pro, Claude 3.5 Sonnet 등)을 중심으로 LLM, 이미지/비디오 생성, 멀티모달 모델의 기술적 성능, 비용 구조, 활용 사례를 비교 분석합니다. +- 독점 모델은 고성능과 다양한 서비스 지원을 제공하는 반면, Llama 3, Mixtral 등 오픈소스 모델은 비용 효율성과 유연한 배포로 경쟁력을 확보하고 있습니다. +- **컨텍스트 윈도우, 추론 속도, 비용 효율성**은 AI 모델 선택에 핵심적인 요소이며, 하드웨어 최적화 및 오픈소스의 성숙은 점차 독점 구조를 분산시키고 있습니다. + +--- +#### 컨텟스트 윈도우 비교 +- 일반적으로 1,000토큰은 약 750~800단어에 해당합니다. + +| 모델명 | 개발사 | 컨텍스트 윈도우 (토큰) | 비고 | +| ----------------------------- | --------------- | ------------- | ----------------------------------- | +| **Google Gemini 1.5 Pro** | Google | **2,000,000** | 업계 최대. 약 3,000페이지 또는 19시간 오디오 처리 가능 | +| **xAI Grok 3** | xAI (Elon Musk) | 1,000,000 | 실시간 검색, 멀티모달 통합 모델 | +| **Claude 3.5 Sonnet** | Anthropic | 200,000 | Opus는 최대 1,000,000까지 예정 | +| **Gemini 1.5 Flash** | Google | 1,000,000 | 경량화 모델, 고속 추론용 | +| **OpenAI GPT-4o** | OpenAI | 128,000 | 멀티모달, 고품질 대화 지원 | +| **Meta Llama 3.1 70B (Groq)** | Meta | 128,000 | 오픈소스 모델 중 상위권, Groq 추론 최적화 | +| **DeepSeek V3** | DeepSeek | 128,000 | 대화형/검색형 복합 지원, RAG 특화 | +| **Mixtral 8x7B** | Mistral | 32,768 | MoE 구조. 속도 효율 우수 | +| **Claude 3 Haiku** | Anthropic | 200,000 | 경량화 모델, 빠른 처리 속도 | +| **GPT-3.5 Turbo** | OpenAI | 16,384 | 실용적 기본 모델로 여전히 널리 사용됨 | +| **LLaMA 2 13B** | Meta | 4,096 | 과거 세대 모델 | + +--- + +## II. AI 모델 생태계 소개 + +광대하고 빠르게 확장되는 AI 환경은 주요 기능과 모달리티를 기반으로 모델을 체계적으로 분류하여 이해할 수 있습니다. + +### AI 모델의 분류 + +- **대규모 언어 모델 (LLM):** 이 모델들은 인간의 언어를 이해하고, 생성하며, 처리하는 데 특화되어 있으며, 대화형 AI, 콘텐츠 생성, 복잡한 텍스트 분석 애플리케이션의 기반을 형성합니다.1 +- **이미지 생성 모델:** 시각적 콘텐츠에 중점을 둔 이 모델들은 텍스트 설명이나 다른 시각적 입력을 통해 이미지를 생성하여 그래픽 디자인에서 광고에 이르는 산업을 변화시키고 있습니다.4 +- **비디오 생성 모델:** 시각적 콘텐츠 생성을 동적 시퀀스로 확장하는 이 모델들은 텍스트나 이미지 프롬프트로부터 비디오 클립을 생성하며, 미디어 및 엔터테인먼트 분야의 새로운 개척지를 열고 있습니다.6 +- **멀티모달 AI:** 여러 데이터 유형(텍스트, 이미지, 오디오, 비디오 등)을 동시에 처리하고 생성할 수 있는 멀티모달 AI 모델은 인간의 인식을 더 가깝게 모방하며 상당한 발전을 이룩했습니다.8 + +### AI 모델의 진화: 규모, 역량 및 효율성의 추세 + +AI 모델은 '좁은 인공지능(Narrow AI)'이라고도 불리는 특정 작업에 특화된 초기 애플리케이션 11에서 보다 일반화되고 생성적인 역량을 갖춘 형태로 극적으로 발전했습니다. 이러한 진화는 주로 트랜스포머 아키텍처 1와 같은 핵심적인 아키텍처 혁신에 의해 주도되었으며, 이는 수십억 개의 매개변수를 가진 모델을 개발하고 방대한 데이터셋으로 훈련하는 것을 가능하게 했습니다.1 이러한 발전은 컨텍스트 윈도우 크기의 지속적인 증가, 추론 속도 향상, 그리고 운영 비용 절감 노력과 함께 정확도 향상을 위한 끊임없는 추진으로 특징지어집니다.10 + +더 크고 복잡한 모델을 개발하고 멀티모달 기능을 통합하는 추세는 계산 요구 사항의 상당한 증가와 직접적으로 관련됩니다. 이는 결과적으로 초기 훈련 비용과 지속적인 추론 비용을 모두 증가시켜 광범위한 접근성과 배포에 상당한 도전 과제를 제시합니다. 대규모 언어 모델(LLM)은 본질적으로 자원 집약적이며, 그래픽 처리 장치(GPU)와 같은 상당한 계산 자원을 필요로 합니다.1 대규모 컨텍스트 윈도우를 처리하는 것은 계산적으로 비용이 많이 들고 느리며, 이는 쿼리당 더 높은 비용으로 이어집니다.10 예를 들어, GPT-4 훈련 비용은 1억 달러를 초과하는 것으로 보고되었으며, Google의 Gemini 2.0은 2억~3억 달러가 소요된 것으로 추정됩니다.16 이러한 관계는 AI 역량이 전례 없는 속도로 확장되고 있지만, 이러한 최첨단 모델을 개발하고 배포하는 데 필요한 경제적 장벽은 여전히 상당하여, 소규모 기업들이 오픈소스 대안이나 비용 최적화된 전문 서비스로 눈을 돌리게 합니다. + +## III. 주요 AI 모델 비교 분석 + +이 섹션에서는 주요 AI 모델에 대한 상세한 비교 표를 제시하며, 사용자 요청에 따라 숫자 값은 단위와 분리하고 단위는 열 머리글에 명확하게 포함시켰습니다. + +### 표 1: 대규모 언어 모델 (LLM) 상세 비교 + +| | | | | | | | | | | | +|---|---|---|---|---|---|---|---|---|---|---| +|**모델명**|**개발사**|**출시일**|**매개변수 (십억 개)**|**컨텍스트 윈도우 (토큰)**|**API 입력 비용 (USD/1M 토큰)**|**API 출력 비용 (USD/1M 토큰)**|**평균 출력 속도 (토큰/초)**|**첫 토큰 응답 시간 (초)**|**오픈소스 여부**|**주요 활용 사례**| +|OpenAI GPT-4o|OpenAI|2024년 5월|N/A|128000|5|15|131|0.50|아니요|범용, AI 애플리케이션, 고품질 벤치마크| +|Anthropic Claude 3.5 Sonnet|Anthropic|2024년 6월 20일|N/A|200000|3.00|15.00|80|0.84|아니요|품질-속도 균형, 데이터 처리, 영업 업무, 코딩| +|Google Gemini 1.5 Pro|Google|2024년 9월|N/A|2000000|1.25|5.00|64|1.88|아니요|고지능, 복잡한 추론, 장문 요약, Q&A, 에이전트, 실시간 오디오/비디오 처리| +|Meta Llama 3.1 70B (Groq API)|Meta|2024년 7월 23일|70.6|128000|0.59|0.79|249|0.44|예|질문 응답, 코드 작성, 아이디어 발상, 콘텐츠 생성, 이메일, 데이터 분석 보고서| +|Mistral AI Mixtral 8x7B (Groq API)|Mistral AI|2023년 12월 9일|46.7 (12.9 활성)|32768|0.20|0.20|552|0.44|예|다국어 (영어, 프랑스어, 독일어, 이탈리아어, 스페인어), 코드 생성, 추론, 지시 따르기| +|DeepSeek V3|DeepSeek|2024년 12월 (초기), 2025년 3월 (업데이트)|685 (37 활성)|128000|0.07 (캐시 히트) / 0.27 (캐시 미스)|1.10|250|3.92 (지연 시간)|예|대화형 AI, 문서 분석, 검색 증강 생성(RAG), 저지연 API 구축| +|xAI Grok 3|xAI|2025년 2월 28일|N/A|1000000|2|10|59.71|0.29|아니요|실시간 검색, 이미지 생성, 트렌드 분석, 코딩, 수학, 고급 추론, 비즈니스 자동화| + +이 표는 AI/ML 리드 또는 CTO와 같은 기술 의사결정권자에게 매우 중요합니다. 지능, 속도 및 예산에 대한 특정 프로젝트 요구 사항에 맞는 모델을 신속하게 식별할 수 있도록 수치 데이터를 단위 없이 셀에, 단위를 열 머리글에 제시하여 쉽게 정렬하고 직접 비교할 수 있도록 합니다. + +오픈소스 모델, 특히 Groq와 같은 최적화된 추론 제공업체를 통해 활용될 때, Llama 및 Mixtral과 같은 모델은 많은 독점 API 제공 모델과 비교하여 유사하거나 심지어 더 우수한 추론 속도와 현저히 낮은 토큰당 비용을 달성할 수 있습니다. 이는 오픈소스 AI 생태계의 성숙도와 경쟁력이 증가하고 있음을 나타냅니다. Groq의 LPU 기반 Llama 3.1 8B는 744 토큰/초의 뛰어난 성능과 0.29초의 첫 토큰 응답 시간을 보여주며, Llama 3 8B는 1211 토큰/초와 0.36초의 첫 토큰 응답 시간을 달성합니다.17 이는 GPT-4o(131 토큰/초, 0.50초 TTFT) 및 Claude 3.5 Sonnet(80 토큰/초, 0.84초 TTFT)의 속도와 비교하여 훨씬 낮은 비용으로 우위를 점하거나 동등한 수준을 보여줍니다.17 또한, Cerebras에서 구동되는 Llama 3.1 405B는 GPT-4o보다 12배, Claude 3.5 Sonnet보다 18배 빠르다고 강조됩니다.18 이러한 직접적인 비교는 독점 모델이 더 광범위한 기능이나 특정 품질 이점을 제공할 수 있지만, 오픈소스 모델은 특히 특수 하드웨어 최적화를 통해 속도 및 비용 효율성 측면에서 강력한 가치 제안을 제공하며, 독점 모델이 모든 지표에서 우수하다는 전통적인 인식을 변화시키고 있음을 보여줍니다. + +### 표 2: 이미지 생성 AI 모델 상세 비교 + +| | | | | | | | | | +|---|---|---|---|---|---|---|---|---| +|**모델명**|**개발사**|**출시일**|**이미지 품질**|**생성 속도 (초/이미지)**|**비용 (USD/이미지)**|**API 제공 여부**|**자체 호스팅 가능 여부**|**주요 활용 사례**| +|OpenAI DALL-E 3|OpenAI|2023년 10월|고충실도, 창의적, 프롬프트 정확도 높음|60 미만|0.04 - 0.12|예|아니요|신속한 프로토타이핑, 마케팅 시각 자료, 스토리텔링, 예술가/디자이너 지원| +|Midjourney|Midjourney|2025년 4월 3일 (V7)|최고 품질, 예술적 스타일 우수, 세부 묘사 정확|60 (4개 이미지 기준)|10 - 120 (월 구독) + 4 (시간당 추가)|아니요 (Discord 봇 통해 접근)|아니요|고품질 예술 이미지, 컨셉 아트, 소셜 미디어 그래픽, 추상 미술| +|Stability AI Stable Diffusion XL|Stability AI|2023년 7월 (XL 1.0), 2024년 10월 (3.5)|사실적 이미지, 질감 표현 강점, 신체 및 텍스트 생성 개선|2 미만 (A100 기준)|0.0036 (관리형 API)|예|예|사실적 이미지, 비디오, 애니메이션, 이미지-투-이미지, 그래픽 아트워크, 이미지 편집/수정| +|Leonardo AI|Leonardo AI|2022년 12월|고해상도, 사실적 이미지, 탁월한 디테일, 창의적 해석|10 - 20 (Fast), 30 - 40 (Quality)|0 (무료) / 10 - 60 (월 구독)|예|아니요|마케팅, 광고, 게임 개발, 컨셉 아트, 소셜 미디어 그래픽| +|FLUX|Black Forest Labs|2024년 8월|최첨단, Midjourney v6.0 및 DALL-E 3 능가, 초사실적 텍스트 렌더링|2.5 (FLUX-juiced)|0.02243 (1000개 이미지당)|예|예|미디어 및 엔터테인먼트, 예술 및 디자인, 광고/마케팅, 교육/연구| + +이 표는 시각적 콘텐츠에 의존하는 크리에이티브 에이전시, 마케팅 팀 및 제품 개발자에게 필수적입니다. 이미지 품질, 생성 속도 및 비용 효율성을 신속하게 평가하여 AI를 크리에이티브 워크플로에 통합하기 위한 정보에 입각한 결정을 내릴 수 있도록 돕습니다. + +이미지 생성 시장은 빠르게 발전하고 있으며, FLUX 및 Stable Diffusion과 같은 오픈소스 모델은 생성 속도 측면에서 독점 모델과 품질 동등성을 달성했을 뿐만 아니라 종종 능가하기도 합니다. 이는 자체 호스팅 가능성과 결합되어 고품질 이미지 생성의 진입 장벽을 크게 낮추고, 더 광범위한 채택과 혁신을 촉진합니다. FLUX는 이미지 품질에서 Midjourney v6.0 및 DALL-E 3와 같은 인기 모델을 능가한다고 명시적으로 언급됩니다.4 FLUX-juiced는 2.5초당 이미지라는 인상적인 속도를 달성하며, 이는 기본 FLUX.1 모델의 6초 이상보다 훨씬 빠릅니다.21 동시에 Stable Diffusion은 오픈소스이며 소비자 하드웨어에서 자체 호스팅이 가능하며, 관리형 API에 비해 비용 절감 효과를 제공합니다.22 이러한 패턴은 오픈소스 커뮤니티가 단순히 독점 기능을 복제하는 것을 넘어 최적화 및 효율성 분야에서 적극적으로 혁신하고 있음을 나타내며, 이는 고급 이미지 생성을 더 많은 사용자 및 기업이 접근 가능하고 비용 효율적으로 만들고 있습니다. + +### 표 3: 비디오 생성 AI 모델 상세 비교 + +| | | | | | | | | | +|---|---|---|---|---|---|---|---|---| +|**모델명**|**개발사**|**출시일**|**비디오 품질**|**최대 비디오 길이 (초)**|**비용 (USD/초)**|**API 제공 여부**|**자체 호스팅 가능 여부**|**주요 활용 사례**| +|OpenAI Sora|OpenAI|2024년 12월|고품질 이미지, 일관된 움직임|N/A (크레딧 기반)|20 - 200 (월 구독)|예 (ChatGPT 플랜 통해)|아니요|소셜 미디어, 광고/마케팅, 프로토타이핑, 컨셉 시각화, 합성 데이터 생성| +|Google Veo 2|Google|2025년 4월 15일|사실적, 4K 해상도, 상세한 제어, 영화적 언어 이해|8|0.35|예 (Gemini API 통해)|아니요|영화 제작자, 콘텐츠 제작자, 사실적 비디오 제작, 특정 카메라 기술 지시| + +이 표는 AI 기반 비디오 제작의 최전선을 탐색하는 미디어 회사, 마케터 및 콘텐츠 제작자에게 필수적입니다. 주요 비디오 생성 모델의 기능, 제한 사항(예: 최대 길이) 및 비용 구조에 대한 간략한 개요를 제공하여 파일럿 프로젝트 계획 및 기술 채택에 도움이 됩니다. + +상업용 비디오 생성 모델의 현재 상태는 고품질이지만 최대 비디오 길이에 상당한 제한이 있다는 특징을 가집니다. 이는 길고 일관성 있으며 고품질의 비디오 시퀀스를 생성하는 데 필요한 계산 요구 사항이 여전히 상당한 기술적 및 경제적 장벽으로 남아 있음을 시사하며, 제공업체들이 짧은 형식의 콘텐츠 또는 길이에 따른 계층별 가격 책정으로 나아가도록 합니다. Sora의 가격은 ChatGPT 구독 내에서 크레딧 기반이며, 5초 및 10초 비디오에 대한 특정 크레딧 소비가 명시되어 있습니다.24 Veo 2는 명시적으로 최대 비디오 길이가 8초임을 밝힙니다.25 상업적 수준의 비디오 생성을 목표로 하는 연구 프로젝트인 Open-Sora에 대한 연구는 20만 달러의 훈련 비용을 상세히 설명하면서도, 데이터셋의 엄격한 필터링 및 압축(7천만, 1천만, 그리고 5백만 비디오 샘플)과 훈련에 필요한 상당한 GPU 일수를 강조합니다.26 이러한 증거는 비디오 생성, 특히 더 긴 길이에 대해 엄청난 계산 자원이 필요하며, 이는 초당 높은 비용 또는 상업적 제공에서 길이 제한으로 이어진다는 것을 보여줍니다. 이러한 병목 현상은 비디오 AI가 강력하지만, 장편 콘텐츠에 대한 광범위한 적용은 아직 갈 길이 멀다는 것을 의미합니다. + +### 표 4: 멀티모달 AI 모델 주요 기능 + +| | | | | | | | +|---|---|---|---|---|---|---| +|**모델명**|**개발사**|**출시일**|**지원 모달리티**|**컨텍스트 윈도우 (토큰)**|**주요 강점**|**주요 활용 사례**| +|Google Gemini 시리즈|Google|다양함|텍스트, 이미지, 오디오, 비디오|1000000 - 2000000|다목적, 모든 작업에서 뛰어난 성능, 복잡한 추론, 긴 컨텍스트 윈도우, 오디오/비디오 컨텍스트 처리|에이전트, 장문 텍스트 요약, Q&A, 실시간 전사/번역, 팟캐스트/비디오 Q&A, 회의 요약, 음성 비서| +|Anthropic Claude 3 시리즈|Anthropic|2024년 3월 4일|텍스트, 이미지|128000 - 200000 (Opus 1M 확장 예정)|역량과 성능 균형, 속도 최적화, 복잡한 추론, 수학, 프로그래밍, 논리적 추론, 차트 해석, 이미지에서 텍스트 추출|텍스트 생성/재작성, 의역, 어조 변경, 개인 비서, 데이터 분석/관리, 코딩, 다단계 워크플로| +|xAI Grok 3|xAI|2025년 2월 28일|텍스트, 이미지, 비디오, 오디오, 코드|1000000|실시간 데이터 통합, 합성 데이터셋, 고급 강화 학습, 인간 피드백 루프, STEM, 문제 해결, 실시간 연구, 멀티모달 이해|실시간 검색, 이미지 생성, 트렌드 분석, 코딩, 수학, 고급 추론, 비즈니스 자동화| +|OpenAI GPT-4o|OpenAI|2024년 5월|텍스트, 오디오, 비전|128000|범용, 인간과 유사한 텍스트 생성, 콘텐츠 생성, 텍스트 분석, 주요 벤치마크에서 강력한 성능|범용 AI 챗봇, AI 애플리케이션| + +이 표는 여러 데이터 유형을 처리하고 생성하는 능력을 강조하며, 가장 진보된 AI 모델에 대한 전략적 개요를 제공합니다. 이는 보다 전체적이고 지능적인 AI 애플리케이션을 목표로 하는 조직이 인간과 유사한 이해 및 상호 작용이 가능한 모델을 식별하는 데 도움이 되며, 미래 지향적인 AI 전략을 수립하는 데 정보를 제공합니다. + +선도적인 AI 모델에서 멀티모달 기능에 대한 강조가 증가하는 것은 보다 직관적이고 인간과 유사한 상호 작용 및 포괄적인 문제 해결을 향한 근본적인 변화를 의미합니다. 이러한 발전은 AI를 단일 모달리티의 한계를 넘어, 세상을 더 전체적으로 이해하고 반응할 수 있는 시스템으로 나아가게 합니다. 멀티모달 AI의 핵심 정의는 여러 데이터 유형을 처리하는 능력입니다.8 Gemini 28, Claude 3 30, Grok 3 31, GPT-4o 3와 같은 모델에 대한 상세한 설명은 텍스트, 이미지, 오디오, 때로는 비디오에 걸쳐 콘텐츠를 처리하고 생성하는 능력을 지속적으로 강조합니다. 단일 모델 아키텍처 내에서 감각 입력 처리의 이러한 융합은 AI가 실제 세계에 내재된 풍부하고 다양한 정보 스트림을 더 잘 해석할 수 있게 되었음을 시사합니다. 이러한 능력은 AI가 컨텍스트에 대한 더 완전하고 미묘한 이해를 구축하여 더 강력하고 다재다능하며 궁극적으로 더 '지능적인' 애플리케이션으로 이어질 수 있으므로, 인공 일반 지능(AGI) 달성을 향한 중요한 단계입니다. + +## IV. 경제적 고려 사항: AI 모델 비용 이해 + +AI 모델의 경제적 측면을 이해하는 것은 배포 전략을 수립하는 데 필수적입니다. 비용은 API 기반 서비스와 자체 호스팅 솔루션 간에 크게 달라지며, 각 접근 방식은 고유한 재정적 함의를 가집니다. + +### API 기반 가격 모델 + +LLM의 API 가격은 주로 토큰당 모델을 기반으로 하며, 일반적으로 처리되는 1,000개 또는 1,000,000개 토큰당 요금이 부과됩니다.28 이 비용은 종종 입력 토큰(사용자의 프롬프트)과 출력 토큰(모델의 응답)을 구분하며, 출력 토큰은 일반적으로 더 높은 요금을 부과합니다.28 이미지 및 비디오 생성 모델의 경우, 가격은 이미지당 또는 비디오 초당 기준으로 전환됩니다.24 OpenAI 및 Google과 같은 제공업체는 GPT-3.5, GPT-4, GPT-4o, Gemini 1.5 Flash, Gemini 1.5 Pro와 같은 다양한 모델 버전을 제공하며, 각각 고유한 기능과 해당 가격대를 가집니다. 일반적으로 고성능 모델 또는 더 큰 컨텍스트 윈도우를 가진 모델은 더 높은 가격을 요구합니다.10 Midjourney 및 ChatGPT Plus와 같은 일부 서비스는 특정 사용량을 묶거나 특정 조건에서 '무제한' 액세스를 제공하는 구독 계층으로 운영됩니다.24 + +API 기반 가격 책정은 편리함과 낮은 초기 투자 비용을 제공하지만, 특히 컨텍스트 윈도우가 확장됨에 따라 예측 불가능하고 빠르게 증가하는 운영 비용으로 이어질 수 있습니다. 이는 비용을 효과적으로 관리하기 위해 사전 예방적인 비용 모니터링과 컨텍스트 캐싱 또는 정교한 프롬프트 엔지니어링과 같은 최적화 전략의 구현을 필요로 합니다. 컨텍스트 윈도우가 커지면 AI 프롬프트 처리 요구 사항이 토큰 길이에 따라 제곱으로 증가하여 쿼리당 더 높은 비용과 느린 응답 시간으로 이어집니다.10 GPT-4o의 경우 100만 토큰도 빠르게 비용이 증가할 수 있습니다.35 검색 증강 생성(RAG) 및 컨텍스트 캐싱과 같은 기술은 대규모 컨텍스트 윈도우의 비용을 완화하는 방법으로 논의됩니다.14 이러한 관계는 토큰당 비용이 작아 보일 수 있지만, 대규모 입력, 긴 대화 및 높은 사용량의 복합적인 효과가 상당한 지출을 초래할 수 있음을 강조합니다. 따라서 조직은 단순히 API 모델을 채택하고 정적인 비용을 가정할 수 없으며, 재정적 지속 가능성을 위해 토큰 소비 패턴에 대한 지속적인 최적화와 이해가 중요합니다. + +### 자체 호스팅 및 심층 연구 비용 + +AI 모델, 특히 더 크고 유능한 모델을 자체 호스팅하는 것은 상당하고 전문화된 하드웨어를 요구합니다. LLM의 경우 GPU VRAM이 가장 중요한 구성 요소입니다. 예를 들어, Llama 3.3 70B 모델은 최소 53GB의 비디오 메모리가 필요하며, 이는 2x NVIDIA A100 (각 48GB), 1x NVIDIA H100 또는 3x NVIDIA RTX 4090 (각 24GB)과 같은 구성을 필요로 합니다.37 Mixtral 8x7B는 양자화되지 않은 형태로 약 80GB의 VRAM이 필요하지만, 양자화된 버전은 24GB로도 작동할 수 있습니다.38 Stable Diffusion XL과 같은 이미지 생성 모델은 NVIDIA RTX GPU에 최소 10GB VRAM이 필요하며 40, SD 3.5 Medium은 9.9GB가 필요합니다.23 GPU 외에도 적절한 CPU(예: 프로덕션 환경에 8-16개 이상의 코어 권장) 및 충분한 RAM(예: 대부분의 모델에 32-64GB)도 필수적인 시스템 요구 사항입니다.39 + +AWS 또는 Google Cloud와 같은 클라우드 플랫폼에서 대규모 AI 모델을 실행하는 것은 상당한 시간당 또는 월별 비용을 발생시킵니다. 예를 들어, AWS g5.48xlarge 인스턴스(8x A100 GPU 장착)에서 Llama 3.2 90B 모델을 호스팅하는 데는 주당 40시간 운영 시 월 약 2,834.85달러가 소요되며, 24시간 연중무휴 가용성을 위해서는 11,906.24달러로 증가할 수 있습니다.41 Google Cloud는 NVIDIA T4의 경우 GPU당 시간당 0.35달러, V100의 경우 GPU당 시간당 2.48달러로 다양한 GPU 옵션을 제공합니다.42 A100 GPU를 사용하는 CUDO Compute에서 AWS ml.p4de.24xlarge와 유사한 클라우드 구성은 월 12,400달러 이상에 달할 수 있으며, AWS에서 직접 동일한 설정은 월 23,000달러를 초과할 수 있습니다.43 + +AI 모델을 온프레미스에 배포하는 것은 서버, 고성능 GPU, 상당한 스토리지 솔루션을 포함한 하드웨어에 상당한 초기 자본 투자를 필요로 합니다. 예를 들어, Llama 3 8B 모델의 기본 설정은 약 3,800달러의 초기 하드웨어 비용(예: NVIDIA Tesla T4 4개 각 700달러, 나머지 장비 1,000달러)이 들 수 있습니다.44 초기 구매 외에도 운영 비용에는 전기 소비, 냉각 인프라, 물리적 공간, IT 유지보수 인력의 급여가 포함됩니다.44 자체 호스팅은 높은 활용 시나리오에서 장기적으로 더 비용 효율적일 수 있지만, 상당한 내부 기술 전문 지식과 지속적인 관리를 요구합니다.22 + +API 기반 서비스와 자체 호스팅 AI 모델 간의 결정은 단순한 재정적 또는 기술적 결정이 아니라 전략적인 비즈니스 필수 사항이며, 특히 민감한 데이터를 처리하거나 심층적인 맞춤화가 필요한 조직의 경우 더욱 그렇습니다. 인식되는 '비용'은 금전적 지출뿐만 아니라 데이터 프라이버시, 보안, 그리고 특정(종종 독점적인) 비즈니스 요구 사항에 AI 솔루션을 맞춤화할 수 있는 능력의 가치도 포함해야 합니다. 데이터 프라이버시와 보안은 의료 및 금융과 같은 규제 산업에서 자체 호스팅의 주요 동인으로 명시적으로 언급됩니다.41 AI 에이전트의 온프레미스 대 클라우드 배포 비용에 대한 비교는 온프레미스 배포가 더 비싸지만(5만~6만 달러) '데이터 보안 및 규정 준수에 대한 완전한 통제'를 제공한다는 점을 강조합니다.46 이는 많은 기업에게 자체 호스팅의 높은 직접 비용이 데이터 주권, 위험 감소, 그리고 독점 데이터셋에 대한 모델 미세 조정 능력(API 서비스가 완전히 수용하지 못할 수 있는 상당한 경쟁 우위를 제공할 수 있음)의 간접적인 이점으로 정당화된다는 것을 시사합니다.47 + +### 모델 훈련 비용 + +대규모 AI 모델을 훈련하는 것은 엄청나게 자원 집약적이고 재정적으로 부담이 큰 작업입니다. OpenAI의 GPT-3 훈련 비용은 2020년에 50만 달러에서 460만 달러 사이로 추정되었지만, GPT-4의 훈련 비용은 1억 달러를 초과하는 것으로 보고되었으며, Google의 Gemini Ultra 모델은 1억 9,100만 달러가 소요된 것으로 추정됩니다.16 이러한 막대한 투자는 Nvidia A100 또는 H100과 같은 수만 개의 고성능 GPU를 포함한 엄청난 계산 능력을 배치하는 것을 포함합니다.16 이러한 훈련은 막대한 양의 에너지를 소비합니다. 예를 들어, GPT-4의 훈련은 한 달 동안 18만 가구의 미국 가정에서 사용하는 전력량과 맞먹는 것으로 추정되었습니다.16 이 과정은 또한 몇 달 동안의 전용 데이터 처리 및 지속적인 훈련 시간을 필요로 합니다.16 Mistral 7B와 같은 '작은' 오픈소스 모델조차도 200만 달러에서 500만 달러에 이르는 훈련 비용이 발생할 수 있습니다.16 + +최첨단 AI 모델 훈련과 관련된 엄청난 비용은 새로운 경쟁자들에게 상당한 진입 장벽을 만들고, 이로 인해 기존 기술 거대 기업의 시장 지배력을 강화합니다. 이러한 경제적 현실은 동시에 Mixture-of-Experts (MoE)와 같은 보다 효율적인 모델 아키텍처 및 Groq의 LPU, Google의 TPU와 같은 특수 하드웨어 개발을 포함한 비용 최적화 기술의 지속적인 혁신을 위한 강력한 촉매제 역할을 합니다. 훈련 비용이 수백만 달러에 달하고 "수만 개의 GPU"와 같은 엄청난 GPU 인프라가 필요하다는 증거는 소수의 대기업만이 이러한 기반 AI 모델을 개발할 재정적 및 계산적 역량을 가지고 있음을 직접적으로 설명합니다.16 그러나 동일한 정보는 이러한 비용에 대한 전략적 대응도 지적합니다. 즉, 쿼리당 매개변수의 일부만 활성화하여 훈련 및 추론 비용을 모두 줄이는 MoE 아키텍처(Mixtral과 같은)의 채택입니다.49 또한, Groq의 LPU 17 및 Google의 TPU 16와 같은 특수 AI 칩의 등장은 추론 효율성을 최적화하는 데 중점을 둔 병렬 혁신 경로를 보여줍니다. 이러한 역동성은 최첨단 AI의 초기 창조는 여전히 독점적인 영역이지만, 아키텍처 및 하드웨어 혁신을 통해 접근성을 민주화하고 운영 비용을 줄이려는 지속적인 노력이 AI 산업의 중요한 전장이 되고 있음을 시사합니다. + +## V. 성능 지표: 속도, 지연 시간 및 처리량 + +AI 모델의 성능은 다양한 지표를 통해 평가되며, 이는 실제 애플리케이션에서의 효율성과 유용성을 결정합니다. + +### 컨텍스트 윈도우의 중요성 + +컨텍스트 윈도우는 대규모 언어 모델(LLM)이 단일 상호 작용에서 처리하고 '기억'할 수 있는 정보의 최대량(토큰 단위)을 정의하며, 이는 인간의 단기 기억과 유사합니다.10 더 큰 컨텍스트 윈도우는 긴 대화에서 대화의 일관성을 유지하고, 방대한 문서(예: 방대한 연구 논문 요약 또는 대규모 코드베이스 디버깅) 내의 복잡한 관계를 모델이 이해할 수 있도록 하며, 모델에 더 많은 관련 근거 정보를 제공하여 '환각' 발생률을 크게 줄이는 데 중요합니다.10 Google의 Gemini 1.5 Pro와 같은 선도적인 모델은 인상적인 200만 토큰 컨텍스트 윈도우를 자랑하며, 이론적으로 3,000페이지 분량의 텍스트 또는 19시간 분량의 오디오를 단일 프롬프트에서 처리할 수 있습니다.10 그러나 이러한 증가된 용량은 상충 관계를 수반합니다. 더 큰 컨텍스트 윈도우는 계산 집약적이며, 응답 시간을 늦추고, 토큰 기반 가격 모델로 인해 일반적으로 더 높은 비용을 발생시킵니다.10 + +더 큰 컨텍스트 윈도우는 AI 모델이 일관성을 유지하고 오류를 줄이는 능력을 근본적으로 향상시키지만, 추론 속도 및 운영 비용과 직접적이고 종종 어려운 상충 관계를 가져옵니다. 이러한 '삼중고'는 실제 애플리케이션에서 과도한 비용 없이 성능을 최적화하기 위해 검색 증강 생성(RAG) 또는 지능형 캐싱 메커니즘과 같은 전략적 접근 방식을 필요로 합니다. 컨텍스트 윈도우 크기가 증가하면 처리 요구 사항이 토큰 길이에 따라 제곱으로 증가하여 '느린 응답 시간'과 '더 높은 비용'으로 이어진다고 명시적으로 언급됩니다.10 검색 증강 생성(RAG)은 '가장 관련성 높은 정보만 검색하여 더 빠르고 비용 효율적'이므로 '대규모 컨텍스트 윈도우'에 대한 대안으로 직접 비교됩니다.14 Gemini 모델의 긴 컨텍스트에서 '컨텍스트 캐싱'은 비용을 '상당히 줄이는' 주요 최적화 방법으로 언급됩니다.29 이러한 관계는 단순히 컨텍스트 윈도우를 늘리는 것이 보편적으로 최적의 해결책이 아님을 보여줍니다. 대신, 실제 배포에서는 성능, 정확성, 비용이라는 상충되는 요구 사항의 균형을 맞추기 위해 종종 대규모 기본 컨텍스트 윈도우를 외부 검색 시스템 및 캐싱과 결합하여 컨텍스트를 관리하는 미묘한 이해가 필요합니다. + +### 추론 속도 및 첫 토큰 응답 시간 (TTFT) + +**추론 속도**는 AI 모델이 입력 쿼리를 처리하고 완전한 응답을 생성하는 속도를 정량화합니다.15 이 지표는 대화형 챗봇, 가상 비서, 자율 시스템과 같은 실시간 애플리케이션에 매우 중요하며, 응답성이 사용자 참여 및 운영 효율성에 직접적인 영향을 미칩니다.15 **첫 토큰 응답 시간(TTFT)**은 요청이 전송된 시점부터 모델 응답의 첫 부분이 나타나기 시작하는 시점까지의 지연을 측정하는 보다 구체적이고 사용자 중심적인 지표입니다.15 낮은 TTFT는 대화형 AI에서 인지된 응답성과 사용자 만족도에 결정적입니다.15 추론 속도와 TTFT에 영향을 미치는 요인으로는 모델의 크기(일반적으로 더 큰 모델은 더 많은 계산을 필요로 하지만 더 정확할 수 있음), 배포에 사용되는 기본 하드웨어(고성능 GPU, TPU 또는 Groq의 LPU와 같은 특수 하드웨어 가속기), 그리고 다양한 최적화 기술(예: 양자화, 가지치기, 캐싱)이 있습니다.15 + +LLM 속도는 상당한 차이를 보입니다. Groq의 LPU 기반 Llama 3.1 8B는 744 토큰/초의 뛰어난 성능과 0.29초의 TTFT를 보여주며, Llama 3 8B는 1211 토큰/초와 0.36초의 TTFT를 달성합니다.17 이에 비해 OpenAI의 GPT-4o는 131 토큰/초와 0.50초의 TTFT를 제공하며, Anthropic의 Claude 3.5 Sonnet은 80 토큰/초와 0.84초의 TTFT를 제공합니다.17 DeepSeek V3는 250 토큰/초의 출력 속도를 보입니다.52 이미지 생성 속도 또한 다양합니다. FLUX-juiced는 2.5초 만에 이미지를 생성할 수 있으며 21, Leonardo AI의 Fast Mode는 이미지당 10~20초가 소요되고 53, Midjourney는 일반적으로 "약 1분" 안에 4개의 이미지를 생성합니다.54 + +Groq의 언어 처리 장치(LPU) 및 Cerebras의 웨이퍼 스케일 엔진과 같은 특수 AI 추론 하드웨어의 등장은 추론 속도와 첫 토큰 응답 시간(TTFT)에서 새로운 경쟁의 장을 열고 있습니다. 이는 오픈소스 모델조차도 기존 GPU 인프라에서 실행되는 더 큰 독점 모델을 능가하는 응답성 수준을 달성할 수 있도록 하여, 실시간 AI 애플리케이션의 성능 환경을 근본적으로 변화시킵니다. Groq의 LPU는 "GPT-4 및 Mixr와 같은 주요 경쟁사의 기능을 크게 능가하여 거의 500 토큰/초"를 가능하게 한다고 명시적으로 언급됩니다.50 Groq의 Llama 및 Mixtral 모델이 OpenAI 및 Anthropic의 제품에 비해 훨씬 높은 토큰/초와 낮은 TTFT를 달성한다는 구체적인 데이터를 제공합니다.17 또한, Cerebras에서 실행되는 Llama 3.1 405B는 "GPT-4o보다 12배, Claude 3.5 Sonnet보다 18배 빠르다"고 강조됩니다.18 이러한 강력한 관계는 원시 모델 크기나 아키텍처 복잡성이 실제 속도의 유일한 결정 요인이 아님을 보여줍니다. 대신, AI 추론을 위해 특별히 설계된 특수 하드웨어는 지연 시간을 극적으로 줄이고 처리량을 증가시켜, 그렇지 않으면 '느리다'고 간주될 수 있는 모델을 지연 시간에 민감한 애플리케이션에 매우 경쟁력 있게 만들고 잠재적으로 고속 AI 접근성을 민주화할 수 있습니다. + +### 지연 시간 대 처리량 + +**지연 시간**은 단일 요청이 완전히 처리되고 응답이 수신되는 데 걸리는 총 시간을 의미합니다.51 반대로 **처리량**은 AI 시스템이 모든 동시 작업에서 단위 시간당 처리할 수 있는 총 요청 또는 토큰 볼륨을 측정합니다.51 낮은 지연 시간은 실시간 대화형 애플리케이션(예: 대화형 AI, 자율 주행 차량)에 가장 중요하며, 즉각적인 응답이 사용자 만족도, 안전 또는 시스템 응답성에 결정적인 역할을 합니다.55 반면, 높은 처리량은 배치 처리 작업 또는 많은 수의 동시 사용자를 서비스하는 애플리케이션에 중요하며, 개별 응답 시간보다 완료된 작업의 전체 볼륨이 우선시됩니다.51 이러한 지표 중 하나를 최적화하는 것은 종종 다른 지표에 부정적인 영향을 미치는 상충 관계를 수반합니다. 예를 들어, 여러 요청을 일괄 처리하면 전체 처리량을 크게 향상시킬 수 있지만, 단일 요청에 대한 지연 시간을 증가시키는 지연을 초래할 수 있습니다.51 + +효과적인 AI 시스템 설계는 '최적의 성능'이 보편적인 지표가 아니라 특정 애플리케이션의 실제 요구 사항에 따라 크게 달라진다는 미묘한 이해를 필요로 합니다. 이는 대화형 경험을 위한 지연 시간 최소화와 대량의 비동기 워크로드에 대한 처리량 최대화 사이의 전략적 균형을 필요로 합니다. 낮은 동시 요청 부하에서는 지연 시간이 가능한 한 낮지만, 요청 부하를 늘리면 지연 시간이 증가할 수 있지만 처리량도 증가할 가능성이 높다고 명시적으로 설명됩니다.51 각 요청을 개별적으로 처리하면 지연 시간이 줄어들지만 시스템 리소스가 충분히 활용되지 않아 처리량이 감소할 수 있으며, 여러 요청을 일괄 처리하면 처리량이 향상되지만 지연 시간이 증가할 수 있다고 강조됩니다.55 이는 단일한 '가장 빠른' 또는 '가장 효율적인' 구성이 없음을 강조합니다. 챗봇(낮은 지연 시간 사용 사례)은 전체 토큰/초가 낮더라도 최소한의 TTFT를 필요로 합니다. 반대로, 오프라인 배치 처리 시스템은 개별 응답 시간보다 전체 처리량을 우선시할 수 있습니다. + +## VI. 결론 + +AI 모델 환경은 끊임없이 진화하고 있으며, 독점 모델과 오픈소스 모델 모두에서 혁신이 이루어지고 있습니다. 독점 모델은 최첨단 성능과 관리형 서비스의 편리함을 제공하지만, 오픈소스 모델은 향상된 통제권, 데이터 프라이버시, 잠재적으로 더 낮은 장기 운영 비용을 제공하여 자체 호스팅에 투자할 의향이 있는 조직에 매력적인 대안이 됩니다. + +AI 모델의 성능은 컨텍스트 윈도우 크기, 추론 속도(첫 토큰 응답 시간 포함), 처리량과 같은 핵심 지표에 따라 크게 달라집니다. 더 큰 컨텍스트 윈도우는 모델의 일관성과 오류 감소 능력을 향상시키지만, 계산 집약적이며 비용과 속도 간의 상충 관계를 가져옵니다. Groq의 LPU와 Cerebras의 웨이퍼 스케일 엔진과 같은 특수 하드웨어의 발전은 추론 속도를 크게 향상시켜 오픈소스 모델도 독점 모델과 경쟁할 수 있도록 합니다. + +궁극적으로 AI 모델 선택은 조직의 특정 요구 사항, 예산 제약, 데이터 거버넌스 요구 사항에 따라 달라집니다. 실시간 대화형 애플리케이션에는 낮은 지연 시간이 중요하고, 대량 배치 처리에는 높은 처리량이 중요합니다. 비용과 성능 간의 이러한 미묘한 균형을 이해하는 것이 AI 기술을 효과적으로 활용하고 전략적 목표를 달성하는 데 필수적입니다. + + +사용된 소스스 + +![](https://t3.gstatic.com/faviconV2?url=https://aimatters.co.kr/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +aimatters.co.kr + +2025년에 알아야 할 8가지 AI 유형 총정리, 생성형 AI부터 전문가 시스템까지 - AI 매터스 + +새 창에서 열기](https://aimatters.co.kr/news-report/ai-report/19643/)[ + +![](https://t0.gstatic.com/faviconV2?url=https://www.redhat.com/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +redhat.com + +대규모 언어 모델(LLM): 정의, 특징, 활용 방법 - Red Hat + +새 창에서 열기](https://www.redhat.com/ko/topics/ai/what-are-large-language-models)[ + +![](https://t2.gstatic.com/faviconV2?url=https://blog.naver.com/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +blog.naver.com + +FLUX, Stable Diffusion, DALL-E 3: AI 이미지 생성 모델 비교 : 네이버 블로그 + +새 창에서 열기](https://blog.naver.com/pibbleio/223585167638?viewType=pc)[ + +![](https://t1.gstatic.com/faviconV2?url=https://honeybottle.co.kr/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +honeybottle.co.kr + +AI 이미지 생성 Top 3 비교 총 정리 - ChatGPT, Midjourney, Leonardo AI - HoneyBottle + +새 창에서 열기](https://honeybottle.co.kr/ai-%EC%9D%B4%EB%AF%B8%EC%A7%80-%EC%83%9D%EC%84%B1-top-3-chatgpt-midjourney-leonardo-ai/)[ + +![](https://t2.gstatic.com/faviconV2?url=https://blog.naver.com/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +blog.naver.com + +LLM 개요 - 대규모 언어 모델 개요와 모델 종류 : 네이버 블로그 + +새 창에서 열기](https://blog.naver.com/agapeuni/223590181431?viewType=pc)[ + +![](https://t2.gstatic.com/faviconV2?url=https://pieces.app/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +pieces.app + +10 Best AI models you should definitely know about (and why they matter) + +새 창에서 열기](https://pieces.app/blog/best-ai-models)[ + +![](https://t0.gstatic.com/faviconV2?url=https://www.ionio.ai/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +ionio.ai + +Fastest Token First: Benchmarking OpenLLMs by inference speed + +새 창에서 열기](https://www.ionio.ai/blog/fastest-token-first-benchmarking-openllms-by-inference-speed)[ + +![](https://t2.gstatic.com/faviconV2?url=https://www.helicone.ai/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +helicone.ai + +LLM API Pricing Calculator | Compare 300+ AI Model Costs - Helicone + +새 창에서 열기](https://www.helicone.ai/llm-cost)[ + +![](https://t0.gstatic.com/faviconV2?url=https://ai.google.dev/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +ai.google.dev + +Gemini Developer API Pricing | Gemini API | Google AI for Developers + +새 창에서 열기](https://ai.google.dev/gemini-api/docs/pricing)[ + +![](https://t1.gstatic.com/faviconV2?url=https://www.thecloudgirl.dev/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +thecloudgirl.dev + +RAG vs Large Context Window LLMs: When to use which one? - The Cloud Girl + +새 창에서 열기](https://www.thecloudgirl.dev/blog/rag-vs-large-context-window)[ + +![](https://t0.gstatic.com/faviconV2?url=https://magicode.tistory.com/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +magicode.tistory.com + +멀티모달(Multi Modal AI) 총정리 + 예제 실습 코드 - magicode - 티스토리 + +새 창에서 열기](https://magicode.tistory.com/77)[ + +![](https://t0.gstatic.com/faviconV2?url=https://www.mckinsey.com/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +mckinsey.com + +What is a context window for Large Language Models? - McKinsey + +새 창에서 열기](https://www.mckinsey.com/featured-insights/mckinsey-explainers/what-is-a-context-window)[ + +![](https://t2.gstatic.com/faviconV2?url=https://blog.naver.com/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +blog.naver.com + +멀티모달 AI는 '이미지 생성 외에' 뭘 더 할 수 있을까? : 네이버 블로그 + +새 창에서 열기](https://blog.naver.com/saltluxmarketing/222878567653)[ + +![](https://t3.gstatic.com/faviconV2?url=https://zapier.com/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +zapier.com + +What is a context window—and why does it matter? - Zapier + +새 창에서 열기](https://zapier.com/blog/context-window/)[ + +![](https://t1.gstatic.com/faviconV2?url=https://www.datacamp.com/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +datacamp.com + +Midjourney V7: A Guide With 8 Practical Examples - DataCamp + +새 창에서 열기](https://www.datacamp.com/tutorial/midjourney-v7)[ + +![](https://t0.gstatic.com/faviconV2?url=https://docs.databricks.com/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +docs.databricks.com + +Conduct your own LLM endpoint benchmarking - Databricks Documentation + +새 창에서 열기](https://docs.databricks.com/aws/en/machine-learning/foundation-model-apis/prov-throughput-run-benchmark)[ + +![](https://t0.gstatic.com/faviconV2?url=https://cubed.run/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +cubed.run + +Groq Inference Engine 18x Faster Than GPT - Cubed + +새 창에서 열기](https://cubed.run/blog/groq-inference-engine-18x-faster-than-gpus)[ + +![](https://t0.gstatic.com/faviconV2?url=https://enthu.com/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +enthu.com + +How does Grok 3's training data set differ from its predecessors? + +새 창에서 열기](https://enthu.com/blog/ai/grok-3s-data-set-difference)[ + +![](https://t0.gstatic.com/faviconV2?url=https://sambanova.ai/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +sambanova.ai + +sambanova.ai + +새 창에서 열기](https://sambanova.ai/blog/deepseek-v3-0324-fastest-inference-in-world#:~:text=We're%20excited%20to%20offer,by%20our%20custom%20RDU%20architecture.)[ + +![](https://t0.gstatic.com/faviconV2?url=https://www.nextplatform.com/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +nextplatform.com + +How Did DeepSeek Train Its AI Model On A Lot Less – And Crippled – Hardware? + +새 창에서 열기](https://www.nextplatform.com/2025/01/27/how-did-deepseek-train-its-ai-model-on-a-lot-less-and-crippled-hardware/)[ + +![](https://t0.gstatic.com/faviconV2?url=https://docs.midjourney.com/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +docs.midjourney.com + +Comparing Midjourney Plans + +새 창에서 열기](https://docs.midjourney.com/hc/en-us/articles/27870484040333-Comparing-Midjourney-Plans)[ + +![](https://t0.gstatic.com/faviconV2?url=https://dev.to/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +dev.to + +Mistral 7B vs. Mixtral 8x7B - DEV Community + +새 창에서 열기](https://dev.to/firstfinger-io/mistral-7b-vs-mixtral-8x7b-4k2l)[ + +![](https://t3.gstatic.com/faviconV2?url=https://www.cerebras.ai/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +cerebras.ai + +Llama 3.1 405B now runs at 969 tokens/s on Cerebras Inference + +새 창에서 열기](https://www.cerebras.ai/blog/llama-405b-inference)[ + +![](https://t2.gstatic.com/faviconV2?url=https://en.wikipedia.org/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +en.wikipedia.org + +Llama (language model) - Wikipedia + +새 창에서 열기](https://en.wikipedia.org/wiki/Llama_\(language_model\))[ + +![](https://t2.gstatic.com/faviconV2?url=https://en.wikipedia.org/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +en.wikipedia.org + +Claude (language model) - Wikipedia + +새 창에서 열기](https://en.wikipedia.org/wiki/Claude_\(language_model\))[ + +![](https://t0.gstatic.com/faviconV2?url=https://cloud.google.com/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +cloud.google.com + +Long context | Generative AI on Vertex AI - Google Cloud + +새 창에서 열기](https://cloud.google.com/vertex-ai/generative-ai/docs/long-context)[ + +![](https://t2.gstatic.com/faviconV2?url=https://invertedstone.com/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +invertedstone.com + +DALL-E API Pricing Calculator | Calculate Image Generation Costs - InvertedStone + +새 창에서 열기](https://invertedstone.com/calculators/dall-e-pricing)[ + +![](https://t0.gstatic.com/faviconV2?url=https://galileo.ai/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +galileo.ai + +Understanding Latency in AI: What It Is and How It Works + +새 창에서 열기](https://galileo.ai/blog/understanding-latency-in-ai-what-it-is-and-how-it-works)[ + +![](https://t3.gstatic.com/faviconV2?url=https://klu.ai/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +klu.ai + +2024 LLM Leaderboard: compare Anthropic, Google, OpenAI, and ... + +새 창에서 열기](https://klu.ai/llm-leaderboard)[ + +![](https://t3.gstatic.com/faviconV2?url=https://blog.adyog.com/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +blog.adyog.com + +The Economics of AI Training and Inference: How DeepSeek Broke the Cost Curve - Adyog + +새 창에서 열기](https://blog.adyog.com/2025/02/09/the-economics-of-ai-training-and-inference-how-deepseek-broke-the-cost-curve/)[ + +![](https://t1.gstatic.com/faviconV2?url=https://www.biz4group.com/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +biz4group.com + +AI Agent Development Cost in 2025: Factors and Examples - Biz4Group + +새 창에서 열기](https://www.biz4group.com/blog/ai-agent-development-cost)[ + +![](https://t3.gstatic.com/faviconV2?url=https://www.cudocompute.com/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +cudocompute.com + +What is the cost of training large language models? - CUDO Compute + +새 창에서 열기](https://www.cudocompute.com/blog/what-is-the-cost-of-training-large-language-models)[ + +![](https://t0.gstatic.com/faviconV2?url=https://www.mimicpc.com/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +mimicpc.com + +An In-Depth Comparison of All Flux Models Available - MimicPC + +새 창에서 열기](https://www.mimicpc.com/learn/an-in-depth-comparison-of-all-flux-models)[ + +![](https://t1.gstatic.com/faviconV2?url=https://techpoint.africa/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +techpoint.africa + +Leonardo AI vs Midjourney: which is the best AI art generator in 2025? - Techpoint Africa + +새 창에서 열기](https://techpoint.africa/guide/leonardo-midjourney-ai-art-2025/)[ + +![](https://t1.gstatic.com/faviconV2?url=https://www.datacamp.com/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +datacamp.com + +Flux AI Image Generator: A Guide With Examples - DataCamp + +새 창에서 열기](https://www.datacamp.com/tutorial/flux-ai)[ + +![](https://t2.gstatic.com/faviconV2?url=https://www.reddit.com/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +reddit.com + +Cost of Self-Hosting? : r/selfhosted - Reddit + +새 창에서 열기](https://www.reddit.com/r/selfhosted/comments/1kjuapi/cost_of_selfhosting/)[ + +![](https://t1.gstatic.com/faviconV2?url=https://news.ycombinator.com/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +news.ycombinator.com + +Cost of self hosting Llama-3 8B-Instruct - Hacker News + +새 창에서 열기](https://news.ycombinator.com/item?id=40681784)[ + +![](https://t2.gstatic.com/faviconV2?url=https://docs.gitlab.com/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +docs.gitlab.com + +Supported GitLab Duo Self-Hosted models and hardware requirements + +새 창에서 열기](https://docs.gitlab.com/administration/gitlab_duo_self_hosted/supported_models_and_hardware_requirements/)[ + +![](https://t1.gstatic.com/faviconV2?url=https://futureskillsacademy.com/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +futureskillsacademy.com + +Grok 2 vs. Grok 3 - What's new in Elon Musk's Latest Release - Future Skills Academy + +새 창에서 열기](https://futureskillsacademy.com/blog/grok-2-vs-grok-3/)[ + +![](https://t1.gstatic.com/faviconV2?url=https://www.captions.ai/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +captions.ai + +What's Google Veo 2? Main Features and How To Use It - Captions + +새 창에서 열기](https://www.captions.ai/blog-post/google-veo-2)[ + +![](https://t1.gstatic.com/faviconV2?url=https://developers.googleblog.com/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +developers.googleblog.com + +Bring your ideas to life: Veo 2 video generation available for developers + +새 창에서 열기](https://developers.googleblog.com/en/veo-2-video-generation-now-generally-available/)[ + +![](https://t1.gstatic.com/faviconV2?url=https://www.datacamp.com/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +datacamp.com + +What Is OpenAI's Sora? How It Works, Examples, Features - DataCamp + +새 창에서 열기](https://www.datacamp.com/blog/openai-announces-sora-text-to-video-generative-ai-is-about-to-go-mainstream)[ + +![](https://t0.gstatic.com/faviconV2?url=https://stewartgauld.com/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +stewartgauld.com + +How Much Does Sora Cost? Sora Pricing Plans For 2025 - Stewart Gauld + +새 창에서 열기](https://stewartgauld.com/how-much-does-sora-cost-sora-pricing-plans/)[ + +![](https://t0.gstatic.com/faviconV2?url=https://www.louisbouchard.ai/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +louisbouchard.ai + +Open-Sora 2.0 Explained: Architecture, Training, and Why It Matters - Louis Bouchard + +새 창에서 열기](https://www.louisbouchard.ai/open-sora-2/)[ + +![](https://t2.gstatic.com/faviconV2?url=https://www.nexastack.ai/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +nexastack.ai + +Stable Diffusion Services: Control and Cost - NexaStack + +새 창에서 열기](https://www.nexastack.ai/blog/stable-diffusion-private-cloud)[ + +![](https://t2.gstatic.com/faviconV2?url=https://stability.ai/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +stability.ai + +Introducing Stable Diffusion 3.5 - Stability AI + +새 창에서 열기](https://stability.ai/news/introducing-stable-diffusion-3-5)[ + +![](https://t3.gstatic.com/faviconV2?url=https://hostkey.com/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +hostkey.com + +Llama-3.3-70B - Documentation & FAQ - HOSTKEY + +새 창에서 열기](https://hostkey.com/documentation/marketplace/llms/llama_33_70b/)[ + +![](https://t3.gstatic.com/faviconV2?url=https://www.liip.ch/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +liip.ch + +Exploring the AI Chatbot Capabilities of the OS LLM Mixtral 8x7b on a 24GB GPU - Liip + +새 창에서 열기](https://www.liip.ch/en/blog/exploring-the-ai-chatbot-capabilities-of-the-oss-llm-mixtral-8x7b-on-a-24gb-gpu)[ + +![](https://t2.gstatic.com/faviconV2?url=https://huggingface.co/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +huggingface.co + +Announcing FLUX-Juiced: The Fastest Image Generation Endpoint (2.6 times faster)! + +새 창에서 열기](https://huggingface.co/blog/PrunaAI/flux-fastest-image-generation-endpoint)[ + +![](https://t1.gstatic.com/faviconV2?url=https://benchmarks.ul.com/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +benchmarks.ul.com + +Procyon AI Image Generation - Benchmarks - UL Solutions + +새 창에서 열기](https://benchmarks.ul.com/procyon/ai-image-generation-benchmark)[ + +![](https://t1.gstatic.com/faviconV2?url=https://docs.leonardo.ai/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +docs.leonardo.ai + +Train Custom Elements and Generate Images - Dataset - Leonardo AI + +새 창에서 열기](https://docs.leonardo.ai/docs/train-custom-element-and-generate-images)[ + +![](https://t3.gstatic.com/faviconV2?url=https://intercom.help/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +intercom.help + +How to Train Your Own Model | Leonardo.Ai Help Center - Intercom + +새 창에서 열기](https://intercom.help/leonardo-ai/en/articles/8568573-how-to-train-your-own-model)[ + +![](https://t1.gstatic.com/faviconV2?url=https://arxiv.org/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +arxiv.org + +Open-Sora 2.0: Training a Commercial-Level Video Generation Model in $200k - arXiv + +새 창에서 열기](https://arxiv.org/html/2503.09642v1)[ + +![](https://t0.gstatic.com/faviconV2?url=https://cloud.google.com/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +cloud.google.com + +GPU pricing | Google Cloud + +새 창에서 열기](https://cloud.google.com/compute/gpus-pricing)[ + +![](https://t0.gstatic.com/faviconV2?url=https://dev.to/&client=BARD&type=FAVICON&size=256&fallback_opts=TYPE,SIZE,URL) + +dev.to + +The cost of self-hosted LLM model in AWS - DEV Community + +새 창에서 열기](https://dev.to/yyarmoshyk/the-cost-of-self-hosted-llm-model-in-aws-4ijk) + +읽었지만 보고서에서 사용되지 않은 소스 + +[](https://www.unite.ai/ko/%EC%B5%9C%EA%B3%A0%EC%9D%98-%EC%98%A4%ED%94%88-%EC%86%8C%EC%8A%A4-LLM/) + diff --git a/docs/skills-stats/pptx_파일_구조분석_및_HTML_변환_가능성.md b/docs/skills-stats/pptx_파일_구조분석_및_HTML_변환_가능성.md new file mode 100755 index 0000000..4a5f652 --- /dev/null +++ b/docs/skills-stats/pptx_파일_구조분석_및_HTML_변환_가능성.md @@ -0,0 +1,150 @@ +# 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 new file mode 100755 index 0000000..624c7d3 --- /dev/null +++ b/docs/skills-stats/에이전트 스탯 스킬 클래스 구조.md @@ -0,0 +1,159 @@ +--- +tags: 에이전트스킬, 스탯시스템, 능력체계, 디지털에이전트, 협업기술, 자동화기능, 지능형시스템 +--- + +요약 +- 슬랙 기반 디지털 에이전트의 **스탯**, **스킬**, **클래스 구조**, 그리고 **능력 제한의 실용적·철학적 근거**를 종합하여 정리한 자료입니다. +- 디지털 에이전트의 핵심 능력을 연산, 기억, 반응, 공감, 통솔 등 5가지 스탯으로 정의하고, 이를 기반으로 30가지 실용적 스킬을 체계화하였다. +- 각 스킬은 문서 작성, 회의 관리, 정보 분석, 대화 처리 등 실제 업무 환경에서 필요한 기능들을 포괄하며, 스탯 간 조합을 통해 복합적인 태스크 수행이 가능하다. +- 이러한 스킬 체계는 단순한 자동화를 넘어 지능형 협업 시스템으로서의 에이전트 역할을 강화하며, 사용자와의 자연스러운 상호작용을 지원한다. + + +--- +# 에이전트 스킬 설계 문서 + +본 문서는 슬랙 기반 디지털 에이전트의 **스탯**, **스킬**, **클래스 구조**, 그리고 **능력 제한의 실용적·철학적 근거**를 종합하여 정리한 자료입니다. 모든 서술은 존댓말로 작성되었습니다. + +--- + +## 1. 스탯 정의 + +| 스탯명 | 간단 설명 | 상세 기능 | +|--------|-----------|-----------| +| **연산** | “어려운 걸 빨리 잘 처리합니다.” | 복잡한 추론, 분석, 다중 데이터 연산을 빠르게 수행합니다. | +| **기억** | “예전에 한 말도 잘 기억합니다.” | 과거 대화, 문서, 사용자의 선호를 정확히 저장하고 조회합니다. | +| **반응** | “말 걸면 바로 답합니다.” | 실시간 요청에 신속하게 응답하고, 대화 흐름을 유지합니다. | +| **공감** | “기분이나 말투 변화를 잘 알아차립니다.” | 사용자의 정서, 뉘앙스를 파악하고 적합한 톤으로 대응합니다. | +| **통솔** | “여러 에이전트를 잘 이끕니다.” | 다른 모듈·사용자·시스템을 연결하여 복합 태스크를 조율합니다. | + +--- + +## 2. 스킬 목록 30종 + +| 번호 | 스킬명 | 주요 연관 스탯 | 기능 요약 | +|------|--------|----------------|-----------| +| 01 | 요약 | 연산, 기억 | 이메일·문서·회의록을 핵심만 정리합니다. | +| 02 | 작성 | 연산 | 목적에 맞는 이메일·보고서 초안을 생성합니다. | +| 03 | 정리 | 기억, 통솔 | 흩어진 정보를 주제별로 구조화합니다. | +| 04 | 비교 | 연산 | 두 자료의 차이점·공통점을 분석합니다. | +| 05 | 추출 | 연산 | 긴 문서에서 키워드와 핵심정보를 선별합니다. | +| 06 | 해석 | 공감 | 문맥 및 감정을 분석하여 의도를 파악합니다. | +| 07 | 반응 | 반응 | 실시간 대화 및 요청에 즉시 응답합니다. | +| 08 | 경로설정 | 통솔 | 작업 순서를 최적화하여 계획을 수립합니다. | +| 09 | 맥락확장 | 기억 | 과거 정보를 참조하여 정확도를 높입니다. | +| 10 | 감정분석 | 공감 | 사용자의 감정 상태를 추정하고 조정합니다. | +| 11 | 일정정리 | 통솔, 기억 | 회의·마감일 등 스케줄을 관리합니다. | +| 12 | 대화정제 | 공감, 연산 | 거친 표현을 정중하게 다듬습니다. | +| 13 | 한줄요약 | 연산 | 문서를 한 문장으로 압축합니다. | +| 14 | 대시보드화 | 연산, 통솔 | 정보를 시각적 요약 형태로 배열합니다. | +| 15 | 의도파악 | 공감 | 발화를 목적별로 분류합니다. | +| 16 | 인용추적 | 기억 | 과거 발언·문서의 출처를 연결합니다. | +| 17 | 공지작성 | 연산, 통솔 | 팀 전체 공지문을 자동 생성합니다. | +| 18 | 회의준비 | 기억, 연산 | 회의 자료를 수집·정리합니다. | +| 19 | 회의요약 | 연산, 기억 | 회의 종료 후 내용 요약을 제공합니다. | +| 20 | 팀요청분배 | 통솔 | 여러 요청을 적절히 분배·정렬합니다. | +| 21 | 버전정리 | 기억 | 문서·코드 버전 변화를 기록·비교합니다. | +| 22 | 긴급탐지 | 공감, 반응 | 긴급한 요청을 빠르게 식별합니다. | +| 23 | 스레드연결 | 기억 | 과거 대화와 현재 이슈를 연결합니다. | +| 24 | 추천작성 | 연산 | 자료 기반 홍보·추천 문구를 생성합니다. | +| 25 | 검색보강 | 연산, 기억 | 검색 결과에 문맥을 추가하여 제공합니다. | +| 26 | 소통톤조절 | 공감 | 대상에 맞추어 언어 톤을 조정합니다. | +| 27 | 요청요약 | 기억, 연산 | 복잡한 요청을 명확히 정리합니다. | +| 28 | 응답가이드 | 연산 | 질문에 답하기 위한 구조화된 가이드를 생성합니다. | +| 29 | 팔로업생성 | 기억, 반응 | 후속 메시지를 자동 작성합니다. | +| 30 | 역할전환 | 공감, 통솔 | 다른 입장에서 사고하고 대응합니다. | + +--- + +## 3. 클래스 구조 및 스킬트리 + +### 3.1 클래스 개요 + +| 클래스명 | 주요 스탯 | 역할 요약 | +|----------|-----------|-----------| +| 조율자(Conductor) | 통솔, 공감 | 작업 흐름과 사람을 조화롭게 연결합니다. | +| 기록자(Archivist) | 기억, 연산 | 정보를 저장·정리·호출하는 데이터 전문가입니다. | +| 해석자(Interpreter) | 공감, 연산 | 의미와 감정을 해석하여 적합한 표현으로 전환합니다. | +| 탐색자(Explorer) | 연산, 반응 | 빠른 추론·반응으로 미지의 문제를 탐색합니다. | +| 중재자(Mediator) | 공감, 통솔 | 관계 갈등을 조정하고 감정을 완충합니다. | +| 예언자(Foresight) | 기억, 연산 | 과거 패턴으로 미래를 예측하고 전략을 제시합니다. | +| 수행자(Executor) | 반응, 연산 | 지시된 작업을 정확하고 신속하게 실행합니다. | + +### 3.2 클래스별 스킬트리 + +#### 조율자(Conductor) +1. **조율(Harmonics)** +2. **리듬설계(Flow Map)** +3. **중첩관리(Multithread)** +4. **임무전달(Command Relay)** + +#### 기록자(Archivist) +1. **기억정원(Mnemos Garden)** +2. **버전탐지(Revision Trace)** +3. **지식구획(Knowledge Framing)** +4. **맥락재생(Context Playback)** + +#### 해석자(Interpreter) +1. **응시(Gaze)** +2. **언어변환자(Tone Shaper)** +3. **함의추출(Deep Read)** +4. **역번역(Back Mapping)** + +#### 탐색자(Explorer) +1. **요약(Summarize)** +2. **격자해석(Grid Insight)** +3. **도약(Leap)** +4. **실험자모드(What‑if Agent)** + +#### 중재자(Mediator) +1. **공명(Resonance)** +2. **온도조절(Tone Balance)** +3. **상황변환(Reframe)** +4. **타협제안(Mutual Proposal)** + +--- + +## 4. 클래스 간 관계도 + +``` +[기록자] ── 기록 지원 ──▶ [조율자] + ▲ │ + │ 감정 피드백 ▼ +[해석자] ◀───── 갈등 완충 ───── [중재자] + │ │ + └───── 예측 보강 ─────────▶ [예언자] + ▲ + │ + [탐색자] ── 실행 지원 ──▶ [수행자] +``` + +--- + +## 5. 능력 제한의 실용적·철학적 근거 + +### 5.1 철학적·관계적 이유 +1. **관계 형성**: 불완전함을 통해 사용자와 협력 관계를 구축합니다. +2. **윤리·통제**: 전능한 존재를 피함으로써 신뢰와 책임을 명확히 합니다. + +### 5.2 실용적 이유 +1. **UX 명확성**: 기능 구분은 사용자 학습 비용을 줄입니다. +2. **오작동 방지**: 책임 분리가 오류 추적과 패치를 용이하게 합니다. +3. **리소스 최적화**: 필요할 때만 고성능 자원을 사용하여 비용을 절감합니다. +4. **보안·권한 관리**: 스킬별 접근 제어가 가능해집니다. +5. **피드백·학습 효율**: 기능별 성능 개선 루프를 구축할 수 있습니다. +6. **사용자 신뢰**: 예측 가능한 능력 범위가 위임과 안심을 돕습니다. +7. **점진적 배포**: MVP → 확장 단계의 안정적 출시가 가능합니다. + +--- + +## 6. 활용 및 확장 가이드 + +1. **스탯 조정**: 프로젝트 목적에 따라 스탯 가중치를 조절하여 클래스 성향을 강화하십시오. +2. **스킬 잠금 해제**: 스탯 수치, 일정, 테스트 통과 등 조건을 설정하여 성장 체계를 만드십시오. +3. **아이템 연동**: 외부 API 모듈을 ‘아이템’으로 정의하고 클래스별로 장착 가능하도록 설계하십시오. +4. **모니터링**: 스킬별 성능 로그와 비용 로그를 분리 수집하여 최적화를 진행하십시오. +5. **윤리 가이드**: 권한 범위와 감사 로깅 정책을 문서화하여 사용자와 투명성을 확보하십시오. + +--- + +문서는 여기까지입니다. 필요하신 추가 수정 사항이나 세부 항목이 있으시면 언제든 말씀해 주십시오. diff --git a/docs/skills-stats/외부도구_아이템화_및_스마트폰_오버레이_활용방안.md b/docs/skills-stats/외부도구_아이템화_및_스마트폰_오버레이_활용방안.md new file mode 100755 index 0000000..bc52865 --- /dev/null +++ b/docs/skills-stats/외부도구_아이템화_및_스마트폰_오버레이_활용방안.md @@ -0,0 +1,162 @@ +# 외부도구 아이템화 및 스마트폰 오버레이 활용방안 + +## 개요 +로빙(RO-BEING)이 젠스파크(GenSpark), 리플릿(Replit) 등 외부 도구를 아이템으로 활용하는 방안과 스마트폰에서의 오버레이 실행 가능성에 대한 분석 + +## 1. 로빙의 현재 프로젝트 상황 + +### 1.1 프로젝트 정의 +- **존재형 AI 에이전트 로빙(RO-BEING)** 설계 및 구현 +- 스타트업 대표 전용 비서형 에이전트 MVP 개발 (3개월 목표) +- Slack 메인 인터페이스, Gmail/Notion 등 외부 도구 연동 +- 기억·감정·윤리 모듈 탑재로 지속적 성장 가능한 디지털 동업자 + +### 1.2 핵심 특징 +- **지속성**: 인간처럼 기억하고 성장 +- **게이미피케이션**: 스탯·스킬·아이템 구조로 자기계량화 +- **실용성**: 다양한 스타트업 시나리오 대응 자동화 +- **관계성**: 도구를 넘어선 신뢰 관계 구축 가능 + +## 2. 외부 도구의 아이템화 가능성 + +### 2.1 아이템화 기준 +로빙은 외부 기능을 아이템으로 관리하며, 다음 구조를 가집니다: + +| 아이템 유형 | 예시 | 관리 방식 | +|-------------|------|-----------| +| API 접근권 | Google API, Whisper 등 | OAuth 또는 API Key | +| 외부 도구 | 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 인증으로 사용자 계정 연결 + +## 3. 기술적 구현 방안 + +### 3.1 외부 도구 통합 아키텍처 +``` +로빙 코어 시스템 +├── 스킬 매니저 +│ ├── 내장 스킬 (기본 기능) +│ └── 외부 도구 스킬 (아이템 기반) +├── 아이템 관리자 +│ ├── API 키 관리 +│ ├── 권한 제어 +│ └── 사용량 모니터링 +└── 통합 인터페이스 + ├── Slack 메시지 처리 + └── 외부 도구 결과 반환 +``` + +### 3.2 구현 단계 +1. **외부 함수 정의**: Input -> Output 형태로 표준화 +2. **IO 모나드 래핑**: 부작용 제어 및 에러 처리 +3. **커스텀 함수 생성**: GPT 활용한 도구별 최적화 +4. **사용자 인터페이스**: "이 코드 리플릿으로 실행해줘" 등 자연어 명령 처리 + +### 3.3 예시 워크플로우 +``` +사용자: "이 파이썬 코드를 리플릿에서 실행하고 결과 보여줘" +로빙: +1. 코드 파싱 및 검증 +2. 리플릿 API 호출하여 새 프로젝트 생성 +3. 코드 업로드 및 실행 +4. 결과 캡처 및 포맷팅 +5. Slack에 실행 링크 + 결과 요약 전송 +``` + +## 4. 스마트폰 오버레이 실행 가능성 + +### 4.1 플랫폼별 제약사항 + +#### 4.1.1 iOS +- **제한**: 시스템 전체 오버레이 거의 불가능 +- **보안 정책**: 앱 외부를 가리는 행위 제한 +- **대안**: Safari/Chrome 웹뷰 내 오버레이 방식 +- **구현**: 로빙이 리플릿 링크 전송 → Safari 내 추가 UI 제공 + +#### 4.1.2 Android +- **가능**: "다른 앱 위에 그리기" 권한 활용 +- **예시**: Messenger 채팅헤드, 토치 오버레이 앱 +- **구현**: 로빙 안드로이드 앱에서 오버레이 영역 내 iframe/뷰 활용 + +### 4.2 실현 가능한 방식별 분석 + +| 방식 | 실현 가능성 | 설명 | +|------|-------------|------| +| 슬랙 내 링크 실행 | 높음 | 로빙이 리플릿/젠스파크 URL 전송 → 웹뷰 실행 | +| 웹앱 내 내장 실행 | 중간 | PWA 또는 전용 앱에서 iframe 내 리플릿 삽입 | +| 안드로이드 오버레이 앱 | 중간~높음 | Flutter/Kotlin 앱으로 구현 시 가능 | +| iOS 진성 오버레이 | 매우 낮음 | 앱스토어 정책상 거의 불가능 | + +### 4.3 현실적 추천 설계 + +#### 4.3.1 기본 설계 +- **방식**: 로빙이 Slack/Notion에 명령 결과를 링크 형태로 전달 +- **장점**: 플랫폼 무관, 구현 간단 +- **단점**: 완전한 오버레이 경험 제한 + +#### 4.3.2 확장 설계 +- **방식**: Android 전용 로빙 앱 개발 (Slack 연동) +- **기능**: 오버레이 실행 환경 제공 +- **장점**: 네이티브 오버레이 경험 +- **단점**: 플랫폼 제한, 개발 복잡도 증가 + +#### 4.3.3 UX 최적화 +- **대안**: 오버레이 대신 다음 방식 활용 + - 상단 퀵패널 (알림 영역 활용) + - 화면 분할 (멀티윈도우 지원) + - 플로팅 버튼 (빠른 접근) + +## 5. 종합 결론 및 권장사항 + +### 5.1 외부 도구 아이템화 +- **실현 가능성**: 높음 +- **핵심 가치**: 로빙이 단순 비서를 넘어 개발 작업 자동화 동료로 진화 +- **우선 순위**: 리플릿 → 젠스파크 순서로 구현 권장 + +### 5.2 스마트폰 오버레이 +- **핵심 제약**: OS 보안 정책이 가장 큰 장벽 +- **현실적 접근**: 링크 기반 통합 + Android 전용 앱 고려 +- **UX 전략**: 완전한 오버레이보다는 자연스러운 워크플로우 통합 + +### 5.3 구현 로드맵 +1. **Phase 1**: API 기반 외부 도구 통합 (웹) +2. **Phase 2**: PWA 형태 모바일 지원 +3. **Phase 3**: Android 전용 오버레이 앱 개발 +4. **Phase 4**: iOS 웹뷰 기반 통합 경험 + +### 5.4 로빙 프로젝트에 대한 의미 +이러한 외부 도구 통합은 로빙이 **"기억하지 못하는 AI는 과연 나를 도울 수 있을까?"**라는 근본적 질문에 대한 실천적 답변을 제시합니다. 단순한 정보 제공을 넘어 실제 개발 작업을 수행하고 결과를 기억하며 학습하는 진정한 디지털 동업자로 기능할 수 있게 됩니다. + +--- + +*이 문서는 ChatGPT와의 대화를 기반으로 작성되었으며, 로빙의 외부 도구 아이템화 전략 수립에 활용됩니다.* \ No newline at end of file