Karpathy LLM Wiki는 Obsidian 세컨드브레인에 언제 붙일 만한가 2026

2026년 4월 18일 기준 Karpathy의 LLM Wiki gist가 말하는 핵심은 단순하다. RAG처럼 질문할 때마다 매번 원문 조각을 다시 찾게 하지 말고, LLM이 markdown 기반의 persistent wiki를 계속 유지하게 하자는 것이다.

이 주장은 세컨드브레인 운영자에게 꽤 세다. 이제 문제는 “내 노트를 AI가 요약해줄까”가 아니라, “내 Obsidian vault 안에 LLM이 유지보수하는 지식 코드베이스를 둘 준비가 됐나”로 바뀐다.

저는 이 아이디어를 처음 봤을 때 반쯤은 불편했다. Obsidian은 내가 쓰는 노트 앱인데, 갑자기 LLM이 파일 10개, 15개를 한 번에 건드린다고 하니까 마음속 안전벨트가 자동으로 채워졌다.

그런데 그 불편함이 오히려 핵심이다. LLM Wiki는 예쁜 지식관리 앱 추천이 아니라, 세컨드브레인을 소프트웨어 프로젝트처럼 운영하자는 제안에 가깝다.

Karpathy는 Obsidian을 IDE, LLM을 programmer, wiki를 codebase로 본다. 이 관점 하나만 받아들여도 운영 기준이 확 달라진다.

IDE라면 구조가 있어야 한다. Programmer라면 작업 규칙이 있어야 한다. Codebase라면 lint와 log가 있어야 한다.

그래서 이 글은 Karpathy LLM Wiki를 단순 요약하지 않는다. Obsidian이나 markdown vault를 이미 굴리는 사람이 raw sources, wiki, schema, ingest, query, lint를 언제 붙여야 하는지 판단하는 운영표로 재가공한다.

한 줄로 말하면 이거다.

LLM Wiki는 노트가 많은 사람에게 필요한 게 아니라, 노트의 변경 비용을 감당할 운영자가 필요한 방식이다.

핵심 판단

Karpathy LLM Wiki를 바로 도입해도 되는 사람은 의외로 많지 않다.

노트를 많이 모은 사람보다, 노트가 바뀌어도 추적할 수 있는 사람이 먼저다.

raw sources와 wiki를 분리하지 않으면 LLM이 원문과 해석을 섞기 쉽다.

schema를 쓰지 않으면 LLM은 매번 친절한 새 인턴처럼 행동한다.

ingest를 설계하지 않으면 새 자료 하나가 vault 전체를 흔들 수 있다.

query를 설계하지 않으면 좋은 답변이 채팅창에서 증발한다.

lint를 설계하지 않으면 세컨드브레인은 다시 오래된 창고가 된다.

이 글의 결론은 도입 찬성도 반대도 아니다.

작게 붙여라.

단, raw, wiki, schema, log, lint 없이 바로 전체 vault에 붙이지는 마라.

그건 세컨드브레인 자동화가 아니라 파일 기반 롤러코스터다.

재밌긴 한데, 내릴 때 표정이 조금 달라질 수 있다.

Karpathy LLM Wiki가 바꾸는 질문

일반적인 RAG 흐름은 질문할 때 원문을 검색한다.

사용자는 파일을 올린다.

시스템은 관련 chunk를 찾는다.

LLM은 그 조각을 읽고 답한다.

이 방식은 빠르게 시작하기 좋다.

하지만 누적이 약하다.

오늘 질문에서 만든 좋은 비교표가 내일 질문에 자동으로 구조화되어 남지 않는다.

물론 채팅 기록은 남을 수 있다.

하지만 채팅 기록은 보통 지식베이스라기보다 대화 영수증에 가깝다.

Karpathy의 제안은 중간에 markdown wiki를 둔다.

raw sources는 원문이다.

wiki는 LLM이 유지하는 해석과 연결의 층이다.

schema는 LLM에게 이 wiki를 어떻게 다룰지 알려주는 운영 규칙이다.

이렇게 바꾸면 질문이 바뀐다.

“이 문서를 어떻게 검색하지?”에서 “이 문서가 내 기존 지식 구조를 어떻게 바꾸지?”로 넘어간다.

바로 이 지점이 Obsidian 운영자에게 중요하다.

Obsidian을 오래 쓰면 자료 수집은 생각보다 쉽다.

진짜 어려운 건 연결 갱신이다.

예전 요약이 새 자료와 충돌하는지 확인하는 일이다.

개념 페이지가 너무 커졌는지 쪼개는 일이다.

인덱스가 현재 상태를 반영하는지 확인하는 일이다.

사람은 이 일을 귀찮아한다.

LLM은 이 일을 비교적 덜 귀찮아한다.

여기서 LLM Wiki의 운영 가치가 나온다.

기존 RAG와 다른 점

RAG는 보통 원문 검색 중심이다.

LLM Wiki는 유지보수 중심이다.

