Karpathy의 LLM-Wiki를 보며 든 생각: RAG보다 지식을 축적하는 위키가 더 중요할 수 있다

Karpathy가 공개한 LLM-Wiki 아이디어를 보고 제일 먼저 든 생각은, “이건 RAG를 대체한다”가 아니라 RAG로는 잘 안 쌓이던 지식을 LLM이 대신 관리해주는 구조에 가깝다는 점이었다.

요즘 문서와 LLM을 연결하는 이야기를 하면 거의 자동으로 RAG가 따라온다. 파일을 넣고, 임베딩하고, 검색하고, 관련 청크를 꺼내서 답을 만든다. 이 방식은 분명 유용하다. 그런데 실제로 오래 써보면 한계도 꽤 분명하다. 매번 다시 찾고, 매번 다시 읽고, 매번 다시 합쳐야 한다. 질문 하나에는 잘 답하지만, 시간이 지날수록 더 좋아지는 지식 베이스가 남는 건 아니다.

LLM-Wiki는 바로 그 지점을 건드린다. 원문 컬렉션은 그대로 두고, 그 위에 LLM이 관리하는 영속적 위키 레이어를 둔다. 새 소스가 들어오면 모델이 읽고, 요약하고, 관련 페이지를 갱신하고, 교차 참조를 붙이고, 모순을 표시하고, 인덱스를 업데이트한다. 쿼리할 때마다 원문에서 다시 지식을 캐내는 대신, 이미 한 번 정리되고 누적된 지식 아티팩트를 바탕으로 답하는 구조다.

왜 이 아이디어가 꽤 중요하게 느껴지냐

대부분의 문서 기반 LLM 워크플로우는 결국 “질문 시점” 중심이다.

• 질문이 들어온다
• 관련 문서를 다시 찾는다
• 관련 청크를 다시 읽는다
• 필요한 내용을 다시 합친다
• 답을 만든다

이건 즉시성은 좋지만, 누적성은 약하다. 같은 주제를 다음 주에 다시 물어도 또 비슷한 과정을 반복해야 한다. 문서가 많아질수록 검색과 조합은 점점 더 복잡해지고, 구조화는 여전히 사용자의 몫으로 남는다.

반면 LLM-Wiki는 “지식이 쌓이는 중간 레이어”를 만든다.

• raw sources는 원본 그대로 보존
• wiki는 LLM이 생성/유지하는 정리 레이어
• schema는 LLM이 어떻게 일할지 알려주는 운영 규칙

이렇게 나누면 모델은 더 이상 임시 답변기만이 아니다. 지식을 정리하고 유지하는 편집자 겸 북키퍼 역할을 맡게 된다.

핵심은 검색보다 북키핑 자동화다

이 아이디어에서 제일 중요한 건 사실 검색이 아니다. 진짜 중요한 건 북키핑 비용을 거의 0에 가깝게 줄인다는 점이다.

사람들이 위키를 오래 유지하지 못하는 이유는 대개 읽고 생각하는 일이 힘들어서가 아니다. 오히려 아래 같은 일들이 귀찮고 비싸다.

• 관련 페이지 링크 추가
• 새 정보 들어오면 기존 요약 수정
• 예전 주장과 충돌하는 부분 표시
• 인덱스 갱신
• 중요한 개념인데 문서가 없는 경우 찾기
• 고아 페이지 정리
• 구조를 계속 일관되게 유지

이런 건 한두 번은 할 수 있어도, 시간이 지나면 거의 반드시 흐트러진다. 위키가 망가지는 이유는 보통 정보가 부족해서가 아니라 유지 관리 비용이 너무 높아서다.

Karpathy가 집은 포인트는 정확히 여기다. LLM은 지루함을 느끼지 않고, 링크 추가를 귀찮아하지 않고, 한 번에 10개 넘는 파일을 업데이트하는 걸 이상하게 여기지 않는다. 즉 사람에게 비싼 북키핑이 모델에게는 상대적으로 싸다.

RAG와 위키는 경쟁 관계라기보다 역할이 다르다

여기서 RAG를 무시할 필요는 없다고 본다. 여전히 RAG는 필요한 순간이 많다.

예를 들면:

• 아주 큰 원문 컬렉션을 빠르게 훑고 싶을 때
• 최신 원문 근거를 바로 끌어오고 싶을 때
• 아직 정리되지 않은 자료를 임시로 조회할 때
• ad hoc 질문에 빠르게 대응할 때

하지만 LLM-Wiki가 주는 건 다른 종류의 가치다.

• 자주 보는 주제를 구조화한다
• 지식이 시간이 갈수록 더 좋아진다
• 질문 결과도 다시 자산으로 남길 수 있다
• 원문과 정리 레이어를 분리해 관리할 수 있다
• 탐색 과정 자체가 위키를 더 풍부하게 만든다

즉, RAG가 “그때그때 꺼내 읽는 구조”라면, LLM-Wiki는 읽은 것을 계속 남기고 연결하는 구조에 가깝다.

Obsidian을 IDE로 보는 비유가 꽤 좋다

Karpathy가 말한 비유 중 인상적인 건 이거였다.

