서론

많은 연구자와 엔지니어에게 논문이나 웹 기사를 LLM(Large Language Model)에 요약시켜 읽는 것은 점차 당연한 일이 되어가고 있다. 요약을 통해 전체상을 파악하고, 대화적으로 질문을 던지는 이러한 방식만으로도 학습 효율은 충분히 올라간다.

하지만 이러한 방식은 한 번의 세션으로 완결된다. 연구와 학습의 질을 결정하는 것은, 서로 다른 타이밍에 읽은 소스(Source) 간의 연결에서 발생하는 깨달음이다.

그렇다고 해서 이를 인간이 대신 수행하는 것도 어렵다. 기억력에는 한계가 있어, 반년 전에 읽은 논문의 세부 사항은 거의 기억하지 못한다. "논문 A와 논문 B가 동일한 문제를 다른 각도에서 다루고 있다", "3개월 전에 읽은 논문의 주장이 지금 읽고 있는 논문에서 부정되고 있다"와 같은 지식의 연결을 기억에 의존해 유지하는 것은 부하가 큰 작업이 된다.

2026년 4월, Andrej Karpathy 씨가 개인의 지식 베이스(LLM Wiki라고 부름)를 LLM으로 구축하는 패턴을 X에 공개했다.

이 트윗은 큰 반향을 일으켰고, Karpathy 씨는 이후 GitHub Gist를 통해 상세 내용을 공유했다. 나는 이 "LLM Wiki"를 1개월 동안 운용해 보았으며, 그 과정에서 보인 LLM의 진정한 가치는 요약이 아니라 연결하는 힘에 있다는 사실을 알게 되었다. 아래 그림은 운용 1개월 시점에 실제로 성장한 나의 wiki를 Obsidian의 그래프 뷰(Graph View)로 연 것이다. 각 노드(Node)는 wiki를 구성하는 페이지(서머리 페이지나 개념 페이지 등. 상세 내용은 다음 절에서 설명)에 대응하며, 에지는 페이지 간의 [[wikilink]]를 나타낸다.

본 기사에서는 이 LLM Wiki를 간단히 소개한 후, 나의 wiki에서 실제로 발견한 "연결에 의한 깨달음"을 2가지 사례로 발췌하여 소개한다. 이어서 LLM Wiki를 직접 시도해 보고 싶은 사람들을 위해 Karpathy 씨의 패턴을 기점으로 한 최소한의 도입 단계를 제시한다. 마지막으로 운용을 통해 드러난 한계, 즉 인간이 읽고 이해하는 것이 병목(Bottleneck)이 된다는 과제에 대해서도 언급한다.

Karpathy 씨의 LLM Wiki란 무엇인가

Karpathy 씨가 LLM Wiki를 제안한 배경에는 기존의 RAG(Retrieval-Augmented Generation) 계열 시스템 등 "LLM + 문서" 사용 방식에 대한 위화감이 있다. NotebookLM이나 ChatGPT의 파일 업로드 등 기존 방식에 공통적으로 나타나는 패턴은, 소스를 있는 그대로 유지하고 질문할 때마다 LLM이 관련 텍스트를 검색하여 답변을 구성하는 방식이다. Karpathy 씨는 이를 "rediscovering knowledge from scratch on every question"(질문할 때마다 지식을 처음부터 다시 발견하는 것)이라고 표현한다. 편리하지만, 이 방식으로는 지식이 축적되지 않는다. 5편의 논문을 통합해야 하는 질문을 던지면, LLM은 매번 지식의 파편을 다시 모아야 한다.

Karpathy 씨가 제안하는 LLM Wiki의 아키텍처는 단순한 3층 구조이다.

중심이 되는 것은 Wiki 층이다. Wiki 층은 markdown 파일 군으로 구성되며, 다음과 같은 페이지들이 나열된다.

• 서머리 페이지 (Summary Page): 1차 자료 1개당 1개씩 만들어지는 요약. 논문·웹 기사마다 1페이지 생성
• 개념 페이지 (Concept Page): 여러 소스를 횡단하여 정리한 테마·수법·인물 등의 정리
• query 페이지: wiki에 대한 질문과 그 답변을 파일링(Filing)한 것
• index.md: 위 모든 페이지를 일람하는 카탈로그 (특별 파일)
• log.md: 조작 이력을 시계열로 추가해 나가는 로그 (특별 파일)