RAG에서는 질문할 때마다 관련 문서를 다시 찾는다.

LLM Wiki에서는 원문을 ingest할 때 이미 wiki를 갱신한다.

RAG에서는 검색 결과가 답변의 재료다.

LLM Wiki에서는 wiki 자체가 계속 갱신되는 산출물이다.

RAG에서는 chunk가 중심이다.

LLM Wiki에서는 page, link, index, log가 중심이다.

RAG에서는 “찾기”가 중요하다.

LLM Wiki에서는 “쌓기”가 중요하다.

이 차이를 모르고 LLM Wiki를 붙이면 실망하기 쉽다.

왜냐면 LLM Wiki는 검색 엔진을 대체하려는 아이디어가 아니기 때문이다.

오히려 검색 이전에 사람이 버려둔 관리 작업을 LLM에게 맡기는 패턴이다.

그래서 “내 vault 검색이 약한데 Graphify나 LLM Wiki를 붙이면 해결될까?”라고 묻는다면 답은 반반이다.

검색만 문제라면 검색 도구를 먼저 손보는 게 낫다.

연결, 요약, 충돌, 인덱스, 로그가 문제라면 LLM Wiki를 볼 만하다.

한마디로 RAG는 답변을 잘 찾게 해준다.

LLM Wiki는 지식베이스가 계속 늙지 않게 해준다.

이 둘은 경쟁 관계라기보다 역할이 다르다.

Obsidian 운영자는 여기서 욕심을 줄여야 한다.

처음부터 RAG, graph, agent, sync, publish까지 한 번에 붙이면 거의 반드시 꼬인다.

먼저 persistent wiki가 정말 필요한지 확인하는 게 순서다.

세 층 구조

Karpathy는 LLM Wiki를 세 층으로 설명한다.

첫 번째는 raw sources다.

두 번째는 wiki다.

세 번째는 schema다.

이 세 층을 분리하는 순간 Obsidian vault가 조금 더 개발 프로젝트처럼 보인다.

raw sources는 수정하지 않는 원문 저장소다.

기사, 논문, 회의록, PDF, 이미지, 데이터 파일이 여기에 들어간다.

여기서는 LLM이 읽을 수는 있어도 마음대로 고치면 안 된다.

원문은 출처다.

출처가 흔들리면 wiki의 모든 요약도 같이 흔들린다.

wiki는 LLM이 작성하고 갱신하는 markdown 파일 모음이다.

요약 페이지, 개념 페이지, 인물 페이지, 비교표, synthesis, overview가 여기에 들어간다.

사용자는 주로 읽고 검토한다.

LLM은 주로 쓴다.

schema는 이 둘 사이의 작업 규칙이다.

예를 들면 CLAUDE.md, AGENTS.md, wiki-conventions.md 같은 파일이 될 수 있다.

파일명 규칙, frontmatter 규칙, 링크 규칙, ingest 절차, query 응답 형식, lint 체크 항목을 적는다.

schema가 없으면 LLM은 매번 즉흥적으로 움직인다.

schema가 있으면 LLM은 반복 가능한 운영자로 바뀐다.

여기서 가장 많이 놓치는 층은 schema다.

사람들은 보통 raw와 wiki 폴더부터 만든다.

그리고 LLM에게 “정리해줘”라고 한다.

이러면 처음 몇 번은 멋지다.

그다음부터 파일명이 흔들리고, 태그가 늘어나고, 같은 개념 페이지가 둘로 갈라진다.

세컨드브레인은 똑똑해진 게 아니라 문서 양식이 풍성하게 망가진다.

웃기지만 꽤 흔한 엔딩이다.

raw sources를 먼저 둘 때

raw sources 폴더는 언제 필요한가.

기준은 간단하다.

원문과 해석을 분리해야 할 때다.

뉴스 클리핑 몇 개를 요약하는 수준이라면 raw 폴더가 없어도 버틸 수 있다.

하지만 논문, 리포트, 회의록, 블로그 원문, YouTube transcript, PDF가 섞이기 시작하면 raw가 필요하다.

특히 나중에 “이 주장 어디서 나왔지?”를 자주 묻는다면 raw는 필수에 가깝다.

raw sources의 목적은 예쁘게 정리하는 것이 아니다.

수정 불가능한 기준점을 남기는 것이다.

LLM이 만든 wiki가 틀렸을 때 돌아갈 곳이 있어야 한다.

그래서 raw 폴더에는 원문 URL, 수집일, 출처 유형, 라이선스나 접근 조건 같은 최소 메타데이터가 붙는 게 좋다.

이미지를 다루는 경우에는 이미지 파일도 로컬에 저장하는 편이 낫다.

Karpathy도 Obsidian에서 attachment folder를 고정하고 이미지를 로컬로 내려받는 팁을 언급한다.

다만 처음부터 모든 이미지를 완벽히 처리하려고 하면 작업이 커진다.

