LLM 지식 베이스 만들기: 흩어진 생각을 연결된 위키와 시각화로 바꾸는 실용 가이드

URL: https://www.youtube.com/watch?v=IpyEKxGlibI
날짜: 2026-08-14
채널: Tech Bridge
원문 제목: [한영자막] LLM 지식 베이스를 만드는 실용 가이드입니다

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==순간순간 쏟아지는 날것의 생각과 LLM 대화 기록을 최대한 많이 축적한 뒤, 에이전트가 이를 태그·출처·백링크가 있는 노트, 주제별 위키, 인터랙티브 시각화로 변환하게 만들면 개인의 기억과 탐색 능력을 확장할 수 있다.==

• 처음부터 완벽하게 정리하려 하지 말고 음성 입력 등 가장 빠른 방식으로 원재료를 많이 남긴다.
• 에이전트 스킬이 노트의 출처를 조사하고, 허용된 태그를 붙이고, 관련 노트를 찾아 백링크로 연결한다.
• 연결된 노트를 주제별 위키와 사람·개념·조직·출처 색인으로 묶으면 개인적인 Wikipedia형 탐색 공간이 생긴다.
• 스케줄 자동화와 클라우드 샌드박스를 결합하면 잠자는 동안에도 노트가 동기화되고 지식 구조가 갱신된다.
• 에이전트가 HTML과 Tailwind로 그래프·차트·습관 추적기를 직접 만들면 기존 앱을 설치하지 않아도 지식의 구조와 사고의 빈틈을 볼 수 있다.

핵심 흐름은 원재료 수집 → 노트 보강 → 주제별 위키 생성 → 자동 갱신 → 그래프와 차트로 시각화다. 발표자는 Apple Notes 폴더가 무질서한 상태인 청중에게 손을 들어 보게 하고, Obsidian을 써 본 사람과 지금 정기적으로 쓰는 사람은 그보다 적다고 확인한다. 그러나 특정 앱을 사용해야 한다는 주장이 아니라, Markdown 파일을 중심에 두고 어떤 뷰어·에이전트·자동화 플랫폼이든 조합해 반복 가능한 개인 지식 시스템을 만들자는 제안이다.

1. 지식 베이스의 출발점은 정리된 노트가 아니라 날것의 생각이다

정리의 품질보다 기록의 속도와 양을 먼저 확보해야 LLM이 나중에 위키와 시각화를 만들 충분한 재료가 생긴다.

1.1. 최종 상태를 먼저 그리되, 시작은 단순한 Markdown 폴더로 한다

1. 출발점은 산만한 생각의 폴더다

   1. 발표자가 보여 준 첫 상태는 여러 곳에 흩어진 생각과 메모가 뒤섞인 jumbled mess다.
   2. 목표 상태는 모든 생각을 한눈에 보고 클릭하며 탐색할 수 있는 정돈된 화면이지만, 처음부터 그 화면을 직접 만들 필요는 없다.

2. 파일 형식과 도구는 교체 가능하다

   1. 예시에서는 메모를 Markdown으로 기록한다.
   2. 발표자가 직접 만든 앱 Hubble은 Markdown 안에서 노트를 쓰고 탐색하는 화면을 제공하지만, 반드시 Hubble을 사용할 필요는 없다.
   3. Warp, Obsidian, 기타 Markdown 뷰어도 같은 원재료를 읽을 수 있으므로 특정 앱에 지식 베이스를 가두지 않는 구성이 가능하다.

3. 네 단계의 변환을 순서대로 쌓는다

   1. 첫 단계는 LLM과 주고받은 내용, 회의 기록, 독서 메모, 떠오른 생각을 원시 파일로 남기는 것이다.
   2. 두 번째 단계는 관련 백링크와 분류 태그를 추가해 노트를 서로 연결하는 것이다.
   3. 세 번째 단계는 연결된 원재료에서 연구 분야·관심사별 위키를 생성하고, 그 안에 사람·개념·출처 같은 색인을 만드는 것이다.
   4. 네 번째 단계는 HTML 기반 그래프와 차트를 만들어 전체 구조와 패턴을 조망하는 것이다.

1.2. 입력 마찰을 줄이는 음성 기록

