Wiki Quality Standards (위키 품질 기준)

Phase 1-3 Deliverable

DAP 위키의 모든 페이지가 만족해야 할 품질 기준. Frontmatter schema, 메타데이터 검증, 링크 규칙, 컨텐츠 기준을 명시.

/lint 스킬과 월간 Update 프로세스가 이 기준을 자동/수동으로 검증.

품질 기준 4가지 축

┌─────────────────────────────────────┐
│  Frontmatter Schema                 │  (타입별 필수/선택 필드)
│  (구조적 정합성)                     │
├─────────────────────────────────────┤
│  Metadata Validation Rules          │  (필드값 정확성 + 논리성)
│  (데이터 일관성)                     │
├─────────────────────────────────────┤
│  Link Validation Rules              │  (그래프 구조)
│  (참조 무결성)                       │
├─────────────────────────────────────┤
│  Content Quality Standards          │  (텍스트 + 구조)
│  (컨텐츠 충실도)                     │
└─────────────────────────────────────┘

1️⃣ Frontmatter Schema (페이지 타입별)

📄 sources/ 페이지

목적: 원본 source의 정보 + 요약 + 링크

필수 필드 (Required)

source_type: "article" | "document" | "video" | "dataset" | "report" | "book"
url: "https://..." | "internal" (for Mode A)
title: "[원본 제목]"  # 1줄, 최대 100자
author: "[저자명]" | "Unknown"
published: "YYYY-MM-DD" | "unknown"
harvested: "2026-04-27"  # 오늘 날짜 (자동 입력)
tags: ["source", "dap", "domain-category", "content-category"]  # 최소 3개

선택 필드 (Optional)

source_count: 1  # 항상 1 (선택사항, 자동 계산 가능)
valid_as_of: "2026-01-19"  # 수치/통계 있으면 필수
summary: "[한 문장 요약]"  # 선택
keywords: ["keyword1", "keyword2"]  # 검색용

검증 규칙

필드	형식	규칙	Lint Check
`source_type`	enum	7가지 중 하나	✅ required
`url`	string	HTTP(S) 또는 “internal”	✅ format check
`title`	string	1-100자	✅ length
`author`	string	1-50자 또는 “Unknown”	✅ length
`published`	date	YYYY-MM-DD 또는 “unknown”	✅ date format
`harvested`	date	YYYY-MM-DD (today)	✅ = today
`tags`	array	≥3 항목, 첫 항목은 “source”	✅ count + first
`valid_as_of`	date	없거나 YYYY-MM-DD	⚠️ required if has numbers

🧠 concepts/ 페이지

목적: 핵심 개념/방법론 정의 + 출처 + 활용

필수 필드

tags: ["concept", "dap", "domain-category", "topic"]  # 최소 3개
created: "2026-04-27"  # 생성 날짜
updated: "2026-04-27"  # 마지막 수정 날짜
sources: ["", ""]  # wikilink 배열
source_count: 2  # sources 배열 길이와 일치해야 함

선택 필드

valid_as_of: "2026-04-27"  # 수치 있으면 필수
aliases: ["concept-alias"]  # 대체 이름
related_insights: [""]  # 관련 insights

검증 규칙

필드	규칙	Lint Check
`tags`	첫 항목은 “concept”, 최소 3개	✅ required
`created`	YYYY-MM-DD, ≤ `updated`	✅ format + logic
`updated`	YYYY-MM-DD, ≥ `created`	✅ format + logic
`sources`	wikilink 배열, 대상 존재	✅ array + broken-link check
`source_count`	= len(sources)	✅ consistency
`valid_as_of`	수치 있으면 필수, 6개월 초과 시 ⚠️	⚠️ conditional

📋 projects/ 페이지

목적: 프로젝트 허브, 진행 상황, 관련 지식 링크

필수 필드

