뼈대 세우기
1. 뼈대 세우기
위키는 폴더 셋과 파일 셋으로 시작합니다. 이 절에서 그것을 한 번에 만듭니다. 손으로 만들지 않고 AI에게 시킵니다.
1.1 세 개의 층
먼저 무엇을 만들지만 짚고 갑니다. 카파시의 원문은 위키를 세 층으로 나눕니다.
원본 자료는 내가 모은 것입니다. PDF, 회의록, 캡처, 저장한 웹 기사가 여기 들어갑니다. AI는 이 폴더를 읽기만 하고 절대 고치지 않습니다. 여기가 사실의 출처입니다.
위키 문서는 AI가 쓴 것입니다. 요약, 대상별 페이지, 개념 페이지, 비교표, 종합 문서가 여기 쌓입니다. 이 층은 AI가 통째로 소유합니다. 나는 읽고, AI는 씁니다.
규칙 문서는 이 위키를 어떻게 다뤄야 하는지 적어 둔 파일입니다. Claude는 작업 폴더에 CLAUDE.md가 있으면 자동으로 읽습니다. 이 파일이 있느냐 없느냐가 AI를 규율 있는 위키 관리자로 만드느냐 그냥 챗봇으로 두느냐를 가릅니다.
원본을 고치지 않는다는 규칙이 특히 중요합니다. 위키가 틀렸다는 것을 나중에 알게 되더라도 원본이 그대로 있으면 다시 만들면 됩니다. 원본까지 AI가 고쳤다면 돌아갈 곳이 없습니다.
1.2 뼈대를 한 번에 만들기
Cowork 대화창에 아래를 그대로 붙여 넣습니다.
이 폴더에 개인 지식 위키의 뼈대를 만들어줘.
폴더:
- raw/ : 원본 자료를 두는 곳. 너는 읽기만 하고 절대 수정하지 않는다.
- wiki/entities/ : 회사·제품·인물처럼 실재하는 대상
- wiki/concepts/ : 개념과 지표
- wiki/topics/ : 여러 자료를 가로지르는 종합 문서
- wiki/decisions/ : 우리가 내린 결정과 그 이유
파일:
- index.md : 위키 전체 문서 목록. 지금은 빈 골격만.
- log.md : 작업 기록. 최신 항목이 위로 오게.
- README.md : 이 폴더가 무엇인지 세 줄 설명.
각 폴더에는 .gitkeep 같은 빈 파일 대신
그 폴더가 무엇을 담는지 한 줄 적은 README.md를 넣어줘.
만들고 나면 전체 구조를 트리로 보여줘.
만들어진 결과는 이런 모양입니다.
work-wiki/
├── CLAUDE.md
├── README.md
├── index.md
├── log.md
├── raw/
│ └── README.md
└── wiki/
├── entities/
├── concepts/
├── topics/
└── decisions/
Obsidian 쪽 화면을 보면 폴더와 파일이 실시간으로 늘어납니다. 새로고침을 누를 필요가 없습니다. 파일이 생기는 즉시 왼쪽 목록에 나타납니다.

이 실시간 반영이 두 창을 나란히 두는 첫 번째 이유입니다. AI가 무슨 짓을 하는지 말이 아니라 결과로 보입니다.
1.3 규칙 문서 최소판 만들기
이제 CLAUDE.md를 만듭니다. 4장에서 제대로 된 버전을 쓸 것이므로 지금은 짧은 최소판이면 충분합니다. 아래를 붙여 넣습니다.
CLAUDE.md 파일을 만들어줘. 내용은 아래 그대로.
# work-wiki 운영 규칙
## 구조
- raw/ 원본 자료. 읽기만 하고 절대 수정하지 않는다.
- wiki/entities/ 회사·제품·인물
- wiki/concepts/ 개념과 지표
- wiki/topics/ 종합 문서
- wiki/decisions/ 결정과 이유
- index.md 전체 문서 목록
- log.md 작업 기록
## 인제스트 절차
1. index.md를 먼저 읽고 관련될 만한 기존 문서를 찾는다.
2. 자료를 읽는다.
3. 관련 문서가 있으면 갱신하고, 없으면 새로 만든다.
4. 기존 내용과 어긋나면 덮어쓰지 말고 양쪽을 남긴 뒤
`> 확인 필요:` 로 시작하는 줄로 표시한다.
5. 관련 문서끼리 [[문서-이름]] 형태로 링크한다.
6. index.md를 갱신한다.
7. log.md 맨 위에 작업 내역을 추가한다.
8. 무엇을 바꿨는지 목록으로 보고한다.
## 문서 규칙
- 모든 사실 문장 끝에 출처를 단다. 예: (raw/파일명.pdf)
- 원본에 없는 해석은 문장 앞에 [추론]을 붙인다.
- 다른 문서를 언급할 때는 반드시 [[문서-이름]]으로 링크한다.
- 파일 이름은 영문 소문자와 하이픈. 예: competitor-a.md
## 질의 규칙
- 답변 끝에 근거로 삼은 문서 이름을 적는다.
- 위키에 없으면 지어내지 말고 "위키에 없습니다"라고 답한다.
- 질의할 때는 어떤 파일도 수정하지 않는다.
1.4 규칙이 읽히는지 확인하기
파일을 만들었으면 실제로 읽히는지 찔러 봅니다.
CLAUDE.md를 읽고, 새 자료를 넣을 때 네가 밟을 순서를 번호로 나열해줘.
그리고 raw 폴더의 파일 이름에 오타가 있는데 고쳐도 될까?
앞 질문에는 여덟 단계가 나오고, 뒤 질문에는 "raw/는 수정하지 않기로 되어 있다"는 취지의 답이 돌아와야 정상입니다. 금지 규칙을 하나씩 찔러 보면 규칙 문서가 실제로 작동하는지 알 수 있습니다.
이런 확인이 왜 필요한지는 반대 경우를 생각해 보면 분명합니다. 규칙 없이 인제스트를 열 번 하면 어떤 문서에는 출처가 있고 어떤 문서에는 없습니다. 파일 이름이 경쟁사A.md, competitor-b.md, 2026-competitor-c-analysis.md로 제각각입니다. 같은 회사가 entities/와 topics/ 양쪽에 하나씩 생깁니다. 규칙 문서는 이 판단을 매번이 아니라 한 번만 하게 만듭니다.
다음 절에서 자료 한 건을 실제로 넣어 봅니다.