1. 음성 입력은 생각을 종이에 옮기는 가장 빠른 방법이다

   1. Apple Notes를 꺼내 타이핑하는 일은 쉽지만, 발표자는 그보다 더 쉬운 입력 방식이 필요하다고 말한다.
   2. 컴퓨터 앞에서 동료들이 듣는 가운데 말하는 일은 조금 어색할 수 있지만, 음성 받아쓰기는 평균 약 200단어/분의 속도를 낸다.
   3. 올림픽 수준의 타이피스트가 아니라면 일반적인 타이핑보다 빠르므로, 생각의 맥락을 잃기 전에 음성 입력 도구로 남기는 편이 유리하다.

2. 유료 서비스 밖에도 로컬 선택지가 있다

   1. WhisperFlow 같은 음성 입력 도구를 쓰는 사람이 생각보다 적다는 점을 지적하면서, 구독료를 내지 않아도 비슷한 작업을 할 수 있다고 소개한다.
   2. Handy는 로컬 모델만 사용하며 기기 밖으로 음성이 나가지 않는 오픈소스 받아쓰기 도구다.
   3. Voice Ink는 비슷한 목적의 도구이며, 발표자는 앱 업데이트를 위해 약 20달러의 평생 비용을 내는 방식이라고 소개한다.
   4. Voice Ink에는 단축키와 모바일 앱이 있어 컴퓨터에서는 Option 키나 Function 키를 누른 채 말하고, 휴대전화에서도 바로 기록할 수 있다.

3. 받아쓰기는 단순한 음성 저장이 아니라 읽을 수 있는 원고가 된다

   1. 도구는 한 번의 긴 발화를 문장과 문단으로 나누고, 반대편에 구두점과 문단 구분이 들어간 형식으로 내놓는다.
   2. 시연 화면의 끝부분이 조금 잘렸지만, 구두점이 자연스럽게 들어오고 긴 녹취가 여러 문단으로 정리되는 모습을 보여 준다.
   3. 발표자는 Acquired 팟캐스트에서 Walt Disney 창업 이야기를 들은 뒤, 그 내용을 한 번의 긴 음성 받아쓰기로 기록한 사례를 제시한다.
   4. 자신에게는 평소 관심사와 조금 다른 주제였지만, 기업이 어떻게 만들어지는지 흥미롭게 읽어 보고 싶어 음성 기록으로 남겼다고 말한다.

1.3. 불완전한 기록을 허용해야 하는 이유

1. 날것의 데이터가 나중의 지식 구조를 가능하게 한다

   1. 회의 녹취, 중요한 문장을 읽은 뒤의 연구 메모, 그 순간 떠오른 단상 등 무엇이든 우선 파일에 넣는다.
   2. LLM에게 위키·시각화·연결 구조를 만들게 하려면 충분한 원재료와 raw data가 필요하다.
   3. 초기에 생각이 조금 산만하고 장황해도 괜찮으며, 완벽한 불릿 목록이나 깔끔한 형식을 갖추지 않아도 된다.

2. 기록의 목표는 순간의 맥락 보존이다

   1. 즉석에서 떠오른 생각을 가능한 한 많이 기록하는 것이 완벽하게 편집하는 것보다 중요하다.
   2. 나중에 LLM이 파일을 검색하고 서로 비교할 수 있기 때문에, 당시 어떤 맥락에서 나온 생각인지 남겨 두는 것 자체가 큰 가치가 있다.
   3. 정리는 입력 시점이 아니라 다음 단계의 에이전트 작업으로 넘길 수 있다.

2. 에이전트로 노트를 보강해 연결된 웹을 만든다

원시 노트의 의미를 새로 쓰기보다 태그·출처·시점·관련 노트를 덧붙이면, 각 파일이 다른 파일로 이어지는 지식망의 노드가 된다.

2.1. Ferrari 메모에서 확인하는 보강 결과

1. 중심에는 원래의 음성 받아쓰기 내용이 남는다

   1. 발표자는 Ferrari의 창업 이야기를 다룬 팟캐스트를 듣고 작은 토끼굴처럼 추가 탐색을 했던 노트를 예로 든다.
   2. 보강 후에도 중심에는 원래의 음성 받아쓰기 스타일과 생각의 흐름이 남아 있어, 에이전트가 원문을 완전히 대체하지 않는다.

