AI에게 자료를 건네고 질문한다. 그 경험은 지난 1년 동안 상당히 편리해졌다. 하지만 반년 정도 사용한 개인용 AI가 왠지 모르게 「첫날과 같다」고 느껴질 때가 있다. 이전에 읽게 했을 터인 논문도, 함께 정리했던 논점도, 다음에 물어보면 다시 처음부터 찾아낸다. 무언가가 쌓여가는 손맛이 없다.

이 감각의 근원은 아마도 RAG에 있다. RAG는 「찾는 것」은 잘 해결했다. 하지만 「쌓아 올리는 것」은 손대지 못한 채 남아 있다.

RAG가 해결한 것, 남겨둔 것

전형적인 RAG는 자료를 잘게 나누고, 임베딩 (Embedding)을 만들고, 질문에 가까운 단편을 추출하여 그 자리에서 답을 구성한다. 질문마다 필요한 근거를 가져올 수 있으므로 컨텍스트 윈도우 (Context Window)에 전부를 채워 넣지 않아도 되고, 출처도 붙이기 쉽다. 잘 만들어진 방식이다.

걸리는 점은 처리 단위가 「이번 질문」으로 닫혀 있다는 점이다. 어떤 질문에서 다섯 개의 자료를 횡단하여 관계를 찾아내더라도, 그 발견은 어디에도 남지 않는다. 다음에 비슷한 것을 질문받으면 다시 단편을 모으는 것부터 다시 시작해야 한다. 검색할 수 있게는 되어 있지만, 지식 그 자체는 자라나지 않는다. 이것이 「반년을 써도 첫날과 같다」는 정체라고 생각한다.

컨텍스트 윈도우는 책상과 같은 것

또 하나, 컨텍스트 윈도우를 기억과 혼동하기 쉽다는 함정이 있다.

AWS의 해설은 컨텍스트 윈도우를 책상에 비유하고 있다. 질문, 자료, 대화 이력, 시스템 지시. 지금 이 순간 생각하는 데 필요한 것은 전부 이 책상 위에 올라간다. 책상이 넓으면 올라가는 양은 늘어난다. 다만, 올라와 있는 것들을 처음부터 끝까지 같은 강도로 읽을 수 있는 것은 아니다.

긴 문서나 긴 대화에서는 중간 정보의 취급이 약해진다. lost in the middle이라고 불리는 현상이다. 대화가 이어질수록 초반에 정한 제약은 책상 깊숙이 밀려나고, 마지막 한마디만이 크게 보인다. 까다로운 점은 모델이 그것을 거절하지 않고, 방금 전과 똑같이 자신감 있는 말투로 대답한다는 것이다.

컨텍스트 윈도우를 넓히거나, 분할하거나, 요약하거나, 제약을 다시 설정하거나, RAG를 추가하거나, 기억층을 직접 갖는 것. 모두 효과가 있다. 그럼에도 책상이 책상이라는 사실은 변하지 않는다. 작업대의 넓이와 쌓아 올린 지식 베이스 (Knowledge Base)는 원래 별개의 것이다.

LLM Wiki라는 반전

Karpathy의 LLM Wiki는 이 전제를 뒤집는다. 자료를 검색용으로 두는 것이 아니라, LLM에게 Wiki 그 자체를 유지보수하게 한다는 발상이다.

설계 문서의 골격은 놀라울 정도로 담백했다.

• Raw sources: 원문 자료. 신뢰할 수 있는 원본이며, LLM은 읽지만 다시 쓰지는 않는다.
• Wiki: LLM이 쓰는 Markdown 군. 요약, 인물이나 조직 페이지, 개념 페이지, 비교 및 통합, 상호 링크가 포함된다.
• Schema:
  CLAUDE.md나 AGENTS.md에 해당하는 규약 파일. 가져오는 방법, 대답하는 방법, 유지보수하는 방법을 LLM에게 전달한다.

조작도 세 가지만이다. Ingest를 통해 새로운 자료를 한 번 처리하여 요약 페이지나 색인, 로그, 관련 페이지까지 업데이트한다. Karpathy는 하나의 자료가 10~15 페이지에 달할 수 있다고 적고 있다. Query를 통해 생자료를 매번 다시 연결하지 않고, 이미 정리된 Wiki를 읽고 인용과 함께 답한다. Lint를 통해 모순이나 오래된 주장, 고립된 페이지, 부족한 개념, 다시 조사해야 할 빈틈을 점검한다.

