LLM Wiki 실전 종합 가이드: Karpathy 방식으로 구축·운영·활용까지 한 번에 끝내기

LLM 위키를 만들고 싶다는 얘기는 많이 나오는데, 실제로 끝까지 운영하는 팀은 많지 않습니다. 이유는 간단합니다. "좋은 아이디어"와 "돌아가는 시스템" 사이에는 운영 설계가 필요하기 때문입니다.

이번 글은 앞서 올린 5편을 하나로 묶은 실전 종합본입니다. 목표는 하나입니다.

• 오늘 읽고
• 오늘 폴더 만들고
• 이번 주 안에 실제로 굴리기

이 글에서는 Andrej Karpathy가 공유한 LLM Knowledge Base 아이디어를 바탕으로, 실제 적용 가능한 구조·운영 루프·프롬프트·검증 방식·활용 시나리오까지 한 번에 정리합니다.

참고 원문(직접 확인):

• Karpathy X 스레드: https://x.com/karpathy/status/2039805659525644595
• Karpathy gist (llm-wiki): https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

---

1) 먼저 문제부터 정확히 정의하자: 왜 팀 문서는 계속 죽는가

대부분 팀이 문서화를 실패하는 원인은 글쓰기 실력이 아닙니다. 운영 비용이 너무 크기 때문입니다.

자주 일어나는 패턴은 이렇습니다.

1. 문서는 만든다
2. 업데이트는 안 된다
3. 링크는 깨진다
4. 서로 다른 문서가 충돌한다
5. 결국 "최신 정보는 슬랙 검색"으로 회귀한다

LLM 도입 후에도 이 문제가 그대로 남는 이유는, LLM을 "답변기"로만 쓰고 "지식 운영자"로 쓰지 않기 때문입니다.

즉, 질문-답변은 빨라졌는데 지식 자산화는 안 된 상태입니다.

이 지점에서 LLM 위키가 필요합니다. 핵심은 단순합니다.

• 문서를 질의 때마다 다시 찾지 말고
• 평소에 위키로 컴파일해두고
• 질문 결과까지 다시 위키에 누적한다

이 구조가 잡히면, 질문할수록 팀 지식이 강해집니다.

---

2) LLM 위키의 기본 아키텍처: raw / wiki / index / log

최소 구조는 다음이면 충분합니다.

llm-wiki/
  raw/
    articles/
    papers/
    repos/
    meetings/
    assets/
  wiki/
    concepts/
    entities/
    playbooks/
    decisions/
    comparisons/
  outputs/
    reports/
    slides/
    charts/
  index.md
  log.md
  RULES.md

raw/

원문 저장소입니다. 절대 수정하지 않습니다(불변). 원문이 바뀌면 추적이 깨지고 신뢰가 무너집니다.

wiki/

LLM이 유지하는 지식층입니다. 요약, 개념 정리, 링크 연결, 충돌 표기, 운영 런북까지 이곳에 쌓입니다.

outputs/

질의 결과 산출물(리포트, 슬라이드, 차트)을 둡니다. 좋은 결과는 wiki로 승격합니다.

index.md

"뭘 어디서 읽어야 하는지"를 안내하는 지도입니다. 문서가 100개 넘어가면 index 품질이 답변 품질을 좌우합니다.

log.md

언제 어떤 소스를 넣었고, 어떤 문서를 갱신했는지 남기는 이력입니다. 운영 신뢰의 핵심입니다.

RULES.md

LLM의 동작 규칙입니다. 이 파일이 곧 운영 정책이며, 품질 가드레일입니다.

---

3) RULES.md에 반드시 넣어야 할 12개 규칙

아래 12개는 실무에서 바로 효과가 납니다.

