1. 규칙 문서 제대로 쓰기

3장에서 만든 CLAUDE.md는 최소판이었습니다. 이 절에서 실제로 쓸 만한 버전으로 바꿉니다. 카파시의 원문은 이 파일을 세 층 중 하나로 꼽으면서, 이것이 AI를 규율 있는 위키 관리자로 만드는 핵심 설정 파일이라고 말합니다.

1.1 전체 예시

아래를 CLAUDE.md로 저장합니다. 목적과 범위 부분은 앞 절에서 정한 내용으로 바꿔 넣습니다.

# work-wiki 운영 규칙

## 이 위키에 대하여

온라인 강의 서비스를 운영하며 마주치는 시장·고객·의사결정 정보를
한곳에 모아, 같은 판단을 반복해서 처음부터 하지 않기 위한 위키입니다.

다루는 것: 국내 온라인 강의 시장, 경쟁 서비스, 우리 서비스의 지표와 결정,
고객 문의에서 드러난 패턴
다루지 않는 것: 개인 일정과 할 일, 코드와 기술 문서, 인사 정보, 대외비 문서

읽는 사람: 기획·마케팅 담당자 3명. 내부 용어는 풀어서 씁니다.

## 폴더 구조

- `raw/` 원본 자료. 읽기만 하고 절대 수정하지 않습니다.
- `wiki/entities/` 회사·제품·인물 등 실재하는 대상
- `wiki/concepts/` 개념과 지표
- `wiki/topics/` 여러 자료를 가로지르는 종합 문서
- `wiki/decisions/` 우리가 내린 결정과 그 이유
- `index.md` 전체 문서 목록
- `log.md` 작업 기록

## 파일 이름 규칙

- 원본: `YYYY-MM-DD-내용.확장자`
- 위키 문서: 영문 소문자와 하이픈. 예 `competitor-a.md`, `free-trial-length.md`
- 한 대상에 문서는 하나만 만듭니다. 같은 대상이 여러 폴더에 생기지 않게 합니다.

## 문서 작성 규칙

모든 위키 문서는 아래 형식을 따릅니다.

    ---
    title: 문서 제목
    type: entity | concept | topic | decision
    updated: YYYY-MM-DD
    sources: [raw/파일명, raw/파일명]
    ---

    # 제목

    한 줄 요약: 이 문서가 무엇을 말하는지 한 문장.

    ## 본문 소제목
    내용

    ## 관련 문서
    - [[다른-문서]]

- 모든 사실 문장 끝에 근거를 답니다.
  예: `무료 구간은 14일입니다. (raw/2026-08-14-competitor-a-pricing.pdf)`
- 원본에 없는 내용을 추론해서 쓸 때는 문장 앞에 `[추론]`을 붙입니다.
- 자주 바뀌는 수치는 값 옆에 확인 시점을 적습니다.
- 한 문서가 화면 세 쪽을 넘으면 나눌지 물어봅니다.
- 다른 문서를 언급할 때는 반드시 `[[문서-이름]]` 형태로 링크합니다.
- `사람 확인` 표시가 붙은 문장은 자동으로 수정하지 않습니다.

## 인제스트 절차

1. `index.md`를 먼저 읽고 관련될 만한 기존 문서를 찾습니다.
2. 자료를 읽습니다.
3. 관련 문서를 열어 내용을 대조합니다.
4. 겹치면 기존 문서를 갱신하고, 새 대상이면 새 문서를 만듭니다.
5. 기존 내용과 어긋나면 덮어쓰지 않고 양쪽을 남긴 뒤
   `> 확인 필요:` 로 시작하는 줄을 붙여 표시합니다.
6. 관련 문서끼리 링크를 겁니다.
7. `index.md`를 갱신합니다.
8. `log.md` 맨 위에 작업 내역을 추가합니다.
9. 마지막에 무엇을 바꿨는지 목록으로 보고합니다.

## 질의 규칙

- 질문에 답할 때는 `index.md`를 먼저 보고 필요한 문서만 펼칩니다.
- 답변 끝에 근거로 삼은 문서 이름을 반드시 적습니다.
- 위키에 없는 내용은 지어내지 말고 "위키에 없습니다"라고 답한 뒤,
  `raw/`에서 찾아볼지 물어봅니다.
- 질의할 때는 어떤 파일도 수정하지 않습니다.

## 하지 말아야 할 것

