지식을 어떻게 쌓고 관리하나

왜 "LLM이 읽을 수 있는 위키"인가

Karpathy는 2025년에 이렇게 말했습니다.

앞으로 내 글·노트를 읽는 쪽은 점점 사람이 아니라 AI가 된다는 뜻입니다. 그러니 내 지식을 검색·요약·AI 비서의 연료로 쓰려면, 사람만 보기 좋은 예쁜 문서(PDF·이미지·특정 앱 전용 포맷)가 아니라 LLM이 그대로 먹을 수 있는 형식 — 즉 plain markdown(일반 텍스트 노트)으로 쌓아야 유리합니다. 이것이 "LLM wiki" 발상의 출발점이에요.

왜 하필 마크다운인가 — AI가 읽기 좋은 5가지 이유

"plain markdown으로 쌓아라"는 말은 자주 듣지만, 왜 하필 마크다운이어야 하는지는 잘 안 알려줍니다. 여기서 그 이유를 처음부터 풀어볼게요. 이 절만 이해하면 LLM wiki의 절반은 잡은 셈입니다.

마크다운(Markdown)은 그냥 글자(텍스트)입니다. 거기에 약속된 기호 몇 개만 더한 거예요. 워드처럼 버튼을 눌러 굵게·제목을 만드는 게 아니라, 기호로 직접 표시합니다.

LLM(AI 언어모델)은 글을 통째로 보는 게 아니라, 토큰(token)이라는 작은 글자 조각으로 잘라서 읽습니다. 그리고 그 입력은 결국 순수한 텍스트(글자)예요 — 그림도 표도, LLM 앞에서는 일단 글자로 바뀌어야 읽힙니다. 이 한 가지 사실이 아래 다섯 이유의 뿌리입니다.

마크다운은 처음부터 글자라, LLM이 그대로 바로 먹습니다. 반면 PDF·이미지·한글(.hwp)·워드 파일은 LLM이 읽기 전에 "글자만 뽑아내는 변환"을 먼저 거쳐야 해요. 그 변환에서 표가 뭉개지고 줄바꿈·순서가 깨지는 일이 흔합니다.

사람은 큰 글씨·굵은 글씨를 보고 "아, 이게 제목이구나" 압니다. 그런데 LLM은 글씨 크기를 못 봐요 — 글자만 봅니다. 마크다운은 그 구조를 기호로 적어두기 때문에, LLM이 #를 보고 "제목", -를 보고 "목록 항목"이라고 글자만으로 문서의 뼈대(위계)를 파악합니다.

같은 "제목" 하나도 형식에 따라 글자 수가 확 다릅니다.

LLM이 한 번에 읽을 수 있는 양(토큰)은 정해져 있고, 토큰은 곧 비용이기도 합니다. 마크다운은 군더더기 태그가 없어 같은 내용을 더 적은 토큰에 담아요 → 한 번에 더 많은 지식을, 더 싸게 읽힐 수 있습니다.

LLM은 인터넷의 방대한 글로 학습했는데, 그중 마크다운으로 쓰인 글이 아주 많습니다 — 개발자 설명서(README), 위키, 기술 문서 상당수가 마크다운이거든요. 그래서 LLM에게 마크다운은 읽기도 쓰기도 자연스러운, 손에 익은 형식입니다.

마크다운에서 노트끼리의 연결([[노트이름]])도 그냥 글자입니다. 그래서 LLM이 "이 노트가 저 노트와 이어져 있다"를 읽는 즉시 압니다 — 그리고 이 연결망이 바로 Part 2의 지식 그래프(검색의 재료)가 됩니다. 또 텍스트라서 한 줄을 고치면 딱 그 한 줄만 달라져, "무엇이 언제 바뀌었는지" 추적(버전 관리)도 쉽습니다.

근거: microsoft/markitdown · Anthropic "Use XML tags" · The Stack(BigCode)·Common Crawl · Cloudflare "Markdown for Agents"(토큰 측정 사례) — 코난 1차/권위 출처 검증(2026-06-08). 토큰 절감 구체 수치는 콘텐츠마다 편차가 커 범위로만 봅니다.