2. 주제와 출처 정보가 추가된다

   1. 노트에는 팟캐스트인지, 어떤 관심 분야와 관련되는지 알려 주는 태그가 붙는다.
   2. 에이전트는 출처 URL을 찾아 노트에 기록한다.
   3. 언제 보강했는지 나타내는 시각도 적는다.

3. 하단에 관련 노트가 연결된다

   1. Ferrari 메모와 다른 창업자·기업 관련 팟캐스트 사이의 관계를 찾아 백링크를 만든다.
   2. 새 노트를 계속 추가할수록 서로 연결되는 웹이 촘촘해진다.
   3. 나중에 특정 주제를 기억하지 못해도 관련 키워드나 연결된 노드에서 과거의 생각으로 돌아갈 수 있다.

2.2. enrich note 스킬의 설계

1. 재실행을 고려한 시각 기록

   1. 에이전트에게 노트를 보강하고 타임스탬프를 기록하라고 지시한다.
   2. 다음에 다시 실행할 때 다른 에이전트가 이미 작업했음을 알 수 있어 동일한 보강을 무한히 반복하지 않는다.
   3. 자동화 단계에서는 이 시각 또는 보강 여부를 기준으로 아직 처리하지 않은 파일만 찾을 수 있다.

2. 태그는 선호 목록에서 선택한다

   1. 발표자는 모든 태그를 별도의 preference 폴더에 모아 둔다.
   2. 에이전트가 매번 새롭고 창의적인 태그를 발명하지 않고, 구체적인 목록을 훑어 기존 분류를 재사용하게 만든다.
   3. Claude가 태그를 지나치게 창의적으로 만들 수 있기 때문에, 새 태그를 추가하는 데는 신중하라고 명시한다.
   4. 정말 반복되는 패턴을 발견했을 때만 새 태그를 목록에 추가하도록 예외를 둔다.

3. 출처와 관련 파일을 외부·내부 검색으로 보강한다

   1. 웹 도구로 원출처를 조사해 URL과 맥락을 확인한다.
   2. 모든 에이전트에 웹 검색이 없을 경우 Exa 같은 검색 도구를 하네스에 붙여 출처 조사를 맡길 수 있다.
   3. 파일 호출로 백링크를 찾고, 핵심 용어 검색으로 관련 노트를 찾는다.
   4. 찾은 파일을 노트 하단에 기록하면 관련 자료를 따라가는 상호 연결망이 만들어진다.

2.3. 실행 방식과 모델 선택

1. 수동 호출로 먼저 검증한다

   1. 스킬은 사용하는 하네스에서 수동으로 실행할 수 있다.
   2. 시연에서는 Warp에 들어가 노트 파일 경로를 불러온 뒤 enrich note를 호출하고, Ferrari 관련 노트에 더 많은 세부 정보를 추가하라고 지시한다.
   3. 발표자는 Warp를 좋아한다는 농담을 하면서도, Warp가 여러 모델과 Open Weight 모델을 선택할 수 있다는 점을 장점으로 든다.

2. 작업에 맞는 모델을 실험할 수 있다

   1. 이처럼 파일을 읽고 분류하며 연결하는 작업에는 Open Weight 모델도 시험해 볼 수 있다.
   2. 발표자는 GLM 5.2가 이런 유형의 작업에 매우 잘 맞는 모델이라고 언급하며, 모델을 고정하지 않고 하네스에서 바꿔 가며 실험하는 흐름을 보여 준다.

3. 전체 폴더 처리로 확장한다

   1. 단일 파일을 보강하는 방식이 확인되면, 아직 보강 타임스탬프가 없는 모든 파일을 찾도록 에이전트에게 지시할 수 있다.
   2. 에이전트는 각 파일에 같은 흐름을 적용하고, 파일을 수정해 이전보다 정돈된 노트북을 만든다.
   3. 이 작업은 이후 자동화 일정으로 옮길 수 있으므로, 사용자는 계속 원재료를 추가하고 에이전트가 구조화를 맡는 분업이 가능하다.

3. 연결된 노트에서 개인용 위키를 생성한다

백링크만으로도 과거의 생각을 찾을 수 있지만, 주제별 위키를 얹으면 사람·개념·조직·출처를 중심으로 더 빠르게 탐색할 수 있다.

