콘텐츠로 이동
🔒 확정공식·정본 문서입니다. 직접 고치지 말고, 바꿀 내용은 PR이나 오너 멘션으로 제안하세요.

D-EDU 사내위키 스펙 (원칙·구조·시나리오)

위키의 원칙 · 카테고리 · 이용 가이드 · 시나리오 · CLAUDE.md 컨텍스트를 담는 단일 기준 문서. 이 문서 자체가 위키의 일부(meta/위키 스펙, policy: protected)이며 같은 하네스로 관리된다.

1. 설계 원칙

  1. Wiki = 확정·히스토리 / Notion = 작업·live. 진행 중 초안은 Notion. 확정·완료된 것만 위키로 이관되어 전역 반영. (위키 = 장기 메모리, Notion = 작업 메모리)
  2. 위키는 사람 가이드이자 에이전트 컨텍스트. 카테고리를 넣으면 에이전트가 그 직무처럼 사고·행동한다. 그래서 카테고리엔 기록뿐 아니라 행동 근거(방법론·철학·템플릿)를 함께 담는다. 1~4 = 전 직무 공통 근거, 직무 탭 = 역할의 사고방식·철학.
  3. SSOT + 직무 탭 규칙. 한 사실은 한 곳에만. 직무 탭은 그 직무만 보는 내용을 자세히 쓰고, 공통은 1~4에 두고 포인팅(링크). 복붙 금지.
  4. 축 = 왜 / 무엇 / 어떻게 / 찾기 / 입구. 1단은 이 질문들로 가른다. (0.메타는 위키 자기관리 축으로 예외.)
  5. 골격 고정, 아래는 자유 증식. 1단·직속 2단은 안정적 그릇. 성장은 3단 이하.
  6. 모든 페이지·영역은 4가지 정책 라벨 중 하나 (건들 곳/말 곳 — 문서 상단에 자동 표시). 표기 없으면 기본 수정가능(living). 배너는 라벨만 달지 않고 '이 문서를 어떻게 다뤄야 하는지' 한 줄 설명을 함께 보여준다(주의는 분산 안 되게 한 줄). type: overview면 정책 라벨에 🗂 목차 칩을 더해 표시(목차이면서 수정가능 등). 수정가능·기록은 작성자·날짜·변경요약을 함께 남긴다 — 작성자는 Claude가 컴파일하면 Claude, 사람이 쓰면 사람 이름. 출처(예: 노션 원문 무손실 컴파일)는 change에 적는다. 기록(append-only)이 어떤 포맷으로 쌓이는지는 [doc-templates](../4-reference/doc-templates.md)의 templates/log에 정의 — 새 항목은 위에, 기존 줄 보존, 엔트리 헤더는 ## YYYY-MM-DD · 제목.
내부 키 라벨 설명 색
protected 🔒 확정 공식·정본 문서. 대표/오너 승인 없이 직접 고치지 말고 PR로 제안. 빨강
living ✍️ 수정가능 누구나 고쳐도 됨. 고친 뒤 작성자·갱신일·변경요약을 남긴다. 파랑
append-only 🗓️ 기록 기존 내용은 지우지 말고 날짜와 함께 아래로 붙인다. 초록
derived ⚙️ 자동 시스템이 자동 생성. 손대지 말고 소스를 고친다. 회색
overview 🗂 목차 그 영역의 지도(카테고리 index). 정책 라벨과 함께 표시 — 보통 ✍️ 수정가능 칩이 같이 뜬다. 인디고
7. 추적의 진실은 이슈트래커. 완료여부는 위키에 직접 안 쓰고 GitHub Issue 링크. 이슈 닫히면 상태=완료.
8. 자족성 + 출처(provenance). 모든 페이지는 그 자체로 읽혀야 한다 — 원본을 파싱·요약해 본문에 담아 90% 이상 자족. 동시에 raw 원본을 가리키는 출처 포인터(source)를 품어 정직성을 지킨다. 내용 없이 포인터만 있는 페이지는 금지. 길면 쪼개고 링크. 모든 카테고리는 개요(_index)를 갖고, 클릭 시 개요가 열리며 사이드탭에 하위가 펼쳐진다(구성은 §2).
9. 공개 영역. 메인 '/'은 리크루팅 목적의 잘 디자인된(이쁜) 공개 문서. 공개(public)/비공개(private) 구분이 존재한다 — 범위는 추후 결정.
10. 문서 템플릿. 각 type은 정해진 템플릿을 따른다. 초반엔 Obsidian으로 틀을 만들고, 이후엔 CLAUDE.md 하네스("같은 type 이전 형식 참고")로 자동 일관화.
11. 기존 Notion 비즈니스 전략 wiki를 참고 기준으로 카테고리 보완. (구조 추후 공유)
12. 시나리오가 구조의 근거다. 모든 노드는 최소 1개 시나리오로 정당화. 새 필요는 경량 규칙으로 진화(§6).