텍스트 중심 vault라면 이미지 처리는 나중으로 미뤄도 된다.

raw sources를 도입하는 신호는 세 가지다.

첫째, 같은 주제를 10개 이상 출처로 비교한다.

둘째, 글이나 의사결정에서 출처 추적이 중요하다.

셋째, LLM 요약이 틀렸을 때 원문으로 되돌아가야 한다.

반대로 raw 폴더가 아직 과한 경우도 있다.

단순 아이디어 메모가 대부분이면 raw보다 inbox 정리가 먼저다.

자료가 20개도 안 되는데 폴더 구조부터 세분화하면 관리 비용이 이긴다.

이럴 땐 /raw, /wiki, /schema 같은 이름만 먼저 만들고, 엄격한 운영은 나중에 붙여도 된다.

wiki를 붙일 때

wiki는 LLM이 작성하는 중간 산출물이다.

여기서 중요한 표현은 “중간”이다.

wiki는 raw source도 아니고 최종 블로그 글도 아니다.

원문을 읽은 뒤 앞으로 계속 재사용할 수 있게 만든 지식 층이다.

Obsidian 운영자라면 이 부분이 매력적이다.

내가 매번 다시 읽지 않아도 되는 개념 페이지가 생긴다.

비슷한 자료가 들어오면 기존 페이지가 갱신된다.

서로 충돌하는 주장도 표시할 수 있다.

하지만 wiki를 너무 빨리 붙이면 문제가 생긴다.

정리할 자료보다 정리 양식이 더 많아진다.

페이지는 늘어나는데 실제 질문은 줄어든다.

링크는 많아지는데 판단은 흐려진다.

이건 세컨드브레인 사용자라면 익숙한 함정이다.

노트를 많이 만들수록 똑똑해지는 느낌이 든다.

하지만 실제로는 청소할 방만 늘어난 경우가 많다.

wiki를 붙일 시점은 “같은 주제를 여러 번 다시 묻고 있다”는 신호가 나올 때다.

예를 들어 AI 에이전트 운영, 투자 리서치, 건강 추적, 독서 프로젝트처럼 시간이 지나며 누적되는 주제가 있다.

새 자료가 기존 판단을 바꾸는지 계속 봐야 한다.

이런 주제는 wiki가 잘 맞는다.

반대로 일회성 여행 계획, 단발성 제품 비교, 한 번 쓰고 끝날 글감은 wiki가 과할 수 있다.

물론 wiki가 있으면 멋지다.

하지만 멋진 시스템은 종종 내 시간을 천천히 먹는다.

특히 LLM이 만든 페이지를 사람이 검토하지 않으면 wiki는 빠르게 권위 있는 척하는 초안이 된다.

wiki는 정답 저장소가 아니라 갱신되는 작업물이다.

그 전제를 놓치면 위험하다.

schema가 없으면 생기는 일

schema는 LLM에게 주는 운영 계약이다.

어떤 폴더를 읽을지.

어떤 폴더를 수정할지.

파일명은 어떻게 만들지.

frontmatter는 어떤 필드를 쓸지.

새 source를 ingest하면 어떤 페이지를 반드시 갱신할지.

query 답변은 어디까지 wiki에 되돌려 저장할지.

lint는 무엇을 검사할지.

이걸 적어두는 문서가 schema다.

Karpathy는 Claude Code라면 CLAUDE.md, Codex라면 AGENTS.md 같은 파일을 예로 든다.

Obsidian 관점에서는 vault 운영 규칙 파일이라고 봐도 된다.

schema가 없을 때 생기는 문제는 매우 현실적이다.

LLM이 비슷한 개념을 서로 다른 이름으로 만든다.

한 번은 sources라고 쓰고 다음에는 references라고 쓴다.

요약 페이지에 출처가 빠진다.

개념 페이지가 너무 길어져도 분할 기준이 없다.

링크 스타일이 흔들린다.

업데이트 로그가 남지 않는다.

나중에 “이 파일 왜 생겼지?”라는 질문이 나온다.

그 순간 세컨드브레인은 다시 수동 청소 모드로 돌아간다.

schema를 너무 거창하게 만들 필요는 없다.

처음엔 1페이지면 충분하다.

수정 가능한 범위.

수정 금지 범위.

파일명 규칙.

링크 규칙.

ingest 절차.

query 절차.

lint 절차.

이 정도만 있어도 LLM의 행동이 꽤 달라진다.

좋은 schema는 LLM을 똑똑하게 만드는 파일이 아니다.

LLM이 같은 실수를 반복하지 않게 만드는 난간이다.

그리고 난간은 멋있으라고 있는 게 아니다.

떨어지지 말라고 있는 거다.

ingest 운영 기준

ingest는 새 source를 raw에 넣고 wiki를 갱신하는 작업이다.

Karpathy의 예시는 한 source가 summary page를 만들고, index를 갱신하고, 관련 entity와 concept page를 고치고, log에 기록되는 흐름이다.