왜 하필 옵시디언인가 — AI의 모국어로 쌓기

마크다운이 "AI가 읽기 좋은 형식"이라면, 옵시디언은 그 마크다운을 가장 잘 다루는 도구입니다. 단순한 메모장이 아니에요 — 노트를 쓰는 것만으로 AI가 이해하기 좋은 구조가 자연스럽게 만들어집니다. 비결은 셋이에요: 프론트매터 · 위키링크 · 그래프.

프론트매터(front matter)는 노트 맨 위에 --- 두 줄 사이에 적는 짧은 메타데이터(머리말 정보)입니다. 제목·태그·날짜처럼 "이 노트가 무엇인지"를 정해진 칸에 적어 두는 거예요.

왜 AI에 좋을까요? AI나 검색 시스템이 본문 전체를 읽지 않고도 머리말만 훑어 분류·필터·검색할 수 있기 때문입니다. 수백 개 노트 중 "AI 태그가 달린, 올해 노트"를 골라내는 일이 한순간이 돼요.

옵시디언에선 [[노트이름]]이라고 쓰면 그 노트로 가는 링크가 됩니다(앞 절에서 본 그 기호예요). 폴더 경로를 외울 필요 없이 이름만으로 노트와 노트를 잇죠.

위키링크로 이어진 노트들을, 옵시디언은 점(노트)과 선(링크)으로 그린 그래프로 보여줍니다. 내 지식 전체가 한 장의 지도로 펼쳐지는 거예요. 그리고 결정적으로 — 이 연결망이 그대로 Part 2의 "지식 그래프(GraphRAG)" 재료가 됩니다. 내가 노트를 이어 둔 방식이, 나중에 검색이 똑똑해지는 바탕이 돼요.

근거: 프론트매터·위키링크·그래프 뷰의 기능 정의 = 옵시디언 공식 문서(help.obsidian.md) · "AI·검색에 유리"는 앞 절의 마크다운 특성에서 유도한 평가 · "X-ray" 비유는 이해를 돕기 위한 설명으로 특정 인물의 출처는 아닙니다 — 코난 공식/1차 출처 검증(2026-06-08).

Andrej Karpathy의 "LLM wiki" — 실제로 어떻게 도는가

OpenAI 창립 멤버·전 Tesla AI 디렉터. 2026년 개인 지식관리 방법 "LLM Knowledge Base / LLM wiki"를 공개해 큰 반향을 일으켰고, "LLM wiki"라는 말이 퍼진 진원지입니다.

발상은 단순합니다 — "코드를 다루는 데 쓰던 AI를, 이제 지식을 다루는 데 쓴다."

그가 공개한 설계(본인 gist llm-wiki.md)는 세 층으로 나뉩니다.

1. raw/ (원자료 · 불변) — 내가 모은 원본(논문·기사 등). "immutable — the LLM reads from them but never modifies them. This is your source of truth." 고치지 않고 추가만 하는 단일 진실 원천.
2. wiki/ (LLM이 소유) — LLM이 만든 마크다운 페이지들(요약·개념·비교). "The LLM owns this layer entirely."
3. schema (규약) = CLAUDE.md / AGENTS.md — LLM에게 "위키가 어떻게 구성되고, 규칙·작업방식이 무엇인지" 알려주는 설정 문서. 그의 표현으로 "what makes the LLM a disciplined wiki maintainer rather than a generic chatbot. You and the LLM co-evolve this over time." → LLM을 규율 있는 위키 관리자로 만드는 핵심. 사람과 LLM이 함께 다듬어 갑니다.

