JYP Garden

DAP 위키 데이터 파이프라인 (Raw → Wiki 흐름)

Properties1
tagsconcept, dap, pipeline, data-flow, architecture, knowledge

8 min read

DAP 위키 데이터 파이프라인 (Raw → Wiki 흐름)

Phase 1-1 Deliverable

DAP 위키의 데이터 수집부터 지식 통합까지의 완전한 흐름 맵핑. 4가지 인제스트 모드와 각 단계의 자동화 가능 포인트 명시.

파이프라인 아키텍처 (3단계)

[데이터 원본]
    ↓ (Step 1: Ingest)
[raw/ 불변 원본]
    ↓ (Step 2: Transform)
[wiki/sources/ 정리된 요약]
    ↓ (Step 3: Synthesize)
[wiki/concepts|insights|entities/]
    ↓ (Step 4: Link)
[wiki/projects/ 통합 허브]

Step 1: Ingest (데이터 수집)

목표: 다양한 원본 → raw/ 폴더에 불변 원본 저장

4가지 인제스트 모드

모드입력처리산출자동화예시
A로컬 파일 (사용자 제공)파일을 raw/articles/ 또는 raw/documents/ 에 저장raw file❌ 수동PDF, 다운로드된 문서
BURL (웹 아티클, YouTube, PDF)WebFetch/defuddle로 마크다운 변환 + raw/ 저장raw file + frontmatter✅ 부분블로그, 기술 문서, 뉴스
C자연어 검색 (“공부방 운영 방법”)WebSearch로 후보 발굴 → 사용자 선택 → B 모드 처리raw file + frontmatter⚠️ 게이트 있음주제 기반 자료 수집
DNotebookLM (2개 이상 URL 비교·분석)외부 분석 도구 → 마크다운 결과 → raw/ 저장raw file (합성)✅ 수동 트리거심층 비교·분석

Step 1 결과물:

  • raw/articles/YYYY-MM-DD-*.md — 프론트매터 포함 (source_type, url, author, published, harvested)
  • 특성: 불변 (원본 보존), append-only

Step 2: Transform (정리 및 요약)

목표: Raw 파일 → 위키 소스 페이지로 변환 (정제, 요약, 링크 추가)

변환 프로세스

입력처리 단계산출
raw 파일 1개읽기 → 핵심 Takeaway 추출wiki/sources/SOURCE-NAME.md
→ 상세 요약 (3-5 섹션)with frontmatter (tags, valid_as_of, source_count)
→ 관련 위키 페이지 링크”연결되는 위키 페이지” 섹션

변환 규칙

Frontmatter 필드 (필수):

source_type: article / document / video / dataset
url: [원본 URL]
title: [원본 제목]
author: [저자]
published: YYYY-MM-DD
harvested: 2026-04-27  # 수집 날짜 (today)
tags: [source, dap, ...] # 도메인 태그 + 콘텐츠 태그
source_count: 1  # 항상 1 (원본 1개)
valid_as_of: YYYY-MM-DD  # 수치·통계 있으면 필수

본문 구조:

  1. 핵심 Takeaway (1-2문): “이 소스의 핵심 통찰은?”
  2. 상세 요약 (3-5 섹션): 논리적 흐름에 따라 구조화
  3. 연결되는 위키 페이지: , 링크 + 한 줄 설명

Step 2 결과물:

  • wiki/sources/dap-YYYY-MM-DD-*.md — 정제된 요약 (readability ↑, context ↓)
  • 특성: 기록적 (원본과 1:1 매핑), append-only

Step 3: Synthesize (개념 통합)

목표: 여러 sources → concepts/insights 통합

3-A: Synthesis Mapping (sources → concepts)

기준: “이 sources들이 어느 기존 concept을 강화하거나, 새로운 concept을 만드나?”

5가지 Action Type:

  1. Strengthen — 기존 concept에 새 섹션/근거 추가 (예: lakehouse-architecture에 Lambda/Kappa 추가)
  2. Challenge — 기존 주장에 대한 반박·수정 (예: “과거에는 X였지만 2024년엔 Y”)
  3. Create New Concept — 새로운 개념 도입 (예: “Zero ETL” 같은 신규 트렌드)
  4. Create New Entity — 도구·인물·서비스 추가 (예: AWS Glue, Databricks)
  5. Update Cross-refs — 기존 pages의 링크 갱신