2. 카테고리 구조

D-EDU 사내위키          ('/' = 리크루팅 랜딩)
│
├─ 0. 위키 운영(메타)  meta  🗂 목차
│   ├─ 위키 스펙 (이 문서)            protected
│   ├─ 오너 레지스트리 (영역→담당)      living
│   ├─ 시나리오 레지스트리  scenarios    append-only
│   ├─ 변경 로그  changelog             append-only
│   └─ 카테고리↔시나리오 추적표          derived
│
├─ 1. 팀·브랜드  team-brand            [왜]  protected
│   ├─ 미션·비전 / 스토리 / 가치
│   └─ 브랜드 가이드 (보이스&톤 / 비주얼 / 포지셔닝) 
│
├─ 2. 제품  product                    [무엇]  🗂 목차
│   ├─ 고객·시장 이해  insight  🗂 목차
│   │   ├─ 페르소나                 living
│   │   ├─ 시장·경쟁사 인텔          living
│   │   ├─ 유저 피드백  feedback      append-only
│   │   ├─ 아이디어 백로그  ideas     append-only  (지속 인테이크 로그·상태는 태그 / 진행 PRD 아이디어는 Notion)
│   │   └─ 유저 리서치  research
│   │       ├─ 리서치 기록            append-only
│   │       ├─ 리서치 방법론          living   (cross-role 원본)
│   │       └─ 폼·템플릿              living
│   └─ 빌드  build  🗂 목차
│       ├─ 프로덕트/사업 라인  lines
│       │   └─ [라인] > 기능 [feature]   = 스펙 컨테이너
│       │       ├─ 개요 / PRD(기획) / 디자인 스펙(디자인) / FRD(개발)   living
│       │       ├─ 상태  derived  / 릴리즈 노트  append-only
│       ├─ 로드맵                 living
│       └─ 비즈니스 모델           living
│
├─ 3. 운영  operations                 [어떻게 — 공통/교차]  🗂 목차
│   ├─ 함께 일하는 법              living
│   ├─ AI 협업 원칙 (하네스 엔지니어링)  living   ← 전사 공통 (각 hub는 적용만 링크)
│   ├─ 교차 플레이북  playbooks    living   (역할 전용 SOP는 hub로)
│   │   ├─ 릴리즈 공지 / 전사 CS 정책
│   │   ├─ QA 플레이북
│   │   └─ GTM / 런치 체크리스트
│   ├─ 스프린트 (목표·성과·회고)  sprints   append-only
│   ├─ 도구·계정 (접근·admin)      living
│   ├─ 회의록  meetings           append-only
│   ├─ 의사결정 기록  decisions    append-only
│   ├─ 액션 보드  action-board     derived
│   └─ 재무 / 정책                 living
│
├─ 4. 레퍼런스  reference  [찾기]  living  (공통만)
│   ├─ 용어집 / 공통 템플릿(문서 형식) / 외부자료 / FAQ
│   ├─ 방법론·리터러시 (실험 설계·A/B · 지표 리터러시)   ← 전사 공통 (각 hub는 적용만 링크)
│   └─ 학습 자료 (세미나·컨퍼런스 기록 append-only / 추천 도서 living)
│
└─ 5. 직무별 탭  hubs   [입구 + 전용 심화 · 팀 소유 · 에이전트 페르소나]  🗂 목차
    │  표준 레이아웃: 온보딩(R&R) → 내 작업(derived) → 전용 심화(사고방식·철학) → 공통 링크
    │
    ├─ 개발  hub-eng
    │   ├─ 개발 온보딩 (R&R)
    │   ├─ 내 작업(기능)  derived
    │   │  ── 사고방식·철학 ──
    │   ├─ 엔지니어링 원칙 & 트레이드오프
    │   ├─ 기술 의사결정 (ADR · 빌드 vs 바이 · 도입 기준)
    │   ├─ AI 협업 적용 (Claude Code 실무 — → 운영/AI 협업 원칙)
    │   │  ── 전용 실무·심화 ──
    │   ├─ 인프라 (온프레미스 / Cloudflare / CI·CD / 시크릿)
    │   ├─ 버전 관리 (브랜치 / 커밋·PR / 코드리뷰)
    │   ├─ 아키텍처 (Slack·GitHub↔Claude Code / MCP)
    │   ├─ 테스트 / 배포 절차 / 런북
    │   ├─ 인시던트 아카이브  incidents   append-only   (→ 런북)
    │   └─ (링크) 페르소나 · 기능 스펙 · 도구·계정 · QA 플레이북 · AI 협업 원칙
    │
    ├─ 마케팅  hub-mkt
    │   ├─ 마케팅 온보딩 (R&R)
    │   ├─ 내 작업(캠페인)  derived
    │   │  ── 사고방식·철학 ──
    │   ├─ 마케팅 원칙 & 메시징 철학 (PASONA · SUCCESs · Cialdini)
    │   ├─ 채널 전략 & 믹스 의사결정
    │   ├─ 그로스 실험 (마케팅 적용 — → 레퍼런스/방법론)
    │   ├─ 지표 & 어트리뷰션 (마케팅 적용 — → 레퍼런스/방법론)
    │   │  ── 전용 실무·심화 ──
    │   ├─ 채널별 플레이북 / 콘텐츠 파이프라인 / 퍼널·전환
    │   ├─ 콘텐츠 자동화 적용 (AI 파이프라인 — → 운영/AI 협업 원칙)
    │   ├─ 캠페인 로그  campaign-log   append-only   (→ 플레이북·페르소나)
    │   └─ (링크) 브랜드 가이드 · 페르소나 · 유저 피드백 · 유저 리서치 방법론 · GTM 체크리스트
    │
    ├─ 기획/PM  hub-pm
    │   ├─ 기획 온보딩 (R&R)
    │   ├─ 내 작업(기능/PRD)  derived
    │   │  ── 사고방식·철학 ──
    │   ├─ 우선순위 & 범위 의사결정 프레임워크
    │   ├─ 실험 설계 (제품 적용 — → 레퍼런스/방법론)
    │   ├─ 지표 & 데이터 해석 (PM 관점 — → 레퍼런스/방법론)
    │   ├─ CCPM & AI 워크플로 적용 (제로원 특화 — → 운영/AI 협업 원칙)
    │   │  ── 전용 실무·심화 ──
    │   ├─ 스프린트 운영 (스윔레인·스크럼 — 방법만)
    │   ├─ 요구사항 작성 가이드
    │   └─ (링크) 유저 리서치 방법론 · QA 플레이북 · GTM 체크리스트
    │            · 유저 피드백 · 아이디어 · 페르소나 · 로드맵
    │            · 기능 스펙 · 스프린트 목표 · 의사결정 · 비즈니스 모델
    │
    ├─ 디자인  hub-design
    │   ├─ 디자인 온보딩 (R&R)
    │   ├─ 내 작업(디자인 스펙)  derived
    │   │  ── 사고방식·철학 ──
    │   ├─ 디자인 원칙 & 철학
    │   ├─ UX 의사결정 프레임워크 (사용성·접근성 판단)
    │   ├─ 인터랙션 & 정보구조 패턴
    │   ├─ 디자인 비평(critique) 방식
    │   │  ── 전용 실무·심화 ──
    │   ├─ 디자인 시스템 (컴포넌트·토큰)
    │   ├─ Figma 워크플로 (MCP / Code Connect)
    │   ├─ AI 디자인 적용 (Claude Design — → 운영/AI 협업 원칙)
    │   ├─ 개발 핸드오프 가이드
    │   └─ (링크) 브랜드 가이드 · 페르소나 · 유저 리서치 방법론
    │
    └─ 신규입사자(공통)  hub-onboarding   derived
        └─ 미션→스토리→가치→페르소나→제품 (서사 순서)

