Karpathy의 LLM Wiki? Claude 또는 GitHub Copilot을 활용한 노코드(No-Code) 방식!

저는 처음 Andrej Karpathy의 LLM Wiki gist를 접했을 때, 우리가 AI 시대에 지식을 어떻게 관리해야 하는지에 대한 본질적인 무언가를 포착했다는 것을 깨달았습니다. 즉, LLM이 환각(Hallucination)을 일으키는 내용이 아니라, 사용자가 입력하는 데이터로부터 성장하는 구조화된 인간 큐레이션 지식 베이스(Knowledge Base)입니다. 문제는 제가 발견한 대부분의 구현 방식이 과도한 코딩을 요구한다는 점이었습니다. 그래서 저는 Claude Code 및 GitHub Copilot의 .github/copilot-instructions.md 시스템과 원활하게 작동하는 완전한 노코드(No-Code) 버전을 구축하기로 결정했습니다. 그 결과물인 llm-wiki-nocode는 문서를 입력하고, 질문을 던지며, 살아있는 위키를 유지 관리할 수 있는 프로덕션 준비 완료(Production-ready) 지식 관리 시스템입니다. 이 모든 과정은 Python이 전혀 필요 없이 자연어 명령만으로 이루어집니다.

LLM Wiki란 무엇인가?
구현 단계로 들어가기 전에 개념을 설명하겠습니다. LLM Wiki는 다음과 같은 특징을 가진 구조화된 지식 베이스입니다:

• 원시 문서(Raw documents)를 입력받아 엔티티(도구, 사람, 회사), 개념(패턴, 아이디어), 그리고 관계를 추출합니다.
• 저장된 지식으로부터만 사실을 검색합니다 (학습 데이터 사용 안 함, 환각 없음).
• 자동화된 상태 점검(Health checks)과 인간의 검토를 통해 무결성을 유지합니다.
• 자동 생성된 답변을 검증하고 정제함에 따라 지식이 축적됩니다.

핵심 원칙은 간단합니다. 위키가 알고 있는 모든 것은 사용자가 입력한 데이터로부터 옵니다. LLM의 학습 데이터가 아닙니다. 웹에서도 아닙니다. 오직 사용자의 소스(Sources)로부터만 옵니다. 이는 실제 문제를 해결합니다. 사용자가 자신의 독점적인 시스템(Proprietary system)에 대해 LLM에 질문할 때, LLM은 종종 자신 있게 거짓 정보를 만들어내곤 합니다. 위키 기반 접근 방식은 지식이 존재하지 않을 경우 LLM이 "찾은 내용이 없습니다"라고 인정하도록 강제합니다. 오염도 없고, 잘못된 권위도 없습니다.

왜 노코드(No-Code)인가?
대부분의 LLM Wiki 구현 방식은 사용자가 Python 환경, 의존성 관리(Dependency management), 벡터 데이터베이스(Vector databases), 그리고 통합 과정의 디버깅을 견딜 인내심을 갖추고 있다고 가정합니다. 이는 잘못된 진입 장벽입니다. 저는 또한 에이전트 워크플로우(Agentic workflows), 지식 그래프(Knowledge graph) 구축, 그리고 시맨틱 검색(Semantic retrieval)을 중심으로 구조화된 Microsoft Agent Framework를 사용하여 프로덕션용 Python 버전도 구축하고 있습니다.

하지만 그것은 자체적인 아키텍처(Architecture)와 트레이드오프(Tradeoffs)를 가진 별개의 프로젝트입니다. 이는 향후 기사의 주제가 될 것입니다. 이 프로젝트는 정반대의 접근 방식을 취합니다: 의존성 제로(Zero dependencies), 설치 제로(Zero installation), 순수 자연어(Pure natural language). 마찰 없음. 즉각적인 사용성. 만약 문서를 입력하고, 질문을 던지며, 오직 자연어만으로 지식 베이스(Knowledge base)를 완전히 유지 관리할 수 있다면 어떨까요? 터미널(Terminal)도 필요 없습니다. pip install도 필요 없습니다. YAML 설정도 필요 없습니다. 그저 영어처럼 읽히는 명령만 있으면 됩니다: /wiki-ingest, /wiki-query, /wiki-lint. 이것이 바로 llm-wiki-nocode가 제공하는 것입니다. 이 시스템은 인간이 조작하기 쉽도록(Human-operable) 설계되었습니다. 즉, 코드를 단 한 줄도 작성해 본 적 없는 사람도 자신만의 지식 베이스를 구축하고 유지 관리할 수 있습니다.

