3장. 내게 맞는 LLM위키 방식 고르기

핵심 요지

3장은 2장에서 만든 raw/, wiki/, output/, index.md, log.md, rules 구조를 어떤 도구와 운영 방식으로 시작할지 고르는 장이다. 목표는 기능이 가장 많은 도구를 고르는 것이 아니라 이번 주 안에 작은 자료 하나를 넣고, 위키 문서 하나를 만들고, 그 문서로 질문한 뒤, 원천과 근거와 확인 필요가 남는지 검증하는 것이다.

자료가 적고 구조를 배우는 단계라면 수동 Markdown이 가장 낮은 위험의 기준선이다. 이미 Codex나 Claude Code를 쓰고 있다면 에이전트 기반 방식이 자연스럽지만, Codex는 AGENTS.md, Claude Code는 CLAUDE.md 또는 .claude/CLAUDE.md 같은 지침 파일을 다르게 읽는다는 점을 확인해야 한다. 반복 작업이 많으면 CLI가, 화면에서 문서와 연결 상태를 확인해야 하면 데스크톱 방식이 후보가 된다.

원문 구조와 장 안에서의 기능

세 절은 순서가 중요하다. 3.1 없이 3.2로 가면 체크리스트가 추상적인 기능 비교표가 된다. 3.2 없이 3.3으로 가면 선택한 도구가 원천 보존, 사람이 고치는 문서, 출처 추적, 버전 확인을 지원하는지 모른 채 실습하게 된다. 3.3이 없으면 실제 작업 디렉터리, 민감 정보 기준, rules 파일, log 기록 기준이 없어 4장의 첫 위키가 흔들린다.

수동 Markdown은 초보용 임시방편이 아니라 기준선이다

수동 Markdown 방식은 별도 구현체 없이 폴더와 Markdown 파일로 raw/, wiki/, output/, AGENTS.md 구조를 직접 만드는 방식이다. 이 방식은 자동화를 포기하자는 뜻이 아니라 역할 분담을 눈으로 확인하는 훈련이다. raw/meeting-note.md는 근거이고, wiki/concepts/...는 LLM 또는 사람이 정리한 해석이며, output/은 보고서와 계획의 작업 공간이다.

수동 방식의 강점은 실패 원인이 드러난다는 점이다. LLM이 원본을 바꿨다면 rules가 약한 것이다. 색인이 갱신되지 않았다면 요청에 index 갱신 기준이 빠진 것이다. 확인 필요가 사라졌다면 문서 템플릿과 검증 조건이 부족한 것이다. 이 경험은 이후 에이전트나 CLI를 써도 결과 검토 기준으로 남는다.

수동 Markdown을 선택하기 좋은 조건

• 자료가 1-5개 정도로 작다.
• 구조와 책임 분리를 직접 배우고 싶다.
• 설치와 플러그인 권한 검토에 시간을 쓰기 어렵다.
• 사람이 직접 Markdown을 열어 고칠 수 있어야 한다.
• 실패했을 때 원인 추적과 되돌리기가 중요하다.

한계도 분명하다. 자료가 늘어나면 색인 갱신, 링크 관리, 처리 이력 기록, 중복 제거를 사람이 계속 챙겨야 한다. 따라서 수동 방식은 끝까지 수동으로 남으라는 뜻이 아니라 나중에 도구가 대체해야 할 운영 기준을 먼저 체득하는 단계다.

에이전트 기반 방식은 기존 작업 흐름에 위키를 붙이는 선택이다

Claude Code와 OpenAI Codex 기반 방식은 이미 에이전트형 LLM 도구를 쓰는 사람에게 자연스럽다. 사용자는 대화하듯 요청하고, 에이전트는 파일을 읽고 쓰며 위키를 갱신한다. 자료 조사, 코드 세션 정리, 업무 메모 정리처럼 대화와 파일 편집이 이어지는 작업에 잘 맞는다.

주의할 점은 지침 파일의 차이다. Codex는 AGENTS.md를 기준으로 확인해야 하고, Claude Code는 CLAUDE.md 또는 .claude/CLAUDE.md 같은 위치의 메모리 파일을 확인해야 한다. nvk/llm-wiki 같은 구현체가 제공하는 /wiki 또는 @wiki 흐름은 해당 구현체 문서 기준의 명령이지 모든 호스트 도구의 공식 내장 기능으로 단정하면 안 된다.