1. Ingest(수집·편입) — 원본 1개를 raw에 넣고 "처리해줘"라고 하면, LLM이 읽고 → 핵심을 나와 상의 → 요약 페이지 작성 → 색인(index) 갱신 → 관련 개념·인물 페이지 갱신 → 로그(log)에 기록. 그의 말로 "A single source might touch 10-15 wiki pages." (소스 하나가 10~15개 페이지를 건드림.)
2. Query(질문) — 위키에 물으면 LLM이 관련 페이지를 찾아 출처와 함께 답함. 핵심은 "good answers can be filed back into the wiki as new pages... your explorations compound." 좋은 답을 다시 위키로 보관하니, 탐색이 채팅에서 증발하지 않고 복리처럼 쌓입니다.
3. Lint(점검) — 주기적 건강검진. "contradictions between pages, stale claims, orphan pages with no inbound links, important concepts lacking their own page, missing cross-references, data gaps." (모순·낡은 주장·고아 페이지·빠진 개념·끊긴 참조·빈틈 찾기.)

출처(1차): gist · llm-wiki.md · 트윗(지식 다루기) · 트윗(context engineering). 위키 규모 "~100글·40만 단어"는 2차 보도 기준.

Karpathy 패턴 ↔ 우리 시스템 (그대로 대응)

우리 옵시디언 vault·봇 시스템은 Karpathy의 LLM wiki와 거의 1:1로 대응합니다. 이 표 하나가 Part 1 → Part 2 → Part 3 전체를 꿰어요.

노트 방법론 지도 — 따라 할 수 있는 실전 how-to

Karpathy만 그런 게 아닙니다. "내 지식을 일반 텍스트로, 내가 소유하며, 연결해서 쌓는다"는 흐름은 여러 갈래로 이미 있었어요. 각각 바로 따라 할 수 있게 정리했습니다.

1. 형식부터 개방형으로 — 노트를 .md·.txt로. 앱 전용·클라우드 종속 포맷 회피(앱이 사라져도 메모장으로 열림).
2. 로컬 소유 + 동기화는 보조 — vault를 내 컴퓨터 폴더에(예 ~/Documents/vault/).
3. 폴더는 최소·평평하게 — 깊은 계층 대신 최상위에 노트, 폴더는 소수만.
4. 경로 대신 링크로 — [[노트이름]] + 빠른 전환(Cmd/Ctrl+O).
5. 정기 재방문 — 일·월·연 리뷰로 과거 아이디어 재연결.

LYT(Linking Your Thinking)의 핵심 도구 MOC = 관련 노트로 가는 링크를 사람이 직접 큐레이션한 지도 노트.

1. "정신적 압박점" 감지 — "한 주제에 아는 건 많은데 정리가 안 돼" 느낌이 MOC 만들 신호(밀로의 용어).
2. 관련 노트 모으기 — 검색·태그로 목록화(15~30개 모이면 적기).
3. 허브 노트 신설 — 예 MOC_프로젝트관리.md, 맨 위 한 문장 설명.
4. 카테고리별 정렬 — ## 핵심 개념 / ## 도구 / ## 사례로 묶어 링크 나열.
5. 비파괴 오버레이 — 원본 노트는 그대로, MOC는 위에 얹는 지도. 새 노트 생기면 갱신.

기준은 "주제"가 아니라 "지금 얼마나 실행에 쓰이나"입니다.

결정 규칙: 마감 있나?→P / 끝없는 책임?→A / 지금은 아니지만 나중에?→R / 더 안 씀?→Archive.

이 방식의 뿌리는 독일 사회학자 Niklas Luhmann(1927–1998)의 Zettelkasten(쪽지 상자) — 평생 약 9만 장의 카드를 1장 = 1아이디어로 적고 서로 연결해 방대한 저술을 남긴 노트법입니다. Matuschak의 Evergreen은 그 현대판이에요.

그의 실제 노트 제목 그대로(verbatim):

터미널에서 LLM을 부르는 그의 도구 llm 실사용 예:

그리고 TIL(Today I Learned) — 매일 배운 작은 걸 짧게 공개 기록("미래의 내가 다시 검색 안 하도록"). 자기 위한 기록인데 부수효과로 남에게도 도움이 됩니다.

출처: stephango.com · linkingyourthinking.com · fortelabs.com · notes.andymatuschak.org · llm.datasette.io

우리 옵시디언 vault — 다섯을 합친 한국어 실천판

위 방법들을 한데 합친 게 우리 옵시디언 vault입니다. 큰 폴더는 역할로 나뉩니다(주제가 아니라 — Forte의 PARA 정신).

