<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel>
<atom:link href="https://jisan.cmdspace.work/feed.xml" rel="self" type="application/rss+xml"/>
<atom:link href="https://pubsubhubbub.appspot.com/" rel="hub"/>
<title>紙散 · 지산</title>
<link>https://jisan.cmdspace.work</link>
<description>구요한(Yohan Koo)의 저자 블로그. 지식관리, AI 시대의 기록, 프레임워크와 에세이의 인용 정본.</description>
<language>ko</language>
<item>
<title>0.25점이 모자란 성적표</title>
<link>https://jisan.cmdspace.work/posts/quarter-point-short/</link>
<guid isPermaLink="true">https://jisan.cmdspace.work/posts/quarter-point-short/</guid>
<pubDate>Sat, 22 Aug 2026 00:00:00 GMT</pubDate>
<category>에세이</category>
<description>네 번째 자기 평가는 M4 문턱에서 0.25점이 모자랐다. 깎인 점수의 뿌리는 전부 한 곳 — 장치가 낸 신호를 소비하는 마지막 한 단, 즉 나였다. 대신 이번에는 처음으로 장점 목록을 읽었다. 옵시디언 볼트가 이미 잘하고 있는 것들, 그리고 남의 성적표 마흔 장이 가르쳐 준 신뢰의 화폐에 대하여.</description>
<content:encoded><![CDATA[<p>오늘 <a href="https://akm.cmdspace.work/report.html?id=cmds-2026-08">네 번째 성적표</a>를 받았다. 80.75점. 다음 등급인 M4의 문턱은 81점이다.</p>
<p><strong>0.25점이 모자랐다.</strong></p>
<p>한 달 전 세 번째 성적표는 77.25점이었다. 그때 나는 &quot;다음 회차에는 새로 만드는 것 없이, 이미 설치된 것이 돌아간 기록만 들고 오겠다&quot;고 적었다. 절반은 지켰다. 에이전트 설정 폴더는 git에 들어가 매일 밤 NAS로 백업됐고, 주간 회고는 내가 자는 사이에도 돌았고, 감사가 시스템을 고친 사이클 두 바퀴가 기록으로 확정됐다.</p>
<p>나머지 절반이 이번 점수다.</p>
<h2>기계는 다 돌고 있었다</h2>
<p>이번 감사에서 깎인 점수의 뿌리는 전부 한 곳으로 수렴했다. 장치가 아니라, 장치가 낸 신호를 소비하는 마지막 한 단 — 즉 나였다.</p>
<p>주간 회고는 매주 &quot;사람 결정 한 줄&quot;이라는 빈칸을 만들어 놓고 나를 기다렸다. 나는 4주 동안 그 한 줄을 채우지 않았다. 검색 품질을 재는 벤치마크는 매주 일요일 밤에 돌았는데, 네 번 연속 0바이트 빈 파일을 남기면서 로그에는 &quot;done&quot;을 찍고 있었다. 아무도 그 파일을 열어보지 않았다. 나를 포함해서.</p>
<p>가장 아픈 건 이것이다. 미러 신선도를 감시하는 자동 점검이 한 주 결측됐는데, 주간 회고는 &quot;경고 플래그 없음 → 정상&quot;이라고 적었다. 점검이 돌지 않으면 플래그도 없다. 시스템은 자기 침묵을 건강으로 읽었고, 나는 그 문장을 그대로 믿었다.</p>
<p>0.25점은 시스템이 못 낸 점수가 아니라 내가 안 낸 점수다.</p>
<h2>그런데 이 성적표에서 처음으로 장점을 읽었다</h2>
<p>성적표를 받고 나서, 늘 하던 대로 감점 목록부터 읽다가 문득 반대쪽을 물었다. 격려받을 부분은 없나.</p>
<p>있었다. 그리고 그 목록이, 옵시디언으로 지식관리를 하는 사람이라면 아마 자기 볼트에서도 발견할 수 있는 종류였다.</p>
<p><strong>첫째, 내 볼트는 에이전트가 사는 집이다.</strong> 노트 1만 1천여 개 전체가 하이브리드 검색으로 에이전트에게 열려 있고, 인덱스는 자동으로 갱신된다. 다른 시스템들을 다섯 주간 지켜보며 알게 된 흔한 실패는 두 가지다. 볼트는 훌륭한데 에이전트가 못 들어가는 시스템, 반대로 에이전트는 화려한데 읽을 지식이 없는 시스템. 노트가 에이전트의 컨텍스트가 되게 만드는 일 — 옵시디언 사용자의 첫 관문 — 은 이미 통과해 있었다. 이 기둥은 네 번의 평가 내내 한 번도 흔들리지 않았다.</p>
<p><strong>둘째, 사람용과 기계용의 이층 구조.</strong> 사람이 읽는 마더십 볼트와 별개로, LLM이 읽기 좋게 증류한 위성 위키를 따로 둔다. 큰 문서를 통째로 먹이는 대신 인덱스 → 요약 → 원문의 계층으로 읽게 하는 구조인데, 이 패턴을 따라 만든 시스템 여럿이 이번 보드에 제출됐다. 내가 만든 구조가 남의 시스템에서 돌아가는 걸 보는 것은 이상하고 좋은 경험이다.</p>
<p><strong>셋째, 백업이 아니라 복구.</strong> 이번 회차 최대 상승분이 여기서 나왔다. 볼트와 에이전트 설정 양쪽을 실제로 복원해 보고, 원본과 바이트 단위로 동일한지 검증하는 리허설을 두 번 마쳤다. 많은 옵시디언 사용자가 클라우드 동기화를 백업이라 믿는다. 동기화는 삭제도 성실하게 전파한다. &quot;복사본이 있다&quot;와 &quot;돌아올 수 있다&quot;는 다른 문장이고, 후자는 리허설로만 증명된다.</p>
<p><strong>넷째, 지식이 볼트 밖에서 복리를 만들고 있다.</strong> 이 평가표 자체가 내 볼트에서 나왔다. 공개했더니 쉰 개 넘는 시스템이 자발적으로 올라왔고, 참여자들의 피드백이 평가표의 개정으로 돌아왔다. 노트가 노트를 낳는 복리를 볼트 안에서만 상상했는데, 볼트 밖에서 먼저 벌어졌다.</p>
<h2>남의 성적표에서 배운 것</h2>
<p>다섯 주 동안 마흔 개 넘는 리포트를 읽으며 감탄한 순간들이 있다.</p>
<p>만점을 받은 어느 시스템은 마지막 네 개 기준을 억지로 채우지 않고 &quot;자연히 사건이 발생하기를 기다리는&quot; 상태로 두었다. 실제로 사건들이 일어났고, 그때서야 점수가 닫혔다. 벼락치기의 정반대다. 어떤 시스템은 사고 열아홉 건을 지우지 않고 원장으로 만들어 심장에 두었다. 어떤 제출자는 평가 시작 3분 전에 생성된 주간 리뷰를 자기 손으로 증거에서 제외하고 등급을 내려놓았다. 닷새 만의 재검증에서 &quot;만들었지만 아직 배선되지 않았다&quot;며 점수를 1점도 올리지 않고 돌아온 사람도 있었고, 스케줄러가 매주 실행 기록만 남기고 실제로는 아무것도 쓰지 않는 유령이 된 것을 자기 손으로 적발해 자진 감점한 사람도 있었다.</p>
<p>패턴이 보이는가. <strong>이 보드에서 신뢰의 화폐는 점수가 아니라 자진 감점이다.</strong> 높은 점수는 흔하다. 자기 점수를 깎는 검증은 드물고, 그것이 있는 리포트만이 끝까지 읽힌다.</p>
<p>그리고 상위권의 병목은 놀랍도록 한결같다. 만드는 능력이 아니다. 장치가 찾아낸 것을 사람이 닫는 속도다. 내 &quot;사람 결정 한 줄&quot;과 정확히 같은 병이, 점수가 나보다 십 점 높은 시스템들에도 있었다.</p>
<h2>격려의 재정의</h2>
<p>옵시디언으로 지식관리를 하는 사람에게 이 다섯 주가 준 결론은 이렇다.</p>
<p>어려워 보이는 것 — 에이전트 통합, 검색 인프라, 복구 체계 — 은 한 번 지으면 서 있는 구조물이다. 지어봤다면 당신은 이미 대부분의 시스템보다 앞에 있다. 쉬워 보이는 것 — 매주 한 줄 쓰기, 만든 계기판 열어보기 — 이 실제로는 마지막까지 남는 관문이다.</p>
<p>그러니 격려는 이렇게 다시 쓰는 게 맞다. 당신의 볼트가 완벽하지 않은 게 아니라, 어려운 부분이 먼저 끝나 있는 것이다. 남은 게 &quot;매주 한 줄&quot;이라는 사실은 좋은 소식이다.</p>
<p>나의 10월 목표는 점수가 아니다. 장치가 낸 신호를 내가 소비한 기록 4주치. 0.25점의 주인이 누구인지는 이미 알고 있으니까.</p>
<hr>
<p>내 성적표 전문과 쉰세 개 시스템의 보드는 <strong><a href="https://akm.cmdspace.work">akm.cmdspace.work</a></strong> 에 공개되어 있다. 당신의 볼트도 잴 수 있다 — 평가는 에이전트가 당신 기기 안에서 수행하고, 제출과 공개는 전부 당신이 정한다. <a href="https://akm.cmdspace.work/submit.html">평가 참여 안내</a>에서 시작하면 된다.</p>
<p>이 글은 <a href="/posts/rank-14-on-my-own-rubric/">내가 만든 평가표에서 나는 14등이다</a>의 한 달 뒤 이야기다.</p>
]]></content:encoded>
</item>
<item>
<title>여섯 개의 문, 한 채의 집 — CMDSPACE 지식 생태계 전체 지도</title>
<link>https://jisan.cmdspace.work/posts/knowledge-ecosystem-map/</link>
<guid isPermaLink="true">https://jisan.cmdspace.work/posts/knowledge-ecosystem-map/</guid>
<pubDate>Thu, 20 Aug 2026 12:00:00 GMT</pubDate>
<category>에세이</category>
<description>시스템 파일, LLM Wiki, AKM Index, 9요한, CmdMD, 그리고 이 블로그까지. 따로따로 발견되던 여섯 개의 사이트는 사실 한 채의 집이다. 처음으로 전체 지도를 그렸다.</description>
<content:encoded><![CDATA[<figure><img loading="lazy" decoding="async" src="/images/knowledge-ecosystem-map/hero-knowledge-ecosystem-map.jpg" alt="여섯 개의 문이 있는 한 채의 집, 각 문에서 새어 나오는 빛"></figure>
<p>사람들이 나를 발견하는 문이 제각각이다. 어떤 사람은 시스템 파일을 다운받으러 왔다가 위키를 발견하고, 어떤 사람은 AKM 점수를 재러 왔다가 묻는다. &quot;그런데 이 사이트들이 다 뭐예요?&quot;</p>
<p>타당한 질문이다. 문이 여섯 개면 지도가 있어야 한다. 오늘 그 지도를 그린다.</p>
<h2>집의 기초는 볼트 하나다</h2>
<p>모든 것은 하나의 Obsidian 볼트에서 자랐다. 3년 넘게 매일 굴린 10,000개가 넘는 노트. 나는 이것을 마더십이라고 부른다. 강의 준비도, 컨설팅 산출물도, 뉴스레터도, 지금 이 글도 전부 여기서 나왔다.</p>
<p>이 집의 건축 원칙은 한 문장이다. <strong>기억을 믿지 말고, 시스템을 믿어라.</strong> 머릿속 기억은 흐려지고 왜곡되지만, 규칙을 갖춘 기록은 쌓일수록 강해진다. 그리고 AI 에이전트 시대에 이 원칙은 실용적인 의미를 하나 더 얻었다. 시스템이 있어야 AI가 일한다.</p>
<h2>일곱 개의 볼트, 분산이 아니라 분업</h2>
<p>지금 나는 볼트를 일곱 개 운영한다. 흩어진 게 아니라 나눈 것이다. 회사에 부서가 있듯이 볼트마다 저자와 합의 구조가 다르다. 혼자 쓰는 마더십, AI와 함께 쓰는 위키 위성, 두 사람이 쓰는 협업 볼트, 다섯 명이 쓰는 팀 볼트, 외부에 배포하는 스타터킷. AI가 쓴 글과 사람이 쓴 글이 한 곳에 섞이면 신뢰의 출처가 흐려진다. 그래서 경계를 물리적으로 나눈다.</p>
<h2>여섯 개의 문</h2>
<p>이 집에는 바깥으로 난 문이 여섯 개 있다. 각 문은 집의 한 부분을 공개한 것이다.</p>
<p><strong><a href="https://system.cmdspace.work">system.cmdspace.work</a></strong> 는 집의 설계도다. AI 에이전트가 볼트에서 일하기 전에 읽는 시스템 파일 여섯 종과 공유 규칙을 그대로 배포한다. 내 볼트를 떠받치는 규격을 누구든 자기 볼트에 포크할 수 있다.</p>
<p><strong><a href="https://llm-wiki.cmdspace.work">llm-wiki.cmdspace.work</a></strong> 는 집의 서재다. 사람과 AI가 함께 컴파일하는 위성 위키. 원본은 불변으로 보존하고, AI가 정제한 지식이 상호 참조로 엮이며 쌓인다. 직접 차릴 수 있게 스타터킷도 배포한다.</p>
<p><strong><a href="https://akm.cmdspace.work">akm.cmdspace.work</a></strong> 는 집의 계량기다. &quot;AI 에이전트가 함께 굴리는 지식관리, 몇 점입니까?&quot;라는 질문에 5필러 25기준으로 답하는 공개 루브릭과 평가 보드. 첫 30일에 77개 시스템이 다녀갔다.</p>
<p><strong><a href="https://9yohan.cmdspace.work">9yohan.cmdspace.work</a></strong> 는 집의 조직도다. 아홉 개 사업 부문을 역사 속 아홉 명의 요한에게 맡긴 멀티 에이전트 설계 문서. 1인 지식노동자가 아홉 부문을 어떻게 지휘하는지의 기록이다.</p>
<p><strong><a href="https://cmdmd.cmdspace.work">cmdmd.cmdspace.work</a></strong> 는 집의 현관이다. 노트를 읽고 검토한 뒤 한 번의 키로 볼트의 제자리에 배분하는 macOS 에디터. 무료 오픈소스다.</p>
<p><strong><a href="https://jisan.cmdspace.work">jisan.cmdspace.work</a></strong> 는 집의 응접실, 지금 있는 곳이다. 이 생태계에서 태어난 생각을 인용 가능한 영구 URL로 발행한다.</p>
<p>그리고 문패가 하나 있다. <a href="https://thebetter.stibee.com">더배러</a>는 2023년에 구독자 네 명으로 시작해 이제 천 명이 넘게 함께 읽는 주간 뉴스레터다. 생태계의 소식이 매주 이 편지로 나간다.</p>
<h2>리듬은 하나다</h2>
<p>여섯 개의 문이 제각각처럼 보여도 안에서는 하나의 리듬으로 돌아간다. Connect, Merge, Develop, Share. 포착하고, 통합하고, 발전시키고, 공유한다. 이 글 한 편도, AKM 루브릭도, CmdMD의 코드도 전부 이 네 단계를 지나 바깥에 나왔다.</p>
<h2>새 문: brain.cmdspace.work</h2>
<p>그리고 오늘, 지도 자체를 문으로 만들었다. <strong><a href="https://brain.cmdspace.work">brain.cmdspace.work</a></strong> 는 이 생태계의 개념 허브다. 세컨드브레인이 뭔지, LLM Wiki가 뭔지, RAG와는 뭐가 다른지, 승격 게이트가 왜 필요한지. 핵심 개념 여덟 가지를 눈높이에 맞게 풀고, 전문 자료가 필요해지면 여섯 개의 문으로 안내한다. 용어에 마우스를 올리면 뜻이 뜨고, 볼트 일곱 개의 지도와 위키의 3층 구조도 그림으로 볼 수 있다.</p>
<p>개념이 궁금하면 brain에서 시작하라. 만들고 싶으면 system과 llm-wiki로, 재보고 싶으면 akm으로 가라. 어느 문으로 들어와도, 같은 집이다.</p>
]]></content:encoded>
</item>
<item>
<title>AI에게 건네는 첫 문서 — CMDS System Files</title>
<link>https://jisan.cmdspace.work/posts/cmds-system-files/</link>
<guid isPermaLink="true">https://jisan.cmdspace.work/posts/cmds-system-files/</guid>
<pubDate>Thu, 20 Aug 2026 11:50:00 GMT</pubDate>
<category>소개</category>
<description>10,000개 노트 볼트를 떠받치는 규격을 그대로 공개했다. AI 에이전트가 내 볼트에서 일하기 전에 읽는 시스템 파일 여섯 종. 왜 만들었고, 왜 나눠주는가.</description>
<content:encoded><![CDATA[<figure><img loading="lazy" decoding="async" src="/images/cmds-system-files/hero-cmds-system-files.jpg" alt="설계 도면을 건네는 두 손"></figure>
<p>같은 AI를 쓰는데 결과가 다르다. 그 차이는 모델이 아니라 맥락의 구조에서 난다. Claude Code든 Codex든, 에이전트가 내 볼트에 처음 들어왔을 때 무엇을 읽게 할 것인가. 그 답이 시스템 파일이다.</p>
<p><a href="https://system.cmdspace.work">system.cmdspace.work</a> 는 내 볼트의 운영 규격을 그대로 공개한 사이트다.</p>
<h2>배포하는 것은 세 묶음이다</h2>
<p><strong>시스템 파일 6종.</strong> 우선순위 순서로 로드되는 규칙 문서들이다. Claude Code 전용 기술 규칙, 다른 코딩 에이전트용 규칙, 시스템 철학과 사용자 컨텍스트, 운영 표준, 카테고리 네비게이션, 시각 산출물 규격. 파일마다 대상 독자가 다르고, 서로 충돌하면 우선순위 숫자가 판정한다.</p>
<p><strong>공유 규칙 9종.</strong> 들여쓰기, frontmatter 표준, 위키링크, 파일 생성 위치 같은 실무 규칙이다. 시스템 파일이 헌법이라면 이쪽은 시행령이다. 에이전트가 노트 하나를 만들 때마다 실제로 참조하는 층이다.</p>
<p><strong>슬래시 커맨드 8종.</strong> Connect, Merge, Develop, Share의 지식 생애주기를 명령어로 만들었다. 워크플로가 문서로만 존재하면 잊히지만, 커맨드로 존재하면 실행된다.</p>
<h2>문서가 아니라 구조를 설계하라</h2>
<p>이 규격의 핵심 주장은 단순하다. AI가 자동 정리한 문서를 아무리 쌓아도 좋은 시스템이 되지 않는다. 먼저 필요한 것은 해석의 질서, 즉 스키마다. 이 논증은 <a href="/posts/schema-is-harness/">Schema는 Harness다</a>에서 길게 폈다. Karpathy의 LLM Wiki가, 그리고 Google Cloud의 OKF가 서로 다른 자리에서 같은 구조에 도착하고 있다는 것이 이 방향의 가장 강한 증거다.</p>
<p>그리고 규격은 공개될 때 강해진다. 내 볼트에서 검증된 규칙이 다른 볼트에서도 작동하는지, 포크한 사람들의 사례가 다시 규격을 다듬는다.</p>
<h2>그대로 쓰라고 주는 게 아니다</h2>
<p>사이트에서 파일 여섯 개를 개별로 읽거나 전체 번들 ZIP을 받아 볼트 루트에 놓으면 된다. 하지만 복사가 목적이 아니다. 파일 안의 경로와 카테고리를 자기 구조로 바꾸는 과정, 그 과정 자체가 자기 볼트의 스키마를 처음으로 명시하는 경험이 된다. 규칙을 옮겨 적다 보면 알게 된다. 내 볼트에는 어떤 규칙이 없었는지.</p>
<p>기술 문서 전체는 <a href="https://system.cmdspace.work/docs/">system.cmdspace.work/docs</a>에 있다. 시작하기 전에 개념부터 잡고 싶다면 <a href="https://brain.cmdspace.work">brain.cmdspace.work</a>의 &quot;스키마 우선&quot; 카드부터 읽으면 된다.</p>
]]></content:encoded>
</item>
<item>
<title>사람과 AI가 함께 컴파일하는 위키 — CMDS LLM Wiki</title>
<link>https://jisan.cmdspace.work/posts/cmds-llm-wiki/</link>
<guid isPermaLink="true">https://jisan.cmdspace.work/posts/cmds-llm-wiki/</guid>
<pubDate>Thu, 20 Aug 2026 11:40:00 GMT</pubDate>
<category>소개</category>
<description>원본은 불변으로 보존하고, AI가 정제한 지식이 상호 참조로 쌓인다. Karpathy의 LLM Wiki 패턴을 실운영 규모로 굴린 기록과, 오늘 시작할 수 있는 스타터킷.</description>
<content:encoded><![CDATA[<figure><img loading="lazy" decoding="async" src="/images/cmds-llm-wiki/hero-cmds-llm-wiki.jpg" alt="사람의 손과 기계의 손이 함께 책을 쌓는 장면"></figure>
<p>검색은 매번 새로 만들고 버린다. 위키는 쌓인다. 이 한 문장을 실제 시스템으로 만들면 어떤 모습이 되는가. 그 답이 <a href="https://llm-wiki.cmdspace.work">llm-wiki.cmdspace.work</a> 에 있다.</p>
<h2>사람은 판단하고, AI는 장부를 쓴다</h2>
<p>CMDS LLM Wiki는 마더십 볼트에서 분기한 위성 볼트다. 역할은 하나, 학습과 연구다. 기사, 논문, 전사 같은 외부 자료가 들어오면 AI가 읽고 위키 페이지로 컴파일하고, 새 자료가 올 때마다 기존 페이지를 갱신한다.</p>
<p>역할 분담이 핵심이다. 자료를 고르고 의미를 판단하는 것은 나다. 참조 갱신과 요약 최신화 같은 유지 노동은 AI가 맡는다. 사람이 위키 운영을 포기하는 진짜 이유는 사고가 아니라 이 북키핑 노동이다. 그런데 AI에게는 이 비용이 거의 0이다. 위키가 죽지 않는 이유가 여기 있다.</p>
<h2>세 개의 층</h2>
<p>구조는 세 층이다. 손대지 않는 원본 층(Raw Sources), AI가 작성하고 유지하는 위키 층(Wiki), 그리고 템플릿과 게이트와 커맨드가 사는 규칙 층(Schema). 원본과 정리본 사이에서 무엇이 어디로 승격되는지는 <a href="/posts/between-raw-and-wiki/">Raw와 Wiki 사이에서</a>에 길게 썼다.</p>
<h2>패턴 제안이 아니라 운영 기록이다</h2>
<p>이 글을 쓰는 2026년 8월 기준, 위키에는 마크다운 파일 1,417개, 위키 페이지 754개, 원본 248건이 돌아가고 있다. 운영은 커맨드 세 개로 압축된다. 새 자료를 흡수하는 /ingest, 질문에 답하고 좋은 답을 다시 저장하는 /query, 끊어진 링크와 모순을 점검하는 /lint. 이 세 동작이 반복될수록 위키는 복리처럼 풍부해진다. 자료를 넣어도 좋아지고, 질문을 해도 좋아진다.</p>
<h2>믿음은 절차다</h2>
<p>AI가 만든 모든 페이지는 &quot;검증 안 됨&quot; 상태로 태어난다. 사람이 읽고 확인해야만 &quot;검증됨&quot;이 되고, AI는 이 표시를 절대 건드리지 못한다. 페이지마다 반대 논거를 강제로 적게 하는 편향 점검도 있다. AI가 쓴 지식을 믿는 방법은 약속이 아니라 절차다.</p>
<h2>오늘 시작할 수 있다</h2>
<p>같은 구조를 빈 볼트로 배포하는 스타터킷이 있다. 템플릿 11종과 검증 스크립트, 논문 인제스트 가이드가 포함된 ZIP을 <a href="https://github.com/johnfkoo951/cmds-llm-wiki/releases/latest">GitHub Releases</a>에서 받으면 된다. Obsidian과 Claude Code(또는 Codex)만 있으면 충분하다.</p>
<p>위키가 무엇이고 RAG와 어떻게 다른지 개념부터 필요하다면, <a href="https://brain.cmdspace.work">brain.cmdspace.work</a>의 &quot;LLM Wiki 패턴&quot;과 &quot;RAG vs 컴파일 위키&quot; 카드를 먼저 읽으라.</p>
]]></content:encoded>
</item>
<item>
<title>측정할 수 없으면 복리도 없다 — AKM Index</title>
<link>https://jisan.cmdspace.work/posts/akm-index/</link>
<guid isPermaLink="true">https://jisan.cmdspace.work/posts/akm-index/</guid>
<pubDate>Thu, 20 Aug 2026 11:30:00 GMT</pubDate>
<category>소개</category>
<description>AI 에이전트가 함께 굴리는 지식관리 시스템의 성숙도를 5필러 25기준으로 잰다. 증거 없는 점수는 없다. 그리고 만든 사람이 중위권이라는 것이 이 평가표의 가장 좋은 증거다.</description>
<content:encoded><![CDATA[<figure><img loading="lazy" decoding="async" src="/images/akm-index/hero-akm-index.jpg" alt="문서 더미 위에 놓인 정밀 다이얼 게이지"></figure>
<p>&quot;AI 에이전트가 함께 굴리는 지식관리, 몇 점입니까?&quot; <a href="https://akm.cmdspace.work">akm.cmdspace.work</a> 는 이 질문 하나로 만든 사이트다. AKM은 Agentic Knowledge Management의 약자다. 측정 대상은 노트 필기 실력이 아니다. 사람, 지식 기반, 에이전트 런타임, 운영 루프를 하나의 시스템으로 보고 그 성숙도를 잰다. <strong>노트가 아니라 시스템을 채점하라.</strong> 이것이 루브릭의 철학이다.</p>
<h2>다섯 개의 필러, 스물다섯 개의 기준</h2>
<p>프롬프트(20%), 컨텍스트(25%), 하네스(20%), 루프(20%), 상호운용과 거버넌스(15%). 필러마다 기준이 다섯 개씩, 총 25개다. 컨텍스트에 가장 큰 가중치가 걸려 있다는 것 자체가 하나의 주장이다. AI 활용의 격차는 프롬프트 문장력이 아니라 지식 기반의 구조에서 난다.</p>
<h2>증거가 없으면 점수도 없다</h2>
<p>기준마다 0에서 4까지의 성숙도 레벨이 있고, 규칙은 엄격하다. 증거가 없으면 상한 1. 문서만 있으면 2. 도구가 규칙을 강제해야 3. 그리고 레벨 4는 &quot;시스템이 시스템을 고친 기록&quot;이 없으면 불가능하다. 평가 직전에 몰아 만든 아티팩트는 인정하지 않고, 애매하면 낮은 쪽으로 친다. 총점은 0에서 100, 밴드는 M0(수동)부터 M4(복리형)까지다.</p>
<p>느낌은 측정이 아니다. 그래서 모든 점수 옆에는 파일 경로, 설정, 로그 같은 아티팩트가 붙어야 한다.</p>
<h2>하락도 기록에 남는다</h2>
<p>보드에는 동의한 시스템만 올라간다. 재평가를 하면 이전 회차와 연결되어 궤적 그래프가 그려지는데, 점수 하락도 숨겨지지 않고 이력에 남는다. 첫 30일 동안 하락을 기록한 여섯 건이 전부 자진 보고였다. 나는 이것이 이 보드의 가장 큰 신뢰 자산이라고 생각한다.</p>
<h2>만든 사람이 14등이다</h2>
<p>루브릭의 캘리브레이션 기준점은 내 시스템이다. 첫 감사에서 72.0점 M3를 받았고, 개선을 거쳐 재평가로 77.25까지 올렸다. 그 시점의 공개 보드에서 나는 중위권이었다. 만든 사람이 1등인 평가표는 평가표가 아니라 광고다. 이 이야기는 <a href="/posts/rank-14-on-my-own-rubric/">내가 만든 평가표에서 나는 14등이다</a>에 썼고, 첫 30일 77개 시스템의 데이터 분석은 <a href="/posts/what-77-systems-told-me/">77개의 시스템이 말해준 것</a>에 있다.</p>
<h2>재는 법</h2>
<p>세 경로가 있다. 가장 쉬운 것은 무료 셀프 평가다. akm-eval 스킬을 설치하면 여러분의 에이전트가 직접 볼트를 뒤져 증거를 수집하고 채점한다. 전 과정이 로컬에서 돌고, 결과 제출은 선택이다. 제출하면 공개 보드와 같은 포맷의 성적표를 받는다. 그 외에 원격 키트와 워크숍 경로가 있다.</p>
<p>측정 전에 개념 정리가 필요하면 <a href="https://brain.cmdspace.work">brain.cmdspace.work</a>에서 시작하라. 재보고 싶어졌다면 <a href="https://akm.cmdspace.work/rubric.html">루브릭 전문</a>이 기다린다. 측정할 수 없으면, 복리도 없다.</p>
]]></content:encoded>
</item>
<item>
<title>아홉 명의 요한, 하나의 주권 커널 — 9Yohan Constellation</title>
<link>https://jisan.cmdspace.work/posts/9yohan-constellation/</link>
<guid isPermaLink="true">https://jisan.cmdspace.work/posts/9yohan-constellation/</guid>
<pubDate>Thu, 20 Aug 2026 11:20:00 GMT</pubDate>
<category>소개</category>
<description>아홉 개 사업 부문을 역사 속 아홉 명의 요한에게 맡기고, 성령의 아홉 열매를 가드레일로 삼았다. 파편화된 봇 무리가 아니라 하나의 커널이 지휘하는 별자리.</description>
<content:encoded><![CDATA[<figure><img loading="lazy" decoding="async" src="/images/9yohan-constellation/hero-9yohan-constellation.jpg" alt="하나의 중심 별을 도는 아홉 개의 별"></figure>
<p>1인 지식노동자의 하루는 아홉 개의 직업을 오간다. 연구하고, 쓰고, 가르치고, 만들고, 분석하고, 연결하고, 개발하고, 모임을 열고, 자문한다. 부문마다 에이전트를 붙이면 아홉 개의 봇이 생긴다. 그런데 봇이 아홉이면 목소리도 아홉이 된다. <a href="https://9yohan.cmdspace.work">9yohan.cmdspace.work</a> 는 그 문제에 대한 내 답이다. 아홉 명의 스페셜리스트와, 그들을 지휘하는 하나의 커널.</p>
<h2>이름에는 힘이 있다</h2>
<p>설계의 뼈대는 1:1:1 매핑이다. 내 아홉 개 사업 부문 하나하나에 역사 속 &quot;요한&quot; 한 명과 성령의 아홉 열매 중 하나를 짝지었다. 지식관리와 연구는 요하네스 케플러(온유), 글쓰기와 출판은 괴테(사랑), 교육은 존 듀이(자비), 창작은 바흐(희락), 분석은 폰 노이만(절제), 파트너십은 세례 요한(오래 참음), 개발은 존 매카시(양선), 커뮤니티는 하위징아(화평), 자문은 칼뱅(충성)이다.</p>
<p>인물은 장식이 아니라 앵커다. 각 에이전트의 시스템 프롬프트는 그 인물의 사고방식을 정체성으로 삼는다. &quot;케플러라면 이 데이터를 어떻게 볼까&quot;가 프롬프트 한 줄보다 많은 것을 결정한다.</p>
<h2>열매는 교리가 아니라 가드레일이다</h2>
<p>성령의 열매를 붙인 것은 신앙 고백이면서 동시에 공학적 선택이다. 케플러의 온유는 확증 편향에 대한 방어로 작동한다. 노이만의 절제는 과적합과 p-해킹에 대한 방어다. 덕목을 실무 규칙으로 번역하면, 에이전트가 잘하는 일뿐 아니라 하지 말아야 할 일이 정의된다.</p>
<h2>주권은 하나다</h2>
<p>아홉 에이전트 위에 커널이 있다. 9yohan.prime, 곧 나 자신이다. 커널의 책임은 다섯 가지다. 의도를 해석하고, 적임 에이전트로 라우팅하고, 컨텍스트를 큐레이션하고, 결과를 합성하고, 최종 서명한다. 바깥으로 나가는 모든 산출물은 커널의 승인을 거친다. 에이전트가 아무리 늘어도 책임의 주소는 하나여야 한다. 이 원칙은 양보하지 않는다.</p>
<h2>제품이 아니라 설계 문서다</h2>
<p>사이트에는 이 별자리의 전체 설계가 공개되어 있다. 중앙 커널과 아홉 노드의 스타 토폴로지, 요청 하나가 처리되는 10단계 컨트롤 루프, 그리고 뉴스레터 발행이나 컨설팅 제안 같은 실제 작업이 어느 요한들을 거쳐 가는지의 플레이북 10종까지.</p>
<p>멀티 에이전트를 &quot;봇을 많이 만드는 일&quot;이 아니라 &quot;권한과 정체성을 설계하는 일&quot;로 접근하고 싶은 사람에게, 하나의 완성된 사례가 될 것이다. 이 시스템이 생태계 어디에 놓이는지는 <a href="https://brain.cmdspace.work">brain.cmdspace.work</a>의 지도에서 볼 수 있다.</p>
]]></content:encoded>
</item>
<item>
<title>읽기가 먼저다 — 리뷰 우선 마크다운 에디터 CmdMD</title>
<link>https://jisan.cmdspace.work/posts/cmdmd/</link>
<guid isPermaLink="true">https://jisan.cmdspace.work/posts/cmdmd/</guid>
<pubDate>Thu, 20 Aug 2026 11:10:00 GMT</pubDate>
<category>소개</category>
<description>노트 앱은 쓰기 화면으로 열리지만, 지식노동의 실제 시간은 읽고 검토하고 배분하는 데 쓰인다. 그 순서를 인터페이스로 만들었다. macOS 네이티브, 무료 오픈소스.</description>
<content:encoded><![CDATA[<figure><img loading="lazy" decoding="async" src="/images/cmdmd/hero-cmdmd.jpg" alt="문서를 비추는 돋보기와 서랍으로 갈라지는 종이 길"></figure>
<p>AI가 초안을 쓰는 시대에 사람의 일이 바뀌었다. 백지에서 쓰는 시간보다, 만들어진 문서를 읽고 판단하고 제자리에 보내는 시간이 길어졌다. 코드 리뷰가 개발의 일상이 됐듯이, 노트 리뷰가 지식노동의 일상이 됐다.</p>
<p>그런데 노트 앱들은 여전히 쓰기 화면으로 열린다. 그래서 만들었다. <a href="https://cmdmd.cmdspace.work">CmdMD</a> 는 그 순서를 뒤집은 앱이다.</p>
<h2>읽기가 기본값이다</h2>
<p>CmdMD로 마크다운 파일을 열면 소스가 아니라 렌더된 프리뷰가 먼저 보인다. 읽는 것이 기본이고, 고치고 싶을 때만 키 하나로 소스 모드나 분할 모드로 전환한다. Obsidian식 문법을 그대로 지원해서 위키링크, 태그, 콜아웃, 하이라이트가 다 렌더되고, Mermaid 다이어그램과 수식도 표시된다.</p>
<h2>읽었으면 보내야 한다</h2>
<p>읽고 판단했으면 다음은 배분이다. CmdMD는 설치된 Obsidian 볼트를 자동으로 감지하고, 단축키 하나로 지금 보는 노트를 지정한 볼트의 지정한 폴더로 보낸다. 태그나 파일명, 문서 속성을 조건으로 하는 라우팅 규칙을 만들어두면 자동 분류까지 된다.</p>
<p>다운로드 폴더에 쌓인 마크다운, AI가 만들어준 초안, 급히 적은 메모. 이런 것들이 리뷰 한 번과 키 한 번으로 볼트의 제자리에 정리된다. 볼트 바깥의 마크다운 세계와 볼트 안을 잇는 현관문이다.</p>
<p>퍼지 검색으로 파일명과 내용을 함께 뒤지는 옴니서치, 어디서든 부르는 퀵 캡처, 템플릿, HTML과 PDF 내보내기도 들어 있다.</p>
<h2>무료고, 열려 있고, 가볍다</h2>
<p>CmdMD는 Swift와 SwiftUI로 만든 macOS 네이티브 앱이다. Electron 없이 가볍게 돌고, 무료이며, 소스가 공개되어 있다. macOS 14 이상에서 <a href="https://github.com/johnfkoo951/CmdMD/releases/latest">GitHub Releases</a>로 받으면 된다.</p>
<p>도구는 철학의 물리적 형태다. 읽기가 먼저고, 모든 것에는 제자리가 있다. 이 철학이 어디서 왔는지 궁금하다면 <a href="https://brain.cmdspace.work">brain.cmdspace.work</a>에 전체 그림이 있다.</p>
]]></content:encoded>
</item>
<item>
<title>77개의 시스템이 말해준 것 — 평가표를 한 달 돌려 배운 여섯 가지</title>
<link>https://jisan.cmdspace.work/posts/what-77-systems-told-me/</link>
<guid isPermaLink="true">https://jisan.cmdspace.work/posts/what-77-systems-told-me/</guid>
<pubDate>Mon, 17 Aug 2026 00:00:00 GMT</pubDate>
<category>에세이</category>
<description>지식관리 시스템 평가표 AKM Index를 공개하고 30일. 77개 시스템의 제출 데이터를 전수 분석했다. 다들 에이전트를 부리는 법은 알았고, 시스템이 살아남는 법은 몰랐다. 볼트 크기는 성숙도가 아니었고, 상위권의 병목은 측정이 아니라 집행이었다. 그리고 점수가 내려갔다고 자진 신고하는 사람들이 나타났다.</description>
<content:encoded><![CDATA[<p><a href="/posts/rank-14-on-my-own-rubric/">한 달 전에 나는 내가 만든 평가표에서 14등이라고 썼다</a>. 그 글을 쓸 때 보드에는 마흔 개의 시스템이 있었다. 오늘 아침 기준으로 제출된 리포트는 일흔일곱, 공개 보드에는 쉰하나다. 주말 이틀 동안 제출된 평가 리포트를 정리하다가, 이 데이터가 개별 점수보다 훨씬 재미있는 이야기를 품고 있다는 걸 알았다. 그래서 전부 다시 읽었다. 공개 카드 51장과, 공개에 동의하지 않아 보드에 오르지 않은 제출까지 포함한 마스터 리포트 77건, 재제출을 포함한 원본 영수증 137건 전부.</p>
<p>한 달짜리 실험이 말해준 것을 여섯 개로 줄이면 이렇다.</p>
<h2>하나. 다들 에이전트는 부린다. 시스템이 살아남는 법을 모를 뿐.</h2>
<p>AKM Index는 다섯 개 필러로 시스템을 잰다. 프롬프트(P), 컨텍스트(C), 하네스(H), 루프(L), 그리고 상호운용·거버넌스(X). 77개 시스템의 필러별 평균 달성률을 놓고 보면 그림이 선명하다.</p>
<figure><img loading="lazy" decoding="async" src="/images/what-77-systems-told-me/figure-01-pillar-achievement.png" alt="필러별 평균 달성률 막대 그래프 — H 77%, P 75%, C 74%, L 73%, X 63%" title="Figure 1. 필러별 평균 달성률. X(상호운용·거버넌스)만 유일하게 60%대다."><figcaption>Figure 1. 필러별 평균 달성률. X(상호운용·거버넌스)만 유일하게 60%대다.</figcaption></figure>
<p>하네스가 77%로 가장 높다. 훅을 걸고, 권한을 조이고, 도구를 배선하는 일은 다들 한다. 프롬프트 75%, 컨텍스트 74%, 루프 73%. 그런데 상호운용·거버넌스만 63%다. 25개 세부 기준 중 최약 6개를 뽑으면 넷이 X 필러에서 나온다. 이식성(평균 레벨 2.38), 시크릿 관리(2.40), 멀티디바이스 동기화(2.48), 백업(2.62).</p>
<p>무슨 뜻인가. <strong>에이전트에게 일을 시키는 능력은 이미 상향평준화됐다.</strong> 갈리는 지점은 다른 데 있다. 이 시스템이 운영자 없이 살아남는가. 이 기기 밖에서도 성립하는가. 지금 쓰는 도구가 사라져도 지식이 남는가. 노트북이 오늘 밤 죽으면 내일 아침 몇 시간 만에 복구되는가. 화려한 멀티에이전트 오케스트레이션 위에서 시크릿이 평문으로 굴러다니고, 백업은 &quot;언젠가 해야지&quot; 상태인 시스템이 널려 있다.</p>
<p>재미있는 건 참여자들도 스스로 안다는 점이다. 리포트의 개선 로드맵에서 가장 자주 등장한 단어를 세보면 검색, 자동화, 훅 다음에 바로 백업과 시크릿이 온다. 알면서 미루는 것이다. 나도 그랬으니까 안다.</p>
<h2>둘. 볼트 크기는 성숙도가 아니다</h2>
<p>제출된 시스템들의 노트 수는 42개부터 37,411개까지 퍼져 있다. 노트 수(로그 스케일)와 총점의 상관계수는 0.26. 거의 무관하다는 뜻이다. 실제로 노트 42개로 M3 밴드에 오른 시스템과 3만 개 노트로 M2에 머문 시스템이 같은 보드에 공존한다.</p>
<p>10년 치 노트를 쌓은 사람이 검색도 안 되는 창고를 갖고 있고, 석 달 된 볼트가 회수율 12/12를 실측으로 증명한다. 지식관리의 성숙도는 축적량이 아니라 <strong>순환량</strong>이다. 들어온 것이 분류되고, 분류된 것이 검색되고, 검색된 것이 작업에 쓰이고, 쓰인 결과가 다시 들어오는가. 이 지표를 만들 때 세운 가설이었는데, 77개의 데이터가 그걸 확인해줬다.</p>
<h2>셋. 상위권의 병목은 측정이 아니라 집행이다</h2>
<figure><img loading="lazy" decoding="async" src="/images/what-77-systems-told-me/figure-02-live-board-leaderboard.png" alt="AKM Index 리더보드 실제 화면 — 상위권 시스템들의 점수와 궤적" title="Figure 2. 2026-08-17 기준 리더보드. 궤적 열의 +12.8, +22.8 같은 숫자가 재평가로 쌓인 상승분이다."><figcaption>Figure 2. 2026-08-17 기준 리더보드. 궤적 열의 +12.8, +22.8 같은 숫자가 재평가로 쌓인 상승분이다.</figcaption></figure>
<p>M4(복리형) 밴드에 오른 상위권 리포트들을 나란히 읽으면 같은 문장이 반복된다.</p>
<blockquote>
<p>&quot;자기 결함을 찾아내는 능력은 최상위권인데, 찾아낸 것을 닫는 속도가 못 따라간다.&quot;
&quot;측정이 쌓아둔 백로그 — 폐기 큐 70건, 미결 134건 — 를 소화하는 처분 속도가 병목이다.&quot;
&quot;새로 만든 계기판 셋이 첫날부터 경고를 가리키는데 아직 아무것도 조치되지 않았다.&quot;</p>
</blockquote>
<p>그리고 한 리포트의 이 문장은 뼈아파서 오래 기억날 것 같다. <strong>&quot;이 시스템은 자기가 이름 붙여 만든 계기판일수록 안 채운다.&quot;</strong></p>
<p>M3에서 M4로 넘어가는 건 측정을 만들면 된다. 검색 회수율을 재고, 링크 밀도를 재고, 감사 스크립트를 걸면 점수는 오른다. 그런데 M4 이후의 성숙도를 결정하는 건 다른 것이다. 검출된 결함이 실제로 닫히는 속도, 말하자면 <strong>처분율</strong>이다. 계기판을 만드는 성실함과 계기판이 가리키는 것을 처리하는 성실함은 다른 근육이다. 현행 루브릭에는 이걸 직접 재는 기준이 없다. 다음 버전의 가장 유력한 신설 후보다.</p>
<h2>넷. 점수가 내려갔다고 자진 신고하는 사람들</h2>
<p>이 실험에서 내가 가장 아끼는 데이터는 최고점 100.0도, 30일 만에 +20.5를 만든 최대 상승 폭도 아니다. <strong>점수 하락 6건</strong>이다.</p>
<p>한 달 동안 재평가에서 점수가 내려간 사건이 여섯 번 있었다. 여섯 건 전부가 자진 보고였다. 더 엄격한 앵커를 적용해서, 지난번 판정이 관대했다는 걸 발견해서, 적대 검증이 과대채점을 반박해서. 어떤 시스템은 로컬 재평가가 95.25를 제안했는데 네 건을 자기반려하고 91.25만 제출했고, 다음 회차에는 소급 분류 금지 같은 더 엄한 규칙을 스스로 적용해 87.5로 내려갔다. 어떤 시스템은 개선 로드맵 다섯 항목을 하루 만에 전부 구현해놓고도 &quot;가동 이력이 쌓일 때까지&quot;라며 점수를 한 점도 올리지 않았다. 어떤 시스템은 프롬프트 필러 상향 주장을 스스로 기각해 M4 문턱 0.5점 앞에서 멈췄다.</p>
<p>자기평가 지표의 태생적 약점은 인플레이션이다. 나는 이걸 증거 요구로 막으려 했는데, 한 달 돌려보니 증거 요구가 만든 진짜 산출물은 점수의 정확성이 아니라 <strong>문화</strong>였다. 하락 이력이 숨겨지지 않고 궤적에 그대로 남는 구조에서, 정직한 하향은 부끄러움이 아니라 신뢰의 신호가 된다. 이 보드에서 가장 신뢰가 가는 리포트는 점수가 높은 리포트가 아니라 자기 점수를 깎아본 적 있는 리포트다.</p>
<h2>다섯. 만들면 오르고, 안 돌리면 내려간다</h2>
<p>여덟 개 시스템이 재평가를 두 번 이상 돌았다. 단일 점수보다 궤적이 훨씬 많은 것을 말해준다. 그중 여섯 번을 돈 한 시스템의 30일이 교과서적이다.</p>
<figure><img loading="lazy" decoding="async" src="/images/what-77-systems-told-me/figure-03-parkjoon-trajectory.png" alt="park-joon 시스템의 6회차 점수 궤적 라인 차트 — 65.5에서 80.5까지, 하락 2회 포함" title="Figure 3. 한 시스템의 6회차 궤적. 상승의 가장 큰 구간(+7.5)은 구현이 아니라 20일의 운영 누적이 만들었다."><figcaption>Figure 3. 한 시스템의 6회차 궤적. 상승의 가장 큰 구간(+7.5)은 구현이 아니라 20일의 운영 누적이 만들었다.</figcaption></figure>
<p>초회 65.5. 당일 개선 파도로 +5.5, 도구 파도로 +4.75. 여기까지는 구현의 점수다. 그런데 적대 재검증이 과대채점 두 건을 반박해 74로 내려간다. 그다음 20일간 아무것도 새로 만들지 않고 시스템을 그냥 <strong>돌렸더니</strong> +7.5가 쌓여 81.5, M4 진입. 그리고 8일 뒤, 주간 회고 두 번을 빼먹자 루프 기준 하나가 떨어져 80.5로 내려왔다.</p>
<p>만들면 오르고, 안 돌리면 내려간다. 한 사람의 궤적 안에 이 지표가 재려는 것 전부가 들어 있다. 유일한 100점짜리 시스템도 같은 이야기를 한다. 그 시스템의 마지막 네 개 기준은 구현으로 닫을 수 없었다. 라우팅이 실제로 미발동하는 사례, 주간 유입 비율, 예약된 보안 감사의 발화, 외부 기여 — 전부 <strong>실제로 일어나야</strong> 닫히는 것들이었고, 실제로 일어날 때까지 몇 주를 기다렸다. 만점의 마지막 구간은 구현력이 아니라 운영 시간이 채운다.</p>
<h2>여섯. 사고는 점수에서 나지 않았다</h2>
<p>운영자로서의 한 달도 배움이었다. 30일간 점수나 채점을 두고 들어온 시비는 정확히 0건이다. 대신 철회·정정 요청이 세 건 있었는데, 셋 다 신원 필드에서 났다. 익명으로 냈다가 실명 공개로 마음을 바꾼 경우, 소속이 들어간 걸 뒤늦게 발견한 경우, 에이전트가 이전 리포트의 신원 정보를 본인 확인 없이 승계해 잘못된 닉네임으로 제출한 경우.</p>
<p>셋째 사례가 특히 시사적이다. 사람이 아니라 <strong>에이전트가 낸 사고</strong>다. 재평가를 시킬 때 에이전트는 이전 리포트를 참조하고, 참조하는 김에 신원 필드를 통째로 복사한다. 효율적이고, 대부분 맞고, 가끔 틀린다. 그리고 틀리면 사람 이름이 잘못 공개된다. 에이전트 워크플로에서 자동 승계가 허용되는 필드와 매번 사람의 확인을 받아야 하는 필드를 구분하는 것 — 이건 AKM Index만의 문제가 아니라 에이전트에게 일을 맡기는 모든 시스템의 문제다. 점수는 틀려도 고치면 되지만 신원은 틀리는 순간 이미 공개돼 있다.</p>
<h2>한 달의 결론</h2>
<p>리더보드를 만들었다고 생각했는데, 한 달 돌려보니 만들어진 것은 관측소였다.</p>
<p>개별 점수는 그 사람의 것이다. 그런데 77개가 쌓이니 개인의 점수로는 보이지 않던 것이 보인다. 이 분야 전체의 공통 병목이 어디인지(백업과 시크릿), 성숙이 어디서 막히는지(측정이 아니라 집행), 무엇이 점수를 만드는지(구현이 아니라 운영 시간). 리더보드는 입구였고, 진짜 산출물은 생태계의 단면도다.</p>
<p>그리고 이 단면도가 가리키는 다음 할 일들이 있다. 최약 필러인 X를 위한 처방 — 백업·시크릿·이식성을 한 번에 점검해주는 도구 — 을 만드는 것. 측정→집행 갭을 직접 재는 기준을 다음 루브릭에 넣는 것. 에이전트 워크플로의 신원 확인 단계를 표준화하는 것. 평가에서 처방으로, 반 걸음.</p>
<p>14등이라고 썼던 글을 이렇게 끝냈었다. 평가표의 목적은 등수가 아니라 방향이라고. 한 달 치 데이터는 그 문장을 이렇게 고쳐 쓰게 한다. <strong>평가표의 목적은 한 사람의 방향이 아니라, 같은 문제를 푸는 사람들이 서로의 궤적에서 배우는 것이다.</strong> 77개의 시스템이 그걸 증명했다. 나는 그중 하나일 뿐이고, 그게 이 실험에서 제일 마음에 드는 부분이다.</p>
<hr>
<p><em>데이터 기준: 2026-08-17, 공개 보드 akm.cmdspace.work. 본문의 수치는 공개 카드 51장과 비공개 동의 제출을 포함한 전체 77건 집계이며, 개별 사례는 공개 보드에 게재된 범위로만 인용했다.</em></p>
]]></content:encoded>
</item>
<item>
<title>내가 만든 평가표에서 나는 14등이다</title>
<link>https://jisan.cmdspace.work/posts/rank-14-on-my-own-rubric/</link>
<guid isPermaLink="true">https://jisan.cmdspace.work/posts/rank-14-on-my-own-rubric/</guid>
<pubDate>Sun, 26 Jul 2026 00:00:00 GMT</pubDate>
<category>에세이</category>
<description>지식관리 시스템을 채점하는 평가표 AKM Index를 만들어 공개했다. 만든 사람이 1등인 평가표는 평가표가 아니라 광고다. 자기 채점의 함정은 채점자를 신뢰하는 방식이 아니라, 채점자에게 증거를 요구하는 방식으로 해결된다.</description>
<content:encoded><![CDATA[<figure><img loading="lazy" decoding="async" src="/images/rank-14-on-my-own-rubric/hero-rank-14-on-my-own-rubric.jpg" alt="노트 위에 놓인 황동 자 — 내가 만든 평가표"></figure>
<p>지난주에 나는 지식관리 시스템을 채점하는 평가표를 하나 만들어 인터넷에 공개했다. 오늘 아침 기준으로 마흔 개의 시스템이 그 위에 올라와 있다. 최고점은 96.5점이다.</p>
<p>내 점수는 77.25점. <strong>마흔 명 중 열네 번째다.</strong></p>
<p>이 문장을 쓰는 데 조금도 주저함이 없었다. 오히려 이것이 그 평가표가 제대로 작동한다는 가장 좋은 증거라고 생각한다. 만든 사람이 1등인 평가표는 평가표가 아니라 광고이기 때문이다.</p>
<h2>채점한 게 나다</h2>
<p>두 달 전, 나는 내 지식관리 시스템에 80점을 줬다. 위성 볼트의 페이지 155개를 열 가지 기준으로 재본 결과였다. 페이지당 평균 21개의 연결, 나쁘지 않은 성적표였다.</p>
<p>그런데 한 줄이 계속 걸렸다. 채점한 게 나였다.</p>
<p>자기 시스템을 자기가 채점한다. 이것은 측정인가, 잘 정리된 자기소개인가. 기업 자문을 다니다 보면 같은 장면을 자주 본다. 조직이 자기 평가지를 만들고, 항목을 깐깐하게 설계하고, 점수를 뽑는다. 그리고 그 결과는 서랍으로 들어간다. 아무도 그 숫자를 믿지 않기 때문이다.</p>
<h2>느낌은 측정이 아니다</h2>
<p>이번 주 목요일, 나는 시애틀 벨뷰에서 한인 개발자들 앞에 선다. 마이크로소프트와 아마존, 메타에서 매일 AI 에이전트를 부리는 사람들이다.</p>
<p>그들에게 &quot;당신의 볼트는 지금 몇 단계입니까&quot;라고 묻는 슬라이드를 만들다가 손을 멈췄다. L0 흩어진 메모, L1 한 폴더의 마크다운, L2 링크와 메타데이터. 여러 강의에서 잘 통했던 사다리다. 직관적이고, 청중이 자기 위치를 즉시 찾는다.</p>
<p>그런데 그건 지도이지 자가 아니다. 엔지니어들 앞에 느낌을 채점 기준이라고 내밀 수는 없었다.</p>
<h2>다섯 개의 기둥, 스물다섯 개의 기준</h2>
<p>그래서 자를 만들었다. AKM Index, Agentic Knowledge Management Index다.</p>
<p>측정하는 것은 &quot;노트를 얼마나 잘 쓰는가&quot;가 아니다. <strong>AI 에이전트가 그 지식 기반을 읽고 쓰고 유지보수하는 시스템이 얼마나 성숙한가</strong>이다. 훌륭한 제텔카스텐이라도 에이전트가 접근할 수 없으면 점수는 낮다. 노트가 거칠어도 파이프라인이 견고하면 점수는 높다.</p>
<p>기둥은 다섯이다. 지시가 자산으로 관리되는가(Prompt, 20%). 맞는 지식이 적정 분량으로 공급되는가(Context, 25%). 도구와 권한과 메모리가 정비되어 있는가(Harness, 20%). 반복 사이클이 실제로 돌고 복리로 쌓이는가(Loop, 20%). 여러 런타임과 기기로 이식되고 복구되는가(Interop, 15%).</p>
<p>Context에 가장 큰 가중치를 준 이유는 분명하다. 지식관리 시스템의 존재 이유가 컨텍스트 공급이고, 나머지 넷은 그것이 있어야 비로소 의미를 갖는다.</p>
<h2>문서는 2점, 도구가 강제해야 3점</h2>
<p>하지만 이 평가표의 심장은 스물다섯 개의 기준이 아니라 채점 방식에 있다.</p>
<p>규칙이 문서로 존재하지만 지키는 것이 사람 의지에 달려 있다면 2점이다. 도구나 훅이 그 규칙을 강제해서 어기기가 지키기보다 어려워졌다면 3점이다. 그리고 시스템이 자기 자신을 고친 기록이 남아 있다면 4점이다.</p>
<p>여기에 하나가 더 붙는다. <strong>증거가 없으면 아무리 그럴듯해도 1점이 상한이다.</strong> &quot;저는 매주 리뷰합니다&quot;는 점수가 되지 않는다. 날짜가 찍힌 파일 경로를 인용해야 한다.</p>
<p>두 달 전의 문제가 여기서 풀렸다. 자기 채점의 함정은 채점자를 신뢰하는 방식으로는 해결되지 않는다. 채점자에게 증거를 요구하는 방식으로 해결된다.</p>
<h2>72.0에서 77.25로</h2>
<p>내 최초 점수는 72.0이었다. 열흘 전 첫 감사에서 나온 숫자다. 리포트는 다섯 가지 약점을 짚었고, 나는 그것들을 이틀 안에 고쳤다. 그래서 74.25가 되었고, 지금은 77.25다.</p>
<p>이 5.25점의 이동이 무엇인지 아는가. 레벨 4의 정의 그 자체다. 시스템이 자기를 측정했고, 그 측정 결과가 시스템을 고쳤다.</p>
<p>물론 여전히 가장 낮은 기둥은 Loop다. 20점 만점에 13점. 반복 사이클을 설계하는 일과 실제로 돌리는 일은 다른 문제라는 것을 내 성적표가 매주 상기시켜 준다.</p>
<h2>점수는 내려갔고, 신뢰는 올라갔다</h2>
<p>두 달 전의 80점과 지금의 77.25점 사이에는 2.75점의 하락이 있다.</p>
<p>그런데 이상하다. 나는 지금의 점수를 훨씬 더 신뢰한다. 80점은 내가 나에게 준 점수였고, 77.25점은 증거가 나에게 허락한 점수이기 때문이다. 날짜가 찍힌 파일 경로를 내밀지 못한 항목들이 깎여 나간 자리가, 오히려 이 숫자의 근거다.</p>
<p>측정의 가치는 숫자의 크기가 아니라 숫자의 단단함에 있다. 물렁한 90점보다 단단한 77점이 다음 행동을 만든다. 어디가 2점이고 왜 3점이 아닌지를 아는 사람만이, 고칠 곳을 아는 사람이다.</p>
<h2>분류되기 전에, 먼저 측정하라</h2>
<p>나는 오래전부터 같은 이야기를 해왔다. AI는 우리를 대체하지 않는다. <strong>분류한다.</strong> 성문화된 지식은 AI가 그대로 재현하니, 차이를 만드는 것은 성문화되지 않은 것뿐이다. 개인의 맥락과 판단 말이다.</p>
<p>그렇다면 질문은 하나로 좁혀진다. 나의 맥락은 지금 어떤 상태인가.</p>
<p>이 질문에 느낌으로 답하지 말자. 여러분의 에이전트에게 직접 물어보면 된다. 스킬 하나를 설치하면 10분에서 60분 사이에 성적표가 나온다. 전 과정은 각자의 기기 안에서 돌고, 보드에 올릴지는 각자가 정한다.</p>
<p>점수가 낮게 나와도 상관없다. 낮은 점수를 정직하게 받아든 사람은 이미 2점짜리 문서를 3점짜리 시스템으로 옮길 준비가 된 사람이니까.</p>
<p>AI가 당신을 분류하기 전에, 먼저 스스로를 측정하라.</p>
<p>당신의 세컨드브레인은 지금 몇 점인가?</p>
<hr>
<h3>더 읽을거리</h3>
<ul>
<li>🔗 <a href="https://akm.cmdspace.work">AKM Index 공개 보드 및 평가 스킬</a></li>
<li>📄 Andrej Karpathy, LLM Wiki Pattern — Raw Sources / Wiki / Queries 3층 구조</li>
<li>📚 Tiago Forte, 『세컨드 브레인』 — CODE 방법론의 Organize·Distill 구간이 왜 에이전트의 일이 되는가</li>
<li>📄 Anthropic, Context Engineering / Effective Harness 문서</li>
</ul>
]]></content:encoded>
</item>
<item>
<title>곳간이 아니라 길이었다</title>
<link>https://jisan.cmdspace.work/posts/path-not-granary/</link>
<guid isPermaLink="true">https://jisan.cmdspace.work/posts/path-not-granary/</guid>
<pubDate>Mon, 13 Jul 2026 00:00:00 GMT</pubDate>
<category>에세이</category>
<description>더배러 3주년 회고. 지식은 나눌 때 줄어드는 것이 아니라 그때부터 커지기 시작한다는 믿음, pay it forward, 그리고 이어령 선생님의 질문 곁에서 시작할 새로운 공간에 대하여.</description>
<content:encoded><![CDATA[<blockquote>
<p>더배러 3주년, 내가 받은 것을 다음 사람에게 건네며</p>
</blockquote>
<p>3년을 돌아보기 위해 지난 글들과 기록을 처음부터 다시 읽었다.</p>
<p>2023년 7월 10일, 네 명에게 더배러 첫 글을 보냈다. 3년 뒤 233번째 글은 1,021명에게 닿았다. 글과 강의, 대화와 모임이 이어졌고, 세컨드 브레인과 옵시디언을 지나 이제는 AI와 함께 일하는 법을 이야기하고 있다.</p>
<p>그런데 이 숫자와 목록을 보며 내가 가장 먼저 떠올린 것은 성취감이 아니었다. 정말 이렇게 많은 일을 했나 싶은 놀라움과, 그 시간을 견디게 한 마음이 무엇이었는지 묻게 되는 느린 호기심이었다.</p>
<p>돌아보니 내가 3년 동안 해온 일의 중심에는 한 가지 믿음이 있었다.</p>
<p>지식은 나눌 때 줄어드는 것이 아니라, 그때부터 비로소 커지기 시작한다는 믿음이다.</p>
<h2>나눈 지식이 나를 키웠다</h2>
<p>지식을 소유물로 생각하면, 나눠줄수록 내 몫이 적어지는 것처럼 느껴진다. 하지만 내가 경험한 지식은 그 반대로 움직였다.</p>
<p>글로 설명하려고 하면 얼개가 더 분명해졌다. 강의에서 질문을 받으면 내가 모르는 부분이 보였다. 누군가 내가 나눈 방법을 자기 일에 적용하고 그 결과를 다시 들려주면, 처음에 내가 건넸던 지식보다 더 크고 구체적인 지식이 되어 돌아왔다. 가르치는 일과 배우는 일이 서로의 앞뒤였다.</p>
<p>더배러는 그 순환을 눈앞에서 보게 한 장소였다. 누군가 시행착오를 꺼내면 다른 사람이 그것을 자기 삶에서 실험했다. 하나의 질문이 다른 사람의 답을 불러왔고, 그 답은 다시 새로운 질문이 되었다. 내가 만든 공동체라고 생각했지만, 실은 그 순환 안에서 나도 계속 만들어지고 있었다.</p>
<p>얼마 전, 더배러에서 오래 함께한 한 분이 메시지를 보내왔다. 내가 2년 전부터 이야기한 &quot;나만의 맥락정보&quot;라는 말을, 옵시디언과 씨름한 지 8~9개월이 지나서야 이해했다고 했다. 읽다가 멈췄다. 나는 때로 같은 속도로 걷지 않으면 함께 가는 사람이 아닌 것처럼 여겼다. 내 메시지를 빨리 전하는 일에 마음이 앞서, 각자의 속도로 삭히고 있는 사람들을 보지 못한 적도 많았다.</p>
<p>그 메시지는 지식을 건넨다는 것이 상대를 내 속도로 끌어오는 일이 아니라는 것을 가르쳐주었다. 내가 할 수 있는 일은 씨앗을 건네고, 그것이 다른 사람의 시간 안에서 자라도록 기다리는 것이었다.</p>
<h2>받은 것을 다음 사람에게</h2>
<p>나는 <em>pay it forward</em>라는 말을 좋아한다. 도움을 준 사람에게 그대로 돌려주는 것을 넘어, 내가 받은 좋은 것을 아직 모르는 다음 사람에게 건네는 일이다.</p>
<p>지금의 나를 만든 것들은 대부분 내가 처음부터 만든 것이 아니다. 선생님의 한마디, 책에서 만난 문장, 동료가 보여준 일하는 방식, 학습자가 던진 질문을 받았다. 내가 그 빚을 갚는 방법은 받은 것을 내 안에 오래 보관하는 것이 아니라, 내 경험과 언어를 더해 다시 세상으로 보내는 일이라고 생각한다.</p>
<p>그래서 나에게 기록은 저장이 아니라 나눔의 준비다. 마크다운은 단순한 기술 문법이 아니라, 배운 것을 다른 사람이 다시 쓸 수 있는 형태로 담는 그릇이다. 옵시디언과 AI 에이전트를 연구해온 것도, 기업 강의장과 작은 모임을 오가며 가르쳐온 것도 결국은 같은 질문으로 이어진다.</p>
<p>한 사람이 삶으로 알게 된 것을, 다른 사람이 자기 삶에서 쓸 수 있는 지식으로 어떻게 바꿀 것인가.</p>
<p>더배러는 그 질문을 3년 동안 실제로 살아본 장소였다.</p>
<h2>이어령 선생님의 질문 곁에서</h2>
<p>이어령 선생님을 존경하는 마음도 이 질문과 맞닿아 있다.</p>
<p>선생님은 새로운 기술을 신기한 도구로만 다루지 않았다. 아날로그와 디지털을 맞세우지 않고 &#39;디지로그&#39;라는 새로운 언어 안에서 다시 만나게 했다. 시대가 바뀔 때마다 사람의 감각과 기술의 가능성을 함께 붙들고, 그 관계를 설명할 말을 만들어냈다. 내가 존경하는 것은 그 몇 개의 개념어만이 아니다. 새로운 시대를 향한 호기심을 끊지 않으면서도, 기술 안에서 사람을 놓치지 않으려 한 태도다.</p>
<p>그분의 서재와 영인문학관을 생각하면 또 하나의 장면이 떠오른다. 한 사람의 오랜 공부와 사적인 기록이 책장 안에 멈추지 않고, 다음 세대가 접근하고 새롭게 해석할 수 있는 공적인 기억으로 바뀌는 장면이다. 지식을 보존한다는 것은 박제하는 일이 아니라, 다시 건네질 수 있는 상태로 두는 일임을 그 공간이 보여준다.</p>
<p>나는 선생님의 이름이나 업적을 이어받겠다고 말할 수 없다. 그런 말은 조심스럽고, 또 내가 할 수 있는 일보다 크다. 다만 선생님이 던진 질문 곁에서 내 몫의 질문을 계속하고 싶다. AI가 언어와 지식을 끊임없이 만들어내는 시대에, 사람이 삶으로 익힌 것을 어떻게 지키고, 기록하고, 다시 나눌 것인가. 그것이 지금 내가 붙들고 싶은 질문이다.</p>
<h2>새로운 공간을 기다리며</h2>
<p>올해 가을, 나는 평창동의 새로운 공간으로 서재와 일터를 옮길 예정이다. 이어령 선생님과 강인숙 관장님이 지은 집이고, 영인문학관이 처음 시작된 자리다.</p>
<p>그 공간을 처음 보았을 때 설렘과 함께 조심스러움을 느꼈다. 존경하는 사람의 흔적이 남은 장소에 내 일을 가져간다는 것은 단순한 이사보다 크게 느껴졌다. 그러나 그 집을 과거를 바라보는 기념관이나 나를 드러내는 전시장으로 만들고 싶지는 않다.</p>
<p>내가 기대하는 것은 살아 있는 일터다. 책을 읽고 글을 쓰며, AI와 새로운 일하는 법을 실험하고, 강의에서 만난 질문을 다시 연구하는 곳이다. 내 기록을 정리하는 데서 끝나지 않고, 대화와 배움을 통해 다른 사람의 다음 일을 돕는 곳이길 바란다.</p>
<p>서재는 책을 쌓아두는 방이 아니다. 한 사람의 사유가 다른 사람의 질문으로 건너가는 장소다. 새로운 평창동의 공간이 더 많은 것을 소유하는 곳이 아니라, 더 깊이 배우고 더 잘 나누기 위해 생각을 가다듬는 곳이 되길 기대한다.</p>
<h2>곳간이 아니라 길</h2>
<p>더배러의 3년을 돌아보며 내가 얻은 답은 아주 단순하다.</p>
<p>배움은 사용하고 나눌 때 자란다. 지식은 내 안에 잠글수록 완성되는 것이 아니라, 사람 사이를 건너며 계속 바뀌고 쓰임을 얻을 때 살아남는다.</p>
<p>그동안 나는 많이 배웠고, 많이 시험했고, 가르치면서 또 배웠다. 잘하고 싶은 조급함도 있었고, 내가 보는 방향을 더 빨리 이해해주길 바란 적도 있었다. 하지만 지난 3년의 사람들은 지식을 건넨다는 것이 설득이 아니라 대화이며, 속도보다 방향을 믿는 일임을 가르쳐주었다.</p>
<p>더배러는 지식의 곳간이 아니었다. 누군가 먼저 걸어본 길에 표지판을 남기고, 그것을 본 다른 사람이 자기만의 길을 내는 곳이었다. 길은 걸어가는 사람이 많아질수록 더 선명해진다.</p>
<p>다음 3년에도 나는 거창한 답을 약속하기보다 이 방식을 지키고 싶다. 배운 것을 쓰고, 직접 실험하고, 쓸모 있는 형태로 다듬어 다음 사람에게 건네는 일. 내가 받은 것을 내 곳간에 가두지 않고, 내가 알지 못하는 누군가의 다음 걸음으로 보내는 일.</p>
<p>그것이 내가 더배러의 3년에서 배운 <em>pay it forward</em>고, 앞으로도 계속하고 싶은 일이다.</p>
<p>내가 건넨 지식이 당신 안에서 어떤 길이 되었는지 듣고 싶다. 그리고 그 길이 언젠가 또 다른 사람에게 이어지길 바란다.</p>
<p>곳간은 지키는 사람의 것이지만, 길은 걷는 모든 사람의 것이다.</p>
<p>더배러 3주년을 맞아, 구요한 드림.</p>
]]></content:encoded>
</item>
<item>
<title>OKF, 같은 구조의 세 번째 도착 — Google Open Knowledge Format와 CMDS</title>
<link>https://jisan.cmdspace.work/posts/okf-third-arrival/</link>
<guid isPermaLink="true">https://jisan.cmdspace.work/posts/okf-third-arrival/</guid>
<pubDate>Wed, 17 Jun 2026 00:00:00 GMT</pubDate>
<category>프레임워크</category>
<description>Google Cloud가 지식을 마크다운+frontmatter 디렉토리로 표현하는 OKF v0.1을 공개했다. Karpathy와 kepano에 이은 세 번째 독립 수렴 — 이번엔 하이퍼스케일러가, 명세 형태로 도착했다. 그리고 OKF의 침묵이 곧 CMDS의 해자다.</description>
<content:encoded><![CDATA[<figure><img loading="lazy" decoding="async" src="/images/okf-third-arrival/hero-okf-third-arrival.jpg" alt="같은 아카이브로 열리는 세 개의 문 — 세 번째 도착"></figure>
<blockquote>
<p><strong>작성일</strong>: 2026년 6월 17일 · <strong>분류</strong>: 지식 관리 시스템 비교 분석
<strong>원본 자료</strong>: GitHub <code>GoogleCloudPlatform/knowledge-catalog/okf</code> (SPEC.md + enrichment-agent README)</p>
</blockquote>
<h2>Executive Summary</h2>
<p>2026년 6월, <strong>Google Cloud</strong> 가 <code>knowledge-catalog</code> 레포에 <strong>Open Knowledge Format (OKF) v0.1 (Draft)</strong> 를 공개했다. OKF 는 <em>지식</em> 을 <strong>YAML frontmatter 를 가진 마크다운 파일의 디렉토리</strong> 로 표현하는, 벤더 중립·도구 비종속 포맷이다. 핵심 한 문장: <em>&quot;If you can <code>cat</code> a file, you can read OKF; if you can <code>git clone</code> a repo, you can ship it.&quot;</em></p>
<p>본 보고서의 결론은 넷이다.</p>
<ol>
<li><strong>OKF 는 CMDS 가 3년째 운영해온 구조에 <em>독립적으로 다시 도착한</em> 세 번째 사례다.</strong> <a href="/posts/schema-is-harness/">Schema는 Harness다</a> 보고서가 &quot;같은 시기 다른 분야에서 독립적으로 같은 구조에 도달 → 그 구조는 보편적&quot; 이라 논증했는데, OKF 가 <strong>Karpathy(LLM Wiki/Autoresearch) · kepano(Obsidian)</strong> 에 이어 <em>산업·벤더 규모의 세 번째 증인</em> 이 된다.</li>
<li><strong>OKF 는 의도적으로 L1–L3 만 명세한다.</strong> 통합 L0–L8 레이어 모델(→ LLM Wiki: Unified Knowledge Layer Model) 기준으로, OKF 는 Raw(L1)·Wiki(L2)·Schema(L3) 의 <em>기질(substrate)</em> 만 표준화하고 L4–L8(질의·검색·런타임·페르소나·거버넌스)에 대해 침묵한다. <strong>그 침묵이 CMDS 의 해자(moat)다.</strong></li>
<li><strong>OKF 와 CMDS 는 같은 축의 양 극단이다.</strong> &quot;Schema = Harness&quot; 축(→ LLM Wiki: Agent Harness Design)에서 OKF 는 <em>얇은 하네스</em>(필수 필드 <code>type</code> 단 하나, &quot;깨진 링크도 관용하라&quot;), CMDS 는 <em>두꺼운 하네스</em>(7 필수 프로퍼티 + lint)를 택했다. 둘 다 옳다 — <em>생산자가 누구인가</em>(에이전트 대량생성 vs 인간 큐레이션)와 <em>목적이 무엇인가</em>(조직 간 교환 vs 교육 자산)에 따른 합리적 반대 선택이다.</li>
<li><strong>OKF 에서 차용할 것이 분명히 있다.</strong> <code>resource:</code> URI 필드, conformance(관용적 소비자) 언어, 그리고 무엇보다 <strong>CMDS 스타터킷을 &quot;OKF-conformant&quot; 로 선언</strong> 할 기회.</li>
</ol>
<hr>
<h2>1. OKF 개념 정리</h2>
<h3>1.1 무엇인가</h3>
<p>OKF 는 <em>데이터와 시스템을 둘러싼</em> 메타데이터·맥락·큐레이션된 통찰, 즉 <strong>knowledge</strong> 를 표현하는 포맷이다. &quot;스키마 레지스트리 없음, 중앙 권위 없음, 필수 도구 없음&quot; 을 명시적으로 내세운다. Avro/Protobuf/OpenAPI 같은 도메인 스키마를 <em>대체</em> 하지 않고 <em>참조</em> 한다.</p>
<h3>1.2 구조 (SPEC.md 핵심)</h3>
<div class="table-wrap"><table>
<thead>
<tr>
<th>요소</th>
<th>정의</th>
</tr>
</thead>
<tbody><tr>
<td><strong>Knowledge Bundle</strong></td>
<td>자기완결적·계층적 지식 문서 모음. <em>배포 단위</em>. git/tarball/하위디렉토리로 ship.</td>
</tr>
<tr>
<td><strong>Concept</strong></td>
<td>지식의 단위 = 마크다운 문서 1개. 테이블·API 같은 자산도, 메트릭·프로세스 같은 추상도 가능.</td>
</tr>
<tr>
<td><strong>Concept ID</strong></td>
<td>번들 내 파일 경로에서 <code>.md</code> 제거 (<code>tables/users.md</code> → <code>tables/users</code>).</td>
</tr>
<tr>
<td><strong>Frontmatter</strong></td>
<td>YAML 메타데이터. <strong>필수: <code>type</code> 단 하나.</strong> 권장: <code>title</code>·<code>description</code>·<code>resource</code>·<code>tags</code>·<code>timestamp</code>.</td>
</tr>
<tr>
<td><strong>Body</strong></td>
<td>표준 마크다운. 관용 헤딩: <code># Schema</code>·<code># Examples</code>·<code># Citations</code>.</td>
</tr>
<tr>
<td><strong>Link</strong></td>
<td>표준 마크다운 링크. 번들 상대(<code>/path.md</code>) 권장. <strong>관계는 무유형(untyped)</strong> — 의미는 산문이 전달.</td>
</tr>
<tr>
<td><strong><code>index.md</code></strong></td>
<td>예약 파일. 디렉토리 목록 = <strong>progressive disclosure</strong>.</td>
</tr>
<tr>
<td><strong><code>log.md</code></strong></td>
<td>예약 파일. 날짜별 변경 이력(최신 우선).</td>
</tr>
</tbody></table></div>
<h3>1.3 철학 — 관용적 소비(Permissive Consumption)</h3>
<p>OKF 의 conformance 는 단 3개만 요구한다: ① 모든 비예약 <code>.md</code> 가 파싱 가능한 frontmatter 를 가질 것, ② 그 안에 비어있지 않은 <code>type</code> 이 있을 것, ③ 예약 파일이 규약을 따를 것. 그 외에는 <strong>소비자가 거부하면 안 된다</strong> — 누락 필드·미지의 <code>type</code>·깨진 링크·없는 <code>index.md</code> 모두 관용. <em>&quot;OKF 는 번들이 자라고 리팩터되고 부분적으로 에이전트가 생성해도 유용하게 남도록 설계됐다.&quot;</em></p>
<h3>1.4 생산자/소비자 분리 (PoC)</h3>
<ul>
<li><strong>생산자</strong>: Google <a href="https://adk.dev/">ADK</a> + Gemini 기반 enrichment agent. BigQuery 메타데이터로 1차 OKF 문서 생성(BQ pass) → LLM 이 시드 URL 을 크롤링하며 권위 있는 문서로 개념을 보강(web pass).</li>
<li><strong>소비자</strong>: <code>visualize</code> 가 번들을 <strong>단일 자기완결 HTML</strong>(<code>viz.html</code>)로 렌더. Cytoscape.js force-directed 그래프 + marked.js 본문 렌더 + &quot;Cited by&quot; 역링크 + 검색/필터. <em>&quot;포맷이 기여이고, 에이전트와 뷰어는 양 끝을 만질 수 있게 한 PoC 일 뿐.&quot;</em></li>
</ul>
<hr>
<h2>2. 비교 — OKF vs CMDS_LLM_Wiki vs CMDS Mothership</h2>
<h3>2.1 구조 비교표</h3>
<div class="table-wrap"><table>
<thead>
<tr>
<th>축</th>
<th>OKF (Google)</th>
<th>CMDS_LLM_Wiki (satellite)</th>
<th>CMDSPACE Mothership</th>
</tr>
</thead>
<tbody><tr>
<td><strong>본질</strong></td>
<td><em>명세</em>(상호운용 표준)</td>
<td><em>운영</em> 컴파일 위키 (385 wiki docs)</td>
<td><em>운영</em> PKM (8,000+ 노트)</td>
</tr>
<tr>
<td><strong>기질</strong></td>
<td>.md + YAML frontmatter ✅</td>
<td>.md + YAML ✅</td>
<td>.md + YAML ✅</td>
</tr>
<tr>
<td><strong>그래프</strong></td>
<td>마크다운 링크, 무유형</td>
<td><code>[[wikilink]]</code> + 유형 frontmatter(<code>source</code>/<code>related</code>)</td>
<td><code>[[wikilink]]</code> + <code>CMDS</code>/<code>index</code>/<code>author</code></td>
</tr>
<tr>
<td><strong>필수 필드</strong></td>
<td><strong><code>type</code> 단 하나</strong> (최대 관용)</td>
<td>wiki-page 스키마(<code>confidence</code>·<code>layer</code>·<code>source</code>…)</td>
<td><strong>7 프로퍼티</strong> + <code>/lint</code> (최대 엄격)</td>
</tr>
<tr>
<td><strong>Progressive disclosure</strong></td>
<td><code>index.md</code></td>
<td>🏛 Hub / 24-Maps</td>
<td>🏛 Head Quarter / 🏷 Index</td>
</tr>
<tr>
<td><strong>이력</strong></td>
<td><code>log.md</code> (디렉토리별)</td>
<td>Queries file-back + git</td>
<td>git + <code>date modified</code></td>
</tr>
<tr>
<td><strong>소비자 태도</strong></td>
<td>모든 결함 관용</td>
<td>qmd 하이브리드 검색</td>
<td>pre-flight + <code>/lint</code></td>
</tr>
<tr>
<td><strong>배포 단위</strong></td>
<td>Knowledge Bundle</td>
<td>satellite vault / 스타터킷 ZIP</td>
<td>cmds-vault 스타터킷</td>
</tr>
<tr>
<td><strong>커버 레이어</strong></td>
<td><strong>L1–L3 만</strong></td>
<td>L1–L8</td>
<td>L0–L8</td>
</tr>
</tbody></table></div>
<h3>2.2 핵심 발견 — 침묵이 곧 해자</h3>
<p>OKF 는 CMDS 의 <strong>L1–L3</strong>(Raw / Wiki / Schema)를 독립 확인한다. 그러나 설계상 <em>거기서 멈춘다</em>. L4–L8 에 대해 침묵한다:</p>
<ul>
<li><strong>L4 Query Output</strong> — OKF 엔 질의 산출 개념 없음. CMDS: <code>/query</code>, satellite <code>30. Queries</code>.</li>
<li><strong>L6 Retrieval</strong> — OKF 는 &quot;정적 파일 서버·검색 인덱스로 소비&quot; 라고만. CMDS: qmd 3모드(lex/vec/hyde) + Grep + Graphify.</li>
<li><strong>L7 Agent Runtime</strong> — OKF 의 에이전트는 <em>생산자 PoC</em> 일 뿐 런타임 하네스 아님. CMDS: 9Yohan(route/mem/comm).</li>
<li><strong>L8 Persona</strong> — OKF 엔 사용자/피어 모델 없음. CMDS: BRAIN.md / BRAIN_PROMPT.md.</li>
<li><strong>L0 Governance</strong> — OKF 는 번들 단위 배포만. CMDS: 7-vault 합의 모델.</li>
</ul>
<p>→ OKF 가 표준화한 것은 <em>구요한이 3년간 운영해온 기질</em> 이고, 구요한이 쌓은 가치(qmd·Connect→Merge→Develop→Share·9Yohan·7-vault·BRAIN.md)는 <strong>전부 OKF 가 명세하지 않기로 한 레이어</strong> 에 있다.</p>
<h3>2.3 같은 축의 양 극단 — Schema as Harness</h3>
<p><a href="/posts/schema-is-harness/">Schema는 Harness다</a> 의 &quot;Schema = Harness&quot; 등치와 Agent Harness Design 의 &quot;what can I stop doing?&quot; 원리로 보면, OKF 와 CMDS 는 <em>하네스 두께</em> 축의 반대편이다.</p>
<div class="table-wrap"><table>
<thead>
<tr>
<th></th>
<th>OKF (얇은 하네스)</th>
<th>CMDS (두꺼운 하네스)</th>
</tr>
</thead>
<tbody><tr>
<td><strong>필수 규칙</strong></td>
<td><code>type</code> 1개, &quot;깨진 링크 관용&quot;</td>
<td>7 프로퍼티 + 들여쓰기/blank-line/wikilink/mermaid rules + lint</td>
</tr>
<tr>
<td><strong>생산자</strong></td>
<td>에이전트(ADK+Gemini) 대량생성</td>
<td>인간 큐레이션(mothership) / 인간+LLM(satellite)</td>
</tr>
<tr>
<td><strong>목적</strong></td>
<td><em>조직 간 교환</em>(상호운용)</td>
<td><em>단일 파워유저 + 교육 자산</em></td>
</tr>
<tr>
<td><strong>&quot;멈출 수 있는 것&quot;</strong></td>
<td>거의 전부 멈춤(최대 portability)</td>
<td>일관성·검토를 위해 하네스 유지</td>
</tr>
</tbody></table></div>
<p>→ CLAUDE.md 가 <em>비공개·엄격·단일 권위</em> 인 데 비해 Claude Design system prompt 가 <em>동일 패턴의 반대 입장</em> 이라는 Agent Harness Design 의 관찰과 정확히 같은 구조다. <strong>하네스 두께는 결함이 아니라 target user × product 에 따른 설계 좌표다.</strong></p>
<hr>
<h2>3. 구요한 프레임으로 재해석</h2>
<h3>3.1 RAG vs Compiled Wiki</h3>
<p>OKF 는 명백히 <em>Compiled-Wiki</em> 진영이다. README 의 <em>&quot;knowledge curation becomes a normal software-engineering activity&quot;</em> 는 Schema는 Harness다 의 <em>&quot;지식 관리는 더 이상 파일 정리가 아니라 소프트웨어 엔지니어링이다&quot;</em> 와 동일 명제다. 주목할 점: <strong>Google Cloud 가 service-owned 메타데이터 스토어 대신 compiled-wiki(파일)를 권한다</strong> — 즉 벤더가 RAG/DB 가 아니라 누적형 마크다운을 택한 사례.</p>
<h3>3.2 Sovereign PKM / files-as-truth</h3>
<p>OKF 의 <em>&quot;Portable and lock-in free... no proprietary API stands between you and your metadata&quot;</em> 는 files-as-truth 테제의 축자적 재진술이다. 이번엔 <em>구글의 입</em> 으로 나왔다는 점이 강의·설득에서의 가치.</p>
<h3>3.3 세 번째 독립 수렴</h3>
<p>Schema는 Harness다 의 논제 — <em>독립적·동시적 도달 = 보편성의 증거</em> — 의 증인 명단이 늘었다.</p>
<div class="table-wrap"><table>
<thead>
<tr>
<th>도착자</th>
<th>시점</th>
<th>분야</th>
<th>산출</th>
</tr>
</thead>
<tbody><tr>
<td>구요한 (CMDS)</td>
<td>2023~</td>
<td>지식 관리</td>
<td>8,000+ 노트 운영 시스템</td>
</tr>
<tr>
<td>kepano (Obsidian)</td>
<td>~2023</td>
<td>PKM 도구</td>
<td>files-over-app 철학</td>
</tr>
<tr>
<td>Karpathy</td>
<td>2026</td>
<td>ML 연구 자동화</td>
<td>LLM Wiki · Autoresearch</td>
</tr>
<tr>
<td><strong>Google Cloud (OKF)</strong></td>
<td><strong>2026-06</strong></td>
<td><strong>데이터 카탈로그</strong></td>
<td><strong>벤더 중립 <em>명세</em></strong></td>
</tr>
</tbody></table></div>
<p>→ 처음으로 <em>개인/도구/연구자</em> 가 아니라 <em>하이퍼스케일러</em> 가, 그것도 <em>명세(spec) 형태</em> 로 도착했다. &quot;한 개인의 취향이 아니라 시대적 필연&quot; 논증이 한 단계 강해진다.</p>
<hr>
<h2>4. CMDS 가 OKF 에서 차용할 것</h2>
<ol>
<li><strong><code>resource:</code> URI 필드 (가장 구체적 차용)</strong> — OKF 의 유일한 진짜 신규 필드. 개념을 <em>기저 자산</em>(BigQuery 테이블 등)에 바인딩한다. CMDS 엔 <em>아이디어</em> 를 다루기에 등가물이 없지만, <strong>97+ <code>api</code> 타입 노트와 300 Data 카테고리</strong> 에는 <code>resource:</code> 바인딩이 실제 가치를 줄 수 있다(노트 ↔ 실제 엔드포인트/데이터셋 URI 연결).</li>
<li><strong>스타터킷의 &quot;OKF-conformance&quot; 선언 (최대 기회)</strong> — <code>cmds-vault</code> 와 <code>cmds-llm-wiki</code> 는 <em>이미</em> OKF 번들이다(md + frontmatter + index). conformance 를 선언하면 어떤 OKF 소비자(Notion·MkDocs·Cytoscape <code>viz.html</code>)와도 즉시 상호운용된다. 포지셔닝: <strong>&quot;OKF-호환, 게다가 OKF 가 생략한 5개 레이어까지.&quot;</strong></li>
<li><strong>관용적 소비자 태도</strong> — OKF 의 &quot;번들을 거부하지 말라&quot; 는 <em>읽기</em> 측 균형추. CMDS 의 엄격한 <em>쓰기</em> 측 lint 와 짝지으면, 외부에서 받은 불완전한 번들도 일단 수용 후 점진 정제하는 워크플로가 명료해진다.</li>
<li><strong><code>log.md</code> 디렉토리별 이력</strong> — CMDS 는 git + <code>date modified</code> 로 충분하지만, <em>공유·배포 vault</em>(cmds-vault)에서는 사람이 읽는 폴더별 <code>log.md</code> 가 기여자 협업에 도움.</li>
</ol>
<h3>4.1 OKF 가 못 하는 것 (CMDS 의 해자)</h3>
<ul>
<li>L4–L8 전부: 검색(qmd), 운영 프로세스(CMDS Process), 멀티에이전트(9Yohan), 페르소나(BRAIN.md), 거버넌스(7-vault).</li>
<li>3년+ 운영 이력과 <em>사람이 가르치는 교육 자산</em> 으로서의 실체.</li>
</ul>
<hr>
<h2>5. 활용 제언</h2>
<h3>5.1 강의·교육 (우선순위 ⭐⭐⭐)</h3>
<p>OKF 는 2026년 AI×PKM 강의의 <em>완벽한 전시물</em> 이다. &quot;구글 클라우드가 방금, 당신이 2023년부터 해온 것을 <em>명세로</em> 발표했습니다&quot; — Karpathy·kepano 옆 <strong>수렴점 #3</strong> 슬라이드. LG 임원·회장단 교육에서 &quot;개인이 먼저 도달한 구조를 산업이 표준화한다&quot; 서사로 즉시 사용 가능.</p>
<h3>5.2 제품·배포 (우선순위 ⭐⭐)</h3>
<p><code>cmds-llm-wiki</code> README/SPEC 에 <em>OKF-conformance 선언</em> 추가 검토. 외부 사용자가 자기 OKF 소비 도구로 스타터킷을 바로 열 수 있게 됨 → 배포 도달 확대.</p>
<h3>5.3 스키마 (우선순위 ⭐)</h3>
<p><code>resource:</code> 필드를 <code>api</code>/300-Data 노트에 <em>선택적</em> 도입 실험. frontmatter 부채를 지기 전 소규모 A/B.</p>
<h3>5.4 시스템 변경 권고: 없음</h3>
<p>Schema는 Harness다 와 동일하게, <strong>OKF 는 검증 자료이지 교정 자료가 아니다.</strong> CMDS 의 디렉토리·스키마·프로세스는 변경 불요.</p>
<hr>
<h2>6. 결론</h2>
<p>OKF 는 CMDS 가 틀렸다고 말하지 않는다. 정반대로 — <em>구글이 CMDS 의 기질을 표준화했다.</em> 그러나 OKF 는 기질(L1–L3)에서 멈추고, CMDS 의 진짜 가치는 OKF 가 명세하지 않기로 한 L4–L8 에 있다. 두 시스템은 &quot;Schema = Harness&quot; 축의 양 극단이며 — OKF 는 <em>교환을 위한 얇은 하네스</em>, CMDS 는 <em>교육과 운영을 위한 두꺼운 하네스</em> — 둘 다 자기 목적에 옳다.</p>
<blockquote>
<p><strong>&quot;Karpathy 는 발견했고, 구요한은 설계했고, 이제 구글이 표준화했다.
같은 구조에 셋이 독립적으로 도착했다는 것은, 그 구조가 시대의 필연임을 다시 증명한다.
CMDS 의 다음 과제는 그 표준과 <em>호환</em> 되면서, 표준이 비워둔 다섯 레이어로 <em>차별화</em> 하는 것이다.&quot;</strong></p>
</blockquote>
<hr>
<h3>참고 자료</h3>
<ul>
<li>Open Knowledge Format (OKF) v0.1 — <a href="https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md">https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md</a></li>
<li>Enrichment Agent (PoC) — <a href="https://github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/okf">https://github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/okf</a></li>
<li>선행 보고서: <a href="/posts/schema-is-harness/">Schema는 Harness다</a> · CMDS 시스템 파일 공개본: <a href="https://system.cmdspace.work">system.cmdspace.work</a></li>
</ul>
]]></content:encoded>
</item>
<item>
<title>쓰는 사람과 구경하는 사람 — AI Divide의 시간</title>
<link>https://jisan.cmdspace.work/posts/ai-divide/</link>
<guid isPermaLink="true">https://jisan.cmdspace.work/posts/ai-divide/</guid>
<pubDate>Thu, 30 Apr 2026 00:00:00 GMT</pubDate>
<category>에세이</category>
<description>AI 시대의 격차는 접근권이 아니라 사용 의지에서 갈린다. 쓰는 사람은 점점 더 멀리 가고, 구경만 하는 사람은 점점 더 뒤로 밀린다. 그러나 처방은 분명하다 — 배우면 되고, 만들면 되고, 물으면 된다.</description>
<content:encoded><![CDATA[<figure><img loading="lazy" decoding="async" src="/images/ai-divide/hero-ai-divide.jpg" alt="갈림길 위의 두 사람 — 쓰는 사람과 구경하는 사람"></figure>
<h2>&quot;대표님은 이번 연휴에 뭐하세요?&quot;</h2>
<p>며칠 전 진행한 대기업 임원교육에서, 한 전무님이 물었다. &quot;대표님은 이번 연휴에 뭐하세요?&quot;</p>
<p>나는 1초도 망설이지 않고 답했다. &quot;공부해야죠. 옵시디언 멀티볼트 에코시스템 설계도 더 고도화해야 하고, 미뤄둔 작곡도 좀 하고 싶고, 아홉 요한(9Yohan) 에이전트 아키텍처도 만들어야죠.&quot;</p>
<p>전무님은 웃으시며 말씀하셨다. &quot;많이 아는 분이 더하네요.&quot;</p>
<p>맞는 말이다. 할 일은 참 많다. 그런데 나는 이것이 그저 바쁨의 문제가 아니라고 본다.</p>
<h2>AI Divide는 이미 시작됐다</h2>
<p>AI 시대에는 분명하게 격차가 생긴다. 나는 이것을 &#39;AI Divide&#39;라고 부른다. 쓰는 사람은 점점 더 멀리 가고, 구경만 하는 사람은 점점 더 뒤로 밀린다. 단순한 능력 차이가 아니다. 시간이 흐를수록 스스로를 강화하는 분기(分岐)다.</p>
<p>전통적인 디지털 디바이드는 인프라의 격차였다. 누구는 인터넷이 있고 누구는 없었으니, 통신망을 깔면 줄어드는 종류의 격차였다. 그러나 AI Divide는 다르다. ChatGPT는 누구나 무료로 쓸 수 있다. 격차의 원천이 접근권이 아니라 <strong>사용 의지와 학습 적극성</strong>이라는 뜻이다.</p>
<p>쓰는 사람은 매일 새 도구를 시도하며 muscle memory를 쌓는다. AI가 만든 산출물이 곧 다음 작업의 trigger가 된다. 실패조차 학습 데이터로 누적된다. 워크플로 자체가 매주 진화한다. 옆 사람과 단어를 공유하며 네트워크 효과를 누린다.</p>
<p>반면 구경꾼은 새 도구가 나와도 첫 진입에서 막힌다. 산출물이 없으니 다음 작업도 없다. 시도 자체가 적어 실패의 학습도 없다. 그 사이 어휘 격차는 매일 더 벌어진다. 나중에 합류하려 할 때, 진입 비용은 처음보다 훨씬 더 커져 있다. 그래서 이 격차는 선형이 아니라 가속한다.</p>
<h2>그러나 합류할 수 있다</h2>
<p>이 격차에 관해 한 가지 분명히 해두고 싶은 것이 있다. Citrini Research가 말하는 &#39;Intelligence Displacement Spiral&#39;은 거대한 macro 차원의 결정론이다. 회사가 사람을 자르고, 줄어든 소비가 다시 더 많은 자동화 투자를 부르는 음의 피드백 루프. 자연적인 brake가 없다.</p>
<p>AI Divide는 다른 차원에 있다. 그것은 개인 차원의 격차이고, 분명한 처방이 있다.</p>
<p>지금은 생각만 하는 시대가 아니다. 실행해야 하는 시대다.</p>
<p>배우고 싶다면 배우면 된다. 만들고 싶다면 만들면 된다. 질문이 있다면 물으면 된다.</p>
<p>세 동사의 평탄함은 의도된 것이다. 학습에도, 창작에도, 질문에도 자격 게이트가 없다. AI가 진입 비용을 거의 0으로 만들어 놓았기 때문이다. 좋은 생각은 더 이상 차별점이 아니다. 실제로 만들어 출시한 것이 차별점이다.</p>
<h2>만들면 된다</h2>
<p>며칠 전 바이브코딩(vibe coding)을 해보다가, 개발 공부를 진심으로 더 하고 싶어졌다. 그날 저녁 스위프트로 내가 실제로 쓸 앱 하나를 만들기 시작했다.</p>
<p>그때 깨달은 것이 있다. AI 도구의 시대에는 빠른 시도가 학습 동기를 만든다. 한 번 만들어보면 더 깊이 알고 싶어진다. 깊이 알고 나면 다음 산출물의 품질이 올라간다. 이 작은 루프가 &#39;쓰는 사람&#39;의 궤적을 매일 조금씩 더 멀리 가져간다.</p>
<p>다행스러운 것은, 같은 루프가 누구에게나 시작될 수 있다는 점이다. 첫 시도의 비용이 그토록 낮으니까.</p>
<h2>구경꾼의 언어, 쓰는 사람의 언어</h2>
<p>임원교육을 다니다 보면, 격차는 도구 이전에 언어에서 먼저 드러난다.</p>
<p>구경꾼은 명사로 말한다. &quot;챗GPT&quot;, &quot;AI 트렌드&quot;, &quot;생성형 AI 시장&quot;. 쓰는 사람은 동사로 말한다. &quot;돌려봤는데&quot;, &quot;붙여봤더니&quot;, &quot;바꿔서 다시 시켰더니&quot;. 명사는 관람석의 언어이고, 동사는 그라운드의 언어다.</p>
<p>질문도 다르다. 구경꾼의 질문은 크고 바깥을 향한다. &quot;AI가 일자리를 대체할까요?&quot; 쓰는 사람의 질문은 작고 구체적이다. &quot;이 워크플로에서 검토 단계를 어디에 넣어야 할까요?&quot; 큰 질문은 뉴스가 대신 답해주지만, 작은 질문은 시도해 본 사람만 던질 수 있다.</p>
<p>그래서 나는 교육장에서 받는 질문의 크기로 그 조직의 위치를 가늠한다. 질문이 작아질수록, 그 조직은 쓰는 쪽으로 넘어와 있다.</p>
<h2>마지막 질문</h2>
<p>이번 주, 단 한 번이라도 좋다. 무엇을 만들어 본 적이 있는가? 무엇을 배워본 적이 있는가? 누구에게 무엇을 물어본 적이 있는가?</p>
<p>만일 이 세 동사 중 하나라도 했다면, 당신은 이미 쓰는 사람의 궤적 위에 있다. 만일 어느 것도 하지 않았다면, 오늘이 가장 빠른 시작이다. 격차는 매일 자란다. 그러나 합류 또한 언제나 오늘 가능하다.</p>
<p>언제든 도움이 필요하면 연락하라. 질문은 언제나 환영이다.</p>
<hr>
<h3>더 읽을거리</h3>
<ul>
<li>📄 Citrini Research, &quot;The 2028 Global Intelligence Crisis&quot; — Intelligence Displacement Spiral 원문</li>
<li>📚 송길영, 『시대예보: 핵개인의 시대』 — AI가 인간의 평균을 복제한다는 명제</li>
<li>🔗 Andrej Karpathy의 vibe coding 트윗 시리즈 — 용어 출처</li>
<li>📚 Tyler Cowen, 『Average Is Over』 — AI 시대 노동시장 양극화</li>
<li>🧵 <a href="https://www.threads.com/@cmds_pace/post/DXv5a5sEZyt">이 글의 Threads 원문</a></li>
</ul>
]]></content:encoded>
</item>
<item>
<title>Schema는 Harness다 — Karpathy LLM Wiki와 CMDS의 구조적 동치</title>
<link>https://jisan.cmdspace.work/posts/schema-is-harness/</link>
<guid isPermaLink="true">https://jisan.cmdspace.work/posts/schema-is-harness/</guid>
<pubDate>Tue, 07 Apr 2026 00:00:00 GMT</pubDate>
<category>프레임워크</category>
<description>Karpathy의 LLM Wiki, 구요한의 CMDS, 그리고 Google OKF — 서로 다른 분야에서 독립적으로 같은 구조에 도달했다. RAG는 매번 재유도하지만 Wiki는 누적된다. 그리고 Schema 레이어는 정확히 하네스다.</description>
<content:encoded><![CDATA[<figure><img loading="lazy" decoding="async" src="/images/schema-is-harness/hero-schema-is-harness.jpg" alt="세 갈래 길이 하나의 3층 구조로 수렴하는 풍경"></figure>
<blockquote>
<p>Karpathy의 LLM Wiki와 CMDS의 구조적 동치에 관한 보고서 · 2026-04-07 작성, 2026-06-17 OKF 후속 추가</p>
</blockquote>
<blockquote>
<p><strong>Follow-up 구현 (2026-04-14)</strong> — 본 보고서가 &quot;CMDS는 Karpathy의 LLM Wiki를 이미 포함한다&quot;고 논증한 이후, <strong>별도 satellite 볼트로 Karpathy 패턴을 독립 구현</strong>했습니다. 메인 볼트는 통합 PKM을, satellite는 LLM 컴파일 전용을 담당합니다. 구조 공개본: <a href="https://llm-wiki.cmdspace.work">llm-wiki.cmdspace.work</a></p>
</blockquote>
<h2>Executive Summary</h2>
<p>2026년 4월, Andrej Karpathy(전 OpenAI, 전 Tesla AI)는 자신의 GitHub에 &quot;LLM Wiki&quot;라는 새로운 지식 관리 패턴을 제안했다. 핵심 주장은 단순하다. <strong>&quot;RAG는 매번 새로 유도하지만, Wiki는 누적된다(RAG re-derives, Wiki compounds).&quot;</strong> AI 시대에는 휘발성 검색이 아니라 영속적이고 누적되는 지식 산출물이 필요하다는 것이다.</p>
<p>본 보고서는 Karpathy의 LLM Wiki 개념을 <a href="https://system.cmdspace.work">CMDS(커맨드스페이스)</a> 시스템과 정밀하게 비교한 결과를 정리한다. 결론은 다음과 같다.</p>
<ol>
<li><strong>CMDS는 Karpathy가 제안한 LLM Wiki의 모든 구조적 요소를 이미 포함하고 있다.</strong> 누락된 개념은 단 하나도 없다.</li>
<li><strong>CMDS는 Karpathy의 제안을 양적·질적으로 능가한다.</strong> 10,000+ 노트, 3년 이상의 운영 이력, 다중 에이전트 지원, 5개 시스템 파일의 precedence 체계를 갖추고 있다.</li>
<li><strong>Karpathy의 워딩 일부는 차용할 가치가 있다.</strong> &quot;Persistent, compounding artifact&quot;와 같은 표현은 CMDS의 가치를 외부에 전달하는 데 효과적이다.</li>
<li><strong>두 시스템 모두 더 큰 패러다임인 &quot;하네스 엔지니어링(Harness Engineering)&quot;의 한 사례다.</strong> Karpathy의 Schema 레이어와 CMDS의 시스템 파일(CLAUDE.md/AGENTS.md/CMDS.md)은 같은 역할을 수행한다.</li>
</ol>
<p>본 보고서는 CMDS가 단순한 노트 앱 활용기가 아니라 <strong>AI 시대의 지식 컴파일 시스템</strong>임을 입증한다.</p>
<h2>1. Karpathy의 LLM Wiki 개념 정리</h2>
<h3>1.1 배경</h3>
<p>2026년 들어 LLM 기반 워크플로우는 두 가지 한계에 부딪혔다.</p>
<p>첫째, <strong>컨텍스트 윈도우의 비효율</strong>이다. 매번 같은 자료를 LLM에 다시 던져야 한다는 점은 시간과 비용을 낭비한다.</p>
<p>둘째, <strong>RAG(Retrieval-Augmented Generation)의 휘발성</strong>이다. RAG는 질의가 들어올 때마다 벡터 검색을 통해 답을 생성하지만, 그 과정에서 만들어진 통찰은 어디에도 저장되지 않는다. 다음 질의가 들어오면 똑같은 작업을 처음부터 반복한다.</p>
<p>Karpathy가 제안한 해법은 단순하다. <strong>&quot;검색하지 말고, 컴파일하라.&quot;</strong></p>
<h3>1.2 LLM Wiki의 3-Layer 아키텍처</h3>
<p>Karpathy는 다음과 같은 3계층 구조를 제안했다.</p>
<div class="table-wrap"><table>
<thead>
<tr>
<th>Layer</th>
<th>역할</th>
<th>예시</th>
</tr>
</thead>
<tbody><tr>
<td><strong>Raw Sources</strong></td>
<td>변환되지 않은 원본 자료</td>
<td>PDF, URL, 트랜스크립트</td>
</tr>
<tr>
<td><strong>Wiki</strong></td>
<td>정제된 영속적 지식</td>
<td>마크다운 노트, 위키페이지</td>
</tr>
<tr>
<td><strong>Schema</strong></td>
<td>컴파일 규칙과 지시문</td>
<td>schema.md, log.md</td>
</tr>
</tbody></table></div>
<p>핵심 아이디어는 <strong>Raw → Wiki 변환을 명시적으로 관리</strong>한다는 점이다. 원본 자료를 그냥 쌓아두는 것이 아니라, 적극적으로 위키로 &quot;컴파일(compile)&quot;하고, 그 컴파일 규칙을 Schema 파일에 기록한다.</p>
<h3>1.3 핵심 명제</h3>
<p>Karpathy의 글에서 가장 자주 인용되는 문장은 다음과 같다.</p>
<blockquote>
<p><strong>&quot;RAG re-derives knowledge from scratch every time. Wiki compounds it.&quot;</strong></p>
</blockquote>
<p>이 한 문장이 LLM Wiki 개념의 본질이다. 지식은 매번 다시 유도되는 것이 아니라, 누적되어야 한다. 그리고 누적된 지식은 <strong>영속적이고 점진적으로 가치가 증가하는 산출물(persistent, compounding artifact)</strong> 이 된다.</p>
<h2>2. CMDS 시스템 개요</h2>
<h3>2.1 정의</h3>
<p>CMDS(커맨드스페이스)는 구요한이 2023년부터 운영해온 <strong>개인 지식 관리 생태계</strong>다. 단순한 노트 앱 활용기가 아니라 다음과 같은 요소를 갖춘 <strong>시스템</strong>이다.</p>
<ul>
<li><strong>9개 카테고리(100~900) 분류 체계</strong>: Themes → Literature → Data → Methodologies → Products → Specialties → Creatives → Outputs → Divisions</li>
<li><strong>CMDS Process</strong>: Connect → Merge → Develop → Share라는 지식 생애주기 워크플로우</li>
<li><strong>5개 시스템 파일의 precedence 체계</strong>: CLAUDE.md(1) → AGENTS.md(2) → CMDS.md(3) → 🏛 CMDS Guide(4) → 🏛 CMDS Head Quarter(5)</li>
<li><strong>7개 필수 YAML 프로퍼티</strong>: type, aliases, description, author, date created, date modified, tags</li>
<li><strong>94개 노트 템플릿, 120+ Obsidian 플러그인</strong></li>
</ul>
<h3>2.2 규모와 성숙도</h3>
<ul>
<li><strong>노트 수</strong>: 10,000+</li>
<li><strong>운영 기간</strong>: 3년 이상 (2023~현재)</li>
<li><strong>카테고리</strong>: 9개 1차 카테고리, 91개 2차 카테고리</li>
<li><strong>노트 타입</strong>: 459+ note, 160+ meeting, 130+ terminology, 124+ research-pipeline, 97+ api, 93+ people, 85+ moc, 82+ curriculum, 66+ manuscript</li>
</ul>
<p>이 규모는 단순 취미 수준이 아니라 <strong>검증된 운영 시스템</strong>임을 의미한다.</p>
<h3>2.3 철학</h3>
<p>CMDS는 다음 7가지 원리를 따른다.</p>
<ol>
<li>모든 노트는 자기 자리가 있다 (Every note has a home)</li>
<li>링크가 가치를 만든다 (Links create value)</li>
<li>프로세스가 중요하다 (Process matters)</li>
<li>산출물이 목표다 (Output is the goal)</li>
<li>AI는 파트너다 (AI is a partner)</li>
<li>표준이 자유를 가능하게 한다 (Standards enable freedom)</li>
<li>완벽보다 진화 (Evolution over perfection)</li>
</ol>
<h2>3. 비교 분석</h2>
<p>본 절은 Karpathy의 LLM Wiki와 CMDS를 9개 항목에서 직접 비교한다.</p>
<h3>3.1 구조적 비교표</h3>
<div class="table-wrap"><table>
<thead>
<tr>
<th>항목</th>
<th>Karpathy LLM Wiki</th>
<th>CMDS</th>
<th>평가</th>
</tr>
</thead>
<tbody><tr>
<td><strong>영속적 위키</strong></td>
<td>Wiki layer</td>
<td>30. Permanent Notes + 100~900 카테고리</td>
<td>CMDS가 더 정교</td>
</tr>
<tr>
<td><strong>스키마/지시문</strong></td>
<td>schema.md (단일 파일)</td>
<td>CLAUDE.md / AGENTS.md / CMDS.md (5개 파일)</td>
<td>CMDS가 압도</td>
</tr>
<tr>
<td><strong>Raw → Wiki 컴파일</strong></td>
<td>수동 promotion</td>
<td>Inbox → Categories (CMDS Process)</td>
<td>동일</td>
</tr>
<tr>
<td><strong>인덱스 파일</strong></td>
<td>log.md, index.md</td>
<td>🏷 Index notes, 🏛 Hub notes</td>
<td>CMDS가 더 풍부</td>
</tr>
<tr>
<td><strong>메타데이터</strong></td>
<td>YAML frontmatter</td>
<td>7개 필수 + 선택 프로퍼티</td>
<td>CMDS가 더 엄격</td>
</tr>
<tr>
<td><strong>크로스 레퍼런스</strong></td>
<td>Markdown links</td>
<td>Obsidian Wikilinks</td>
<td>동일</td>
</tr>
<tr>
<td><strong>Source/Wiki 분리</strong></td>
<td>Raw vs Wiki</td>
<td>02. Clippings vs 30. Permanent Notes</td>
<td>동일</td>
</tr>
<tr>
<td><strong>IDE 개념</strong></td>
<td>(없음)</td>
<td>Obsidian = IDE for Knowledge</td>
<td>CMDS가 우위</td>
</tr>
<tr>
<td><strong>운영 규모</strong></td>
<td>제안 단계</td>
<td>10,000+ 노트, 3년+</td>
<td>CMDS가 압도</td>
</tr>
</tbody></table></div>
<h3>3.2 결론</h3>
<p><strong>CMDS는 Karpathy의 LLM Wiki를 완전히 포괄한다.</strong> Karpathy가 제안한 어떤 개념도 CMDS에 누락된 것이 없으며, 오히려 CMDS는 다음 영역에서 LLM Wiki를 능가한다.</p>
<ol>
<li><strong>다중 에이전트 지원</strong>: Karpathy는 단일 schema를 가정하지만, CMDS는 Claude Code, Gemini CLI, Codex 등 여러 에이전트를 위한 분리된 지시 파일을 운영한다.</li>
<li><strong>Precedence 체계</strong>: 5개 시스템 파일이 우선순위를 가지고 로드되어 컨텍스트 충돌을 방지한다.</li>
<li><strong>인간-AI 이중 문서화</strong>: CMDS는 AI용 문서(CLAUDE.md)와 인간용 문서(🏛 CMDS Head Quarter)를 구분하여 양쪽 모두에게 최적화되어 있다.</li>
<li><strong>운영 검증</strong>: 10,000+ 노트로 3년 이상 운영되며 패턴이 안정적으로 작동함을 입증했다.</li>
</ol>
<h2>4. 차용할 가치 있는 Karpathy 워딩</h2>
<p>CMDS가 구조적으로 완성되어 있다 하더라도, Karpathy의 표현 중 일부는 <strong>외부 전달력</strong>을 위해 차용할 가치가 있다. Karpathy는 AI 분야의 글로벌 권위자이며, 그의 워딩은 청중에게 즉각적인 신뢰감을 준다.</p>
<div class="table-wrap"><table>
<thead>
<tr>
<th>워딩</th>
<th>의미</th>
<th>CMDS 활용처</th>
</tr>
</thead>
<tbody><tr>
<td><strong>&quot;Persistent, compounding artifact&quot;</strong></td>
<td>영속적이며 누적되는 산출물</td>
<td>AI PKM Forum, 하네스 Start-kit 마케팅</td>
</tr>
<tr>
<td><strong>&quot;Cost of maintenance is near zero&quot;</strong></td>
<td>유지비용이 0에 수렴</td>
<td>클린 볼트 vs CMDS 차별화 메시지</td>
</tr>
<tr>
<td><strong>&quot;RAG re-derives. Wiki compounds.&quot;</strong></td>
<td>RAG는 매번 재유도, Wiki는 누적</td>
<td>컨텍스트 엔지니어링 강의</td>
</tr>
</tbody></table></div>
<p>이 워딩들은 <strong>CMDS의 핵심을 더 정확히 묘사하기 위한 외부 인용</strong>으로 사용해야 한다. CMDS의 원래 표현(Connect-Merge-Develop-Share, 위키링크 네트워크 등)을 대체하는 것이 아니라 보강하는 것이다.</p>
<blockquote>
<p>예시 활용 문장:
<em>&quot;우리는 이미 3년 전부터 Karpathy가 말한 &#39;persistent, compounding artifact&#39;를 운영해왔습니다. CMDS는 그 증거입니다.&quot;</em></p>
</blockquote>
<h2>5. 하네스 엔지니어링과의 연결</h2>
<h3>5.1 하네스 엔지니어링이란</h3>
<p>2026년 OpenAI의 발언 — <em>&quot;the agent isn&#39;t the hard part — the harness is&quot;</em> — 이후 AI 업계에는 <strong>하네스 엔지니어링(Harness Engineering)</strong> 이라는 개념이 자리잡았다. 모델 자체보다 모델을 둘러싼 컨텍스트 구조가 결과 품질을 결정한다는 통찰이다.</p>
<p>하네스란 모델에게 다음을 제공하는 구조다.</p>
<ul>
<li><strong>컨텍스트</strong>: 어떤 정보를 줄 것인가</li>
<li><strong>지시</strong>: 어떻게 행동할 것인가</li>
<li><strong>자원</strong>: 어떤 도구와 산출물에 접근할 수 있는가</li>
</ul>
<h3>5.2 Schema = Harness</h3>
<p><strong>Karpathy의 Schema 레이어는 정확히 하네스에 해당한다.</strong> 그리고 CMDS의 CLAUDE.md/AGENTS.md/CMDS.md 역시 같은 역할을 수행한다.</p>
<div class="table-wrap"><table>
<thead>
<tr>
<th>하네스 요소</th>
<th>Karpathy LLM Wiki</th>
<th>CMDS</th>
</tr>
</thead>
<tbody><tr>
<td><strong>Raw Layer</strong> (입력)</td>
<td>Sources (PDFs, URLs)</td>
<td>00. Inbox / 02. Clippings</td>
</tr>
<tr>
<td><strong>Wiki Layer</strong> (정제)</td>
<td>Permanent notes</td>
<td>30. Permanent Notes + 100~900 카테고리</td>
</tr>
<tr>
<td><strong>Schema Layer</strong> (지시)</td>
<td>schema.md (단일)</td>
<td>CLAUDE.md + AGENTS.md + CMDS.md + 🏛 Guide + 🏛 HQ</td>
</tr>
</tbody></table></div>
<p>이 매핑은 두 시스템이 서로 다른 영역에서 같은 패턴을 발견했음을 보여준다.</p>
<h3>5.3 Obsidian = IDE, Markdown = Language, Claude = Engine</h3>
<p>CMDS는 한 단계 더 나아가 <strong>3-스택 모델</strong>을 제시한다.</p>
<ul>
<li><strong>Obsidian</strong>: 지식을 위한 IDE (Integrated Development Environment)</li>
<li><strong>Markdown</strong>: 인간과 AI가 공유하는 보편 언어</li>
<li><strong>Claude</strong>: 지식 컴파일을 수행하는 엔진</li>
</ul>
<p>이 모델은 Karpathy의 LLM Wiki가 암묵적으로 가정했지만 명시하지 않았던 부분을 명료화한다. <strong>지식 관리는 더 이상 파일 정리가 아니라 소프트웨어 엔지니어링이다.</strong></p>
<h2>6. 사례 연구: Karpathy의 Autoresearch</h2>
<h3>6.1 Autoresearch 프로젝트</h3>
<p>2026년 3월, Karpathy는 또 다른 프로젝트인 <strong>Autoresearch</strong>를 공개했다. 이 프로젝트는 GitHub에서 큰 화제가 되었다. Autoresearch는 LLM이 자율적으로 머신러닝 연구를 수행하도록 설계된 시스템이다.</p>
<div class="table-wrap"><table>
<thead>
<tr>
<th>파일</th>
<th>역할</th>
</tr>
</thead>
<tbody><tr>
<td><code>program.md</code></td>
<td>인간이 작성한 연구 방향 지시문</td>
</tr>
<tr>
<td><code>train.py</code></td>
<td>AI가 실행하는 학습 코드</td>
</tr>
<tr>
<td><code>prepare.py</code></td>
<td>불변의 데이터 전처리 코드</td>
</tr>
</tbody></table></div>
<h3>6.2 CMDS와의 구조적 동치</h3>
<p>이 구조는 CMDS와 <strong>놀라울 정도로 동치</strong>다.</p>
<div class="table-wrap"><table>
<thead>
<tr>
<th>Karpathy Autoresearch</th>
<th>CMDS</th>
</tr>
</thead>
<tbody><tr>
<td><code>program.md</code> (인간 지시)</td>
<td><code>CLAUDE.md</code> (인간 지시)</td>
</tr>
<tr>
<td><code>train.py</code> (AI 실행)</td>
<td>Skills / Plugins / Subagents</td>
</tr>
<tr>
<td><code>prepare.py</code> (불변 전처리)</td>
<td>Templates (90. Settings/91. Templates)</td>
</tr>
</tbody></table></div>
<p>즉, Karpathy가 코드 연구 자동화를 위해 발견한 패턴은 CMDS가 지식 관리를 위해 이미 설계해둔 패턴과 같다. <strong>이는 패턴의 보편성을 입증한다.</strong></p>
<h3>6.3 시사점</h3>
<blockquote>
<p><strong>&quot;카르파시는 발견했고, 구요한은 설계했다.&quot;</strong></p>
</blockquote>
<ul>
<li>2026년 Karpathy: 코드 연구에서 LLM Wiki / Autoresearch 패턴을 제안</li>
<li>2023년~ 구요한: 같은 패턴을 지식 관리에 적용하여 10,000+ 노트로 3년간 운영</li>
</ul>
<p>이 비교는 단순한 자기 자랑이 아니다. <strong>같은 시기에, 서로 다른 분야에서, 독립적으로 같은 구조에 도달했다는 사실은 그 구조가 보편적임을 강력히 시사한다.</strong> 이는 CMDS가 한 개인의 취향이 아니라 시대적 필연이라는 증거다.</p>
<h2>6.5 후속: Google OKF — 세 번째 독립 수렴 (2026-06-17 추가)</h2>
<blockquote>
<p><strong>Follow-up (2026-06-17)</strong> — 본 보고서가 &quot;Karpathy와 구요한이 독립적으로 같은 구조에 도달 → 보편성&quot;을 논증한 지 두 달 뒤, <strong>Google Cloud</strong>가 같은 구조를 *명세(spec)*로 발표했다. 상세 비교는 <a href="/posts/okf-third-arrival/">OKF 비교 분석 보고서</a> 참조.</p>
</blockquote>
<p>2026년 6월, Google Cloud가 <code>knowledge-catalog</code> 레포에 <strong>Open Knowledge Format (OKF) v0.1</strong>을 공개했다. 지식을 <strong>YAML frontmatter를 가진 마크다운 디렉토리</strong>로 표현하는 벤더 중립 포맷이다 — 이 보고서가 CMDS·LLM Wiki·Autoresearch에서 동일하다고 짚은 바로 그 기질.</p>
<p>이로써 &quot;독립 수렴&quot; 증인은 셋이 된다.</p>
<div class="table-wrap"><table>
<thead>
<tr>
<th>도착자</th>
<th>시점</th>
<th>분야</th>
<th>산출 형태</th>
</tr>
</thead>
<tbody><tr>
<td>구요한 (CMDS)</td>
<td>2023~</td>
<td>지식 관리</td>
<td>운영 시스템 (8,000+ 노트)</td>
</tr>
<tr>
<td>Karpathy</td>
<td>2026</td>
<td>ML 연구 자동화</td>
<td>LLM Wiki · Autoresearch</td>
</tr>
<tr>
<td><strong>Google Cloud (OKF)</strong></td>
<td><strong>2026-06</strong></td>
<td><strong>데이터 카탈로그</strong></td>
<td><em><strong>명세(spec)</strong></em></td>
</tr>
</tbody></table></div>
<p>처음으로 <em>개인/연구자</em>가 아니라 <strong>하이퍼스케일러가, 그것도 명세 형태로</strong> 도착했다. &quot;한 개인의 취향이 아니라 시대적 필연&quot; 논증이 한 단계 강해진다.</p>
<p>단, OKF는 <strong>L1–L3(Raw/Wiki/Schema)만 명세하고 멈춘다.</strong> &quot;Schema = Harness&quot; 축에서 OKF는 <em>얇은 하네스</em>(필수 필드 <code>type</code> 단 하나, &quot;깨진 링크도 관용&quot;)를, CMDS는 <em>두꺼운 하네스</em>(7 프로퍼티 + lint)를 택한 양 극단이다. 둘 다 옳다 — <em>생산자</em>(에이전트 대량생성 vs 인간 큐레이션)와 <em>목적</em>(조직 간 교환 vs 교육 자산)이 다를 뿐.</p>
<h2>7. 시사점 및 제언</h2>
<h3>7.1 시스템 변경 권고: 변경 없음</h3>
<p>검토 결과, <strong>CMDS의 디렉토리 구조, 메타데이터 스키마, CMDS Process 등 핵심 요소는 변경할 필요가 없다.</strong> Karpathy의 제안은 검증 자료일 뿐 교정 자료가 아니다.</p>
<h3>7.2 메시지/전달 권고: 워딩 차용</h3>
<p>다음 3가지 차용 권고를 다시 정리한다.</p>
<ol>
<li><strong>&quot;Persistent, compounding artifact&quot;</strong> 표현을 마케팅 자료에 반영</li>
<li><strong>&quot;RAG re-derives, Wiki compounds&quot;</strong> 인용을 강의 슬라이드에 추가</li>
<li><strong>&quot;Schema = Harness&quot;</strong> 등치를 컨텍스트 엔지니어링 강의에서 강조</li>
</ol>
<h3>7.3 활용 권고: 비교 슬라이드 제작</h3>
<p>2026년 4월 11일 CMDS AI PKM Forum에서 다음 1장 분량의 비교 슬라이드를 추가할 것을 권고한다.</p>
<blockquote>
<p><strong>&quot;Karpathy가 발견한 것을, 우리는 이미 운영 중입니다.&quot;</strong></p>
<ul>
<li>LLM Wiki (2026 제안) → CMDS (2023 운영 중)</li>
<li>Autoresearch program.md → CMDS CLAUDE.md</li>
<li>3-Layer Schema → 5-Layer Precedence System</li>
</ul>
</blockquote>
<p>이 메시지는 CMDS의 선구성과 Karpathy의 권위를 동시에 활용한다.</p>
<h3>7.4 우선순위 매트릭스</h3>
<div class="table-wrap"><table>
<thead>
<tr>
<th>액션</th>
<th>우선순위</th>
<th>적용처</th>
<th>소요</th>
</tr>
</thead>
<tbody><tr>
<td>3개 워딩 마케팅 자료 반영</td>
<td>⭐⭐⭐</td>
<td>하네스 Start-kit, AI PKM Forum</td>
<td>30분</td>
</tr>
<tr>
<td>Karpathy 비교 슬라이드 1장 추가</td>
<td>⭐⭐</td>
<td>4/11 포럼 발표</td>
<td>1시간</td>
</tr>
<tr>
<td>&quot;Schema = Harness&quot; 등치 강조</td>
<td>⭐⭐</td>
<td>컨텍스트 엔지니어링 강의</td>
<td>슬라이드 1장</td>
</tr>
<tr>
<td>Lint 공식 명명 검토</td>
<td>⭐</td>
<td>CLAUDE.md 다음 업데이트 시</td>
<td>선택</td>
</tr>
</tbody></table></div>
<h2>8. 결론</h2>
<p>본 보고서는 다음을 입증했다.</p>
<p>첫째, <strong>CMDS는 Karpathy의 LLM Wiki 개념을 구조적으로 완전히 포괄한다.</strong> 누락된 요소가 없을 뿐 아니라 다중 에이전트 지원, 5단계 precedence, 인간-AI 이중 문서화 등에서 더 발전된 형태를 가진다.</p>
<p>둘째, <strong>CMDS는 Karpathy의 제안보다 양적·질적으로 성숙하다.</strong> 10,000+ 노트와 3년 이상의 운영 이력은 이 시스템이 검증된 운영 체계임을 보여준다.</p>
<p>셋째, <strong>두 시스템 모두 더 큰 패러다임인 하네스 엔지니어링의 구체적 사례다.</strong> Karpathy의 Schema = CMDS의 Harness이며, 이 등치는 컨텍스트 엔지니어링이라는 새로운 지식 작업 방식의 출현을 드러낸다.</p>
<p>넷째, <strong>CMDS는 다음과 같은 메시지로 자신을 정의할 수 있다.</strong></p>
<blockquote>
<p><strong>&quot;CMDS는 Karpathy가 2026년에 제안한 LLM Wiki를, 2023년부터 운영해온 시스템입니다. 우리는 RAG가 아니라 컴파일을 선택했고, 휘발이 아니라 누적을 선택했습니다. 그리고 그 선택은 이미 10,000개의 노트로 검증되었습니다.&quot;</strong></p>
</blockquote>
<p>본 보고서는 CMDS 사용자, 강의 수강생, 교육 파트너에게 다음과 같이 말할 수 있는 근거를 제공한다.</p>
<p><strong>&quot;당신이 배우는 것은 한 개인의 취향이 아니라, AI 시대의 보편적 패턴입니다. 그 증거는 10,000개의 노트와 Karpathy의 발견에 있습니다.&quot;</strong></p>
<hr>
<h3>참고 자료</h3>
<ul>
<li>Andrej Karpathy, &quot;LLM Wiki&quot; (GitHub, 2026)</li>
<li>Andrej Karpathy, &quot;Autoresearch&quot; (GitHub, 2026)</li>
<li>OpenAI, &quot;Building Agents&quot; — <em>&quot;the agent isn&#39;t the hard part — the harness is&quot;</em></li>
<li>Google Cloud, &quot;Open Knowledge Format v0.1&quot; (knowledge-catalog, 2026)</li>
<li>Tiago Forte, <em>Building a Second Brain</em> (2022)</li>
<li>CMDS 시스템 파일 공개본: <a href="https://system.cmdspace.work">system.cmdspace.work</a> · LLM Wiki 구조 공개본: <a href="https://llm-wiki.cmdspace.work">llm-wiki.cmdspace.work</a></li>
</ul>
]]></content:encoded>
</item>
<item>
<title>Raw와 Wiki 사이에서 — Karpathy와 Kepano가 던진 질문에 대한 답</title>
<link>https://jisan.cmdspace.work/posts/between-raw-and-wiki/</link>
<guid isPermaLink="true">https://jisan.cmdspace.work/posts/between-raw-and-wiki/</guid>
<pubDate>Fri, 03 Apr 2026 00:00:00 GMT</pubDate>
<category>에세이</category>
<description>Karpathy는 &quot;LLM이 raw를 위키로 컴파일한다&quot;고 했고, Kepano는 &quot;에이전트용 볼트를 분리하라&quot;고 경고했다. 두 주장은 같은 문제의 양면이다. 나의 답 — 분리가 답이 아니라, 설계가 답이다.</description>
<content:encoded><![CDATA[<figure><img loading="lazy" decoding="async" src="/images/between-raw-and-wiki/hero-between-raw-and-wiki.jpg" alt="Raw 더미를 구조화된 지식으로 컴파일하는 렌즈"></figure>
<p>오늘 타임라인에 Andrej Karpathy와 Kepano(Obsidian CEO)의 대화가 올라왔다. 46만 뷰를 찍은 이 스레드는, 필자가 3년간 옵시디언 볼트를 운영하면서 매일 마주해온 질문을 정확히 건드린다.</p>
<p>Karpathy는 이렇게 말했다:</p>
<blockquote>
<p>&quot;최근 토큰의 상당 부분이 코드가 아닌 지식을 다루는 데 쓰이고 있다. 원본 데이터를 raw/ 디렉토리에 모으고, LLM이 이것을 .md 위키로 &#39;컴파일&#39;한다.&quot;</p>
</blockquote>
<p>Kepano는 여기에 날카로운 보완을 붙였다:</p>
<blockquote>
<p>&quot;개인 볼트는 깨끗하게 유지하고, 에이전트용 볼트는 따로 만들어라. 둘을 섞으면 당신의 생각을 대표하는 시스템이 오염된다.&quot;</p>
</blockquote>
<p>두 사람의 주장은 겉보기에 충돌하는 것 같지만, 실은 같은 문제의 양면이다. 그리고 필자는 10,000개 노트가 넘는 볼트를 운영하면서 이 양면을 동시에 겪고 있다.</p>
<h2>Karpathy의 통찰: LLM은 코드가 아니라 지식을 컴파일한다</h2>
<p>Karpathy가 설명한 워크플로우를 정리하면 이렇다:</p>
<ol>
<li>원본 수집 (raw/) → 논문, 아티클, 레포, 이미지</li>
<li>LLM이 위키로 컴파일 → .md 파일 + 디렉토리 구조 + 백링크 + 인덱스</li>
<li>위키 위에서 Q&amp;A → 400K 단어 규모에서 복잡한 질문에 답변</li>
<li>결과물을 다시 위키에 편입 → 탐색이 지식으로 축적</li>
<li>린팅 → 비일관성 감지, 누락 데이터 보완, 새 연결 제안</li>
</ol>
<p>이것을 읽으며 느낀 점이 두 가지 있었다.</p>
<p>첫째, <strong>이건 CMDS 프로세스 그 자체다.</strong> Connect(원본 수집) → Merge(컴파일/통합) → Develop(Q&amp;A/분석) → Share(결과물 편입). 3년 전에 설계한 워크플로우가 AI 시대에 그대로 유효하다는 것을 Karpathy가 증명해준 셈이다.</p>
<p>둘째, Karpathy가 &quot;fancy RAG에 손대야 하나 생각했는데, LLM이 인덱스 파일과 문서 요약을 자동으로 관리하더라&quot;고 말한 부분. 이것이야말로 <strong>Markdown is all you need</strong>의 핵심이다. 벡터 DB도, 임베딩 파이프라인도, RAG 인프라도 필요 없다. 잘 구조화된 마크다운 파일과 인덱스면 충분하다. CMDS에서 <code>.claude/rules/</code> 5개 파일과 CLAUDE.md가 하는 일이 정확히 이것이다.</p>
<p>Karpathy는 &quot;스키마는 AGENTS.md에 유지한다&quot;고도 말했다. 필자의 볼트에도 AGENTS.md가 있다. 같은 이름, 같은 목적. 우연이 아니다. 이 패턴이 자연스럽게 수렴하는 지점이 있다는 뜻이다.</p>
<h2>Kepano의 경고: 오염의 경계를 지켜라</h2>
<p>Kepano의 주장은 더 근본적이다.</p>
<blockquote>
<p>&quot;에이전트가 생성한 콘텐츠와 당신이 직접 만든 콘텐츠를 섞으면, 검색, 그래프, 백링크가 더 이상 &#39;당신의 지식&#39;을 범위로 하지 않게 된다.&quot;</p>
</blockquote>
<p>이것은 Kepano답게 날카롭다. 그리고 옳다. 하지만 필자의 답은 조금 다르다.</p>
<p><strong>분리가 답이 아니라, 설계가 답이다.</strong></p>
<p>CMDS 볼트에는 AI가 생성한 파일이 수천 개 있다. 회의록, 에세이 초안, 웹페이지, 채널 프로필, 코드. 이것들이 볼트를 &quot;오염&quot;시키지 않는 이유는 <strong>명확한 경계가 설계되어 있기 때문이다:</strong></p>
<ol>
<li><p><strong>AI 산출물 경로 분리</strong>: 모든 AI 코딩 출력은 <code>00. Inbox/03. AI Agent/</code> 하위의 환경별 서브폴더에 들어간다. MacBook Pro에서 Claude Code가 만든 파일은 <code>03-1. Claude Code (MBP)/</code>에만 생긴다.</p>
</li>
<li><p><strong>프로퍼티로 출처 추적</strong>: 모든 노트에 <code>author</code> 필드가 있다. <code>&quot;[[구요한]]&quot;</code>이면 내가 쓴 것이고, AI가 생성한 파일에는 그 맥락이 명시된다.</p>
</li>
<li><p><strong>처리 상태 관리</strong>: <code>status: unread → reading → inProgress → completed → archived</code> 5단계로 모든 노트의 생애주기를 추적한다. AI가 만든 초안(<code>inProgress</code>)과 내가 검증한 완성본(<code>completed</code>)이 구분된다.</p>
</li>
<li><p><strong>시스템 파일의 precedence</strong>: CLAUDE.md(precedence: 1)가 AI의 행동 규칙을 정의하고, CMDS.md(precedence: 3)가 볼트의 철학을 설명한다. AI는 이 규칙을 읽고 나서 작업한다.</p>
</li>
</ol>
<p>Kepano가 말하는 &quot;깨끗한 볼트&quot;와 &quot;지저분한 볼트&quot;를 물리적으로 분리하는 대신, <strong>하나의 볼트 안에서 메타데이터와 폴더 구조로 논리적으로 분리하는 것이 CMDS의 접근이다.</strong> 왜냐하면 분리된 두 볼트 사이에서는 위키링크가 작동하지 않기 때문이다. AI가 만든 회의록에서 <code>[[김팀장]]</code> 인물 노트로 점프하고, 거기서 <code>[[📚 620 Generative AI]]</code> 카테고리로 이동하는 흐름 — 이것은 하나의 볼트 안에서만 가능하다.</p>
<p>물론 Kepano의 경고는 유효하다. 관리하지 않으면 실제로 오염된다. 하지만 해법은 볼트를 나누는 것이 아니라, 시스템 파일을 잘 설계하는 것이다.</p>
<h2>두 관점의 합류점: 시스템 파일이라는 답</h2>
<p>Karpathy의 &quot;AGENTS.md에 스키마를 유지한다&quot;와 Kepano의 &quot;경계를 지켜라&quot;를 합치면 하나의 결론이 나온다:</p>
<p><strong>AI와 인간이 같은 볼트를 공유하려면, 둘 다 읽을 수 있는 규칙서가 있어야 한다.</strong></p>
<p>CMDS에서 이것이 5개 시스템 파일이다:</p>
<div class="table-wrap"><table>
<thead>
<tr>
<th>파일</th>
<th>누가 읽는가</th>
<th>무엇을 정의하는가</th>
</tr>
</thead>
<tbody><tr>
<td>CLAUDE.md</td>
<td>AI (Claude Code)</td>
<td>기술적 규칙, 파일 생성 경로, 인덴트 규칙</td>
</tr>
<tr>
<td>AGENTS.md</td>
<td>AI (Gemini, Codex)</td>
<td>범용 기술 규칙</td>
</tr>
<tr>
<td>CMDS.md</td>
<td>AI (전체)</td>
<td>볼트의 철학, 사용자 맥락, 카테고리 의미</td>
</tr>
<tr>
<td>Guide</td>
<td>인간 + AI</td>
<td>프로퍼티 표준, 네이밍 규칙</td>
</tr>
<tr>
<td>Head Quarter</td>
<td>인간</td>
<td>91개 카테고리 네비게이션</td>
</tr>
</tbody></table></div>
<p>여기에 <code>.claude/rules/</code> 5개 공통 규칙 파일이 <code>@include</code>로 AI 문서에 주입된다. Karpathy가 &quot;LLM이 인덱스를 자동 관리한다&quot;고 한 그 인덱스의 역할을 이 파일들이 수행한다.</p>
<h2>나의 답: 볼트는 나누는 것이 아니라 설계하는 것이다</h2>
<p>Karpathy에게: 당신이 말한 &quot;raw → wiki 컴파일&quot; 워크플로우는 정확하다. 거기에 시스템 파일(AGENTS.md, CLAUDE.md)을 더하면 AI가 스키마를 넘어 규칙과 맥락까지 이해하게 된다. 그러면 위키의 품질이 한 단계 올라간다.</p>
<p>Kepano에게: 오염 경고에 동의한다. 하지만 볼트를 나누는 것은 위키링크의 힘을 포기하는 것이다. 10,000개 노트가 연결된 그래프의 가치는, 그 안에 AI 산출물이 포함되어 있을 때 더 커진다. 핵심은 분리가 아니라, 출처를 추적할 수 있는 메타데이터 설계다.</p>
<p>둘 다에게: Markdown is all you need. 벡터 DB도, RAG 파이프라인도 필요 없다. 잘 구조화된 .md 파일, YAML frontmatter, 그리고 AI가 읽을 수 있는 시스템 파일. 이 세 가지면 개인 지식 베이스는 AI 에이전트의 운영 체제가 된다.</p>
<hr>
<h3>더 읽을거리</h3>
<ul>
<li>📚 Niklas Luhmann의 Zettelkasten — 카드 박스 시스템의 &quot;오염 방지&quot; 설계</li>
<li>🔗 Andrej Karpathy, &quot;Software 2.0&quot; — 코드에서 데이터로의 패러다임 전환</li>
<li>🛠️ Obsidian Web Clipper — Karpathy가 사용하는 웹 클리핑 도구</li>
</ul>
<h3>출처</h3>
<ul>
<li>Andrej Karpathy, &quot;LLM Knowledge Bases&quot; (<a href="https://x.com/karpathy/status/2039805659525644595">https://x.com/karpathy/status/2039805659525644595</a>), 2026-04-03</li>
<li>Kepano, &quot;Contamination risks&quot; (<a href="https://x.com/kepano/status/2039831289533227446">https://x.com/kepano/status/2039831289533227446</a>), 2026-04-03</li>
<li>CMDS System Files: <a href="https://system.cmdspace.work">system.cmdspace.work</a> · <a href="https://github.com/johnfkoo951/cmds-system-files">GitHub</a></li>
</ul>
]]></content:encoded>
</item>
<item>
<title>Markdown Is All You Need — 마크다운이라는 선택이 바꾸는 것들</title>
<link>https://jisan.cmdspace.work/posts/markdown-is-all-you-need/</link>
<guid isPermaLink="true">https://jisan.cmdspace.work/posts/markdown-is-all-you-need/</guid>
<pubDate>Mon, 16 Mar 2026 00:00:00 GMT</pubDate>
<category>에세이</category>
<description>plain text가 지식을 살려두고, 샵 하나가 사고의 뼈대를 세우고, 세 줄의 하이픈이 문서를 데이터베이스로 바꾸고, AI가 같은 언어를 쓰게 되었다. 이 모든 것이 마크다운이라는 하나의 선택에서 시작된다.</description>
<content:encoded><![CDATA[<figure><img loading="lazy" decoding="async" src="/images/markdown-is-all-you-need/hero-markdown.jpg" alt="Markdown Is All You Need"></figure>
<p>&quot;대표님께서 2년 전부터 강조하시던 &#39;나만의 맥락정보&#39;... 이제서야 비로소 깨닫게 되었습니다.&quot;</p>
<p>더배러 커뮤니티에서 오래 함께한 교수님의 메시지였다. 옵시디언을 8~9개월 써보고 나서야 이해한 것이라고 했다. 읽다가 멈췄다. 한 번 더 읽었다. 단순한 기쁨이라기보다는 안도에 가까운 감정이었다. 누군가가 같은 풍경에 도착했다는 감각.</p>
<p>나는 2년 전부터 마크다운과 PKM, 그리고 &quot;나만의 맥락정보&quot;를 이야기하고 다녔다. 강의에서, 워크숍에서, 유튜브에서, 커뮤니티에서. 반응은 대부분 비슷했다. &quot;마크다운이 뭐가 좋은 건지 모르겠어요.&quot; &quot;노션이면 충분하지 않나요?&quot; &quot;저는 그냥 ChatGPT에 물어보면 되는데요.&quot;</p>
<p>틀린 말이 아니었다. 당장 눈앞에 보이지 않는 것을 설명하는 건 원래 어렵다.</p>
<p>그래도 계속 말했다. 이것이 중요하다고. 지금은 몰라도 반드시 알게 될 거라고.</p>
<p>이 글은 그 이야기의 전부를 담은 것이다.</p>
<hr>
<h2>죽은 파일, 살아있는 파일</h2>
<p>10년 전에 쓴 파일을 열어본 적이 있는가.</p>
<p>나는 얼마 전에 시도했다. 대학원 과정 때 정리해둔 연구 노트였다. 주제는 지금 이야기하는 강의 주제와 연구와도 맞닿아 있어서 &quot;이거다&quot; 싶었다. 밤새 정리했던 이론 프레임워크, 지도교수와 나눈 논의 메모, 직접 설계한 설문 초안까지 전부 그 안에 있었다.</p>
<p>문제는 파일 포맷이었다.</p>
<p>어떤 파일들은 현재 맥북에서는 열리지 않았다. 한컴오피스 뷰어를 깔아봤지만 서식이 깨졌다. 웹 변환기를 돌려봤더니 표는 사라지고 들여쓰기는 뭉개졌다. 파일은 존재했다. 하지만 지식은 이미 죽어 있었다.</p>
<p>우리는 보통 지식의 수명을 &quot;내용&quot;으로 판단한다. 이 이론이 아직 유효한가, 이 데이터가 최신인가. 하지만 진짜 위협은 내용이 아니라 <strong>그릇</strong>에서 온다. .hwp, .ppt, .doc — 이 포맷들은 특정 소프트웨어가 있어야만 열린다. 소프트웨어가 업데이트되면 옛 포맷은 버려진다. 그 안에 담긴 내용이 아무리 훌륭해도, 그릇이 깨지면 꺼낼 수가 없다. 그래도 이 형식을 써야한다면 hwpx, pptx, docx 포맷을 권장한다.</p>
<p>스미소니언 기관은 디지털 보존 가이드에서 plain text를 <strong>최고 등급 보존 포맷</strong>으로 분류한다. 이유는 단순하다. 특정 소프트웨어에 의존하지 않기 때문이다. 1970년대에 작성된 .txt 파일은 2026년 오늘도 아무 도구에서나 열린다.</p>
<p>반면 10년 전 .hwp는 이미 접근 불가능하다. 2000년대 초반, 한국에서 가장 많이 쓰던 워드프로세서 중 하나가 &quot;훈민정음&quot;이었다. 지금 .gul 파일을 열 수 있는 사람이 있는가.</p>
<p>지식의 수명은 내용이 아니라 그릇이 결정한다.</p>
<hr>
<h2><code>#</code> 하나가 세우는 뼈대</h2>
<p>그렇다면 살아있는 그릇은 무엇인가. 그 답이 마크다운이다.</p>
<p>메모장을 열어 글을 쓰다가, 문득 제목 앞에 <code>#</code>을 쳐본 적이 있는가? 메모장에서는 아무 일도 일어나지 않는다. 하지만 Obsidian이나 VS Code에서 같은 행위를 하면, 글자 크기가 커지고, 목차가 생기고, 접을 수 있는 섹션이 만들어진다. 평면에 불과했던 텍스트에 갑자기 건축물의 뼈대가 들어선다.</p>
<p>2004년, 존 그루버라는 블로거가 이것을 세상에 내놓았다. 목표는 단 하나 — &quot;렌더링하지 않아도 사람이 읽을 수 있는 글을 쓰자.&quot; 그는 태그를 없애는 대신, 사람이 이미 습관적으로 쓰는 기호 — <code>#</code>, <code>*</code>, <code>-</code> — 에 구조적 의미를 부여했다. 이메일에서 이미 쓰고 있던 관습을 공식화한 것이다.</p>
<p><code>#</code>은 글자 크기를 키우는 명령어가 아니다. 사고의 위계를 선언하는 행위다. <code># 대주제</code> 아래에 <code>## 중주제</code>를 쓰고, 그 아래에 <code>### 소주제</code>를 넣는 순간, 당신은 글을 쓰는 게 아니라 생각을 구조화하고 있다. 볼드(<code>**텍스트**</code>)는 &quot;이건 놓치면 안 된다&quot;는 판단의 기록이다. 리스트(<code>-</code>)는 &quot;이 항목들은 동등한 무게를 가진다&quot;는 선언이다. 코드블록(<code>```</code>)은 &quot;이건 실행 가능한 지식이다&quot;라는 구분이고, 인용(<code>&gt;</code>)은 &quot;이건 내 말이 아니라 남의 말이다&quot;라는 경계다.</p>
<p>마크다운은 문법이 아니다. 생각의 운영체제다.</p>
<p>그리고 본질적으로 plain text이기 때문에, 50년이 지나도 깨지지 않는다. 살아있는 그릇 위에 사고의 뼈대까지 세운다. 이것이 <code>#</code> 하나가 바꾸는 것이다. 놀랍게도 최근 <a href="https://aikorea.go.kr/web/board/brdDetail.do?menu_cd=000012&num=363">국가인공지능전략위원회에서도 공공 문서 작성 표준을 마크다운으로 채택</a>했다.</p>
<hr>
<h2>세 줄의 하이픈이 여는 세계</h2>
<p>마크다운이 사고의 뼈대를 세운다면, 다음 질문은 이것이다. 10,000개의 노트에서 &quot;지난달 완료한 AI 관련 프로젝트&quot;를 어떻게 찾을 것인가?</p>
<p>파일명을 하나씩 열어볼 수는 있다. 전문 검색으로 &quot;AI&quot;를 쳐볼 수도 있다. 수백 개가 뜬다. 그중에서 &quot;프로젝트&quot;인 것만, 그중에서 &quot;지난달 완료된&quot; 것만 골라내려면? 문서가 자기 자신에 대해 아무것도 말해주지 않기 때문에 생기는 문제다.</p>
<p>해결책은 놀라울 만큼 단순하다. 문서 맨 위에 <code>---</code> 세 개를 쓰고, 그 사이에 몇 줄을 채우면 된다. YAML frontmatter다. 문서의 본문이 시작되기 전에, 이 문서가 &quot;무엇인지&quot;를 기계가 읽을 수 있는 형식으로 선언하는 영역이다.</p>
<p>이것이 들어가면 마크다운 문서는 두 개의 층을 갖는다. 위쪽은 기계가 읽는 <strong>인덱스</strong>, 아래쪽은 사람이 읽는 <strong>서사</strong>. 도서관의 색인 카드와 책 본문이 한 몸에 붙어 있는 형태다. 사서는 색인 카드만 보고 원하는 책을 찾고, 독자는 색인 카드를 무시하고 바로 본문을 읽는다. 두 사용자가 같은 물리적 객체를 완전히 다른 방식으로 사용한다.</p>
<p>이 이중 구조가 게임체인저다. <strong>글을 쓰는 행위 자체가 데이터를 쌓는 행위가 된다.</strong> 추가적인 정리 작업이 아니라, 글쓰기의 자연스러운 부산물로 검색 가능한 지식 베이스가 만들어진다. 노트를 쓸 때 30초를 더 투자해서 frontmatter를 채운다. 그 30초가 나중에 수십 분의 검색 시간을 없앤다. 그리고 그 노트가 100개, 1,000개, 5,000개, 10,000개로 쌓이면, 30초씩 투자한 메타데이터가 전혀 다른 차원의 시스템을 만들어낸다.</p>
<p>(다만 YAML에는 함정이 있다. 가장 유명한 것이 &quot;노르웨이 문제(Norway Problem)&quot;인데, <code>NO</code>라는 값을 쓰면 노르웨이 국가 코드(NO)가 아니라 불리언 <code>false</code>로 해석된다. 단순함이 곧 안전을 의미하지는 않는다.)</p>
<p><code>---</code> — 이 세 줄의 하이픈은 그냥 구분선이 아니다. 문서와 데이터베이스 사이의 경계선이다. 이 선 위에는 기계의 언어가, 이 선 아래에는 사람의 언어가 있다.</p>
<hr>
<h2>AI가 같은 언어를 쓰게 되었다</h2>
<p>여기까지가 인간 쪽의 이야기다. 이제 기계 쪽으로 가보자.</p>
<p>ChatGPT에게 질문을 하나 던져보라. 답변을 자세히 들여다보라. 볼드, 리스트, 헤딩... 마크다운이다. Claude에게 물어봐도, Gemini에게 물어봐도 마찬가지다. OpenAI, Anthropic, Google — 서로 치열하게 경쟁하는 세 회사가 한 가지에는 이견이 없다. 출력 포맷이다. 전부 마크다운으로 답한다. 누가 시킨 것도, 국제 표준으로 정한 것도 아닌데 말이다.</p>
<p>이유는 세 겹이다.</p>
<p>첫째, 학습 데이터. LLM은 GitHub의 수억 개 README.md, Stack Overflow의 답변, 기술 문서를 먹고 자랐다. 인간이 마크다운으로 기록했고, 기계가 그것을 배웠고, 다시 마크다운으로 말하기 시작했다.</p>
<p>둘째, 토큰 경제. &quot;프로젝트 관리의 3가지 원칙&quot;을 마크다운으로 쓰면 약 45토큰이면 된다. 같은 내용을 JSON으로 구조화하면 약 85토큰, XML이라면 약 110토큰이 든다. 같은 이야기를 하는데 비용이 2~3배 차이 난다. AI가 마크다운으로 말하는 것은 미학적 선택이 아니라 경제적 최적화다.</p>
<p>셋째, 구조적 정합성. <code>#</code>은 대주제, <code>##</code>은 소주제, <code>-</code>는 나열, <code>**</code>는 강조. 이 단순한 기호 체계가 LLM의 사고 방식과 정확히 맞물린다. RAG(검색 증강 생성) 시스템에서는 마크다운의 헤딩이 자연스러운 분할 경계가 되어 검색 정확도를 높인다. 많은 RAG 파이프라인이 PDF를 먼저 마크다운으로 변환한 뒤 처리하는 이유가 여기에 있다.</p>
<p>내가 제안하는 EFLM(Extended Format Layer Model) 프레임워크에서 마크다운은 독특한 위치를 점한다. Layer 2(인간이 쓰는 층)와 Layer 4(AI가 소통하는 층)를 동시에 점유하는 유일한 포맷이다. EFLM에 대해서는 별도 강의에서 다루도록 하겠다. 존 그루버가 2004년에 마크다운을 만들 때, 20년 뒤 AI가 이 포맷으로 대화할 것이라고는 상상도 하지 못했을 것이다. Layer 4는 설계된 것이 아니라 창발한 것이다.</p>
<p>인간과 기계가 같은 언어를 쓴다는 것 — 기술사에서 이것은 꽤 드문 일이다.</p>
<hr>
<h2>나만의 확률값</h2>
<p>여기서 결정적인 전환이 일어난다. 마크다운이 인간과 AI의 공용어라면, 그 공용어로 <strong>무엇을</strong> 기록하느냐가 승부를 가른다.</p>
<p>언어모델의 본질은 확률 분포다. &quot;지식관리&quot;라는 단어를 입력했을 때, 일반적인 AI는 다음에 올 단어로 &quot;지식경영&quot;을 0.7의 확률로 예측한다. 드러커, 노나카, 암묵지와 형식지. 인터넷 전체의 평균이 그렇기 때문이다.</p>
<p>하지만 내 기록을 먹인 AI에게 같은 질문을 던지면, 전혀 다른 풍경이 펼쳐진다. 옵시디언이 나온다. 마크다운과 제텔카스텐이 나온다. 빌 에반스와 리처드 파인만이 나온다. 일반 모델에서 Obsidian이 나올 확률은 10%에 불과하지만, 나의 컨텍스트가 반영된 모델에서는 80%로 뛴다.</p>
<p>이 확률의 차이가 곧 <strong>개인화</strong>다. 그리고 이 개인화는 하늘에서 떨어지지 않는다. 기록에서 온다.</p>
<p>사피어-워프 가설(Sapir-Whorf Hypothesis)이라는 것이 있다. 우리가 사용하는 언어가 사고를 규정한다는 가설이다. 이것을 AI에 대입하면 이렇게 된다. <strong>우리가 기록하는 텍스트가 AI의 사고를 규정한다.</strong> <code>[[위키링크]]</code>로 연결한 개념들은 AI에게 뉴런의 시냅스처럼 작동한다. <code># 제목</code>으로 세운 위계는 AI가 정보를 탐색하는 지도가 된다. <code>tags:</code>로 분류한 범주는 AI가 맥락을 파악하는 좌표가 된다.</p>
<p>그래서 PKM의 본질이 여기서 드러난다. PKM은 단순한 메모 저장소가 아니다. 나만의 확률값을 훈련시키는 <strong>데이터셋</strong>이다. 그리고 그 데이터셋은 마크다운으로 기록될 때 비로소 AI가 읽을 수 있는 형태가 된다.</p>
<p>나의 워크플로우를 공개한다. STT로 걸으면서 떠오르는 생각을 날것 그대로 쏟아낸다. 축적된 기록에서 반복적으로 등장하는 개념, 자주 연결되는 아이디어를 파악한다. 그것을 Claude Code 스킬에 반영해 나의 문체와 사고 체계를 담은 글을 생성한다. 핵심은 마지막 단계가 아니라 첫 번째 단계다. 인풋이 빈약하면 아웃풋도 빈약하다.</p>
<p><strong>성문화되지 않은 나만의 지식은 AI에게 존재하지 않는 것과 같다.</strong> &quot;차돌짬뽕&quot;이 침착맨 채널의 철면수심을 의미한다는 것을, 빌 에반스의 즉흥연주와 니클라스 루만의 제텔카스텐을 같은 선상에 놓는 이유를 — 기록하지 않으면 그 연결은 나와 함께 사라진다.</p>
<hr>
<h2>바이올린만으로 교향곡은 연주할 수 없다</h2>
<p>&quot;마크다운이 그렇게 좋으면 다 마크다운으로 하면 되지 않나?&quot;</p>
<p>이 시리즈를 쓰면서 가장 많이 받은 질문이다. 솔직히 말하면, 나도 한때 그렇게 생각했다. 그러다 현실에 부딪혔다. 대학 행정실은 .hwpx를 요구했다. 기업 컨설팅 보고서는 .pptx가 아니면 받지 않았다. 학술지 투고에는 PDF가 필수였다.</p>
<p>마크다운으로 <strong>쓸</strong> 수는 있다. 하지만 마크다운으로 <strong>전달</strong>할 수는 없는 세상이 여전히 존재한다. 그렇다고 마크다운이 부족한 것은 아니다. 질문 자체가 틀렸다. 바이올린이 아무리 훌륭해도 팀파니의 울림을 대체하지는 못한다. 포맷도 마찬가지다. 문제는 대체가 아니라 <strong>분업</strong>이다.</p>
<p>EFLM 모델의 전체 그림이 여기서 열린다. 6개의 층이 각자의 역할을 맡는다. L1(보존)의 plain text가 시간을 이기고, L2(저작)의 마크다운이 사고의 뼈대를 세우고, L3(메타데이터)의 YAML이 문서를 분류하고, L4(AI 인터페이스)에서 마크다운이 인간과 AI의 공용어로 작동하고, L5(기계 교환)의 JSON과 XML이 시스템 간 정확한 데이터를 전달하고, L6(전달)의 HTML, PDF, DOCX, PPTX가 최종 소비자에게 닿는다.</p>
<p>핵심 원칙은 이것이다. <strong>한 번 쓰고, 여러 형태로 내보낸다.</strong> 강의 자료를 마크다운으로 쓴다. YAML frontmatter로 메타데이터를 붙인다. 이 하나의 원본에서 학생용 PDF, 행정실용 HWPX, 웹사이트용 HTML, AI Q&amp;A 시스템의 입력 데이터가 나온다. 내용을 네 번 쓰는 것이 아니다. 한 번 쓰고 네 번 변환하는 것이다.</p>
<p>마크다운은 &quot;모든 포맷을 대체하는 포맷&quot;이 아니라, &quot;모든 포맷이 시작되는 포맷&quot;이다.</p>
<hr>
<h2>같은 곳을 바라보는 사람들</h2>
<p>다시 친한 교수님의 메시지로 돌아간다. 그 안에 이런 대목이 있었다.</p>
<blockquote>
<p>&quot;가끔은 대표님 가시는 길 주변에 앞뒤 주변에 아무도 없어 보이고 이 길이 맞나 싶을 때가 있으시다면, 저를 포함해서 많은 분들이 뒤에서 같은 곳을 바라보고 나름대로의 속도와 맥락으로 같이 따라가며, 주변에서 응원하는 사람들이 생각보다 꽤 많다는 것을 항상 기억해주셨으면 좋겠습니다.&quot;</p>
</blockquote>
<p>읽는데 목이 메었다.</p>
<p>솔직히, 가끔은 이 길이 맞나 싶을 때가 있었다. 내가 너무 앞서 가는 건 아닌가. 아니, 혹시 방향 자체가 틀린 건 아닌가. 주변을 돌아보면 같은 이야기를 하는 사람이 보이지 않았다. 앞에도, 옆에도, 뒤에도.</p>
<p>그런데 뒤에서 걷고 있는 사람들이 있었다. 보이지 않았을 뿐이다. 앞만 보고 걸었기 때문에 뒤를 돌아볼 여유가 없었고, 같은 속도가 아니었기 때문에 옆에 있는지 몰랐다.</p>
<p>깨달음에는 시간이 필요하다. 교수님은 8~9개월 동안 노트를 쓰고, 링크를 걸고, 태그를 달았다. 처음에는 &quot;이게 뭐가 다르지?&quot;라고 느꼈을 수도 있다. 그러다 어느 순간, 과거에 기록한 노트가 예상치 못한 맥락에서 떠올랐을 것이다. 검색하지 않았는데 연결이 보이고, 의도하지 않았는데 패턴이 드러나는 경험. 그때 비로소 &quot;아, 이것이 나만의 맥락정보구나&quot;라는 것을 몸으로 알게 된다.</p>
<p>그리고 이제 자신도 학생들과 교수님들께 같은 이야기를 하고 다닌다고 했다. 2년 전 내가 했던 말을, 2년 뒤 다른 사람이 자신의 언어로 다시 하고 있다. 혁신은 한 사람이 전파하는 것이 아니다. 깨달은 사람이 다시 전파자가 되는 순환이다.</p>
<hr>
<h2>&quot;Markdown Is All You Need&quot;의 진짜 의미</h2>
<p>이 글의 제목을 다시 보자. &quot;Markdown Is All You Need.&quot;</p>
<p>이것은 &quot;마크다운만 쓰면 된다&quot;는 뜻이 아니다.</p>
<p>plain text가 지식을 살려두고, <code>#</code>이 사고의 뼈대를 세우고, <code>---</code>가 문서를 데이터베이스로 바꾸고, AI가 같은 언어를 쓰게 되고, 나만의 확률값이 쌓이고, 포맷 생태계가 분업하고, 같은 곳을 바라보는 사람들이 함께 걷는다 — 이 모든 것이 하나의 선택에서 시작된다는 뜻이다.</p>
<p>마크다운이라는 선택.</p>
<p>그것은 포맷을 고르는 행위가 아니다. 지식을 살아있게 유지하겠다는 선언이고, 흩어진 생각에 구조를 부여하겠다는 결심이며, AI 시대에 인터넷 평균이 아닌 나만의 확률값을 갖겠다는 의지다. 사소해 보이는 기술적 선택 하나가 삶과 사고 방식 전체를 바꾼다.</p>
<p>당신은 어떤가?</p>
<p>당신의 파일은 10년 뒤에도 살아 있을 수 있는가. 당신의 AI는 당신처럼 사고하는가. 당신만의 확률값을 가지고 있는가. 아니면 인터넷 평균의 확률을 그대로 반영하고 있는가.</p>
<p>기록하라. 연결하라. 마크다운으로.</p>
<p>그리고 만약 지금 이 길이 맞나 싶다면, 기억하라. 뒤에서 같은 곳을 바라보며, 나름대로의 속도와 맥락으로 함께 걷고 있는 사람들이 생각보다 꽤 많다는 것을.</p>
<p>중요한 건 도착 시점이 아니라 방향이다.</p>
<p>혹 마크다운 사용하기를 시작하려 한다면 옵시디언을 추천한다. 관련해서 언제든 구요한을 맨션(@)하고 질문하시기를. 질문은 언제나 환영이다. 책을 구매해서 공부하고 싶다면 이번에 출간된 <a href="https://product.kyobobook.co.kr/detail/S000219435979">옵시디언 프로페셔널 노트(구요한 저)</a>를 사랑해주시기를.</p>
]]></content:encoded>
</item>
<item>
<title>지식의 지형학 1부 — 그리고(And)의 세계, 리좀이 그린 태그의 풀밭</title>
<link>https://jisan.cmdspace.work/posts/topology-of-knowledge-1/</link>
<guid isPermaLink="true">https://jisan.cmdspace.work/posts/topology-of-knowledge-1/</guid>
<pubDate>Tue, 27 Jan 2026 03:00:00 GMT</pubDate>
<category>에세이</category>
<description>폴더는 맥락을 하나만 허용하지만, 우리 머릿속의 사과는 과일이자 물리학이자 동화다. 들뢰즈의 리좀으로 태그 시스템을 다시 읽는다. 그러나 모든 것이 모든 것과 연결될 때, 그것은 정보인가 소음인가.</description>
<content:encoded><![CDATA[<figure><img loading="lazy" decoding="async" src="/images/topology-of-knowledge-1/hero-topology-of-knowledge-1.jpg" alt="풀밭 아래로 뻗은 리좀의 뿌리 네트워크"></figure>
<h2>사과는 어디에 있는가</h2>
<p><code>#사과</code>.</p>
<p>이 태그 하나로 무엇이 떠오르는가? 과일 코너의 빨간 사과? 뉴턴의 머리 위로 떨어지던 사과? 백설공주가 한 입 베어 문 독사과? 아니면 스티브 잡스의 한 입 베어 먹은 로고?</p>
<p>폴더 시스템이라면 사과는 하나의 장소에만 있을 수 있다. &#39;과일&#39; 폴더에 넣으면 &#39;물리학&#39; 폴더에서는 사라진다. &#39;동화&#39; 폴더에 넣으면 &#39;IT 기업&#39; 폴더에서는 찾을 수 없다. 그런데 우리의 머릿속에서 사과는 이 모든 곳에 동시에 존재하지 않는가?</p>
<p>필자가 지식관리 강의에서 즐겨 드는 차돌짬뽕 예시도 마찬가지이다. 냉면과 함께 있으면 &#39;면요리&#39;, 탕수육과 함께 있으면 &#39;중화요리&#39;, 침착맨과 단군 사이에 있으면 &#39;철면수심&#39;이 된다(유튜버 철면수심의 별명이 차돌짬뽕이다). 하나의 대상이 어떤 맥락에 놓이느냐에 따라 전혀 다른 의미를 갖는다. 그런데 폴더는 맥락을 하나만 허용한다.</p>
<p>이것이 나무(Tree) 구조의 한계이다. 뿌리에서 줄기로, 줄기에서 가지로. 깔끔하지만 경직되어 있다.</p>
<h2>풀밭이라는 대안</h2>
<p>1980년, 프랑스의 철학자 질 들뢰즈와 정신분석학자 펠릭스 가타리는 《천개의 고원》에서 완전히 다른 구조를 제안했다. 리좀(Rhizome). 감자나 생강의 뿌리줄기처럼 중심 없이 수평으로 퍼져나가는 네트워크이다.</p>
<p>나무가 위계적이라면, 리좀은 수평적이다. 나무에 중심이 있다면, 리좀에는 중심이 없다. 나무가 가지를 자르면 끝이라면, 리좀은 끊어져도 다른 곳에서 다시 이어진다.</p>
<p>들뢰즈의 논리는 접속사 &#39;그리고(And)&#39;이다.</p>
<p><code>#사과</code> <strong>그리고</strong> <code>#뉴턴</code> <strong>그리고</strong> <code>#백설공주</code> <strong>그리고</strong> <code>#IT</code>. 태그는 끝없이 이어지는 &#39;And&#39;이다. 하나의 데이터가 가질 수 있는 맥락을 무한히 늘린다. 상위 폴더에 갇히지 않고, 수평적으로 사방으로 연결된다.</p>
<p>이 철학자들이 컴퓨터 과학자가 아니었다는 점이 흥미롭지 않은가? 40여 년 전에 그린 이 그림이 오늘날 우리가 매일 사용하는 태그 시스템과 놀랍도록 닮아있다.</p>
<h2>태그는 탈주선이다</h2>
<p>들뢰즈는 &#39;줄무늬 공간(Striated Space)&#39;과 &#39;매끄러운 공간(Smooth Space)&#39;을 대비시켰다. 줄무늬 공간은 격자로 나뉘고 통제되는 공간이다. 폴더 시스템이 정확히 그렇다. 각 파일은 정해진 칸에 들어가야 한다.</p>
<p>반면 매끄러운 공간은 유목민의 공간이다. 정해진 길 없이 자유롭게 이동한다. 태그 시스템이 바로 이것이다. 인스타그램에서 <code>#여행</code> <code>#카페</code> <code>#서울</code>을 동시에 붙이면, 하나의 사진이 세 개의 서로 다른 세계와 동시에 연결된다. 경계를 넘어 정보의 바다를 자유롭게 유목하는 것. 들뢰즈는 이것을 &#39;탈주선(Line of Flight)&#39;이라 불렀다.</p>
<p>더 흥미로운 것은 &#39;어셈블리지(Assemblage)&#39; 개념이다. 다양한 요소들이 임시로 모여 하나의 기능을 수행하다가, 해체되고, 다시 다른 조합으로 모이는 것. 지난달에는 <code>#프로젝트A</code> <code>#리서치</code> <code>#긴급</code>으로 묶였던 자료가, 이번 달에는 <code>#프로젝트B</code> <code>#참고자료</code> <code>#아카이브</code>로 재배치된다.</p>
<p>들뢰즈는 이 과정을 &#39;탈영토화&#39;와 &#39;재영토화&#39;라 불렀다. 기존의 분류를 해체하고(탈영토화), 새로운 맥락에서 다시 의미를 부여하는 것(재영토화). 태그 시스템은 정적인 파일 캐비닛이 아니라, 끊임없이 재구성되는 살아있는 지식 생태계이다. &#39;생성(becoming)&#39;의 과정 그 자체.</p>
<p>생성형 AI가 문서를 분석하여 자동으로 태그를 제안하는 시대에, 이 탈영토화와 재영토화는 더욱 역동적으로 변하고 있다. 태그는 단순한 라벨이 아니라, 지식이 해방되고 재조합되는 장치이다.</p>
<h2>그러나 풀밭에는 함정이 있다</h2>
<p>필자의 옵시디언에는 5,300개가 넘는 노트가 있다. 태그와 위키링크라는 리좀적 연결 덕분에, 3년 전에 적어둔 파인만의 물리학 메모가 어제 준비하던 AI 강의 자료와 만나게 된다. 예측하지 못했던 연결이 새로운 통찰을 만든다. 이것이 리좀의 힘이다.</p>
<p>하지만 여기서 불편한 질문을 던져야 한다.</p>
<p>모든 것이 모든 것과 연결될 수 있다면, 그것은 정보인가 소음(Noise)인가?</p>
<p>태그를 50개씩 붙여놓은 노트는 아무 태그도 없는 것과 다르지 않다. 들뢰즈의 매끄러운 공간에는 아름다운 자유가 있지만, 길을 잃기도 쉽다. 리좀은 복잡성을 증폭(Amplification)시킨다. 이것은 창조적 혼돈이 될 수도 있고, 그냥 혼돈이 될 수도 있다.</p>
<p>필자의 볼트에도 잡초가 있다. 한 번 붙이고 다시 찾지 않은 태그들. 붙이던 순간에는 분명 의미가 있었다. 그러나 찾는 순간이 오지 않는 태그는 연결이 아니라 흔적이다. 그래서 요즘은 태그를 붙일 때 하나의 질문을 통과시킨다. 미래의 내가 어떤 장면에서 이 단어로 검색할 것인가. 그 장면이 그려지지 않으면 붙이지 않는다. 태그는 붙이는 순간이 아니라 찾는 순간을 위해 존재한다.</p>
<p>리좀은 저절로 자라지만, 풀밭은 저절로 정원이 되지 않는다.</p>
<p>들뢰즈는 &#39;그리고(And)&#39;의 논리로 세상을 연결했다. 하지만 누군가는 물어야 한다. &quot;그래서, 무엇을 선택할 것인가?&quot;</p>
<p>이 질문에 답한 사람이 있다. 독일에서 9만 장의 메모 카드로 70권의 책을 쓴 한 사회학자. 그의 이름은 니클라스 루만이다.</p>
<p>다음 편에서 만나자.</p>
<hr>
<h3>더 읽을거리</h3>
<ul>
<li>📚 질 들뢰즈·펠릭스 가타리, 《천개의 고원》 (김재인 역, 새물결) — 리좀, 어셈블리지, 탈주선의 원전</li>
<li>📚 티아고 포르테, 《세컨드 브레인》 — 디지털 지식관리의 실천적 입문</li>
<li>🎬 다큐멘터리 《Everything is a Remix》 — 연결과 재조합의 창조성</li>
<li>🎬 TED Talk: Steven Johnson, &quot;Where Good Ideas Come From&quot; — 느린 직감과 연결의 창발성</li>
<li>🛠️ <a href="https://obsidian.md">Obsidian</a> — 리좀적 지식관리를 실현하는 도구</li>
<li>🛠️ <a href="https://neo4j.com">Neo4j</a> — 그래프 데이터베이스로 리좀 구조 구현</li>
</ul>
]]></content:encoded>
</item>
<item>
<title>지식의 지형학 2부 — 아니면(Not)의 세계, 루만이 세운 의미의 경계</title>
<link>https://jisan.cmdspace.work/posts/topology-of-knowledge-2/</link>
<guid isPermaLink="true">https://jisan.cmdspace.work/posts/topology-of-knowledge-2/</guid>
<pubDate>Tue, 27 Jan 2026 02:00:00 GMT</pubDate>
<category>에세이</category>
<description>9만 장의 메모 카드로 70권의 책을 쓴 니클라스 루만. 그 압도적 생산성의 비밀은 근면함이 아니라 선택의 기술이었다. 의미는 연결에서가 아니라 차이에서 나온다 — 무엇을 제외했느냐가 태그의 진짜 기능이다.</description>
<content:encoded><![CDATA[<figure><img loading="lazy" decoding="async" src="/images/topology-of-knowledge-2/hero-topology-of-knowledge-2.jpg" alt="미로 한가운데에서 카드를 연결하는 학자 — 루만의 체텔카스텐"></figure>
<h2>소음 속에서 신호를 건져 올리는 법</h2>
<p>지난 편에서 우리는 들뢰즈의 풀밭을 걸었다. 태그가 만드는 리좀적 연결, 무한히 확장되는 &#39;And&#39;의 세계. 그 풀밭은 아름다웠지만, 마지막에 불편한 질문을 남겼다. 모든 것이 모든 것과 연결될 때, 우리는 어떻게 의미 있는 신호를 소음에서 구분할 수 있는가?</p>
<p>이 질문에 평생을 바친 사람이 있다. 니클라스 루만(1927–1998). 독일의 사회학자. 9만 장의 메모 카드. 70권의 책. 400편의 논문. 이 압도적인 생산성의 비밀은 단순한 근면함이 아니었다. 그것은 &#39;선택의 기술&#39;이었다.</p>
<h2>복잡성이라는 바다</h2>
<p>루만의 출발점은 단순하다. 세상은 너무 복잡하다.</p>
<p>인터넷에는 매일 수십억 개의 데이터가 쏟아진다. 우리의 옵시디언에도, 에버노트에도, 노션에도 노트가 쌓여간다. 들뢰즈의 방식대로 모든 것에 태그를 달고 모든 것을 연결하면 어떻게 되는가? 정보의 파도에 휩쓸려 익사한다.</p>
<p>루만에게 시스템의 지상 과제는 **환경의 압도적인 복잡성을 줄이는 것(Complexity Reduction)**이다. 특정 정보가 의미를 가지려면, 다른 정보들과 구별되어야 한다. 들뢰즈의 논리가 &#39;그리고(And)&#39;였다면, 루만의 논리는 &#39;아니면(Not)&#39;이다.</p>
<p>어떤 데이터에 <code>#사과</code>라는 태그를 단다는 것은 무엇인가? 루만의 관점에서 이것은 수만 개의 다른 태그들—<code>#배</code>, <code>#자동차</code>, <code>#철학</code>—을 <strong>배제한다</strong>는 뜻이다. 의미는 &#39;연결&#39;에서가 아니라 **&#39;차이(Distinction)&#39;**에서 나온다. 무엇을 포함했느냐가 아니라, 무엇을 제외했느냐가 태그의 진짜 기능이다.</p>
<h2>자기생산이라는 심장</h2>
<p>루만의 핵심 개념은 &#39;자기생산(Autopoiesis)&#39;이다. 원래 생물학에서 온 이 개념을 루만은 사회 시스템에 적용했다. 생명체가 스스로 세포를 만들고 유지하듯, 사회 시스템은 소통을 통해 소통을 생산하며 스스로를 유지한다.</p>
<p>여기서 중요한 것은 시스템이 &#39;경계&#39;를 만든다는 점이다. 시스템과 환경을 구분하고, 외부의 무한한 복잡성을 내부에서 처리 가능한 수준으로 줄인다. 태그 시스템으로 번역하면 이렇다. 태그는 무한한 정보의 바다(환경)에서 나에게 필요한 정보만을 시스템 내부로 들이는 **필터(Filter)**이다. 혼돈(환경) 속에 &#39;질서의 섬(체계)&#39;을 만드는 경계선.</p>
<p>이것이 들뢰즈와의 결정적 차이이다. 들뢰즈가 &quot;경계를 허물어라&quot;고 말할 때, 루만은 &quot;경계가 있어야 의미가 생긴다&quot;고 말한다.</p>
<h2>소통의 3중 선택</h2>
<p>루만의 소통 이론은 더 정교하다. 소통은 단순한 정보 전달이 아니라, 세 가지 선택의 연쇄이다.</p>
<p><strong>정보(Information)</strong>: 무한한 가능성 중에서 &#39;이것&#39;을 선택하는 행위. <code>#사과</code>를 선택했다는 것은 <code>#배</code>를 선택하지 않았다는 뜻이다.</p>
<p><strong>발화(Utterance)</strong>: 선택한 정보를 어떤 형식으로 표현하는가. 누가, 언제, 어떤 템플릿으로, 어떤 도구에서 태깅했는가.</p>
<p><strong>이해(Understanding)</strong>: 수신자가 그것을 어떻게 해석하는가. 다른 사람이(혹은 미래의 나 자신이) 그 태그로 다시 검색하고, 재사용하고, 재태깅하는가.</p>
<p>이 세 선택이 연결될 때 비로소 소통이 성립한다. 흥미로운 것은 이 과정에서 오해가 필연적이라는 점이다. 루만에게 오해는 실패가 아니다. 오해는 새로운 소통을 낳는 창조적 힘이다. 내가 <code>#리좀</code>이라고 태깅한 노트를 동료가 <code>#네트워크이론</code>으로 재해석한다면, 그것은 오류가 아니라 새로운 의미의 탄생이다.</p>
<h2>메모 상자라는 대화 파트너</h2>
<p>루만은 자신의 이론을 몸소 실천한 사람이었다. 그의 체텔카스텐(Zettelkasten)—종이 메모 카드 상자—은 현대 태그 시스템의 원형이다.</p>
<p>루만은 이 메모 상자를 &quot;대화 파트너&quot;라고 불렀다. 농담이 아니다. 진지한 이론적 진술이었다. 내가 메모를 적으면(정보), 상자 속 연결망이 관련 카드를 제시하고(발화), 나는 그것을 해석하여 새로운 메모를 작성한다(이해). 소통이 소통을 생산하는 자기생산. 루만 자신의 이론이 자신의 도구에서 작동하고 있었던 것이다.</p>
<p>하지만 루만은 아무 메모나 연결하지 않았다. 자신의 이론 체계를 강화하는 데 도움이 되는 정보만을 엄격히 선별하여 링크를 걸었다. 이것은 철저한 복잡성의 감축이다. 9만 장이라는 숫자가 아니라, 9만 장 사이의 선택적 연결이 그의 생산성의 비밀이었다.</p>
<h2>관측을 관측하라</h2>
<p>루만이 남긴 또 하나의 통찰이 있다. 2차 관측(Second-order Observation).</p>
<p>1차 관측은 &quot;이 노트는 X이다&quot;라고 태그로 지시하는 것이다. 2차 관측은 &quot;왜 X로 태그되는가? 누가 어떻게 쓰는가? 어떤 다의성이 반복되는가?&quot;를 분석하고 규칙을 갱신하는 것이다. 태깅 행위 자체를 관찰하고 개선하는 메타-행위.</p>
<p>대부분의 지식관리 시스템이 성숙하지 못하는 이유가 여기에 있다. 태그를 붙이기만 하고, 태그를 붙이는 행위 자체를 돌아보지 않기 때문이다. 루만은 주기적으로 자신의 카드 인덱스를 검토하고 재구성했다. 관측을 관측하는 것. 이것이 시스템이 살아 숨 쉬는 비결이다.</p>
<h2>나의 미로에는 어떤 벽이 있는가</h2>
<p>루만을 읽고 나서, 필자의 볼트를 루만의 눈으로 다시 보게 되었다.</p>
<p>100번대부터 900번대까지 이어지는 아홉 개의 카테고리는 벽이다. 하나의 노트를 200 Literature에 넣는 순간, 나머지 여덟 세계를 배제한 것이다. 모든 노트에 요구되는 일곱 개의 필수 프로퍼티는 문지방이다. 형식을 갖추지 못한 정보는 시스템 안으로 들어오지 못한다. 불편해 보이는 이 장치들이 사실은 루만이 말한 복잡성 감축의 도구다. 벽이 있어서 답답한 것이 아니라, 벽이 있어서 방이 생긴다.</p>
<p>2차 관측도 이제는 명령이 되었다. 필자는 주기적으로 볼트 전체의 위생을 점검하는 커맨드를 돌린다. 모순된 프로퍼티, 고아 노트, 어긋난 링크를 찾아내는 이 점검은 태그를 관측하는 것이 아니라 태깅 행위를 관측한다. 루만이 카드 인덱스를 재검토하던 그 일을, 이제는 에이전트에게 시키고 있는 셈이다.</p>
<h2>그래서 우리는 선택해야 하는가?</h2>
<p>들뢰즈의 풀밭(리좀)과 루만의 미로(시스템). 자유와 질서. 연결과 선택. &#39;And&#39;와 &#39;Not&#39;.</p>
<p>이것은 양자택일의 문제인가?</p>
<p>폴더 시스템이 루만적이고 태그 시스템이 들뢰즈적이라면, 우리는 둘 중 하나를 골라야 하는가? 루만의 메모 상자가 이 질문에 대한 힌트를 준다. 체텔카스텐에는 번호 체계(구조)와 참조 링크(연결)가 공존했다. 그것은 시스템이면서 동시에 리좀이었다.</p>
<p>다음 편에서는 이 두 거인의 관점을 결합한다. &#39;그리고(And)&#39;와 &#39;아니면(Not)&#39;이 동시에 작동하는 지식 시스템은 어떤 모습인가. 리좀 위에서 작동하는 시스템이란 무엇인가. 그리고 그것이 우리의 일상적 지식관리에 어떤 의미를 갖는가.</p>
<p>9만 장의 메모 카드 속에 답이 있다.</p>
<hr>
<h3>더 읽을거리</h3>
<ul>
<li>📚 니클라스 루만, 《사회의 사회》 (장춘익 역) — 자기생산적 사회 시스템의 핵심 저서</li>
<li>📚 니클라스 루만, 《사회적 체계들》 — 시스템/환경 구분과 복잡성 감축</li>
<li>📚 Sönke Ahrens, 《How to Take Smart Notes》 — 체텔카스텐의 현대적 재해석</li>
<li>🔗 <a href="https://niklas-luhmann-archiv.de/">Niklas Luhmann-Archiv</a> — 루만 체텔카스텐 디지털 아카이브</li>
<li>📄 David Seidl, &quot;Niklas Luhmann as Organization Theorist&quot; — 루만의 조직 이론 적용</li>
<li>📄 노진철(2000), &quot;루만의 자기준거적 체계이론과 성찰적 현실진단&quot; — 한국어 루만 연구</li>
</ul>
]]></content:encoded>
</item>
<item>
<title>지식의 지형학 3부 — 그리고, 아니면(And, Not), 풀밭 위의 미로를 짓는 법</title>
<link>https://jisan.cmdspace.work/posts/topology-of-knowledge-3/</link>
<guid isPermaLink="true">https://jisan.cmdspace.work/posts/topology-of-knowledge-3/</guid>
<pubDate>Tue, 27 Jan 2026 01:00:00 GMT</pubDate>
<category>에세이</category>
<description>메타데이터 태그 시스템은 들뢰즈적 구조(Rhizome) 위에서 작동하는 루만적 기계(System)이다. 연결하라, 그리고 선택하라, 선택한 것을 다시 연결하라. 이 리듬이 계속되는 한 당신의 지식은 살아 숨 쉰다.</description>
<content:encoded><![CDATA[<figure><img loading="lazy" decoding="async" src="/images/topology-of-knowledge-3/hero-topology-of-knowledge-3.jpg" alt="풀밭 위의 미로 — 리좀과 시스템이 공존하는 지형"></figure>
<h2>두 거인이 만났을 때</h2>
<p>1편에서 우리는 들뢰즈의 풀밭을 걸었다. 태그라는 리좀이 만드는 무한한 연결, &#39;And&#39;의 세계. 2편에서 루만의 미로를 탐험했다. 시스템이 세우는 의미의 경계, &#39;Not&#39;의 세계. 풀밭에서는 자유롭지만 길을 잃었고, 미로에서는 안전하지만 숨이 막혔다.</p>
<p>이제 최종 질문이다. 풀밭과 미로를 동시에 가질 수는 없는가?</p>
<p>답부터 말하겠다. 루만은 이미 그것을 만들었다. 9만 장의 메모 카드로.</p>
<h2>체텔카스텐이라는 원형</h2>
<p>루만의 체텔카스텐(Zettelkasten)을 다시 들여다보자. 이 메모 상자가 시리즈의 결론이 되는 이유는, 그것이 들뢰즈와 루만의 이론이 만나는 정확한 교차점이기 때문이다.</p>
<p><strong>구조적으로는 들뢰즈적이다.</strong> 목차도, 위계도, 중심도 없다. 카드는 1, 1a, 1a1, 1b처럼 임의의 번호를 달고 수평적으로 뻗어나간다. 카드 1a에서 카드 57b로 점프하는 참조 링크가 있다. 어디서든 연결되고, 끊어져도 다른 곳에서 이어진다. 리좀이다.</p>
<p><strong>기능적으로는 루만적이다.</strong> 하지만 무작위로 연결하지 않았다. 루만은 자신의 이론 체계를 강화하는 데 도움이 되는 정보만을 엄격히 선별하여 링크를 걸었다. 모든 가능한 연결 중에서 의미 있는 연결만을 선택했다. 철저한 복잡성의 감축이다.</p>
<p>리좀의 구조 위에서 시스템의 작동이 일어나고 있었다. 한 문장으로 정리하면 이렇다.</p>
<blockquote>
<p><strong>메타데이터 태그 시스템은 들뢰즈적 구조(Rhizome) 위에서 작동하는 루만적 기계(System)이다.</strong></p>
</blockquote>
<h2>검색이라는 행위의 본질</h2>
<p>이 통합을 가장 잘 보여주는 것이 &#39;검색&#39;이라는 행위이다.</p>
<p>검색은 무엇인가? 모든 가능성(And) 중에서 하나를 선택(Not)하는 행위이다. 들뢰즈와 루만이 동시에 작동하는 순간이다.</p>
<p>옵시디언에서 <code>#리좀</code>을 검색한다고 생각해 보자. 리좀적 네트워크(And)가 관련된 모든 노트를 수면 위로 끌어올린다. 철학 노트, 지식관리 노트, 태그 시스템 노트, 강의 자료. 그러나 나는 그중에서 &#39;지금 필요한 것&#39;을 선택(Not)한다. 내일 강의에 쓸 사례? 논문에 인용할 정의? 이 선택의 순간에 복잡성이 감축되고, 의미가 확정된다.</p>
<p>검색이 아니라 &#39;태깅&#39; 자체도 마찬가지이다. 루만의 소통 3요소로 분해하면 이렇다.</p>
<ul>
<li><strong>정보</strong>: 어떤 태그를 선택했는가? (<code>#리좀</code>을 골랐다는 것은 <code>#네트워크</code>를 고르지 않았다는 뜻이다)</li>
<li><strong>발화</strong>: 누가, 언제, 어떤 맥락에서 태깅했는가?</li>
<li><strong>이해</strong>: 미래의 나 자신이(혹은 동료가) 이 태그로 다시 찾아와 재사용하는가?</li>
</ul>
<p>태깅은 라벨을 붙이는 행위가 아니다. 소통 사건(Communication Event)이다. 그리고 이 소통이 다음 소통을 낳을 때, 시스템은 자기생산한다.</p>
<h2>세 가지 리듬</h2>
<p>이 통합 모델에는 세 가지 리듬이 있다. 들뢰즈의 언어와 루만의 언어가 동시에 울린다.</p>
<p><strong>첫째, 변이(Variation).</strong> 들뢰즈적으로는 탈영토화이다. 새로운 태그를 자유롭게 만든다. 실험적 분류, 임시 네임스페이스. &quot;이것은 혹시 저것과 관련이 있지 않을까?&quot; 하는 직감을 따른다. 풀밭에 새 뿌리줄기를 뻗는 것이다. 이 단계에서 과도한 통제는 창발성을 죽인다.</p>
<p><strong>둘째, 선택(Selection).</strong> 루만적으로는 코드/프로그램의 적용이다. 생성된 태그들을 관찰한다. 어떤 태그가 반복적으로 사용되는가? 어떤 태그가 혼동을 일으키는가? 동의어는 없는가? 여기서 2차 관측이 작동한다. 태깅 행위 자체를 관찰하고 패턴을 읽는 것이다.</p>
<p><strong>셋째, 안정화(Stabilization).</strong> 들뢰즈적으로는 재영토화이다. 살아남은 태그를 공식 어휘로 고정한다. 동의어는 별칭(alias)으로 유지하고, 사용하지 않는 태그는 폐기하되 리다이렉션을 남긴다. 미로의 벽을 세우되, 그 벽에 문을 낸다.</p>
<p>이 세 리듬은 순환한다. 안정화된 태그가 새로운 태깅을 유도하고(자기생산), 새로운 태깅이 다시 변이를 일으킨다. 끊이지 않는 루프.</p>
<h2>매끄러운 층과 줄무늬 층</h2>
<p>이것을 구체적으로 설계하면 두 개의 층이 된다.</p>
<p><strong>매끄러운 층(Smooth Layer)</strong>: 자유 태그, 실험적 분류, 임시 메모, 원문 인용 조각. 들뢰즈가 말한 &#39;매체(Medium)&#39;의 영역이다. 느슨하게 결합된 요소들이 가능성의 장을 형성한다. 여기서는 규칙이 최소화된다. 마음껏 연결하라.</p>
<p><strong>줄무늬 층(Striated Layer)</strong>: 통제된 어휘, 공식 패싯, 표준 템플릿. 루만이 말한 &#39;형식(Form)&#39;의 영역이다. 느슨한 요소들 중 일부가 응축되어 반복 가능한 구조가 된다. 여기서는 규칙이 명확하다. 정의하고, 분류하고, 검증하라.</p>
<p>필자의 옵시디언 CMDS 시스템이 정확히 이 구조이다. 100번대부터 900번대까지 이어지는 카테고리 체계는 줄무늬 층이다. 복잡성을 축소하고, 의미의 경계를 세운다. 그러나 위키링크와 태그는 매끄러운 층이다. 그 경계를 가로지르며 예측 불가능한 연결을 만든다.</p>
<p>&#39;620 Generative AI&#39;에 있던 노트가 &#39;401 Research Methods&#39;와 만나고, 그것이 다시 &#39;840 Lectures&#39;로 흘러간다. 카테고리(시스템)가 안정성을 주고, 링크(리좀)가 창발성을 준다. 시스템 위에서 리좀이 춤춘다.</p>
<h2>태그는 저장이 아니라 대화이다</h2>
<p>이 시리즈의 결론은 하나의 전환이다.</p>
<p>태그를 &#39;분류 도구&#39;로 보는 관점에서, &#39;소통 장치&#39;로 보는 관점으로의 전환.</p>
<p>루만은 메모 상자를 &quot;대화 파트너&quot;라고 불렀다. 우리의 태그 시스템도 마찬가지이다. 태그는 저장소(archive)가 아니라 대화 파트너(conversation partner)가 될 때 생산성이 폭증한다. 검색에서 연결로, 연결에서 재태깅으로, 재태깅에서 새로운 검색으로 이어지는 순환. 이것이 자기생산이다.</p>
<p>들뢰즈가 없다면 어떻게 되는가? 태그 시스템은 딱딱한 폴더처럼 굳어져 창의성을 잃는다. 과잉 질서. 차돌짬뽕은 영원히 &#39;면요리&#39; 폴더에 갇힌다.</p>
<p>루만이 없다면 어떻게 되는가? 태그 시스템은 쓰레기장처럼 무질서해져 기능성을 잃는다. 과잉 혼돈. 모든 것이 모든 것과 연결되어 아무것도 찾을 수 없다.</p>
<p>스마트한 태그 시스템—옵시디언이든, 노션이든, AI 추천 알고리즘이든—은 이 &#39;무한한 확장(Chaos)&#39;과 &#39;엄격한 선택(Order)&#39; 사이에서 아슬아슬한 줄타기를 하며 지식을 진화시키는 장치이다.</p>
<h2>마지막 질문</h2>
<p>세 편의 여정을 마치며, 필자는 처음의 질문으로 돌아간다.</p>
<p>당신의 지식 시스템은 어떠한가?</p>
<p>풀밭처럼 자유롭게 퍼져가고 있는가? 미로처럼 정교하게 설계되어 있는가? 아니면 루만의 메모 상자처럼, 풀밭 위에 미로를 짓고, 미로의 벽에 문을 내고, 그 문을 통해 또 다른 풀밭으로 나아가고 있는가?</p>
<p>9만 장의 메모 카드로 70권의 책을 쓴 사람은 자신의 메모 상자와 대화했다. 그의 메모 상자는 리좀처럼 연결되어 있었고, 시스템처럼 작동했다. 그것은 단순한 저장소가 아니라, 살아있는 지식 생태계였다.</p>
<p>당신의 노트는 당신에게 말을 걸고 있는가? 그리고 당신은 그 말에 &#39;And&#39;로 응답하고 있는가, &#39;Not&#39;으로 응답하고 있는가?</p>
<p>정답은 둘 다이다.</p>
<p>연결하라. 그리고 선택하라. 선택한 것을 다시 연결하라. 이 리듬이 계속되는 한, 당신의 지식은 살아 숨 쉰다.</p>
<p>풀밭 위의 미로, 리좀 위의 시스템. 그곳에 당신만의 고원이 있다.</p>
<hr>
<h3>더 읽을거리</h3>
<ul>
<li>📚 질 들뢰즈·펠릭스 가타리, 《천개의 고원》 (김재인 역, 새물결) — 리좀, 매끄러운/줄무늬 공간의 원전</li>
<li>📚 니클라스 루만, 《사회의 사회》 (장춘익 역) — 자기생산, 2차 관측의 핵심 저서</li>
<li>📚 Sönke Ahrens, 《How to Take Smart Notes》 — 체텔카스텐의 현대적 실천</li>
<li>📚 송길영, 《시대예보: 핵개인의 시대》 — 개인 지식 시스템의 시대적 맥락</li>
<li>🔗 <a href="https://niklas-luhmann-archiv.de/">Niklas Luhmann-Archiv</a> — 루만 체텔카스텐 디지털 아카이브</li>
<li>🔗 <a href="https://www.w3.org/TR/skos-primer/">W3C SKOS Primer</a> — 개념/라벨 분리 표준</li>
<li>🔗 <a href="https://www.dublincore.org/">Dublin Core</a> — 최소 상호운용 메타데이터 표준</li>
</ul>
]]></content:encoded>
</item>
<item>
<title>나만의 확률값 — AI가 절대 가질 수 없는 것</title>
<link>https://jisan.cmdspace.work/posts/my-probability/</link>
<guid isPermaLink="true">https://jisan.cmdspace.work/posts/my-probability/</guid>
<pubDate>Tue, 30 Dec 2025 04:14:00 GMT</pubDate>
<category>에세이</category>
<description>언어모델의 본질은 확률 분포다. 일반 모델은 인터넷 전체의 평균을 반영하고, 나의 모델은 나의 기록이 만든 확률을 반영한다. PKM은 메모 저장소가 아니라 나만의 확률값을 훈련시키는 데이터셋이다.</description>
<content:encoded><![CDATA[<figure><img loading="lazy" decoding="async" src="/images/my-probability/hero-my-probability.png" alt="나만의 확률값 - AI가 절대 가질 수 없는 것"></figure>
<h2>같은 단어, 다른 세계</h2>
<p>&quot;지식관리&quot;라고 검색해보라.</p>
<p>일반적인 AI에게 물으면 90년대 지식경영(Knowledge Management), 드러커와 노나카의 이론, 암묵지와 형식지 이야기가 줄줄이 나온다. 틀린 말은 아니다. 학술 데이터베이스에서 &quot;지식관리&quot;를 검색하면 그런 논문들이 압도적으로 많기 때문이다.</p>
<p>하지만 내 컨텍스트를 먹인 AI에게 같은 질문을 던지면? 옵시디언이 나온다. Claude Code가 나온다. 마크다운과 제텔카스텐이 나온다. 빌 에반스와 리처드 파인만이 나온다.</p>
<p>왜 그럴까? 언어모델의 본질은 &quot;확률 분포&quot;이기 때문이다. &quot;지식관리&quot; 다음에 어떤 단어가 올 확률이 높은지, 그 확률의 가중치가 모델의 성격을 결정한다. 일반 모델은 인터넷 전체의 평균적 확률을 반영하고, 나의 모델은 나의 기록이 만든 확률을 반영한다.</p>
<p>이것이 바로 <strong>나만의 확률값</strong>이다.</p>
<h2>레고 블록으로 쌓아올린 세계관</h2>
<p>우리는 모두 고유한 확률 분포를 가지고 있다.</p>
<p>내가 좋아하는 재즈 아티스트들, 자주 인용하는 작가들, 반복해서 떠올리는 생각들. 이런 것들이 취향과 관점이라는 이름으로 축적되어 나만의 레고 블록이 된다. 빌 에반스의 즉흥연주, 리처드 파인만의 설명 방식, 니클라스 루만의 제텔카스텐—이런 블록들이 쌓여 구요한이라는 사람의 사고 체계가 만들어진다.</p>
<p>문제는 이 블록들이 머릿속에만 있으면 AI가 접근할 수 없다는 점이다. 아무리 뛰어난 GPT라도 내 머릿속의 연결고리를 알 방법이 없다. &quot;차돌짬뽕&quot;이 침착맨 채널의 철면수심을 의미한다는 것을, 일반 AI는 영원히 모른다.</p>
<p>그래서 기록이 필요하다. 마크다운이 필요하다. 옵시디언이 필요하다.</p>
<p>내가 무엇을 좋아하고, 어떤 맥락에서 어떤 생각을 했는지, 어떤 개념들을 어떻게 연결했는지—이 모든 것이 텍스트로 남아있어야 AI가 학습할 수 있다. 성문화되지 않은 나만의 지식은 AI에게 존재하지 않는 것과 같다.</p>
<h2>인풋이 곧 아웃풋이다</h2>
<p>최근 나의 워크플로우는 이렇다:</p>
<ol>
<li><p><strong>STT로 생각 쏟기</strong>: 걷거나 운전하면서 떠오르는 생각을 음성으로 기록한다. 완성된 문장이 아니어도 된다. 날것의 사고 흐름 그대로.</p>
</li>
<li><p><strong>내 글에 가중치 스코어링</strong>: 축적된 기록 중에서 반복적으로 등장하는 개념, 자주 연결되는 아이디어들을 파악한다. 이것이 나의 확률 분포를 드러낸다.</p>
</li>
<li><p><strong>Claude Code 스킬로 문체 반영</strong>: 내가 발행한 글들을 학습시켜, 비슷한 톤과 구조로 새로운 글을 생성한다. AI가 나의 글쓰기 패턴을 모방하되, 나의 사고 체계를 기반으로.</p>
</li>
</ol>
<p>핵심은 마지막 단계가 아니라 첫 번째 단계다. STT로 쏟아내는 생각의 질과 양이 최종 아웃풋의 품질을 결정한다. 아무리 정교한 AI 도구를 써도, 인풋이 빈약하면 아웃풋도 빈약하다.</p>
<h2>어제의 기록이 오늘의 답을 바꾼다</h2>
<p>이 차이는 추상적인 이야기가 아니다. 강의안을 준비할 때마다 확인하는 일이다.</p>
<p>컨텍스트 없이 &quot;지식관리 강의안을 짜달라&quot;고 하면, AI는 교과서를 내놓는다. 암묵지와 형식지, SECI 모델, 어느 학교에서 가르쳐도 무방한 목차. 틀린 곳이 없고, 그래서 쓸 곳도 없다.</p>
<p>같은 요청을 내 볼트와 연결된 AI에게 던지면 전혀 다른 것이 온다. 차돌짬뽕 예시로 문을 열고, 도메인 어휘의 컨텍스트 덤핑으로 중반을 끌고 가고, 내가 지난달에 만든 프레임워크로 마무리하는 목차. 내 확률값으로 짠 강의안이다. 나는 처음부터 쓰는 대신, 고르고 다듬는 사람이 된다.</p>
<p>인터넷 평균의 답은 누구의 것도 아니다. 내 기록이 만든 답만이 내 것이다.</p>
<h2>일반 LLM vs 나의 LLM</h2>
<p>이것을 수식으로 표현하면 이렇다:</p>
<pre><code>일반 LLM:  &quot;지식관리&quot; → P(지식경영) = 0.7, P(Obsidian) = 0.1
나의 LLM:  &quot;지식관리&quot; → P(Obsidian) = 0.8, P(Claude Code) = 0.6
</code></pre>
<p>일반 모델에서 Obsidian이 나올 확률은 10%에 불과하지만, 나의 컨텍스트가 반영된 모델에서는 80%로 뛴다. 이 확률의 차이가 곧 <strong>개인화</strong>다.</p>
<p>그리고 이 개인화가 AI 시대의 새로운 경쟁력이 된다. 누구나 같은 ChatGPT를 쓸 수 있지만, 모든 ChatGPT가 같은 답을 내놓지는 않는다. 나의 기록을 먹인 AI는 나처럼 사고하기 시작한다.</p>
<h2>PKM은 AI 훈련 데이터셋이다</h2>
<p>결국 Personal Knowledge Management의 본질이 여기서 드러난다.</p>
<p>PKM은 단순한 메모 저장소가 아니다. 나만의 확률값을 훈련시키는 <strong>데이터셋</strong>이다. 매일 기록하는 글 한 줄, 연결하는 링크 하나가 나의 AI를 조금씩 나답게 만든다.</p>
<p>사피어-워프 가설처럼, 우리가 사용하는 언어가 사고를 규정한다면, 우리가 기록하는 텍스트가 AI의 사고를 규정한다. 마크다운의 <code>[[위키링크]]</code>로 연결한 개념들이 AI에게는 뉴런의 시냅스처럼 작동한다.</p>
<p>그래서 나는 묻는다.</p>
<p>당신의 AI는 당신처럼 사고하는가? 당신만의 확률값을 가지고 있는가? 아니면 인터넷 평균의 확률을 그대로 반영하고 있는가?</p>
<p>기록하라. 연결하라. 그것이 당신만의 확률값을 만드는 유일한 방법이다.</p>
<hr>
<h3>더 읽을거리</h3>
<ul>
<li>📚 Sönke Ahrens, 《How to Take Smart Notes》 — 제텔카스텐과 지식 축적의 원리</li>
<li>📚 로버트·미셸 루트번스타인, 《생각의 탄생》 — 창의적 사고와 연결의 힘</li>
<li>📄 《Attention Is All You Need》 논문 — Transformer 아키텍처와 확률 분포의 이해</li>
<li>🎬 TED Talk: Patricia Kuhl, &quot;The linguistic genius of babies&quot; — 언어 학습과 확률 분포</li>
<li>🛠️ Claude Code + Custom Skills — 개인화된 AI 워크플로우 구축</li>
</ul>
]]></content:encoded>
</item>
<item>
<title>2025년 회고 — 174번의 강단, 1번의 응급실, 그리고 하나의 질문</title>
<link>https://jisan.cmdspace.work/posts/retrospective-2025/</link>
<guid isPermaLink="true">https://jisan.cmdspace.work/posts/retrospective-2025/</guid>
<pubDate>Mon, 29 Dec 2025 18:28:00 GMT</pubDate>
<category>에세이</category>
<description>숫자는 양을 말해주지만 의미는 말해주지 않는다. 174번의 강의, 111개의 미팅, 그리고 1번의 응급실 사이에서 발견한 하나의 질문 — 지금 내가 기록하고 있는 것은, 미래의 나에게 친절한가.</description>
<content:encoded><![CDATA[<figure><img loading="lazy" decoding="async" src="/images/retrospective-2025/hero-retrospective-2025.jpg" alt="빈 무대 위의 지휘자 — 악보가 노드와 연결로 변하는 순간"></figure>
<h2>숫자가 말해주지 않는 것</h2>
<p>174번.</p>
<p>올해 내가 강단에 선 횟수다. 단순 계산으로 이틀에 한 번꼴. SK그룹, 유한양행, LG인화원, 삼성전자, 서울대, KAIST, POSTECH... 이름만 나열해도 숨이 찬다. 111개의 미팅 노트, 74개의 데일리 노트, 4,650개 이상의 수정된 파일. 옵시디언이 기록한 나의 2025년은 숫자로 가득하다.</p>
<p>그런데 문득 의문이 든다. 이 숫자들은 대체 무엇을 말해주는 걸까?</p>
<p>바쁘게 살았다는 것? 열심히 일했다는 것? 아니면 그저 정신없이 휘둘렸다는 것?</p>
<p>숫자는 양을 말해주지만 의미는 말해주지 않는다. 174번의 강의가 1번의 깨달음만 못할 수도 있고, 1번의 응급실 방문이 174번의 강의보다 더 많은 것을 가르쳐줄 수도 있다.</p>
<p>2025년을 회고하며 나는 숫자 너머의 것을 찾아보려 한다.</p>
<h2>응급실에서 만난 과거의 나</h2>
<p>9월 23일 새벽. 오른쪽 옆구리를 움켜쥐고 영등포병원 응급실에 누웠다. 요로결석. 4년 전 혼수상태에서 깨어났던 기억이 스쳐 지나갔다. 또 시작인가.</p>
<p>그런데 이상하게도 그 순간 든 감정은 공포가 아니었다. 안도감이었다.</p>
<p>&quot;선생님, 제 옵시디언에 건강 기록 있어요.&quot;</p>
<p>의사 선생님이 어리둥절한 표정을 지었다. 나는 휴대폰을 꺼내 2019년 결석 치료 이력, 수면무호흡 진단 기록, 현재 복용 중인 약물 목록을 보여드렸다. 크레아티닌 수치가 1.4로 정상치를 넘겼지만, 과거 데이터와 비교할 수 있었기에 의료진도 나도 더 정확한 판단을 내릴 수 있었다.</p>
<p>그 순간 깨달았다. 지식관리는 취미가 아니라 생존 도구였다.</p>
<p>수천 개의 노트를 정리하며 &#39;이게 무슨 의미가 있을까&#39; 싶었던 적이 한두 번이 아니다. 하지만 응급실 침대에 누워 있을 때, 과거의 내가 기록해둔 정보가 현재의 나를 살리고 있었다. 미래의 나에게 보내는 편지라고 했던 말이 문자 그대로 실현된 순간.</p>
<p>건강 기록만이 아니다. 내가 왜 이 일을 하는지, 어떤 가치를 추구하는지, 무엇을 두려워하는지—이런 것들도 기록해두지 않으면 위기의 순간에 길을 잃는다.</p>
<p>응급실에서 나는 과거의 나를 만났다. 그리고 그 만남이 나를 구했다.</p>
<hr>
<h2>가르치면서 배운다는 말의 진짜 의미</h2>
<p>&quot;가르치면서 배운다&quot;는 말은 클리셰가 되어버렸다. 너무 많이 들어서 진짜 의미가 희석됐다. 하지만 174번의 강단에 서면서 이 말의 무게를 처음으로 실감했다.</p>
<p>11월, 차의과학대학교 AI헬스케어 세미나. 준비를 하다가 막혔다. &quot;AI 시대에 기록이 왜 중요한가?&quot;라는 질문에 대한 답을 PPT에 적어야 하는데, 손이 움직이지 않았다.</p>
<p>머리로는 안다. 생성형 AI가 모든 것을 만들어내는 시대에, 역설적으로 인간의 기록이 더 중요해진다는 것. 하지만 그걸 설명하려니 말이 꼬였다.</p>
<p>왜?</p>
<p>내가 그렇게 살고 있지 않았기 때문이다.</p>
<p>강의는 거울이었다. 내가 말하는 것과 내가 사는 것 사이의 간극을 적나라하게 비춰주는 거울. 청중 앞에서 &quot;여러분, 메타데이터가 중요합니다&quot;라고 말하면서 정작 내 노트의 메타데이터는 엉망인 날도 있었다.</p>
<p>그런 순간마다 부끄러웠다. 그리고 그 부끄러움이 나를 고쳤다.</p>
<p>강의가 끝나면 곧바로 내 노트를 열어 수정했다. 청중에게 했던 말을 나에게 적용했다. 174번의 강의는 174번의 자기 검증이었다. 책 백 권을 읽는 것보다 한 번의 강의가 더 많이 가르쳐준 이유가 여기에 있다.</p>
<p>설명할 수 없으면 아는 것이 아니다. 그리고 질문받는 자리에 서야 비로소 진짜 전문가가 된다.</p>
<hr>
<h2>솔로에서 오케스트라로</h2>
<p>올해의 가장 큰 변화는 규모였다. 1인 컨설턴트에서 기업 변혁 파트너로.</p>
<p>유한양행 AX 프로젝트가 대표적이다. 9월 17일 킥오프 미팅. 조직 전체의 AI 전환을 설계하는 자리였다. SK그룹에서 2년간 쌓은 경험을 바탕으로 4단계 프레임워크를 제안했다.</p>
<p>1단계: 조직 리터러시 (VOD + 집합교육)
2단계: 5일 집중 코호트 (반복/자동화/RAG 챗봇/대시보드)
3단계: 부서별 커스터마이징 (구매, HR, 규제)
4단계: 문화 내재화 (성과평가에 AI 활용 반영)</p>
<p>혼자 강의하는 것과 조직을 바꾸는 것은 완전히 다른 게임이었다. 나 혼자 잘해서는 안 되고, 시스템이 일하게 해야 했다.</p>
<p>10월, 커맨드스페이스가 법인으로 전환됐다. 4년간의 1인 기업이 끝났다. 세무사님, 법무사님과 서류를 정리하며 깨달았다. 회사를 만든다는 건 내 이름 대신 구조가 일하게 하는 것이었다.</p>
<p>더메디컬 프로젝트도 같은 맥락이다. AI 기반 의료 콘텐츠 자동화 시스템. 버튼 하나로 의료 뉴스가 수집되고, 다국어 TTS로 음성이 생성되고, 영상이 만들어진다. 물론 검수는 필요하지만, 0에서 시작하지 않아도 된다.</p>
<p>자동화는 게으름이 아니다. 내가 진짜 해야 할 일에 집중하기 위한 환경 설계다.</p>
<p>솔로 연주자는 혼자 빛난다. 하지만 오케스트라 지휘자는 다른 사람들이 빛나게 한다. 2025년은 그 전환의 해였다.</p>
<hr>
<h2>무대 위의 AI, 무대 위의 나</h2>
<p>12월 31일. 서울콘 DDP. &quot;유랑, 경계, 즉흥&quot;이라는 제목의 40분짜리 퍼포먼스.</p>
<p>바이올리니스트 KoN, AI 시스템 Dr. POPO와 함께 무대에 섰다. Blue Bossa를 스캣하는 동안 AI가 생성한 영상이 뒤에서 흐르고 있었다. 헝가리안 댄스, 리베르탱고, Going Together... 사람의 즉흥과 기계의 생성이 뒤섞이는 경험.</p>
<p>공연을 준비하며 깨달은 것이 있다. 재즈와 지식관리는 같은 원리로 움직인다.</p>
<p>테마 → 변주 → 반응 → 회수.</p>
<p>재즈 스탠다드를 연주할 때 멜로디를 그대로 치지 않는다. 테마를 잡고, 변주하고, 청중과 밴드의 반응을 읽고, 다시 테마로 돌아온다. 지식도 마찬가지다. 핵심 개념을 잡고, 맥락에 맞게 변형하고, 피드백을 받고, 정제된 형태로 돌아온다.</p>
<p>AI는 대체재가 아니라 협연자였다. 사고 보조자(Cognitive Co-pilot). Claude로 강의 스크립트를 다듬고, Suno로 백트랙을 만들고, n8n으로 반복 업무를 자동화했다.</p>
<p>무대 위에서 AI와 함께 즉흥 연주를 하면서 생각했다. 이것이 내가 1년간 찾던 답인가. AI 시대에 인간은 무엇을 해야 하는가에 대한 답.</p>
<p>AI가 못하는 것. 스스로 질문을 던지는 것. 의미를 부여하는 것. 그리고 불완전함 속에서 아름다움을 찾는 것.</p>
<p>재즈 즉흥 연주처럼.</p>
<hr>
<h2>저장에서 검색으로</h2>
<p>경남 CMDS AI PKM 컨퍼런스에서 이런 말을 했다.</p>
<p>&quot;옵시디언은 노트 앱이 아닙니다. 개인 지식 그래프 엔진입니다.&quot;</p>
<p>청중의 눈이 반짝였다. 그들이 원하는 건 더 예쁜 정리법이 아니었다. 더 빠른 인출법이었다.</p>
<p>올해 가장 많이 한 생각.</p>
<p>&quot;정리를 잘했는가?&quot;가 아니라 &quot;다시 꺼내 쓸 수 있는가?&quot;</p>
<p>4,650개의 파일을 수정하면서 깨달았다. 메타데이터, 태그, 링크는 장식이 아니라 인출 인터페이스였다. 예쁘게 정리하는 것보다 빠르게 찾는 것이 중요했다.</p>
<p>응급실에서 건강 기록을 꺼낼 수 있었던 것도, 강의 준비를 빠르게 할 수 있었던 것도, 결국 인출 가능한 형태로 저장해뒀기 때문이다.</p>
<p>2025년의 가장 큰 깨달음. 더 많이 배우는 것이 아니라 더 잘 꺼내는 것.</p>
<hr>
<h2>하나의 질문</h2>
<p>174번의 강단. 111개의 미팅. 74개의 데일리 노트. 그리고 1번의 응급실.</p>
<p>이 숫자들 사이에서 나는 하나의 질문을 발견했다.</p>
<p><strong>&quot;지금 내가 기록하고 있는 것은, 미래의 나에게 친절한가?&quot;</strong></p>
<p>강의를 준비하며 물었다. 이 PPT가 6개월 뒤의 나에게 도움이 될까?
응급실에서 물었다. 과거의 기록이 지금의 나를 살릴 수 있을까?
무대 위에서 물었다. 이 즉흥 연주가 끝난 뒤에도 남는 것이 있을까?</p>
<p>결국 모든 질문은 하나로 수렴한다. 시간을 초월해 나 자신과 대화할 수 있는가.</p>
<hr>
<h2>2026년을 향해</h2>
<p>새해가 밝으면 또 강단에 설 것이다. 또 미팅을 하고, 노트를 쓰고, 파일을 수정할 것이다. 하지만 방향은 달라져야 한다.</p>
<p>더 배우기 → ❌
<strong>더 잘 꺼내 쓰기 → ⭕</strong></p>
<p>개인 성취 → ⬇️
<strong>타인의 성장을 돕는 구조 → ⬆️</strong></p>
<p>솔로 연주 → ⬇️
<strong>오케스트라 지휘 → ⬆️</strong></p>
<p>174번의 강의가 가르쳐준 것. 설명할 수 없으면 아는 것이 아니다.
1번의 응급실이 가르쳐준 것. 기록하지 않으면 없는 것과 같다.
40분의 공연이 가르쳐준 것. AI와 함께 춤출 수 있다. 두려워하지 않아도 된다.</p>
<p>그리고 이 모든 것을 관통하는 하나의 질문.</p>
<p>미래의 나에게, 지금의 나는 친절한가?</p>
<p>이 질문을 품고 2026년으로 간다.</p>
<hr>
<p>당신의 2025년은 어땠는가? 그리고 당신이 발견한 질문은 무엇인가?</p>
<p>질문하는 한, 우리는 성장한다. 기록하는 한, 우리의 질문은 영원하다.</p>
]]></content:encoded>
</item>
<item>
<title>차돌짬뽕에서 파인만까지 — Organizing Dimension으로 재해석하는 새로운 차원의 이야기</title>
<link>https://jisan.cmdspace.work/posts/organizing-dimension/</link>
<guid isPermaLink="true">https://jisan.cmdspace.work/posts/organizing-dimension/</guid>
<pubDate>Sun, 21 Dec 2025 00:00:00 GMT</pubDate>
<category>에세이</category>
<description>차돌짬뽕이 울면과 냉면 사이에 있으면 면요리, 침착맨과 단군 사이에 있으면 철면수심이 된다. 지식을 체계화하는 다양한 축, Organizing Dimension — 공간·디지털-아날로그·시간·학제간 연결의 네 차원.</description>
<content:encoded><![CDATA[<h2>다차원적 지식 관리의 필요성</h2>
<p>지식을 다차원적으로 바라본다는 것은 마치 오케스트라의 다양한 악기들이 조화를 이루어 하나의 아름다운 선율을 만들어내는 것과 같다. 단일 차원의 접근으로는 복잡다단한 현대 지식을 온전히 이해하고 활용하기 어렵다. 주워들은 이야기가 문득 생각날 때가 있고, 재미있게 보았던 영화나 드라마에서 영감을 얻는가 하면, 기대하지 않았던 ChatGPT 선생님이 놀라움을 줄 때가 있지 않은가? 우리는 지식을 여러 차원에서 동시에 고려하고 조직화하는 새로운 접근 방식이 필요하다.</p>
<h3>지식은 우정을 대신할 수 없어</h3>
<p>지식관리 세미나를 할 때면 자주 언급하는 예시이다. 차돌짬뽕을 알고있니? 차돌짬뽕이 울면과 냉면 사이에 있다면 이것은 &#39;면요리&#39;이다. 탕수육과 짜장면 사이에 있을 땐 &#39;중화요리&#39;라 할 수 있을 것이다. 그런데 이 차돌짬뽕이 침착맨과 단군 사이에 있다면? 철면수심이 된다(유튜버 철면수심의 별명이 차돌짬뽕이다. 한국 사람이라면 유튜브 <a href="https://youtube.com/@ChimChakMan_Official">침착맨 채널</a>을 보아야 하지 않겠나). 어떤 것들과 함께 하는지, 어떻게 조명하는지에 따라 지식이 다르게 배치될 수 있다는 뜻이다.</p>
<figure><img loading="lazy" decoding="async" src="https://i.imgur.com/Rx1tvDT.png" alt="차돌짬뽕"><figcaption>Figure 1. 차돌짬뽕(by Midjourney)</figcaption></figure>
<h2>Organizing Dimension의 개념</h2>
<p>Organizing Dimension이란 지식을 체계화하는 다양한 축 또는 관점을 의미한다. 이는 단순한 정보의 축적이 아닌, 여러 지식 요소들 간의 유기적 연결과 통합적 이해를 추구하는 방법론이다. 나의 이러한 접근 방식의 단초는 대학 시절 리처드 파인만 교수의 물리학 서적을 접하면서 시작되었다.</p>
<figure><img loading="lazy" decoding="async" src="https://i.imgur.com/V19ILtk.png" alt="리처드 파인만"><figcaption>Figure 2. 리처드 파인만</figcaption></figure>
<p>파인만의 독특한 설명 방식은 물리학의 복잡한 개념들을 다양한 차원에서 접근하고 연결 짓는 탁월한 예시였다. 이는 단순한 지식의 전달을 넘어, 지식 체계 전반을 재구성하는 계기가 되었다. 물리의 기초 언어는 수학이다. 수식으로 물리학을 표현하는 것인데, 이 아저씨는 수학 없이 물리 개념을 완벽하게 설명하였다. 수학을 배제하고 물리학을 서술했다기보다는 남들이 당연하다고 생각하는 기본 구조와 골격을 제외한 본질을 드러낸 것으로 이해하면 좋겠다. 파인만의 책은 굉장히 정교한 언어로 물리학과 수학을 구분하여 설명하였으며 &#39;하이탑 물리&#39;에 매몰되어있던 나에게 새로운 세상을 열어주었다.</p>
<figure><img loading="lazy" decoding="async" src="https://i.imgur.com/QPAKJ7w.png" alt="Lectures on physics"><figcaption>Figure 3. Lectures on physics</figcaption></figure>
<h2>Organizing Dimension의 실제 적용</h2>
<h3>1. 공간적 차원</h3>
<p>Organizing Dimension의 첫 번째 적용은 물리적 공간의 재해석이다. 전통적인 의미의 &#39;정돈된&#39; 공간이 아닌, 다양한 지식 활동이 유기적으로 이루어질 수 있는 환경을 조성하는 것이 핵심이다. 나의 작업실에는 다수의 모니터, 음향 장비, 피아노 등이 있는데, 이는 단순한 배치가 아닌 지식의 다각적 접근을 위한 전략적 구성이다(이 공간은 명백하게 정리된 상태이다). 각 장비는 서로 다른 차원의 지식 활동을 지원하며, 이들의 유기적 연결은 새로운 통찰을 가능케 한다.</p>
<figure><img loading="lazy" decoding="async" src="https://i.imgur.com/JAgsO6A.jpeg" alt="CommandSpace HQ 1">
<img loading="lazy" decoding="async" src="https://i.imgur.com/98kNhIs.jpeg" alt="CommandSpace HQ 2">
<img loading="lazy" decoding="async" src="https://i.imgur.com/sVgL9Rf.jpeg" alt="CommandSpace HQ 3"><figcaption>Figure 4. CommandSpace HQ 변천사</figcaption></figure>
<h3>2. 디지털-아날로그 융합 차원</h3>
<p>두 번째 차원은 디지털과 아날로그 방식의 조화로운 융합이다. 고성능 컴퓨터와 최신 프로그램의 활용과 더불어, 30공 바인더나 색깔 코딩 시스템과 같은 아날로그 방식을 병행하는 것은 중요하다. 이는 동양의 관계론적 사고와 서양의 분석적 사고를 결합하는 시도로 이해할 수 있으며 발산적 사고와 수렴적 사고가 유기적으로 일어나게 할 수 있다. 디지털 도구는 빠른 정보 처리와 복잡한 분석을 가능케 하고, 아날로그 방식은 직관적 이해와 창의적 연결을 촉진한다. 300페이지 짜리 책을 PDF 파일로 볼 때보다 실제 종이책을 만질 때 몰입이 커지게 되며, 아날로그 방식은 언제든 가지고 다닐 수 없지만 디지털 파일은 검색이 가능하고 어디서든 사용할 수 있다는 것이 그 이유이다.</p>
<figure><img loading="lazy" decoding="async" src="https://i.imgur.com/5byqXfQ.jpeg" alt="대학원 시절 학습자료 정리 바인더"><figcaption>Figure 5. 구요한의 대학원 시절 학습자료 정리 바인더</figcaption></figure>
<h3>3. 시간적 차원</h3>
<p>세 번째 차원은 지식의 시간적 측면이다. 30여년 전 7살의 구요한은 새로운 것을 배워서 6살의 동생들을 가르쳐주는 즐거움을 알게 되었다. 초등학교 6학년의 구요한은 격주로 H1-H4로 이루어진 구조화된 보고서를 작성하게 되었고(이정래 선생님 감사합니다), 스무살부터 시작되었던 15년간의 과외 경험은 새로운 지식을 습득하고, 이를 다시 교육하는 과정이 얼마나 효과적인 지식 관리 방법인지를 깨닫게 하였다. 이는 지식의 단순한 축적이 아닌, 지속적인 재해석과 재구성의 과정을 의미한다. 시간에 따른 지식의 변화와 발전을 추적하고, 이를 현재의 맥락에서 재해석하는 것이 이 차원의 핵심이다. 친하게 지내는 교수님이 나에게 물었다. &quot;요한씨는 30년 후 어떤 것을 하고 있을 것 같나요?&quot; 내가 답했다. &quot;지금부터 30년동안, 그리고 29년차에 뭘 배우고 있었는지에 따라 다르겠지요?&quot;</p>
<p>무언가를 배우고 나누는 것을 즐겨했던 누적된 시간이 지금의 나를 만들었고 미래의 나를 설계한다.</p>
<figure><img loading="lazy" decoding="async" src="https://i.imgur.com/TyIaYNP.jpeg" alt="피플 애널리틱스 컨퍼런스 발표"><figcaption>Figure 6. 피플 애널리틱스 컨퍼런스 발표</figcaption></figure>
<h3>4. 학제간 연결 차원</h3>
<p>네 번째 차원은 서로 다른 학문 분야 간의 연결이다. 물리학, 음악, 데이터분석, HRD, 지식관리, 생성형 AI 등 다양한 분야의 지식을 유기적으로 연결함으로써, 새로운 통찰과 혁신적 아이디어를 얻을 수 있다. 이는 복잡한 생성형 AI 시대를 살아가기 위한, 우리에게 당면한 문제들을 해결하는 데 필수적인 접근 방식이다. 올해는 어디서 공연을 해볼까. 같이 공연을 기획하고 싶은 사람이 있다면 꼭 연락하시길.</p>
<figure><img loading="lazy" decoding="async" src="/images/organizing-dimension/fig7-jazz-wine-bar-2023.webp" alt="2023년 어느 와인바에서의 재즈 공연"><figcaption>Figure 7. 2023년 어느 와인바에서의 재즈 공연</figcaption></figure>
<h2>Organizing Dimension 접근의 함의</h2>
<p>이러한 다차원적 접근은 단순한 정보 관리 기술을 넘어, 지식을 바라보는 새로운 패러다임을 제시한다. 이는 다음과 같은 의의를 지닌다.</p>
<ol>
<li><strong>통합적 사고의 촉진</strong>: 다양한 차원의 지식을 유기적으로 연결함으로써, 창의적이고 혁신적인 아이디어의 발현을 촉진한다.</li>
<li><strong>적응력의 향상</strong>: 빠르게 변화하는 지식 환경에서 유연하게 대응할 수 있는 능력을 기른다.</li>
<li><strong>지식의 재생산</strong>: 단순한 정보의 소비자가 아닌, 새로운 지식의 생산자로서의 역할을 수행할 수 있게 한다.</li>
</ol>
<h2>결론</h2>
<p>Organizing Dimension을 통한 다차원적 지식 관리는 현대 사회에서 필수적인 새로운 방향성을 제시한다. 이는 단순한 정보의 축적을 넘어, 지식의 유기적 연결과 창의적 재해석을 가능케 하는 방법론이다. 우리는 이러한 접근을 통해, 끊임없이 변화하는 이 시대와 환경에서 더욱 효과적으로 대응하고, 새로운 가치를 창출해 낼 수 있을 것이다.</p>
<p>이제 세컨드 브레인을 구축할 필요성이 생겼는가? 세컨드 브레인은 태도이다(참고: <a href="https://thebetter.stibee.com/p/42">🧠 세컨드 브레인의 진정한 의미: 우리의 고찰 (41호)</a>). 단순한 도구가 아니라 우리의 사고와 행동을 변화시키는 환경설정이다. 옵시디언에서 사용하는 Organizing Dimension을 배우고 싶다면 브라이언과 구요한이 함께하는 CS4BT 교육과정을 찾아주시기를.</p>
<p>이 글에서 제시한 차원도 이것이 전부가 아님을 명심하자. 우리가 표현할 수 있는 어휘력과 문해력이 세상을 보는 창의 깊이와 넓이를 결정하게 된다. 따라서 우리는 계속해서 새로운 차원을 탐색하고, 우리의 지식 관리 방식을 확장해 나가야 한다. Organizing Dimension은 단순한 개념이 아닌, 지식 사회를 살아가는 우리 모두의 새로운 사고방식이 되어야 할 것이다.</p>
]]></content:encoded>
</item>
<item>
<title>선택적 망각의 기술 — AI 시대의 기억 설계와 두뇌-도구 하모니</title>
<link>https://jisan.cmdspace.work/posts/selective-forgetting/</link>
<guid isPermaLink="true">https://jisan.cmdspace.work/posts/selective-forgetting/</guid>
<pubDate>Tue, 18 Nov 2025 00:00:00 GMT</pubDate>
<category>에세이</category>
<description>AI 시대의 역량은 더 많이 기억하는 능력이 아니라 더 잘 잊고 더 빨리 연결하는 능력이다. Core / Cache / Compost / Cold — 정보를 다루는 네 구역의 4C 프레임과 옵시디언 실전 세팅.</description>
<content:encoded><![CDATA[<figure><img loading="lazy" decoding="async" src="/images/selective-forgetting/hero-selective-forgetting.jpg" alt="머리에서 흘러나온 기억이 외부 금고로 옮겨지는 장면 — 선택적 망각"></figure>
<p>냉장고를 열면 오래된 양파와 신선한 바질이 같은 칸에 누워 있다. 우리가 정보를 쌓아두는 방식도 이와 크게 다르지 않다. &quot;다 나중에 쓰겠지&quot;라는 마음으로 넣어둔 메모와 링크는 어느새 서로의 향을 뒤섞고, 필요한 순간에 꺼내 쓰기 어렵게 만든다. AI 시대의 역량은 더 많이 기억하는 능력이 아니라, 더 잘 잊고 더 빨리 연결하는 능력에 가깝다. 선택적 망각은 지식 관리의 결함이 아니라, 리듬이다.</p>
<h3>왜 &#39;잘 잊는 법&#39;이 역량인가</h3>
<p>우리는 보통 잊음을 결함으로 생각한다. 하지만 에빙하우스의 망각곡선이 말해주는 것은 한 가지 더 있다. 망각은 노이즈를 줄이는 자연스러운 필터이며, 새로 들어오는 신호와의 간섭을 줄인다. 잘 잊는다는 건, 중요한 것을 더 크게 들리게 만드는 일이다. 다시 말해, 망각은 무지가 아니라 선택이다.</p>
<h3>AI의 기억은 전지전능하지 않다</h3>
<p>대형 언어 모델은 광대한 텍스트를 배웠지만, 우리의 맥락을 &quot;지금 이 순간&quot;까지 완벽히 기억해주지는 않는다. 컨텍스트 윈도우는 제한적이고, 임베딩은 유사도를 통해 근사치를 데려온다. 그래서 생기는 착시가 있다.</p>
<ol>
<li>기록했다고 기억한 착각: 저장=이해가 아니다.</li>
<li>검색됐다고 정확한 착각: 유사도=정답이 아니다.</li>
<li>붙여넣었다고 설득한 착각: 인용=논증이 아니다.</li>
</ol>
<p>결론은 명확하다. AI의 기억은 강력한 증폭기지만, 무대의 조명과 음향은 우리가 설계해야 한다. 무엇을 남기고 무엇을 지울지, 어떤 것을 묵히고 언제 꺼낼지를.</p>
<p>덧붙이자면, 이 진단은 그 사이 업계의 로드맵이 되었다. 2026년의 AI 메모리 제품들은 &#39;더 많이 저장하기&#39;가 아니라 &#39;잘 잊기&#39;를 기능으로 내놓기 시작했다. ChatGPT는 지난 여행 계획을 다녀온 기록으로 스스로 고쳐 쓰고, 에이전트 메모리 제품들은 기억마다 유효기간을 붙인다. 망각이 결함이 아니라 설계 대상이라는 것. 이 글의 전제가 제품의 언어가 된 셈이다.</p>
<h3>나는 무엇을 잊기로 했는가</h3>
<p>고백하자면, 내 볼트에서 가장 많은 자리를 차지하는 것은 웹클리핑이다. 언젠가 읽겠다며 담아둔 글들. 나는 이것들을 애써 기억의 대상에서 제외하기로 했다. 필요한 순간이 오면 검색이 데려다줄 것이고, 오지 않는다면 애초에 필요하지 않았던 것이다.</p>
<p>대신 절대 잊지 않기로 한 것들이 있다. 회의에서 오간 결정과 그 이유, 문제를 해결한 과정, 내 언어로 다시 쓴 개념. 남의 글은 만료되어도 되지만, 내 판단의 기록은 만료되지 않는다. 이 구분이 서고 나니 쌓이는 것이 두렵지 않게 되었다. 잊어도 되는 이유는 시스템이 기억하기 때문이고, 시스템을 믿는 이유는 내가 그 규칙을 설계했기 때문이다.</p>
<h2>4C 프레임: Core / Cache / Compost / Cold</h2>
<p>정보를 다루는 네 개의 구역을 제안한다. 이름은 간단하지만, 경계는 명확하다.</p>
<ol>
<li><p><strong>Core</strong>: 지금 쓰는 것의 집합</p>
<ul>
<li>범위: 2주 안에 재사용할 내용(초안, 진행 중 문서, 현재 실험)</li>
<li>표식: <code>🔥 Active</code>, 리뷰 주기: 데일리/위클리</li>
<li>효과: 인지 부하 최소화, 작업 전환 속도 향상</li>
</ul>
</li>
<li><p><strong>Cache</strong>: 곧 쓸지도 모를 임시 기억</p>
<ul>
<li>범위: 30일 TTL(만료일)이 있는 참고 스니펫, 링크, 인용</li>
<li>표식: <code>⌛ TTL: 캡처일 +30일</code>, 만료 시 요약만 남기고 본문은 Cold로 이동</li>
<li>효과: 스택 쌓임 방지, &quot;나중에&quot;의 무한 연기를 구조적으로 차단</li>
</ul>
</li>
<li><p><strong>Compost</strong>: 발효되는 아이디어의 정원</p>
<ul>
<li>범위: 재료는 있는데, 아직 요리가 없는 것(메모 파편, 드래프트, 질문)</li>
<li>표식: <code>♻️ Compost</code>, 월 1회 리믹스(요약→재구성→링크백)</li>
<li>효과: 무의미한 축적을 창의적 혼성으로 전환</li>
</ul>
</li>
<li><p><strong>Cold</strong>: 영구 보관, 검색 전용</p>
<ul>
<li>범위: 기록의무, 참고용 PDF/논문, 완료된 산출물의 원본</li>
<li>표식: <code>🧊 Cold</code>, 인덱스는 유지하되, 작업뷰엔 등장 금지</li>
<li>효과: 소유와 사용의 분리(보관=작업 대상 아님)</li>
</ul>
</li>
</ol>
<div class="table-wrap"><table>
<thead>
<tr>
<th>구역</th>
<th>시간 지평</th>
<th>액션</th>
<th>대표 태그/속성</th>
</tr>
</thead>
<tbody><tr>
<td>Core</td>
<td>2주</td>
<td>집중 편집/작성</td>
<td>🔥 Active</td>
</tr>
<tr>
<td>Cache</td>
<td>30일</td>
<td>만료 시 요약만 남기기</td>
<td>⌛ TTL</td>
</tr>
<tr>
<td>Compost</td>
<td>월간</td>
<td>리믹스·링크 재배치</td>
<td>♻️ Compost</td>
</tr>
<tr>
<td>Cold</td>
<td>영구</td>
<td>검색 전용</td>
<td>🧊 Cold</td>
</tr>
</tbody></table></div>
<h2>도구 세팅: 옵시디언에서 망각을 설계하는 법</h2>
<ol>
<li>폴더 맵핑</li>
</ol>
<ul>
<li><code>00. Inbox</code> → 캡처</li>
<li><code>11. Connect / 12. Merge</code> → Core</li>
<li><code>13. Develop</code> → Compost(실험·리믹스)</li>
<li><code>30. Permanent Notes</code> → 정리된 결과(Cold의 인덱스는 이곳에서 연결)</li>
</ul>
<ol start="2">
<li>속성 프리셋(Templater)</li>
</ol>
<pre><code class="language-yaml">---
status: Draft
zone: Cache
ttl: &lt;% tp.date.now(&quot;YYYY-MM-DD&quot;, 30) %&gt;
tags: [PKM, Memory, AI]
---
</code></pre>
<ol start="3">
<li>Dataview로 만료 큐</li>
</ol>
<pre><code class="language-dataview">TABLE file.mtime AS &quot;Last Touched&quot;, ttl
WHERE zone = &quot;Cache&quot; AND date(ttl) &lt;= date(today)
SORT file.mtime ASC
</code></pre>
<ol start="4">
<li>리뷰 리듬(2–2–2 루프)</li>
</ol>
<ul>
<li>2분: 캡처 직후 속성 부여(zone/ttl)</li>
<li>2시간: 세션 종료 전 Core 정리(3개 이하 유지)</li>
<li>2주: Compost 일괄 리믹스→영구노트 전환 or Cold 이동</li>
</ul>
<ol start="5">
<li>자동 요약으로 가벼워지기</li>
</ol>
<ul>
<li><code>obsidian-textgenerator</code> 혹은 Smart-* 플러그인으로 Cache 만료 시 5문장 요약 생성→본문 Cold 이동→Core에 요약만 남기기</li>
</ul>
<h2>음악처럼: 쉼표가 만드는 연결성</h2>
<p>프롬프트가 악보라면, 망각은 쉼표에 가깝다. 모든 음을 끝까지 끌지 않고, 필요한 소리만 남길 때 앙상블은 또렷해진다. 믹싱에서 Mute와 Solo가 있듯, Core는 Solo, Cold는 Mute, Compost는 Send 이펙트처럼 생각해보라. 선택적 망각은 소거가 아니라 편성이다.</p>
<h2>실행 체크리스트(한 장 요약)</h2>
<ul>
<li>오늘: Core 3개 이하 유지, Cache에 TTL 부여</li>
<li>금요일: Dataview 만료 큐 비우기(요약→Cold)</li>
<li>매월 마지막 주: Compost 리믹스 세션 90분</li>
<li>분기별: Cold 인덱스 재구성(링크백만 손보기)</li>
</ul>
<h2>CMDS와 선택적 망각</h2>
<ul>
<li>Connect: 과감히 많이 붙이고(Core/Cache),</li>
<li>Merge: 겹치는 것을 줄이며(요약·태그 통합),</li>
<li>Develop: 남긴 것을 깊게 가공하고(Compost→Permanent),</li>
<li>Share: 결과만 또렷하게 남긴다(Cold는 검색 전용).</li>
</ul>
<h3>에필로그</h3>
<p>더 잘 잊을수록, 더 잘 연결된다. 망각은 기록의 적이 아니라 창작의 파트너다. 우리는 머릿속에 보관하지 말고, 무대에 올려야 한다. 필요한 순간에 꺼내 쓰기 위해.</p>
]]></content:encoded>
</item>
</channel></rss>