운용은 3가지 기본 오퍼레이션(Operation)으로 돌아간다.

• Ingest: 새로운 소스를 투입하면, LLM이 서머리 페이지를 만들고, 관련 개념 페이지에 지견을 파급시키며, index와 log를 업데이트한다. 1개의 소스 투입으로 10~15페이지에 걸쳐 업데이트가 이루어지기도 한다.
• Query: wiki에 대해 질문한다. 가치 있는 답변은 query 페이지로서 wiki에 파일링하여 자산화한다.
• Lint: 정기적으로 헬스 체크(Health Check)를 실행한다. 모순·고립 페이지·지식 격차·"다음에 물어야 할 질문"을 LLM이 제안한다.

운영(Operation)과 인간·LLM·3층 구조의 관계를 도식화하면 다음과 같다.

이 세 가지 운영을 통해 인간이 능동적으로 수행하는 주요 액션은 소스를 raw/에 투입하여 인제스트(ingest)하는 것과, 위키(wiki)에 대해 질문하는 것 두 가지이다. 요약(Summary)이나 개념 페이지의 집필, 페이지 간 링크 유지, 인덱스(index)와 로그(log)의 업데이트, 모순 탐지 등 위키의 유지 관리 작업은 모두 LLM이 담당한다. Karpathy 씨는 Obsidian과 LLM 에이전트(Agent)를 나란히 열어두는 운영 방식을 권장하고 있다. LLM이 대화에 따라 위키를 편집하면, 인간은 그 결과를 Obsidian에서 열람한다.

이 구조에서 무엇이 바뀌는가. RAG(Retrieval-Augmented Generation)적인 접근 방식에서는 질문이 던져진 시점에 LLM이 여러 소스에서 관련 부분을 모아 통합한다. 반면, LLM Wiki에서는 LLM이 로우 소스(Raw sources)를 받아들여 위키를 생성하는 시점에, 여러 소스를 가로지르는 지식의 정리가 일어난다. 질문 시에는 그 시점까지 정리된 위키로부터 답변한다. Karpathy 씨의 표현을 빌리자면, 위키는 "persistent, compounding artifact"(지속적으로 축적되어 가는 성과물)이다.

그리고 Karpathy 씨는 이 패턴이 "왜 작동하는가"에 대해서도 깊이 있게 이야기하고 있는데, 이 점이 흥미롭다. 요점은 GitHub Gist의 「Why this works」 파트에 집약되어 있다.

요약하자면, 지식 베이스를 유지하는 데 있어 지루한 부분은 읽거나 생각하는 것이 아니라, 북키핑 (bookkeeping) (교차 참조(cross-reference) 업데이트, 요약의 최신화, 새로운 데이터가 기존의 주장과 모순될 때의 기록, 수십 페이지에 걸친 일관성 유지)이다. 인간이 위키를 포기하는 이유는 유지 부하가 가치의 증가보다 빠르게 늘어나기 때문이다. LLM은 지치지 않고, 교차 참조 업데이트를 잊지 않으며, 한 번의 패스(pass)로 15개의 파일을 다시 쓸 수 있다. 유지 비용이 거의 제로에 가깝게 떨어지기 때문에 위키는 계속해서 유지된다.

여기까지가 Karpathy 씨 주장의 요약이다. 실제로 1개월간 운용해 보며 내가 가장 강하게 느낀 점은, LLM Wiki의 진가는 요약집의 편리함이 아니라, 여러 소스를 가로질러 정리된 개념 페이지가 LLM의 손에 의해 자동으로 구축되어 가는 것, 즉 서두에서 언급한 「연결하는 힘」에 있다는 점이었다.

왜 「연결하는 힘」이 중요한가

위키층의 페이지 중 콘텐츠로서 기능하는 것은 크게 세 가지로 나뉜다.

• 서머리 페이지 (wiki/papers/, wiki/articles/): 1차 자료와의 1대1 대응
• 개념 페이지 (wiki/concepts/): 여러 소스에서 추출한 개념·기법·연구 영역을 통합한 「합성 성과물」
• Query 결과 (wiki/queries/): 질문에 대한 답변을 파일링(filing)한 것

