LLM으로 문서를 다룰 때 대부분 여기서 멈춥니다.
문제는 다음 질문을 던지는 순간 다시 원점으로 돌아간다는 점입니다. 질문이 복잡해질수록 모델은 문서를 다시 뒤지고, 다시 조합하고, 다시 요약합니다. 즉 매번 똑같은 인지비용을 반복해서 내고 있습니다.
이 글은 Andrej Karpathy가 최근 공유한 LLM Knowledge Bases 아이디어를 바탕으로,
개발자가 실제로 바로 쓸 수 있는 형태로 정리한 실전 가이드입니다.
핵심은 한 줄입니다.
답변을 잘 만드는 것보다, 답변이 점점 쉬워지는 지식 구조를 먼저 만든다.
RAG 자체는 유용합니다. 하지만 개인 연구/팀 학습 관점에서는 한계가 분명합니다.
결국 “한 번 잘 답하는 시스템”은 되는데, “시간이 갈수록 더 똑똑해지는 시스템”이 되기 어렵습니다.
Karpathy가 강조한 지점도 정확히 여기입니다. 최근 토큰 사용량의 큰 비중이 코드 조작에서 지식 조작(markdown + images)으로 이동했다는 말은, 실제로 병목이 구현 속도에서 지식 정리/운영으로 옮겨갔다는 뜻입니다.
최소 구조는 단순합니다.
kb/
raw/
wiki/
index.md
log.md
이 구조만 있어도 체감 차이가 큽니다. 문서가 많아질수록 “검색 정확도”보다 “구조화 정도”가 답변 품질을 좌우하기 때문입니다.
새 소스를 넣으면 LLM이 해야 할 일은 명확합니다.
중요한 포인트: 문서 1개 ingest가 1개 파일 수정으로 끝나면 실패입니다. 좋은 ingest는 보통 여러 페이지를 건드립니다.
질의 시에는 다음 순서가 안정적입니다.
이 마지막 단계(파일링)가 핵심입니다. 좋은 분석 결과를 다시 위키에 넣지 않으면, 다음 질의에서 또 반복합니다.
주기적으로 위키 점검을 돌립니다.
사람이 하기 귀찮아서 위키가 죽습니다. LLM은 이 반복 유지보수를 꽤 잘합니다.
Karpathy 접근에서 실무적으로 제일 좋은 부분이 이겁니다. Obsidian을 단순 노트 앱이 아니라 IDE frontend로 사용합니다.
여기서 흔한 오해: “그럼 사람이 문서를 많이 손봐야 하나?” 정반대입니다.
위키는 LLM의 작업 영역으로 두고, 사람은 소스 선택과 질문 설계에 집중한다.
이 분리가 되면 운영이 오래 갑니다.
이 방식이 그냥 ‘그럴듯한 정리법’이 아닌 이유는, 질문 난이도가 올라갈수록 차이가 커지기 때문입니다.
질문 때 즉석 조립이 아니라, 평소에 연결된 그래프를 사용합니다.
좋은 답변은 위키 문서가 되어 남고, 다음 질문의 재료가 됩니다.
원문 전체 재탐색보다, 정리된 페이지 중심 탐색이 효율적입니다.
링크 업데이트/모순 점검/인덱스 정리는 LLM이 잘하는 반복 작업입니다.
과하게 시작하지 말고, 아래만 하세요.
raw, wiki, index.md, log.md)이렇게만 해도 “질문 품질”과 “답변 일관성”이 눈에 띄게 바뀝니다.
개인용보다 팀용이 어렵습니다. 아래 세 가지만 강제하면 실패 확률이 크게 줄어듭니다.
팀 위키가 망하는 가장 큰 이유는 콘텐츠 품질이 아니라 유지보수 중단입니다. LLM KB의 가치는 바로 유지보수 비용을 낮춰주는 데 있습니다.
LLM을 “질문하면 답하는 도구”로만 쓰면, 매번 다시 시작하는 비용에서 벗어나기 어렵습니다.
LLM을 “지식을 컴파일하고 운영하는 엔진”으로 쓰면, 질문할수록 시스템이 강해집니다.
이 차이가 결국 생산성 차이로 이어집니다.
다음 글에서는 이 구조를 Software 3.0 관점에서 더 깊게 풀어보겠습니다. 코드를 덜 짜자는 얘기가 아니라, 지식을 더 잘 운영하는 팀이 결국 더 빠르게 만든다는 이야기입니다.