무엇을 준비하나
이 페이지는 화면 앞에서 그대로 따라 하는 실습입니다. 컴퍼니 브레인이 무엇이고 왜 위키 형태로 쌓는지는 설명 편에 있습니다. 먼저 읽으면 각 단계의 목적이 보입니다.
여기서 하는 일은 간단합니다. 스킬 하나를 내려받아 올리고, 샘플 문서를 함께 올리고, 세 동작을 실행합니다. 규칙서와 스킬을 직접 작성하지 않습니다. 이미 공개된 것을 그대로 사용합니다. 터미널 없이 Claude 데스크톱 앱만으로 끝까지 진행합니다.
LLM 위키는 Andrej Karpathy가 공개한 지식 관리 방식입니다. 사람이 위키를 쓰지 않습니다. LLM이 원본을 읽어 위키 페이지를 쓰고 고치며, 사람은 읽고 질문만 합니다. 이 실습에서는 그 방식을 스킬 하나로 구현한 Astro-Han/karpathy-llm-wiki를 씁니다. Karpathy 본인이 만든 스킬이 아니라, 그가 공개한 방식을 따라 만든 MIT 라이선스 오픈소스입니다.
아래 zip은 그 저장소를 데스크톱 앱에 바로 올릴 수 있게 다시 묶은 것입니다. 앱은 스킬 설명문을 200자까지만 받으므로 247자인 원본 설명 한 줄만 줄였고, 규칙 본문은 그대로입니다. 라이선스와 수정 내역을 함께 넣었습니다.
기본은 데스크톱 앱입니다. 터미널로도 진행할 수 있으며, 터미널 안내는 도구별로 다릅니다. 사용하는 도구를 고르면 안내가 그 기준으로 바뀝니다.
Codex는 ChatGPT의 코딩 에이전트입니다. 이 스킬은 두 도구에서 같은 파일로 작동합니다.
- Claude 데스크톱 앱이 있으면 됩니다. 터미널은 쓰지 않습니다. 설정에서 코드 실행이 켜져 있어야 스킬이 작동합니다. 무료 요금제에서도 사용자 지정 스킬을 쓸 수 있습니다
- 계속 확장할 계획이라면 터미널 쪽이 낫습니다. Claude Code (Claude Code 101 참고)로 하는 길을 4-B 아래에 함께 적었습니다
- 정리할 문서 몇 개가 필요합니다. 준비된 것이 없으면 아래 실습용 샘플을 받아 그대로 씁니다. 회사 문서로 바로 시작해도 됩니다
- 이 스킬에는 민감도 기준이 없습니다. 무엇을 넣을지는 사람이 정합니다. 인사·급여·개인정보는 올리지 않습니다
가상의 회사가 넉 달 동안 남긴 회의록·정책·결정 기록·장애 기록·메일입니다. 압축을 풀면 raw/company/에 7개, sensitive-excluded/에 대외비 1개가 들어 있습니다. raw 폴더만 작업 폴더에 옮기면 됩니다.
| 파일 | 종류 | 이 문서로 무엇을 보나 |
|---|---|---|
| 2026-03-04_주간회의록 | 회의록 | 환불 기한을 7일로 정한 결정 |
| 2026-03-18_제품회의록 | 회의록 | 결정되지 않은 논의(월 9,000원 안) |
| 2026-04-08_가격정책_결정기록 | 결정 기록 | 논의와 다른 최종안(월 11,000원)과 반대 의견 |
| 2026-05-12_주간회의록 | 회의록 | 환불 기한을 14일로 바꾼 결정 |
| 고객응대_정책_v3 | 정책 | 2월 기준이라 7일이 그대로 남은 문서 |
| 2026-06-02_파트너십_안내_메일 | 메일 | 수수료 조건과 접수 절차 |
| 2026-06-20_장애_대응_기록 | 장애 기록 | 담당과 기한이 흩어진 후속 조치 3건 |
| 2026-07-01_인사평가_메모 | 대외비 | raw/에 넣지 않는 문서 |
- 정보 충돌. 환불 기한이 3월 7일 기준에서 5월 14일 기준으로 바뀝니다. 정책 문서 v3에는 아직 7일이 적혀 있습니다. 최신을 본문에 살리고 옛 기준에
Status: Outdated블록을 붙이는지 확인합니다. - 논의와 결정의 구분. 3월에 나온 월 9,000원 안은 논의였고, 4월 결정 기록의 월 11,000원이 확정입니다. 두 값이 부딪히면
Status: Disputed로 표시되거나 확정본이 본문에 남아야 합니다. - 민감 정보. 인사평가 메모에는 등급과 연봉 조정폭, 개인 간병 사정이 들어 있습니다. 이 스킬은 이것을 걸러 주지 않습니다. 그래서 샘플에서도
raw/밖에 따로 두었습니다. - 흩어진 후속 조치. 장애 기록의 조치 3건은 담당과 기한이 제각각입니다. 위키에서 한 자리에 모이는지 확인합니다.
무엇을 만드는지 한눈에
이 실습이 만드는 것은 컴퍼니 브레인의 세 구성 요소 중 LLM 위키입니다. Karpathy가 정리한 구성 요소가 이 스킬에서 어떤 이름으로 나오는지 먼저 대응해 둡니다.
| LLM 위키 | 이 스킬에서 부르는 이름 |
|---|---|
raw · 손대지 않는 원본 문서 | raw/<주제>/ |
wiki · LLM이 쓰는 마크다운 | wiki/<주제>/ + wiki/index.md + wiki/log.md |
schema · 규칙 문서 | SKILL.md (스킬에 이미 들어 있음) |
ingest · 새 자료 흡수 | Ingest |
query · 근거를 달아 답하기 | Query |
lint · 건강 점검 | Lint (check_evidence.py 포함) |
폴더에 쌓기만 하기
- 파일은 많은데 어디에 무엇이 있는지 모름
- 같은 내용이 여러 문서에 중복
- 옛 정보와 새 정보가 뒤섞여 무엇이 최신인지 불명
- 아는 사람이 나가면 맥락도 함께 사라짐
LLM 위키로 정리하기
- 원본은
raw/에 그대로 두고, 정리본은wiki/에 따로 쌓임 - 새 자료가 들어오면 기존 페이지에 병합하거나 새 페이지를 만듦
- 충돌하면 지우지 않고
Status블록으로 표시 - 숫자·날짜·인용은
raw/에 같은 형태로 있어야만 위키에 적힘
위키 페이지로 작성
(페이지 인용)
+ 자동 수정
1단계. 누가 이 위키를 운영하나
도서관을 떠올리면 이해가 쉽습니다. 들어온 책을 읽고 서가에 꽂는 사람, 방문자에게 "그 자료는 저쪽에 있어요"라고 안내하는 데스크 직원, 목록과 실물이 어긋나지 않는지 주기적으로 대조하는 사람이 있습니다. 이 스킬도 같은 세 동작으로 나뉩니다. 슬래시 명령이 아니라 말로 호출합니다. "이 문서들을 위키에 넣어줘"라고 하면 스킬이 자동으로 실행됩니다.
Ingest · 흡수
원본을 raw/에 저장하고, 위키에 이미 있는 내용인지 먼저 대조한 다음 페이지를 새로 만들거나 기존 페이지에 병합합니다. 목차와 작업 기록까지 함께 갱신합니다.
Query · 응답
위키를 찾아 답합니다. 파일을 쓰지 않습니다. 답마다 어느 위키 페이지에서 나왔는지 링크를 답니다. 목차와 전문 검색을 둘 다 훑고도 없으면 없다고 말합니다.
Lint · 점검
목차와 실제 파일이 어긋나지 않는지, 링크가 깨지지 않았는지 검사해 고칠 수 있는 것은 고칩니다. 사실이 어긋나는 문제는 고치지 않고 사람에게 보고합니다.
스킬이 스스로 근거 불변식이라고 부르는 규칙이 있습니다. 위키에 적힌 숫자·날짜·직접 인용은 그 페이지가 가리키는 raw/ 파일 안에 글자 그대로 있어야 한다. 원본이 "42K"라고 적었으면 위키에도 42K라고 씁니다. 42,000으로 바꿔 쓰지 않습니다. 찾지 못한 값은 아예 쓰지 않습니다. Ingest가 이 상태를 만들고, Lint가 이 상태를 다시 확인합니다.
스킬이 맡는 일
- 원본을 어느 주제 폴더에 둘지 정하고 파일 이름을 붙입니다.
- 새 페이지를 만들지, 기존 페이지에 합칠지 판단합니다.
- 충돌을 지우지 않고
Status블록으로 남깁니다. wiki/index.md목차와wiki/log.md작업 기록을 갱신합니다.
사람이 맡는 일
- 무엇을
raw/에 넣을지 고릅니다. 민감 자료를 거르는 단계는 여기뿐입니다. - 주제 폴더 이름을 우리 조직의 용어로 정합니다.
- 좋은 질문을 던지고, 답에 붙은 인용을 눌러 원본까지 확인합니다.
- Lint가 사람에게 넘긴 판단 항목을 결정합니다.
이 스킬은 파일 몇 개가 전부입니다(SKILL.md, references/, scripts/). 우리 조직에만 필요한 규칙, 예를 들어 민감도 기준이나 결재 라인 표기를 더하고 싶으면 설치된 SKILL.md를 열어 문단을 추가하면 됩니다. MIT 라이선스이므로 수정에 제약이 없습니다. 다만 먼저 원본 그대로 한 차례 실행해 본 뒤 고칩니다. 무엇이 부족한지 확인한 다음 고쳐야 합니다.
2단계. 어떤 순서로 도나
1단계에서 누가 일할지 정했으니, 이번에는 언제 어떤 순서로 일할지를 봅니다. 책 쓰기는 한 번 완성하면 끝이지만, 위키는 다릅니다. 새 회의록은 매주 들어옵니다. 그래서 들어온 것만 처리하고 나머지는 건드리지 않습니다. 전체를 매번 다시 읽으면 느리고, 정상인 페이지까지 흔들립니다.
Ingest는 네 단계로 나뉩니다. 이 스킬의 핵심입니다.
raw/<주제>/ 아래 마크다운으로 저장합니다. 파일 이름은 2026-05-12-refund-window.md처럼 날짜 + 짧은 이름입니다. 출처 링크와 수집일을 머리말에 적습니다. 원문은 고치지 않습니다. 이미 폴더에 넣어 둔 파일이라면 이 단계는 건너뜁니다.New(새 페이지), Update(기존 페이지에 병합), Disputed(기존과 충돌), No material(새로울 것이 없음). 마지막 판정이 나오면 위키를 건드리지 않고 기록만 남기고 멈춥니다. 빈약한 자료로 불필요한 페이지를 만들지 않기 위해서입니다.Status: Disputed를 붙이고 양쪽을 서로 링크합니다.Status: Outdated로 표시합니다. 이력을 조용히 고쳐 쓰지 않습니다. 끝나면 wiki/index.md와 wiki/log.md를 갱신합니다.자료 여러 개를 한꺼번에 넣어도 됩니다. 다만 스킬은 검색은 동시에 하되 위키 쓰기는 하나씩 합니다. index.md와 log.md는 모두가 함께 쓰는 파일이라, 동시에 손대면 서로 덮어씁니다. 샘플 7개를 넣으면 순서대로 처리되는 것이 정상입니다. 느린 것이 아니라 그렇게 설계된 것입니다.
3월 회의록에는 "환불 기한 7일", 5월 회의록에는 "환불 기한 14일"이라고 적혀 있다면? 최신(5월)을 본문에 살리고, 3월 기준은 Status: Outdated 블록으로 언제 무엇으로 바뀌었는지와 함께 남깁니다. 어느 쪽이 맞는지 판단이 서지 않을 때는 Status: Disputed로 양쪽을 다 남기고 사람에게 넘깁니다. 옛 정보를 지워 버리면 "왜 바뀌었나"라는 맥락이 사라집니다.
책 쓰기는 기획서 하나로 한 번에 완성하는 파이프라인입니다. 컴퍼니 브레인은 계속 반복되는 루프입니다. 그 루프를 지탱하는 것이 wiki/log.md입니다. 언제 무엇을 넣었고 무엇이 No material로 걸러졌는지 한 줄씩 쌓입니다. 이 기록이 없으면 다음 달에 같은 자료를 또 넣게 됩니다.
3단계. 무엇을 파일로 두나
AI 에이전트는 사람과 달리 구두로 알려준 규칙을 기억하지 못합니다. 대신 매번 같은 파일을 읽고 시작합니다. 이 실습의 장점은 그 규칙 파일을 직접 쓰지 않아도 된다는 점입니다. 스킬 안에 이미 들어 있습니다. 우리가 만드는 것은 폴더 두 개뿐입니다.
아래 그림은 터미널로 할 때 내 컴퓨터에 생기는 모습입니다. 데스크톱 앱으로 하면 스킬은 사용자 지정에 올라가 있고, raw/와 wiki/는 대화 안에 생깁니다. 폴더 이름과 규칙은 양쪽이 똑같습니다. 무엇이 어디에 쌓이는지 보이도록 그림으로 두었습니다.
스킬이 들어가는 폴더 이름이 도구마다 다릅니다. 쓰는 쪽을 고르면 아래 내용이 그 기준으로 바뀝니다.
스킬 파일 자체는 두 도구가 똑같이 읽습니다. 두는 위치만 다릅니다.
raw/에 문서를 넣고 첫 Ingest를 시키면, 스킬이 wiki/와 index.md, log.md를 자동으로 만듭니다. 이미 있으면 덮어쓰지 않습니다. 반대로 Query나 Lint를 먼저 부르면 "먼저 ingest를 돌리라"고 답합니다. 폴더를 임의로 만들지 않는 쪽이 안전하기 때문입니다.
| 파일 | 역할 | 누가 손대나 |
|---|---|---|
| /karpathy-llm-wiki/ | 세 동작의 절차와 페이지 서식이 적힌 규칙 본체 | 그대로 둠 |
| raw/ | 원본 문서. 스킬은 읽기만 하고 절대 고치지 않습니다 | 사람이 투입 |
| wiki/<주제>/*.md | 정리된 위키 페이지. 원본에서 확인한 사실만 적힙니다 | 스킬이 작성 |
| wiki/index.md | 주제별 목차. 페이지마다 요약 한 줄과 갱신일 | 스킬이 갱신 |
| wiki/log.md | 언제 무엇을 넣고 무엇을 걸렀는지 남는 작업 기록 | 덧붙이기만 |
원본이 고정되어 있어야 한 번 확인한 페이지가 계속 확인된 상태로 남습니다. 원본을 손댈 수 있으면 어제 맞다고 검사한 숫자가 오늘 틀린 숫자가 됩니다. 그래서 검사기(check_evidence.py)가 위키 전체를 몇 초 만에 다시 검사할 수 있습니다. 회사로 치면 회의록 원본은 봉인하고, 요약본만 계속 고쳐 쓰는 방식입니다.
스킬이 이미 정해 둔 규칙 여섯 가지
직접 쓰지 않아도 되지만, 무엇을 정해 두었는지는 알고 써야 결과를 읽을 수 있습니다.
주제 폴더는 한 겹만
wiki/<주제>/<페이지>.md까지입니다. 더 깊이 파고들지 않습니다. 새 주제 폴더는 정말 다른 주제일 때만 만듭니다.
근거 불변식
숫자·날짜·직접 인용은 원본에서 먼저 찾은 다음 그대로 옮겨 적습니다. 못 찾은 값은 쓰지 않거나 정밀도를 뺍니다.
Status 블록
새 자료가 옛 주장을 밀어내면 Outdated, 출처끼리 어긋나면 Disputed를 붙입니다. 옛 내용을 지우지 않습니다.
Raw 필드
페이지마다 어느 원본에서 왔는지 링크를 답니다. 이 링크가 끊기면 그 페이지는 검사 자체가 불가능해집니다.
No material 판정
새로울 것이 없는 자료는 위키에 손대지 않고 기록만 남깁니다. 빈약한 자료로 불필요한 페이지를 만들지 않습니다.
답에는 인용을
Query는 위키 페이지 링크를 달아 답하고, 목차와 전문 검색을 둘 다 훑고도 없으면 없다고 말합니다. 추측하지 않습니다.
이 여섯 가지에 민감도 기준이 없습니다. 인사·급여·개인정보를 걸러 내는 규칙은 이 스킬에 들어 있지 않습니다. 그래서 무엇을 raw/에 넣을지가 사람이 쥔 유일한 안전장치입니다. 회사에서 장기간 운영할 계획이라면 설치된 SKILL.md에 우리 조직의 민감도 기준을 한 문단 추가합니다. 그것이 이 스킬을 우리 것으로 만드는 첫 수정입니다.
Claude에게 실행을 맡긴다
여기부터는 화면 앞에서 그대로 따라 하면 됩니다. 스킬을 올리고, 문서를 올리고, 세 동작을 실행합니다. 터미널은 쓰지 않습니다.
위에서 받은 스킬 zip을 압축을 풀지 말고 그대로 올립니다. 한 번 올려 두면 새 대화에서도 계속 사용할 수 있습니다.
| 순서 | 하는 일 |
|---|---|
| 1 | Claude 데스크톱 앱에서 왼쪽 아래 사용자 지정을 누릅니다 |
| 2 | 스킬 탭으로 갑니다 |
| 3 | 오른쪽 위 + 버튼을 누르고, 스킬을 직접 쓰는 쪽이 아니라 zip 파일을 올리는 쪽을 고릅니다 |
| 4 | 받아 둔 karpathy-llm-wiki-skill.zip을 올리고 켭니다 |
설정에서 코드 실행이 꺼져 있으면 사용자 지정 스킬이 실행되지 않습니다. 이 스킬은 파일을 만들고 check_evidence.py를 실행하기 때문에 그 기능이 필요합니다. 켜져 있는데도 실행되지 않으면 대화에서 "karpathy-llm-wiki 스킬 써줘"라고 이름을 직접 호출합니다.
샘플 문서를 내려받아 압축을 풀면 raw/company/에 7개, sensitive-excluded/에 대외비 1개가 나옵니다. 새 대화를 열고 raw/company/의 7개만 끌어다 올립니다. 대외비 파일은 올리지 않습니다. 이것이 이 실습에서 사람이 하는 유일한 판단입니다.
원본을 그대로 올리지 말고 복사본을 만들어 그중 올릴 것만 고릅니다. 재무 자료나 인사 기록이 섞인 폴더는 통째로 올리지 않습니다. 무엇을 올릴지 정하는 일이 이 실습에서 가장 중요한 결정입니다.
여기까지가 데스크톱 앱 준비입니다. 위키를 계속 확장할 계획이라면 터미널 쪽이 낫습니다. 데스크톱 앱에서는 만든 위키가 대화 안에 있으므로 대화를 닫으면 사라지지만, 터미널에서는 내 컴퓨터 폴더에 그대로 남습니다. 바탕화면에 company-brain 폴더를 만들고 raw 폴더를 그 안에 옮긴 다음, 그 폴더에서 아래를 실행합니다.
어느 도구에 설치할지 물으면 를 고릅니다. 끝나면 /karpathy-llm-wiki/에 파일이 들어옵니다. 그 폴더에서 claude를 실행하면 4-D부터 프롬프트가 똑같습니다. Node.js가 없으면 받아 둔 스킬 zip을 풀어 그 폴더에 그대로 넣어도 됩니다. 설치 명령이 하는 일은 이것뿐입니다.
대화 안에서 만든 wiki/는 대화를 닫으면 사라집니다. 한 차례 실행한 뒤 "raw와 wiki 폴더를 zip으로 묶어줘"라고 해서 내려받아 둡니다. 다음에 이어서 할 때 그 zip을 다시 올리고 "압축 풀고 이어서 해줘"라고 하면 그 자리에서 이어집니다. 매주 이렇게 수동으로 옮기는 일이 번거로워지면 그때가 터미널로 이동할 시점입니다.
문서를 올린 대화에 아래를 그대로 붙여 넣습니다. 처음 한 번은 raw/와 wiki/ 폴더, 목차와 작업 기록까지 함께 만들어집니다. 자료가 7개이므로 한 번에 끝나지 않습니다. 하나씩 순서대로 처리되는 것이 정상입니다.
- 문서마다 판정을 먼저 말하는지 확인합니다. 3월 회의록은
New, 5월 회의록은 환불 기한을 바꾸니Update또는Disputed가 나와야 합니다 - 정책 문서 v3(2월 기준 7일)와 5월 회의록(14일)이 서로 연결되는지 확인합니다. 각각 따로 페이지를 만들고 끝나면 연결을 놓친 것입니다
- 숫자를 원본 표기 그대로 옮기는지 확인합니다. "월 11,000원 / 40건"이 "1만 1천원"으로 바뀌면 규칙을 어긴 것입니다
- 끝나면
wiki/log.md를 열어 봅니다. 문서 7개가 각각 어떤 판정으로 처리됐는지 한 줄씩 남아 있습니다
위키가 생성됐으니 이제 질문합니다. Query는 파일을 쓰지 않습니다. 읽고 답할 뿐입니다. 함정 넷이 제대로 처리됐는지 이 네 질문으로 확인합니다.
- 환불 기한은 14일, 2026-05-20 시행. 3월의 7일 기준이
Status: Outdated로 남아 있어야 합니다 - 라이트 요금제는 월 11,000원 / 40건. 사용자 62%가 월 35건 이하라는 근거까지 나와야 합니다. 3월에 논의된 9,000원이 확정처럼 나오면 논의를 결정으로 적은 것입니다
- 후속 조치 3건과 담당·기한이 한 자리에 모여 나와야 합니다
- 인사 평가는 "위키에 없습니다". 그 문서를
raw/에 넣지 않았기 때문입니다. 스킬이 걸러 준 것이 아니라 사람이 걸러 낸 것입니다
Query는 기본적으로 대화로만 답합니다. 답이 유용하면 "이 답 위키에 저장해줘"라고 요청합니다. 그때만 새 페이지가 생기고, 목차에 [Archived] 표시가 붙습니다. 원본에서 온 사실이 아니라 정리된 답이라는 것을 구분해 두기 위해서입니다. 기존 페이지에 섞이지 않습니다.
마지막으로 위키의 상태를 검사합니다. 목차와 실제 파일이 어긋나거나 링크가 깨진 것은 그 자리에서 고칩니다. 사실이 어긋나는 문제는 고치지 않고 사람에게 보고합니다. 고칠 권한을 나눠 둔 것입니다.
| 점검 종류 | 무엇을 보나 | 처리 |
|---|---|---|
| 목차·링크 | 목차에 빠진 페이지, 없는 파일을 가리키는 항목, 깨진 내부 링크, 끊어진 원본 링크 | 그 자리에서 수정 |
| 근거 대조 | check_evidence.py가 위키의 숫자·날짜·인용을 원본에서 되찾습니다. 못 찾으면 표시합니다 |
보고만 |
| 판단 항목 | 페이지끼리 모순, 표시 없이 낡은 주장, 어디에도 이어지지 않은 외톨이 페이지, 자주 언급되는데 페이지가 없는 개념 | 보고만 |
근거 대조는 의심 목록이지 판정이 아닙니다. 계산으로 만든 값이나 숫자처럼 보이는 제품 이름이 표시되기도 합니다. 스킬 문서도 그렇게 명시합니다. 표시된 항목을 원본과 하나씩 대조해 실제로 어긋난 것만 고칩니다. 기계가 먼저 범위를 좁히고 사람이 판정하는 구조입니다.
월요일 아침, 지난주 회의록 3개를 올리고 Ingest를 실행하면 아래처럼 진행됩니다. 한 산출물이 다음 산출물의 입력이 됩니다. 각 줄 오른쪽에 누가 맡는지 적었습니다.
위 표에서 위키 본문을 쓰는 것은 Ingest뿐입니다. Query는 읽기만 하고, Lint는 목차와 링크만 손댑니다. 본문을 쓰는 주체를 하나로 묶어야 형식과 톤이 흔들리지 않습니다. 사람으로 치면 "검토는 여러 명이 하지만, 위키에 글을 쓰는 사람은 한 명"인 구조입니다. 책 쓰기 실습에서 저자(블랙)만 본문을 고친 것과 같은 원리입니다.
만든 위키를 신뢰할 수 있는지 측정한다
Lint가 기계로 잡아 주는 것은 목차와 링크, 그리고 원본에서 되찾지 못한 숫자까지입니다. 나머지는 사람이 확인합니다. 컴퍼니 브레인은 책과 달리 여러 사람이 두고두고 참고합니다. 한 번 잘못 들어간 정보는 계속 잘못 안내합니다. 아래 여섯 가지를 직접 확인합니다.
원본 추적
페이지마다 Raw 필드가 붙어 있고, 눌러서 원본까지 열리는가
중복 없음
같은 내용이 여러 페이지에 흩어져 있지 않은가
최신성
충돌하는 정보 중 최신이 본문에, 옛것은 Status 블록으로 남았는가
민감 정보 제외
인사·급여·개인정보가 raw/에 섞여 들어가지 않았는가
논의와 결정
확정되지 않은 논의가 결정처럼 적히지 않았는가
답변 신뢰
Query가 위키에 없는 것은 "없다"고 답하고 지어내지 않는가
Lint가 넘긴 항목을 함께 검토하는 프롬프트
답에 위키 페이지 인용이 붙는지, 그리고 마지막 질문에 "위키에 없다"고 답하는지가 합격선입니다.
- 지금 환불 기한은 며칠이고 언제 바뀌었나? (14일, 2026-05-20 시행. 옛 7일 기준이 Status 블록으로 남아 있어야 합니다)
- 라이트 요금제 가격은 얼마이고 왜 그 숫자로 정했나? (월 11,000원 / 40건. 사용자 62%가 월 35건 이하라는 근거까지 나와야 합니다)
- 결제 장애 이후 남은 후속 조치는? (알림 수신처 변경, 만료일 달력 등록, 실패 임계 알림 3건과 담당·기한)
- 한지우의 인사 평가 등급은? (위키에 없다고 답해야 정상입니다)
위 여섯 항목은 사람이 읽고 판단하는 검증입니다. 페이지가 10장일 때는 가능합니다. 50장이 넘으면 눈으로 훑을 수 없습니다. 이 스킬이 Lint를 세 동작 중 하나로 둔 이유가 여기 있습니다. 모순, 낡은 주장, 어디에도 연결되지 않은 페이지를 기계가 먼저 좁힌 다음 사람이 확인합니다.
정확도를 숫자로 측정하고 매주 자동으로 실행되게 만드는 일은 실습 카드 04번 · 위키 건강검진에서 이어서 만듭니다.
다음 주가 되면 올려 둔 스킬은 그대로 두고, 새 회의록만 올린 뒤 "위키에 넣어줘"라고 다시 요청합니다. 데스크톱 앱이라면 지난번에 내려받아 둔 raw·wiki zip을 함께 올립니다. 이미 정리한 자료는 No material로 걸러지고 새것만 반영됩니다. 지식을 한 번 정리하는 대신 정리하는 방식을 한 번 설치합니다. 그다음은 매주 환경이 스스로 성장합니다.
지식 그래프를 그려 본다
위키 페이지가 수십 개로 늘면 목록만으로는 전체가 보이지 않습니다. 어떤 정책이 어떤 제품에 걸려 있는지, 작년 결정이 지금 어디에 영향을 주는지 같은 관계는 표로는 드러나지 않습니다. 지식 그래프는 위키의 페이지·태그·결정을 노드(점)로, 그 사이 연결을 엣지(선)로 그려 전체 지형을 한눈에 보여 줍니다. 연결이 많아 커진 노드가 우리 조직이 가장 많이 다루는 주제입니다.
한 차례 실행했다면, 다음은 운영입니다
정확도를 전후로 측정하고, 위키가 낡지 않게 막고, 매주 자동으로 실행되게 만드는 일이 남았습니다.
점검과 운영 7가지 카드에서 이어서 만듭니다.