docs: 스트림데이터 MD/위키 통합 지식베이스 사업화 리서치 추가
Gemini 대화 기반 — 인제션 아키텍처, 가치 판단 필터링, 프롬프트 DB 시너지, 위키 통합, 사업화 검토, 핵심 비판 4가지, RBAC 구현 전략 정리 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
parent
13d3a0b42e
commit
e8ab0d2ba7
251
journey/research/260320_스트림데이터_MD위키_통합_지식베이스_사업화_리서치.md
Normal file
251
journey/research/260320_스트림데이터_MD위키_통합_지식베이스_사업화_리서치.md
Normal file
@ -0,0 +1,251 @@
|
||||
# 스트림 데이터 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 쿼리 |
|
||||
Loading…
x
Reference in New Issue
Block a user