Step 3-A 결과물:

  • Enhanced concepts: wiki/concepts/*.md (source_count 증가, 새 섹션 추가)
  • New concepts (필요 시): wiki/concepts/NEW-CONCEPT.md

3-B: Insights (3개 이상 sources 합성)

기준: “2개 이상 sources를 비교·통합하면 새로운 인사이트가 생기나?”

발동 조건:

  • 3개 이상 sources 필요
  • 각 source가 다른 관점/근거 제공
  • 합성 결과가 새로운 통찰 제시

작성 프로세스:

  1. sources 핵심 비교 (표 또는 다이어그램)
  2. 공통점·차이점 분석
  3. 새로운 인사이트 도출 (Synthesis + NotebookLM 병렬 사용 가능)

Step 3-B 결과물:

  • wiki/insights/DAP-INSIGHT-*.md — 합성 분석
  • 특성: 3개+ sources 인용, synthesis narrative

목표: Concepts/Insights → Projects와 단방향 링크

링크 규칙 (CLAUDE.md 원칙)

방향규칙예시
Project → Zettel✅ 단방향 (frontmatter related_*)[[wiki/work/projects/dap-wiki-ops-master-plan]]의 frontmatter에 [[wiki/concepts/lakehouse-architecture]] 추가
Zettel → Project❌ 금지 (역링크 추가 금지)concepts 본문에 project 링크 쓰지 말 것
Zettel ↔ Zettel✅ 양방향 가능[[wiki/concepts/lakehouse-architecture]] ↔ [[wiki/concepts/etl-design-framework]]

Project의 “Knowledge Pulls” 섹션 구조:

#### [[wiki/concepts/lakehouse-architecture]]
![[concepts/lakehouse-architecture#정의]]
- **소환 이유**: 데이터 저장소 선택 기준
- **활용 지점**: Raw → Wiki 저장소 구조 결정

Step 4 결과물:

  • Updated wiki/projects/dap-wiki-ops-master-plan.md:
    • Frontmatter related_concepts, related_sources, related_insights 배열
    • “Knowledge Pulls” 섹션 채우기

자동화 포인트 (현재 vs 미래)

현재 (2026-04-27) — 수동 워크플로

단계도구빈도대기 시간
Step 1: IngestWebFetch (B), WebSearch (C), 수동 (A/D)Ad hoc5-10분
Step 2: TransformClaude 수동 작성소스당 5분30분/batch
Step 3: SynthesizeClaude 수동 분석batch 후 10분1시간/6sources
Step 4: Link수동 프론트매터 편집마지막 2분5분

미래 (Phase 2) — 자동화 기회

우선순위 A (High) — 빠른 ROI

  1. Step 2 부분 자동화: raw 파일 → “핵심 Takeaway + 섹션 스케치” 자동 생성

    • 도구: Python + Claude API + prompt caching
    • 효과: 변환 시간 50% 단축

  2. Step 4 자동 링크: raw → sources → concepts 매핑 자동화

    • 도구: obsidian-cli hooks + embedding search
    • 효과: 링크 누락 제거

우선순위 B (Medium) — 확장성

  1. Step 3 인사이트 제안: 3개+ sources 자동 감지 → “인사이트 작성?” 제안

    • 도구: Skills 트리거
    • 효과: 인사이트 발견 확률 ↑

  2. 메타데이터 검증: frontmatter 완전성 자동 확인

    • 도구: lint 스킬
    • 효과: QA 비용 ↓

현재 상태 (2026-04-27)

완료

  • Step 1: Batch 1 (3 sources) + Batch 2 (3 sources) = 6 sources 수집
  • Step 2: 6개 sources 정리 완료
  • Step 3: 3개 concepts 강화 (synthesis mapping)
  • Step 4: Project linking (진행 중)

즉시 액션

  1. Step 4 완료: dap-wiki-ops-master-plan frontmatter + Knowledge Pulls 채우기
  2. Step 1 반복: 필요시 추가 sources 수집 (선택사항)
  3. 자동화 계획: Phase 2에서 우선순위 A 항목 구현

관련 개념

메모

파이프라인 설계 원칙 (from etl-design-framework):

  • ✅ 확장성: A/B/C/D 4가지 모드로 다양한 원본 수용
  • ✅ 신뢰성: raw/ 불변 보존 (롤백 가능)
  • ✅ 유연성: 각 단계의 규칙을 설정 기반으로 관리
  • ✅ 모니터링: wiki/log.md append-only 기록
  • ⚠️ 자동화: 현재 부분 자동화, Phase 2에서 확대

다음 Phase (1-2, 1-3):

  • Phase 1-2: 관리 프로세스 정의 (수집·큐레이션·링킹·린트·업데이트 사이클)
  • Phase 1-3: 품질 기준 수립 (Frontmatter 스키마, 검증 규칙)

그래프 뷰