이를 Raw sources로부터의 흐름으로 도식화하면, 서머리와 개념 페이지의 구성 방식이 질적으로 다르다는 것을 알 수 있다.

이 중 논문·기사 서머리만이라면 NotebookLM이나 ChatGPT의 파일 업로드로도 충분히 대체 가능하다. 따라서 개념 페이지의 존재가 핵심이다. 개념 페이지는 여러 소스를 가로질러 공통된 구조·분류·반례 등을 추출한다.

이를 인간이 직접 만들려고 하면 Karpathy 씨가 말한 북키핑(bookkeeping)의 부하 때문에 지속할 수 없게 된다. 새로운 기사를 읽을 때마다 기존의 개념 페이지로 돌아가 내용을 추가하고, 필요하다면 분류를 다시 만들고, 참조를 다시 연결해야 한다. 3개 정도까지는 지속할 수 있어도, 10개, 50개가 되면 유지 비용이 얻을 수 있는 가치를 상회하여 업데이트를 포기하게 된다. LLM은 이를 불평 없이 끊임없이 수행한다. 새로운 기사를 인제스트(ingest)할 때마다 관련 개념 페이지를 열어 다시 읽고, 새로운 지견이나 모순, 질문이 있다면 정리하여 작성해 준다.

덧붙여 개념 페이지의 구조는 자유롭다. LLM Wiki의 장점으로서, 인제스트(ingest) 스킬을 자신에게 맞게 고쳐 써서 개념 페이지의 템플릿을 자신이 다시 읽고 싶은 형태로 키워나갈 수 있다는 점이 있다. 나의 경우, 인제스트 스킬에 「횡단적 지견」과 「미결 과제(unresolved questions)」 섹션을 반드시 만들도록 작성해 두었다. 전자는 「여러 소스를 나란히 놓았을 때 비로소 보이는 관찰」을, 후자는 「다음에 조사해야 할 질문」을 불렛 포인트로 축적한다. 새로운 기사가 인제스트될 때마다 LLM은 이 섹션들을 업데이트한다. 이 불렛 포인트들이 시간이 흐르며 성장해 나가는 것이 LLM Wiki의 본체이다.

실례: LLM이 연결해 준 깨달음

추상적인 이야기만으로는 실감이 나지 않으므로, 실제로 자신의 wiki에서 얻은 두 가지 깨달음을 소개한다. 둘 다 「단일 논문이나 기사를 읽는 것만으로는 나올 수 없는」 종류의 지견이다.

사례 1: Automated Scientific Discovery의 평가 축과 편향(Bias)

최근 LLM 에이전트를 사용하여 문헌 리뷰부터 실험·논문 집필까지의 과학 연구 프로세스를 자동화하는 「Automated Scientific Discovery (과학적 발견의 자동화)」 논문이 급속도로 늘어나고 있으며, 본인은 다음과 같은 논문들을 10편 이상 순차적으로 ingest(수집/입력)해 왔다 (주요 논문 발췌).

• AI Scientist v1 (2024)
• AI Scientist v2 (2025)
• AI Scientist Nature 버전 (2026)
• AI co-scientist (2025)
• AI-Researcher / Scientist-Bench (2025)
• ScienceAgentBench (2025)
• Agent Laboratory (2025)
• Beel et al. AI Scientist v1 평가 논문 (2025)
• ResearchAgent (2025)

이것들을 순차적으로 ingest 해 나가는 과정에서, LLM은 wiki/concepts/automated-scientific-discovery.md라는 개념 페이지를 자동으로 생성하고, 새로운 논문을 투입할 때마다 내용을 추가 및 업데이트해 나갔다. 결과적으로 wiki는 (1) 각 논문에 흩어져 있던 평가 축을 4개의 카테고리로 정리하였고, (2) 3편의 독립된 논문에 등장하는 평가 편향(Bias) 관찰을 「LLM-as-Judge의 동작이 서로 다른 측면」이라는 하나의 패턴으로 통합해 주었다. 이것이 LLM Wiki의 「연결하는 힘」을 처음으로 실감한 사례이다.

