LLM Wiki 2026 — RAG 안 붙이고도 개인 위키가 굴러가는 조건, second brain 운영 체크리스트

개인 second brain에 벡터 DB부터 붙이는 건 종종 순서가 틀렸다.

검색이 멍청해서가 아니라, 읽는 레이어가 없어서다.

Andrej Karpathy가 2026년 4월 초 공유한 LLM Wiki 아이디어가 꽂힌 이유도 여기 있다.

핵심은 거창한 인프라가 아니다.

raw source를 버리지 않고, LLM이 읽기 좋은 markdown 위키 레이어를 얇게 하나 올리는 방식이다.

이게 왜 재밌냐면, 내가 이미 굴리고 있는 Obsidian second brain 구조랑 생각보다 잘 맞기 때문이다.

00.Inbox에 raw source를 쌓고, 허브 페이지에서 읽기 좋은 형태로 재구성하고, 주간 리뷰에서 stale check를 거는 구조라면, 굳이 모든 걸 RAG 파이프라인으로 시작하지 않아도 된다.

진짜 승부는 입력량보다 회수율이다.

그리고 회수율은 생각보다 자주, 검색 모델보다 위키 구조에서 갈린다.

이 글은 Karpathy의 LLM Wiki 아이디어를 계기로, 언제 개인 위키가 RAG보다 낫고, 언제 반대로 RAG가 필요한지, 그리고 내 second brain 운영 기준으로는 어디까지 얇게 붙이는 게 맞는지 정리한 메모다.

이런 운영자에게 특히 잘 맞는다

• Obsidian이나 비슷한 노트 시스템에 자료는 많이 쌓이는데 다시 꺼내 쓰기가 잘 안 되는 사람
• RAG를 붙일까 말까 고민하는데, 아직 인프라부터 키우고 싶진 않은 사람
• AI 에이전트에게 읽힐 지식 레이어를 따로 만들고 싶은 사람
• raw source, 요약, 허브, 주간 리뷰가 따로 놀고 있는 사람
• 검색은 되는데 자산화가 안 된다는 느낌이 드는 사람

메모를 허브로 승격시키는 실전 흐름은 짧은 AI 뉴스 메모를 나중에 운영 허브로 키우는 가장 쉬운 방법 2026 — 메모와 가이드 분업 설계 쪽이 바로 이어지고, 허브를 실제 배포 산출물로 넘길 때 생기는 리스크는 AI가 만든 PDF를 바로 배포하면 왜 사고가 나나 2026 — 검수·버전·저작권 체크리스트 에서 더 구체적으로 이어진다.

답을 먼저 적으면

LLM Wiki는 RAG 대체품이라기보다 읽기 쉬운 compiled layer에 가깝다.

자료가 대략 100개 안팎, 주제 허브가 반복되고, 운영자가 직접 큐레이션할 수 있고, markdown 중심으로 돌아가는 개인 시스템이라면, RAG보다 먼저 붙여볼 가치가 크다.

반대로 자료가 너무 크고, 실시간성이 강하고, 권한 분리와 문서 조각 인용이 중요하고, 여러 사람이 같은 지식베이스를 운영해야 한다면, 위키만으로는 곧 숨이 찬다.

그때는 RAG나 별도 인덱싱 계층이 다시 필요해진다.

지금 결론

내 기준으로는 이렇게 정리된다.

1. raw source는 그대로 보존한다.
2. topic별 compiled wiki를 얇게 만든다.
3. ontology나 action log는 운영 OS로 따로 둔다.
4. 질문은 compiled wiki -> source -> 운영 로그 순서로 본다.
5. 위키가 오래 안 읽히면 검색 문제가 아니라 허브 품질 문제로 먼저 본다.

이 순서가 맞으면, RAG를 안 붙여도 surprisingly well 돌아가는 구간이 있다.

Karpathy도 gist에서 대략 100 sources와 hundreds of pages 수준의 moderate scale에서는 이 방식이 꽤 잘 먹힌다고 설명했다.

이건 작은 숫자 같아 보여도, 개인 second brain엔 사실 꽤 넓은 범위다.

왜 이 아이디어가 갑자기 꽂혔나

개인 지식 시스템은 늘 두 가지 사이에서 흔들린다.