세 가지 핵심 작업 (The Three Core Operations)
위키의 전체 인터페이스는 세 가지 명령으로 구성됩니다. 그 외의 모든 것은 이 세 가지에서 파생됩니다:

1. /wiki-ingest, 지식 베이스 구축하기
   Ingest는 문서가 지식이 되는 단계입니다. 원본 파일(Markdown, 일반 텍스트 등 무엇이든)을 지정하면, 시스템은 엔티티(Entities)를 추출합니다. 엔티티란 도구, 프레임워크, 회사, 사람과 같은 명명된 대상(Named things)과 패턴, 방법론, 원칙과 같은 추상적인 개념(Concepts)을 의미합니다. 시스템은 이들 사이의 관계를 탐지하고, 새로운 정보를 기존 위키 페이지와 병합하며, 검토가 필요한 모순 사항을 표시하고, 인덱스(Index)와 감사 로그(Audit log)를 한 번의 과정으로 업데이트합니다. 파일 경로를 전달하거나, 자동 인제스트(Auto-ingest)를 위해 scan을 사용하거나, 완전히 새로 시작하고 싶다면 --RESET-ALL을 사용할 수 있습니다. 결과물로는 wiki/ 폴더 내의 새 페이지 및 업데이트된 페이지와 무엇이 변경되었는지에 대한 상세 로그가 생성됩니다.

2. /wiki-query, 환각(Hallucination) 없는 질문하기
   Query는 검색(Retrieval) 측면입니다. 자연어로 질문을 던지면, 시스템은 3~8개의 관련 위키 페이지를 읽고 오직 해당 콘텐츠로부터만 답변을 합성(Synthesize)합니다. 외부 지식은 사용하지 않습니다. 학습 데이터 오염(Training data pollution)도 없습니다. 이것이 핵심 약속입니다: 답변의 모든 주장은 정확히 어디에서 왔는지 보여주는 위키링크(Wikilink)와 함께 인용됩니다.

답변은 위키의 종합 페이지(synthesis page)로 통합되기 전, 사용자의 검토를 위해 questions_pending/ 폴더에 저장됩니다. 3. /wiki-lint, Maintain Health Lint는 위키의 상태를 점검하는 도구입니다. 이는 두 단계로 실행됩니다: 첫 번째는 깨진 링크(broken links), 고립된 페이지(orphaned pages), 누락된 프론트매터(frontmatter), 빈 섹션(empty sections)을 잡아내는 결정론적 단계(deterministic pass)입니다. 그다음은 모순(contradictions), 오래된 주장(stale claims), 누락된 페이지, 참조되지 않은 엔티티(unreferenced entities)를 찾는 의미론적 단계(semantic phase)입니다. 출력 결과는 제안된 수정 사항이 포함된 상세 보고서이며, 사용자가 검토하고 승인할 수 있도록 lint_pending/에 저장됩니다. 디렉토리 구조(The Directory Structure) 레이아웃을 이해하는 것은 위키가 어떻게 작동하는지 이해하는 핵심입니다: wiki/ ← 살아있는 지식 베이스 (Living knowledge base)
├── index.md ← 모든 페이지의 카탈로그
├── log.md ← 운영 감사 추적 (Operation audit trail)
├── sources/ ← 수집된 문서당 하나의 페이지
├── entities/ ← 명명된 대상: 도구, 프레임워크, 회사
├── concepts/ ← 추상적 아이디어: 패턴, 방법론
└── synthesis/ ← 질문으로부터 승인된 답변들
raw/ ← 수집 대기 중인 문서
questions_pending/ ← 자동 생성된 답변 (사용자 검토 필요)
questions_approved/ ← 사용자가 검증한 답변
lint_pending/ ← 위키 상태 보고서 (사용자 검토 필요)
lint_approved/ ← 사용자가 승인한 수정 사항
docs/ ← 사양 및 가이드
핵심 통찰: wiki/는 단일 진실 공급원(single source of truth)입니다. 그 외의 모든 것은 인간의 결정을 기다리는 대기열(queue)입니다. raw/는 입력값입니다. questions_pending/와 lint_pending/은 내려져야 할 결정을 기다리는 상태입니다. 무언가를 승인하면 _approved/로 이동하여 다시 wiki/로 통합됩니다. 세 가지 페이지 유형(Three Page Types) 위키는 지식을 체계적으로 유지하기 위해 세 가지 별개의 페이지 유형을 사용합니다. Sources(소스)는 문서를 수집할 때 생성되며, 소스 파일당 하나의 페이지가 만들어집니다. 각 소스 페이지에는 제목, 저자, 날짜, 원문 내용(raw content), 그리고 해당 문서에서 추출된 모든 엔티티(entities)와 개념(concepts) 목록이 포함됩니다. 이것은 여러분의 감사 추적(audit trail)이 됩니다: 어떤 정보가 정확히 어떤 문서에서 왔는지 알 수 있습니다. Entities(엔티티)는 이름이 있고 식별 가능한 대상입니다. Jira나 Kubernetes 같은 도구, React나 MAF 같은 프레임워크, 회사, 또는 인물 등이 이에 해당합니다.

