카파시의 LLM 위키? 클로드·깃허브 코파일럿으로 코드 없이!
Source: Dev.to
나는 처음에 Andrej Karpathy의 LLM Wiki gist를 접했을 때, AI 시대에 지식을 관리하는 방법에 대한 핵심적인 통찰을 담고 있다는 것을 깨달았다. 바로 구조화된, 인간이 직접 큐레이션하는 지식 베이스가 LLM이 환각을 일으키는 것이 아니라, 우리가 공급하는 내용으로부터 성장한다는 점이다. 하지만 대부분의 구현체는 무거운 코딩을 요구했다. 그래서 나는 Claude Code와 GitHub Copilot의 .github/copilot-instructions.md 시스템 모두와 원활히 작동하는 완전 무코드 버전을 만들기로 했다.
그 결과가 llm-wiki-nocode다. 이는 문서를 ingest하고, 질문을 던지고, 살아있는 위키를 유지관리하는 모든 과정을 자연어 명령만으로 수행할 수 있는, 프로덕션 수준의 지식 관리 시스템이다. 파이썬은 전혀 필요하지 않다.
개념 설명
LLM Wiki는 다음과 같은 특징을 가진 구조화된 지식 베이스이다.
- 원시 문서를 ingest 하여 엔티티(도구, 사람, 기업), 개념(패턴, 아이디어), 관계를 추출한다.
- 사실은 저장된 지식에서만 검색한다(학습 데이터나 환각 없음).
- 자동 건강 검진과 인간 리뷰를 통해 무결성을 유지한다.
- 자동 생성된 답변을 검증·정제하면서 지식이 점진적으로 축적된다.
핵심 원칙은 단순하다: 위키가 아는 모든 것은 당신이 공급한 내용에서만 나온다. LLM의 학습 데이터도, 웹도 아니다. 오직 당신의 소스만이 출처다.
이 접근법은 실제 문제를 해결한다. 자사 시스템에 대해 LLM에 질문하면 종종 자신 있게 허구를 만들어낸다. 위키 기반 접근법은 해당 지식이 없을 경우 “아무것도 찾지 못했습니다”라고 답하게 만든다. 오염도, 허위 권위도 없다.
대부분의 LLM Wiki 구현은 Python 환경, 의존성 관리, 벡터 DB, 디버깅 등을 전제한다. 이는 잘못된 진입 장벽이다.
나는 별도로 Microsoft Agent Framework를 활용한 프로덕션용 Python 버전도 개발 중이다. 이는 에이전트 워크플로, 지식 그래프 구축, 의미 검색 등을 중심으로 설계된 별도 프로젝트이며, 추후 글에서 다룰 예정이다.
이번 프로젝트는 반대 접근법을 취한다: 의존성 0, 설치 0, 순수 자연어. 마찰 없이 즉시 사용 가능하다.
자연어만으로 문서를 ingest하고, 질문하고, 지식 베이스를 유지한다면?
- 터미널? 필요 없다.
pip install? 필요 없다.- YAML 설정? 필요 없다.
그냥 영어처럼 읽히는 명령만 입력하면 된다.
/wiki-ingest
/wiki-query What are the key architectural patterns?
/wiki-lint
이것이 llm-wiki-nocode가 제공하는 전부다. 시스템은 인간이 직접 조작할 수 있도록 설계되었다. 코드를 한 줄도 짜보지 않은 사람도 자신의 지식 베이스를 만들고 유지할 수 있다.
위키 인터페이스: 세 가지 명령
위키는 세 가지 명령만으로 동작한다. 나머지는 이 세 가지에서 파생된다.
- /wiki-ingest – 지식 베이스 구축
- /wiki-query – 환각 없는 질문
- /wiki-lint – 건강 검진
/wiki-ingest – 문서를 지식으로 변환
문서를 원시 파일(Markdown, 텍스트 등)로 지정하면, 엔티티(도구, 프레임워크, 기업, 사람)와 개념(패턴, 방법론, 원칙)을 추출한다. 그리고 이들 사이의 관계를 감지하고, 기존 위키 페이지와 병합하며, 모순은 플래그로 표시한다. 인덱스와 감사 로그도 한 번에 업데이트된다.
- 파일 경로 지정
scan옵션으로 자동 ingest--RESET-ALL로 전체 초기화
출력은 wiki/ 안의 새 페이지·업데이트된 페이지와 변경 로그다.
/wiki-query – 환각 없이 질문하기
자연어 질문을 입력하면, 시스템은 관련 위키 페이지 3~8개를 읽고 그 내용만으로 답변을 합성한다. 외부 지식이나 학습 데이터는 전혀 사용되지 않는다. 답변의 모든 주장에는 위키링크가 달려 정확한 출처를 보여준다. 답변은 questions_pending/에 저장돼 검토 후 위키에 합성 페이지로 통합된다.
/wiki-lint – 위키 건강 검진
Lint는 두 단계로 진행된다.
- 결정론적 단계 – 깨진 링크, 고아 페이지, 누락된 frontmatter, 빈 섹션 탐지
- 의미론적 단계 – 모순, 오래된 주장, 누락된 페이지, 참조되지 않은 엔티티 탐지
결과 보고서는 lint_pending/에 저장돼 검토·승인 후 적용한다.
디렉터리 구조 이해하기
위키가 어떻게 동작하는지 이해하려면 디렉터리 구조를 파악해야 한다.
wiki/ ← 살아있는 지식 베이스
├── index.md ← 모든 페이지 카탈로그
├── log.md ← 작업 감사 로그
├── sources/ ← ingest된 문서당 1페이지
├── entities/ ← 명명된 것들: 도구, 프레임워크, 기업
├── concepts/ ← 추상 아이디어: 패턴, 방법론
└── synthesis/ ← 질문에 대한 승인된 답변
raw/ ← ingest 대기 중인 문서들
questions_pending/ ← 자동 생성 답변 (검토 대기)
questions_approved/ ← 검증된 답변
lint_pending/ ← 위키 건강 보고서 (검토 대기)
lint_approved/ ← 승인된 수정 사항
docs/ ← 사양 및 가이드
핵심 인사이트: wiki/가 단일 진실 원천이다. 그 외는 모두 인간의 결정을 기다리는 대기열이다. raw/는 입력, questions_pending/·lint_pending/는 결정 대기, 승인이 되면 _approved/로 이동해 wiki/에 통합된다.
페이지 타입 세 가지
위키는 지식을 체계화하기 위해 세 가지 페이지 타입을 사용한다.
- Sources – 문서를 ingest하면 생성된다. 파일당 하나의 페이지이며, 제목·저자·날짜·원본 내용·추출된 엔티티·개념 리스트를 포함한다. 이는 감사 추적 역할을 한다.
- Entities – 명명된 실체(도구, 프레임워크, 기업, 사람 등)이다. 각 엔티티 페이지에는 정의, 등장 위치(어떤 source·concept가 참조했는지), 관련 엔티티가 기록된다. 이렇게 하면 상호 연결된 지식 웹이 형성된다.
- Concepts – 추상 아이디어·패턴이다. 예: 마이크로서비스, CQRS, DRY, YAGNI 등. 각 페이지에는 설명, 예시(항상 출처 인용 포함), 관련 개념·엔티티와의 연결이 들어간다. 개념은 소스 전반에 걸친 패턴을 보여준다.
인간‑게이트 승인 루프
다른 구현과 차별되는 점은 자동 결정을 100% 내리지 않는다는 것이다. 시스템은 생성 → ingest → 질문 → 건강 검진 순으로 자동 작업을 수행하고, 결과는 _pending/ 폴더에 남긴다. 사용자는 여기서 어떤 자동 생성 콘텐츠를 통합하고, 어떤 것을 수정·거부할지 판단한다. 승인되면 콘텐츠는 _approved/로 이동해 살아있는 위키에 반영된다.
이 루프는 협상 불가다. 시스템은 보조 역할을 할 뿐, 최종 결정은 인간이 내린다. “어느 날 아침에 위키가 수천 개의 나쁜 결정을 스스로 내렸다”는 일은 일어나지 않는다.
자동 생성 → 인간 검토 → 통합
↓ ↓ ↓
@wiki-querier questions_pending/ wiki/synthesis/
@wiki-linter lint_pending/ wiki pages updated
테스트용 샘플 문서
bak/ 디렉터리에는 테스트용 문서 세 개가 포함돼 있다.
afw-instructions.md– Microsoft Agent Framework 모범 사례에 대한 기술 문서mfa_agents_howto.md– 에이전트 구축 가이드ARCH_BOOKING_PLATFORM.md– 가상 시스템 아키텍처 문서
이 예시들은 위키가 다양한 소스를 어떻게 처리하는지 보여준다.
테스트하려면 파일을 raw/에 복사하고 ingest 명령을 실행한다.
cp bak/ARCH_BOOKING_PLATFORM.md raw/
wiki-ingest