• raw source를 많이 모으는 쪽
• retrieval 인프라를 먼저 붙이는 쪽

둘 다 장점이 있다.

문제는 둘 다 혼자 가면 금방 삐끗한다는 거다.

raw source만 쌓으면 창고가 되고, RAG만 붙이면 답은 나오는데 지식이 자산으로 남지 않는 경우가 많다.

Karpathy의 LLM Wiki 아이디어가 좋은 이유는, 이 사이에 사람이 다시 읽는 층을 하나 둔다는 점이다.

원문은 원문대로 두고, 에이전트와 사람이 반복해서 꺼내볼 topic 허브를 따로 만든다.

이게 생각보다 중요하다.

질문에 대한 정답을 매번 새로 계산하는 시스템과, 질문을 계기로 점점 읽기 좋은 자산이 쌓이는 시스템은 완전히 다르기 때문이다.

전자엔 속도가 강점이고, 후자엔 복리성이 있다.

블로그도 그렇고 second brain도 그렇고, 나중에 돈이 되는 쪽은 대개 후자다.

Karpathy가 제안한 LLM Wiki 구조는 뭔가

gist의 핵심은 화려한 모델 얘기가 아니다.

구조가 핵심이다.

내가 읽은 기준으로는 세 층이다.

층	역할	왜 필요한가
raw source	원문, 링크, 캡처, 원자료	사실의 근거를 잃지 않기 위해
wiki	topic별로 읽기 좋게 정리한 compiled layer	사람이 다시 읽고 LLM이 요약하기 쉽게 만들기 위해
schema	어떤 페이지가 있고 어떤 메타를 갖는지 정리한 규칙	유지보수와 자동화 일관성을 위해

그리고 운영 파일로 index.md와 log.md를 꽤 중요하게 본다.

이 두 개가 별거 아닌 것 같아도, 사실 위키를 위키답게 만든다.

index.md는 진입점이고, log.md는 변경 이력이다.

둘 중 하나라도 없으면 금방 이런 일이 생긴다.

• 어디서부터 읽어야 할지 모른다
• 최근에 뭐가 바뀌었는지 모른다
• topic 허브가 stale인지 아닌지 감이 안 온다
• 같은 주제를 또 새로 정리하게 된다

여기서 느낌이 온다.

이건 검색 시스템 얘기라기보다, 운영 가능한 문서 시스템 얘기다.

내 second brain 구조에 대입하면 더 명확하다

내 볼트 기준으로는 이 매핑이 제일 자연스럽다.

LLM Wiki 구조	내 볼트 대응	실제 역할
raw source	00.Inbox/	클리핑, 요약, 캡처, 원문 메모
compiled wiki	01.Projects/온톨로지/llm-wiki/	topic hub, 읽기 좋은 정리층
운영 OS	01.Projects/온톨로지, 99.system, .claude	action, governance, weekly review, agent logs

이렇게 나누면 장점이 생긴다.

raw source는 건드리지 않아도 되고, compiled wiki는 읽는 속도를 올려주고, 운영 OS는 규칙과 실행을 담당한다.

즉 백오피스와 프론트를 분리하는 셈이다.

이 분리가 은근히 크다.

지식 시스템이 망가지는 대표적인 이유가, 원문 저장소와 읽기 레이어와 운영 레이어가 한 파일에서 싸우기 시작하기 때문이다.

그 순간 문서가 예뻐지지도 않고, 조회도 빨라지지 않고, 운영도 피곤해진다.

내 볼트 안에서도 이미 이 패턴이 있었다

재밌는 건 이게 갑자기 하늘에서 떨어진 아이디어가 아니라는 점이다.

내 쪽 리서치 문서에서도 비슷한 결론이 이미 몇 번 나와 있었다.

예를 들면 온톨로지 리서치 문서에서는 Properties + Links + (Bases 또는 Dataview) 조합을 현실적인 표준으로 봤다.

그리고 semantic recall 관련 메모에서도 포인트는 같았다.

새 도구를 덕지덕지 붙이는 것보다, 흩어진 정보가 다시 잘 찾아지게 만드는 방식이 먼저라는 거다.

이 문장을 뒤집으면, LLM Wiki가 꽂히는 이유도 설명된다.