각 엔티티 (Entity) 페이지에는 정의, 등장 위치(어떤 소스와 개념이 이를 참조하는지), 그리고 관련 엔티티가 나열됩니다. 이는 서로 연결된 지식의 웹을 형성합니다. 개념 (Concepts)은 추상적인 아이디어와 패턴입니다. 마이크로서비스 (microservices)나 CQRS와 같은 방법론, DRY 또는 YAGNI와 같은 원칙, 혹은 디자인 패턴 (Design Pattern) 등이 이에 해당합니다. 각 개념 페이지에는 설명, 예시 (항상 출처 인용 포함), 그리고 관련 개념 및 엔티티와의 연결 정보가 포함됩니다. 개념은 여러분이 소스 전반에서 패턴을 파악하는 방식입니다.

작동 방식: 인간이 통제하는 루프 (The Human-Gated Loop)
이 부분은 llm-wiki-nocode를 다른 구현 방식과 차별화하는 지점입니다. 시스템은 100% 자동으로 결정을 내리고 사용자가 그 결과를 떠안게 방치하지 않습니다. 대신, 인간의 승인을 거치는 루프 (human-gated approval loop)를 따릅니다. 시스템은 문서를 생성하고, 수집하며, 질문에 답하고, 상태 문제 (health issues)를 찾아냅니다. 그런 다음 여러분은 _pending/ 폴더를 확인하며 생성된 내용을 검토합니다. 어떤 자동 생성 콘텐츠를 통합할 만큼 충분히 좋은지, 어떤 것이 개선이나 거절이 필요한지 결정합니다. 승인하면 콘텐츠는 _approved/로 이동하여 살아있는 위키 (living wiki)에 다시 통합됩니다. 이 루프는 타협할 수 없는 원칙입니다. 시스템은 보조할 뿐이며, 결정은 여러분이 합니다. 어느 날 아침 일어났을 때 위키가 밤새 수천 개의 잘못된 결정을 내렸다는 사실을 발견하는 일은 결코 없을 것입니다.

자동 생성 → 인간 검토 → 통합
↓ ↓ ↓
@wiki-querier questions_pending/
wiki/synthesis/
@wiki-linter lint_pending/
wiki pages updated

시작하기: 실질적인 예시
저장소(Repo)의 bak/ 디렉토리에는 테스트를 위한 세 가지 완성된 문서가 포함되어 있습니다. Microsoft Agent Framework의 모범 사례에 관한 기술 문서인 afw-instructions.md가 있습니다. mfa_agents_howto.md는 에이전트 (agents) 구축을 위한 가이드입니다. 그리고 ARCH_BOOKING_PLATFORM.md는 시뮬레이션된 시스템 아키텍처 (system architecture) 문서입니다. 이 예시들은 위키가 어떻게 다양한 소스 자료를 처리하는지 보여줍니다.