심지어 한 source가 10개에서 15개 wiki page를 건드릴 수도 있다고 한다.

이 부분에서 바로 운영 판단이 필요하다.

LLM이 파일 여러 개를 만지는 건 강력하지만, 동시에 위험하다.

그래서 ingest는 처음부터 batch로 돌리지 않는 게 좋다.

처음 10개 source는 하나씩 처리하는 편이 낫다.

사용자는 요약을 읽고, 강조점을 잡아주고, 잘못된 연결을 고쳐야 한다.

이 과정을 통해 schema가 자란다.

처음부터 “이 폴더 전체 정리해줘”라고 하면 속도는 빠르다.

대신 잘못된 관습도 빠르게 퍼진다.

LLM Wiki에서 ingest는 수집 자동화가 아니다.

지식베이스에 새 변경사항을 merge하는 작업에 가깝다.

그래서 저는 ingest를 git commit처럼 보는 게 좋다고 생각한다.

source 하나가 들어오면 어떤 page가 바뀌었는지 확인한다.

index가 갱신됐는지 본다.

log가 남았는지 본다.

새로운 충돌이나 미해결 질문이 생겼는지 본다.

이렇게 하면 Obsidian vault가 조금 귀찮아진다.

하지만 그 귀찮음은 가치 있는 귀찮음이다.

정리되지 않은 자료 더미를 나중에 파내는 것보다 훨씬 싸다.

ingest를 도입할 시점은 분명하다.

새 자료가 들어올 때마다 기존 노트를 찾아 고치는 일이 반복된다면 ingest가 필요하다.

새 자료가 들어와도 그냥 읽고 끝난다면 ingest 자동화는 과하다.

query 운영 기준

query는 wiki에 질문하는 작업이다.

여기서 LLM은 raw source 전체를 다시 뒤지는 게 아니라 index와 관련 wiki page를 읽고 답한다.

답변에는 출처나 wiki page 링크가 붙어야 한다.

질문에 따라 답변 형식도 달라질 수 있다.

비교표가 될 수 있다.

새 markdown page가 될 수 있다.

발표 자료 초안이 될 수 있다.

차트가 될 수 있다.

중요한 건 좋은 query 결과를 다시 wiki에 저장할 수 있다는 점이다.

이게 LLM Wiki의 compounding 효과다.

질문해서 얻은 연결이 채팅창에서 사라지지 않는다.

다음 질문의 재료가 된다.

Obsidian 운영자는 이 부분을 적극적으로 설계해야 한다.

모든 query 결과를 저장하면 wiki가 금방 지저분해진다.

반대로 아무것도 저장하지 않으면 LLM Wiki의 장점이 줄어든다.

그래서 저장 기준이 필요하다.

새 개념을 만든 query는 저장한다.

기존 판단을 바꾸는 query는 저장한다.

비교표나 체크리스트처럼 재사용 가치가 있는 query는 저장한다.

단순 질의응답은 저장하지 않는다.

이 기준만 있어도 wiki가 훨씬 덜 비대해진다.

query를 도입할 시점도 명확하다.

내가 자주 묻는 질문이 반복될 때다.

예를 들어 “이 도구를 언제 써야 하지?”, “이 주장과 저 주장이 충돌하나?”, “이번 자료가 기존 전략을 바꾸나?” 같은 질문이다.

이 질문들이 반복되면 query 결과를 wiki로 되돌리는 구조가 필요하다.

단발성 답변만 원한다면 일반 챗봇이나 RAG가 더 가볍다.

모든 질문이 knowledge base에 남을 필요는 없다.

세컨드브레인에도 다이어트가 필요하다.

네, 지식도 살찐다.

lint 운영 기준

lint는 wiki 건강검진이다.

코드에서 lint가 문법과 스타일 문제를 잡듯, LLM Wiki의 lint는 지식베이스의 구조 문제를 잡는다.

Karpathy가 말한 lint 항목은 꽤 실용적이다.

페이지 간 모순.

새 source가 오래된 claim을 대체했는지 여부.

inbound link가 없는 orphan page.

중요한 개념인데 독립 page가 없는 항목.

빠진 cross-reference.

web search로 채울 수 있는 data gap.

Obsidian 사용자라면 이 목록이 익숙할 수 있다.

왜냐면 대부분 “언젠가 정리해야지” 하고 미뤄둔 것들이기 때문이다.

LLM Wiki에서 lint는 선택 기능처럼 보이지만 사실 핵심 운영 기능이다.

ingest와 query만 있으면 wiki는 커진다.

lint가 있어야 wiki가 견딘다.

특히 100개 source, 수백 개 page 수준으로 가면 index.md만으로도 어느 정도 버틸 수 있지만, 구조적 부채는 반드시 생긴다.

그때 lint가 없으면 LLM도 헷갈린다.

사용자도 헷갈린다.

둘이 같이 헷갈리면 꽤 자신감 있는 엉뚱한 결론이 나온다.