(1) 평가 패러다임의 다축화라는 구조의 부상

10편 정도 투입한 후 개념 페이지를 다시 읽었을 때, 평가 패러다임이 지난 1~2년 사이 다축화되어 왔음을 볼 수 있었다. wiki의 「횡단적 지견 (Cross-cutting insights)」 섹션에 축적된 독립적인 관찰들을 내가 다시 나열하면 다음과 같이 정리할 수 있다.

wiki가 하고 있었던 것은 단순한 불렛 포인트의 축적이 아니라, 새로운 논문을 ingest 할 때마다 기존의 관찰을 바탕으로 새로운 관찰을 추가하는 것이었다. 각 논문에 흩어져 있던 평가 방식이, 아웃풋(논문)을 평가하는 3개 축 (실행 기반/인간/LLM)과 논문 평가에서 벗어난 현장 검증이라는 네 번째 축으로 정리된 것은 이러한 추가 작업이 쌓인 결과이다.

(2) 서로 다른 논문의 관찰이 하나의 패턴으로 통합됨

동일한 개념 페이지에는 다른 타입의 연결도 정리되어 있었다.

AI 생성 논문을 평가했을 때, 자동 리뷰 LLM의 점수는 동일한 논문에 대한 인간 리뷰어의 평균 점수보다 2.3포인트 높다 (Agent Lab). 반면, 자동 리뷰 LLM은 OpenReview에 투고된 인간 작성 논문의 9/10를 reject 한다 (Beel et al.). 게다가 평가에 사용하는 LLM을 GPT-4o / o1-mini / Claude-3.5 등으로 전환하면, 동일한 논문의 comparable rate가 13.64% → 81.82%로 약 68포인트 변동한다 (AI-Researcher). 이 세 가지는 독립적인 관찰처럼 보이지만, LLM-as-Judge의 평가는 「대상 논문을 누가 작성했는가 (AI/인간)」와 「어떤 LLM이 평가자인가」 모두에 강하게 의존하며, 중립적인 평가 축으로 다룰 수 없다는 동일한 패턴의 세 가지 관측면으로 볼 수 있다.

Agent Laboratory, Beel et al., AI-Researcher라는 3개의 논문을 서로 다른 타이밍에 ingest(수집)한 것만으로도, 「2.3포인트 차이」, 「9/10 reject」, 「68포인트 변동」이라는 독립된 숫자들이 LLM-as-Judge의 평가 편향(bias)이라는 하나의 패턴에 대한 세 가지 관측면으로서 통합되었다.

이러한 통합이 보이는 것은 내가 10개를 전부 기억하고 있기 때문이 아니라, LLM이 새로운 논문을 ingest할 때마다 과거의 페이지를 다시 읽어 정합성을 재조정하기 때문이다. 독서 노트를 Notion 등으로 만들더라도, 3개월 전의 노트로 돌아가 내용을 다시 쓰는 행위는 인간에게는 거의 발생하지 않는다.

사례 2: Sam Altman(OpenAI)과 Dario Amodei(Anthropic)의 사상 대비

계기는 「업계 주요 인물의 비전을 알고 싶다」 정도의 의도로, OpenAI CEO인 Sam Altman과 Anthropic CEO인 Dario Amodei의 다음 4개 에세이를 서로 다른 타이밍에 ingest한 것이었다.

• Sam Altman, "Reflections" (2025-01)
• Dario Amodei, "Machines of Loving Grace" (2024-10)
• Dario Amodei, "The Urgency of Interpretability" (2025-04)
• Dario Amodei, "The Adolescence of Technology" (2026-01)

이 4개를 순차적으로 ingest하는 동안, wiki는 OpenAI와 Anthropic CEO의 AGI에 대한 사상 차이를 대비로서 정리해 주었다. 이것이 「연결하는 힘」을 또 다른 형태로 실감한 사례이다.

구체적으로는, wiki/concepts/에는 다음과 같은 페이지 그룹이 LLM에 의해 작성되었다.