노트 사이는 [[위키링크]]로 잇습니다(Milo의 연결). 자주 찾는 주제는 MOC(지도 노트)로 묶고(Milo), 노트는 가능한 한 원자적으로 쪼갭니다(Matuschak). 전부 plain markdown — 우리가 소유하고(kepano), AI가 그대로 읽습니다(Karpathy).

"폴더를 어떻게 짜야 하나?"엔 정답이 없습니다. 유명한 세 방식을 비교해 보면, 뿌리는 같고 취향만 다릅니다.

우리 vault는 재경 방식(숫자 prefix로 역할 고정)에 가깝지만, 어느 쪽이든 plain markdown + 위키링크라는 뿌리는 같아요. 처음엔 아무거나 하나 골라 시작하고, 쓰면서 내 손에 맞게 바꾸면 됩니다.

knowledge-manager — 흩어진 자료를 LLM wiki로

노트를 처음부터 다 손으로 쓰는 건 무리예요. 우리 자료는 이미 여기저기 흩어져 있죠 — PDF 보고서, 워드 문서, 노션 페이지, 메신저 대화, 웹 기사. 이걸 한 번에 LLM wiki로 빨아들이는 도구가 우리 knowledge-manager(지식 관리자)입니다.

누구나 겪는 일이죠. 중요한 자료는 분명 어딘가 있는데, PDF는 다운로드 폴더에, 회의록은 노션에, 링크는 메신저에 흩어져 찾질 못합니다. AI에게 물어봐도, 그 자료가 AI가 읽을 수 있는 형태로 한곳에 모여 있지 않으면 소용없어요.

한 줄 명령(/knowledge-manager)을 주면, 안에서 다섯 단계가 차례로 돕니다.

1. 수집(Collect) — 자료를 가져옵니다(PDF·웹·노션 등).
2. 분석(Analyze) — 무슨 내용인지, 핵심이 무엇인지 파악합니다.
3. 변환(Convert) — AI가 읽기 좋은 마크다운으로 바꿉니다(앞 절의 그 형식!).
4. 저장(Store) — 프론트매터(이름표)를 달아 vault 알맞은 폴더에 저장합니다.
5. 연결(Link) — 관련 노트와 [[위키링크]]로 잇고, 필요하면 MOC(지도 노트)에 등록합니다.

자료 종류마다 꺼내는 방법이 달라요. 웹 기사는 본문만 긁어오고, PDF는 글자를 떠내는 여러 단계를 거치고, 노션·메신저는 또 각자의 방식이 있죠. knowledge-manager는 입력이 무엇인지 감지해 알맞은 추출 경로로 자동 분기합니다 — 사용자는 "이거 넣어줘"만 하면 됩니다.

회사 자료를 다룬다면 경계가 중요합니다. 기밀 문서·고객 정보를 외부 AI 서비스에 함부로 올리면 안 되죠.

오늘 바로 시작하기 — 5단계

거창할 필요 없어요. 오늘 한 폴더부터가 당신의 LLM wiki 첫걸음입니다.

1. Obsidian 설치(무료) → vault 폴더 하나 생성.
2. PARA 폴더 4개(Projects/Areas/Resources/Archives) + 임시 Inbox (Forte).
3. 영역마다 MOC 1개(예 MOC_AI학습.md) — 관련 노트를 모아 지도로 (Milo).
4. 마크다운 + [[위키링크]]로 노트 작성, 한 노트 한 개념 (kepano·Matuschak).
5. LLM 연동(LLM wiki化) — raw/에 원자료를 넣고 Claude Code/Codex에 "이 소스 읽고 요약 페이지 + 색인 갱신"(=Ingest) → "쌓인 노트 종합해줘"(=Query). 규약은 CLAUDE.md로 (Karpathy).

한국에서는 — 그리고 이 강의

이게 먼 나라 이야기 같나요? 한국에서도 이미 일어나고 있습니다(아래는 직접 확인한 출처만).

※ 검증되지 않은 한국어 URL은 일부러 싣지 않았습니다(가짜 출처 박제 방지 — 코난 리서치 원칙).