이게 제일 무섭다.

lint는 매일 돌릴 필요 없다.

처음에는 주 1회 또는 큰 ingest 후에만 돌려도 충분하다.

글 발행 전.

프로젝트 마감 전.

새 source 10개 이상 ingest 후.

index 구조를 바꾼 후.

이런 시점에 lint를 돌리면 된다.

lint 결과는 단순 보고서로 끝내지 말고 action으로 바꿔야 한다.

merge할 page.

삭제 후보 page.

새로 만들 concept page.

출처 확인이 필요한 claim.

다음 리서치 질문.

이렇게 나와야 운영에 도움이 된다.

index.md와 log.md

Karpathy가 제안한 특별 파일 두 개는 index.md와 log.md다.

이 두 파일은 작지만 중요하다.

index.md는 내용 중심 지도다.

wiki 안에 어떤 page가 있는지 보여준다.

각 page의 링크, 한 줄 요약, 날짜, source count 같은 정보를 담을 수 있다.

LLM이 query를 처리할 때 index를 먼저 읽고 관련 page로 들어가면 꽤 잘 작동한다.

Karpathy는 중간 규모, 예를 들면 source 100개와 수백 page 수준에서는 index만으로도 embedding 기반 RAG 인프라 없이 꽤 괜찮게 작동한다고 본다.

이건 Obsidian 운영자에게 좋은 소식이다.

처음부터 vector DB를 붙이지 않아도 된다.

처음부터 knowledge graph 서버를 세우지 않아도 된다.

처음부터 MCP가 없어도 된다.

index.md 하나를 잘 유지하는 것이 더 중요할 수 있다.

log.md는 시간 중심 기록이다.

어떤 source를 언제 ingest했는지.

어떤 query를 했는지.

어떤 lint를 돌렸는지.

무엇이 바뀌었는지.

이 흐름을 append-only로 남긴다.

log는 단순 기록이 아니다.

LLM이 “최근에 뭐 했지?”를 이해하는 발판이다.

사람에게도 유용하다.

며칠 뒤에 돌아와서 “왜 이 페이지가 이렇게 바뀌었지?”라고 물을 때 log가 답해준다.

Karpathy는 log entry prefix를 일정하게 만들면 grep 같은 unix 도구로도 최근 작업을 뽑을 수 있다고 언급한다.

이건 작지만 운영적으로 중요하다.

LLM Wiki가 커질수록 fancy UI보다 parseable convention이 이긴다.

index는 현재 지도다.

log는 변화 기록이다.

둘 중 하나만 고르라면 처음에는 log를 먼저 두는 것도 괜찮다.

변경 이유가 남아야 나중에 고칠 수 있기 때문이다.

Obsidian에 붙이는 최소 구조

처음부터 거창한 플러그인 스택을 만들 필요는 없다.

Obsidian vault 안에 작은 실험 구역을 만들면 된다.

예를 들면 이런 구조다.

llm-wiki/
  raw/
    sources/
    assets/
  wiki/
    index.md
    log.md
    concepts/
    entities/
    syntheses/
  schema/
    AGENTS.md
    page-conventions.md

이 구조는 정답이 아니다.

하지만 역할 분리가 보인다.

raw는 원문이다.

wiki는 LLM이 관리하는 결과물이다.

schema는 작업 규칙이다.

Obsidian에서 이 구조를 쓸 때 중요한 건 no-focus 운영이다.

AI가 파일을 만들고 수정할 수는 있지만, Obsidian 앱 포커스를 불필요하게 뺏을 필요는 없다.

direct file write와 git diff 확인이 더 안정적이다.

이미 Obsidian을 PARA로 운영한다면 기존 vault 전체를 LLM Wiki로 바꾸려고 하지 않는 게 좋다.

작은 프로젝트 하나만 떼어내라.

예를 들면 “AI 에이전트 운영 리서치” 같은 주제다.

raw에 공식 문서와 글을 넣는다.

wiki에 concept page를 만든다.

schema에 ingest 규칙을 적는다.

log에 모든 변경을 남긴다.

이렇게 2주만 굴려보면 알 수 있다.

내가 이 방식을 계속 쓸 사람인지.

아니면 그냥 검색 잘 되는 inbox가 필요한 사람인지.

둘 다 괜찮다.

도구 선택에서 제일 비싼 건 잘못된 자존심이다.

도입 분기표

아래 표는 Obsidian 세컨드브레인 운영자가 LLM Wiki를 어디까지 붙일지 고르는 기준이다.

완전한 정답표가 아니라, 운영 리스크를 줄이는 출발점으로 보면 된다.