• 인물 페이지: sam-altman.md와 dario-amodei.md가 각각 독립적으로 작성됨
• 에세이에서 추출된 개념 페이지:
  • Amodei의 3개 에세이로부터: powerful-ai, compressed-21st-century, returns-to-intelligence, technological-adolescence, mechanistic-interpretability 총 5개
  • Altman의 Reflections로부터: agi, iterative-deployment 총 2개

여기까지는 에세이에서 추출된 개별 개념의 리스트일 뿐이다. 주목해야 할 점은, agi.md 안에 AGI(또는 고도 AI)를 어떻게 정의할 것인가를 둘러싼 두 사람의 접근 방식이 대비로서 정리되어 있었다는 것이다.

wiki는 이 대비를, Altman 씨의 정의는 "무엇을 넘어서는가"보다 "어디로 향하는가"라는 방향성의 어휘로 기능하고, Amodei 씨의 정의는 "무엇을 할 수 있는가"의 검증 가능한 기능 리스트로 기능한다고 한 문장으로 요약하고 있었다.

여기서 나에게 깨달음을 준 점은, 에세이를 ingest(입력/섭취)한 것만으로도 그 작성자의 사상 체계가 개별 개념으로 분해되고, 다른 인물과의 비교 축까지 자동으로 세워졌다는 것이다. 비교 분석을 의도해서 투입한 것이 아니다. "Altman 씨의 에세이를 읽었다"와 "Amodei 씨의 에세이를 읽었다"라는 별개의 투입이, wiki 내에서 스스로 대립 축으로 재구성되었다.

이는 앞서 언급한 사례 1(평가 축의 다각화)과는 다른 타입의 "연결하는 힘"이다. 사례 1은 다수의 동종 소스 통합이며, 사례 2는 소수의 서로 다른 관점의 대비 추출이다. LLM Wiki는 두 가지 모두를 워크플로우 상에서 동일한 조작으로 수행한다.

그 외 운용하며 알게 된 것

지식을 연결한 사례 외에, 운용 1개월 만에 보인 주변적인 소감을 2가지로 정리해 둔다.

1. Lint가 wiki의 정합성을 유지해 준다. 정기적으로 lint를 실행하면, LLM은 깨진 wikilink, 고립된 페이지, 비슷한 의미임에도 별도 페이지로 나뉜 개념(표기 불일치나 입도 차이로 중복된 카테고리) 등을 검출하여 수정 제안을 보내준다. 예를 들어 "agent-harness와 에이전트 하네스와 harness가 각각 별도 페이지로 존재한다", "reinforcement-learning 태그와 rl 태그가 혼재되어 있다"와 같은 드리프트(Drift)는 ingest를 반복하는 과정에서 반드시 발생한다. lint를 통해 정기적으로 정비해 두면, 이러한 무너짐이 누적되어 wiki가 황폐해지는 것을 방지할 수 있다.

2. Query 결과의 파일링을 통해 탐색의 성과가 축적된다. 나는 최근 시계열 기초 모델(TSFM)에 관한 서베이를 진행하며 관련 논문을 10편 이상 ingest했다. 이 상태에서 "TSFM으로 해결할 수 있는 태스크는 무엇인가? 미래 값 예측 이외에 적용할 수 있는가?"와 같은 거친 질문을 query로 던지면, LLM은 ingest된 논문들을 횡단적으로 읽고, 각각의 논문이 다루는 태스크를 카테고리화하여 정리한 뒤 wiki/queries/ 아래에 파일링해 주었다.

이는 동일한 질문을 ChatGPT나 Claude에 던지는 것과는 질적으로 다르다. 범용 LLM은 "세상의 TSFM 연구 일반"을 주제로 한 얕고 넓은 답변이 되기 쉽지만, LLM Wiki에 대한 query는 내가 읽을 가치가 있다고 판단하여 ingest한 논문 세트만을 근거로 답한다. 스코프(Scope)가 나의 큐레이션에 한정됨으로써, 답변은 범위가 좁은 만큼 깊어지고 나의 문제 의식에 밀착된 것이 된다. 나아가 답변이 wiki/queries/

남게 되므로, 다음 query나 ingest가 이 답변을 참조할 수 있다. 채팅 이력 속에서 사라졌던 합성 결과가 wiki에 자산으로서 축적되어 간다는 장점이 있다.

도입까지의 3가지 단계