3.1. 관련 노트만으로도 생기는 개인용 Wikipedia형 탐색

1. Left Hand of Darkness 독서 메모 사례

   1. 발표자는 『The Left Hand of Darkness』를 읽으며 여러 장에서 흥미로운 부분을 발견할 때마다 짧은 메모를 따로 남겼다.
   2. 에이전트가 서로 관련된 메모를 묶어 주자, 책의 각 장에서 나온 생각을 한곳에서 클릭해 따라갈 수 있었다.
   3. Apple Notes를 뒤져 2주 전에 어느 폴더에 적었는지 찾을 필요 없이, 관련 주제로 과거 메모를 발견할 수 있다.

2. 생각의 Wikipedia 토끼굴

   1. Wikipedia의 문서를 따라가며 연쇄적으로 탐색하는 일을 좋아하는 사람이라면, 연결된 노트가 개인의 생각으로 만든 토끼굴처럼 작동한다.
   2. 원래는 서로 떨어져 있던 독서·연구·관심사가 관련 키워드를 통해 서로 이어진다.
   3. 이 단계의 가치는 거대한 문서를 새로 쓰는 데 있지 않고, 이미 적어 둔 것을 다시 발견할 수 있게 만드는 데 있다.

3.2. 위키의 구성 요소와 최신 AI 위키 사례

1. 관심 영역을 한 덩어리로 요리한다

   1. 연결된 raw ingredients를 주제별 위키로 합치면 더 단단하고 읽기 쉬운 탐색 공간이 된다.
   2. 위키는 발표자가 관심을 갖는 주제로 여러 개 만들 수 있으며, 그중 하나는 최신 AI 뉴스 위키다.
   3. 최신 모델의 system card 같은 연구 문서를 읽거나 팟캐스트를 들을 때마다 관련 자료를 같은 위키로 끌어온다.

2. 사람·개념·조직·출처를 색인화한다

   1. 위키 화면에는 가장 관심이 집중된 출처와 주제가 모인다.
   2. 여러 노트에서 추출한 개념을 묶어 보여 주며, 예상했던 개념뿐 아니라 예상하지 못한 교차 관심사도 드러낸다.
   3. 사람 목록에는 각 메모에서 발견한 인물이 들어가고, 조직 목록에는 관련 회사·기관이 들어간다.
   4. AI 음악과 연결된 자료를 통해 재즈 뮤지션 Adam Neely가 AI가 음악 산업에 미치는 영향을 이야기한다는 사실을 찾아내고, 이를 최신 AI 위키 안에 함께 배치한 사례를 보여 준다.

3. 사람이 직접 목차를 작성하지 않는다

   1. 이런 목록과 연결 구조는 프로그램으로 생성된다.
   2. 발표자는 자신에게 시간이 있는 것은 원재료를 만드는 일뿐이며, 자료를 전부 직접 연결하고 분류할 시간은 없다고 말한다.
   3. 에이전트가 반복적인 추출·분류·링크 작업을 맡기 때문에, 사람은 무엇을 읽고 기록할지에 집중할 수 있다.

3.3. Andrej Karpathy의 LLM 지식 베이스 아이디어

1. raw 디렉터리에서 관심 분야별 위키로 이동한다

   1. 발표자는 Andrej Karpathy의 gist를 LLM 지식 베이스 아이디어가 정리된 출발점으로 소개한다.
   2. 핵심 원리는 Apple Notes에서 옮긴 짧은 메모들이 있는 raw 디렉터리를 준비하고, 그중 관심 있는 focus area를 골라 위키로 합치는 것이다.
   3. raw sources를 읽고 위키를 생성하는 기본 원칙을 자신의 폴더 구조와 관심사에 맞춰 조정할 수 있다.

2. 프롬프트로 결과를 취향에 맞춘다

   1. 발표자는 관심 있는 내용이 raw 폴더에 있다고 설명하고, gist의 나머지 지침과 함께 위키를 생성해 달라고 요청했다.
   2. 어떤 영역을 포함할지, 어떤 자료를 중심에 놓을지, 어떤 분류를 만들지에 따라 같은 원칙을 여러 위키에 재사용할 수 있다.
   3. 결과는 사람이 작성한 고정 문서가 아니라, 새 노트가 쌓일 때 다시 생성하거나 갱신할 수 있는 조직화된 지식 공간이다.