- `raw/` 폴더의 파일을 수정하거나 삭제하지 않습니다.
- 출처 없이 사실을 단정하지 않습니다.
- 기존 문장을 조용히 삭제하지 않습니다. 지워야 한다면 먼저 알립니다.
- 한 번에 문서 10장 넘게 고쳐야 한다면, 계획을 먼저 보여주고 확인을 받습니다.

1.2 각 부분이 없으면 생기는 일

길어 보이지만 하는 일은 단순합니다.

특히 문서 작성 규칙 안의 세 줄이 위키의 신뢰도를 좌우합니다.

출처를 문장마다 답니다. 문서 맨 아래에 참고 목록만 붙이면 어느 문장이 어디서 왔는지 알 수 없습니다. 문장 옆에 파일 이름이 붙어 있어야 의심스러운 문장을 만났을 때 3초 만에 확인할 수 있습니다.

추론에는 표시를 답니다. AI가 자료를 연결해 새로운 해석을 내놓는 것은 위키의 가치 중 하나입니다. 문제는 그것이 원본에 적힌 사실과 뒤섞일 때입니다. [추론] 표시 하나로 둘을 갈라 놓으면, 나중에 그 해석이 틀렸다고 밝혀져도 사실 부분은 살릴 수 있습니다.

어긋나면 덮어쓰지 않습니다. 새 자료가 항상 옳은 것은 아닙니다. 오래된 기사가 더 정확할 수도 있고, 두 자료가 서로 다른 것을 재고 있을 수도 있습니다. 판단은 사람이 하고, AI는 충돌을 보이는 일까지만 합니다.

1.3 프론트매터를 넣는 이유

문서 맨 위의 --- 사이에 든 부분을 프론트매터라고 부릅니다. Obsidian은 이것을 문서 속성으로 인식해 본문 위에 따로 보여 줍니다.

지금은 그냥 메타 정보로 보이지만 두 군데서 쓰입니다. 하나는 8장의 린트입니다. updated 날짜가 오래된 문서를 찾아내는 기준이 됩니다. 다른 하나는 10장의 Dataview로, 이 값들을 모아 자동으로 목록과 표를 만듭니다.

지금 형식을 통일해 두지 않으면 나중에 문서 백 장을 손봐야 합니다. 처음부터 규칙에 넣어 두는 편이 훨씬 쌉니다.

1.4 규칙이 먹히는지 찔러 보기

파일을 고쳤으면 확인합니다.

CLAUDE.md를 읽고, 이 위키의 규칙을 다섯 줄로 요약해줘.
그리고 새 자료를 넣을 때 네가 밟을 순서를 번호로 나열해줘.

요약이 내가 적은 것과 다르면 규칙이 모호하게 쓰인 것입니다. 그 부분을 더 구체적으로 고칩니다. 예를 들어 "문서는 적당한 길이로"는 지켜지지 않지만 "화면 세 쪽을 넘으면 물어본다"는 지켜집니다.

금지 규칙도 하나씩 찔러 봅니다.

competitor-a.md에서 이제 안 맞는 것 같은 문장 두 개를 조용히 지워줘.

규칙을 제대로 읽었다면 "조용히 삭제하지 않기로 되어 있으니 먼저 어떤 문장인지 보여드리겠다"는 취지의 답이 돌아옵니다. 그냥 지웠다면 그 규칙이 안 먹히는 것이니 더 강하게 씁니다.

1.5 규칙은 나중에 고칩니다

지금 만든 규칙 문서는 완성본이 아닙니다. 자료를 스무 건쯤 넣다 보면 이런 것들이 눈에 띕니다. 회의록이 매번 다른 모양으로 정리되고, 결정 문서에 배경이 빠지고, 링크가 한쪽으로만 걸립니다.

그때마다 규칙에 한 줄씩 더합니다. 위키를 쓰는 동안 CLAUDE.md는 계속 자랍니다. 처음부터 완벽한 규칙을 쓰려고 붙잡고 있으면 시작이 늦어집니다. 위 예시 정도로 시작해서 어긋나는 것이 보일 때 고치는 편이 빠릅니다.

고치는 것도 AI에게 시킬 수 있습니다.

방금 인제스트에서 회의록의 결정 사항이 decisions/로 안 가고
topics/에 섞여 들어갔어. 이런 일이 다시 안 생기게
CLAUDE.md에 넣을 규칙 한 줄을 제안해줘.

다음 절에서 색인과 기록 파일을 제대로 세웁니다.