에이전트 방식의 합격 기준

• 에이전트가 현재 프로젝트의 rules 파일을 읽었음을 요약할 수 있다.
• raw/ 원본을 수정하지 않는다는 기준을 실제 작업 결과가 지킨다.
• 새 wiki/ 문서에 원천 경로와 확인 날짜가 남는다.
• index.md와 log.md 갱신 후보가 남는다.
• 근거 없는 내용은 확인 필요로 분리된다.
• 플러그인이나 외부 기능을 쓰는 경우 저장 위치, 네트워크 호출, 승인 범위를 설명할 수 있다.

CLI와 데스크톱 방식은 확장 선택지다

CLI는 명령으로 자료를 넣고, 컴파일하고, 질문하고, 점검하는 흐름에 맞다. 반복성과 재현성이 강하므로 연구 자료를 정기적으로 넣거나 팀 문서를 주기적으로 점검하는 경우에 유리하다. 반면 Node.js, Python, API 키, 환경 변수, 버전 전제를 다룰 수 있어야 한다.

데스크톱 방식은 문서 트리, 미리보기, 그래프, 채팅 화면, 점검 화면처럼 가시성이 필요할 때 맞다. 명령줄이 부담스럽거나 연결 상태를 눈으로 확인하고 싶은 사용자에게 편할 수 있다. 하지만 화면이 편하다고 해서 신뢰성이 자동으로 생기지는 않는다. 데스크톱 방식에서도 원본 보존, 위키 문서와 원본 구분, 출처 없는 강한 주장 점검이 그대로 필요하다.

도구 선택의 최소 조건

3.2는 첫 LLM위키 도구가 최소한 세 조건을 만족해야 한다고 설명한다. 첫째, 원천 자료와 정리된 위키 문서를 구분해 저장할 수 있어야 한다. 둘째, 생성된 위키 문서를 사람이 직접 열어 고칠 수 있어야 한다. 셋째, 공식 문서와 변경 이력을 확인할 수 있어야 한다. 이 조건은 기능 체크리스트보다 앞선다.

• 30분 안에 샘플 자료 하나를 넣어 볼 수 있는가.
• 원본 자료가 따로 남는가.
• 위키 문서가 Markdown처럼 사람이 읽고 고칠 수 있는 형식인가.
• 저장 위치와 백업 경로를 확인할 수 있는가.
• 공식 README, Releases, Changelog가 있는가.
• 권한, 네트워크 호출, API 키 사용 범위를 설명할 수 있는가.
• 다른 도구로 옮길 수 있는가.

자료 형식은 업로드가 아니라 근거 추적 능력으로 판단한다

확인 필요로 표시된 항목은 실제 업무 자료를 바로 넣지 않는다. 공개 샘플이나 더미 자료로 먼저 테스트하고, 민감 정보가 포함될 가능성이 있으면 조직 보안 기준, 외부 전송, 저장 위치를 확인한다.

공식 문서와 버전 확인은 선택 전 절차다

LLM위키 구현체는 빠르게 바뀐다. 책이나 블로그의 예제 명령도 그대로 믿지 말고 공식 README, Releases, Changelog, 설치된 도구의 도움말을 다시 확인해야 한다. 사용법 변화가 저장 구조, 아카이브 처리, 명령 이름, 권한 모델에 직접 영향을 줄 수 있기 때문이다.

1. 도구 후보를 발견한다.
2. 공식 저장소 README를 확인한다.
3. 최신 Releases 또는 Changelog를 확인한다.
4. 설치 전제인 OS, Python/Node.js, API 키, 모델 설정을 확인한다.
5. 저장 위치, 권한, 네트워크 호출 범위를 확인한다.
6. 설치된 도구의 도움말을 확인한다.
7. 작은 샘플로 실행한다.
8. 원본과 위키 문서가 분리되는지 확인한다.
9. 분리되지 않으면 업무 자료로 확장하지 않고 문서와 버전 차이를 다시 본다.

실습 환경은 도구보다 먼저 고정해야 하는 운영 계약이다

