4장. 첫 번째 주제 위키 만들기 원문 기반 정리
소스 경로: data/runtime/write-agents/LLM wiki reference analyses/md/wikidocs/chapters/04-first-topic-wiki.md
4장은 LLM위키를 실제 업무에 적용하는 첫 실행 장이다. 핵심은 큰 지식베이스를 만들려 하지 않고, 다음 주에 실제로 쓸 작은 업무 질문 하나를 고른 뒤 원천 자료, 최소 폴더 구조, 첫 질문, 다음 자료 수집 목록까지 남기는 것이다.
원문과 확인 범위
- 장 원문: 4장. 첫 번째 주제 위키 만들기
- 원천 도서: LLM위키 완벽 가이드
- 하위 원문: 4.1 업무 주제 정하기, 4.2 위키 초기화하기, 4.3 첫 질문으로 방향 잡기
- 확인일: 2026-06-06 KST
- 확인 범위: 장 랜딩 페이지의 절 구성, 4.1-4.3 세부 원문, 현재 로컬 세부 페이지 분석 본문
원문이 추가 근거로 언급한 참고 자료는 Andrej Karpathy LLM Wiki Gist, nvk/llm-wiki GitHub 저장소, nvk/llm-wiki Releases, OpenAI Codex AGENTS.md 문서, Anthropic Claude Code memory 문서, WiCER 논문이다.
핵심 요지
4장은 1-3장에서 정한 필요성, 구조, 도구 선택 원칙을 실제 첫 위키로 전환하는 실행 장이다. 장 랜딩 원문은 세 하위 절 목록 중심의 짧은 입구이며, 실질 내용은 4.1의 주제 축소, 4.2의 최소 구조 초기화, 4.3의 첫 질문 설계를 함께 읽어야 완성된다.
이 장의 결론은 첫 위키를 크게 만들지 말라는 것이다. 첫 위키는 회사 전체 지식베이스나 업무 자동화 전체를 담는 창고가 아니다. 다음 주에 실제로 쓸 작은 업무 질문 하나, 확인 가능한 원천 자료 3-5개, 사람이 직접 검증할 수 있는 성공 기준을 가진 작업 공간이어야 한다.
4.2는 선택한 주제를 실제 파일 구조로 고정한다. 최소 구조는 raw/, wiki/, output/, index.md, log.md, AGENTS.md이며, Claude Code를 쓰는 경우 CLAUDE.md를 선택적으로 둘 수 있다. 핵심은 폴더 이름이 아니라 책임 분리다.
4.3은 첫 질문을 단순 요약 요청이 아니라 위키 기반 업무 질문으로 바꾼다. 좋은 첫 질문은 현재 위키의 자료 범위, 답변 목적, 출력 형식, 근거 부족 표시 기준을 포함한다. 첫 답변은 완성본이 아니라 다음 자료 수집 방향을 드러내는 진단 도구로 다룬다.
원문 구조
| 원문 | 역할 | 핵심 내용 | 다음 단계 산출물 |
|---|---|---|---|
| 4장 랜딩 | 실행 장의 입구 | 4.1, 4.2, 4.3으로 구성됨을 안내한다. | 세 하위 절을 순서대로 읽는 탐색 경로 |
| 4.1 업무 주제 정하기 | 주제 축소 | 큰 업무 영역을 다음 주에 쓸 작은 업무 질문으로 줄이고 첫 자료 3-5개와 성공 기준을 정한다. | 첫 업무 주제, 원천 자료 후보, 성공 기준 카드 |
| 4.2 위키 초기화하기 | 초기 구조 작성 | raw/, wiki/, output/, index.md, log.md, AGENTS.md, 선택적 CLAUDE.md를 만든다. | 최소 폴더 구조, 작업 규칙 파일, 구조 점검 결과 |
| 4.3 첫 질문으로 방향 잡기 | 첫 질문 설계 | 업무 질문을 위키 질문으로 바꾸고 확인된 내용, 제한된 추정, 추가 자료를 나눈다. | 첫 질문, 초기 답변 라벨, 다음 자료 목록 |
세 절은 순서가 바뀌면 위험해진다. 4.1 없이 구조부터 만들면 범위가 너무 커지고, 4.2 없이 질문부터 던지면 원천과 요약과 산출물이 섞이며, 4.3 없이 자료만 넣으면 위키가 질문 가능한 업무 시스템이 아니라 파일 모음으로 남는다.
장 수준 합성
1. 첫 위키는 관심사가 아니라 검증 가능한 업무 질문으로 시작한다
4.1은 첫 위키의 실패 원인을 큰 주제에서 찾는다. 업무 자동화 전체, 마케팅 지식 전체, 개발 문서 전체처럼 넓은 주제는 자료가 끝없이 늘고 질문도 흐려진다. 첫 주제는 한 번에 답할 수 있는 업무 질문으로 줄여야 한다.
| 항목 | 작성 내용 | 합격 기준 |
|---|---|---|
| 큰 업무 영역 | 처음 떠오른 넓은 관심사 | 줄이기 전 원재료로만 사용한다. |
| 첫 위키 주제 | 한 번의 업무 질문으로 줄인 주제 | 다음 주에 실제로 쓸 수 있다. |
| 원천 자료 후보 | 회의록, 문의 목록, 공식 문서, 메모 등 3-5개 | 날짜, 출처, 자료 성격을 적을 수 있다. |
| 첫 질문 | 자료 범위와 출력 형식이 있는 질문 | 단순 요약 요청이 아니다. |
| 성공 기준 | 사람이 확인 가능한 행동 기준 | 문서 수가 아니라 다음 업무가 쉬워졌는지 본다. |
2. 첫 자료 묶음은 수집량이 아니라 근거 가능성으로 고른다
첫 위키의 원천 자료는 짧고, 출처가 분명하며, 다시 확인할 수 있어야 한다. 회의록, 업무 메모, 고객 문의 목록, 공식 문서 일부, 반복 보고서 양식은 적합한 후보가 될 수 있다. 오래된 대화 전체, 출처가 섞인 복사본, 기억에 의존한 요약 메모, 민감 정보가 그대로 들어간 문서는 첫 자료로 위험하다.
민감 정보도 이 단계에서 먼저 처리해야 한다. 이름, 이메일, 고객명, 계약 조건, 내부 금액 같은 정보가 LLM 도구나 플러그인에 들어가기 전에 조직 보안 기준을 확인하고, 실습용 복사본이나 익명화 기준을 정한다.
3. 성공 기준은 문서 수가 아니라 다음 업무의 쉬워짐이다
좋은 성공 기준은 관찰 가능해야 한다. 회의록 위키라면 최근 회의록 3개에서 실행 항목을 빠짐없이 찾는지, 각 실행 항목에 담당자와 기한과 확인 방법이 붙는지, 미확정 항목을 확정된 항목처럼 쓰지 않는지, 정리 문서에서 원천 회의록으로 돌아갈 수 있는지가 기준이 된다.
4. 초기화는 빈 폴더 만들기가 아니라 운영 계약 만들기다
| 위치 | 책임 | 첫 내용 | 실패 신호 |
|---|---|---|---|
raw/ | 원본 자료 보관 | 회의록, 메모, 웹 문서 저장본 | 요약문이 원본을 덮어쓴다. |
wiki/ | 정리된 지식 작성 | 개념 정리, 질문별 답변, 요약 | 근거 없는 단정이 쌓인다. |
output/ | 업무 산출물 작성 | 보고서, 실행 계획, 공유용 초안 | output이 원본의 유일한 사본이 된다. |
index.md | 위키 입구 | 문서 목록, 주요 질문, 없는 자료 | 어디서 시작할지 알 수 없다. |
log.md | 처리 이력 | 구조 생성, 자료 추가, 문서 갱신 | 언제 왜 바뀌었는지 추적할 수 없다. |
AGENTS.md | LLM 작업 기준 | raw 보존, 근거 표시, 확인 필요, log 갱신 | 요청마다 처리 방식이 달라진다. |
CLAUDE.md | Claude Code 선택 규칙 | AGENTS.md 참조 또는 추가 규칙 | 도구별 규칙이 어긋난다. |
rules 파일은 보안 강제 장치가 아니라 작업 기준이다. 따라서 파일을 만들었다는 사실보다 결과물이 실제로 raw를 보존하고, 근거와 확인 날짜와 확인 필요를 남기고, index와 log를 갱신했는지가 더 중요하다.
5. 첫 질문은 현재 위키의 한계를 드러내야 한다
좋은 첫 질문은 현재 위키의 어떤 자료를 기준으로 답할지, 무엇을 결정하려는지, 어떤 출력 형식이 필요한지, 근거 부족 항목을 어떻게 표시할지 요구한다.
현재 위키의 [자료 범위]만 기준으로 [결정 또는 실행 목적]을 위해 답해 주세요.
출력은 [표/목록/비교 기준/실행 계획] 형식으로 작성해 주세요.
확인된 내용, 제한된 추정, 추가로 필요한 자료를 분리해 주세요.
각 핵심 문장에는 근거 위치를 붙이고, 출처가 없는 단정은 하지 마세요.
마지막에는 다음 질문 후보와 index/log에 반영할 항목을 제안해 주세요.
첫 답변에서 중요한 것은 결론이 아니라 빈틈이다. 근거가 약한 문장, 추정으로 표시된 문장, 확인 필요로 남은 항목을 찾고 이를 다음 자료 목록으로 바꾸는 흐름이 5장의 자료 수집 기준과 6장의 답변 검증 루프로 이어진다.
6. 답변의 빈틈은 다음 수집과 검증으로 넘긴다
| 초기 답변의 빈틈 | 필요한 다음 자료 | 다음 행동 | 연결되는 장 |
|---|---|---|---|
| 자동화 효과가 클 가능성이 있으나 근거가 약하다 | 최근 회의록 정리 소요 시간 | 작업 시간을 기록하거나 기존 기록을 찾는다. | 5.1, 5.2 |
| 실행 항목 형식이 반복된다고 했지만 표본이 적다 | 회의록 3-5개 | raw/meeting-notes/에 원천을 추가한다. | 5.2 |
| 검토자가 자주 수정한다고 했지만 사례가 없다 | 검토 코멘트 또는 수정 요청 5개 | 수정 사례를 메모로 남기고 민감 정보 여부를 확인한다. | 5.3 |
| 자동화 후보 판단이 다른 후보와 비교되지 않았다 | 후보별 빈도, 영향, 난이도 비교표 | 비교 기준을 만들고 제한적 추정으로 낮춘다. | 6.2 |
실무 적용 절차
- 최근 1-2주 안에 LLM에게 맡기고 싶었던 업무를 넓게 적는다.
- 각 후보가 다음 주 안에 실제로 쓸 일인지 확인하고, 당장 쓸 일이 아니면 보류한다.
- 남은 후보를 한 번의 업무 질문으로 줄인다.
- 후보마다 원천 자료 3-5개를 적고 자료명, 날짜, 자료 성격, 사용 이유, 주의할 점을 남긴다.
- 자료가 너무 많거나 출처가 섞여 있으면 필요한 부분만 발췌하거나 첫 주제를 더 줄인다.
- 민감 정보가 있으면 실습용 복사본, 익명화, 외부 전송 경로, 접근 권한을 먼저 정한다.
- 성공 기준을 문서 수가 아니라 관찰 가능한 업무 행동으로 쓴다.
- 실패 신호를 미리 적어 둔다.
- 주제 폴더를
raw/,wiki/,output/,index.md,log.md,AGENTS.md구조로 초기화한다. index.md에는 위키 목적, 핵심 질문, 주요 문서, 아직 없는 자료를 적는다.log.md에는 구조 생성일, 만든 폴더와 파일, 다음 행동을 남긴다.AGENTS.md에는 raw 원본 임의 수정 금지, wiki Markdown 작성, output 분리, 근거 파일과 확인 날짜와 확인 필요 표시, log 갱신을 쓴다.- Claude Code를 함께 쓰면
CLAUDE.md가AGENTS.md를 참조하도록 하거나 같은 규칙을 짧게 반복한다. - 첫 질문에 현재 위키의 자료 범위, 결정 목적, 출력 형식, 확인된 내용과 제한된 추정의 분리, 추가 자료 제안을 포함한다.
- 첫 답변을 받은 뒤 근거가 약한 문장, 추정, 출처 없음, 최신성 확인 필요를 표시한다.
- 빈틈을 소요 시간, 수정 사례, 예외 조건, 비교 기준 같은 다음 자료 목록으로 바꾼다.
- 5장으로 넘어가기 전에 첫 주제 카드, 첫 자료 묶음, 초기 구조, 첫 질문, 다음 자료 목록이 모두 남았는지 확인한다.
체크리스트와 검증 질문
위키 초기화 완료 체크리스트
- 첫 주제가 한 번의 업무 질문으로 표현된다.
- 원천 자료 후보가 3-5개로 좁혀졌다.
- 성공 기준과 실패 신호가 함께 적혀 있다.
raw/,wiki/,output/의 책임이 분리되어 있다.index.md에 위키 목적, 핵심 질문, 대표 문서, 없는 자료가 있다.log.md에 구조 생성과 다음 행동이 남아 있다.AGENTS.md에 raw 원본 보존, 근거 표시, 확인 필요, log 갱신이 있다.- 첫 질문이 자료 범위와 출력 형식과 근거 부족 표시를 포함한다.
검증 질문
- 첫 주제가 업무 자동화 전체처럼 과하게 넓지 않은가?
- 이 주제를 다음 주에 실제로 쓸 수 있는가?
- 각 자료의 날짜, 출처, 자료 성격, 사용 이유를 적을 수 있는가?
- 민감 정보와 비공개 정보가 그대로 들어가지 않도록 기준을 세웠는가?
- 성공 기준이 문서 수가 아니라 다음 업무의 쉬워짐으로 쓰였는가?
index.md만 보고 위키 목적과 첫 질문을 알 수 있는가?- 첫 답변의 추정과 확인 필요가 다음 자료 목록으로 바뀌었는가?
첫 자료 묶음 평가표
| 질문 | 통과 신호 | 보류 신호 |
|---|---|---|
| 자료가 3-5개 정도인가? | 사람이 다시 확인할 수 있는 양이다. | 채팅 로그 6개월치처럼 잡음이 많다. |
| 날짜와 출처를 적을 수 있는가? | 회의 날짜, URL, 문서 버전, 작성자가 있다. | 기억에 의존한 요약뿐이다. |
| 성공 기준에 직접 연결되는가? | 담당자와 기한, 분류 기준, 근거 문장 등을 확인할 수 있다. | 읽어도 첫 질문에 답하기 어렵다. |
| 민감 정보 처리가 가능한가? | 실습용 복사본과 익명화 기준이 있다. | 고객명, 계약 조건, 이메일이 그대로 있다. |
| 원천과 요약을 분리할 수 있는가? | raw에는 원본, wiki에는 정리본을 둘 수 있다. | 원본을 수정해야만 쓸 수 있다. |
4장 완료 산출물
| 산출물 | 내용 | 합격 기준 |
|---|---|---|
| 첫 주제 카드 | 큰 업무 영역, 첫 위키 주제, 원천 자료 후보, 첫 질문, 성공 기준 | 다음 주에 실제로 쓸 작은 질문이다. |
| 첫 자료 묶음 | 3-5개 원천 자료 후보와 사용 이유, 주의할 점 | 날짜, 출처, 자료 성격, 민감 정보 기준이 있다. |
| 초기 구조 | raw, wiki, output, index, log, rules | 원본과 정리본과 산출물이 섞이지 않는다. |
| 작업 규칙 | raw 보존, 근거 표시, 확인 필요, log 갱신 | LLM에게 매번 설명할 기준이 파일로 남는다. |
| 첫 질문 | 자료 범위, 목적, 형식, 근거 부족 표시 | 단순 요약 요청이 아니라 업무 판단 질문이다. |
| 다음 자료 목록 | 첫 답변의 빈틈에서 나온 자료 후보 | 5장의 수집 기준으로 바로 넘길 수 있다. |
관련 문서 연결
- 통합 루트: 책 전체를
raw -> wiki -> output -> review흐름으로 통합한 안내 문서다. - 3.3 이 책의 실습 환경 정하기: 4장에서 사용할 미니 위키 환경과 보안 기준을 먼저 고정한다.
- 4.1 업무 주제 정하기: 큰 업무 영역을 첫 위키 주제로 줄이고 첫 자료와 성공 기준을 정한다.
- 4.2 위키 초기화하기: raw, wiki, output, index, log, rules의 최소 구조를 만든다.
- 4.3 첫 질문으로 방향 잡기: 첫 질문을 자료 범위와 근거 검증 기준이 있는 업무 질문으로 바꾼다.
- 5장. 자료를 넣고 다시 쓰기 좋은 지식으로 바꾸기: 4.3에서 드러난 빈틈을 실제 수집 기준과 원천 카드로 바꾼다.
- 5.1 자료를 넣기 전에 정할 기준: 첫 자료 묶음의 포함, 제외, 민감 정보, 신뢰도, 최신성 기준을 정한다.
- 6장. 위키에 질문하고 답을 검증하기: 4.3의 첫 질문과 초기 답변을 문장별 근거 라벨과 결정 반영 루프로 확장한다.
- 6.2 답변의 근거 확인하기: 첫 답변의 확인된 내용, 제한된 추정, 출처 없음을 더 엄밀하게 나눈다.
- 8장. 오래 믿고 쓰는 LLM위키 운영법: 4장에서 만든 첫 구조와 rules가 시간이 지나도 믿을 수 있는지 감사한다.
이 장 개요는 장 랜딩만이 아니라 4.1-4.3 세부 원문을 함께 반영해 장 수준으로 재구성한 것이다. 원문에 나온 명령과 예시는 장문 복제하지 않고 성공 기준과 운영 원칙 중심으로 정리했다. 실제 도입 전에는 공식 문서, 설치된 도움말, 릴리스 노트, 조직 보안 기준을 다시 확인해야 한다.