상황	먼저 할 일	아직 하지 말 일	이유
source 20개 미만	inbox와 기본 태그 정리	graph, batch ingest	구조보다 습관 확인이 먼저
source 50개 이상	raw와 wiki 분리	전체 vault 자동 수정	원문과 해석이 섞이면 복구가 어렵다
반복 질문이 많음	query 결과 저장 기준 만들기	모든 답변 자동 저장	wiki 비대화 방지
개념 충돌이 잦음	lint 체크리스트 도입	새 자료만 계속 추가	오래된 claim이 위험해진다
팀 wiki 운영	schema와 review flow 작성	LLM 단독 merge	책임 경계가 필요하다
블로그 리서치 운영	source별 ingest와 log	출처 없는 synthesis	발행 전 검증이 중요하다
1회성 프로젝트	markdown summary만 작성	persistent wiki 구축	운영 비용이 이득보다 클 수 있다
수백 page 이상	index 보강과 검색 도구 검토	index 없이 대화로만 탐색	탐색 비용이 커진다

실무적으로는 3단계로 나누면 편하다.

1단계는 raw와 log만 둔다.

원문을 저장하고 어떤 처리를 했는지만 남긴다.

2단계는 wiki와 index를 붙인다.

반복되는 개념과 비교표를 markdown page로 축적한다.

3단계는 schema와 lint를 강화한다.

LLM이 반복 가능한 운영자가 되도록 규칙과 건강검진을 붙인다.

대부분은 2단계에서 오래 머문다.

그게 정상이다.

모든 개인 vault가 팀 지식베이스처럼 될 필요는 없다.

Graphify는 어디에 놓을까

Graphify는 이 글에서 필수 도구가 아니다.

예시로만 보는 게 맞다.

Graphify 공식 사이트는 이 도구를 AI coding assistant를 위한 open-source knowledge graph skill로 설명한다.

코드, 문서, 논문, 다이어그램에서 queryable knowledge graph를 만들고, graph.html, graph.json, GRAPH_REPORT.md 같은 결과물을 내세운다.

또 /graphify, /graphify query, /graphify path, /graphify explain 같은 흐름을 강조한다.

이건 LLM Wiki와 잘 어울릴 수 있다.

특히 codebase, 논문, 다이어그램이 섞인 프로젝트에서 구조적 연결을 보고 싶을 때 도움이 될 수 있다.

하지만 Obsidian 세컨드브레인 운영자가 반드시 Graphify를 써야 하는 건 아니다.

처음부터 graph를 붙이면 운영 난도가 올라간다.

내 wiki page 이름도 안정되지 않았는데 graph.html부터 보면 예쁘게 복잡해진다.

예쁜 복잡함은 사람을 설득한다.

문제는 일을 해결하진 않을 때가 많다는 점이다.

Graphify를 검토할 시점은 이렇다.

첫째, wiki가 수백 page 이상으로 커졌다.

둘째, index만으로 연결 구조를 파악하기 어렵다.

셋째, 코드와 문서와 diagram이 섞여 있다.

넷째, “A와 B 사이 경로를 설명해줘” 같은 path query가 실제 업무에 필요하다.

다섯째, graph 결과물을 사람이 검토할 시간이 있다.

반대로 단순 개인 독서노트나 블로그 글감 정리에는 과할 수 있다.

Graphify는 LLM Wiki의 출발점이 아니라 확장 옵션이다.

먼저 markdown wiki가 굴러가야 graph도 의미가 있다.

지도는 도시가 있어야 쓸모 있다.

빈 땅에 지도부터 그리면 멋진 판타지 설정집이 된다.

운영 체크리스트

LLM Wiki를 Obsidian에 붙이기 전에 아래 질문에 답해보면 된다.

raw source와 LLM 작성 wiki를 폴더로 분리했나?
LLM이 절대 수정하면 안 되는 경로를 정했나?
ingest가 끝나면 index.md가 갱신되나?
ingest가 끝나면 log.md가 append-only로 남나?
query 결과 중 어떤 것을 wiki page로 저장할지 기준이 있나?
lint가 볼 항목을 5개 이상 정했나?
출처 없는 claim을 어떻게 표시할지 정했나?
오래된 claim을 superseded로 표시할 방법이 있나?
Obsidian graph view에서 orphan page를 볼 루틴이 있나?
git diff나 백업으로 LLM 변경을 되돌릴 수 있나?
batch ingest 전에 source 5개 이하로 수동 검토를 해봤나?
wiki page가 최종 사실이 아니라 운영 중인 synthesis라는 점을 표시했나?

이 체크리스트에서 6개 이상 “아니오”라면 아직 전체 도입은 이르다.

그래도 실험은 가능하다.

단, 실험 구역을 분리해라.

내 전체 vault를 실험대에 올리지 마라.

Obsidian vault는 생각보다 개인적이다.

몇 년치 메모를 한 번에 자동 정리하겠다는 마음은 이해하지만, 그건 토요일 오전에 냉장고 청소하다가 집 전체 리모델링 시작하는 흐름과 비슷하다.

처음엔 선반 하나만 하자.

제발 선반 하나만.

실패 패턴

첫 번째 실패 패턴은 raw 없이 wiki부터 만드는 것이다.

이러면 출처와 해석이 섞인다.