모든 영역에 라벨이 붙는다. 1단 축·2단 분류 폴더의 개요(_index)는 🗂 목차(overview), 그 아래 실제 문서는 위 §1.6 라벨(확정/수정가능/기록/자동) 중 하나. 노드 옆 영문=슬러그, 그 뒤=라벨(없으면 수정가능).

1단 포함/제외 경계선

  • 메타 = 위키 자신 관리. 팀·브랜드 = 정체성 + 리크루팅.
  • 제품 = 무엇 + 고객/시장 이해. 운영 = 어떻게(공통/교차) + 실행 리듬 + 전사 공통 원칙(AI 협업).
  • 레퍼런스 = 맥락 없이 찾는 공통 사실·자료·방법론. 직무별 탭 = 역할 입구 + 직무 전용(사고방식·철학) + 공통 포인팅.

표기 규칙

  • 노드 옆 영문 = 슬러그, 그 뒤 = policy(없으면 living).
  • 템플릿 위치: 문서 형식 템플릿 → 레퍼런스/공통 템플릿 / 리서치 도구(폼) → 제품/유저 리서치/폼·템플릿.

개요(_index) 구성 (모든 카테고리 필수 · policy: living)

클릭 시 열리는 그 영역의 지도+요약. 다음 5가지를 담는다: 1. 무엇·왜 — 한 줄 목적 + 포함/제외 경계 2. 여기 있는 것 — 하위 노드 지도 (각 한 줄 설명 + 링크) 3. 여기서 시작하라 — 핵심·자주 찾는 문서 링크 4. 오너 · 갱신일 5. 관련 — 다른 카테고리 링크 ※ 직무 hub 개요엔 R&R + 그 직무 사고방식 한 줄을 추가. ※ 개요는 간결하게 — 사이트에서 클릭하면 "이 영역이 뭐고 뭐가 들어있나"를 30초에 파악하는 지도. 긴 설명은 하위 문서로.