3.4. Bible in a Year와 업무 노트로의 확장

1. 낯선 주제의 인물 색인

   1. 발표자는 『Bible in a Year』 팟캐스트를 들으며 성경을 공부하고, 자신의 주된 전문 영역과는 거리가 있는 주제의 노트를 만들었다.
   2. 종교 문헌의 인물 이름은 서로 비슷하고 발음하기 어려워 누가 무엇을 했는지 기억하기 쉽지 않다는 개인적인 난점을 말한다.
   3. 위키는 인물별 항목을 만들고, 각 인물이 한 일과 그 근거가 된 노트로 연결해 준다.

2. 업무 공간의 사람·고객 위키

   1. 회의 메모가 많다면 만난 모든 사람을 모은 people 섹션을 자동으로 만들 수 있다.
   2. 고객 성공(Customer Success) 업무라면 관심 고객과 관련 대화를 한곳에서 찾는 색인으로 확장할 수 있다.
   3. 인물 항목에서 관련 회의와 원출처 링크로 백링크를 만들면, 사람 중심으로 과거 협업 맥락을 다시 찾아볼 수 있다.

3. 원재료로 돌아가는 경로도 남긴다

   1. 위키의 읽기 쉬운 항목이 원래의 raw note를 가려서는 안 된다.
   2. 클릭으로 원본 메모와 출처로 이동할 수 있어, 요약된 인물·개념에서 구체적인 문장과 당시의 생각으로 내려갈 수 있다.
   3. 최종 목표는 매일 만드는 메모를 더 읽기 쉽고 탐색하기 좋은 형태로 바꾸는 것이다.

4. 자동화로 매일·매주 지식 구조를 갱신한다

수동 실행은 결과를 확인하기 좋지만 시간이 걸리므로, 노트 동기화·에이전트 실행·결과 동기화를 일정에 넣어 사용자가 개입하지 않는 흐름을 만든다.

4.1. 온디맨드 생성의 한계와 cadence

1. 에이전트 작업은 즉시 끝나지 않을 수 있다

   1. 발표자는 시연 중 백그라운드에서 에이전트가 노트를 처리하게 두고, 노트 보강과 위키 생성에 시간이 걸리는 모습을 보여 준다.
   2. 따라서 필요할 때마다 수동으로 호출하는 방식만으로는 새 자료가 쌓일 때마다 구조를 유지하기 어렵다.

2. 매일 또는 매주 실행한다

   1. 노트를 보강하는 스킬과 위키를 생성·갱신하는 스킬을 매일 혹은 매주 실행되는 cadence로 바꾼다.
   2. 사용자가 자는 동안 자동으로 처리하면 아침에 전날의 자료가 연결된 상태로 준비된다.
   3. 자료가 들어오는 속도에 맞춰 일일 일정과 주간 일정 중 하나를 선택할 수 있다.

4.2. 로컬 자동화와 클라우드 자동화의 선택

1. Codex 앱의 로컬 자동화

   1. Codex 앱 같은 도구에는 매일 컴퓨터에서 작업을 실행하는 자동화 기능이 있다.
   2. 다만 로컬 자동화가 작동하려면 작업 시점에 노트북이 열려 있어야 한다.
   3. 컴퓨터가 꺼져 있거나 닫혀 있으면 일정이 실행되지 않는다는 운영 조건을 고려해야 한다.

2. oz.dev의 클라우드 일정과 트리거

   1. 클라우드에서 돌리고 싶다면 발표자는 oz.dev를 소개한다.
   2. 일정 기반 실행뿐 아니라 Slack 메시지, iMessage 같은 이벤트를 트리거로 삼을 수 있다.
   3. 로컬 컴퓨터가 항상 켜져 있지 않아도 클라우드 샌드박스가 작업을 시작하게 할 수 있다.

4.3. Markdown을 클라우드 샌드박스에서 처리하는 흐름

