# 스트림 데이터 MD/위키 통합 지식베이스 및 사업화 리서치

> 출처: Gemini 대화 (2026-03-20)
> 성격: 데이터 아키텍처 구상 + 사업화 타당성 검토

---

## 1. 핵심 아이디어: 스트림 데이터 → MD → Postgres → 위키

모든 정보(슬랙, 이메일, 뉴스 등)를 `.md`로 표준화하여 NAS에 저장하고 Postgres에 동기화하면, 파편화된 정보가 하나의 **개인 지식 베이스**로 통합된다.

### 인제션 흐름

```
[Slack/Email/News API] → [Python Worker] → [LLM Summary] → [NAS (.md)] → [Postgres (Vector/Graph)]
```

### 소스별 프론트메타 설계

**슬랙:**
```yaml
---
source: "slack"
channel: "dev-robeing"
participants: ["user_A", "user_B"]
thread_id: "p1701234567"
summary: "RAG 시스템 인덱싱 오류 해결 방안 논의"
---
```

**이메일:**
```yaml
---
source: "gmail"
from: "partner@company.com"
subject: "2026년 협력 계약서 초안"
has_attachment: true
original_link: "https://mail.google.com/..."
---
```

**뉴스/RSS:**
```yaml
---
source: "tech-news"
category: "AI/LLM"
url: "https://news-site.com/article1"
importance: 4
---
```

---

## 2. 가치 판단: 3단계 필터링

### 1단계 — 정적 필터링 (비용 제로)
- 길이 제한: 본문 10자 미만 제외
- 형식 체크: 이미지/이모지만 있는 메시지 제외
- 화이트리스트: 특정 중요 인물/채널은 무조건 통과

### 2단계 — LLM 기반 판단 (저비용 모델 활용)
- 정보의 유효기간: "내일도 의미 있는가?"
- 실행 가능성: "To-do나 의사결정이 포함되어 있는가?"
- 지식 밀도: "새로운 정보나 기술적 해결책이 포함되어 있는가?"

### 3단계 — 관계 중심 필터링 (Graph Centrality)
- 연결성: 진행 중인 프로젝트/관심 태그와 관련 있는가?
- 중요도 전이: 이미 '중요'한 문서에서 파생된 정보인가?

### 가치 점수 시스템
```yaml
---
source: "slack"
value_score: 85
reason: "프로젝트 아키텍처 결정 사항 포함"
priority: "high"
---
```

---

## 3. 프롬프트 DB화와의 시너지

### 핵심 시너지 4가지
1. **맞춤형 프롬프트 라우팅** — 소스 유형에 따라 적절한 프롬프트 자동 선택
2. **Few-shot 예제 자동화** — 성공적 [질문-검색-답변] 세트를 DB에 저장, 유사 질문 시 자동 삽입
3. **버전 관리 & A/B 테스트** — v1_꼼꼼한_분석 vs v2_빠른_요약 비교 운영
4. **프롬프트도 데이터** — 어떤 프롬프트가 어떤 문서에 가장 효과적이었는지 연결

### 프롬프트 DB 스키마 (참고)
| 컬럼 | 타입 | 설명 |
|------|------|------|
| name | String | 고유 이름 (예: contract_analysis) |
| version | Integer | 프롬프트 버전 |
| template | Text | 실제 프롬프트 (변수는 `{{text}}`) |
| input_type | String | 적용 대상 (Slack, News, PDF 등) |
| params | JSONB | Temperature, 모델명 등 설정값 |
| success_rate | Float | 성공률 (사용자 피드백 기반) |

### MD 관리 하이브리드 방식
- **Source of Truth**: NAS의 MD 파일
- **DB**: 에이전트가 빠르게 읽기 위한 고속 캐시
- 파일 변경 감지 워커가 Postgres `prompts` 테이블 자동 업데이트

---

## 4. Skill.md 트렌드 (Prompts as Code)

에이전트의 '능력(Skill)' 자체를 모듈화하여 관리하는 추세.

### 특징
- 인간과 AI의 공용 인터페이스 (마크다운 = 사람 읽기 편함 + LLM 구조 파악 최적)
- PromptOps: Git diff로 프롬프트 변경 이력 추적
- 에이전트가 skill.md를 직접 읽어서 자신의 능력 판단

### 스킬 파일의 표준 구조
| 항목 | 설명 |
|------|------|
| Name & Version | 고유 명칭 + 버전 (YAML Frontmatter) |
| Description | 에이전트가 이 스킬을 언제 쓸지 판단하는 기준 |
| Input/Output Schema | 데이터 입출력 형식 명시 |
| Few-shot Examples | 대표 성공 사례 |
| Constraint | 제약 사항 |

---

## 5. 위키 통합 시너지

### 핵심 가치
- **공통 분모**: 에이전트와 사용자가 같은 곳을 바라보는 거울
- **스킬 가시화**: 에이전트의 능력치 매뉴얼 = 위키 카테고리
- **맥락의 시각화**: 문서 간 링크 = 그래프 관계의 시각적 표현
- **Goose Council 기반**: 여러 AI 모델 결과물 비교 분석 가능

### 선순환 구조
```
Ingestion → Synthesis(AI 요약) → Connection(Graph) → Feedback(사용자 수정) → Evolution(skill.md 업데이트)
```

---

