DOCS/journey/research/260320_스트림데이터_MD위키_통합_지식베이스_사업화_리서치.md
happybell80 e8ab0d2ba7 docs: 스트림데이터 MD/위키 통합 지식베이스 사업화 리서치 추가
Gemini 대화 기반 — 인제션 아키텍처, 가치 판단 필터링, 프롬프트 DB 시너지,
위키 통합, 사업화 검토, 핵심 비판 4가지, RBAC 구현 전략 정리

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-03-20 14:23:20 +09:00

8.8 KiB

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

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


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

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

인제션 흐름

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

소스별 프론트메타 설계

슬랙:

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

이메일:

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

뉴스/RSS:

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

  • 연결성: 진행 중인 프로젝트/관심 태그와 관련 있는가?
  • 중요도 전이: 이미 '중요'한 문서에서 파생된 정보인가?

가치 점수 시스템

---
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 예시

---
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 구현 전략

프론트메타 기반 데이터 태깅 (인제션 단계)

---
source: "slack"
original_channel: "C12345"
access_control:
  groups: ["dev-team", "admin"]
  users: ["user_a", "user_b"]
  level: "internal"  # public, internal, private, confidential
---

PostgreSQL RLS 활용 (검색 단계)

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 쿼리