tags: ["project", "dap", ...]  # 첫 항목은 "project"
created: "2026-04-27"
updated: "2026-04-27"
status: "active" | "paused" | "closed"  # 상태
deadline: "2026-05-31"  # YYYY-MM-DD
started: "2026-04-27"
closed: "" | "2026-05-31"  # status=closed일 때만 필수
priority: 1 | 2 | 3  # 1=High, 2=Medium, 3=Low
effort: "S" | "M" | "L" | "XL"  # 예상 소요 시간/복잡도
related_concepts: [""]

선택 필드

related_sources: [""]
related_insights: [""]
related_entities: [""]
outcome: "[프로젝트 완료 조건]"

검증 규칙

필드	규칙	Lint Check
`status`	active/paused/closed	✅ enum
`deadline`	YYYY-MM-DD, ≥ today	⚠️ future check
`started`	YYYY-MM-DD, ≤ `updated`	✅ logic
`closed`	"" (if active) or YYYY-MM-DD (if closed)	✅ conditional
`priority`	1-3	✅ range
`effort`	S/M/L/XL	✅ enum
`related_concepts`	wikilink 배열	✅ array + broken-link

💡 insights/ 페이지

목적: 3개 이상 sources 합성 분석

필수 필드

tags: ["insight", "dap", "synthesis", ...]  # 첫 항목은 "insight"
created: "2026-04-27"
updated: "2026-04-27"
sources: ["", "", ""]  # ≥3
source_count: 3  # ≥3

선택 필드

valid_as_of: "2026-04-27"  # 비교 분석이면 권장
related_concepts: [""]

검증 규칙

필드	규칙	Lint Check
`sources`	배열 길이 ≥ 3	✅ min count
`source_count`	= len(sources), ≥ 3	✅ consistency
다른 필드	concepts와 동일	✅ as above

🏛️ entities/ 페이지

목적: 인물, 도구, 서비스, 조직 카탈로그

필수 필드

tags: ["entity", "dap", "entity-type"]  # 첫 항목은 "entity"
created: "2026-04-27"
updated: "2026-04-27"
entity_type: "person" | "tool" | "service" | "organization"

선택 필드

website: "https://..."
description: "[한 문장 설명]"
sources: [""]  # 언급된 sources
related_concepts: [""]

검증 규칙

필드	규칙
`entity_type`	4가지 중 하나
`website`	HTTP(S) 형식 또는 공백
`description`	1-200자

Entity 추가 정책 (Phase 1-5 추가)

질문: 언제 entity 페이지를 만들 것인가?

타이밍 기준

다음 경우 entity 페이지 생성 권장:

3회 이상 언급 (concept/source 여러 페이지에서 같은 도구/서비스 언급)
- 예: AWS Glue, BigQuery, Databricks가 여러 concepts에 등장
- 조치: entity 페이지 생성 → 도구별 특징·활용·관계 정리
링크의 허브 역할 (여러 concepts의 교점)
- 예: Anthropic, OpenAI (AI 회사 여러 concept에서 참조)
- 조치: entity 페이지로 중앙집중식 관리 + 관련 concepts 링크
비즈니스 의사결정에 영향 (우리 DAP 도메인에서 중요)
- 예: Azure Data Factory (회사의 ETL 인프라)
- 조치: entity 페이지로 기술 평가·비교 정리

실행 방법

소스 수집 후 synthesis mapping 시 도구/서비스 식별
현재 entities/ 확인: 이미 entity 페이지가 있는가?

없으면 생성:

entity_type: "tool" | "service" | "organization" | "person"
website: "https://..."
description: "[한 문장 설명]"
sources: [""]
related_concepts: [""]

주의사항

Phase 1: concepts 먼저 (entity는 선택)
Phase 2: 3회 이상 언급된 도구만 entity로 진격
중복 체크: entities/ 폴더에서 같은 이름의 페이지 있는지 확인

2️⃣ Metadata Validation Rules (메타데이터 검증)

날짜 논리

규칙: 시간의 흐름에 따라 일관성 있어야 함

created ≤ updated  (생성 후 수정 가능)
published ≤ harvested  (발행 후 수집)
started ≤ updated  (시작 후 수정 가능)
closed ≥ started  (시작 후 종료)
deadline ≥ today  (미래 날짜, 과거면 lint warning)