본 기사를 읽고 "나도 LLM Wiki를 해보고 싶다"라고 생각한 분들을 위해, 최소한의 도입 단계를 정리해 둔다.

단, 본 기사는 자신의 스킬 세트를 완성된 형태로 배포하는 스타일을 취하지 않는다. 이는 Karpathy 씨 본인이 gist의 서두에서 다음과 같이 언급한 태도를 따르는 것이다.

This is an idea file, it is designed to be copy pasted to your own LLM Agent (e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.). Its goal is to communicate the high level idea, but your agent will build out the specifics in collaboration with you.

즉, gist 자체가 "아이디어를 전달하기 위한 파일"이며, 구체적인 디렉토리 구조·스킬 정의·페이지 포맷은 "자신의 LLM 에이전트와 협업하여 구현한다"는 것을 전제로 하고 있다. LLM Wiki는 도메인이나 연구 테마에 따라 최적의 형태가 달라지기 때문에, Karpathy 씨의 패턴을 기점으로 스스로 LLM과 함께 키워나가는 것이 결국 지름길이다.

Step 1: Karpathy 씨의 gist를 LLM에게 읽혀서 초안을 만들게 하기

Karpathy 씨의 GitHub Gist를 Claude Code와 같은 코딩 에이전트(Coding Agent)에게 읽힌 후, "이 패턴에 따라 나만의 wiki 셋업을 만들어줘"와 같이 지시한다. 출력물로서 최소한 다음을 얻을 수 있다.

• schema 파일 (Claude Code라면 CLAUDE.md, Codex라면 AGENTS.md 등): 디렉토리 구조·페이지 타입·명명 규칙·ingest/query/lint의 각 워크플로우(Workflow) 정의
• raw/, wiki/의 디렉토리 구조와 샘플 페이지

첫 schema 파일은 단순해도 괜찮다. Step 3에서 LLM과 상담하며 개선해 나간다는 전제를 두어도 무방하다.

참고: 미니멈 구성 샘플

참고로, 내가 실제로 운용하고 있는 리포지토리(Repository)의 구성(범용적인 부분만 추출한 간략 버전)을 아래에 나타낸다. Claude Code를 사용했을 경우의 예시이며, Codex 등을 사용할 경우에는 CLAUDE.md를 AGENTS.md로, .claude/skills/를 해당 디렉토리로 바꾸어 생각하기 바란다. 어디까지나 하나의 예시이며, Step 3 이후 각자의 도메인에 맞춰 다시 작성하는 것을 전제로 한다.

llm-wiki/
├── CLAUDE.md # schema: 디렉토리 규칙·워크플로우 정의
├── .claude/skills/
...

스킬의 내용도 실용적인 측면에서는 이 정도의 간소함으로 작동한다. 아래는 ingest-paper의 미니멈 버전이다 ([[wikilink]] 표기법은 Obsidian의 기능이며, 다른 markdown 에디터에서 운용할 경우에는 상대 경로 링크 등 다른 형식으로 교체한다).

---
name: ingest-paper
description: 학술 논문 PDF를 읽어 들여, 요약(Summary)을 wiki/papers/에 생성하고, 관련 concept 페이지·index.md·log.md를 파급 업데이트한다.
...

이것만으로도 논문 PDF를 던지면 wiki/papers/에 요약이 만들어지고, 관련 concept 페이지가 업데이트되며, index와 log에 기록되는 기본 루프가 작동한다.

Step 2: 수중에 있는 논문·기사를 우선 5편 정도 ingest 해보기

자신의 관심 영역에 있는 논문·기사를 5편 정도 투입한다. 요약과 concept 페이지가 어떻게 생성되는지, index.md와 log.md가 업데이트되는지 눈으로 직접 확인한다.

여기서 중요한 것은 "템플릿이 완벽한가"가 아니라 "생성된 concept 페이지가 나에게 다시 읽고 싶은 형태인가"를 보는 것이다.

Step 3: 템플릿을 자신의 도메인에 맞춰 키우기 (지속적으로 LLM에게 시키기)