1. 동기화 → 실행 → 재동기화의 세 단계

   1. 컴퓨터의 Markdown 폴더를 클라우드 샌드박스 또는 필요할 경우 Docker 기반 박스로 동기화한다.
   2. 그 환경에서 에이전트가 아직 보강되지 않은 노트를 찾고, enrich note 스킬을 실행한다.
   3. 에이전트가 웹 검색·파일 호출·코드 diff 같은 도구 작업을 마치면 수정된 Markdown을 다시 컴퓨터로 동기화한다.

2. Obsidian headless CLI를 사용하는 이유

   1. 발표자는 Obsidian headless CLI를 사용해 컴퓨터의 Markdown 묶음을 다른 환경으로 보내고 다시 내려받는다.
   2. GitHub 폴더에 노트를 두고 git clone으로 가져오는 단순한 방법도 가능하다.
   3. Obsidian CLI를 선호하는 이유는 사용자가 직접 push와 pull을 관리하지 않아도 백그라운드에서 동기화되기 때문이다.

3. 클라우드 안에서 실행할 작업

   1. 클라우드 샌드박스에 Obsidian CLI를 설치하고 Markdown 폴더를 내려받는다.
   2. 아직 보강되지 않은 노트에 대해 enrich note를 실행하도록 에이전트에게 지시한다.
   3. 모든 도구 호출과 코드 변경을 에이전트가 처리하게 하고, 완료 시 결과를 다시 원래 위치에 동기화한다.
   4. 전체 설계는 복잡한 데이터베이스 이관이 아니라, 파일을 잠깐 가져와 처리하고 돌려보내는 단순한 흐름이다.

4.4. 아침에 받는 개인용 일간지

1. 자동화 프롬프트의 구성

   1. 에이전트 환경에 Obsidian CLI가 준비되어 있다고 알려 준다.
   2. 위키를 내려받아 갱신하고, 개인 설정에 필요한 특별 지침을 적용한 뒤 다시 동기화하라고 프롬프트에 적는다.
   3. 이렇게 하면 클라우드 러너가 매일 샌드박스를 새로 만들고 같은 지시를 반복한다.

2. 두 개의 반복 작업

   1. 하나의 일정은 raw note를 주제별 위키로 묶고 기존 위키를 최신 상태로 갱신한다.
   2. 다른 일정은 enrich note를 실행해 태그와 백링크를 추가하고 노트 사이의 탐색 경로를 만든다.
   3. 두 작업 모두 먼저 동기화하고, 에이전트가 처리한 뒤, 수정 내용을 다시 저장소에 밀어 넣는 방식이다.

3. 실제 실행 결과

   1. 발표자는 브라우저에서 클라우드 실행 기록을 확인하며, 전날 만든 노트를 대상으로 enrich note가 동작한 사례를 보여 준다.
   2. 원래는 뒤섞인 메모였지만, 웹 검색으로 팟캐스트 출처를 찾아 다시 들을 수 있는 링크가 생기고, 제목과 관련 노트가 추가된다.
   3. Ferrari 팟캐스트와 다른 창업자 팟캐스트가 관련 자료로 함께 연결된다.
   4. 사용자는 휴대전화로 음성 입력만 하면 되고, 다음 날에는 연결과 정리가 끝난 결과를 받는 운영 모델이다.

5. HTML 시각화로 지식의 구조와 사고의 빈틈을 본다

Markdown과 위키를 넘어 에이전트에게 HTML·Tailwind 결과물을 직접 만들게 하면, 파일을 하나씩 클릭하지 않고 전체 관심사의 구조를 조망할 수 있다.

5.1. 설치형 플러그인 없이 만드는 그래프 뷰

1. 에이전트에게 시각화를 직접 주문한다

   1. 발표자는 노트 앱 안에서 HTML 페이지도 볼 수 있다는 점을 활용한다.
   2. 모든 Markdown 파일을 읽고 HTML과 Tailwind로 그래프 뷰를 만들어 달라고 에이전트에게 요청한다.
   3. 위키 링크를 하나씩 따라가는 대신 전체 노트의 bird's-eye view와 공통 패턴, 관심 영역을 한 화면에서 보려는 목적이다.