표시·제목 규약 (사이트 렌더링)

  1. policy 영역 배너 — 모든 문서 상단에 4상태(protected/living/append-only/derived) 또는 overview에 따른 한 줄 배너가 자동 표시된다(.mkdocs/policy_banner.py). "이 문서를 어떻게 다뤄야 하나"를 사람·LLM에게 즉시 알린다. → 본문에 "이건 living이다" 식 설명을 중복으로 쓰지 않는다.
  2. 제목 = H1 — frontmatter title과 본문 # H1은 반드시 동일. 두 개로 보이면 안 된다.
  3. 사람이 읽는 제목 — 슬러그(결제-환불-정산-정책-수립)가 아니라 자연어(결제·환불·정산 정책). 불필요한 하이픈 금지, 단어 구분은 공백/가운뎃점(·). 코드 클래스명만 괄호로(회원 도메인 (Member)). 표준 약어(AI·QA·GA·UX·Figma·FRD…) 허용.
  4. 카테고리 분류 폴더 = 토글 — 순수 분류용 2단 폴더(예: 2-product/build·insight)는 클릭 시 펼침 위주. 실질 내용은 그 하위(예: business-model)가 담당하고 거기서 policy 배너가 작동.
  5. 기계어 금지 — 사람이 읽도록 쓴다. 표·불릿 나열만 X, 맥락·이유를 문장으로. 빈 헤더·"상세는 raw" 때우기 금지(원칙 8).
  6. 정직성 — 없으면 "내용 추가 필요". 채울 실제 자료(raw·확정본)가 있으면 본문에 컴파일한다. 없으면 기계로 때우지 말고 그 섹션을 !!! warning "🚧 내용 추가 필요" 블록으로 표시하고 무엇이 필요한지 한 줄 적는다(사람이 채울 단서). 가짜 충실함보다 정직한 공백이 낫다.

3. 이용 가이드 — 이럴 땐 이렇게

스프린트가 끝났다 (Notion → Wiki) → Notion 확정본을 위키로 이관: 기능 컨테이너 + 라우팅대로 전역 반영(릴리즈노트·용어집·페르소나/로드맵·의사결정). 진행 중 초안은 위키에 안 올린다.

결과를 남기고 싶다 → 해당 로그에 추가(과거 수정 금지) → 바뀐 현재 기준은 정리본에 반영하고 로그 링크.

기능 완료 확인 → 기능 상태/운영 액션 보드. 이슈 닫히면 자동 완료.

내 할 일 / 새 기능 → 내 hub "내 작업" 뷰. 새 기능은 제품/빌드/라인/기능 폴더에 PRD·디자인·FRD 함께.

에이전트를 그 직무처럼 동작 → 해당 직무 탭 + 1~4를 컨텍스트로. hub엔 사고방식·철학, 온보딩엔 R&R.

AI 워크플로/실험/지표를 다룬다 → 공통 원칙은 운영(AI 협업 원칙)·레퍼런스(방법론·리터러시)에서 보고, 역할별 적용은 내 hub에서.

문서가 길다 / 어디 적을지 모른다 → 쪼개고 링크(빈 페이지 금지). 위치는 §6 라우팅 → 없으면 meta/scenarios + §6 변경 규칙.

4. 시나리오 레지스트리 (meta/scenarios · append-only)