위키를 테스트하려면, 이 파일 중 하나를 raw/로 복사하고 ingest를 실행하세요: cp bak/ARCH_BOOKING_PLATFORM.md raw/ /wiki-ingest. 인제스터 (ingestor)는 아키텍처 문서를 파싱(parse)하여 서비스(services), 기술(technologies), 팀(teams)과 같은 엔티티 (entities)를 추출하고, "마이크로서비스 (microservices)", "이벤트 기반 (event-driven)", "CQRS"와 같은 개념 (concepts)을 뽑아내며, wiki/entities/ 및 wiki/concepts/에 각각의 페이지를 생성하고, 모든 변경 사항을 wiki/log.md에 기록합니다. 그다음, 질문을 던져보세요: /wiki-query 예약 플랫폼의 핵심 서비스는 무엇인가요? 쿼리어 (querier)는 위키에서 관련 페이지를 검색하여, 위키에 있는 내용만을 사용하여 답변하고, 위키링크 (wikilinks)로 출처를 인용하며, 귀하의 검토를 위해 답변을 저장합니다. 마지막으로, 상태 점검 (health check)을 실행하세요: /wiki-lint. 린터 (linter)는 깨진 링크, 고립된 페이지 (orphaned pages), 모순 사항을 확인하고 수정 사항을 제안합니다. 귀하가 보고서를 검토하고 어떤 수정 사항을 적용할지 결정하면, 위키는 스스로 개선됩니다.

설정 계층 (Configuration Layer): .claude/ 및 .github/
이 부분은 설명할 가치가 있는 매우 중요한 설계 결정입니다.

.claude/ 디렉토리, Claude Code 설정
.claude/ 폴더에는 Claude Code를 위한 완전한 설정이 포함되어 있습니다:
.claude/
├── CLAUDE.md ← 프로젝트 지침 및 행동 제약 사항 (behavioral constraints)
├── settings.json ← 명령 등록 및 하네스 (harness) 설정
└── commands/
├── wiki-ingest.md ← /wiki-ingest 명령 워크플로 (workflow) 정의
├── wiki-query.md ← /wiki-query 명령 워크플로 정의
└── wiki-lint.md ← /wiki-lint 명령 워크플로 정의

작동 방식:
CLAUDE.md는 위키의 정체성과 사용 가능한 명령을 정의하는 메인 시스템 프롬프트 (system prompt)입니다. settings.json은 각 명령을 등록하고 이를 워크플로에 매핑 (map)합니다. commands/ 내의 각 파일은 완전한 명세 (specification)이며, Claude에게 해당 작업을 어떻게 수행할지 정확하게 알려줍니다: 무엇을 읽을지, 무엇을 추출할지, 어떤 형식을 사용할지, 무엇을 검증할지를 정의합니다. Claude Code에서 /wiki-ingest를 입력하면, Claude는 commands/wiki-ingest.md를 읽고 해당 워크플로를 실행합니다.

.github/ 디렉토리, GitHub Copilot 설정

마찬가지로, .github/에는 GitHub Copilot 전용 지침이 포함되어 있습니다:

.github/
├── prompts/
│ ├── wiki-ingest.prompt.md ← ingest 명령을 위한 LLM 프롬프트 (LLM prompt)
│ ├── wiki-query.prompt.md ← query 명령을 위한 LLM 프롬프트 (LLM prompt)
│ └── wiki-lint.prompt.md ← lint 명령을 위한 LLM 프롬프트 (LLM prompt)
├── instructions/
│ └── wiki-schema.instructions.md ← 공유 페이지 형식 및 스키마 문서 (Shared page format and schema documentation)
└── agents/
├── wiki-ingestor.agent.md ← Ingestor 에이전트 정의 (Ingestor agent definition)
├── wiki-querier.agent.md ← Querier 에이전트 정의 (Querier agent definition)
└── wiki-linter.agent.md ← Linter 에이전트 정의 (Linter agent definition)