나중에 LLM 요약이 틀렸을 때 원문으로 돌아가기 어렵다.

두 번째 실패 패턴은 schema 없이 LLM에게 정리만 맡기는 것이다.

처음에는 잘한다.

세 번째 실행부터 스타일이 흔들린다.

다섯 번째 실행부터 폴더 안에 비슷한 파일이 늘어난다.

세 번째 실패 패턴은 모든 query를 저장하는 것이다.

질문 하나마다 page가 생기면 wiki가 대화 찌꺼기 저장소가 된다.

저장 기준이 없으면 query는 자산이 아니라 먼지가 된다.

네 번째 실패 패턴은 lint를 미루는 것이다.

wiki는 늘어나는 속도보다 정합성을 잃는 속도가 더 무서울 때가 있다.

특히 AI가 많이 도와줄수록 사람이 안심하고 확인을 덜 한다.

그 순간 오래된 claim이 새 page에서 다시 살아난다.

다섯 번째 실패 패턴은 graph부터 붙이는 것이다.

Graphify든 다른 graph 도구든 구조를 시각화하는 건 매력적이다.

하지만 page naming, index, log가 불안정하면 graph는 문제를 예쁘게 보여줄 뿐이다.

예쁘게 보이는 문제는 은근히 해결된 것처럼 느껴진다.

이 착각이 제일 비싸다.

여섯 번째 실패 패턴은 LLM Wiki를 “자동 지식관리”로 이해하는 것이다.

정확히는 “반자동 유지보수”에 가깝다.

사람은 source를 고르고 방향을 정한다.

LLM은 요약, 연결, 갱신, bookkeeping을 맡는다.

사람이 빠지면 품질 기준도 빠진다.

LLM Wiki는 사람을 대체하는 뇌가 아니다.

사람이 귀찮아하던 관리 근육을 빌려주는 외골격에 가깝다.

블로그 운영자에게 주는 의미

TECHTAEK 같은 기술 블로그 운영자에게 LLM Wiki는 특히 유용할 수 있다.

이유는 글감이 단발로 끝나지 않기 때문이다.

OpenAI Agents SDK를 쓰다가 Cloudflare AI Platform으로 이어지고, Claude Code routines를 보다가 Obsidian 운영으로 이어진다.

주제들이 서로 연결된다.

새 공식 문서가 나오면 기존 글의 판단도 조금씩 바뀐다.

이때 raw source와 wiki가 분리되어 있으면 글쓰기 품질이 좋아진다.

원문 출처는 raw에 남긴다.

운영 판단은 wiki에 쌓는다.

발행 글은 별도 output으로 뺀다.

이렇게 하면 블로그 글이 단순 요약에서 벗어난다.

매번 “공식 문서에 뭐가 나왔나”를 반복하는 게 아니라, “내 운영 기준에서 이 변화는 어디에 붙나”를 쓸 수 있다.

이 글의 주제도 그렇다.

Karpathy gist를 그대로 요약하면 좋은 글이 아니다.

중요한 건 Obsidian 사용자가 오늘 무엇을 바꿔야 하는지다.

raw를 만들지.

wiki를 만들지.

schema를 쓸지.

ingest를 자동화할지.

query 결과를 저장할지.

lint를 주간 루틴으로 둘지.

이 판단이 독자에게 남아야 한다.

그래서 LLM Wiki는 블로그 파이프라인에도 맞다.

다만 “모든 글감을 wiki로 만들자”는 식으로 가면 다시 과해진다.

글감 중에서도 반복되는 hub 주제만 wiki로 만들면 된다.

예를 들면 AI agent 운영, Obsidian 자동화, LLM cost control, API security 같은 축이다.

나머지는 inbox와 draft로 충분하다.

FAQ

Karpathy LLM Wiki는 RAG를 대체하나?

완전한 대체라기보다 역할이 다르다.

RAG는 질문 시점에 원문에서 관련 조각을 찾는 데 강하다.

LLM Wiki는 원문을 읽은 뒤 persistent markdown wiki를 계속 갱신하는 데 초점이 있다.

검색이 문제라면 RAG나 markdown search가 먼저일 수 있다.

지식의 축적, 충돌 관리, cross-reference 유지가 문제라면 LLM Wiki가 더 잘 맞는다.

Obsidian 초보도 바로 도입해도 되나?

작은 실험은 가능하다.

하지만 전체 vault에 바로 붙이는 건 추천하지 않는다.

먼저 raw, wiki, schema를 분리한 작은 프로젝트 하나로 시작하는 게 낫다.

Obsidian 기본 링크, 폴더, frontmatter, graph view에 익숙해진 뒤 도입하면 실패 비용이 줄어든다.

schema는 꼭 AGENTS.md나 CLAUDE.md여야 하나?

아니다.

핵심은 파일명이 아니라 역할이다.

LLM이 읽고 따를 수 있는 운영 규칙이면 된다.

