Personal Knowledge Base 마스터 플랜

### 1.1 문제 정의

plan docs/plan/pkb-master-plan.md

버전: v2.0
작성일: 2026-04-21
상태: Implemented (Phase 1-3 완료)
범위: 개인 → 팀 → 기업으로 확장 가능한 AI 기반 지식 관리 시스템

1. 배경

1.1 문제 정의

현재 AI 작업/지식이 여러 도구에 파편화되어 있음.

Cursor / Claude Code / Claude Chat 세션 로그가 흩어짐
Notion 문서와 Obsidian vault가 따로 존재
프로젝트별 맥락이 다음 세션으로 이어지지 않음
과거 결정/검토 내용을 다시 찾기 어려움

1.2 기회

Context Engineering이 2026년 업계 표준으로 부상 (Karpathy 제안 → Neo4j, Elastic, ByteByteGo 모두 가이드 발표)
Self-hosted AI 스택이 실용 가능한 수준에 도달 (Ollama, Qdrant, vLLM 성숙)
로컬 우선 접근이 대기업 제품 대비 실질 경쟁력 확보 (데이터 소유권, 비용, 커스터마이즈)
홈랩 인프라가 이미 존재 (K3s 클러스터, GB10 GPU, A6 ×3)

1.3 핵심 질문

"어떤 AI가 나오든, 어떤 벤더가 망하든 살아남는 지식 시스템을 어떻게 만들까?"

→ 답: Markdown + Git + 플러그인형 AI 레이어

2. 비전

2.1 최종 목표

Phase 1:  개인 완성형 PKB
Phase 2:  홈랩 기반 멀티디바이스
Phase 3:  팀/회사 내부 배포
Phase 4:  제품화 (SaaS or 온프레미스 라이선스)

2.2 5년 후 상상

내가 했던 모든 작업/결정이 검색 가능한 지식 베이스로 존재
"저번에 Kafka 검토했을 때 결론이?" 같은 질문에 즉답
팀원들이 같은 시스템을 내부망에서 사용
외부 기업에 제품으로 제공 가능
Notion/Jira/Confluence는 선택지 (제거 또는 MCP 연동 유지)
SaaS 구독 비용을 원하는 수준까지 축소 (단계 선택형)

3. 현재 상태 (Baseline)

3.1 이미 갖춰진 것