GitHub Copilot은 저장소(repo)를 열 때 이 파일들을 자동으로 읽습니다. prompts/ 폴더에는 LLM 지침(Claude의 commands/와 유사함)이 들어 있습니다. agents/ 폴더는 각 에이전트가 어떻게 동작하는지를 정의합니다. instructions/ 폴더는 공유 스키마 문서를 보유하고 있어, Claude Code와 Copilot 모두 페이지 형식을 동일하게 이해할 수 있도록 합니다.

멘탈 모델 (Mental Model):
.claude/와 .github/를 플랫폼별 어댑터 (platform-specific adapters)라고 생각하세요.
핵심 로직(무엇을 추출할지, 어떻게 형식을 맞출지, 무엇을 검증할지)은 wiki-schema.instructions.md를 통해 공유됩니다.
하지만 명령을 호출하는 방식, 구문(syntax), 그리고 각 LLM 시스템이 워크플로(workflows)를 구성하는 방식은 Claude Code와 GitHub Copilot 간에 서로 다릅니다.

이러한 이중 지원(dual-support) 방식은 다음을 의미합니다:

• Claude Code를 사용하는 경우:
  프로젝트를 열고 /wiki-ingest를 입력하면, Claude가 .claude/commands/wiki-ingest.md를 읽습니다.
• GitHub Copilot을 사용하는 경우:
  저장소가 자동으로 통합되며, Copilot이 .github/prompts/wiki-ingest.prompt.md를 읽고 .github/agents/wiki-ingestor.agent.md를 사용합니다.
• 둘 다 사용하지 않는 경우:
  여전히 모든 파일을 읽고 각 작업이 정확히 무엇을 하는지 이해할 수 있습니다.

핵심 로직은 중복되지 않습니다. 두 버전 모두 동일한 의미론(semantics)을 가진 동일한 세 가지 작업을 구현하며, 단지 서로 다른 방언(dialects)을 사용할 뿐입니다.

주요 설계 선택 (Key Design Choices)
전체 구현 과정을 거치면서 공유할 가치가 있는 몇 가지 중요한 패턴을 발견했습니다.
위키는 미세 조정 (fine-tuning)이 아닌 검색 전용 쿼리 (retrieval-only queries)를 사용합니다.

이는 LLM (Large Language Model)을 학습시키거나 수정하지 않습니다. 대신, 시맨틱 검색 (semantic search)을 사용하여 관련 페이지를 찾고, 오직 해당 페이지들로부터만 답변을 합성하도록 LLM에 요청합니다. 이는 미세 조정 (fine-tuning)을 결합한 RAG (Retrieval-Augmented Generation)보다 구현이 더 간단하면서도 더 신뢰할 수 있습니다. 엔티티 (Entity)와 컨셉 (Concept)은 근본적으로 다르며, 이를 구분하여 다루는 것이 중요합니다. Jira나 PostgreSQL 같은 도구는 엔티티, 즉 지칭할 수 있는 구체적인 대상입니다. CQRS나 이벤트 소싱 (event sourcing) 같은 패턴은 컨셉, 즉 다양한 맥락에 적용될 수 있는 아이디어입니다. 위키가 이러한 구분을 이해하면, "Kubernetes와 관련된 컨셉은 무엇인가요?"라고 물었을 때 의미 있고 연결된 답변을 얻을 수 있습니다. 통합 전 인간의 검토는 타협할 수 없는 필수 사항입니다. 단 한 번의 문서 인제스트 (ingest)로도 수백 개의 페이지가 생성될 수 있습니다. 만약 이를 검토하지 않는다면, 위키에는 쓰레기 데이터가 쌓이게 될 것입니다. _pending/ 폴더는 결정 지점을 강제합니다. 초기에 투입되는 저렴한 인간의 주의력이 나중에 손상된 데이터를 디버깅하는 수고를 덜어줍니다. 감사 추적 (audit trail)은 필수입니다. 모든 작업과 모든 인제스트는,