위키는 retrieval을 없애는 게 아니라, retrieval이 더 잘 먹히는 읽기 표면을 만든다.

그러니까 이 아이디어를 RAG 안티로 읽으면 반만 읽은 거고, retrieval 전 단계의 문서 정리 레이어로 읽어야 제맛이다.

언제 LLM Wiki가 RAG보다 먼저 붙을 만한가

이게 제일 중요한 질문이다.

나는 아래 5가지 조건이 맞으면, RAG보다 먼저 compiled wiki를 붙여도 된다고 본다.

1. 자료 규모가 moderate scale일 때

Karpathy가 말한 ~100 sources, hundreds of pages는 개인 시스템에선 결코 작은 숫자가 아니다.

이 정도면 사람이 topic hub 몇 개를 관리하면서도 전체 그림을 아직 잃지 않을 수 있다.

반대로 수천 문서가 넘어가면 얘기가 달라진다.

그때는 raw retrieval 인프라가 다시 중요해진다.

2. 주제가 반복될 때

주식, 연금, AI 에이전트 운영, 블로그 운영처럼 같은 주제가 자꾸 돌아오는 시스템이라면 위키 효율이 높다.

질문이 조금씩 달라도, topic hub는 계속 재사용된다.

이런 도메인에서는 매번 새로 검색하는 것보다, 잘 관리된 허브 하나가 훨씬 강하다.

3. 운영자가 직접 큐레이션할 수 있을 때

여기서 운영자란 꼭 사람이 수작업으로 다 쓴다는 뜻이 아니다.

사람이 판단 기준을 잡고, LLM이 정리와 업데이트를 맡는 구조를 말한다.

허브가 믿을 만하려면 최소한 이 판단층은 남아 있어야 한다.

아무 source나 들어오는 공개 지식창고면 얘기가 달라지지만, 개인 second brain은 이 큐레이션이 가능하다.

4. markdown이 실제 운영 포맷일 때

Obsidian, repo docs, notes 폴더처럼 원래부터 markdown이 중심인 시스템이면 위키 레이어가 붙기 쉽다.

새 DB나 새 CMS를 추가하지 않아도 되기 때문이다.

이건 생각보다 큰 장점이다.

기술 부채는 대개 새 기능보다 새 포맷에서 더 빨리 생긴다.

5. 질문 로그가 자산으로 다시 쌓여야 할 때

내가 자주 겪는 문제는 이거다.

질문은 잘 답했는데, 그 답이 다음에 다시 안 잡힌다.

그럼 검색은 성공했어도 자산화는 실패한 거다.

LLM Wiki는 이 지점을 겨냥한다.

질문 결과를 topic 허브나 log에 축적할 수 있기 때문이다.

그러면 다음 질문은 약간 더 쉬워지고, 다음 글감도 더 빨리 잡힌다.

반대로 언제 RAG가 여전히 필요한가

여기서 괜히 위키 만능론으로 가면 바로 미끄러진다.

LLM Wiki가 좋은 구간이 있는 것과, RAG가 여전히 필요한 구간이 있는 건 동시에 참이다.

1. 문서량이 너무 많을 때

수천 문서, 수만 chunk가 기본인 환경에서는 topic hub만으로 커버가 안 된다.

compiled wiki는 앞단 요약층으론 좋지만, 전체 raw corpus 검색까지 대체하긴 어렵다.

2. 출처 조각 인용이 중요할 때

정확한 문장 근거, 세부 정책 차이, 조항 단위 인용이 필요한 환경에서는 raw retrieval이 여전히 중요하다.

위키는 좋은 설명을 주지만, 가끔 너무 잘 설명해서 source의 거친 결을 지워버리기도 한다.

3. 권한 분리가 강할 때

여러 팀, 여러 고객, 다른 접근 권한이 섞인 환경에서는 개인 위키 감성으로는 버티기 어렵다.

이건 검색보다 access control 문제다.

그 순간부터 별도 지식 인프라가 필요해진다.

4. 실시간성이 매우 강할 때

문서가 하루에도 수십 번 바뀌고, 가장 최신 상태가 늘 중요하다면, 수동 큐레이션이 들어가는 위키는 금방 stale해진다.

이 경우엔 live retrieval이나 동적 인덱싱이 더 중요하다.

