Wiki Operations: 5가지 관리 프로세스 (수집·큐레이션·링킹·린트·업데이트)
Phase 1-2 Deliverable
DAP 위키가 지속 가능하게 운영되기 위한 5가지 반복 프로세스의 상세 워크플로우, 체크리스트, SLA, 소유권 정의.
관리 프로세스 개요
DAP 위키는 다음 5가지 프로세스의 반복 사이클로 구동됩니다.
┌─────────────────────────────────────────────────────────┐
│ 월간·분기 주기 (Update Metadata) │
│ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 주간 사이클 │ │
│ │ │ │
│ │ 월요일: 큐레이션 → 주 3-5회: 수집 → 링킹 │ │
│ │ → 금요일: 린트 → 월요일 다시... │ │
│ │ │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ ↓ (월 1회 또는 분기 1회) │
│ │
│ 메타데이터 갱신 (index.md, frontmatter, CLAUDE.md) │
└─────────────────────────────────────────────────────────┘
Process 1️⃣: 수집 (Ingest)
개요
| 항목 | 값 |
|---|---|
| 주기 | Ad hoc (수시) + 정기 (주 1-3회) |
| 소유권 | 모든 역할 (분산형) |
| 입력 | 소스 후보 (자동 감지 또는 수동 제안) |
| 산출 | raw/ 파일 (4가지 모드) |
| 소요 시간 | 모드당 2-15분 |
| SLA | 수집 후 24시간 내 Transform 시작 |
상세 워크플로우
Step 1: 소스 평가 (5분)
입력: 소스 후보 (URL, 파일, 검색어)
체크리스트:
- 관련성: “DAP 위키 도메인(데이터수집·ETL·분석·거버넌스)과 맞는가?”
- 신뢰성: “저자/출처가 신뢰할 만한가?”
- 품질: “최소 500자 이상 실질 콘텐츠인가?”
- 최신성: “발행 후 2년 내인가?” (역사 자료는 예외)
판정:
- ✅ 수집 → Step 2로
- ❌ 폐기 → 로그 기록 (선택사항)
Step 2: 인제스트 모드 선택 (1분)
| 상황 | 모드 | 액션 |
|---|---|---|
| 사용자가 파일 제공 | A | raw/articles/YYYY-MM-DD-source-name.md 저장 (프론트매터 수동 추가) |
| 웹 URL 제공 | B | WebFetch/defuddle로 마크다운 변환 → raw/ 저장 |
| ”~한 글 찾아줘” (자연어) | C | WebSearch → 후보 3-5개 제시 → 사용자 선택 → 모드 B 처리 |
| 2개 이상 URL 비교·분석 | D | NotebookLM 외부 분석 → 결과 markdown → raw/ 저장 |
Step 3: 파일 생성 및 프론트매터 입력 (3-10분)
필수 필드 (frontmatter):
source_type: article / document / video / dataset / report
url: [원본 URL 또는 "internal" (mode A)]
title: [원본 제목]
author: [저자명]
published: YYYY-MM-DD [또는 "unknown"]
harvested: 2026-04-27
tags: [source, dap, domain-category, content-category] # 예: [source, dap, etl, future-trends]품질 체크:
- 파일명:
YYYY-MM-DD-descriptive-name.md형식 - 프론트매터: 모든 필수 필드 입력
- 본문: 최소 200자 (마크다운 변환 후)
산출: raw/ 파일 저장, 로그 기록
Step 4: 처리 핸드오프 (1분)
다음 단계 (Transform)로 자동 연결:
- log.md에 ”## [YYYY-MM-DD] ingest | …” 기록
- Transform 담당자 또는 자동 프로세스에 알림
Process 2️⃣: 큐레이션 (Curate)
개요
| 항목 | 값 |
|---|---|
| 주기 | 주 1회 (월요일 아침) |
| 소유권 | 위키 마스터 (1인) |
| 입력 | RSS 피드, 검색 알림, 사용자 제안 |
| 산출 | 이번 주 수집 우선순위 리스트 |
| 소요 시간 | 20-30분 |
| SLA | 월요일 10:00까지 공유 |
상세 워크플로우
Step 1: 소스 후보 발굴 (10분)
자동 소스:
/curate스킬 실행 → RSS 피드 + arXiv + HuggingFace Daily Papers 자동 필터링- 결과: 주제 관련 상위 10-20개 후보
수동 소스:
- 사용자 제안 수집 (Slack, 메일 등)
- 검색 알림 확인 (Google Alerts, Twitter 키워드)
산출: 후보 목록 (20-30개)
Step 2: 우선순위 평가 (10분)
평가 기준:
| 기준 | 점수 | 설명 |
|---|---|---|
| 관련성 | 3점 | DAP 도메인 직접 언급 (예: ETL, 데이터 품질) |
| 2점 | 간접 관련 (예: 클라우드 아키텍처) | |
| 1점 | 주변 영역 (예: 데이터 시각화) | |
| 신뢰성 | 3점 | 학술지, 공식 기술 블로그 (예: Microsoft Learn) |
| 2점 | 기술 커뮤니티, 인디 개발자 (평판 있음) | |
| 1점 | 개인 블로그, 매체 미확인 | |
| 최신성 | 3점 | 최근 6개월 |
| 2점 | 6-12개월 | |
| 1점 | 1년 이상 (기초 개념만) |
우선순위 결정: (관련성 + 신뢰성 + 최신성) 합산
- 8-9점: 🔴 High — 이번 주 필수 수집
- 6-7점: 🟠 Medium — 이번 주 또는 다음 주
- 3-5점: 🟡 Low — Backlog (향후 필요 시)
- 0-2점: ❌ Skip — 폐기
Step 3: 수집 일정 계획 (5분)
이번 주 수집 목표: 3-5개 (High) + 1-2개 (Medium)
일정:
월 (Curate Day): 큐레이션 완료 + 팀 공유
화-목: 수집 진행 (매일 1-2개)
금: 린트 + 아카이브
산출: 주간 큐레이션 리스트 문서 (또는 Slack 스레드)
Process 3️⃣: 링킹 (Link)
개요
| 항목 | 값 |
|---|---|
| 주기 | 소스 수집 직후 (실시간 또는 배치) |
| 소유권 | 편집자 (개인) |
| 입력 | 새 sources/ 페이지 |
| 산출 | 강화된 concepts/ + 새 concepts/ |
| 소요 시간 | 소스당 10-15분 |
| SLA | 수집 후 2-4시간 내 완료 |
상세 워크플로우
Step 1: Synthesis Mapping (5분)
입력: 새 source 페이지 1개
질문:
- “이 source의 핵심 통찰이 기존 concepts 중 어느 것을 강화하나?”
- 예: “AWS Glue 사례” → etl-design-framework 강화
- “새로운 concept을 만들어야 하나?” (기존에 없는 개념 도입)
- 예: “Zero ETL” → 새 concept 작성
- “기존 cross-refs를 업데이트해야 하나?”
Action Type 선택:
- Strengthen (60%): 기존 concept에 새 섹션/근거 추가
- Challenge (10%): 기존 주장에 대한 반박 추가
- Create New Concept (20%): 신규 개념 도입
- Create New Entity (5%): 도구/인물/서비스 추가
- Update Cross-refs (5%): 양방향 링크 갱신
산출: Action 리스트 (예: “Strengthen lakehouse + Create entity AWS-Glue”)
Step 2: Concept 업데이트 (8-10분)
모드 A: Strengthen (기존 concept 강화)
- 해당 concept 페이지 열기
- 새로운 섹션 또는 기존 섹션에 source 내용 통합
- Frontmatter
sources배열에 새 source 추가 source_count증가updated필드 갱신
예시:
## 실제 사례: AWS Glue (출처: [[sources/etl-future-technology-kyobo]])
### Glue의 4가지 핵심 이점
1. **서버리스 확장성**...
2. ...모드 B: Create New Concept (신규 개념)
- 새 파일 생성:
wiki/concepts/CONCEPT-NAME.md - Frontmatter 작성 (tags, created, sources 배열)
- 정의, 특징, 활용 섹션 작성
- 양방향 링크 추가 (”## 관련 개념” → 기존 concepts)
- 기존 concepts에 역링크 추가 (”## 관련 개념” → 새 concept)
모드 C: Update Cross-refs
- 관련 concepts의 ”## 관련 개념” 섹션 확인
- 새로운 개념·source와의 연결 설명 추가
Step 3: Project Knowledge Pulls 업데이트 (2-3분)
확인: 이 source가 dap-wiki-ops-master-plan의 목표와 관련 있는가?
Yes: 프로젝트 frontmatter의 related_concepts / related_sources 배열에 추가
산출: 강화된 concepts + 선택적 새 concepts
Process 4️⃣: 린트 (Lint)
개요
| 항목 | 값 |
|---|---|
| 주기 | 주 1회 (금요일) |
| 소유권 | 자동화 (스킬) + 수동 검토 |
| 입력 | wiki/ 전체 |
| 산출 | QA 리포트 (문제 목록) |
| 소요 시간 | 자동 5분 + 수동 검토 10-15분 |
| SLA | 금요일 오후에 리포트 생성 |
상세 워크플로우
Step 1: 자동 검사 실행 (5분)
명령어: /lint 스킬
검사 항목:
| 카테고리 | 검사 내용 | 방법 | 심각도 |
|---|---|---|---|
| Orphans | 역링크가 0개인 페이지 | Graph 분석 | 🔴 Major |
| Broken Links | 깨진 wikilink (대상 없음) | 파일 존재 확인 | 🔴 Major |
| Stale Data | valid_as_of > 6개월 | Frontmatter 검사 | 🟠 Minor |
| Missing Fields | 필수 frontmatter 빠짐 | Frontmatter 검증 | 🔴 Major |
| Contradictions | ”⚠️ Contradiction” 섹션 유무 | 텍스트 검색 | 🟠 Medium |
| Tag Coverage | 필수 tags 누락 (예: “source”) | Frontmatter 검사 | 🟡 Info |
| Source Attribution | 주장 뒤 (출처: ) 확인 | 텍스트 패턴 | 🟡 Info |
산출: QA 리포트 (마크다운 형식)
## 린트 리포트 2026-04-27
### 🔴 Major Issues (2)
- Orphan: [[concepts/xyz]] (역링크 0개)
- Broken: [[concepts/abc#section]] → 섹션 없음
### 🟠 Medium Issues (1)
- Stale: [[99-Archive/sources/old-article]] (valid_as_of: 2025-10-01, 6개월 경과)
### 🟡 Info (3)
- Tag missing: [[concepts/foo]] → "etl" 태그 없음
- ...
Step 2: 수동 검토 및 조치 (10-15분)
검토자: 위키 마스터
체크리스트:
- Orphans 검토: 고아 페이지가 정말 필요 없는가? (또는 링크 추가 필요?)
- Yes (불필요): 페이지 삭제 검토 또는 아카이브
- No (필요): 역링크 추가
- Broken Links: 링크 수정 또는 섹션명 확인
- Stale Data: 재검증 필요? 또는 valid_as_of 갱신?
- Missing Fields: frontmatter 보완
- Contradictions: 모순 내용 분석 후 수정 또는 명시적 섹션 추가
산출: 수정 목록 + 아카이브 목록
Step 3: 수정 실행 (5-10분, 별도 시간)
주간 린트 수정 세션:
- 시간: 금요일 오후 또는 월요일 오전
- 내용: 린트 리포트의 Major/Medium 이슈 수정
- 기록: log.md에 ”## [YYYY-MM-DD] lint | …” 항목 추가
Process 5️⃣: 업데이트 (Update Metadata)
개요
| 항목 | 값 |
|---|---|
| 주기 | 월 1회 (말일) + 분기 1회 (분기말) |
| 소유권 | 위키 마스터 (1인) |
| 입력 | 린트 결과, 새 sources/concepts, 프론트매터 변경 |
| 산출 | 갱신된 카탈로그 (index.md, CLAUDE.md 규칙) |
| 소요 시간 | 30-45분 |
| SLA | 매월 말일까지, 매분기 말일까지 |
상세 워크플로우
Step 1: 통계 수집 (5분)
수집 항목:
총 Sources: N개
총 Concepts: N개
총 Insights: N개
총 Projects: N개
마지막 업데이트: YYYY-MM-DD
방법: Obsidian vault 통계 또는 수동 카운트
Step 2: wiki/index.md 갱신 (15분)
업데이트 사항:
Projects 테이블:
- 새 프로젝트 행 추가
- Status 변경 반영 (active → closed)
- Updated 필드 갱신
Sources 테이블:
- 새 sources 행 추가
- Updated 필드 갱신
Concepts 테이블:
- 새 concepts 행 추가
- 기존 concepts의 “소스 수” 열 갱신
- Updated 필드 갱신
Insights 테이블:
- 새 insights 행 추가 (분기별로 주로)
Step 3: Frontmatter 메타 검증 (10분)
체크리스트:
- 모든 소스 페이지에
updated필드가 최근 날짜인가? - 모든 concepts의
source_count가 정확한가? - 모든 프로젝트의
deadline,priority,status필드가 유효한가? -
valid_as_of필드가 6개월을 초과한 페이지는 없는가? (있으면 린트 플래그)
Step 4: CLAUDE.md 규칙 동기화 (10분)
검토 항목:
- CLAUDE.md의 파이프라인 설명이 실제 상황과 일치하는가?
- 4가지 인제스트 모드 (A/B/C/D)가 여전히 정확한가?
- 새로운 스킬이나 도구가 추가되었으면 명시했는가?
- 모순 (Contradiction) 발견되었는가? (있으면 주석으로 기록)
수정:
- 실제와 불일치하는 부분 업데이트
- 새로운 규칙 추가 (있으면)
- 마지막 검토 날짜 기록
Step 5: 분기 보고서 작성 (15분, 분기 1회만)
분기 보고서 (wiki/log.md에 추가):
## [YYYY-MM-DD] project | quarterly-update-Q2-2026
### 통계
- Sources 추가: 6개 (누계: 12개)
- Concepts 추가: 2개 (누계: 5개)
- Insights 추가: 1개 (누계: 1개)
### 주요 변화
- Phase 1-2 완료: 5가지 관리 프로세스 정의
- 린트 자동화 정상 작동
### 다음 분기 목표
- Phase 2 시작: 마스터 플랜 초안 작성
- 자동화 우선순위 A 구현주간/월간 스케줄 (칼렌더)
월 (Monday)
├─ 10:00 — Curate: 이번 주 수집 목표 결정 (20분)
├─ 11:00 — Ingest Starts: 수집 진행 (지속)
└─ EOD — log.md에 월간 큐레이션 결과 기록
화~목 (Tue-Thu)
├─ Ingest: 목표 3-5개 수집 (매일 1-2개)
├─ Link: 수집 직후 2-4시간 내 링킹 완료
└─ EOD — log.md에 daily ingest 누적 기록
금 (Friday)
├─ 14:00 — Lint: 자동 검사 + 수동 검토 (25분)
├─ 15:00 — Feedback: 주간 정리 + 다음 주 계획
└─ EOD — log.md에 주간 린트 결과 기록
월말 (Last Day of Month)
├─ 09:00 — Update: index.md + CLAUDE.md 갱신 (40분)
├─ 10:00 — Verification: 메타 검증
└─ EOD — log.md에 월간 업데이트 기록
분기말 (Last Day of Quarter)
├─ 09:00 — Quarterly Report: 분기 보고서 작성 (30분)
├─ 10:00 — Strategy Review: 다음 분기 목표 설정
└─ EOD — log.md에 분기 보고서 기록
자동화 기회 (현재 vs 미래)
현재 (2026-04-27) — 수동 워크플로
| 프로세스 | 자동화 도구 | 자동화 비율 |
|---|---|---|
| Ingest | WebFetch (모드 B), WebSearch (모드 C) | 30% |
| Curate | RSS 피드 자동 필터링 (/curate 스킬) | 40% |
| Link | 수동 synthesis mapping | 0% |
| Lint | /lint 스킬 (자동 검사 + 리포트) | 80% |
| Update | Python 스크립트 (향후) | 0% |
미래 (Phase 2-3) — 자동화 확대
우선순위 A (Phase 2 - High ROI):
- Link 프로세스 50% 자동화: Embedding-based concept matching
- Lint 수정 자동화: frontmatter 자동 보완
우선순위 B (Phase 3 - Medium):
- Ingest 전 자동 평가: 소스 관련성 점수 자동 계산
- Update 메타 자동 갱신: source_count, updated 필드 자동화
에러 처리 및 Edge Cases
Edge Case 1: 같은 source 중복 수집
상황: 이미 수집한 source를 또 수집하려고 할 때
대응:
- raw/ 파일명에 YYYY-MM-DD 붙여서 중복 가능 (버전 추적)
- source_type frontmatter에 “updated source” 명시
- log.md에 “기존 source 업데이트” 기록
Edge Case 2: Source가 분석 완료 후 Concept과 충돌 발견
상황: “근데 이 source의 주장이 다른 concept과 모순이네?”
대응:
- 모순된 두 페이지를 파악
- 더 신뢰할 만한 source/주장 판단
- 약한 주장 페이지에 ”## ⚠️ Contradiction” 섹션 추가:
## ⚠️ Contradiction [[concepts/other]] claims X, but shows Y. → **Resolved by**: [판단 근거]
Edge Case 3: Insight 작성 중 새로운 Concept 발견
상황: 3개 sources 합성 중에 “아, 이건 새 concept을 만들어야겠다”
대응:
- Insight 작성 일시 중지
- 새 concept 페이지 먼저 작성
- Insight에서 해당 concept 인용
- log.md에 “insight 진행 중 concept 발견” 기록
Edge Case 처리 규칙 (Phase 1-5 추가)
Edge Case 1: 같은 Source 중복 수집
상황: 이미 수집한 source를 또 수집하려고 할 때
대응:
- 파일명에 버전 표시:
YYYY-MM-DD-source-name_v2.md(버전 추가) - sources/ 페이지는 최신 내용만: 중복 페이지 생성 안 함
- 로그 기록:
## [2026-04-28] ingest | source-name (UPDATE from 2026-04-27) - Reason: Content update - Previous version: - New version: - 링크 업데이트: sources/ 페이지의 frontmatter URL을 최신 버전으로 변경
판단 기준:
- ✅ 같은 URL의 업데이트된 버전 → _v2 사용
- ❌ 같은 내용의 다른 URL → 폐기 (이미 있음)
Edge Case 2: 관련성 낮은/Abandoned Source
상황: 수집 후 “이거 DAP 도메인과 별로 관련이 없네” 발견
대응:
-
sources/ 페이지 생성 여부:
- ✅ 최소 200자 이상 실질 콘텐츠 → 생성 (향후 복합 분석에 도움 될 수 있음)
- ❌ 200자 미만 또는 스팸 → 생성 안 함
-
Frontmatter에 플래그 추가 (선택사항):
status: "low-relevance" # 또는 "abandoned", "pending-review" note: "Initial assessment: slightly tangential to core DAP topics" -
로그 기록:
## [YYYY-MM-DD] ingest | source-name (LOW RELEVANCE) - Decision: Indexed but not prioritized for synthesis - Reason: [구체적 이유]
판단 기준:
- High: ETL, 데이터 파이프라인, 품질 거버넌스 직접 언급
- Medium: 데이터 분석, 자동화 일반론
- Low: 주변 기술 (보안, DevOps 등)
Edge Case 3: Concept Conflict (모순)
상황: 새로운 source가 기존 concept의 주장과 충돌
대응:
-
해당 concept 페이지에 섹션 추가:
## ⚠️ Contradiction [[99-Archive/sources/old-source]] claims X, but suggests Y. **Reconciliation**: [어느 쪽이 맞는가? 또는 둘 다 맞는 맥락은?] -
로그 기록:
## [YYYY-MM-DD] ingest | source-name (CONFLICT DETECTED) - Conflict with: [[concepts/concept-name]] - Action taken: Added ⚠️ Contradiction section -
Lint에서 플래그: 월간 Lint 시 모든 “Contradiction” 섹션 검토
성공 지표 (KPI)
| KPI | 목표 | 측정 주기 | 추적 방법 |
|---|---|---|---|
| 주간 Ingest | 3-5개 | 주 1회 | log.md 항목 수 |
| Curate 정확도 | High 우선순위 80% 이상 수집됨 | 월 1회 | 수집 vs 큐레이션 비교 |
| Link SLA 이행 | 수집 후 24시간 내 링킹 95% | 주 1회 | log.md 타임스탬프 |
| Lint Pass Rate | Major 이슈 0개 | 주 1회 | lint 리포트 |
| Orphan Pages | 0개 | 주 1회 | lint 리포트 |
| Stale Data | 0개 (6개월 초과) | 월 1회 | lint 리포트 |
관련 개념
- dap-wiki-data-pipeline — 4단계 파이프라인 (원본, 이 문서는 프로세스)
- data-quality-and-governance — 품질 기준 (lint 구현 근거)
메모
프로세스 설계 원칙 (from etl-design-framework와 data-quality-and-governance):
- ✅ 확장성: 매주 3-5개 source 처리 가능하도록 설계
- ✅ 신뢰성: log.md append-only로 모든 작업 추적, 롤백 가능
- ✅ 자동화 준비: 각 프로세스 단계별 자동화 기회 명시
- ⚠️ 거버넌스: 인간의 판단이 필요한 단계 (Curate, Link, Lint 검토) 명확히 표시
다음 Phase (1-3):
- Phase 1-3: 품질 기준 수립 (Frontmatter 스키마, 검증 규칙)