## 6. 슬랙 정보화 파이프라인 상세

### 4단계 흐름
1. **캡처**: Slack Events API/Webhook → user_id(누가), ts(언제), text(무엇), thread_ts(맥락)
2. **가치 판단**: skill.md 기반 프롬프트 호출 → 점수화
3. **MD 표준화**: 프론트메타 + 요약문으로 파일 생성
4. **DB 연결**: RDB(메타데이터) + Vector(임베딩) + Graph(관계)

### 정보화된 MD 예시
```markdown
---
id: "slack_1701234567"
type: "slack_knowledge"
author: "전영준(Ted)"
timestamp: "2026-03-20 14:00"
channel: "#dev-ai-agent"
tags: ["postgres", "graph_db", "architecture"]
original_link: "https://workspace.slack.com/archives/..."
value_score: 92
---

# 요약: PostgreSQL 내 그래프 DB 도입 결정
- **핵심 내용:** Apache AGE 사용하여 RDB와 Graph 통합하기로 결정
- **결정 이유:** 데이터 싱크 오버헤드 감소, 쿼리 복잡도 저감
- **후속 조치:** 다음 주까지 PoC 스키마 설계 완료 예정
```

---

## 7. 사업화 검토

### 밸류 프로포지션
1. **투명성**: 위키(.md) 중간 단계로 AI의 이해를 확인/수정 가능 → 블랙박스 RAG와 차별화
2. **데이터 주권**: 로컬 NAS/서버 설치 → 금융, 공공, 의료, 제조 분야 적합
3. **비용 효율**: 통합 Postgres로 인프라 유지비 절감

### 비즈니스 모델
| 모델 | 대상 | 수익원 |
|------|------|--------|
| Enterprise On-prem | 대기업, 보안 민감 그룹 | 구축비 + 연간 유지보수 + 커스텀 에이전트 |
| B2B SaaS (Private) | 스타트업, 중소기업 | 월 구독료 (인당/용량당) |
| Personal Brain | 전문직, 1인 개발자 | 개인용 라이선스 (Self-hosted) |

### 킬러 기능 후보
- 자동 위키 생성기: 슬랙 대화 → 30초 내 의사결정 요약 위키 페이지
- 프롬프트 마켓플레이스: skill.md 거래 플랫폼
- Goose Council 모드: 멀티 모델 토론 → 최선의 결론 도출

---

## 8. 핵심 비판 (사업적 급소 4가지)

### 비판 1: 요약의 함정 (Hallucination Loop)
- AI 요약 시 뉘앙스/디테일 유실
- 잘못된 요약을 '진실'로 믿는 위험
- AI가 자신의 잘못된 요약을 재학습하는 피드백 루프
- **대응**: Traceability — 위키 문장에서 원본(슬랙/메일) 특정 지점으로 즉시 점프

### 비판 2: 협업 권한(RBAC)의 지옥
- 슬랙 채널/이메일마다 권한이 다름
- 통합 Postgres + 공용 위키에서 "누가 이 정보를 볼 권한이 있는가?" 제어 난제
- 민감한 메일 요약이 일반 사원에게 노출되면 사업 종료
- **대응**: Local-Only Encryption + 프론트메타 기반 태깅 + PostgreSQL RLS

### 비판 3: MD 파일의 물리적 한계
- 다수 에이전트가 동시에 skill.md를 읽고/수정할 때 파일 I/O 병목
- 파일 시스템은 DB만큼 동시성 제어에 능숙하지 않음
- **대응**: Hybrid Sync — 로컬 편집은 파일, 대규모 추론은 인메모리 DB

### 비판 4: Feature vs. Product
- Notion Connected AI, Slack AI 요약, Microsoft Recall 등 빅테크 내재화
- 단순 '정보 연결'은 빅테크가 가장 잘하는 영역
- **대응**: Multi-Model Competition — 특정 모델 비종속, Goose Council식 중립 지능 플랫폼

---

## 9. RBAC 구현 전략

### 프론트메타 기반 데이터 태깅 (인제션 단계)
```yaml
---
source: "slack"
original_channel: "C12345"
access_control:
  groups: ["dev-team", "admin"]
  users: ["user_a", "user_b"]
  level: "internal"  # public, internal, private, confidential
---
```

### PostgreSQL RLS 활용 (검색 단계)
```sql
SELECT * FROM documents
WHERE (access_groups && ARRAY['user_current_group'])
AND embedding <=> '[question_vector]' < 0.5
LIMIT 5;
```
→ 에이전트는 질문자가 볼 수 있는 데이터만 접근

### 지식 격리 아키텍처
- **Public/Team Wiki**: 공유 기술 문서 (아웃라인 동기화)
- **Private Vault**: 개인 이메일, DM (본인만 접근)
- 에이전트는 질문자 권한에 따라 공용/개인 DB 동시 검색

### RBAC 주의사항
| 항목 | 리스크 | 해결 |
|------|--------|------|
| 권한 동기화 | 슬랙 채널 멤버 변경 시 | Slack API로 주기적 권한 매핑 업데이트 |
| 요약본 노출 | 제목/요약에 민감 정보 | 요약 시 PII 마스킹 프롬프트 강제 적용 |
| 상속 권한 | 상위 폴더 → 하위 미전파 | Graph DB(AGE)로 권한 상속 Hierarchy 쿼리 |