1. raw는 읽기 전용, 수정 금지
2. ingest 시 index/log 업데이트 필수
3. 새 문서 생성 시 관련 문서 2개 이상 링크
4. 기존 주장과 충돌 시 삭제하지 말고 "충돌" 섹션에 기록
5. 숫자/지표가 포함된 문장은 출처 링크 필수
6. 추상 문장은 금지, 구체 예시 또는 수치 포함
7. 질의 결과가 재사용 가치 있으면 wiki로 승격
8. 한 문서에 논점 1개 원칙(길어지면 분할)
9. 30일 이상 미갱신 핵심 문서 경고
10. 고아 페이지(인바운드 링크 0) 점검
11. 폐기된 결론은 "Deprecated" 표시
12. 주 1회 lint 실행 결과를 log.md에 남김

이 규칙을 넣으면 "그럴듯한 문서"가 아니라 "운영 가능한 문서"가 됩니다.

---

4) 운영 루프 설계: ingest / query / lint

LLM 위키는 결국 루프 게임입니다. 세 루프만 지키면 망가지지 않습니다.

A. Ingest 루프 (지식 입력)

새 소스를 넣을 때 LLM 지시 예시는 이렇게 구체적으로 써야 합니다.

예시 프롬프트: "raw/articles/stripe-retry-policy.md ingest해.

1. 8줄 핵심 요약 작성
2. wiki/concepts/payment-reliability.md 업데이트
3. wiki/playbooks/payment-failure-runbook.md에 대응 절차 반영
4. index.md, log.md 업데이트
5. 기존 결론과 충돌 2개 이상 있으면 표시"

핵심: 출력 파일 경로까지 명시해야 누적됩니다.

B. Query 루프 (지식 활용)

질의 시에도 규칙이 있습니다.

1. index에서 후보 문서 찾기
2. 관련 문서 읽기
3. 답변 작성
4. outputs/에 저장
5. 재사용 가치 있으면 wiki/decisions 또는 wiki/comparisons로 승격

이 5단계를 빼먹지 않으면, 질문이 자산으로 바뀝니다.

C. Lint 루프 (지식 유지보수)

주 1회 아래 항목을 점검합니다.

• 문서 간 충돌 주장
• 업데이트 누락 문서
• 고아 페이지
• 링크 깨짐
• 지표 불일치(비율, 비용, 기간)

lint를 빼면 4~8주 내에 위키 신뢰도가 떨어집니다. lint는 선택이 아니라 필수입니다.

---

5) 실무 예시: 결제 장애 대응 지식 위키 만들기

아래는 SaaS 팀에서 바로 적용 가능한 예시입니다.

초기 소스(raw)

• 최근 3개월 장애 회고 12건
• 결제 관련 PR 30개
• 고객 문의 로그 200건 요약
• 대시보드 알람 패턴 정리

위키 결과(wiki)

• concepts/payment-failure-types.md
• playbooks/payment-timeout-runbook.md
• playbooks/retry-strategy-guide.md
• comparisons/psp-error-code-map.md
• decisions/decision-2026-04-retry-policy.md

실제 체감 결과(보통 2~4주)

• 동일 이슈 재탐색 시간 감소
• 온콜 대응 편차 감소
• 신규 인력 온보딩 속도 상승

이건 모델이 똑똑해져서가 아니라, 맥락이 구조화돼서 검색/판단이 쉬워진 효과입니다.

---

6) "AI 티" 줄이고 알맹이 늘리는 문서 작성법

지식 문서가 추상적으로 흐르는 순간 실사용성이 떨어집니다. 아래 체크를 강제로 넣으면 품질이 올라갑니다.

문단 규칙

• 한 문단 = 한 주장
• 주장마다 근거 링크/수치/예시 중 1개 필수
• "보통", "일반적으로" 같은 말 나오면 재작성

섹션 규칙(기승전결)

• 기: 왜 지금 이 문제를 다루는지 상황 설명
• 승: 원인/배경/현상 구체화
• 전: 해결 방식과 선택지 비교
• 결: 지금 당장 할 액션 명시

결론 규칙

결론은 요약 문장이 아니라 실행 문장으로 끝냅니다. 예:

• "이번 주 금요일까지 raw 20개 ingest하고 lint 1회 실행"

---

7) 14일 실행 플랜 (그대로 따라하면 됨)

Day 1~2: 구조 세팅

• 폴더 생성
• RULES.md 작성
• index/log 템플릿 작성

Day 3~5: 초기 ingest

• 핵심 문서 20~30개 입력
• 개념 페이지 10개 생성

Day 6~7: 첫 query 주간

• 자주 묻는 질문 15개 실행
• outputs/ 저장
• 유의미한 결과 5개 wiki 승격

Day 8: 첫 lint

• 충돌/누락/고아 페이지 정리
• 규칙 위반 사례 보완

Day 9~11: 팀 적용

• 온콜/기획/개발 1개 워크플로우에 붙이기
• 실제 의사결정 문서 연결

Day 12~14: 운영 고정

• 주간 점검 루틴 문서화
• 담당자 지정
• 다음 주 ingest 우선순위 확정

2주가 지나면 "문서가 쌓인다"가 아니라 "문서가 일한다"는 상태를 볼 수 있습니다.

---

8) 결과값은 어떻게 측정하나 (정량 지표)

아래 지표를 매주 기록하면 효과를 확인할 수 있습니다.

1. 평균 탐색 시간 (질문→답변까지)
2. 재발 이슈 재조사 시간
3. 온보딩 시 독립 처리까지 걸린 시간
4. 고아 페이지 비율
5. 출처 없는 주장 비율
6. 최근 30일 미갱신 핵심 문서 수

권장 목표(첫 4주)

• 탐색 시간 20~30% 감소
• 고아 페이지 비율 50% 이상 감소
• 출처 없는 주장 비율 70% 이상 감소

정량 지표가 있어야 "좋아진 것 같다"에서 "실제로 좋아졌다"로 바뀝니다.

---

9) 어디에 활용하면 가장 효과가 큰가

LLM 위키는 모든 업무에 다 붙일 필요 없습니다. 반복 맥락이 많은 영역부터 시작해야 효과가 큽니다.

우선 추천 영역

1. 장애 대응/런북 운영
2. 기술 의사결정 기록(RFC/ADR)
3. 리서치 기반 제품 기획
4. CS 이슈 분류/해결 패턴
5. 세일즈 FAQ/도입 질문 대응

공통점은 "같은 질문이 자주 반복된다"는 점입니다. 반복이 많은 영역일수록 누적 효과가 큽니다.

---

10) 자주 하는 실수 7개

1. 처음부터 큰 인프라 구축
2. RULES.md 없이 감으로 운영
3. raw와 wiki 경계 붕괴
4. query 결과 파일링 누락
5. lint 미실행
6. 결론 문서(decisions) 미관리
7. 담당자 없이 모두의 책임으로 둠

이 7개만 피해도 성공 확률이 크게 올라갑니다.

---

최종 결론: LLM 위키는 "노트"가 아니라 "운영 시스템"이다

이 글의 핵심을 다시 한 줄로 정리하면 이렇습니다.

• LLM을 질문-답변 도구로만 쓰면 매번 다시 시작하고,
• LLM을 지식 운영자로 쓰면 매주 더 빨라진다.

그리고 그 차이는 기술 스택이 아니라 운영 루프에서 나옵니다.

지금 바로 실행할 최소 액션 3개:

1. raw / wiki / index.md / log.md / RULES.md 생성
2. 핵심 문서 10개 ingest
3. 이번 주 금요일 lint 1회 예약

이 3개를 실행하면, 다음 주부터 팀의 질문 방식과 문서 품질이 달라집니다.

원문을 다시 보고 싶다면 아래 링크에서 직접 확인하세요.

• https://x.com/karpathy/status/2039805659525644595
• https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

여기까지 왔다면 이제 아이디어 단계는 끝났습니다. 운영 단계로 넘어가면 됩니다.