Lint Check:

✅ 모든 date 필드는 YYYY-MM-DD 형식
⚠️ deadline이 과거인 경우 (아직 진행 중인 프로젝트면 수정 필요)
🔴 date 필드가 논리적 순서 위반

배열 일관성

source_count 규칙: frontmatter 배열 길이와 정확히 일치

sources:
  - "[[sources/data-architecture-basics-heartcount]]"
  - "[[sources/data-management-2026-trends]]"
  - "[[sources/etl-pipeline-design-principles]]"
source_count: 3  # ✅ 정확함

Lint Check:

✅ source_count = len(sources)
🔴 불일치 시 자동 수정 또는 경고

valid_as_of 규칙

조건부 필수:

수치, 통계, 버전, 정책 등 시점 의존적 정보 있으면 필수
정의, 개념 설명 등 시점 무관 정보면 선택

6개월 초과 경고:

today - valid_as_of > 180 days → ⚠️ lint warning
"This page's data is stale. Last verified: 2025-10-01"

Lint Check:

✅ 조건부 검사 (페이지 내용 스캔하여 필요성 판단)
⚠️ 6개월 초과 시 lint flag (자동 갱신 아님)

Tags 규칙

필수 구조:

첫 항목: 페이지 타입 (source/concept/project/insight/entity)
두 번째 항목: “dap” (모든 DAP 위키 페이지)
추가 항목: 도메인/주제 태그 (3-5개)

예시:

tags: [source, dap, etl, design-principles]
tags: [concept, dap, data-architecture, storage, lakehouse]
tags: [project, dap, wiki-operations, phase1]

Lint Check:

🔴 첫 항목 ≠ 페이지 타입
🔴 두 번째 항목 ≠ “dap”
🟡 tags 배열 길이 < 3

3️⃣ Link Validation Rules (링크 검증)

Orphan 페이지 (역링크 0개)

정의: 어디서도 언급되지 않는 페이지

원인:

새로 만든 페이지 (아직 아무도 링크 안 함) → ✅ OK (일시적)
불필요한 페이지 (더 이상 쓸모없음) → 🔴 아카이브 또는 삭제 검토
링크 누락 (필요하지만 누군가 링크 깜빡함) → 🟠 링크 추가

Lint Check:

✅ 자동 감지 (Obsidian 그래프 분석)
수동 검토: “이 orphan이 정말 필요한가?”

Broken Links (깨진 링크)

정의: 대상이 없는 wikilink

예시:

[[concepts/non-existent-page]]  # ❌ 페이지 없음
[[concepts/lakehouse-architecture#wrong-section]]  # ❌ 섹션 없음

Lint Check:

✅ 자동 감지 (파일 존재 확인)
🔴 모든 broken link는 자동 fix 또는 수정 필수

양방향 링크 규칙 (Project ↔ Zettel)

원칙: Project → Zettel은 단방향만 (Zettel에서 Project 역링크 금지)

✅ 올바른 예

프로젝트 페이지:

related_concepts:
  - "[[concepts/lakehouse-architecture]]"
  - "[[concepts/etl-design-framework]]"

Concepts 페이지 (프로젝트 역링크 NO):

## 관련 개념
 
- [[concepts/etl-design-framework]] — 데이터 처리
- [[wiki/concepts/data-quality-and-governance]] — 품질 관리

❌ 잘못된 예

Concepts 페이지 (프로젝트 역링크 있음):

[[wiki/work/projects/dap-wiki-ops-master-plan]]에서 사용됨.
← 이것은 위반! Zettel은 project를 모른다.

Lint Check:

🔴 Zettel 본문에서 [[projects/ 패턴 감지 → 경고

Cross-references (개념 간 연결)

규칙: 관련 concepts는 양방향 링크로 명시

예시:

## 관련 개념
 
- [[concepts/etl-design-framework]] — ETL 파이프라인 설계
- [[wiki/concepts/data-quality-and-governance]] — 품질 관리

Lint Check:

🟡 관련 concepts가 최소 1개는 있어야 함 (고아 개념 방지)

4️⃣ Content Quality Standards (컨텐츠 기준)

최소 길이 기준

페이지 타입	최소 길이	기준
sources	200자	핵심 Takeaway + 상세 요약
concepts	500자	정의 + 특징 + 활용
projects	300자	목표 + 컨텍스트 + 진행 상황
insights	300자	합성 분석 (최소 3개 sources)
entities	100자	기본 설명

Lint Check:

⚠️ 최소 길이 미만 시 경고 (자동 수정 아님)

필수 섹션 구조

Sources 페이지

# [제목]
 
> [!note] Key Insight
> 
> 한 문장 통찰
 
## 핵심 Takeaway
 
## 상세 요약
 
(섹션 2-5개, 논리적 흐름)
 
## 연결되는 위키 페이지
 
 — 한 줄 설명

Concepts 페이지

# [개념명]
 
> [!note] Key Insight
> 
> 한 문장 정의
 
## 정의
 
## 특징 / 구조
 
## DAP 위키에서의 활용
 
## 관련 개념
 
 — 한 줄 설명

Projects 페이지

# [프로젝트명]
 
> [!info] Outcome
> 
> 완료 조건
 
> [!quote] Why This Project
> 
> 배경
 
## Context
 
## Knowledge Pulls
 
## Plan
 
## Progress
 
## Next Actions
 
## Risks
 
## Artifacts
 
## Retrospective (Close 시)

Lint Check:

🟡 필수 섹션 누락 시 경고

출처 인용 규칙

규칙: 구체적인 주장 뒤에는 (출처: ) 필수

✅ 올바른 예

AWS Glue는 서버리스 확장성을 제공한다 (출처: [[sources/etl-future-technology-kyobo]]).
 
데이터 거버넌스는 자동화와 인간 판단의 하이브리드 모델이다 
(출처: [[sources/data-management-2026-trends]]).

❌ 잘못된 예

AWS Glue는 좋은 도구다.  # 출처 없음 → ⚠️ 경고
 
레이크하우스는 ACID 트랜잭션을 지원한다 (출처: Wikipedia).  
# [[wiki/concepts/wikilink]] 아님 → ⚠️ 경고

Lint Check:

🟡 “is”, “provides”, “supports” 등 주장 키워드 후 출처 없으면 경고 (휴리스틱)
⚠️ 외부 링크 (http) 인용 감지 → wikilink로 전환 권장

스타일 가이드

마크다운 포맷

요소	규칙
제목	# (H1만 사용, 복수 H1 금지)
부제	또는 (최대 3단계)
강조	`[[wiki/concepts/wikilink]]` 또는 bold (마크다운, 색상 코드 아님)
표	데이터 비교 시 사용 (순수 텍스트 아님)
코드 블록	코드/설정/예시만 포함, 마크다운 설명 아님
이미지	`!` (외부 URL 아님)
링크	내부: “, 외부: `[text](url)`

일관성

용어: “데이터 흐름” vs “데이터 파이프라인” → 한 가지 통일
약자: 첫 사용 시 풀어서 쓰고 “(약자)” 명시
시제: 현재형 (“~하다”) 일관되게

Quality Checklist (자동화된 검증)

매 변경 시 (자동)

☐ Frontmatter 필수 필드 존재?
☐ date 필드가 유효한 YYYY-MM-DD 형식?
☐ wikilink가 실제 페이지를 가리킴?
☐ title이 1-100자?
☐ tags 첫 항목 = 페이지 타입?

주 1회 Lint (자동 + 수동)

☐ Orphan 페이지 (역링크 0개) 검토
☐ Broken links 수정
☐ valid_as_of 6개월 초과 페이지 확인
☐ source_count = len(sources) 일치
☐ Project ↔ Zettel 양방향 링크 위반 확인
☐ 필수 섹션 존재 여부

월 1회 Update (수동)

☐ Frontmatter updated 필드 갱신
☐ CLAUDE.md 규칙과 실제 practice 일치 여부
☐ 새로운 스타일/용어 규약 추가

위반 시 조치

심각도	위반 사항	자동 조치	수동 검토
🔴 Major	Broken link	경고 + 자동 수정	수정 검증
🔴 Major	Broken wikilink in sources	경고	필수 수정
🔴 Major	source_count 불일치	경고	필수 수정
🔴 Major	Project ↔ Zettel 양방향	경고	필수 수정
🟠 Medium	Orphan 페이지	경고	검토 후 링크 추가 또는 삭제
🟠 Medium	valid_as_of 6개월 초과	경고	재검증 또는 갱신
🟡 Info	최소 길이 미만	경고	보완 권장
🟡 Info	필수 섹션 누락	경고	추가 권장
🟡 Info	출처 인용 누락	경고	추가 권장

도구 지원

`/lint` 스킬

자동 실행:

모든 Frontmatter 검증 (Major)
모든 링크 검증 (Major)
스타일 체크 (Info)

수동 검토:

Orphan 페이지 판단 (keep/link/delete)
valid_as_of 갱신 필요 여부

Obsidian Graph View

시각화:

Orphan 페이지 : 고립된 node
Cross-references: 연결된 node
Project-Zettel 방향: 화살표 방향

메모

기준 적용 순서:

Phase 1-3 (현재): 기준 정의 (이 문서)
Phase 1-4: CLAUDE.md 규칙 vs 마스터 플랜 정렬 검증
Phase 2: 자동화 규칙 구현 (hooks, scripts)
Phase 3: 스킬 통합 및 검증

향후 개선:

Lint 자동화 비율 확대 (현재 80% → 95%)
Frontmatter 자동 생성 (Mode B/C 인제스트 시)
스타일 자동 수정 (대소문자, 띄어쓰기 등)

테스트 섹션 (Sprint 4 Week 4 통합 테스트)

2026-04-28: Scenario 2 테스트 - Frontmatter 자동 갱신 검증
Hook이 updated 필드를 자동으로 오늘 날짜로 갱신하는지 확인
Index.md가 이 변경을 정확히 반영하는지 확인

JYP Garden

탐색기

Wiki Quality Standards (위키 품질 기준)

Wiki Quality Standards (위키 품질 기준)

품질 기준 4가지 축

1️⃣ Frontmatter Schema (페이지 타입별)

📄 sources/ 페이지

필수 필드 (Required)

선택 필드 (Optional)

검증 규칙

🧠 concepts/ 페이지

필수 필드

선택 필드

검증 규칙

📋 projects/ 페이지

필수 필드

선택 필드

검증 규칙

💡 insights/ 페이지

필수 필드

선택 필드

검증 규칙

🏛️ entities/ 페이지

필수 필드

선택 필드

검증 규칙

Entity 추가 정책 (Phase 1-5 추가)

타이밍 기준

실행 방법

주의사항

2️⃣ Metadata Validation Rules (메타데이터 검증)

날짜 논리

배열 일관성

valid_as_of 규칙

Tags 규칙

3️⃣ Link Validation Rules (링크 검증)

Orphan 페이지 (역링크 0개)

Broken Links (깨진 링크)

양방향 링크 규칙 (Project ↔ Zettel)

✅ 올바른 예

❌ 잘못된 예

Cross-references (개념 간 연결)

4️⃣ Content Quality Standards (컨텐츠 기준)

최소 길이 기준

필수 섹션 구조

Sources 페이지

Concepts 페이지

Projects 페이지

출처 인용 규칙

✅ 올바른 예

❌ 잘못된 예

스타일 가이드

마크다운 포맷

일관성

Quality Checklist (자동화된 검증)

매 변경 시 (자동)

주 1회 Lint (자동 + 수동)

월 1회 Update (수동)

위반 시 조치

도구 지원

/lint 스킬

Obsidian Graph View

관련 개념

메모

테스트 섹션 (Sprint 4 Week 4 통합 테스트)

그래프 뷰

목차

`/lint` 스킬