2. 별도 도구 설치가 필수가 아니다

   1. 이 그래프 뷰는 새로운 전용 도구를 설치해 만든 것이 아니라, 에이전트에게 직접 빌드하라고 시킨 HTML 결과물이다.
   2. 에이전트가 파일을 읽고 코드를 생성할 수 있으므로 기존 노트 앱 안에 필요한 화면을 추가할 수 있다.
   3. 원하는 인터랙션과 색상, 배치, 차트 유형을 자연어로 조정할 수 있다.

5.2. 그래프가 보여 주는 관심사와 연결

1. 주제 군집을 한눈에 확인한다

   1. 중앙에는 발표자의 직선적인 생각 메모가 모여 있고, 발표자 스스로 산만한 사람이라 그 배치가 어울린다고 농담한다.
   2. 책 관련 노트 군집은 더 읽어야 할 책이 많다는 사실을 보여 준다.
   3. 스타트업 창업, AI와 엔지니어링, 신앙과 성경 관련 메모도 각각의 관심 영역으로 묶여 나타난다.

2. 클릭 가능한 노드로 내려간다

   1. 각 노드를 클릭하면 어떤 원본 노트인지 볼 수 있다.
   2. 해당 노트가 다른 생각과 어떻게 연결되는지도 확인할 수 있다.
   3. 그래프를 걸어 다니듯 탐색하면서 현재 실제로 무엇에 관심이 있는지, 어느 분야에 생각의 빈틈이 있는지 파악한다.
   4. 전체 조망에서 출발해 특정 문서와 연결된 아이디어로 드릴다운하는 두 가지 탐색이 가능하다.

3. 표현 방식도 데이터와 함께 바꾼다

   1. 발표자는 그래프를 우주 공간에 놓아 달라고 요청한다.
   2. 노드와 연결선이 별자리처럼 보이는 star constellation 형태로 바뀐다.
   3. 같은 데이터라도 시각적 은유를 바꾸면 연결 구조를 다른 감각으로 살펴볼 수 있다는 사례다.

5.3. 그래프를 습관 추적기로 확장한다

1. 기록 빈도를 차트로 만든다

   1. 특정 주제에 대해 얼마나 자주 노트를 쓰는지 추적하는 habit tracker를 만들 수 있다.
   2. GitHub의 잔디 그래프와 비슷한 burn-down chart를 연결해 기록 습관의 변화량을 표시할 수 있다.
   3. 발표자의 실제 기록 습관은 매우 일정하지 않지만, 그래프가 쌓이면서 습관의 형성 정도를 확인할 수 있다.

2. 시각화의 범위는 제한되지 않는다

   1. 그래프, 차트, 트래커 등 어떤 화면이든 데이터와 목적에 맞춰 에이전트에게 만들게 할 수 있다.
   2. 필요한 것은 새 앱을 찾는 일보다 어떤 패턴을 보고 싶은지, 어떤 노드를 클릭하고 싶은지, 어떤 시간 변화를 추적할지 구체적으로 말하는 일이다.

주요 발언 모음

“목표는 지금 이 순간 가능한 한 많은 생각을 내려놓는 것이다. 완벽한 불릿 포인트로 형식을 맞추지 않아도 괜찮다.”

“LLM에게 위키와 시각화를 만들게 하려면 많은 raw data, 많은 raw materials가 필요하다.”

“관련 주제로 찾을 수 있다면, 2주 전에 Apple Notes 어디에 저장했는지 찾아 헤맬 필요가 없다.”

“모든 일을 직접 할 필요가 없다. 휴대전화로 음성 받아쓰기만 하면 나머지 결과가 반대편에서 나온다.”

“내가 원하는 것은 내가 작성하는 모든 것의 bird's-eye view다. 공통 패턴과 공통 관심 영역을 찾아 달라.”

“무엇을 만들고 싶든 에이전트에게 요청하면 된다.”

핵심 데이터 & 수치