5권 정도 ingest(데이터 주입)해 보면, "나에게 이 섹션은 필요 없다"라거나 "반대로 이 섹션이 부족하다"라는 감각이 생겨난다. 개념 페이지의 어떤 섹션을 반드시 만들 것인가와 같은 템플릿 부분은 ingest 스킬(ingest skill)에 기술되어 있으므로, 여기에 반영해 나간다. 반면, 명명 규칙(Naming Convention)·디렉토리 구조·페이지 타입의 분류와 같은 Wiki 전체의 "문법"은 schema 파일(Claude Code라면 CLAUDE.md, Codex라면 AGENTS.md 등 에이전트마다 다름)에서 다룬다.

예를 들어 나는 연구자이기 때문에, 각 concept 페이지의 말미에 "미해결 과제" 섹션을 반드시 만들도록 ingest 스킬에 추가해 두었다. 이것이 있으면 페이지를 한 번 읽을 때마다 내 연구의 다음 테마 후보를 얻을 수 있다. 엔지니어라면 "구현 패턴", "주의할 점(ハマりどころ)"과 같은 섹션이 가치를 가질지도 모른다.

이러한 조정 또한 LLM에게 시키는 것이 요령이다. "ingest 스킬을 읽고, 현재 템플릿에 부족한 요소를 제안해 줘"라고 물으면 현재 템플릿에 대한 개선안이 돌아온다. "concept 페이지에 미해결 과제 섹션을 필수 사항으로 만들고 싶어"라고 부탁하면, ingest 스킬의 정의와 기존 concept 페이지를 모두 업데이트해 준다.

그리고 이 조정은 한 번으로 끝나지 않는다. 몇 주에서 몇 달간 운용하다 보면 더욱 새로운 깨달음이 나온다. 이것들 역시 마찬가지로 LLM에게 시킨다. Lint를 정기적으로 실행하면, LLM 스스로가 "현행 규칙과 실체의 괴리"를 검출하여 제안해 준다. schema 파일도 스킬 군도 정적인 설정 파일이 아니라, 운용을 통해 자신의 사용법을 학습해 나가는 동적인 결과물로서 키워 나간다.

이 루프가 돌아가기 시작하면, 본 기사에서 쓴 것과 같은 "연결하는 힘"의 사례가 자신의 도메인에서 일어나기 시작한다. 일반론으로서 LLM Wiki가 편리하다는 것과, 자신의 연구나 업무에서 실제로 깨달음이 연쇄하기 시작하는 것 사이에는 Step 3의 이 조정 프로세스가 필요하다.

과제: 연결된 너머에 "이해"의 병목 현상이 있다

지금까지 "LLM의 연결하는 힘이 대단하다"라는 이야기를 써왔지만, 운용하다 보면 무시할 수 없는 한계도 보인다.

인간이 읽고 이해하는 것이 병목(Bottleneck)이 된다.

LLM이 개념 페이지를 깔끔하게 정리해 주더라도, 그것을 인간이 읽고 자신의 이해로서 소화하지 않으면 진정한 의미의 "자신의 지식"이 되지 않는다. 연구 아이디어를 낼 때, 논문을 쓸 때, 토론에서 설득할 때, 최종적으로 의지할 수 있는 것은 자신의 머릿속에 있는 이해이다.

이 과제에 대한 첫 번째 대책으로서, 나는 일부러 ingest할 소스를 내 손으로 직접 선택하고 있다. 소스 선정(Source Selection)을 자동화하거나 LLM에게 맡기는 것 자체는 간단하며, 예를 들어 arXiv의 특정 카테고리 신착 논문을 매일 자동으로 ingest할 수도 있다. 하지만 그렇게 하면 내가 인지하지 못하는 곳에서 개념 페이지가 멋대로 자라나고, 막상 다시 읽으려 할 때 "언제 이런 페이지가 생겼지?" 하는 상태가 된다. 이해의 병목 현상이 더욱 심각해지는 것이다.

그래서 내가 "읽고 싶다・재밌겠다"라고 판단한 논문이나 웹 기사만을 의도적으로 투입한다. 결과적으로 하루에 10건을 ingest하는 날도 있고 0건인 날도 있지만, 그래도 상관없다. 양보다 질이라고 생각한다. 우선 Wiki를 넘치게 하지 않는 것, 이것이 첫 번째 대책이다.