흥미로워 보였지만 내가 원하는 기능은 없다

LLM Wiki 앱이 사용하는 프로젝트의 루트에 생성된 schema.md, purpose.md 파일들에 추가 설정 없이, AspectScope를 사용하여 분석한 데이터를 Ingest 시킨 결과를 봤더니, 고개가 절래절래 저어졌다.

검증 또는 확인이 필요하다는 문서가 하나의 분석 문서당 적게는 3개, 많게는 8개까지 만들어졌는데 해당 문서를 Research 시켰다해도 그 내용들이 관련 Wiki Page에 적용되진 않았다. 게다가 그 많은 queries/*.md 문서들은 자동으로 처리되지 않는다. 식별자도 멋대로 소문자로 만들어버리고 의미 단위를 희안하게 끊어서 조각내는 게… 음,, 아니다 싶었다. 100개가 좀 넘는 문서를 Ingest 시킨 후에, 미련없이 다 밀어버렸다. 그렇게 첫번째 시도는 하루 만에 끝나고,

두번째 셋업에서는 AGENT의 도움을 얻어 schema.md, purpose.md를 나름 내 목적에 맞게 촘촘하게 설정한 상태에서 다시 사용해 보았다. 78개의 분석 문서들을 Ingest 시켰다. 그리고 Ingest 후에는 opencode를 사용하여 결과물들을 기존의 Wiki에 병합시키는 과정을 자동으로 처리하게 하였다. 이번에는 아무래도 두개의 설정 문서 덕분에 상당히 체계적이고 원하는 방식의 식별자 사용과 의미단위로 나눌 수 있었으나, 제길 …. 다시 밀어버렸다.

이유는 “Ingest 되고 난 후의 데이터를 기존 Wiki 페이지에 병합하지 못하기 때문” 이다. 다시 말해서, 주어진 데이터를 LLM이 조각 내어 Refine(?)시켰다 하더라도, 조각난 그 정보들이 서로를 알지 못할 뿐더러 섞이지도 않는다는 사실을 LLM Wiki 소스코드를 확인하고 나서야 흥미가 완전히 사라져 버린 것이다.

물론 그 조각들을 다시 섞이게 하기위해 Sidecar AGENT를 두고 지속적으로 업데이트 하게 하면 된다. 그러나 내가 원하는 건, AspectScope로 분석된 데이터를 Ingest만 할게 아니라 기존 Wiki Page에 자동으로 병합하면서 관련 주제나 정보를 쌓아가길 원한 것이다. 소스코드 변경없이 설정만으로 그 목적을 달성해보려 했으나, 결국 LLM Wiki 소스 자체를 수정하여 개인적으로 빌드해서 사용할 수 밖에 없다고 결론냈다. LLM Wiki의 데이터를 MCP를 통해 AspectScope MCP와 함께 분석 AGENT에서 활용할 계획이었는데, 잠시 멈추고 방법을 다시 찾아볼 수 밖에 …

Andrej Karpathy 라는 사람의 구조파악

LLM Wiki 라는 앱은 nash_su(베이징, 前 IterCast 창업자)가 구현했으며, 핵심 방법론은 Karpathy의 llm-wiki.md gist 추상 설계 패턴 문서에서 온 것이다.

데이터를 구조화 하는 패턴이 나와 비슷해 보여 그 사람의 구조를 파악해보면 LLM Wiki가 어떤 기반에서 만들어졌는지 이해하는데 도움이 될 것 같아 AspectScope를 통해 분석하였다.

1단계. 모르는 것과 아는 것의 경계 긋기

Karpathy에 대해 알려진 정보를 바탕으로 그 사람의 구조를 특정하기 위해, AspectScope에 그의 프로파일을 생성하고 생년월일 1986-10-23, 시각 12:00에 불확실도 ±720분 플래그를 설정하였다.

범위가 너무 넓지만 그 날 전체를 통틀어 확실한 것은 아래와 같다:

Karpathy는 Mercury-Venus Conjunction 구조를 갖고 있으며, 태어난 당일 범위에서 Orb 값이3.77~5.0이다.

흠,,, Mercury-Venus 가 무려 Conjunction 이라니… 이 구조만으로 많은 것을 직감할 수 있다.

AspectScope의 aspect-scan으로 그의 생일 하루(00:00~24:00)를 30분 간격으로 잘라 Mercury-Venus Conjunction Orb 변화를 추적하니, 하루 종일 Orb이 단조 증가한다. 즉 Exact Conjunction은 전날 이미 지났고, 이날은 계속 멀어지는 중이다. 허용 Orb 상한을 넘지 않으려면 출생은 현지시간 약 16:05 이전이어야 하기 때문에, 후보 범위가 ±720분에서 16시간 창으로 좁혀졌다.

2단계. 16시간 좁히기

시시각각 바뀌는 ASC와 MC는 약 2시간마다 별자리를 바꾸기 때문에 10분 간격으로 ASC/MC 회전 타임라인을 뽑고, 거기에 행성들이 각도축에 붙는(angular) 시점을 찾았다.
Karpathy의 홈페이지에 공개된 데이터를 기반으로, 그 사람의 드러난 성향은 커뮤니케이터 시그니처 였고, 그 특징에 부합하는 영역은 4개의 영역중 딱 두 개였다.

음… 스탠퍼드 강의로 유명한 사람이니 D(경력축에 언어능력이 걸림)도, OpenAI 공동창립자니 B(집단 하우스의 태양)도 말이 된다.

여기서 감으로 고르면 이 짓거리가 그냥 별자리 운세보기로 떨어지므로, 나는 판별식이 필요했다. 그래서 Transit Chart를 분석한다.

행성 대 행성 트랜짓(예: 트랜짓 Uranus ↔ Natal Venus)은 ASC/MC가 아니라 한번 고정되면 절대 안 바뀌므로, 후보 시각이 달라져도 변화가 거의 없어 판별력이 없다.

따라서 여기서 판별 변수는 오직 하나 – 트랜짓 외행성 ↔ 각도축(ASC/MC)이다. 이 판별 기준은 천문학적 우연이 아니라 아래와 같은 검증 가능한 실제 이력을 사용하였다:

• 2015-12-11: OpenAI 공동창립
• 2024-07-16: Eureka Labs(교육 스타트업) 설립

두 날짜, 두 후보 차트, 총 4회의 Transit-to-Natal 교차 계산. 결과:

Pluto-MC Trine은 수십 년 주기의 심층 경력 전환 위상이고, Uranus-ASC Opposition 은 “기관에서의 독립·자기 벤처 전환”의 전형적 특징이다.

두 독립적인 트랜짓이 모두 B에서 맞고 D에는 근사치조차 없었다.

물론 이것은 수학적 증명이 아니다.
다만 “두 개의 독립된 저확률 사건이 같은 후보에서 연속히트”는 합리적 신뢰도의 추정이다.

최종 추정: 1986-10-23 08:25~08:55 (중심 08:40±10분), Location: Slovakia Bratislava

3단계. 차트 확정

08:40 차트의 골격은 이렇다:

• Mercury-ASC Conjunction (+0.14°, Scorpio) – 존재 자체가 심층 해부형 언어 기능
• Venus도 ASC 인접 (+4.62°, Libra) – 날카로움 위의 우아함
• Saturn 1하우스(Scorpio) – 검증 강박, 진짜/가짜의 경계 설정
• Sun 11하우스 – 집단·네트워크 속 자기실현
• Moon Gemini 8하우스 – 심층 탐구가 정서적 보상

graph LR

  Mercury <-- Conjunction (+0.14°) --> Ascendant
  Mercury <-- Opposition (+0.14°) --> Descendant
  Mercury <-- Conjunction (+4.62°) --> Venus
  Moon <-- Quincunx (+7.16°) --> Mercury
  Sun <-- SemiSextile (+5.75°) --> Mercury

  linkStyle 0 stroke:blue,stroke-width:5px;
  linkStyle 1 stroke:red,stroke-width:5px;
  linkStyle 2 stroke:blue,stroke-width:2px;
  linkStyle 3 stroke:red,stroke-width:1px;
  linkStyle 4 stroke:green,stroke-width:2px;

  classDef node1 stroke-width:1px;
  classDef node2 stroke-width:2px;
  classDef node5 stroke-width:5px;
  class Ascendant node5;
  class Descendant node5;
  class Mercury node5;
  class Moon node1;
  class Sun node2;
  class Venus node2;

이제 LLM Wiki gist(llm-wiki.md)의 설계 선택들과 겹쳐 읽으면 소름 돋는 대응이 보인다:

강점의 대가로서의 한계도 같은 구조에서 나온다:

• Mercury-Scorpio의 전수 해부 성향 → ingest 때마다 기존 wiki 전체 재검토(병합은 하지않는다) → 확장성 제한 (커뮤니티의 v2 extension gist “what breaks at scale”이 정확히 이 제한을 밝힘)
• Saturn 1하우스의 검증 권한 위임 불가 → 인간 큐레이션 병목 – 혼자 쓰는 도구로 최적화
• Mercury-Venus Conjunction이 분리형(separating)이고 Orb 폭이 4.6~4.8° → 표현력과 정확성이 결합됐지만 완전 융합이 아님 → 미세한 드리프트

즉 LLM Wiki의 한계는 설계자 인격 구조의 필연적 발현이다.

그런데, 나는 왜 거부감이 드는가

1. 통제 불가능한 확장에 대해서 근원적으로 거부한다 -> Wiki 페이지의 내용이 내가 조절할 수 없는 글들로 채워지는 것을 견디기 힘들다.
2. 생성 문서들의 서술 패턴(인용은 많고 단정은 없는 “근거타령”)은 불확실성에 대한 반발로 작용한다 -> LLM Wiki 내용에 기반한 LLM Chatting 의 결과가 RAG보다 못하다고 느낌.
3. LLM Wiki의 본질은 팽창이고, 원리와 구조에 입각한 간결함과 명쾌함을 추구하는 나의 Mercury-Pluto Trine 구조적 특징이 추구하는 것과 부딪힐 수 밖에 없다.
4. 내 Mercury 네트워크의 핸들러는 Sextile(+3.36°)로 연결된 Venus(Gemini)다. 즉 나는 위상 Topology 그래프보다 비교(comparison) 뷰에 반응하는 구조다.
   LLM Wiki force-directed 그래프가 나에게 쓸모없어 보이는 건 당연했다. 그래프가 보여주는 건 ‘연결의 양’ 일 뿐이다.
   ‘관계의 의미 차이’가 아니다.

그러나 완전히 버리기엔 너무 이르다.

LLM Wiki 저장소의 schema.md를 통제 수단으로 강화하고, 다른 플러그인들을 조합해서 사용하다보면 해결책이 나올 것은 직감이 든다.

이 주제의 Kontexus Note PREFIX는 0,rYu,1 이다. 방법을 찾을 때 까지 관련 포스트는 해당 PREFIX로 이어간다.

디지털 폐기물 매립지, LLM Wiki

현재 상태로는 쓸모없다 (2026-09-06)

nashsu/llm_wiki는 Karpathy의 LLM Wiki 아키텍처는 이해했지만, Karpathy의 “pattern이지 product가 아니다”, “사용자와 agent가 구체적인 workflow를 함께 발전시킨다” 라는 개방성을 고정된 ingestion pipeline으로 바꾸면서 훼손했다.

schema.md, purpose.md 에 무슨 짓을 해도 4096자 크기 제한의 Summary를 피할 수 없다. 게다가 Summary 방식을 외부에서 조절할 수 없는 건 누구 말대로 지식을 관리하는 것이 아니라 지식이 관리되고 있다는 외관을 보일 뿐이다.

그럼에도 불구하고 LLM Wiki 앱을 써야 한다면, 3가지 정도의 이유가 있다:

1. 인터랙티브 지식 그래프 뷰어 (Graph View): [[wikilink]]와 related 메타데이터를 기반으로 노드 간의 관계망, 중심 노드, 고립된 지식 공백을 시각적 2D/3D 그래프로 렌더링해 주는 GUI.
2. 로컬 벡터 임베딩 및 시맨틱 검색 엔진 (LanceDB): wiki/ 폴더의 모든 마크다운을 로컬 벡터 DB(LanceDB)에 인덱싱하여, 키워드가 정확히 일치하지 않아도 “글쓰기 지연과 관련된 위상 구조”처럼 의미 기반 검색을 가능하게 해 줌.
3. 지식 제공용 로컬 MCP 서버 (Desktop MCP Server) 제공: Claude Desktop, Cursor 등 외부 AI가 이 위키를 search_wiki, read_wiki_page 같은 도구로 읽어갈 수 있도록 API/MCP 엔드포인트를 열어주는 백엔드 데몬.

가능한 소스를 건드리지 않으려고 했지만, 위의 3가지를 쓰려고 fork해서 내 입맛에 맞게 수정해서 사용하기로 결정했다.