3.3은 책의 실습 환경을 작게 고정한다. 기본 선택은 Markdown 파일, raw/, wiki/, output/, index.md, log.md, AGENTS.md, 선택적 CLAUDE.md, 가상의 짧은 회의록이다. 이 선택은 기능이 많아서가 아니라 흐름이 보이기 때문이다. 원본은 보존되고, 위키 문서는 원본을 가리키며, 작업 이력은 남는다.

도구가 바뀌어도 유지되는 흐름은 자료 넣기 → 묻기 → 점검하기다. Karpathy의 LLM Wiki 아이디어에서 말하는 ingest, query, lint 흐름과 연결되지만, 핵심은 명령 이름이 아니다. 어떤 도구를 쓰든 원천, 정리본, 질문, 검증, 산출물, 로그가 서로 연결되어야 한다.

실무 적용 절차

1. 2장에서 만든 구조 원칙을 다시 확인한다. 원천, 위키, 산출물, index, log, rules의 책임을 말로 설명할 수 있어야 한다.
2. 최근에 실제로 다룰 첫 자료를 하나 고른다. 가능하면 가상의 회의록이나 익명화된 짧은 업무 메모로 시작한다.
3. 현재 조건을 적는다. 자료 수, 기술 숙련도, 이미 쓰는 LLM 도구, 터미널 사용 가능 여부, 민감 정보 가능성, 반복 작업 빈도를 나눈다.
4. 시작 방식을 고른 이유를 한 문장으로 쓴다.
5. 수동 Markdown을 기준선으로 놓고, 에이전트, CLI, 데스크톱 방식이 필요한 이유가 있는지 따진다.
6. Codex나 Claude Code를 쓰려면 해당 도구가 어떤 지침 파일을 읽는지 확인한다.
7. 플러그인이나 CLI를 검토한다면 공식 README, Releases, Changelog, 설치된 도움말을 먼저 본다.
8. 도구 후보별로 30분 안에 샘플 자료를 넣어 볼 수 있는지 확인한다.
9. 샘플 검증에서 원본 자료와 위키 문서가 분리되는지 본다.
10. 생성된 위키 문서가 사람이 직접 열고 고칠 수 있는 형식인지 확인한다.
11. 저장 위치, 백업 방법, 삭제 방법, export 가능성을 적는다.
12. 웹 수집, 플러그인, API 키, 외부 모델 호출이 있다면 네트워크와 권한 범위를 적는다.
13. PDF, 이미지, 코드 세션처럼 애매한 형식은 공개 샘플로 먼저 시험한다.
14. 샘플 답변이나 문서에서 원천 경로, 확인 날짜, 확인 필요가 남는지 점검한다.
15. 첫 실습 환경을 raw/, wiki/, output/, index.md, log.md, AGENTS.md, 선택적 CLAUDE.md로 만든다.
16. 내 실습 환경 문서를 작성한다. 어떤 도구를 쓰고, 어떤 자료를 넣지 않으며, 어떤 검증을 할지 한 장에 적는다.
17. 도구 선택표에서 낮은 위험의 답이 부족하면 도구 도입을 미루고 수동 Markdown으로 시작한다.
18. 4장으로 넘어가기 전에 작은 자료 하나가 원천, 위키 문서, index, log, 검증 질문으로 이어지는지 확인한다.

예시와 체크리스트

시작 방식 판단표

30분 샘플 위키 검증

• raw/에 원천 샘플이 보존된다.
• wiki/에 원천을 가리키는 정리 문서가 생긴다.
• output/ 또는 산출물 후보가 원천과 위키 근거를 가리킨다.
• index.md에 새 문서 링크와 한 줄 설명이 있다.
• log.md에 자료 추가, 문서 생성, 확인 필요가 남는다.
• rules 파일이 원본 수정 금지, 출처 표기, 확인 필요 표시, log 갱신을 요구한다.
• 도구가 만든 답변을 원본과 대조했다.
• 실제 고객 정보나 비공개 자료를 사용하지 않았다.

내 실습 환경 문서 템플릿

# 나의 LLM위키 실습 환경

## 기본 선택
- 실습 폴더:
- 주로 사용할 LLM 도구:
- Markdown 편집기:
- 터미널 사용 가능 여부:

## 폴더 구조
- 원천 자료: raw/
- 정리된 위키 문서: wiki/
- 산출물: output/
- 인덱스: index.md
- 작업 로그: log.md