간과하기 쉬운 점은 이것이 앱이 아니라, 먼저 한 장의 설계 문서로서 배포되었다는 것이다. 의존 관계를 품은 프로덕트가 아니라, 에이전트에게 통째로 넘길 수 있는 문장으로서 시작되었다. Karpathy가 다른 인터뷰에서 말했던 Software 3.0, 즉 무엇을 에이전트에게 복사해서 넘길 것인가가 설계가 된다는 감각과 그대로 겹친다.

컴파일이라는 발상

RAG와 LLM Wiki의 차이는 검색 방식의 우열이 아니다. 통합한 결과를 어디에 두느냐의 차이다.

RAG에서는 통합이 질문할 때마다 일시적으로 일어나며, 답과 함께 흘러가 사라진다. LLM Wiki에서는 그 통합이 파일로서 남는다. 모순은 페이지에 적히고, 관계는 링크가 되며, 색인은 업데이트된다. 질문에서 태어난 비교표나 분석도 쓸모가 있다면 Wiki로 되돌릴 수 있다.

이 「되돌리는 것」이 효과적이다. 대화창 끝에서 사라졌어야 할 발견이 다음 질문에서 읽히는 재료가 된다. 읽힐수록 Wiki는 두꺼워지고, 물어볼수록 다음 질문이 편해진다. RAG와의 차이가 명확히 드러나는 지점은 여기다.

인간은 편집장이 된다

Karpathy는 Sequoia와의 인터뷰에서 AI 시대 인간의 가치가 구현의 세부 사항에서 사양(Specification)·판단·검증으로 이동하고 있다고 반복해서 말하고 있습니다. LLM Wiki에서도 같은 일이 일어납니다.

인간이 하는 일은 무엇을 읽힐지 선택하고, 어떤 논점을 중요하게 볼지 결정하며, LLM의 요약을 살펴보고 위화감이 있다면 수정하는 것입니다. 그리고 좋은 질문을 던지는 것입니다. 요약, 상호 링크(Interlinking), 색인(Index), 로그(Log), 차분 업데이트(Differential update)와 같이 Wiki 운영에서 가장 번거롭고 지속하기 어려운 작업들은 LLM이 맡게 됩니다. 인간이 글을 쓰지 않게 되는 것이 아니라, 인간이 편집장이 된다고 말하는 것이 더 적절합니다.

RAG 다음에 필요한 것

RAG가 필요 없어진다는 이야기가 아닙니다. LLM Wiki 안에서도 검색은 필요합니다. 규모가 커지면 Markdown 색인만으로는 부족하며, BM25나 벡터 검색(Vector search), 그래프 검색(Graph search)이 필요해집니다.

그럼에도 불구하고, RAG만으로는 "반년을 써도 첫날과 같다"는 현상이 좀처럼 사라지지 않습니다. 검색은 입구일 뿐이며, 축적은 그 너머에 있는 별도의 계층이기 때문입니다. 이 시리즈에서는 그 축적 계층을 네 편의 글을 통해 추적해 나갈 것입니다. 본 기사는 문제 제기까지입니다. 다음에는 Karpathy의 설계 문서를 데스크톱 앱으로 구현한 nashsu/llm_wiki를 살펴보겠습니다.

개인적인 견해

LLM Wiki에서 가장 감명 깊었던 점은 새로운 기술 그 자체보다, 지식 관리의 책임 소재를 깔끔하게 구분해 놓았다는 점입니다.

원문은 인간이 선택하며, 마음대로 다시 쓰지 않습니다. Wiki는 LLM에게 맡겨 유지보수하게 합니다. 규약은 양측이 함께 키워나갑니다. 이러한 구분만으로도 "AI에게 전부 떠넘기기"도 "인간이 모든 것을 떠안기"도 아닌, 지속 가능한 운영이 가능해집니다.

RAG는 질문에 답하는 검색 장치로서는 강력합니다. 하지만 수년간 함께할 AI에게는, 가져온 결과를 그 자리에서 일회용으로 쓰고 버리는 것이 아니라, 발견한 내용을 구조로서 남기는 메커니즘이 필요합니다. 이를 갖추고 있느냐가 개인용 AI와 조직에서 사용하는 AI의 다음 분기점이 될 것입니다.

참고

• Karpathy의 설계 문서: LLM Wiki
• Sequoia Training Data (YouTube): Andrej Karpathy: From Vibe Coding to Agentic Engineering
• AWS / Dev.to: Why does AI forget what you said (and how to fix it)
• Dev.to: Toward a Standard Model for Agent Memory

이 기사는 「AI Watch」에도 게재될 예정입니다. 최첨단 AI를 기술적 내용까지 깊이 있게 분석하여 전달합니다.

Discussion