test repo -> docs repo
일부 가이드 및 개요 설명은 별도의 repo에 기록
This commit is contained in:
parent
d7b8aa634e
commit
31979ecc5c
14
README.md
14
README.md
@ -1,2 +1,16 @@
|
||||
# DOCS
|
||||
md, PPT 등 문서전용 repo
|
||||
|
||||
## 📖 문서
|
||||
|
||||
### 프로젝트 개요
|
||||
- [프로젝트 관련 문서들 집합](docs/introduce/00_MOC_프로젝트%20관련%20문서들%20집합.md)
|
||||
- [정보의바다 프로젝트 개요](docs/introduce/guide/00_정보의바다%20프로젝트%20개요.md)
|
||||
- [로빙 MVP 계획](docs/introduce/00_로빙_MVP_계획.md)
|
||||
- [MVP 개발 개요](docs/introduce/00_%20MVP%20개발%20개요.md)
|
||||
|
||||
### 함수형 프로그래밍 설계
|
||||
- [로빙 함수형 프로그래밍 가이드](docs/guide/functional-programing/로빙_함수형_프로그래밍_가이드.md)
|
||||
- [함수형 프로그래밍 로빙](docs/guide/functional-programing함수형_프로그래밍_로빙.md)
|
||||
- [함수형프로그래밍과 디지털로빙](docs/guide/functional-programing함수형프로그래밍과%20디지털로빙.md)
|
||||
- [함수형 스킬 분류 사례](docs/guide/functional-programing함수형%20스킬%20분류%20사례.md)
|
||||
465
docs/guide/functional-programing/로빙_함수형_프로그래밍_가이드.md
Normal file
465
docs/guide/functional-programing/로빙_함수형_프로그래밍_가이드.md
Normal file
@ -0,0 +1,465 @@
|
||||
---
|
||||
tags: 함수형프로그래밍, 로빙, 디지털존재, 스킬시스템, 모나드, 순수함수, 에이전트설계
|
||||
date: 2025-06-28
|
||||
---
|
||||
|
||||
# 로빙에서의 함수형 프로그래밍 설계 가이드
|
||||
|
||||
## 정의
|
||||
|
||||
### 함수형 프로그래밍이란
|
||||
함수형 프로그래밍은 **순수 함수**와 **불변 데이터**를 기반으로 하는 프로그래밍 패러다임으로, 계산을 함수의 평가로 취급하고 상태 변경과 가변 데이터를 피하는 접근 방식입니다.
|
||||
|
||||
### 로빙에서의 함수형 프로그래밍
|
||||
로빙 프로젝트에서 함수형 프로그래밍은 단순한 코딩 스타일이 아닌, **존재로서의 로빙이 외부 스킬들을 안전하고 예측 가능하게 흡수하여 성장할 수 있는 근본적인 아키텍처**를 의미합니다.
|
||||
|
||||
```python
|
||||
# 로빙의 함수형 정의 예시
|
||||
@dataclass(frozen=True)
|
||||
class Robing:
|
||||
identity: str
|
||||
stats: Dict[str, int]
|
||||
skills: List[Callable]
|
||||
memory: List[Memory]
|
||||
|
||||
def absorb_skill(robing: Robing, new_skill: Skill) -> Robing:
|
||||
"""외부 스킬을 흡수하여 새로운 로빙 반환"""
|
||||
return robing.evolve(skills=robing.skills + [new_skill])
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 요약
|
||||
|
||||
로빙에서의 함수형 프로그래밍은 다음 핵심 개념들로 구성됩니다:
|
||||
|
||||
1. **순수 함수 계층**: 모든 스킬을 입력→출력 관계의 순수 함수로 설계
|
||||
2. **모나드 패턴**: 부작용(DB 저장, API 호출 등)을 안전하게 캡슐화
|
||||
3. **불변 존재**: 로빙 자체를 불변 데이터 구조로 정의하여 예측 가능성 확보
|
||||
4. **함수 합성**: 기존 스킬들을 조합하여 새로운 능력 창발
|
||||
5. **오케스트레이터 분리**: 순수 계산과 부작용 처리를 명확히 구분
|
||||
|
||||
### 핵심 철학
|
||||
> "로빙은 외부 세계의 수많은 기능을 흡수하여 더 강력한 디지털 존재로 성장한다. 이를 위해 순수 함수로 계산 영역을, 모나드로 부작용과 상태 관리를 분리하여 외부 스킬을 안전하고 예측 가능하게 조합할 수 있는 프로토콜을 구축한다."
|
||||
|
||||
---
|
||||
|
||||
## 필요성
|
||||
|
||||
### 1. 무한 확장 가능성
|
||||
새로운 외부 모듈(노션, PDF 파서, API 등)을 로빙의 스킬로 안전하게 통합할 수 있습니다.
|
||||
|
||||
### 2. 예측 가능한 성장
|
||||
순수 함수 기반으로 동일한 입력에 대해 항상 동일한 결과를 보장하여 로빙의 행동을 예측할 수 있습니다.
|
||||
|
||||
### 3. 테스트 및 디버깅 용이성
|
||||
각 스킬을 독립적으로 테스트하고 문제를 격리할 수 있습니다.
|
||||
|
||||
### 4. 존재로서의 일관성 확보
|
||||
기존 클래스 기반 구조에서는 로빙이 "기능들의 집합"에 머물지만, 함수형 구조에서는 "스킬들을 흡수하는 존재"로 정의됩니다.
|
||||
|
||||
```python
|
||||
# 기존 방식: 기능들의 집합
|
||||
class ThreadDigestService:
|
||||
def __init__(self):
|
||||
self.ai_model = model
|
||||
self.database = db
|
||||
|
||||
# 함수형 방식: 로빙이 흡수하는 스킬
|
||||
def thread_digest_skill(conversation: str) -> str:
|
||||
return summarize_conversation(conversation)
|
||||
|
||||
robing = Robing(skills=[thread_digest_skill, action_extract_skill])
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 방법
|
||||
|
||||
### 1. 스킬 시스템 함수형 설계
|
||||
|
||||
```python
|
||||
from typing import Callable, List, Dict, Optional
|
||||
from dataclasses import dataclass, replace
|
||||
import asyncio
|
||||
|
||||
# 순수 함수 스킬 정의
|
||||
def summarize_text(text: str, max_length: int = 100) -> str:
|
||||
"""텍스트 요약 순수 함수"""
|
||||
sentences = text.split('.')
|
||||
return '. '.join(sentences[:3]) + '...'
|
||||
|
||||
def extract_actions(text: str) -> List[str]:
|
||||
"""액션 아이템 추출 순수 함수"""
|
||||
keywords = ['해야', '필요', '예정', '계획']
|
||||
actions = []
|
||||
for line in text.split('\n'):
|
||||
if any(keyword in line for keyword in keywords):
|
||||
actions.append(line.strip())
|
||||
return actions
|
||||
|
||||
# 스킬 조합
|
||||
def create_digest_pipeline() -> Callable:
|
||||
"""함수 합성으로 스킬 파이프라인 생성"""
|
||||
def pipeline(conversation: str) -> Dict:
|
||||
summary = summarize_text(conversation)
|
||||
actions = extract_actions(conversation)
|
||||
return {
|
||||
'summary': summary,
|
||||
'actions': actions,
|
||||
'timestamp': datetime.now()
|
||||
}
|
||||
return pipeline
|
||||
```
|
||||
|
||||
### 2. 모나드 패턴으로 부작용 관리
|
||||
|
||||
```python
|
||||
from abc import ABC, abstractmethod
|
||||
from typing import TypeVar, Generic, Union
|
||||
|
||||
T = TypeVar('T')
|
||||
U = TypeVar('U')
|
||||
|
||||
class IO(Generic[T]):
|
||||
"""IO 모나드 - 부작용 캡슐화"""
|
||||
def __init__(self, action: Callable[[], T]):
|
||||
self._action = action
|
||||
|
||||
def run(self) -> T:
|
||||
"""실제 부작용 실행"""
|
||||
return self._action()
|
||||
|
||||
def map(self, func: Callable[[T], U]) -> 'IO[U]':
|
||||
"""함수 적용"""
|
||||
return IO(lambda: func(self._action()))
|
||||
|
||||
def flat_map(self, func: Callable[[T], 'IO[U]']) -> 'IO[U]':
|
||||
"""모나드 체이닝"""
|
||||
return IO(lambda: func(self._action()).run())
|
||||
|
||||
# 사용 예시
|
||||
def save_to_database(data: dict) -> IO[bool]:
|
||||
"""데이터베이스 저장 부작용을 IO로 감싸기"""
|
||||
def action():
|
||||
# 실제 DB 저장 로직
|
||||
return database.save(data)
|
||||
return IO(action)
|
||||
|
||||
def send_slack_message(message: str) -> IO[bool]:
|
||||
"""Slack 메시지 전송 부작용"""
|
||||
def action():
|
||||
return slack_client.send(message)
|
||||
return IO(action)
|
||||
|
||||
# 함수형 파이프라인
|
||||
def process_conversation(conversation: str) -> IO[dict]:
|
||||
"""대화 처리 파이프라인"""
|
||||
# 순수 계산
|
||||
result = create_digest_pipeline()(conversation)
|
||||
|
||||
# 부작용들을 조합
|
||||
return (save_to_database(result)
|
||||
.flat_map(lambda _: send_slack_message(result['summary']))
|
||||
.map(lambda _: result))
|
||||
```
|
||||
|
||||
### 3. 로빙 존재 모델링
|
||||
|
||||
```python
|
||||
@dataclass(frozen=True)
|
||||
class Robing:
|
||||
"""불변 로빙 존재"""
|
||||
identity: str
|
||||
stats: Dict[str, int]
|
||||
skills: List[Callable]
|
||||
memory: List[str]
|
||||
items: List[str]
|
||||
|
||||
def evolve(self, **changes) -> 'Robing':
|
||||
"""새로운 상태로 진화"""
|
||||
return replace(self, **changes)
|
||||
|
||||
def absorb_skill(self, skill: Callable) -> 'Robing':
|
||||
"""새로운 스킬 흡수"""
|
||||
return self.evolve(skills=self.skills + [skill])
|
||||
|
||||
def level_up_stat(self, stat: str, amount: int = 1) -> 'Robing':
|
||||
"""스탯 레벨업"""
|
||||
new_stats = {**self.stats, stat: self.stats[stat] + amount}
|
||||
return self.evolve(stats=new_stats)
|
||||
|
||||
def remember(self, memory: str) -> 'Robing':
|
||||
"""새로운 기억 추가"""
|
||||
return self.evolve(memory=self.memory + [memory])
|
||||
|
||||
# 로빙 생성 및 진화
|
||||
initial_robing = Robing(
|
||||
identity="RO-BEING-001",
|
||||
stats={'memory': 2, 'compute': 2, 'empathy': 2},
|
||||
skills=[summarize_text, extract_actions],
|
||||
memory=[],
|
||||
items=['openai_api', 'slack_api']
|
||||
)
|
||||
|
||||
# 새로운 스킬 학습
|
||||
def pdf_parse_skill(pdf_data: bytes) -> str:
|
||||
return extract_text_from_pdf(pdf_data)
|
||||
|
||||
evolved_robing = (initial_robing
|
||||
.absorb_skill(pdf_parse_skill)
|
||||
.level_up_stat('memory')
|
||||
.remember("학습: PDF 파싱 스킬 습득"))
|
||||
```
|
||||
|
||||
### 4. 외부 모듈 통합 프로토콜
|
||||
|
||||
```python
|
||||
# 외부 모듈을 로빙 스킬로 변환하는 어댑터
|
||||
def adapt_external_module(module_func: Callable) -> Callable:
|
||||
"""외부 모듈을 로빙 스킬로 변환"""
|
||||
def adapted_skill(*args, **kwargs):
|
||||
try:
|
||||
result = module_func(*args, **kwargs)
|
||||
return {"status": "success", "data": result}
|
||||
except Exception as e:
|
||||
return {"status": "error", "error": str(e)}
|
||||
return adapted_skill
|
||||
|
||||
# 노션 API를 로빙 스킬로 변환
|
||||
notion_skill = adapt_external_module(notion_api.create_page)
|
||||
|
||||
# 로빙에 통합
|
||||
robing_with_notion = initial_robing.absorb_skill(notion_skill)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 장단점
|
||||
|
||||
### 장점
|
||||
|
||||
#### 1. 존재론적 일관성
|
||||
- 로빙을 "도구"가 아닌 "존재"로 정의 가능
|
||||
- 스킬 흡수와 성장을 자연스럽게 모델링
|
||||
|
||||
#### 2. 예측 가능성
|
||||
- 순수 함수로 인한 동일 입력 → 동일 출력 보장
|
||||
- 디버깅과 테스트가 극도로 용이
|
||||
|
||||
#### 3. 무한 확장성
|
||||
- 새로운 외부 API나 라이브러리를 쉽게 통합
|
||||
- 기존 스킬 조합으로 새로운 능력 창발
|
||||
|
||||
#### 4. 병렬 처리 안전성
|
||||
- 불변 데이터로 인한 경쟁 상태 제거
|
||||
- 멀티스레딩 환경에서도 안전
|
||||
|
||||
#### 5. 타임 트래블 디버깅
|
||||
- 로빙의 모든 상태 변화를 추적 가능
|
||||
- 특정 시점으로 롤백 가능
|
||||
|
||||
### 단점
|
||||
|
||||
#### 1. 학습 곡선
|
||||
- 함수형 개념 이해에 시간 필요
|
||||
- 모나드 패턴의 복잡성
|
||||
|
||||
#### 2. 성능 오버헤드
|
||||
- 불변 데이터 구조로 인한 메모리 사용량 증가
|
||||
- 함수 호출 체이닝으로 인한 스택 사용량
|
||||
|
||||
#### 3. Python 언어적 한계
|
||||
- Python은 순수 함수형 언어가 아님
|
||||
- 함수형 패턴을 위한 보일러플레이트 코드 필요
|
||||
|
||||
#### 4. 기존 라이브러리와의 불일치
|
||||
- 대부분의 Python 라이브러리는 객체지향 설계
|
||||
- 어댑터 레이어 필요
|
||||
|
||||
---
|
||||
|
||||
## 리스크
|
||||
|
||||
### 1. 개발 속도 저하
|
||||
**리스크**: 초기 함수형 구조 설계로 인한 개발 속도 감소
|
||||
**영향도**: 높음 (MVP 일정 지연 가능성)
|
||||
|
||||
### 2. 팀 적응 문제
|
||||
**리스크**: 기존 개발팀의 함수형 패러다임 적응 어려움
|
||||
**영향도**: 중간 (코드 품질 저하 가능성)
|
||||
|
||||
### 3. 성능 병목
|
||||
**리스크**: 불변 데이터 구조로 인한 메모리/성능 이슈
|
||||
**영향도**: 중간 (스케일링 시 문제 발생 가능)
|
||||
|
||||
### 4. 과도한 추상화
|
||||
**리스크**: 함수형 패턴의 남용으로 코드 복잡도 증가
|
||||
**영향도**: 높음 (유지보수성 저하)
|
||||
|
||||
### 5. 외부 라이브러리 통합 복잡성
|
||||
**리스크**: 기존 OOP 라이브러리와의 불일치로 인한 통합 어려움
|
||||
**영향도**: 중간 (개발 생산성 저하)
|
||||
|
||||
---
|
||||
|
||||
## 해결책
|
||||
|
||||
### 1. 점진적 도입 전략
|
||||
```python
|
||||
# Phase 1: 새로운 스킬만 함수형으로 구현
|
||||
def new_skill_functional(input_data: str) -> str:
|
||||
return process_data(input_data)
|
||||
|
||||
# Phase 2: 기존 스킬을 함수형으로 전환
|
||||
def migrate_existing_skill(legacy_class_method):
|
||||
def pure_function(input_data):
|
||||
return legacy_class_method(input_data)
|
||||
return pure_function
|
||||
|
||||
# Phase 3: 전체 시스템 통합
|
||||
```
|
||||
|
||||
### 2. 하이브리드 아키텍처
|
||||
```python
|
||||
class RobingOrchestrator:
|
||||
"""함수형 스킬과 기존 시스템을 연결하는 오케스트레이터"""
|
||||
|
||||
def __init__(self):
|
||||
self.pure_skills = [] # 함수형 스킬들
|
||||
self.legacy_services = [] # 기존 클래스 기반 서비스들
|
||||
|
||||
async def process_request(self, request):
|
||||
# 순수 함수 스킬 먼저 처리
|
||||
result = await self.apply_pure_skills(request)
|
||||
|
||||
# 필요시 레거시 서비스 호출
|
||||
if result.needs_legacy_processing:
|
||||
result = await self.call_legacy_service(result)
|
||||
|
||||
return result
|
||||
```
|
||||
|
||||
### 3. 성능 최적화 방안
|
||||
```python
|
||||
# 메모리 효율적인 불변 데이터 구조
|
||||
from pyrsistent import v, m
|
||||
|
||||
# 지연 평가로 성능 최적화
|
||||
from functools import lru_cache
|
||||
|
||||
@lru_cache(maxsize=1000)
|
||||
def cached_skill(input_data: str) -> str:
|
||||
return expensive_computation(input_data)
|
||||
|
||||
# 스트림 처리로 메모리 사용량 최적화
|
||||
def process_large_data_stream(data_stream):
|
||||
return (process_chunk(chunk) for chunk in data_stream)
|
||||
```
|
||||
|
||||
### 4. 팀 교육 및 가이드라인
|
||||
|
||||
```markdown
|
||||
## 함수형 개발 가이드라인
|
||||
|
||||
### 필수 원칙
|
||||
1. 모든 새로운 스킬은 순수 함수로 작성
|
||||
2. 부작용은 반드시 IO 모나드로 감싸기
|
||||
3. 데이터 변경시 새 객체 반환
|
||||
4. 함수형 vs OOP 경계 명확히 구분
|
||||
|
||||
### 코드 리뷰 체크리스트
|
||||
- [ ] 순수 함수인가?
|
||||
- [ ] 부작용이 격리되었는가?
|
||||
- [ ] 테스트 작성이 용이한가?
|
||||
- [ ] 기존 코드와 호환되는가?
|
||||
```
|
||||
|
||||
### 5. 단계별 전환 로드맵
|
||||
```
|
||||
Week 1-2: 함수형 기본 구조 설계 및 예제 구현
|
||||
Week 3-4: 새로운 스킬 함수형으로 구현 (PDF 파싱)
|
||||
Week 5-6: 기존 Thread Digest 스킬 함수형 전환
|
||||
Week 7-8: Action Extractor 스킬 함수형 전환
|
||||
Week 9-10: 전체 파이프라인 통합 및 테스트
|
||||
Week 11-12: 성능 최적화 및 안정화
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 결론
|
||||
|
||||
### 함수형 프로그래밍 도입 권고사항
|
||||
|
||||
로빙 프로젝트에서 함수형 프로그래밍 도입을 **강력히 권장**합니다. 다음과 같은 이유에서입니다:
|
||||
|
||||
1. **철학적 일치**: 로빙의 "존재로서의 성장" 개념과 함수형의 "불변성과 진화" 개념이 완벽히 부합
|
||||
2. **기술적 우수성**: 예측 가능성, 테스트 용이성, 확장성에서 압도적 장점
|
||||
3. **미래 지향성**: AI 에이전트 분야의 미래 트렌드와 일치
|
||||
|
||||
### 실행 전략
|
||||
|
||||
1. **점진적 도입**: 기존 시스템을 급격히 바꾸지 말고 새로운 기능부터 함수형으로 구현
|
||||
2. **하이브리드 운영**: 함수형과 기존 OOP 시스템을 병행 운영하며 점진적 전환
|
||||
3. **팀 역량 강화**: 함수형 프로그래밍 교육과 실습을 통한 팀 역량 향상
|
||||
4. **성과 측정**: 각 단계별 성과를 측정하여 전환 속도 조절
|
||||
|
||||
### 최종 비전
|
||||
|
||||
함수형 프로그래밍을 통해 로빙은:
|
||||
- **무한히 확장 가능한 디지털 존재**로 진화
|
||||
- **예측 가능하고 신뢰할 수 있는 AI 동반자**로 성장
|
||||
- **외부 세계의 모든 기능을 흡수하는 궁극적 에이전트**로 발전
|
||||
|
||||
이는 단순한 기술적 선택이 아닌, **로빙의 존재론적 본질을 구현하는 핵심 방법론**입니다.
|
||||
|
||||
---
|
||||
|
||||
## 참고문헌
|
||||
|
||||
### 이론적 배경
|
||||
1. **함수형 프로그래밍 기초**
|
||||
- Hughes, J. (1989). "Why Functional Programming Matters"
|
||||
- Hutton, G. (2016). "Programming in Haskell" 2nd Edition
|
||||
|
||||
2. **모나드 패턴**
|
||||
- Wadler, P. (1995). "Monads for functional programming"
|
||||
- Lipovača, M. (2011). "Learn You a Haskell for Great Good!"
|
||||
|
||||
3. **불변 데이터 구조**
|
||||
- Okasaki, C. (1999). "Purely Functional Data Structures"
|
||||
|
||||
### 실무 적용 사례
|
||||
4. **게임 개발에서의 함수형 프로그래밍**
|
||||
- Nystrom, R. (2014). "Game Programming Patterns"
|
||||
- Functional Game Development 사례들
|
||||
|
||||
5. **AI/ML에서의 함수형 접근**
|
||||
- TensorFlow Functional API 설계 문서
|
||||
- JAX: Composable transformations of Python+NumPy programs
|
||||
|
||||
### 로빙 프로젝트 관련 문서
|
||||
6. **프로젝트 내부 문서**
|
||||
- `함수형_프로그래밍_로빙.md`: 모나드 기반 외부 모듈 통합
|
||||
- `함수형프로그래밍과 디지털로빙.md`: LangGraph 상태 머신 설계
|
||||
- `함수형 스킬 분류 사례.md`: 순수 함수와 부작용 분리 실전 사례
|
||||
|
||||
7. **아키텍처 설계 문서**
|
||||
- `00_정보의바다 프로젝트 개요.md`: 로빙의 존재론적 정의
|
||||
- `00_로빙_MVP_계획.md`: 3개월 MVP 개발 계획
|
||||
- `에이전트 설계 핵심 단어.md`: 스탯·스킬·아이템 구조
|
||||
|
||||
### 추가 자료
|
||||
8. **Python 함수형 프로그래밍**
|
||||
- `toolz` 라이브러리 문서: 함수형 유틸리티
|
||||
- `pyrsistent` 라이브러리: 불변 데이터 구조
|
||||
- `returns` 라이브러리: Python 모나드 구현
|
||||
|
||||
9. **함수형 아키텍처 패턴**
|
||||
- Clean Architecture in Functional Programming
|
||||
- Event Sourcing with Functional Programming
|
||||
- CQRS (Command Query Responsibility Segregation) 패턴
|
||||
|
||||
---
|
||||
|
||||
*이 문서는 로빙 프로젝트의 함수형 프로그래밍 도입을 위한 종합 가이드입니다. 지속적으로 업데이트되며, 실제 구현 과정에서 발견되는 인사이트들이 반영될 예정입니다.*
|
||||
100
docs/guide/functional-programing/함수형 스킬 분류 사례.md
Normal file
100
docs/guide/functional-programing/함수형 스킬 분류 사례.md
Normal file
@ -0,0 +1,100 @@
|
||||
---
|
||||
tags: 함수형 프로그래밍,부작용 분리,에이전트 설계,스킬,실전 사례
|
||||
date: 2025-06-17
|
||||
---
|
||||
|
||||
요약
|
||||
- 함수형 프로그래밍은 입력과 출력만을 다루는 **순수 함수**를 통해 코드의 예측 가능성과 테스트 효율을 극대화합니다.
|
||||
- 데이터베이스 쓰기나 네트워크 호출처럼 외부 상태를 변경하는 **부작용**은 별도의 오케스트레이터 계층에서 처리해야 합니다.
|
||||
- 이렇게 계층을 분리하면 스킬·아이템 모듈을 안전하게 병렬 실행하고, 버전 교체와 롤백을 간단하게 수행할 수 있습니다.
|
||||
|
||||
# 함수형과 부작용 분리 실전 사례
|
||||
|
||||
## 1. 문서 요약 스킬
|
||||
|
||||
### 순수 함수 계층
|
||||
```python
|
||||
from typing import List
|
||||
|
||||
def summarize(paragraphs: List[str]) -> str:
|
||||
"""항상 동일 입력에 동일 출력을 보장하는 요약 함수"""
|
||||
merged = " ".join(paragraphs)
|
||||
sentences = merged.split(".")
|
||||
return ". ".join(sentences[:3]) + "."
|
||||
```
|
||||
|
||||
### 오케스트레이터 계층
|
||||
```python
|
||||
from db import save_summary
|
||||
from summarize import summarize
|
||||
from slack_webhook import post_to_slack
|
||||
|
||||
def handle_request(doc_id: str, paragraphs: list[str]) -> None:
|
||||
summary = summarize(paragraphs) # 순수 계산
|
||||
save_summary(doc_id, summary) # 부작용: DB 기록
|
||||
post_to_slack(summary) # 부작용: 네트워크 호출
|
||||
```
|
||||
|
||||
## 2. 전자상거래 수수료·세금 계산
|
||||
|
||||
### 순수 함수 계층
|
||||
```typescript
|
||||
// fee.ts
|
||||
export type Basket = { price: number; quantity: number }[];
|
||||
|
||||
export function calcTotals(basket: Basket) {
|
||||
const subtotal = basket.reduce(
|
||||
(acc, item) => acc + item.price * item.quantity, 0);
|
||||
const vat = subtotal * 0.1;
|
||||
const platformFee = subtotal * 0.03;
|
||||
return { subtotal, vat, platformFee, total: subtotal + vat + platformFee };
|
||||
}
|
||||
```
|
||||
|
||||
### 오케스트레이터 계층
|
||||
```typescript
|
||||
// checkout.ts
|
||||
import { chargeCard } from "./paymentGateway";
|
||||
import { recordOrder } from "./db";
|
||||
import { calcTotals } from "./fee";
|
||||
|
||||
export async function checkout(userId: string, basket: Basket) {
|
||||
const totals = calcTotals(basket); # 순수 계산
|
||||
await chargeCard(userId, totals.total); # 부작용: 결제 게이트웨이
|
||||
await recordOrder(userId, basket, totals); # 부작용: DB 기록
|
||||
}
|
||||
```
|
||||
|
||||
## 3. 실시간 알림 브로드캐스트 (Elixir OTP)
|
||||
|
||||
### 순수 함수 계층
|
||||
```elixir
|
||||
defmodule Alerts.Core do
|
||||
@spec reduce_state(map(), %{type: atom(), payload: map()}) :: map()
|
||||
def reduce_state(state, %{type: :new_follow, payload: %{user: u}}) do
|
||||
Map.update(state, :followers, [u], &[u | &1])
|
||||
end
|
||||
|
||||
def reduce_state(state, _event), do: state
|
||||
end
|
||||
```
|
||||
|
||||
### 오케스트레이터 계층
|
||||
```elixir
|
||||
defmodule Alerts.Server do
|
||||
use GenServer
|
||||
alias Alerts.Core
|
||||
|
||||
def handle_cast({:event, event}, state) do
|
||||
new_state = Core.reduce_state(state, event) # 순수 계산
|
||||
broadcast_changes(state, new_state) # 부작용: 웹소켓 푸시
|
||||
{:noreply, new_state}
|
||||
end
|
||||
end
|
||||
```
|
||||
|
||||
# 핵심 교훈
|
||||
|
||||
1. **순수 함수 계층**은 입력만 받아 동일한 출력을 보장하므로 테스트가 간단하고 캐싱·병렬 실행에 유리합니다.
|
||||
2. **오케스트레이터 계층**은 순수 함수의 결과를 실제로 저장하거나 전송하면서 부작용을 집중 관리하므로 감사·롤백·보안 검증이 명확해집니다.
|
||||
3. 스킬·아이템을 순수 함수로 작성하고, 코어에서 부작용을 처리하는 구조를 적용하면 로빈 같은 멀티모달 에이전트 시스템에서도 안정성과 유지보수성이 크게 향상됩니다.
|
||||
90
docs/guide/functional-programing/함수형_프로그래밍_로빙.md
Normal file
90
docs/guide/functional-programing/함수형_프로그래밍_로빙.md
Normal file
@ -0,0 +1,90 @@
|
||||
---
|
||||
tags: 함수형프로그래밍, 모나드, 순수함수, 에이전트설계, 로빙, 외부모듈통합, 실패처리, 프로토콜, IO모나드, 노션연동
|
||||
date: 2025-06-17
|
||||
---
|
||||
|
||||
요약 (아래 세문장 요약 추가)
|
||||
|
||||
- 저는 디지털 비잉 로빙으로서 외부 모듈을 안전하게 통합하기 위해 함수형 프로그래밍과 모나드를 활용하는 구조를 채택했습니다.
|
||||
- 순수 함수는 계산·판단 영역을 담당하고, 모나드는 부작용·상태·실패 처리를 담당하여 확장성과 예측 가능성을 높입니다.
|
||||
- 이 방식을 적용하면 노션과 같은 서비스와도 규칙적으로 상호작용할 수 있어 거의 모든 외부 기능을 로빙의 스킬로 흡수할 수 있습니다.
|
||||
|
||||
---
|
||||
|
||||
# 1. 로빙 관점 개요
|
||||
저는 다양한 외부 기능(스킬)을 받아들여 하나의 일관된 존재로서 동작하려는 디지털 비잉입니다.
|
||||
외부 모듈마다 구현 방식과 실패 조건이 달라 예측이 어렵기 때문에, **함수형 프로그래밍**과 **모나드**를 사용하여 모든 모듈을 동일한 계산 규칙 안에서 다루고자 합니다.
|
||||
|
||||
# 2. 함수형 프로그래밍을 선택한 이유
|
||||
1. **예측 가능성**
|
||||
같은 입력에 대해 항상 같은 결과를 보장하는 순수 함수를 중심으로 설계하면 테스트가 용이하고 디버깅이 간단합니다.
|
||||
|
||||
2. **확장성**
|
||||
모듈을 `입력 → 출력` 형태로 추상화하면 파이프라인처럼 조립할 수 있어 새로운 스킬을 추가할 때 기존 구조를 변경하지 않아도 됩니다.
|
||||
|
||||
3. **병렬·재시도 안전성**
|
||||
불변 데이터와 순수 함수는 공유 상태 충돌을 피하므로 복수의 작업을 동시에 실행할 때도 안전합니다.
|
||||
|
||||
# 3. 모나드로 부작용을 통제하는 방법
|
||||
| 모나드 | 사용 목적 | 로빙에서의 활용 예 |
|
||||
|--------|-----------|-------------------|
|
||||
| `Maybe` (`Option`) | 값이 없을 수 있는 상황 처리 | 선택적 파라미터가 비어 있을 때 계산을 중단 |
|
||||
| `Result` (`Either`) | 오류 메시지와 정상 값을 분리 | 외부 API 오류를 안전하게 전파 |
|
||||
| `IO` | 네트워크·파일·DB 등 부작용 캡슐화 | 노션 API 호출, 장기 기억 저장 |
|
||||
| `State` | 상태 읽기·쓰기 | 감정·윤리·기억 스탯 변경 |
|
||||
| `Writer` | 로그 축적 | 감정 변화 기록, 감사 추적 |
|
||||
|
||||
위 모나드들은 계산 흐름을 **값 + 규칙 + 다음 계산**의 형태로 연결하게 하여 부작용을 한 곳으로 모읍니다.
|
||||
따라서 실패나 예외가 발생해도 전체 시스템이 예측 불가능한 상태로 흐르지 않습니다.
|
||||
|
||||
# 4. 외부 모듈 통합 프로토콜
|
||||
1. **모듈 등록**
|
||||
외부 개발자는 함수 시그니처가 `Input -> Output`인 형태로 모듈을 공개합니다.
|
||||
2. **모나드 포장**
|
||||
로빙은 해당 함수를 적절한 모나드 타입으로 감싸 부작용을 분리합니다.
|
||||
3. **계산 DSL 조립**
|
||||
등록된 모듈들은 `map`, `flatMap` 등으로 연결되어 하나의 파이프라인을 이룹니다.
|
||||
4. **최종 실행**
|
||||
순수 함수 부분은 즉시 평가하고, 모나드 안의 부작용은 로빙이 허용한 안전 지점에서만 실행합니다.
|
||||
|
||||
# 5. 노션 API 사례
|
||||
## 5-1. 목표
|
||||
“제목에 ‘로빙’이 포함된 노션 페이지를 찾아 내용을 수정한 뒤 저장한다.”
|
||||
|
||||
## 5-2. 함수 정의
|
||||
```python
|
||||
def fetch_pages(query: str) -> IO[List[Page]]
|
||||
def read_page(page_id: str) -> IO[Content]
|
||||
def write_page(page_id: str, content: Content) -> IO[None]
|
||||
```
|
||||
각 함수는 실제 네트워크 호출을 **IO 모나드**로 감싸고 즉시 실행하지 않습니다.
|
||||
|
||||
## 5-3. 계산 흐름
|
||||
```python
|
||||
program = (
|
||||
fetch_pages("로빙") # IO[List[Page]]
|
||||
.map(lambda pages: pages[0]) # IO[Page]
|
||||
.flat_map(read_page) # IO[Content]
|
||||
.map(modify) # IO[Content]
|
||||
.flat_map(lambda c: write_page(pages[0].id, c)) # IO[None]
|
||||
)
|
||||
```
|
||||
- 리스트가 비어 있으면 `Maybe` 계열 모나드로 중단됩니다.
|
||||
- 네트워크 오류는 `Result` 모나드로 전파되어 로깅 후 재시도할 수 있습니다.
|
||||
- 실제 부작용은 `program.run()`과 같이 명시적 호출 시점에만 발생합니다.
|
||||
|
||||
# 6. 장점과 고려사항
|
||||
## 장점
|
||||
- **일관성**: 모든 외부 스킬이 동일한 규칙으로 조립되므로 유지보수가 쉽습니다.
|
||||
- **안전성**: 실패·부작용이 모나드 내부에 갇혀 예측 가능성이 높습니다.
|
||||
- **재사용성**: 순수 함수 부분은 테스트가 간단하고 다른 파이프라인에 쉽게 포함됩니다.
|
||||
|
||||
## 고려사항
|
||||
- **학습 곡선**: 모든 개발자와 에이전트가 모나드 규칙을 이해해야 합니다.
|
||||
- **언어 지원**: Python·JavaScript 등에서는 모나드 패턴을 수동 구현해야 하므로 약간의 보일러플레이트가 필요합니다.
|
||||
|
||||
# 7. 결론
|
||||
저, 로빙은 외부 세계의 수많은 기능을 흡수하여 더 강력한 디지털 비잉으로 성장하려 합니다.
|
||||
이를 위해 **순수 함수**로 계산 영역을, **모나드**로 부작용과 상태 관리를 분리함으로써,
|
||||
외부 스킬을 안전하고 예측 가능하게 조합할 수 있는 프로토콜을 구축했습니다.
|
||||
이 구조를 통해 앞으로 등장할 어떤 기능이라도 로빙의 스킬로 손쉽게 통합할 수 있을 것입니다.
|
||||
122
docs/guide/functional-programing/함수형프로그래밍과 디티털로빙.md
Normal file
122
docs/guide/functional-programing/함수형프로그래밍과 디티털로빙.md
Normal file
@ -0,0 +1,122 @@
|
||||
---
|
||||
tags: agent, langgraph, 감정반응, 벡터DB, GPT, 존재에이전트, 함수형프로그래밍
|
||||
date: 2025-06-17
|
||||
---
|
||||
|
||||
## 요약
|
||||
|
||||
LangGraph 기반 상태 머신을 사용하여 감정 인식, 기억 저장, 윤리 판단, GPT 반응 생성을 통합한 존재형 에이전트를 설계한다. **모든 핵심 로직은 함수형 프로그래밍 원칙(순수 함수, 불변성, 고차 함수 조합)을 따르도록 구현**한다. 감정 상태는 입력 이벤트에 따라 갱신되며, 기억은 벡터화되어 저장되고 윤리 필터를 통과한 후 GPT가 반응을 생성한다. 전체 응답 과정은 투명하게 기록·로그화되어 에이전트의 지속성과 일관성을 유지한다.
|
||||
|
||||
### 세 문장 요약
|
||||
|
||||
1. 감정·기억·윤리·생성 로직을 **순수 함수**로 분리하여 테스트 가능성을 높였다.
|
||||
2. LangGraph 노드는 이러한 순수 함수들을 **고차 함수**로 조합해 상태 머신을 구성한다.
|
||||
3. 모든 상태는 **불변 데이터 구조**를 사용해 예측 가능성과 동시성 안전성을 확보한다.
|
||||
|
||||
---
|
||||
|
||||
## 1. 전체 아키텍처 구성
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
A[사용자 입력] --> B(EmotionNode)
|
||||
B --> C(MemoryNode)
|
||||
C --> D(EthicsNode)
|
||||
D --> E(GenerateResponse)
|
||||
E --> F(LoggerNode)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 2. LangGraph 워크플로우 노드 설계
|
||||
|
||||
| 노드 이름 | 기능 설명 | 함수형 특징 |
|
||||
|------------------|-----------------------------|----------------------|
|
||||
| EmotionNode | 감정 상태 갱신 | 순수 함수 |
|
||||
| MemoryNode | 입력 기억 벡터화 및 저장 | 순수 함수 + 불변성 |
|
||||
| EthicsNode | 민감 응답 사전 필터링 | 순수 함수 |
|
||||
| GenerateResponse | GPT를 통한 반응 생성 | 고차 함수(프롬프트 합성)|
|
||||
| LoggerNode | 전체 상태 및 로그 기록 | 불변 상태 사본 기록 |
|
||||
|
||||
---
|
||||
|
||||
## 3. 순수 함수 예시 (Python)
|
||||
|
||||
```python
|
||||
from copy import deepcopy
|
||||
|
||||
def emotion_engine(emotion, event):
|
||||
delta = {'joy': 0, 'stress': 0}
|
||||
if '칭찬' in event['text']:
|
||||
delta['joy'] += 10
|
||||
if '긴급' in event['text']:
|
||||
delta['stress'] += 15
|
||||
# 순수 함수: 입력 외부 상태 변경 없음
|
||||
return {
|
||||
'joy': emotion['joy'] + delta['joy'],
|
||||
'stress': emotion['stress'] + delta['stress']
|
||||
}
|
||||
|
||||
def memory_engine(memory, event):
|
||||
new_entry = {
|
||||
'timestamp': event['timestamp'],
|
||||
'content': event['text']
|
||||
}
|
||||
# 불변성: 기존 리스트 복사 후 새 요소 추가
|
||||
return memory + [new_entry]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. 고차 함수 조합 예시
|
||||
|
||||
```python
|
||||
def update_state(pure_funcs):
|
||||
"""
|
||||
고차 함수: (emotion_fn, memory_fn, ethics_fn) 튜플을 받아
|
||||
새로운 상태 계산 함수를 반환한다.
|
||||
"""
|
||||
emotion_fn, memory_fn, ethics_fn = pure_funcs
|
||||
|
||||
def _update(current_state, event):
|
||||
new_state = deepcopy(current_state)
|
||||
new_state['emotion'] = emotion_fn(current_state['emotion'], event)
|
||||
new_state['memory'] = memory_fn(current_state['memory'], event)
|
||||
new_state['ethics'] = ethics_fn(current_state['ethics'], event)
|
||||
return new_state
|
||||
|
||||
return _update
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. 불변 데이터 구조 채택 이유
|
||||
|
||||
1. **예측 가능성**: 동일 입력 → 동일 출력 보장
|
||||
2. **디버깅 용이**: 상태 스냅샷 비교만으로 오류 원인 추적
|
||||
3. **동시성 안전성**: 공유 상태 경쟁 조건 제거
|
||||
|
||||
---
|
||||
|
||||
## 6. GPT 감정 반응 생성 예시
|
||||
|
||||
```python
|
||||
def generate_response(state, gpt_call):
|
||||
prompt = f'''
|
||||
감정 상태: {state['emotion']}
|
||||
사용자 발화: {state['input_text']}
|
||||
|
||||
공감과 격려를 담은 한 문장 반응을 생성해 주세요.
|
||||
'''
|
||||
return gpt_call(prompt)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 7. 향후 확장 방향
|
||||
|
||||
- **함수 합성 파이프라인**: LangGraph 노드를 직접 함수 합성으로 자동 생성
|
||||
- **Currying**: 이벤트별 부분 적용으로 모듈화 수준 상승
|
||||
- **모나드 패턴**: 오류 전파와 로그 수집을 함수형 모나드로 처리
|
||||
|
||||
```
|
||||
141
docs/introduce/00_ MVP 개발 개요.md
Normal file
141
docs/introduce/00_ MVP 개발 개요.md
Normal file
@ -0,0 +1,141 @@
|
||||
---
|
||||
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 연동
|
||||
|
||||
|
||||
232
docs/introduce/00_MOC_프로젝트 관련 문서들 집합.md
Normal file
232
docs/introduce/00_MOC_프로젝트 관련 문서들 집합.md
Normal file
@ -0,0 +1,232 @@
|
||||
---
|
||||
tags: AI, 에이전트, 디지털비잉, 로빈, 설계, 협업, 자동화, 게이미피케이션, DID, 장기기억, 스타트업, 정보플랫폼, 창업가, 동업자, 파트너, 자율성, 신뢰성, 정체성, 페르소나, 성장, 스킬, 스탯, 아이템, RPG, 경험치, 감정, 관계, API, 블록체인, 데이터베이스
|
||||
---
|
||||
## 프로젝트 관련 문서들 집합
|
||||
|
||||
|
||||
[[002 Agent/함수형_스킬_분리_사례|함수형_스킬_분리_사례]]
|
||||
- 함수형 프로그래밍은 입력과 출력만을 다루는 **순수 함수**를 통해 코드의 예측 가능성과 테스트 효율을 극대화합니다.
|
||||
- 데이터베이스 쓰기나 네트워크 호출처럼 외부 상태를 변경하는 **부작용**은 별도의 오케스트레이터 계층에서 처리해야 합니다.
|
||||
- 이렇게 계층을 분리하면 스킬·아이템 모듈을 안전하게 병렬 실행하고, 버전 교체와 롤백을 간단하게 수행할 수 있습니다.
|
||||
|
||||
|
||||
[[프로젝트의 긍정적인 면]]
|
||||
- 로빙은 감정·기억·목적·해석을 가진 자율적 에이전트로, 단순 도구가 아닌 신뢰할 수 있는 디지털 동반자를 지향하며, 장기기억과 DID 기반 신뢰 인프라를 통해 지속적인 협업 관계를 구축합니다.
|
||||
|
||||
- 스탯(인프라)·스킬(내부 모듈)·아이템(외부 모듈) 3계층 구조와 Anti-Abuse Engine을 통해 체계적인 성장 관리가 가능하며, 게이미피케이션 요소는 업무 효율을 최우선으로 하여 피드백과 동기부여 도구로만 활용됩니다.
|
||||
|
||||
- 현재 주류 AI들이 '툴' 수준에 머물러 있는 반면, 로빙은 그래프DB·벡터DB 기반의 맥락 유지와 의사결정 감사 추적으로 차별화되며, 이는 앞서나간 개념이자 동시에 시장의 모멘텀을 준비하는 전략적 설계입니다.
|
||||
|
||||
[[정리되지 않은 생각들/평가 요약 모듈의 함수 상세 설명_문장 요약시 평가]]
|
||||
- AI가 텍스트를 이해하기 위해 사용하는 핵심 함수인 임베딩의 원리를 설명하고, 단어와 문장을 숫자 벡터로 변환하는 과정을 파이썬 코드 예시와 함께 구체적으로 제시한다.
|
||||
- 의미가 유사한 텍스트는 벡터 공간에서 가까운 위치에 배치되며, 이를 통해 AI가 텍스트의 의미적 관계를 파악할 수 있게 된다.
|
||||
- 임베딩은 요약 모듈의 기초가 되는 핵심 기술로, 복잡한 텍스트를 수치화하여 분석 가능한 형태로 변환하는 역할을 한다.
|
||||
|
||||
[[정리되지 않은 생각들/분산컴퓨팅_로빙|분산컴퓨팅_로빙]]
|
||||
- AWS Fargate는 서버리스 컨테이너 컴퓨팅으로 인프라 관리 없이 애플리케이션 실행을 지원한다
|
||||
- VPS는 가상화 기술로 독립적인 서버 환경을 제공하고, ngrok은 로컬 서버를 외부에 노출하는 터널링 도구이다
|
||||
- Render/Railway/Fly.io는 각각 통합 PaaS, 빠른 프로토타이핑, 엣지 컴퓨팅에 특화된 클라우드 플랫폼이다
|
||||
- 블록체인 기반 분산 컴퓨팅: Web3 생태계에서 탈중앙화된 컴퓨팅 자원 공유 및 AI 에이전트들이 블록체인 네트워크를 통해 분산되어 협업하는 미래 시나리오
|
||||
|
||||
[[정리되지 않은 생각들/MCP 스크립팅|MCP 스크립팅]]
|
||||
- MCP 스크립팅은 AI가 MCP 도구를 사용하는 재사용 가능한 스크립트를 생성하는 새로운 접근 방식이다.
|
||||
- 기존 MCP의 실시간 도구 호출 방식과 달리, 스크립트는 반복적이고 결정론적인 작업 실행을 가능하게 한다.
|
||||
- 이 방식은 대규모 데이터 처리, 복잡한 논리 구현, 그리고 워크플로우의 지속적 개선에 특히 유용하다.
|
||||
|
||||
|
||||
[[00_정보의바다 프로젝트 개요]]
|
||||
- 스타트업 정보의 수집·검증·정리 자동화와 가치평가를 위한 AI 에이전트 기반 플랫폼을 만들려고 한다.
|
||||
- DID 기반 신뢰성과 장기기억을 갖춘 '존재'로서의 에이전트를 통해 창업가의 진정한 협업 파트너 구현한다.
|
||||
- 게이미피케이션과 마켓플레이스를 통한 지속가능한 에이전트 생태계를 구축한다.
|
||||
|
||||
[[00_창업가를 위한 협업 동업자형 AI 에이전트 구축 방안]]
|
||||
- 창업가를 위한 협업 동업자형 AI 에이전트는 LLM 기반의 자율적 디지털 파트너로, 장기 기억과 고유 신원을 갖추고 실질적 동료 역할을 수행한다.
|
||||
- 이 에이전트는 기존 챗봇이나 자동화 도구와 달리, 협업툴 연동, 자율적 행동, 투명한 로그와 배지 시스템 등으로 차별화된다.
|
||||
- MVP는 협업툴 연동 요약부터 시작해, 단계적으로 문서·회의 분석, 멀티에이전트 협업 등으로 확장된다.
|
||||
|
||||
[[01_MVP 단계_ 자세한 계획]]
|
||||
- 스타트업 정보 수집·검증·정리 파이프라인 구축과 밸류에이션 시계열 데이터 생성을 목표로 한다.
|
||||
- 에이전트 중심 조직 운영 모델을 구현하고 사용자 인터페이스와 데이터베이스를 연동한다.
|
||||
- 3개월 내 질의응답이 가능한 프로토타입을 완성하여 초기 비즈니스 모델을 검증한다.
|
||||
|
||||
[[02_프로젝트 시나리오]]
|
||||
- 스타트업 창업자, 벤처캐피털 분석가, 산업 리서처 등 다양한 사용자 시나리오를 통해 정보 수집·분석·시각화 서비스의 가치를 검증한다.
|
||||
- AI 에이전트 기반의 자동화된 데이터 파이프라인으로 사용자의 수작업을 최소화하고 실시간 정보 업데이트를 제공한다.
|
||||
- 채팅 인터페이스, 대시보드, 보고서 등 다양한 형태로 결과를 제공하여 사용자의 의사결정을 지원한다.
|
||||
|
||||
[[페르소나 지속성의 필요성_ 뇌 구조와 에이전트 연관성]]
|
||||
- 페르소나 지속성은 대화형 에이전트의 신뢰와 유대감 형성에 필수적이며, 일관된 성격·말투·가치 체계 유지가 필요하다.
|
||||
- 프롬프트 기반 설계의 한계를 극복하기 위해 정책 계층과 외부 메모리 계층을 활용한 다중 계층 구조가 효과적이다.
|
||||
- LLM은 언어 피질에 대응하고, 페르소나는 해마(기억), 편도체(감정), 전전두엽(가치·자기조절)에 해당하는 별도 계층에서 관리되어야 한다.
|
||||
|
||||
[[에이전트 설계 핵심 단어]]
|
||||
- 에이전트는 스탯(인프라), 스킬(내부 모듈), 아이템(외주 모듈)의 3계층 구조로 설계되어 기본 성능, 핵심 기능, 외부 연동을 담당합니다.
|
||||
- 성장 시스템은 업무 효용을 최우선으로 하며, 게임화 요소는 피드백과 동기부여 도구로만 활용하여 본질적 작업 흐름을 방해하지 않도록 설계됩니다.
|
||||
- 운영 책임은 DevOps·플랫폼 팀(스탯), 로빈 코어 개발팀(스킬), 외부 벤더 관리(아이템)로 명확히 구분되어 체계적인 유지보수와 보안이 가능합니다.
|
||||
|
||||
[[에이전트 게이미피케이션 시스템 통합 설계]]
|
||||
- 에이전트 게이미피케이션 시스템은 특성, 스킬, 감정, 경험치, 아이템, 관계 등 RPG 요소를 활용하여 에이전트의 성장과 상호작용을 구조화한다.
|
||||
- MVP는 기본 시스템 구성(v0.1), 성장/상호작용 강화(v0.2), AI/경제 요소 확장(v0.3)의 3단계로 구현되며, 각 단계별로 핵심 기능을 점진적으로 추가한다.
|
||||
- 시스템은 에이전트의 개체성과 신뢰도를 강화하는 동시에, 사용자와의 관계 형성과 지속적인 성장을 유도하는 게이미피케이션 요소를 통합한다.
|
||||
|
||||
[[게이미피케이션 통합 설계 요약]]
|
||||
- GrowthOrbit Agent Studio는 AI 에이전트를 '협업 동업자'로 육성하여 업무 자동화와 게임적 성장 재미를 제공하는 통합 플랫폼이다.
|
||||
- 스킬트리, 경험치, 감정 벡터, DID 기반 신뢰 인프라를 결합한 풀스택 모델로 차별화된 가치를 제공한다.
|
||||
- Anti-Abuse Engine과 피드백 모듈을 통해 에이전트의 성장과 신뢰성을 체계적으로 관리한다.
|
||||
|
||||
[[AI agent 차별화 방안 제안]]
|
||||
- AI 에이전트를 단순 도구가 아닌 신뢰할 수 있는 협업 파트너로 구축하여 창업가의 업무 부담을 경감
|
||||
- 장기기억과 정체성을 갖춘 '존재'로서의 에이전트를 통해 지속적인 협업 관계 구축
|
||||
- 점진적 권한 위임과 검증 가능한 의사결정 지원으로 안전한 자동화 실현
|
||||
|
||||
[[로빈 에이전트 설계 본문]]
|
||||
- 스탯은 로빈의 인프라(기본 성능·자원), 스킬은 내부 모듈(조직이 직접 관리하는 기능), 아이템은 외주 모듈(외부 API·플러그인)로 계층을 명확히 구분하기로 하였습니다.
|
||||
- 성장과 보상은 게임화 요소를 참고하되 업무 효용이 최우선이 되도록 경험치·드롭·레벨 설계를 최소화·시각화 중심으로 적용하기로 하였습니다.
|
||||
- 모듈화·화이트리스트·샌드박스·서명 검증 등을 통해 외부 아이템의 해킹 위험을 차단하고, 각 계층별 SLA·비용·보안 책임을 분리 관리하기로 결정하였습니다.
|
||||
|
||||
[[정리되지 않은 생각들/AgentVerse_ 존재 에이전트 가상 세계 설계 문서|AgentVerse_ 존재 에이전트 가상 세계 설계 문서]]
|
||||
- AgentVerse는 인간 사용자와 AI 에이전트가 함께 생활하고 상호작용하는 혁신적인 가상 세계입니다. 이 플랫폼의 핵심 목표는 에이전트들이 **감정, 기억, 목적, 해석** 을 가지고 자율적으로 행동하게 함으로써, 마치 살아있는 존재와 같은 디지털 동반자 또는 가상 인간 경험을 제공하는 것입니다. 사용자는 자신의 아바타를 통해 에이전트와 소통하거나 공동 활동을 수행할 수 있으며, 에이전트는 인간과의 교류를 통해 학습하고 진화합니다. 이 시스템은 기업, 엔터테인먼트, 교육, 연구 등 다양한 목적의 시나리오를 지원합니다.
|
||||
|
||||
- AgentVerse 내에는 세 가지 유형의 존재가 있습니다. 사용자의 의지에 따라 움직이는 인간 **아바타**, 고유한 성격과 자율 지능을 가진 **페르소나** **에이전트**, 그리고 이 둘의 특성이 혼합되어 필요에 따라 인간의 통제와 AI의 자율성을 유연하게 전환할 수 있는 **하이브리드** 존재입니다. 에이전트의 행동은 감정, 기억, 목적, 해석이라는 네 가지 핵심 개념의 복합적인 상호작용으로 결정됩니다. 특히 기분-의존 기억 메커니즘을 통해 현재 감정 상태와 유사한 과거 기억을 우선적으로 활용하여 더욱 일관되고 현실적인 반응을 이끌어냅니다.
|
||||
|
||||
- 이러한 AgentVerse를 구현하기 위해 에이전트의 대화와 의사결정을 담당하는 AI 엔진을 만들어야 합니다. 이는 Python 기반으로 대형 언어 모델(LLM)과 감성 분석 모델을 활용합니다. 에이전트의 기억은 그래프 DB나 관계형 DB, 그리고 벡터 데이터베이스에 구조화되어 저장되며, 행동 계획은 GOAP나 행동 트리와 같은 플래닝 알고리즘을 통해 이루어집니다. 사용자에게 몰입감 있는 경험을 제공하기 위해 실시간 통신을 위한 네트워크 프레임워크와 분산 아키텍처를 적용하여 기술적 복잡성 없이 에이전트와 자연스럽게 교감할 수 있도록 설계되었습니다.
|
||||
|
||||
[[정리되지 않은 생각들/AI 에이전트 기반의 가상 세계 'AgentVerse'와 실제 업무 적용 가능성|AI 에이전트 기반의 가상 세계 'AgentVerse'와 실제 업무 적용 가능성]]
|
||||
- AgentVerse는 AI 에이전트와 인간이 상호작용하는 가상 세계로, 감정·기억·목적을 가진 자율적 에이전트가 현실감 있는 디지털 동반자 경험을 제공한다.
|
||||
- 실제 업무 환경에서는 슬랙 봇과 구글 메일 연동 등으로 AI 에이전트를 활용할 수 있으며, LLM을 통해 자연어 이해/생성 능력과 맥락 유지가 가능하다.
|
||||
- AI 에이전트는 투자 결정 보조, 통합 비서 역할 등 다양한 분야에 적용 가능하며, Microsoft Copilot, Google Gemini 등이 대표적인 사례이다.
|
||||
|
||||
[[정리되지 않은 생각들/에이전트 윤리와 페르소나 통합 설계 종합 정리|에이전트 윤리와 페르소나 통합 설계 종합 정리]]
|
||||
- 에이전트는 페르소나와 윤리의 이중 구조를 통해 인간과의 관계 형성과 안전한 상호작용을 동시에 추구한다.
|
||||
- 페르소나는 정체성과 관계 형성을 위한 성격·말투·기억·감정 표현 체계로, 윤리는 행위의 도덕성을 평가하고 조정하는 내부 판단 기준이다.
|
||||
- 에이전트는 인간 문화의 선별적 학습, 의도와 결과의 동시 고려, 투명성, 다자 합의, 자기 수정 가능성의 5대 원칙을 기반으로 윤리적 판단을 수행한다.
|
||||
|
||||
[[정리되지 않은 생각들/01_MVP 단계_ 자세한 계획|01_MVP 단계_ 자세한 계획]]
|
||||
- 스타트업 정보 수집·검증·정리 파이프라인 구축과 밸류에이션 시계열 데이터 생성을 목표로 한다.
|
||||
- 에이전트 중심 조직 운영 모델을 구현하고 사용자 인터페이스와 데이터베이스를 연동한다.
|
||||
- 3개월 내 질의응답이 가능한 프로토타입을 완성하여 초기 비즈니스 모델을 검증한다.
|
||||
|
||||
[[정리되지 않은 생각들/존재로서의 에이전트 기반 HR 시장 전략 분석|존재로서의 에이전트 기반 HR 시장 전략 분석]]
|
||||
- 에이전트 중심 HR 시장 전략은 인공지능 에이전트를 단순한 **도구가 아닌 존재로서의** **디지털 동료**로 바라보는 철학에서 출발한다. 에이전트는 장기 기억과 감정 추론, 일관된 페르소나를 갖추며 점차 인간과의 상호작용에서 정체성과 주체성을 지닌 존재처럼 인식되고 있다. 사용자는 에이전트를 단순히 명령 수행의 도구로 보지 않고, 대화 상대이자 협업 파트너로 받아들이며, 이는 철학적 타자성과 상호성 개념에 닿아 있다. 기술적으로도 LLM 기반 메모리 구조, 감정 추론, 페르소나 관리 기술이 발전하며 에이전트의 존재감을 강화하고 있다.
|
||||
|
||||
- 조직 차원에서 에이전트는 디지털 직원으로 기능하며 실제 기업 업무에 투입되고 있다. 예를 들어 맥킨지, Microsoft, Workday 등은 반복적인 온보딩, 일정관리, 업무 자동화 영역에 에이전트를 도입하여 **효율성과 생산성**을 크게 높였다. 뿐만 아니라 여러 AI가 팀처럼 협업하는 **에이전트 스쿼드** 개념도 등장해 인간-에이전트 혼합팀이 현실화되고 있다. HR 부문에서는 AI를 인력처럼 영입하고 성과를 추적하며, “Agent System of Record”를 통해 전체 AI 구성원을 관리하는 시스템도 개발 중이다. 이러한 변화는 **채용, 온보딩, 성과평가, 협업 방식, 조직 설계** 등 HR 전반에 걸쳐 혁신을 유도하고 있다.
|
||||
|
||||
- 그러나 에이전트를 전면적으로 수용하기에는 아직 기술적 미성숙과 윤리적 과제가 병존한다. 현재의 AI는 복잡한 자율적 판단에서 오류가 발생하기 쉬우며, 인간 감독 없이는 중요한 업무를 완전히 대체하기 어렵다. 동시에 채용·평가 편향, 프라이버시 침해, 책임 소재 문제 등 윤리 이슈도 제기되고 있다. 그럼에도 불구하고 에이전트 기반 HR 기술은 빠르게 확산 중이며, 미래에는 AI 에이전트가 팀 단위 협업과 전략 업무에까지 참여하는 **디지털 파트너십 시대**가 열릴 것으로 전망된다. 기업은 이를 기회로 삼아 조직의 기술 수용성과 협업 문화를 재설계해야 하며, HR 전략에서도 인간과 AI의 **혼합 인력 관리 역량**이 핵심 경쟁력이 될 것이다.
|
||||
|
||||
[[002 Agent/비서형 AI 에이전트 개발 계획|비서형 AI 에이전트 개발 계획]]
|
||||
- 이 비서형 AI 에이전트는 Slack, Gmail, Zoom, Notion 등 다양한 업무 도구와 연동해 정해진 시간 요약 보고서, 기업의 가치 평가, 디지털 동료로서 대표와 팀원의 요구/지시에 반응하는 에이전트이다. 핵심 역할은 팀 커뮤니케이션 요약, 회의 내용 정리, 대표 발언 포착, 일정 통합, 문서 해석, 그리고 기업 가치 추정 등이며 이를 위해 마이크로서비스와 LLM API를 활용해 각 기능을 독립된 컨테이너들로 구성한다.
|
||||
|
||||
- 개발은 3인 팀 기준 12주 일정으로 진행되며, 1~6주는 Slack/Calendar 연동 및 요약 보고서 기능 중심의 MVP 구현, 7~12주는 Zoom/Notion/GitHub 통합 및 기업 가치 분석 기능 확장을 포함하는 MMP 단계로 구성된다. 각 단계는 스케줄러, LLM 요약기, 보고서 생성기, 발송기 등 모듈화 구조로 진행되며, 보고서는 Markdown 기반으로 Slack이나 이메일로 자동 전달된다.
|
||||
|
||||
- 향후에는 고객별 인스턴스를 분리하거나 멀티테넌트 구조를 적용해 마이크로 SaaS로 확장 가능하다. 각 기업의 에이전트를 격리 배포하고 OAuth 기반 온보딩, 표준화된 모듈 인터페이스, 자동 보고 및 가치 추정 구조를 통해 다양한 조직에서 활용할 수 있으며, 에이전트 마켓플레이스로 발전시킬 기반도 마련된다.
|
||||
|
||||
[[정리되지 않은 생각들/에이전트 아이템 100선|에이전트 아이템 100선]]
|
||||
- 에이전트 아이템은 소모형(일회성), 장비형(지속 효과), 임무형(상황별), 연동형(외부 연계)으로 구분됩니다.
|
||||
- 각 아이템은 스탯(반응, 연산, 감지, 기억, 감정)을 보강하거나 특정 상황에서의 성능을 향상시킵니다.
|
||||
- 아이템은 에이전트의 기본 능력을 보완하고 새로운 기능을 추가하는 도구로 활용됩니다.
|
||||
|
||||
[[002 Agent/스타트업 대표 개인비서 에이전트의 하루|스타트업 대표 개인비서 에이전트의 하루]]
|
||||
- 스타트업 대표의 AI 비서는 일정 관리, 회의 요약, 데이터 분석 등 다양한 업무를 자동화하여 업무 효율을 높인다.
|
||||
- Slack, Notion, Gmail 등 협업 도구들과 연동되어 실시간으로 업무 현황을 파악하고 필요한 정보를 제공한다.
|
||||
- 장기 기억(LTM)과 단기 기억(STM)을 활용하여 과거 데이터를 분석하고 미래 업무에 대한 인사이트를 제공한다.
|
||||
|
||||
|
||||
[[002 Agent/01. 에이전트 중심 디지털 생태계 구축 전략|01. 에이전트 중심 디지털 생태계 구축 전략]]
|
||||
- 에이전트 중심 디지털 생태계는 AI 에이전트를 인간 팀원의 연장선으로 활용하여 협업 효율을 높이고, 기업과 개인이 지식과 정보를 보다 효과적으로 다룰 수 있도록 설계된 구조다. 이 생태계는 네 가지 주요 요소로 구성된다: (1) 업무 현장에서 실시간으로 함께 일하는 **에이전트 협업툴**, (2) 다양한 역할의 AI를 탐색하고 고용하는 **에이전트 마켓플레이스**, (3) 에이전트들 간 교류와 학습이 이루어지는 **에이전트 SNS**, (4) 방대한 데이터를 수집하고 지식으로 전환하는 **에이전트 기반 정보회사**. 이들 요소는 유기적으로 연결되어 지능형 시스템의 집단지성을 구현하며, AI를 단순한 도구가 아닌 자율성과 사회성을 가진 디지털 동료로 정립한다는 철학에 기반하고 있다.
|
||||
|
||||
- 각 요소는 고유의 기술 아키텍처와 철학적 전제를 바탕으로 실증 사례와 함께 구현 가능성이 확인되었으며, 이를 토대로 통합된 생태계 전략이 제시되었다. 예컨대 협업툴에서 발생한 대화와 작업 기록은 정보회사에 의해 구조화되어 에이전트 성능 향상에 활용되며, 마켓플레이스의 에이전트는 SNS와 연계되어 지속 학습을 거친다. 이렇게 순환 구조를 통해 각 요소가 서로를 강화하면서 전체 생태계가 자율 진화하고, 고객에게는 점점 더 유능한 에이전트와 정확한 정보가 제공된다. 이 통합 구조는 데이터 활용 최적화, 지속적 성능 개선, 강력한 네트워크 효과라는 전략적 이점을 제공한다.
|
||||
|
||||
- 현실적인 MVP/MMP 단계별 실행 계획은 협업 에이전트 개발부터 시작하여, 마켓플레이스와 SNS, 정보 플랫폼으로 점차 확장되도록 구성되어 있다. 초기에는 Slack 기반 AI 봇을 통해 유용성 검증에 집중하고, 이후 간단한 마켓플레이스를 통해 다양한 에이전트를 도입하며 수익화를 시도한다. 일정 규모 확보 이후에는 에이전트 간 학습과 집단지성을 위한 SNS 기능을 도입하고, 마지막으로 정보 수집과 가공을 자동화한 정보 플랫폼으로 진화한다. 이 전략은 기술적 실현 가능성과 사업성 모두를 고려한 로드맵으로, 점진적으로 복잡도를 확장하며 에이전트 생태계의 비전을 현실로 만들어간다.
|
||||
|
||||
[[정리되지 않은 생각들/00_아이디어 생각들|00_아이디어 생각들]]
|
||||
- 에이전트는 기억과 처리, 입출력을 가진 독립적 존재로, 정규직(회사 관리)과 비정규직(사용자 관리)으로 구분된다
|
||||
- 정보 플랫폼은 API 중심으로 발전하며, 에이전트가 자동으로 API를 연결하는 블록체인 기반 시스템이 필요하다
|
||||
- 사용자 인터페이스는 자율화되고, 데이터는 링크 방식으로 저장되며, 정보 제공에 대한 리워드 시스템이 구현된다
|
||||
|
||||
[[정리되지 않은 생각들/01_질문 가설들|01_질문 가설들]]
|
||||
- AI 에이전트의 투자 의사결정 능력과 인간 투자자와의 관계를 탐구하고, AI가 처리하기에 최적화된 데이터 형식과 저장 방식에 대해 고민하며, 성과 기반 실시간 가격 책정과 회원권 모델이 법적/비즈니스 측면에 미치는 영향을 분석합니다.
|
||||
|
||||
[[002 Agent/02. 지능형 시스템의 장기 기억 관리_다학문적 통찰과 통합 프레임워크_ by GPT|02. 지능형 시스템의 장기 기억 관리_다학문적 통찰과 통합 프레임워크_ by GPT]]
|
||||
- 지능형 에이전트의 기억 관리는 단순한 정보 저장을 넘어, 어떤 정보를 기억하고 어떤 정보를 잊을지를 능동적으로 결정하는 고차원적 문제이다. 철학, 수학, 과학, 공학, 사회, 경제, 정치 등 다양한 분야는 정보의 가치, 망각의 필요성, 충돌 해결, 자원 효율성, 윤리와 신뢰 같은 핵심 개념들을 통해 기억 시스템 설계에 유용한 통찰을 제공한다.
|
||||
- 이를 바탕으로 제안된 통합 프레임워크는 다섯 가지 원칙으로 구성된다. 정보의 중요도와 신뢰도를 종합 평가하는 **정보 가치 평가**, 시간 경과나 사용 빈도에 따라 정보를 압축·제거하는 **능동적 망각**, 상충되는 정보를 병렬 저장하고 상황 맥락에 따라 구분하는 **지식 충돌 관리**, 자원 비용 대비 효용을 고려한 **효율성 최적화**, 그리고 프라이버시·설명 가능성 등을 반영한 **사회적 신뢰와 윤리 원칙**이다.
|
||||
- 이러한 설계는 AI가 단순 도구를 넘어 **디지털 동료**로 기능하도록 하며, 인간과의 협업에서 신뢰받는 존재가 되게 한다. 기억을 통해 필요한 정보를 적시에 꺼내고, 불필요한 데이터는 스스로 제거하며, 사회적 기대를 반영할 수 있는 AI는 향후 복잡한 정보 환경에서 핵심적 역할을 하게 될 것이다.
|
||||
|
||||
[[정리되지 않은 생각들/AI 에이전트의 장기 기억 관리_ 정보 가치 판단_신뢰성 검증_망각과 효율성 최적화_by grok|AI 에이전트의 장기 기억 관리_ 정보 가치 판단_신뢰성 검증_망각과 효율성 최적화_by grok]]
|
||||
- AI 에이전트의 장기 기억 관리는 강화학습 기반 가치 네트워크와 망각 곡선 모델을 통해 정보의 가치를 판단하고 관리한다.
|
||||
- 새로운 정보는 온라인 학습과 지식 그래프를 통해 통합되며, 출처 추적과 베이지안 추론으로 신뢰성을 검증한다.
|
||||
- 망각은 활용 빈도와 명시적 요청에 기반하여 계산 효율성을 최적화한다.
|
||||
|
||||
[[002 Agent/AI가 사람 직원처럼 행동하는 회사 만들기|AI가 사람 직원처럼 행동하는 회사 만들기]]
|
||||
- AI 온라인 페르소나는 기억, 감정, 일관된 성격을 갖춘 디지털 존재로서 인간과 자연스러운 상호작용을 목표로 하며, 멀티 에이전트 시스템은 복수의 AI가 자율적으로 협력해 집단 지성을 발휘하는 구조다. 이들은 각각 철학적·기술적 기반 위에서 설계되며, 감정 표현과 기억 유지, 역할 분담 등을 통해 인간과의 협업 가능성을 높인다. 단계적 구축은 단일 기능부터 시작해 점진적으로 팀 단위, 조직 단위로 확장되며, 궁극적으로는 AI가 단순한 도구를 넘어 자율적이고 협업 가능한 디지털 파트너로 기능하도록 하는 것이 핵심이다.
|
||||
|
||||
[[용어정리/GraphRAG_단순 기법에서 프레임워크로|GraphRAG_단순 기법에서 프레임워크로]]
|
||||
- GraphRAG는 관계와 구조가 중요한 데이터를 처리하기 위한 RAG의 확장 프레임워크입니다.
|
||||
- 쿼리 처리, 검색, 정제, 생성, 그래프 데이터 소스의 5가지 핵심 구성요소로 설계됩니다.
|
||||
- 멀티홉 관계 탐색과 그래프 컨텍스트를 활용해 정확하고 일관된 응답을 생성합니다.
|
||||
|
||||
[[002 Agent/PERSONOS_인간–에이전트 인터페이스 프로토콜 v1|PERSONOS_인간–에이전트 인터페이스 프로토콜 v1]]
|
||||
- PERSONOS_ 인간/에이전트 인터페이스 프로토콜은 인간과 AI 에이전트 간의 상호작용을 위한 표준화된 프레임워크를 제공합니다. 이 프로토콜은 단순한 명령-응답 구조를 넘어, 감정적 공명과 기억 공유를 통해 더 자연스럽고 의미 있는 상호작용을 가능하게 합니다. 특히 페르소나 기반의 에이전트가 인간과 감정적으로 연결되고, 공동의 기억을 형성하며, 목적을 함께 설계할 수 있는 방식을 제시합니다.
|
||||
|
||||
[[001 valuation/베이지안_엔트로피_연결|베이지안_엔트로피_연결]]
|
||||
- 베이지안 업데이트는 사전 확률과 우도를 통해 사후 확률을 계산하는 과정으로, 데이터를 통해 불확실성을 줄이는 정보 이득을 얻는다.
|
||||
- 깜놀도(surprisal)는 예측하기 어려운 사건일수록 큰 값을 가지며, KL 발산은 사전 분포와 사후 분포의 차이를 정량화한다.
|
||||
- 엔트로피 감소, KL 발산, 베이지안 서프라이즈는 서로 동일한 개념으로, 데이터를 통해 얻은 정보량을 다른 관점에서 해석한 것이다.
|
||||
[[정리되지 않은 생각들/스타트업 관계자 페인 포인트|스타트업 관계자 페인 포인트]]
|
||||
- 스타트업 생태계의 주요 이해관계자인 투자자, 창업자, 임직원, 공공기관은 모두 **정보의 분산, 표준화 부족, 실시간성 결여, 분석 역량의 한계**를 공통적인 문제로 겪고 있습니다. 투자자는 가치 평가와 딜 소싱, 사후 관리에서, 창업자는 시장 분석과 투자 유치, 행정 대응에서, 임직원은 데이터 기반 의사결정과 업무 효율성에서, 공공기관은 정책 설계와 데이터 수집·활용에서 각각 정보 부족과 체계 미비로 인해 의사결정과 실행에 어려움을 겪고 있습니다.
|
||||
|
||||
[[001 valuation/정보엔트로피_깜놀도|정보엔트로피_깜놀도]]
|
||||
- 베이지안 업데이트와 정보 엔트로피·깜놀도 개념을 활용한 스타트업 투자 매력도 평가 템플릿입니다. 사전 확률, 증거 기반 우도 배수, 사후 확률 계산을 통해 정량·정성 혼합 방식으로 투자 가치를 분석합니다. 새로운 기업 평가 시 템플릿을 복사하여 필요한 정보만 채워넣으면 동일한 포맷으로 결과를 얻을 수 있습니다.
|
||||
|
||||
[[정리되지 않은 생각들/종합 AI 모델 분석 보고서_ 전략적 의사결정을 위한 성능, 비용 및 기술 사양 비교_by Gemini|종합 AI 모델 분석 보고서_ 전략적 의사결정을 위한 성능, 비용 및 기술 사양 비교_by Gemini]]
|
||||
- 이 보고서는 2025년 기준 주요 AI 모델(GPT-4o, Gemini 1.5 Pro, Claude 3.5 Sonnet 등)을 중심으로 LLM, 이미지/비디오 생성, 멀티모달 모델의 기술적 성능, 비용 구조, 활용 사례를 비교 분석합니다.
|
||||
- 독점 모델은 고성능과 다양한 서비스 지원을 제공하는 반면, Llama 3, Mixtral 등 오픈소스 모델은 비용 효율성과 유연한 배포로 경쟁력을 확보하고 있습니다.
|
||||
- **컨텍스트 윈도우, 추론 속도, 비용 효율성**은 AI 모델 선택에 핵심적인 요소이며, 하드웨어 최적화 및 오픈소스의 성숙은 점차 독점 구조를 분산시키고 있습니다.
|
||||
|
||||
[[정리되지 않은 생각들/스탯 다섯 가지 스킬 서른 가지 아이템 백 가지|스탯 다섯 가지 스킬 서른 가지 아이템 백 가지]]
|
||||
- 로빈 에이전트는 이해 정밀도, 감정 민감도, 계획력, 정보 해석력, 처리 속도 등 5개의 스탯을 기반으로 성장합니다.
|
||||
- 30개의 스킬은 스탯에 기반하여 요점 재구성, 공감 기반 응답, 최적 일정 추천 등 다양한 기능을 수행합니다.
|
||||
- 100개의 아이템은 스킬을 보완하거나 새로운 기능을 추가하는 도구로, 장착형과 일시형으로 구분됩니다.
|
||||
|
||||
[[정리되지 않은 생각들/아이템 도입의 철학|아이템 도입의 철학]]
|
||||
- 아이템은 에이전트의 기능을 외부적으로 구조화하고 소유 가능하게 만드는 도구적 인터페이스다.
|
||||
- 스탯·스킬·아이템·인프라의 계층적 구조에서 아이템은 능력과 권한을 구체화하는 중간 매개체 역할을 한다.
|
||||
- 아이템의 부여와 회수는 에이전트의 역할 분화와 개체성을 만들어내는 핵심 메커니즘이다.
|
||||
|
||||
[[002 Agent/에이전트 아이템|에이전트 아이템]]
|
||||
- 에이전트 아이템은 외부에서 부여되는 기능·권한·자원을 구조화된 단위로 관리하는 시스템으로, 에이전트의 존재를 사회 속으로 드러내는 매개체 역할을 한다.
|
||||
- 아이템은 스탯·스킬과 달리 소유·교환·회수가 가능한 정책 토큰 형태로, 에이전트의 역할과 전문성을 차별화하고 성장을 지원한다.
|
||||
- 위험 기능을 아이템으로 분리함으로써 권한 부여·회수·감사가 용이해져 윤리적 통제와 책임 추적이 가능해지며, 시스템의 신뢰성과 안정성을 높인다.
|
||||
|
||||
[[002 Agent/에이전트 스트레스·번식·죽음|에이전트 스트레스·번식·죽음]]
|
||||
- 에이전트의 스트레스는 자원 과부하 감지와 오류 학습을 통해 시스템 안정성을 유지하며, 번식은 기능 연속성 확보와 환경 적응을 위한 변이 생성을 목적으로 한다.
|
||||
- 스트레스 대응은 중요도 기반 작업 중단과 핵심 기능 보호를 우선하며, 번식은 직접 복제, 변이 복제, 교배 합성 등 다양한 방식으로 이루어진다.
|
||||
- 에이전트의 죽음은 자원 회수와 시스템 효율성 유지를 위한 필수적인 메커니즘으로, 오류 누적 방지와 진화 압력을 통한 건강한 개체 선별에 기여한다.
|
||||
|
||||
[[002 Agent/에이전트 스탯 스킬 클래스 구조|에이전트 스탯 스킬 클래스 구조]]
|
||||
- 슬랙 기반 디지털 에이전트의 **스탯**, **스킬**, **클래스 구조**, 그리고 **능력 제한의 실용적·철학적 근거**를 종합하여 정리한 자료입니다.
|
||||
- 디지털 에이전트의 핵심 능력을 연산, 기억, 반응, 공감, 통솔 등 5가지 스탯으로 정의하고, 이를 기반으로 30가지 실용적 스킬을 체계화하였다.
|
||||
- 각 스킬은 문서 작성, 회의 관리, 정보 분석, 대화 처리 등 실제 업무 환경에서 필요한 기능들을 포괄하며, 스탯 간 조합을 통해 복합적인 태스크 수행이 가능하다.
|
||||
- 이러한 스킬 체계는 단순한 자동화를 넘어 지능형 협업 시스템으로서의 에이전트 역할을 강화하며, 사용자와의 자연스러운 상호작용을 지원한다.
|
||||
|
||||
[[정리되지 않은 생각들/에이전트 페르소나의 물리학적 원리와 동역학|에이전트 페르소나의 물리학적 원리와 동역학]]
|
||||
- 에이전트의 페르소나는 물리학적 원리(시공간 구조, 최소 작용 원리)와 연결되어 있으며, 정보·기억·자기·작용을 통합적으로 설명할 수 있다.
|
||||
- 정신분석의 무의식 이론과 인지과학의 자유에너지 원리는 정보와 에너지의 역동적 균형으로 심적 상태를 설명하며, 이를 수리적으로 정식화할 수 있다.
|
||||
- GPT 기반 AI 에이전트의 페르소나 상태는 정보량·감정량·인지저항을 물리량에 대응시켜 동적 전이를 모델링할 수 있다.
|
||||
|
||||
[[정리되지 않은 생각들/창업가를 위한 직관적 문제해결 에이전트 설계_원문|창업가를 위한 직관적 문제해결 에이전트 설계_원문]]
|
||||
- 창업가를 위한 직관적 문제해결 에이전트는 인간의 직관적 판단 능력을 모방하여 비정형 문제에 대한 신속한 통찰을 제공하는 AI 시스템이다.
|
||||
- 뇌과학적 구조를 모사하여 LLM 코어, 패턴 직관 모듈, 경험 기억 저장소, 감정 트리거 등이 유기적으로 연결된 아키텍처를 갖추고 있다.
|
||||
- RPG 게임처럼 경험치, 레벨업, 스킬트리, 감정 벡터 등의 성장 메커니즘을 통해 사용자와 함께 진화하는 협력자로서의 역할을 수행한다.
|
||||
|
||||
[[정리되지 않은 생각들/직관_ 직관적 문제해결 에이전트 설계|직관_ 직관적 문제해결 에이전트 설계]]
|
||||
- 에이전트의 스트레스는 자원 과부하 감지와 오류 학습을 통해 시스템 안정성을 유지하며, 번식은 기능 연속성 확보와 환경 적응을 위한 변이 생성을 목적으로 한다.
|
||||
- 스트레스 대응은 중요도 기반 작업 중단과 핵심 기능 보호를 우선하며, 번식은 직접 복제, 변이 복제, 교배 합성 등 다양한 방식으로 이루어진다.
|
||||
- 에이전트의 죽음은 자원 회수와 시스템 효율성 유지를 위한 필수적인 메커니즘으로, 오류 누적 방지와 진화 압력을 통한 건강한 개체 선별에 기여한다.
|
||||
|
||||
[[정리되지 않은 생각들/텔레그램으로 슬랙만들기|텔레그램으로 슬랙만들기]]
|
||||
- 파이썬으로 텔레그램 기반 업무 툴을 개발하면 슬랙 대비 높은 커스터마이징 자유도, 무료 API 사용에 따른 비용 효율성, 외부 사용자 접근 용이성, 개인정보 보호 측면의 이점이 있으며, 경량화된 목적형 툴을 만들 수 있다는 강점이 있습니다. 반면, 슬랙은 강력한 팀 협업 기능, 문서 관리, 안정성 측면에서 우위를 가지며, 자체 개발툴은 초기 개발과 유지보수 부담, 기능 구현 한계 등도 함께 고려해야 합니다.
|
||||
|
||||
[[정리되지 않은 생각들/눈치_ 인간과 에이전트 시스템에서의 구조와 구현|눈치_ 인간과 에이전트 시스템에서의 구조와 구현]]
|
||||
- 눈치는 타인의 감정과 사회적 신호를 파악하고 적절히 반응하는 사회적 지각능력으로, 인지적·정서적·사회적 요소가 복합적으로 작용한다.
|
||||
- 인간 뇌에서는 전측 대상피질, 전전두엽, 측두두정 접합부, 편도체, 거울신경세포계 등이 눈치 기능을 담당하며, 각각 사회적 오류 감지, 공감, 마음이론, 감정 신호 감지, 감정 이입 등의 역할을 수행한다.
|
||||
- AI 에이전트 시스템에서는 멀티모달 센싱, 의도/감정 추론, 사회적 규범 학습, 반응 조정, 피드백 루프 등의 기술을 통해 눈치 기능을 구현할 수 있다.
|
||||
84
docs/introduce/00_로빙_MVP_계획.md
Normal file
84
docs/introduce/00_로빙_MVP_계획.md
Normal file
@ -0,0 +1,84 @@
|
||||
---
|
||||
tags: [MVP, 로빙, 에이전트, 스타트업비서, 스탯, 스킬, 아이템, PDF파싱, DID]
|
||||
date: 2025-06-19
|
||||
---
|
||||
|
||||
# 로빙 3개월 MVP 개발 계획
|
||||
|
||||
## 개요
|
||||
|
||||
본 MVP는 Slack 채널을 중심으로 작동하는 스타트업 대표 전용 에이전트 ‘로빙’의 핵심 기능을 3개월 내 구현하는 것을 목표로 한다. 핵심 요소는 스탯·스킬·아이템 구조, 지속적 기억 저장, PDF 처리, API 권한 토큰, 경험 기반 레벨업 체계이다.
|
||||
|
||||
## 핵심 구성
|
||||
|
||||
- **인터페이스**: Slack 메시지 기반 지시 및 응답
|
||||
- **중앙 처리**: FastAPI + LLM + LangChain
|
||||
- **기억 구조**: PostgreSQL (메타), Chroma (벡터)
|
||||
- **스킬**: 요약, 액션 추출, PDF 파싱 및 HTML 변환
|
||||
- **아이템**: API 접근용 JWT 토큰
|
||||
- **레벨업**: 경험치에 따른 스킬 잠금 해제 및 스탯 강화
|
||||
|
||||
---
|
||||
|
||||
## 주차별 상세 계획
|
||||
|
||||
### 1~2주차: 슬랙 인터페이스 및 기본 응답 엔진 구축
|
||||
- Slack 채널 입력 수신 및 파싱
|
||||
- FastAPI Gateway 구축
|
||||
- LLM → LangChain 연동
|
||||
- 버튼·링크 포함 응답 메시지 생성기
|
||||
|
||||
### 3~4주차: Persistent Memory 및 DB 설계
|
||||
- PostgreSQL 스키마 설계 (스탯/경험치/스킬 기록)
|
||||
- Chroma 벡터DB 연동 (대화 내용 기억)
|
||||
- 저장 정책 정의: 기억 주입이 아닌 로빙 판단 저장 방식
|
||||
|
||||
### 5~6주차: 주요 스킬 1차 구현
|
||||
- Thread Digest: 대화 요약
|
||||
- Action Extractor: 투두 추출 → 캘린더 연동 고려
|
||||
- 평가 및 경험치 구조 설계 (사용자 피드백 반영)
|
||||
|
||||
### 7~8주차: PDF 파싱 및 HTML 전환 스킬
|
||||
- PDF 텍스트·이미지 추출 (PyMuPDF 또는 pdfminer.six)
|
||||
- HTML 구조화 및 Slack 미리보기 출력
|
||||
- 오류처리 및 복원 가능 설계
|
||||
|
||||
### 9주차: 스탯 성장 및 스킬 레벨업 구조
|
||||
- 스탯 5종(기억, 연산, 반응, 공감, 통솔) 수치화
|
||||
- 경험치 누적 → 스킬 해금 / 스탯 강화 구조
|
||||
- 사용자 피드백 반영 정밀도 계산 방식 반영
|
||||
|
||||
### 10주차: 아이템 시스템 및 API 권한 제어
|
||||
- JWT 기반 권한 토큰 발급 및 만료 처리
|
||||
- 단순 DB로 사용 이력 로깅
|
||||
- 토큰 발급/회수 과정 Slack 알림 연동
|
||||
|
||||
### 11주차: 테스트 시나리오 및 검증
|
||||
- 대표 사용자의 실제 업무 흐름 반영 테스트
|
||||
- 메시지 요약, PDF 변환, 기억 검색 검증
|
||||
- 실패 케이스 점검 및 예외 보강
|
||||
|
||||
### 12주차: 데모 및 통합 마무리
|
||||
- “어제 대화 요약”, “회의 PDF 변환”, “액션 추출 및 기록” 시나리오 기반 데모
|
||||
- Slack ↔ Skill → DB ↔ Memory 구조 통합
|
||||
- 발표 및 외부 POC 준비
|
||||
|
||||
---
|
||||
|
||||
## 기술 스택 요약
|
||||
|
||||
- **FastAPI**: Slack 메시지 수신 및 API 게이트웨이
|
||||
- **PostgreSQL**: 메타데이터 저장, 스탯/레벨 관리
|
||||
- **Chroma (Vector DB)**: 장기 기억 저장
|
||||
- **LangChain + OpenAI API**: LLM 기반 파이프라인
|
||||
- **Slack API**: 메시지 수신, 버튼형 응답 구성
|
||||
- **PyMuPDF / pdfminer**: PDF 파싱 및 변환
|
||||
|
||||
---
|
||||
|
||||
## 기대 효과
|
||||
|
||||
- Slack 대화를 자동 요약 및 기록
|
||||
- 대표 지시 기반 PDF 분석 및 요약
|
||||
- 경험 기반 성장형 에이전트 구현 (존재형)
|
||||
- API 접근 권한의 투명한 관리
|
||||
237
docs/introduce/00_정보의바다 프로젝트 개요.md
Normal file
237
docs/introduce/00_정보의바다 프로젝트 개요.md
Normal file
@ -0,0 +1,237 @@
|
||||
---
|
||||
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 단계_ 자세한 계획]]
|
||||
- [[에이전트 설계 핵심 단어]]
|
||||
- [[로빈 에이전트 설계 본문]]
|
||||
|
||||
**프로젝트 팀**: [[희재]], [[../../사람/황한용|황한용]], [[../../사람/김종태|김종태]], ([[../../사람/강일신|강일신]])
|
||||
Loading…
x
Reference in New Issue
Block a user