5. 운영자가 더 이상 큐레이션을 못 할 때

위키의 숨은 비용은 읽기 좋은 형태를 유지하는 비용이다.

이걸 아무도 안 돌보면, 허브는 몇 주 만에 아주 그럴싸한 박제가 된다.

겉은 예쁜데 현재성이 죽는 거다.

그럼 차라리 raw retrieval이 더 솔직하다.

그래서 정답은 위키냐 RAG냐가 아니라 레이어링이다

여기서 제일 많이 하는 실수가 이분법이다.

위키 아니면 RAG.

이렇게 가면 싸움은 쉬운데 운영은 어려워진다.

내가 지금 더 설득력 있다고 보는 건 layered approach다.

레이어	먼저 볼 것	역할
compiled wiki	사람이 읽는 허브	빠른 온보딩과 재사용
raw source	원문, 요약, 캡처	근거 확인과 세부 맥락
운영 로그	action, review, stale, ownership	유지보수와 책임 추적
retrieval 계층	필요 시 검색/임베딩	대규모 탐색과 세부 인용

질문을 받았을 때도 순서를 고정하면 좋다.

1. 허브를 먼저 본다
2. source를 확인한다
3. 운영 로그를 본다
4. 그래도 부족하면 retrieval로 확장한다

이 순서를 쓰면 답이 빨라진다.

무엇보다 설명 품질이 좋아진다.

처음부터 chunk를 긁어모으면 정답은 맞아도 서사가 약한 경우가 많은데, 허브를 먼저 보면 맥락이 살아 있다.

TECHTAEK 글도 사실 이 맥락형 답변이 더 잘 먹힌다.

내 시스템에선 왜 얇은 compiled wiki가 맞나

여기서 중요한 단어가 얇은이다.

Karpathy 방식이 좋다고 해서, 내 시스템 전체를 새로 뒤엎을 필요는 없다.

오히려 그러면 망한다.

내 볼트는 이미 governance가 강한 편이다.

• Capture
• Review
• Synthesis
• weekly check
• action log
• agent logs

이 백엔드는 이미 있다.

부족한 건 topic별로 사람이 빨리 읽을 수 있는 앞단이다.

그래서 compiled wiki는 엔진 교체가 아니라, 읽기 인터페이스 추가로 가야 한다.

내부 문서에도 이 포인트가 이미 적혀 있다.

지금 시스템은 위키보다 운영체계에 더 가깝다. 그래서 compiled wiki는 새 엔진이 아니라 읽기 인터페이스로 붙이는 게 맞다.

이 문장이 거의 정답이다.

괜히 새 엔진처럼 다 바꾸면, 원래 있던 강점인 governance를 잃어버린다.

실제로 어떻게 붙이면 좋나

내 기준의 최소 구조는 이 정도다.

폴더

• raw source: 00.Inbox/
• compiled wiki: 01.Projects/온톨로지/llm-wiki/
• 운영 규칙: 기존 온톨로지와 .claude

핵심 파일