ID 시나리오 상태 충족 위치
S1 마케터가 마케팅 전략을 수립한다 ✅ 브랜드 가이드 · 페르소나 · 시장·경쟁사 인텔 · 기능 카탈로그 · 캠페인 로그
S2 마케팅 결과·인사이트가 히스토리로 쌓여 다음 기획에 반영 ✅ 캠페인 로그(append) → 채널 플레이북·페르소나·포지셔닝(링크 반영)
S3 개발자가 PRD를 보고 FRD를 작성 (wiki만으로) ✅ 기능 스펙 컨테이너(개요·PRD·디자인·FRD 공존)
S4 운영 중 오류 → 과거 사례 확인 + 신규 적재 ✅ 런북 + 인시던트 아카이브(append)
S5 기획자가 피드백·아이디어·전영역으로 PRD 초안 ✅ 제품/고객·시장 이해(피드백·아이디어·리서치·페르소나)
S6 기획변경 → FRD 반영 → 완료 추적 ✅ PRD↔FRD 링크 + 상태(이슈 rollup)
S7 디자이너가 톤·브랜딩 정보를 추출 ✅ 브랜드 가이드 + 디자인 시스템
S8 건들 곳/말 곳 가이드(하네스)가 정의됨 ✅ 원칙 6(4상태) + §5 + CLAUDE.md
S9 회의 결정 → 액션플랜 → 완료 통합 ✅ 회의록 → 의사결정(액션아이템) → 액션 보드
S10 클릭 드릴다운 + 벡터검색으로 원하는 정보 ✅ 계층 트리 + frontmatter(type·owner·tag)
S11 방대 내용은 링크아웃/하위트리로 무한 확장 ✅ 원칙 8 + §6 확장 규칙
S12 에이전트가 직무처럼 사고·행동 ✅ 직무 탭(철학·R&R) + 1~4 공통 컨텍스트(원칙 2)
S13 Notion 작업 → Wiki 확정 이관 ✅ 원칙 1 + §3 핸드오프
S14 리크루팅 공개 메인 + 공개/비공개 분리 ✅ 원칙 9
S15 type별 템플릿 자동 일관화 ✅ 원칙 10 + §6 템플릿 하네스
S16+ (§6 변경 규칙으로 추가) — —

5. 콘텐츠 4상태 상세 (원칙 6 참고표)

상태 policy 규칙 예
보호 protected 오너 승인 없이 수정 금지 미션·가치·브랜드·위키 스펙
정리본 living 항상 최신화, 오너 검토 (기본값) 페르소나·기능 스펙·방법론·플레이북·원칙
로그 append-only 기존 수정/삭제 금지, 추가만 피드백·아이디어·캠페인·인시던트·회의록·스프린트·의사결정
파생 derived 자동 생성, 직접 수정 금지 내 작업 뷰·상태·액션 보드

6. 운영 · 하네스 (포인터)

상세 규칙은 중복하지 않고 가리킨다. - 에이전트 운영 규칙 → repo 루트 CLAUDE.md (편집 정책·라우팅·카테고리 지도·불변 규칙). - 문서 템플릿 16종 → reference/templates/{type}.md (공통 골격 요지→본문→source→links). - 하드 하네스(반드시 강제): protected→CODEOWNERS+브랜치보호 / append-only→CI diff 검사 / 자족성+출처→PostToolUse hook / derived→생성 Action · issue-close→상태 sync. - 직무처럼 사고: 직무별 subagent(hub-*+1~4) / 검수: 읽기전용 wiki-reviewer subagent. - 구조 변경(경량): 새 필요→meta/scenarios append→가장 낮은 레벨부터(문서<3단<2단<1단). hub 내부=팀 오너 자유 / 1~4=오너 검토. 모두 meta/changelog append.

7. 파일 배치

<repo>/
└─ llm-wiki/
   ├─ CLAUDE.md                      ← 위키 작업 시 로드 (path-scoped)
   ├─ 0-meta/
   │   ├─ 위키-스펙.md               ← 이 문서 (protected)
   │   ├─ scenarios.md  changelog.md  owner-registry.md
   ├─ 1-team-brand/  2-product/  3-operations/  5-hubs/hub-*/
   └─ 4-reference/
       └─ templates/{type}.md        ← 템플릿 17종 (overview·prd·frd·principle…)
- llm-wiki/CLAUDE.md는 @0-meta/위키-스펙.md(깊은 맥락)와 4-reference/templates/(틀)를 가리킨다. - 직무 전용 맥락은 5-hubs/hub-*/CLAUDE.md(폴더별)나 subagent에 — 루트는 가볍게.