요소	위치	상태
AI 로그 수집	`D:\dev\ai-rules\scripts\export_ai_logs.ps1`	작동
프로젝트 동기화	`sync-projects.ps1`	작동
로그 저장소	`D:\Obsidian Vault\Agent-Work-Hub\`	21개 프로젝트 수집 중
개인 PKB	`D:\dev-reference\obsidian-vault\`	Claude Chat + Desktop Commander로 매일 사용
Privacy 3단계	`obsidian-vault` frontmatter	public / internal / personal
Daily Scrum 봇	`D:\dev\gencrew-bot\`	Telegram 발송 작동
작업 스케줄러	`DailyScrum` 태스크	매일 09:00 자동 실행
홈랩 인프라	K3s, Cilium, A6×3, GB10	운영 중

3.2 미개발

Cross-project 리포트 자동 생성
세션 내용 기반 프로젝트 분류
벡터 인덱싱 / 의미 검색
Q&A 엔진
MCP 브릿지 레이어 (Notion / Jira / Confluence / Slack / GitHub)
Notion ↔ vault 양방향 동기화 (Stage 3에서)
팀 공유용 권한 레이어
민감정보 자동 필터링
감사 로그

4. 설계 원칙

원칙 1 — 파일이 진실의 원천 (Source of Truth)

Markdown + Git 저장소가 원본
→ 모든 AI 기능은 그 위에 덧입힌 레이어
→ AI가 다 사라져도 데이터는 남음

원칙 2 — 추상화 레이어 분리

Application (UI, Bot, CLI)
      ↓ 표준 API
Knowledge API (자체 정의)
      ↓ 플러그인
Backend (Qdrant, Ollama, Claude API, ...)

백엔드는 언제든 교체 가능.

원칙 3 — 로컬 우선, 클라우드 선택

기본 동작은 전부 로컬
클라우드 모델은 "더 좋을 때만" 추가
네트워크 끊겨도 핵심 기능 작동

원칙 4 — 멀티테넌시 준비

처음부터 모든 문서에 메타데이터:

---
tenant: personal | team-x | public
owner: dydan
privacy: personal | internal | public
project: AITEM
---

원칙 5 — 다층 방어 (Defense in Depth)

보안은 단일 레이어로 충분하지 않음:

물리적 분리 (Git repo) + 자동 필터 (pre-commit) + 권한 (RBAC) + 감사 (log)

원칙 6 — 변화에 보험

변하는 것(모델, 벤더, 프레임워크)과 안 변하는 것(파일, 구조, 표준)을 분리.

원칙 7 — 점진적 대체 (Progressive Replacement)

기존 도구(Notion, Jira, Confluence)를 하루아침에 바꾸지 않는다. 4단계로 이전:

Stage 1: 외부 도구 유지 + MCP 읽기 연동 (AI 쿼리만 통합)
Stage 2: 양방향 MCP (선택적 vault 편집)
Stage 3: vault가 원본, 외부는 뷰어 역할
Stage 4 (선택): 외부 도구 완전 제거

언제든 이전 Stage로 롤백 가능.

원칙 8 — MCP를 추상화 레이어로

사용자 / AI / 봇 → Knowledge API → MCP → 실제 도구

백엔드 도구가 바뀌어도(Notion → Obsidian) 사용자 경험은 그대로.

5. 아키텍처

5.1 전체 구조도

┌──────────────────────────────────────────────────┐
│ Ingestion Layer (수집)                            │
│  - AI 세션 로그 (Cursor, Claude)                  │
│  - Notion API                                     │
│  - 수동 문서 (Obsidian에서 직접 작성)              │
│  - 웹 클리핑 (나중)                               │
└──────────────────────┬───────────────────────────┘
                       ↓
┌──────────────────────────────────────────────────┐
│ Storage Layer (저장)                              │
│  - Git 저장소 (3 vault 분리)                      │
│    · personal / work / public                     │
│  - Markdown + frontmatter                         │
└──────────────────────┬───────────────────────────┘
                       ↓
┌──────────────────────────────────────────────────┐
│ Processing Layer (가공)                           │
│  - 세션 분류 (LLM)                                │
│  - 요약 / 토픽 추출                               │
│  - 민감정보 스크러빙                              │
│  - 청킹 + 임베딩                                  │
└──────────────────────┬───────────────────────────┘
                       ↓
┌──────────────────────────────────────────────────┐
│ Index Layer (인덱스)                              │
│  - Qdrant (벡터 검색)                             │
│  - 지식 그래프 (위키링크 → Obsidian Canvas)       │
│  - BM25 (키워드 검색)                             │
└──────────────────────┬───────────────────────────┘
                       ↓
┌──────────────────────────────────────────────────┐
│ Knowledge API                                     │
│  /search  /query  /store  /link                   │
└──────────────────────┬───────────────────────────┘
                       ↓
┌──────────────────────────────────────────────────┐
│ Application Layer (활용)                          │
│  - Claude Desktop + MCP                           │
│  - Telegram 봇 (Daily Scrum, Q&A)                 │
│  - 리포트 (daily/weekly/monthly/quarterly/yearly) │
│  - 웹 UI (나중)                                   │
└──────────────────────────────────────────────────┘

5.2 Vault 분리 구조 — 6단계 계층

기업 환경까지 고려한 scope 6단계:

Level 1: 🌐 PUBLIC           외부 공개 (블로그, 오픈소스)
Level 2: 🏢 COMPANY-WIDE     전사 공통 (온보딩, 규정, 템플릿)
Level 3: 🏛️ DEPARTMENT       본부/부서 (Engineering, Product)
Level 4: 👥 TEAM             팀 (Backend, Frontend, DevOps)
Level 5: 💼 WORK-PERSONAL    회사에서 나만 보는 메모
Level 6: 🔒 PERSONAL-LIFE    회사와 무관한 순수 개인

Git 저장소 구조 (Gitea 기준)

gitea.company.internal/
  ├─ public/                      ← 전사 공개
  │   └─ handbook.git
  │   └─ onboarding.git
  │
  ├─ engineering/                 ← 부서 organization
  │   ├─ dept-wiki.git           ← 부서 공통
  │   ├─ team-backend.git        ← 팀별
  │   ├─ team-frontend.git
  │   └─ team-devops.git
  │
  ├─ product/
  │   └─ dept-wiki.git
  │
  └─ users/                       ← 개인 영역 (회사 내)
      └─ dydan-work.git

github.com/me/                    ← 순수 개인 (집 영역)
  └─ personal-vault.git (private)

개인 PC 마운팅

D:\vaults\
  ├─ _personal-life\       🔒 순수 개인 (github private)
  ├─ _work-personal\       💼 회사 내 개인 (gitea/users/dydan-work)
  ├─ team-backend\         👥 팀 (gitea/engineering/team-backend)
  ├─ dept-engineering\     🏛️ 부서
  ├─ company\              🏢 전사
  └─ public\               🌐 공개

각 폴더는 독립 Git 저장소의 clone. Obsidian multi-vault로 전환하며 사용.

접근 권한 매트릭스

              Public  Company  Dept   Team   WorkMe  PersonalMe
─────────────────────────────────────────────────────────────
모든 직원      R       R        -      -       -       -
부서 소속      R       R        R      -       -       -
팀 소속        R       R        R      R       -       -
본인           R       R        R*     R*      RW      RW
외부 공개      R       -        -      -       -       -

R: 읽기, W: 쓰기
* 소속된 부서/팀만

원칙:

상위 → 하위 자동 상속 없음
하위 → 상위 승격 프로세스 필수
개인 영역은 본인만 접근

승격(Promotion) 프로세스

[Work-Personal] ──promote──→ [Team] ──promote──→ [Dept] ──promote──→ [Company]

각 단계마다 자동 처리:
  1. PRIVATE 블록 제거
  2. 개인 스크러빙 (이메일, 사내 URL)
  3. frontmatter.scope 변경
  4. frontmatter.promoted_from 기록
  5. 상위 저장소에 PR 생성
  6. 리뷰 후 merge

메타데이터 확장

---
scope: public | company | department | team | work-personal | personal-life
tenant: company-a                # 기업 고객 구분 (제품화 시)
owner: dydan@company.com
privacy: public | internal | confidential | secret
department: engineering
team: backend
project: AITEM
promoted_from: /users/dydan/notes/kafka.md
promoted_at: 2026-04-20
tags: [kafka, messaging, architecture]
created: 2026-04-19
---

5.3 Context 5-Layer Stack

Layer 1: System Instructions (CLAUDE.md)
Layer 2: Conversation State (세션 히스토리)
Layer 3: RAG / Retrieval (Qdrant + 키워드 하이브리드)
Layer 4: Tool Definitions (MCP 스킬)
Layer 5: Workflow State (Agent 진행 상태)

6. 단계별 로드맵

6.0 타임라인 비교

Phase	전통 방식	바이브코딩 기준	단축
Phase 1	0~1개월	1~2일	15x
Phase 2	1~2개월	1~2일	30x
Phase 3	2~4개월	3~4일	20x
Phase 4	4~6개월	2~3일	50x
Phase 5	6~9개월	4~5일	40x
Phase 6 (기술)	9~12개월	1~2주	20x
Phase 6 (인증)	-	별도 3~6개월 (AI 무관)	-

기준: Cursor/Claude Code 활용, 80% 코드 AI 생성, 즉시 이터레이션.

전체: 12개월 → 3~~4주 풀타임 / 2~~3개월 파트타임

AI로 단축 불가능한 항목

네트워크 (모델 다운로드, 초기 인덱싱)
실행 대기 (파드 기동, 빌드)
사람 의사결정 (설계 리뷰, 취향 판단)
인증/규제 (SOC 2, ISO 27001, AI Act)
실사용 검증 (최소 1~2주 관찰)

Phase 1 — 개인 파이프라인 완성 (바이브: 12일 / 전통: 01개월)

목표: 오늘 만든 계획의 Phase 1 실행. AI 로그 → 리포트 → Telegram 자동화.

#	작업	위치	난이도
1.1	`generate-cross-report.ps1` 작성	`ai-rules/scripts/`	중
1.2	`run-daily-scrum.bat` 수정 (로그 수집 + 리포트 생성 추가)	`gencrew-bot/`	저
1.3	`messenger-telegram.mjs` AI 세션 섹션 추가	`gencrew-bot/scripts/lib/`	저
1.4	`daily-scrum.mjs` cross-report 읽기 연동	`gencrew-bot/scripts/`	중
1.5	#태그 기반 세션 분류 (규칙 기반)	`generate-cross-report.ps1`	저
1.6	주간/월간/분기/연간 집계 로직	`generate-cross-report.ps1`	중
1.7	스케줄러 주간 태스크 추가	Windows Task Scheduler	저

완료 조건: 매일 아침 Telegram에 AI 세션 요약 포함된 리포트 수신.

Phase 2 — Vault 분리 + 보안 기초 (바이브: 12일 / 전통: 12개월)

목표: 개인 정보 유출 위험 원천 차단 + 미래 팀 확장 준비.

#	작업	난이도
2.1	`D:\vaults\` 3분리 (personal / work / public)	저
2.2	각 vault별 Git 저장소 분리	저
2.3	`.gitignore` 엄격화 (시크릿 패턴, 민감 폴더)	저
2.4	gitleaks + pre-commit 훅 설치	중
2.5	frontmatter privacy 필드 일괄 적용	중
2.6	`publish.ps1` 작성 (PRIVATE 블록 자동 제거)	중
2.7	시크릿 스크러버 (API key, token 등 패턴)	중
2.8	감사 로그 기초 (쿼리 기록 시작)	중

완료 조건: 실수로 민감정보 커밋 시 pre-commit이 차단.

Phase 3 — 벡터 인덱싱 + Q&A (바이브: 34일 / 전통: 24개월)

목표: 의미 기반 검색. "저번에 뭐 검토했지?" 같은 질문 응답.

#	작업	난이도
3.1	Qdrant 로컬 Docker 구동	저
3.2	임베딩 파이프라인 (nomic-embed-text)	중
3.3	청킹 전략 (hierarchical, 256~~512 토큰, 10~~15% overlap)	중
3.4	주기적 인덱싱 (증분 업데이트)	중
3.5	Knowledge API (`/search`, `/query`) FastAPI	중
3.6	Telegram 봇에 Q&A 명령 추가	중
3.7	응답에 출처(provenance) 필수 표시	중
3.8	하이브리드 검색 (벡터 + BM25)	고

완료 조건: "AITEM에서 결제 관련 뭐 논의했지?" 에 근거 포함 답변.

Phase 4 — 홈랩 마이그레이션 (바이브: 23일 / 전통: 46개월)

목표: PC 꺼도 작동. 여러 기기에서 접근.

#	작업	난이도
4.1	Qdrant K3s 배포	중
4.2	Ollama K3s 배포 (GB10 GPU 할당)	중
4.3	Knowledge API K3s 배포	중
4.4	Ingress + TLS (내부 도메인)	중
4.5	백업 전략 (벡터 + Git 스냅샷)	중
4.6	모니터링 (LGTM 스택 — 이미 운영)	저
4.7	클라이언트 동기화 (Obsidian Git 활용)	저

완료 조건: 폰에서도 Q&A 사용 가능.

Phase 5 — 팀 확장 준비 (바이브: 45일 / 전통: 69개월)

목표: 회사 시범 도입 가능 상태.

#	작업	난이도
5.1	Gitea 기반 팀 vault 분리	중
5.2	Keycloak SSO 통합	고
5.3	Qdrant 멀티테넌트 컬렉션	중
5.4	RBAC 레이어 (`.roles.yml` 설계)	고
5.5	NeMo Guardrails 통합 (출력 필터)	고
5.6	Presidio PII 탐지 통합	중
5.7	감사 대시보드 (Grafana)	중
5.8	권한 회수 자동화 (퇴사자 처리)	중

완료 조건: 소규모 팀(5명) 시범 운영 가능.

Phase 6 — 제품화 (바이브: 12주 + 인증 별도 36개월 / 전통: 9~12개월)

목표: 외부 기업 판매 가능.

#	작업	난이도
6.1	테넌트 완전 격리 아키텍처 검증	고
6.2	온프레미스 설치 자동화 (Helm Chart)	고
6.3	관리자 웹 UI (테넌트/사용자/권한)	고
6.4	사용량 대시보드 (테넌트별 쿼리, 토큰)	중
6.5	EU AI Act 준수 문서화	중
6.6	SOC 2 / ISO 27001 준비 검토	고
6.7	마케팅 사이트 / 데모 환경	중
6.8	가격 정책 (SaaS / 온프레 / 하이브리드)	중

완료 조건: 첫 파일럿 고객 계약.

7. 기술 스택

7.1 확정된 선택

레이어	기술	이유
문서 저장	Markdown + frontmatter	벤더 중립, 영속성
버전 관리	Git (Gitea 내부, GitHub 외부)	표준, 감사 내장
에디터	Obsidian	이미 사용 중, 플러그인 풍부
벡터DB	Qdrant	Rust, 빠름, 멀티테넌시 지원
로컬 LLM	Ollama → vLLM (팀 규모부터)	단계적 전환
임베딩	nomic-embed-text	로컬, 품질 우수
API	FastAPI	Python, 생태계
자동화	PowerShell (OS 레벨), Node.js (봇), n8n (나중)	기존 자산 활용
모니터링	LGTM 스택	이미 운영 중
오케스트레이션	K3s	이미 운영 중

7.2 보류 / 검토 중

지식그래프: Neo4j vs Obsidian Canvas (Dataview)
가드레일: NeMo vs LlamaGuard vs 자체 구현
에이전트 프레임워크: LangGraph vs Claude Agents SDK vs 자체
외부 LLM: Anthropic Claude API (고품질 시) vs OpenAI vs 완전 로컬

7.3 명시적 배제 (원본 저장소로는)

기술	이유	단, MCP 연동은 허용
Notion	벤더 락인, 유료, 데이터 소유권 문제	✅ 기존 자산은 MCP로 읽기
Jira	벤더 락인, 고비용, 과도한 복잡성	✅ 회사 정책상 유지 필요 시 MCP 연동
Confluence	동일	✅ 동일
OpenAI 전용 솔루션	락인 위험	✅ 품질이 필요한 특정 작업만
프로프라이어터리 벡터DB	대안 풍부	❌
Electron 기반 데스크탑 앱	Obsidian이 이미 그 역할	❌

원칙: 원본 데이터(Source of Truth)는 Markdown + Git. 외부 도구는 MCP 브릿지로만 접근.

7.4 외부 도구 통합 전략 (MCP 기반)

7.4.1 3-트랙 전략

기존 도구를 대체할지, 연동할지, 점진 전환할지 선택 가능:

┌─────────────────────────────────────────────────┐
│ Track A: 완전 대체                                │
│   자체 스택만 사용, 외부 도구 제거                 │
│   → 비용 최소, 완전 소유                          │
│                                                    │
│ Track B: MCP 브릿지                               │
│   외부 도구 유지, AI 통합만 추가                   │
│   → 기존 워크플로우 유지, 마찰 최소                │
│                                                    │
│ Track C: 점진 이전 (권장)                         │
│   MCP 연동 → 일부 대체 → 완전 대체                │
│   → 현실적, 팀/용도별 선택 가능                    │
└─────────────────────────────────────────────────┘

팀마다, 용도마다, 시기마다 다른 트랙 선택 가능.

7.4.2 도구별 매핑

외부 도구	대체안 (Track A)	MCP 서버 (Track B)	기본 권장
Notion (문서)	Obsidian + Gitea	`@openclaw/notion`	Track C
Notion (DB)	Dataview + 플러그인	동일	Track C
Jira	Markdown + Kanban 플러그인	`@atlassian/mcp-server` (공식)	Track B
Confluence	Obsidian + Gitea	`@atlassian/mcp-server`	Track C
Slack	Matrix / Rocket.Chat	`@modelcontextprotocol/server-slack`	Track B
GitHub Issues	Gitea Issues	`@modelcontextprotocol/server-github`	Track B
Google Drive	로컬 + Git LFS	`@modelcontextprotocol/server-google-drive`	Track B
사내 위키 / ERP	-	자체 MCP 서버 작성	Track B

7.4.3 시나리오별 권장

개인 사용 (현재):

Track A: Notion 제거 → Obsidian
Track B: GitHub Issues 유지 + MCP 연동

소규모 팀 (5~20명):

Track A: Confluence → Obsidian + Gitea
Track B: Jira 유지 (전환 저항 큼) + MCP
Track C: Notion DB → 점진 이전 (분기 단위)

중견/대기업:

Track B 중심:
  기존 Jira/Confluence/Notion 유지
  → MCP로 AI 레이어만 추가
  → 팀별 파일럿 운영

선도 팀은 Track C로 파일럿
Track A는 장기 목표 (3~5년)

7.4.4 점진 이전의 4단계 (Progressive Replacement)

Stage 1: 외부 도구 유지 + MCP 읽기 연동
         → AI 쿼리만 통합, 편집은 기존 도구
         → 사용자 경험 변화 제로
         
Stage 2: 양방향 MCP (쓰기 포함)
         → AI/봇이 Jira 이슈 생성 등
         → 선택적으로 vault에서도 편집
         
Stage 3: vault가 원본(Source of Truth), 외부는 뷰
         → Markdown이 마스터, Notion/Confluence는 자동 동기화된 뷰어
         → 이 단계에서 Git 이점(감사, PR, 브랜치) 확보
         
Stage 4 (선택): 외부 도구 완전 제거
         → 팀 합의 후, 비용/가치 재검토
         → 중견/대기업은 여기까지 안 가도 됨

언제든 이전 Stage로 롤백 가능. 마이그레이션 실패 리스크 최소화.

7.4.5 MCP 아키텍처 업데이트

┌─────────────────────────────────────────┐
│ Data Sources                             │
│   ├─ Local vault (Markdown) — 원본       │
│   ├─ Jira (MCP) — 읽기/쓰기               │
│   ├─ Confluence (MCP) — 읽기              │
│   ├─ Notion (MCP) — 읽기 (이전 중)        │
│   ├─ GitHub (MCP) — 읽기/쓰기             │
│   ├─ Slack (MCP) — 읽기                  │
│   └─ 사내 시스템 (자체 MCP)                │
└──────────────┬──────────────────────────┘
               ↓
┌─────────────────────────────────────────┐
│ Retrieval Orchestrator                   │
│   - 쿼리 분석 → 어느 소스 호출할지 결정    │
│   - MCP + 벡터DB 병렬 호출                │
│   - 결과 통합 + 출처 표시                 │
│   - 권한 필터링 (Scope × Privacy)         │
└──────────────┬──────────────────────────┘
               ↓
┌─────────────────────────────────────────┐
│ Response Generation (LLM)                │
│   - Claude / Ollama                      │
│   - 출처 필수 인용                        │
│   - 가드레일                              │
└──────────────┬──────────────────────────┘
               ↓
        사용자 / 봇 / 리포트

7.4.6 통합 쿼리 예시

사용자: "지난 주 결제 관련 버그 중에 주요한 거 정리해줘"

Knowledge API 내부 처리:
  1. 쿼리 분석: 기간=지난주, 주제=결제, 종류=버그
  2. 병렬 호출:
     ├─ atlassian-mcp: Jira에서 "payment" 라벨 + closed 이슈
     ├─ 로컬 벡터DB: AI 세션 로그 중 결제 디버깅
     ├─ slack-mcp: #alerts 채널의 결제 에러 알림
     └─ github-mcp: fix(payment) 커밋/PR
  3. 통합 + LLM 요약
  4. 출처 표시:
     - Jira: PAY-123, PAY-145
     - Session: 2026-04-17 Claude
     - Slack: #alerts 2026-04-18
     - PR: gencrew-bot#234

기존 도구를 그대로 두고도 교차 조회가 됨.

8. 보안 / Privacy 설계

8.1 데이터 분류 (Scope × Privacy)

Scope (조직 범위) — 6단계

Scope	예시	Git 저장소	접근
public	블로그, 오픈소스	GitHub public	누구나
company	전사 핸드북, 온보딩	Gitea company/	전 직원
department	부서 위키, 부서 규칙	Gitea dept/	부서 소속
team	팀 프로젝트, 팀 노하우	Gitea team/	팀 소속
work-personal	회사 내 개인 TIL	Gitea users/me-work	본인만
personal-life	일기, 금융, 사생활	GitHub private or 로컬	본인만

Privacy (민감도) — 4단계

Privacy	설명	처리
public	공개 가능	필터 없음
internal	조직 내부만	scope 기반 필터
confidential	승인된 사용자만	추가 권한 체크
secret	최소 인원	암호화 + 감사

Scope × Privacy 조합으로 세밀한 제어:
예) scope: team + privacy: confidential → 팀 소속 중에서도 승인자만

8.2 방어 레이어 (5중)

Layer 1: 물리적 분리      → 다른 Git 저장소
Layer 2: Pre-commit 훅    → gitleaks, 정규식 스캔
Layer 3: Frontmatter 필터 → privacy 필드 기반 자동 제외
Layer 4: Inline 필터      → <!-- PRIVATE --> 블록 제거
Layer 5: 벡터/LLM 레이어  → 권한별 컬렉션, 출력 가드레일

8.3 민감정보 패턴 (pre-commit 검사)

API Key       : [A-Za-z0-9]{32,} 
Bearer Token  : Bearer [A-Za-z0-9\-\._~\+\/]+=*
sk-* (OpenAI) : sk-[A-Za-z0-9]{10,}
주민번호      : \d{6}-[1-4]\d{6}
카드번호      : \d{4}-\d{4}-\d{4}-\d{4}
이메일 비번   : password\s*[:=]\s*\S+
.env 파일     : 전면 금지

8.4 감사 로그 (Audit Trail)

모든 쿼리 기록:

{"ts":"2026-04-19T10:00:00Z","user":"dydan","action":"query","q":"AITEM kafka","collections":["personal","work"],"results":5}

보관 기간: 최소 1년 (EU AI Act 대응).

9. 리스크 관리

9.1 기술 리스크

리스크	영향	완화책
오픈소스 프로젝트 중단	중	핵심은 표준 기반(Git, MD). 대안 즉시 존재
벡터DB 포맷 변경	저	원본 Markdown 유지 → 재인덱싱만
로컬 LLM 품질 한계	중	Claude API로 폴백 옵션 유지
홈랩 장애	중	백업 + 로컬 모드 폴백

9.2 보안 리스크

리스크	영향	완화책
민감정보 커밋	고	Pre-commit 훅 다중 검사
권한 우회 쿼리	고	API 레이어 강제 필터
벡터DB 노출	고	내부망 only, TLS
퇴사자 데이터 반출	중	감사 로그 + 이상 탐지
LLM 환각으로 거짓 정보	중	출처 필수 표시

9.3 운영 리스크

리스크	영향	완화책
혼자 유지보수 부담	고	문서화 + 자동화 우선
기술 부채 누적	중	분기별 리팩토링 주간
사용 안 함	고	Phase 1부터 매일 쓰는 구조 설계

9.4 비즈니스 리스크

리스크	영향	완화책
대기업 무료 제품 출시	중	플러그인으로 통합 가능 구조
규제 변화 (AI Act 등)	중	처음부터 감사/출처 내장
시장 수요 부재	중	개인용으로도 가치 있으면 충분

10. 의사결정 기록

10.1 확정된 결정

#	결정	이유	날짜
D1	Markdown + Git을 원본 저장소로	벤더 중립, 이식성	2026-04-19
D2	Obsidian을 메인 에디터로	기존 사용 중, 로컬 우선	2026-04-19
D3	Qdrant를 벡터DB로	프로덕션 준비도, 멀티테넌시	2026-04-19
D4	Notion 의존 축소 → 최종 제거 (단, MCP 연동은 허용)	락인/비용 해소하되 전환 마찰은 최소화	2026-04-19
D5	Phase 1부터 시작 (벡터 뒤로)	파이프라인 먼저, 최적화 나중	2026-04-19
D6	Scope 6단계 계층 구조	개인 → 팀 → 부서 → 전사 확장	2026-04-19
D7	저장소 분리 방식 (Gitea org)	권한 모델 네이티브 활용	2026-04-19
D8	Scope × Privacy 이중 분류	조직 범위와 민감도 독립 제어	2026-04-19
D9	3-트랙 통합 전략 (A/B/C)	대체/연동/점진 선택, 팀별 유연성	2026-04-19
D10	MCP를 외부 도구 추상화 레이어로	Jira/Confluence/Notion 공존 가능	2026-04-19
D11	Progressive Replacement 4단계	하루아침 전환 금지, 롤백 가능	2026-04-19

10.2 미결정 (추후 검토)

지식그래프 도구 선택 (Neo4j vs Obsidian 플러그인)
외부 LLM API 사용 범위
제품화 시 오픈소스 vs 클로즈드
SaaS 전용 / 온프레미스 전용 / 하이브리드
가격 모델

11. 실행 체크리스트 (Phase 1 상세)

다음 작업을 이 순서로 진행:

즉시 (이번 주)

본 계획안 검토 및 확정
generate-cross-report.ps1 Phase 1.1 작성
현재 존재하는 cross-project/reports/daily/ 포맷 유지하며 확장
#태그 규칙 정의 (프로젝트명 매핑 테이블)

1주차

run-daily-scrum.bat 수정 + 테스트
messenger-telegram.mjs AI 세션 섹션 추가
수동 실행으로 End-to-End 검증

2주차

주간 집계 로직
일요일 주간 스케줄러 태스크 등록
Telegram 주간 메시지 포맷

3~4주차

월간/분기/연간 집계
Phase 2 준비 (vault 분리 계획 수립)

12. 참고 자료

12.1 내부 문서

D:\Obsidian Vault\Agent-Work-Hub\cross-project\docs\automation-architecture.md
D:\dev-reference\obsidian-vault\CLAUDE.md
D:\dev\ai-rules\scripts\export_ai_logs.ps1
D:\dev\gencrew-bot\scripts\daily-scrum.mjs

12.2 외부 자료 (2026 Q1~Q2 기준)

Context Engineering: Vishnyakova (arxiv 2603.09619), Context Kubernetes (arxiv 2604.11623)
Personal RAG: Karpathy LLM Wiki, Claude Code + Obsidian 패턴
Enterprise: ServiceNow Context Engine, Tabnine Enterprise Context Engine
OSS 대안: AppFlowy, AFFiNE, SiYuan, Trilium

12.3 변경 이력

날짜	버전	변경	작성자
2026-04-19	v1.0	최초 작성	dydan + AI

13. 다음 행동

실행 현황 (2026-04-21)

구현 완료

항목	저장소	PR
Phase 1: 추출 파이프라인 (LLM 기반)	pkb-wiki	#1
Phase 2: 검색 (ChromaDB + FTS5) + API + 생명주기 + MCP	pkb-wiki	#3
Phase 3: Telegram + 상태 감지 + Weekly report	pkb-wiki	#3
자동 캡처: SessionEnd hook + /logs 연동 + 05:00 스케줄러	pkb-wiki	#7
분류 체계: tenant/scope/domain + 한국어 폴더	pkb-wiki	#8
retrospective: AI 품질 자동 분석	pkb-wiki	#10
approve → taxonomy 폴더 자동 분류	pkb-wiki	#11
처리 완료 레지스트리 (중복 추출 방지)	pkb-wiki	#9
FTS5 하이픈 버그 수정	pkb-wiki	#6
로그 수집 중복 버그 수정	ai-rules	#83
/logs → pkb extract 자동 연동	ai-rules	#78

운영 데이터

정제 문서: 67개 (6개 프로젝트 + 공통)
벡터 인덱스: 69개
아카이브 키워드 인덱스: 214개
분류: personal/프로젝트/, personal/공통/, personal/학습/

스킬

/pkb <query> — 지식 검색
/pkb-capture — 수동 캡처

남은 작업 (필요 시)

MCP 서버 Claude Desktop 등록
Notion import 실행 (import/notion/ 구조 준비됨)
웹 대시보드 / Graph RAG (이후 검토)

이 문서는 **살아있는 계획서(living document)**다. 실행하면서 계속 업데이트한다.