• index.md
• log.md
• 운영규칙.md
• topics/*.md

topic page 기본 섹션

1. 한 줄 정의
2. 왜 중요한가
3. 현재 내가 믿는 것
4. source notes
5. 사실 / 해석 / 질문
6. 다음 액션

이 포맷이 좋은 이유는 문서가 예쁘기 때문이 아니다.

사실과 해석을 구분하기 쉽고, 다음 액션이 남아서 stale page가 덜 생기기 때문이다.

직접 얹어보니 바로 좋아진 점

이번에 나는 이 아이디어를 그냥 메모로만 남기지 않고, 실제로 01.Projects/온톨로지/llm-wiki/ 아래에 얇은 레이어를 먼저 깔아봤다.

만든 건 딱 이 정도다.

• index.md
• 운영규칙.md
• log.md
• topics/LLM Wiki.md
• topics/AI 에이전트 운영.md

거창한 자동화는 아직 안 붙였다.

일단 읽기 표면부터 만든 셈이다.

직접 해보니 좋아진 건 3가지였다.

1. 질문을 받을 때 첫 화면이 생긴다

원래는 관련 Inbox 요약 3개 + 예전 온톨로지 문서 2개 + 세컨드브레인 리포트 1개를 열어야 했다.

이건 자료가 없는 게 아니라, 첫 진입점이 없는 상태다.

근데 topic hub가 하나 생기니까 질문이 들어왔을 때 먼저 읽을 표면이 생긴다.

이게 별거 아닌 것 같아도, 답변 속도보다 설명 정리력에 더 크게 먹힌다.

2. 사실과 해석을 분리하기 쉬워진다

raw source만 볼 때는 내 생각이랑 원문 포인트가 쉽게 섞인다.

특히 AI/에이전트 주제는 표현이 그럴싸해서 더 위험하다.

근데 hub에 사실 / 해석 / 질문 칸을 나눠두니, 어디까지가 source이고 어디서부터가 내 운영 판단인지 선이 선다.

이건 글 쓸 때도 좋고, 나중에 다시 볼 때도 덜 헷갈린다.

3. 블로그 전환이 빨라진다

이게 의외로 컸다.

글감으로 바꾸려면 결국 이 주제를 한 문장으로 뭐라고 설명할지, 지금 내가 믿는 결론이 뭔지, 독자한테 바로 줄 체크리스트가 뭔지 이 세 가지가 먼저 나와야 한다.

compiled wiki 허브는 이 세 가지를 미리 압축해둔다.

그래서 블로그 초안으로 넘길 때 기사가 아니라 운영 메모에서 출발하게 된다.

이 차이가 생각보다 크다.

직접 해보니 귀찮아지는 점도 있다

여기서부터가 진짜 TECHTAEK 포인트다.

좋은 점만 보면 거의 모든 아이디어가 멋있어 보인다.

근데 운영에 붙이면 귀찮음이 진실을 말해준다.

1. 허브 이름 짓기가 은근히 어렵다

source를 topic으로 묶는 순간, 제목이 기사 제목에서 운영 개념으로 바뀌어야 한다.

이게 잘 안 되면 허브가 금방 중복된다.

예를 들면 LLM Wiki, compiled wiki, RAG 없이 굴리는 위키, 이런 게 따로 놀기 시작할 수 있다.

결국 topic naming 규칙이 필요해진다.

2. stale 판단이 생각보다 애매하다

문서가 안 바뀌었다고 stale은 아니다.

주제가 그대로 유효하면 허브는 그대로 살아 있을 수 있다.

반대로 source가 새로 들어왔는데도 허브가 안 바뀌면 stale일 수 있다.

즉 마지막 수정일 하나로는 부족하다.

주간 점검에서 새 source 유입 대비 허브 미갱신 같은 규칙을 따로 봐야 한다.

3. 허브가 source를 너무 잘 덮어버릴 수 있다

이건 꽤 위험하다.

허브 설명이 좋아질수록, 사람이 raw source를 덜 읽게 된다.

그럼 어느 순간부터는 위키가 진짜를 대신해버린다.

그래서 source notes 구역은 귀찮아도 남겨둬야 한다.

요약이 좋아질수록 근거 링크는 더 중요해진다.

4. 자동화 욕심이 빨리 올라온다

허브 몇 개가 생기면 바로 이런 생각이 든다.

그럼 ingest도 자동으로 하고 stale check도 자동으로 하고 topic 추천도 자동으로 하고 weekly review에서 갱신도 자동으로 하자

여기서 급발진하면 다시 인프라 프로젝트가 시작된다.

그래서 내 기준으론 처음엔 topic 3개, 주간 stale check 1개, log 기록만 수동으로 돌리는 게 맞다.

작은 예시로 보면 더 쉽다

예를 들어 LLM Wiki 관련 링크가 3개 들어왔다고 해보자.

• gist 원문
• 누군가의 요약 글
• 내 노션 인박스에서 넘어온 한 줄 요약

이걸 그대로 세 개 보관하면 캡처는 끝난다.

근데 다음 주에 RAG 없이 개인 위키 굴리는 법 질문이 오면, 다시 세 파일을 다 열어봐야 한다.

이건 저장은 성공했지만 회수는 실패한 상태다.

반대로 topic hub 하나를 만들면 달라진다.

• 한 줄 정의가 생긴다
• 지금 내가 믿는 것이 생긴다
• source가 한곳에 모인다
• 열린 질문이 남는다
• 다음 액션이 생긴다

그럼 다음 질문이 들어왔을 때 허브를 먼저 읽고, 필요할 때만 source로 내려가면 된다.

이 차이가 생각보다 크다.

숫자 예시로 보면 언제 효율이 바뀌나

대충 이런 그림으로 볼 수 있다.

case 1. source 20개

이 정도면 사실 raw source만 있어도 버틴다.

머릿속 map이 아직 유지되기 때문이다.

case 2. source 100개

여기서부터 허브의 가치가 급격히 올라간다.

topic이 반복되기 시작하고, 같은 질문이 다른 표현으로 다시 들어오기 때문이다.

Karpathy가 moderate scale이라고 말한 구간도 딱 이 지점이다.

case 3. source 500개+

이때부터는 허브만으론 한계가 온다.

topic 허브는 여전히 중요하지만, raw retrieval 인프라가 같이 필요해질 확률이 높다.

즉 내 해석은 이렇다.

• 0~30: 그냥 저장해도 됨
• 30~150: compiled wiki 효율이 제일 큼
• 150+: 위키 + retrieval 혼합이 현실적

이건 절대 법칙은 아니다.

근데 개인 second brain 운영 경험상 꽤 쓸 만한 기준이다.

실전 운영 체크리스트

아래 조건이 맞으면 LLM Wiki를 시작해도 된다.

시작해도 되는 신호

• 같은 주제의 메모가 자꾸 쌓인다
• 비슷한 질문에 매번 비슷한 답을 새로 쓰고 있다
• raw source는 있는데 topic별 진입점이 없다
• 주간 리뷰 루프가 이미 있다
• markdown 파일을 중심으로 굴리고 있다

아직 이른 신호

• source가 너무 적어서 그냥 폴더 검색이면 충분하다
• topic 구분이 아직 없고 메모 성격도 뒤섞여 있다
• 큐레이션할 사람이 없다
• 위키를 만들겠다는 마음보다 새 도구를 만져보고 싶은 마음이 더 크다
• stale check를 할 루프가 없다

마지막 줄이 중요하다.

위키는 생각보다 금방 늙는다.

그래서 잘 만들기보다 늙은 걸 발견하기가 더 중요하다.

실수 TOP 5

1. raw source를 허브로 덮어써버리기

이건 나중에 거의 반드시 후회한다.

허브는 허브고, 원문은 원문이다.

source를 버리면 해석 검증이 어려워진다.

2. source 1개당 topic page를 하나씩 만들기

그럼 위키가 아니라 요약 폴더가 된다.

비슷한 주제는 허브에 합쳐야 한다.

3. 사실과 해석을 섞어 쓰기

이건 LLM이 읽을 때도, 사람이 다시 읽을 때도 둘 다 안 좋다.

나중에 무엇이 원문이었는지 흐려진다.

4. log.md 없이 시작하기

작은 시스템일 땐 별거 아닌 것 같아도, 금방 최근에 뭐가 바뀌었지?가 된다.

변경 로그는 생각보다 큰 정신적 안전장치다.

5. 위키를 완성품처럼 대하기

완성된 백과사전처럼 만들려고 하면, 시작도 못 하고 금방 지친다.

이건 living doc다.

늘 조금 덜 끝난 상태로 굴리는 게 맞다.

내가 지금 당장 붙인다면 이렇게 한다

기술적으로 거창하게 안 간다.

1. 00.Inbox source 중 반복 주제 3개를 고른다
2. llm-wiki/topics/에 허브 3개만 만든다
3. 각 허브에 한 줄 정의 / 왜 중요한가 / 현재 내가 믿는 것 / source / 질문 / 액션을 넣는다
4. 주간 리뷰에서 stale hub만 한 번 본다
5. 블로그 글감과 연결되는 topic은 internal link를 추가한다

이 정도면 충분하다.

뭐든 그렇듯, 처음부터 ingestion daemon을 만들고 lint 체계를 완벽히 짜는 순간 일이 커진다.

그건 보통 일은 커졌는데 회수율은 아직 안 오른 상태다.

아주 인간적인 삽질이다.

어떤 주제부터 허브로 만들면 효율이 높은가

개인적으로는 아래 순서가 좋다.

1. 반복 질문이 많은 주제

예:

• AI 에이전트 운영
• 연금/ISA
• 배당 ETF 구조
• 블로그 운영

이런 건 허브가 바로 효용을 낸다.

2. source는 많은데 설명이 매번 새로 필요한 주제

예:

• RAG vs wiki
• hooks vs agent
• covered call vs dividend growth

이런 건 허브가 설명 비용을 줄여준다.

3. 운영 판단이 같이 붙는 주제

예:

• 언제 도입할까
• 언제 안 쓰는 게 낫나
• 어떤 팀엔 맞고 어떤 팀엔 안 맞나

이건 단순한 정보보다 운영 판단이 들어가야 해서, compiled wiki의 장점이 더 커진다.

이 글을 블로그 운영에 바로 연결하면 뭐가 좋아지나

이건 TECHTAEK 관점에서도 중요하다.

LLM Wiki 방식은 그냥 개인 메모용이 아니라, 블로그 허브 강화에도 잘 맞는다.

왜냐면 좋은 블로그 운영도 결국 비슷하기 때문이다.

• raw source 수집
• topic 허브 강화
• 질문형 글 분기
• 내부링크 축적
• 주기적 리프레시

즉 글감 시스템과 second brain이 따로 노는 게 아니라, 사실 거의 같은 문제를 다른 말로 부르고 있는 셈이다.

그래서 이 아이디어를 잘 붙이면, 글감 찾기와 허브 강화와 에이전트 회수율이 같이 좋아질 수 있다.

이건 생각보다 큰 돈 냄새가 난다.

뉴스형 트래픽은 빨리 오고 빨리 가는데, 허브형 지식 자산은 늦어도 오래 간다.

FAQ

Q1. 그럼 RAG는 안 써도 된다는 말인가

아니다.

지금 당장 모든 개인 시스템에 RAG가 먼저 필요한 건 아니다에 더 가깝다.

규모와 운영 조건이 맞으면, compiled wiki가 먼저일 수 있다는 뜻이다.

Q2. Obsidian이면 Dataview나 Bases가 꼭 있어야 하나

꼭은 아니다.

근데 허브 조회와 상태 확인이 쉬워져서 꽤 도움이 된다.

내 쪽 리서치 기준으로도 Properties + Links + Bases 또는 Dataview 조합은 현실성이 높았다.

Q3. topic page는 누가 쓰나

초안은 LLM이 써도 된다.

하지만 현재 내가 믿는 것, 해석, 다음 액션은 사람이 마지막 판단을 넣는 게 좋다.

여길 다 자동화하면 금방 그럴싸한 소설이 된다.

Q4. log.md까지 꼭 필요할까

작을 때는 없어도 버틴다.

근데 2주만 지나도 최근 변경을 기억 못 한다.

그래서 빨리 넣는 편이 낫다.

Q5. 이걸 팀 위키에도 그대로 적용할 수 있나

일부는 된다.

하지만 팀 위키는 권한, 최신성, 책임 분리가 더 중요해서 개인 second brain보다 훨씬 빨리 별도 retrieval 계층이 필요해질 수 있다.

같이 걸어둘 운영 글

• 짧은 AI 뉴스 메모를 나중에 운영 허브로 키우는 가장 쉬운 방법 2026 — 메모와 가이드 분업 설계
• AI가 만든 PDF를 바로 배포하면 왜 사고가 나나 2026 — 검수·버전·저작권 체크리스트
• Claude Code 자동화 용어 정리 2026 — Triage·Compound·LLM Wiki·Harness를 어디에 써야 안 겹칠까

출처

• Andrej Karpathy, llm-wiki gist, 2026년 4월 확인
• https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
• Obsidian Help, Properties
• https://help.obsidian.md/properties
• Obsidian Help, Introduction to Bases
• https://help.obsidian.md/bases
• Dataview 공식 문서
• https://blacksmithgu.github.io/obsidian-dataview/

한 줄 메모

이 아이디어의 본질은 검색을 더 똑똑하게 만드는 것보다 지식을 다시 읽기 쉽게 유지하는 것에 있다.

그래서 내 기준에선 RAG의 경쟁자가 아니라, RAG 앞단에 붙는 인간 친화적 인터페이스에 더 가깝다.