• 약 200단어/분: 발표자가 음성 받아쓰기의 평균 속도로 제시한 수치이며, 일반적인 타이핑보다 빠른 입력 방식이라는 근거다.
• 약 20달러 평생 비용: 발표자가 Voice Ink의 앱 업데이트를 위한 평생 비용으로 언급한 금액이다.
• 일일 또는 주간 cadence: 노트 보강과 위키 생성 자동화를 운영할 수 있는 반복 주기다.
• 네 단계 파이프라인: 원재료 수집, 노트 보강과 연결, 위키 생성, 그래프·차트 시각화로 이어지는 발표의 전체 구조다.
• 주요 도구: Hubble, Warp, Obsidian, Handy, Voice Ink, Exa, Codex 앱, oz.dev, Obsidian headless CLI가 각기 작성·검색·자동화·동기화의 예시로 등장한다.
• 대표 원재료: Acquired의 Walt Disney 창업 팟캐스트, Ferrari 창업 팟캐스트, 『The Left Hand of Darkness』 독서 메모, 최신 AI 모델 system card 연구 문서, 『Bible in a Year』 팟캐스트가 지식 구조화 사례로 사용된다.

실전 적용 절차

1. 저장소를 만든다: Markdown 파일을 넣을 raw 폴더와 선호 태그를 모아 둘 preference 폴더를 준비한다.
2. 입력 속도를 높인다: 컴퓨터와 휴대전화에 음성 받아쓰기 도구를 설치하고, 회의·독서·대화·LLM 작업에서 떠오른 내용을 즉시 기록한다.
3. 형식을 강제하지 않는다: 구두점이나 불릿이 완벽하지 않아도 원래의 맥락과 생각을 보존한다.
4. 보강 스킬을 만든다: 보강 시각 기록, 기존 태그 선택, 새 태그 추가 제한, 출처 웹 조사, 관련 파일 검색, 백링크 추가를 지시한다.
5. 수동 실행으로 확인한다: 한두 개 노트에 enrich note를 적용해 태그·출처·관련 노트가 원하는 형태로 나오는지 검증한다.
6. 폴더 단위로 확장한다: 아직 보강되지 않은 파일만 찾아 전체 노트에 같은 작업을 적용한다.
7. 주제별 위키를 만든다: 관심 영역을 자연어로 설명하고 raw 폴더를 입력으로 지정해 사람·개념·조직·출처 목록과 원본 백링크를 생성한다.
8. 클라우드 자동화를 붙인다: Obsidian headless CLI나 Git으로 Markdown을 샌드박스에 동기화하고, 에이전트 실행 후 수정 파일을 다시 동기화한다.
9. 일정과 트리거를 정한다: 로컬 노트북을 켜 둘 수 있으면 로컬 자동화를, 그렇지 않으면 oz.dev 같은 클라우드 일정과 Slack·iMessage 트리거를 사용한다.
10. 시각화를 요청한다: HTML·Tailwind로 클릭 가능한 그래프를 만들고, 필요하면 별자리 레이아웃이나 기록 빈도 차트를 추가한다.

결론 및 시사점

1. 입력과 정리를 분리한다: 사람은 순간의 생각을 많이 남기고, 에이전트는 나중에 분류·연결·출처 조사·시각화를 수행하는 편이 지속 가능하다.
2. 파일을 원본으로 유지한다: Markdown 원재료와 원출처 링크를 남겨 두면 어떤 뷰어나 위키가 바뀌어도 지식의 기반을 보존할 수 있다.
3. 태그의 폭발을 막는다: 선호 태그 목록과 새 태그 추가 조건을 명시해야 에이전트가 비슷한 주제에 매번 다른 분류를 만들지 않는다.
4. 연결이 검색보다 강하다: 백링크와 키워드 연결은 과거 메모를 날짜나 저장 위치가 아니라 주제와 관계로 다시 찾게 한다.
5. 위키는 개인의 탐색 레이어다: 특정 연구·독서·업무 분야에 대한 사람, 개념, 조직, 출처의 색인을 자동으로 만들면 개인의 Wikipedia형 지식 공간이 생긴다.
6. 자동화는 동기화 경계를 명확히 해야 한다: 원본을 내려받고, 처리하고, 수정 결과를 되돌리는 세 단계를 분리하면 클라우드 에이전트도 안전하게 반복 실행할 수 있다.
7. 시각화는 장식이 아니다: 군집과 연결선은 실제 관심사, 연결이 약한 분야, 기록 습관의 공백을 발견하게 하는 분석 도구다.
8. 작은 기록을 오래 쌓는 것이 핵심이다: 완벽한 지식 관리 시스템을 먼저 만들기보다 매일 음성이나 텍스트로 raw material을 축적하는 것이 전체 파이프라인의 출발점이다.