## 작업 규칙
- Codex를 쓰는 경우: AGENTS.md를 기준으로 확인한다.
- Claude Code를 쓰는 경우: CLAUDE.md를 기준으로 확인한다.
- 둘 다 쓰는 경우: CLAUDE.md에서 AGENTS.md를 가져오는 방식을 확인한다.

## 자료 입력 기준
- 첫 실습에는 가상 자료 또는 익명화 자료만 사용한다.
- 개인정보, 계약 정보, 고객 원문, 비공개 코드는 그대로 넣지 않는다.
- 원본 파일은 raw/에 보관하고 임의로 수정하지 않는다.

## 검증 기준
- 위키 문서에 원천 자료 경로가 있는가?
- 확인되지 않은 내용이 확인 필요에 적혀 있는가?
- 작업 후 log.md에 기록할 내용이 남았는가?
- 도구가 만든 답변을 원본과 대조했는가?

검증 질문

• 도구 이름보다 작은 검증 가능성을 먼저 봐야 하는 이유를 설명할 수 있는가?
• 내가 고른 시작 방식의 이유를 한 문장으로 말할 수 있는가?
• 수동 Markdown을 기준선 또는 되돌아갈 경로로 남겨 두었는가?
• Codex를 쓰면 AGENTS.md, Claude Code를 쓰면 CLAUDE.md 로드 여부를 실제로 확인했는가?
• 플러그인이나 /wiki, @wiki 같은 명령을 공식 내장 기능으로 단정하지 않고 해당 구현체 문서 기준으로 이해했는가?
• CLI 도구를 고를 때 Node/Python/API 키/환경 변수/버전 전제를 확인했는가?
• 데스크톱 도구를 고를 때 저장 위치, 백업, export, 원본 보존을 확인했는가?
• 도구 후보가 원천 자료와 위키 문서를 분리해 저장하는가?
• 생성된 위키 문서를 사람이 직접 열고 고칠 수 있는가?
• 공식 README, Releases, Changelog, 설치된 도움말을 확인했는가?
• PDF, 이미지, 코드 세션처럼 애매한 자료는 공개 샘플로 먼저 테스트했는가?
• 웹 수집, 플러그인, API 호출이 있다면 네트워크 접근과 권한 범위를 설명할 수 있는가?
• 첫 실습 자료가 실제 고객 정보, 계약 정보, 개인정보, 비공개 코드를 포함하지 않는가?
• 10분 또는 30분 미니 위키에서 원천, 위키 문서, index, log, 확인 필요가 남았는가?
• 4장으로 넘어가기 전에 내 실습 환경 문서를 만들었는가?

누락 또는 주의사항

• 장 랜딩 원문은 세 하위 절 목록 중심의 짧은 페이지다. 이 문서는 장 랜딩만이 아니라 3.1-3.3 세부 원문을 함께 반영해 장 수준으로 재구성했다.
• Codex, Claude Code, nvk/llm-wiki, atomicstrata/llm-wiki-compiler, OpenKB, nashsu/llm_wiki, WiCER 관련 설명은 원문 확인일 기준의 도구와 문서 확인 결과다. 실제 도입 전에는 현재 공식 문서, 릴리스, 설치된 도움말, 조직 보안 정책을 다시 확인해야 한다.
• AGENTS.md와 CLAUDE.md는 결과를 강제하는 장치가 아니다. 모델이 규칙을 읽었다고 해도 원본 보존, 출처 표기, 확인 필요 표시, index/log 갱신을 결과물에서 다시 검토해야 한다.
• 플러그인이나 CLI 도구가 로컬 파일을 만든다고 해도 URL 수집, 웹 리서치, LLM 호출, 외부 API 사용은 호스트 도구와 조직 정책을 따른다. 고객 원문, 개인정보, 계약 정보, 비공개 코드, 내부 정책 자료는 첫 실습에 그대로 넣지 않는다.
• 수동 Markdown 방식은 낮은 위험의 기준선이지만 자료가 많아지면 색인, 중복, 링크, 감사 부담이 커진다. 반복 작업이 많아졌을 때는 3.2의 도구 선택표로 에이전트, CLI, 데스크톱 확장을 다시 검토한다.

관련 문서 연결