Codex를 쓴다면 AGENTS.md가 자연스럽고, Claude Code를 쓴다면 CLAUDE.md가 자연스럽다.

일반 Obsidian 운영에서는 schema/wiki-rules.md 같은 이름도 충분하다.

index.md와 log.md 중 뭐부터 만들어야 하나?

처음에는 둘 다 작게 만드는 게 좋다.

굳이 하나만 고르면 log.md를 먼저 추천한다.

변경 기록이 남아야 나중에 무엇이 왜 바뀌었는지 추적할 수 있기 때문이다.

그다음 index.md를 만들어 LLM과 사람이 현재 wiki 구조를 빠르게 훑게 하면 된다.

Graphify를 같이 써야 하나?

필수는 아니다.

Graphify는 AI coding assistant를 위한 knowledge graph skill 예시로 볼 수 있다.

graph.html, graph.json, GRAPH_REPORT.md 같은 산출물과 query, path, explain 흐름은 매력적이다.

하지만 개인 Obsidian vault에서는 markdown wiki, index, log, lint가 먼저다.

Graphify는 구조가 커지고 path query가 실제로 필요해진 뒤 검토해도 늦지 않다.

LLM이 wiki를 전부 작성하게 두면 위험하지 않나?

위험할 수 있다.

그래서 raw source는 수정 금지로 두고, wiki는 LLM 작성 영역으로 분리하고, schema로 수정 규칙을 제한해야 한다.

그리고 log와 git diff로 변경을 추적해야 한다.

LLM Wiki의 핵심은 무제한 자동화가 아니라 검토 가능한 반자동 유지보수다.

몇 개 source부터 LLM Wiki가 의미 있나?

정확한 숫자는 없다.

다만 source 20개 미만이면 inbox와 summary만으로도 충분한 경우가 많다.

source가 50개 이상이고 같은 주제의 반복 질문이 생기면 raw와 wiki 분리를 고려할 만하다.

source 100개, wiki 수백 page 수준으로 가면 index, log, lint의 가치가 확 올라간다.

블로그 글감 관리에도 쓸 수 있나?

쓸 수 있다.

특히 반복되는 hub 주제에는 잘 맞는다.

AI agent 운영, Obsidian 자동화, LLM 비용 관리, 보안 체크리스트처럼 계속 갱신되는 주제는 wiki화할 가치가 있다.

단발성 뉴스 요약은 굳이 wiki로 만들지 않아도 된다.

LLM Wiki를 시작할 때 제일 먼저 정할 것은 무엇인가?

수정 금지 구역과 수정 가능 구역이다.

raw sources는 원문이므로 LLM이 수정하지 않게 둔다.

wiki는 LLM이 작성하고 갱신할 수 있게 둔다.

schema는 둘 사이의 규칙으로 둔다.

이 경계가 없으면 자동화가 편해지는 만큼 복구가 어려워진다.

공식 출처

Karpathy LLM Wiki gist: persistent markdown wiki, raw sources, wiki, schema, ingest, query, lint, index.md, log.md, Obsidian as IDE 관점의 원문 아이디어.
Graphify 공식 사이트: AI coding assistants를 위한 open-source knowledge graph skill 설명, graph.html, graph.json, GRAPH_REPORT.md, /graphify query/path/explain 흐름 확인.

결론

Karpathy LLM Wiki를 Obsidian 세컨드브레인에 붙일 만한 시점은 노트가 많아졌을 때가 아니다.

새 자료가 들어올 때마다 기존 판단, 개념, 링크, 출처, 로그를 갱신해야 하는 순간이다.

그때 raw sources는 기준점이 된다.

wiki는 누적되는 해석이 된다.

schema는 LLM의 작업 계약이 된다.

ingest는 새 자료를 merge하는 루틴이 된다.

query는 질문을 자산으로 바꾸는 통로가 된다.

lint는 지식베이스가 낡지 않게 보는 건강검진이 된다.

처음부터 전부 붙이지 않아도 된다.

작은 raw 폴더, 짧은 index.md, append-only log.md, 1페이지 schema, source 3개로 충분하다.

그 작은 실험이 2주 뒤에도 계속 돌아가면 그때 확장하면 된다.

반대로 2주 뒤에 손이 안 간다면 멋진 graph보다 가벼운 inbox가 맞는 사람일 수 있다.

LLM Wiki의 진짜 매력은 “AI가 내 지식을 다 관리해준다”가 아니다.

내가 생각할 시간을 남기기 위해, LLM에게 반복되는 bookkeeping을 맡기는 것이다.

Obsidian 세컨드브레인은 결국 내 판단을 위해 존재한다.

LLM Wiki도 마찬가지다.

도구가 똑똑해지는 것보다 중요한 건, 내가 다시 꺼내 쓸 수 있는 판단이 남는 것이다.

Karpathy LLM Wiki는 Obsidian 세컨드브레인에 언제 붙일 만한가 2026 — raw·wiki·schema·lint 분기표