• Obsidian은 IDE
• LLM은 프로그래머
• 위키는 코드베이스

이 비유가 좋은 이유는, 위키를 그냥 노트 모음으로 보지 않게 만들기 때문이다. 코드베이스처럼 생각하면 금방 감이 온다.

• raw sources는 외부 입력
• wiki는 점진적으로 리팩터링되는 결과물
• schema는 작업 규칙과 컨벤션
• index/log는 탐색과 변경 기록
• lint는 건강 점검

이렇게 보면 LLM-Wiki는 단순 메모 시스템이 아니라, 지식 코드베이스를 운영하는 방식에 더 가깝다.

이 구조가 특히 잘 맞는 영역

내가 보기엔 이 방식은 아래 같은 주제에서 특히 강하다.

1. 시간이 걸려 축적되는 연구

• 논문 읽기
• 업계 동향 정리
• 제품/경쟁사 분석
• 기술 주제별 개념 맵 구축

2. 자기 자신에 대한 장기 기록

• 건강 기록
• 목표 추적
• 저널 정리
• 루틴 변화와 패턴 관찰

3. 팀 내부 지식 정리

• 회의 기록
• Slack 스레드
• 프로젝트 결정 로그
• 고객 피드백 축적

4. 독서나 강의 노트

• 챕터별 요약
• 등장 개념 연결
• 인물/사건/주제별 페이지 분리
• 시간이 지나며 관점이 바뀌는 지점 기록

이런 영역의 공통점은 단순 조회보다 축적과 정리의 복리 효과가 크다는 점이다.

결국 핵심은 “질문”보다 “아티팩트”다

지금까지 많은 LLM 도구는 질문에 잘 답하는 데 집중해 왔다. 하지만 오래 남는 건 답변 그 자체가 아니라, 다음 질문을 더 쉽게 만드는 구조화된 아티팩트다.

이 점에서 LLM-Wiki의 방향은 꽤 설득력이 있다. 질문 결과도 다시 위키에 저장할 수 있고, 새 소스가 들어오면 기존 이해를 수정할 수 있고, 시간이 갈수록 위키 자체가 더 강해진다. 이건 단발성 채팅 로그와는 전혀 다른 성격이다.

결국 유용한 시스템은 그 순간 똑똑하게 답하는 시스템보다, 시간이 지나며 더 잘 정리되는 시스템일 가능성이 높다.

그래도 주의할 점은 있다

물론 이 방식도 아무 조건 없이 잘 돌아가진 않는다.

• schema가 약하면 위키가 금방 흐트러질 수 있음
• LLM이 자신있게 잘못된 합성을 할 위험이 있음
• 원문과 위키의 경계가 흐려지면 신뢰성이 떨어짐
• 모든 주제에 과도하게 페이지를 만들면 오히려 잡음이 늘 수 있음
• 초반 구조 설계가 나쁘면 유지 비용이 다시 커질 수 있음

그래서 raw sources를 immutable하게 두고, wiki는 파생 레이어로 유지하고, schema를 함께 다듬는 구조가 중요해 보인다. 즉 이건 단순히 “LLM에게 위키 만들어”가 아니라, 지식 운영 구조를 설계하는 문제에 가깝다.

OpenClaw 같은 흐름과도 자연스럽게 닿아 있다

이 아이디어를 보면서 자연스럽게 떠오른 건, 결국 이것도 에이전트 하네스 문제라는 점이었다.

좋은 결과를 만드는 건 모델 하나가 아니라:

• 어떤 레이어를 분리하는지
• 어떤 파일을 source of truth로 두는지
• 어떤 규칙으로 갱신하는지
• 어떤 작업을 ingest/query/lint로 나누는지
• 어떤 결과를 다시 자산으로 저장하는지

이런 구조다.

그래서 LLM-Wiki가 흥미로운 이유도 단순히 “LLM으로 위키를 쓴다”가 아니다. 오히려 지식을 계속 축적할 수 있게 만드는 작업 구조를 제안한다는 점이 더 중요하다.

마무리

Karpathy의 LLM-Wiki를 보면서 든 생각은 단순하다. 문서를 매번 다시 찾는 RAG도 여전히 유용하지만, 더 오래 남는 가치는 LLM이 지식을 점진적으로 정리하고 유지하는 영속적 위키 쪽에 있을 수 있다.

정리하면 이렇다.

• RAG는 질문 시점에 강하고, LLM-Wiki는 축적 시점에 강하다
• 핵심은 검색 자체보다 북키핑 비용을 줄이는 데 있다
• 위키는 단순 노트가 아니라 지식 아티팩트이자 코드베이스처럼 운영될 수 있다
• 좋은 답변은 사라지지 않고 다시 위키에 저장돼야 한다
• 결국 중요한 건 답변 품질만이 아니라, 시간이 갈수록 더 좋아지는 구조를 만드는 일이다

이 관점이 맞다면, 앞으로의 지식 도구는 “무엇을 잘 찾아오나”보다 무엇을 계속 남기고 어떻게 더 잘 연결하나 쪽으로 발전할 가능성이 더 커 보인다.