LLM Knowledge Base 제대로 만들기: RAG에서 못 얻는 누적 지식 구조

LLM으로 문서를 다룰 때 대부분 여기서 멈춥니다.

1. 파일을 올린다
2. 질문한다
3. 답을 받는다

문제는 다음 질문을 던지는 순간 다시 원점으로 돌아간다는 점입니다. 질문이 복잡해질수록 모델은 문서를 다시 뒤지고, 다시 조합하고, 다시 요약합니다. 즉 매번 똑같은 인지비용을 반복해서 내고 있습니다.

이 글은 Andrej Karpathy가 최근 공유한 LLM Knowledge Bases 아이디어를 바탕으로, 개발자가 실제로 바로 쓸 수 있는 형태로 정리한 실전 가이드입니다. 핵심은 한 줄입니다.

답변을 잘 만드는 것보다, 답변이 점점 쉬워지는 지식 구조를 먼저 만든다.

---

1) 왜 기존 RAG 경험이 아쉬운가

RAG 자체는 유용합니다. 하지만 개인 연구/팀 학습 관점에서는 한계가 분명합니다.

• 질문할 때마다 재검색
• 문서 간 연결은 일회성
• 이전 탐색 결과가 구조로 축적되지 않음
• 좋은 답변이 채팅 로그에서 사라짐

결국 “한 번 잘 답하는 시스템”은 되는데, “시간이 갈수록 더 똑똑해지는 시스템”이 되기 어렵습니다.

Karpathy가 강조한 지점도 정확히 여기입니다. 최근 토큰 사용량의 큰 비중이 코드 조작에서 지식 조작(markdown + images)으로 이동했다는 말은, 실제로 병목이 구현 속도에서 지식 정리/운영으로 옮겨갔다는 뜻입니다.

---

2) LLM Knowledge Base의 기본 구조

최소 구조는 단순합니다.

kb/
  raw/
  wiki/
  index.md
  log.md

raw/

• 원문 저장소
• 기사, 논문, 레포, 데이터셋, 이미지
• 원칙: 불변(immutable)

wiki/

• LLM이 유지보수하는 markdown 지식층
• 개념 페이지, 엔티티 페이지, 비교 문서, 요약 문서
• 페이지 간 링크/백링크를 적극 활용

index.md

• 위키의 전체 카탈로그
• 어떤 문서를 먼저 읽어야 할지 빠르게 찾는 진입점

log.md

• 무엇을 언제 반영했는지 이력
• ingest/query/lint의 실행 기록

이 구조만 있어도 체감 차이가 큽니다. 문서가 많아질수록 “검색 정확도”보다 “구조화 정도”가 답변 품질을 좌우하기 때문입니다.

---

3) 운영 루프 3개만 지키면 무너지지 않는다

(A) Ingest

새 소스를 넣으면 LLM이 해야 할 일은 명확합니다.

1. 원문 읽기
2. 요약 페이지 생성/갱신
3. 관련 개념 페이지 업데이트
4. 링크/백링크 정리
5. index/log 반영

중요한 포인트: 문서 1개 ingest가 1개 파일 수정으로 끝나면 실패입니다. 좋은 ingest는 보통 여러 페이지를 건드립니다.

(B) Query

질의 시에는 다음 순서가 안정적입니다.

1. index에서 후보 문서 찾기
2. 관련 페이지 읽기
3. 답변 합성
4. 결과를 새 문서로 파일링

이 마지막 단계(파일링)가 핵심입니다. 좋은 분석 결과를 다시 위키에 넣지 않으면, 다음 질의에서 또 반복합니다.

(C) Lint

주기적으로 위키 점검을 돌립니다.

• 상충 주장 탐지
• 업데이트 누락 탐지
• 고아 페이지 탐지
• 반복 등장 개념인데 페이지가 없는 항목 탐지

사람이 하기 귀찮아서 위키가 죽습니다. LLM은 이 반복 유지보수를 꽤 잘합니다.

---

4) Obsidian을 ‘노트 앱’이 아니라 ‘지식 IDE’로 쓰기

Karpathy 접근에서 실무적으로 제일 좋은 부분이 이겁니다. Obsidian을 단순 노트 앱이 아니라 IDE frontend로 사용합니다.

• raw 데이터 확인
• wiki 탐색
• 링크 그래프 시각화
• 출력 결과(문서/슬라이드/차트) 확인

여기서 흔한 오해: “그럼 사람이 문서를 많이 손봐야 하나?” 정반대입니다.

위키는 LLM의 작업 영역으로 두고, 사람은 소스 선택과 질문 설계에 집중한다.

이 분리가 되면 운영이 오래 갑니다.

---

5) 실제로 품질이 올라가는 이유

이 방식이 그냥 ‘그럴듯한 정리법’이 아닌 이유는, 질문 난이도가 올라갈수록 차이가 커지기 때문입니다.

이유 1. 문서 간 연결이 이미 준비돼 있음

질문 때 즉석 조립이 아니라, 평소에 연결된 그래프를 사용합니다.

이유 2. 결과물이 사라지지 않음

좋은 답변은 위키 문서가 되어 남고, 다음 질문의 재료가 됩니다.

이유 3. 컨텍스트 윈도우 낭비가 줄어듦

원문 전체 재탐색보다, 정리된 페이지 중심 탐색이 효율적입니다.

이유 4. 유지보수가 자동화됨

링크 업데이트/모순 점검/인덱스 정리는 LLM이 잘하는 반복 작업입니다.

---

6) 바로 시작하는 7일 플랜

과하게 시작하지 말고, 아래만 하세요.

Day 1

• 폴더 구조 생성 (raw, wiki, index.md, log.md)
• ingest 규칙 문서 1장 작성

Day 2~3

• 핵심 문서 20~30개 ingest
• 각 문서에서 개념 페이지 최소 1개 생성

Day 4

• 복합 질문 3개 실행
• 답변을 문서로 파일링

Day 5

• 첫 lint 실행
• 상충/누락 항목 수정

Day 6

• 출력 포맷 추가 (Marp 슬라이드 또는 차트)

Day 7

• 한 주 회고 문서 작성
• 다음 주 ingest 우선순위 확정

이렇게만 해도 “질문 품질”과 “답변 일관성”이 눈에 띄게 바뀝니다.

---

7) 팀 적용 시 주의할 점

개인용보다 팀용이 어렵습니다. 아래 세 가지만 강제하면 실패 확률이 크게 줄어듭니다.

1. raw는 절대 수정하지 않기
2. 결과물 파일링을 습관이 아니라 규칙으로 만들기
3. lint를 ‘가끔’이 아니라 ‘주기 작업’으로 운영하기

팀 위키가 망하는 가장 큰 이유는 콘텐츠 품질이 아니라 유지보수 중단입니다. LLM KB의 가치는 바로 유지보수 비용을 낮춰주는 데 있습니다.

---

마무리

LLM을 “질문하면 답하는 도구”로만 쓰면, 매번 다시 시작하는 비용에서 벗어나기 어렵습니다.

LLM을 “지식을 컴파일하고 운영하는 엔진”으로 쓰면, 질문할수록 시스템이 강해집니다.

이 차이가 결국 생산성 차이로 이어집니다.

다음 글에서는 이 구조를 Software 3.0 관점에서 더 깊게 풀어보겠습니다. 코드를 덜 짜자는 얘기가 아니라, 지식을 더 잘 운영하는 팀이 결국 더 빠르게 만든다는 이야기입니다.