마츠오 연구소(Matsuo Institute)의 오자키입니다. 25년 졸업 예정자로 데이터 사이언티스트로 일하고 있습니다.

이전에 「AI 시대의 태스크 관리에 대해 생각하기」라는 글을 썼습니다. 대략적으로 말하자면, AI에게 실행을 「위임(delegation)」하고 인간은 여러 작업의 「중간 상태(intermediate state)」를 감독하는 데 전념한다면, 멀티태스킹의 스위칭 코스트(switching cost)를 대폭 낮출 수 있지 않을까, 그리고 태스크 관리는 머지않아 「사람의 생산성을 높이는 도구」와 「AI를 움직이는 인터페이스(interface)」를 겸하게 되지 않을까 하는 이야기였습니다.

그 기사의 숙제로서, 「그렇다면 그 "인터페이스"의 실체는 구체적으로 무엇인가?」라는 점에 대해 생각해 보려 합니다. 당시의 저는 Gemini 중심적인 환경(Google 생태계 + 자연어)을 소개했지만, 솔직히 그것은 「입력 지원」 수준에 그쳤으며, AI가 관리에 깊이 관여하는 형태는 아니었습니다.

그로부터 반년. 이것저것 만들고 부수는 과정을 반복하던 중, 해외 연구자들을 중심으로 앞다투어 프로토콜화가 진행되고 있는 Personal Knowledge Base (PKB = 개인 지식 베이스)에 도달했습니다. 이른바 Obsidian의 Vault 내에 자신의 하루 작업 내용과 섭취한 정보를 축적하고, 이를 Claude Code와 같은 CLI Agent와 함께 정리함으로써, 자신의 태스크는 물론 메모리(memory) 자체를 관리하면서 동시에 작업도 진행한다——는 것입니다. 그리고 시행착오 끝에 도달한 저만의 답이, 본 기사에서 소개할 Claudian Orchestra입니다. Obsidian의 Vault(플레인 Markdown 군)를 인간과 AI의 공유 메모리(shared memory)로 삼고, Claude Code를 지휘자로 하여 여러 에이전트가 그 Vault를 정리·운영하는——그런 구성의 PKB입니다.

본 기사에서는 ①지난번 숙제의 확인 → ②2026년 활발하게 논의되는 「AI에 실리는 지식 베이스」 흐름 (Karpathy 스타일 · Google 스타일 · 상용 · 연구) → ③그 흐름 속에서 제가 만든 Claudian Orchestra의 설계 → ④지난번의 철학이 어떻게 구현으로 이어졌는가, 라는 순서로 써 내려가겠습니다. 여전히 「생각해 보았다」 계열의 에세이라고 생각하고 읽어주세요 (웃음).

1. 지난 내용 복습: 태스크 관리는 「AI를 움직이는 인터페이스」가 된다

먼저 지난번의 주장을 3가지만 되짚어 보겠습니다.

#	지난번의 주장	요점
1	멀티태스킹의 재정의	인지 심리학의 지견에 따르면, 유사한 작업으로서 「한 덩어리」로 인지할 수 있다면 스위칭 코스트는 낮아진다. AI에게 실행을 위임하면 인간은 중간 상태의 감독에 전념할 수 있다
...

이 중 세 번째, 「인터페이스화」가 숙제였습니다. 인터페이스라고 말하는 것은 쉽지만, 인간과 AI가 같은 것을 보고, 같은 것에 기록하며, 거기서 다음 행동이 태어나는——그런 공유 면을 어떤 매질(substrate)로 만들면 좋을 것인가, 라는 과제가 떠오릅니다. 다만 때마침 2026년에 접어들며, 이 질문에 대한 답이 곳곳에서 솟아나오기 시작했습니다.

2. 「AI에 실리는 지식 베이스」가 동시다발적으로 발생하고 있다

2.1 Karpathy의 "LLM wiki / AI second brain"

계기는 바이브 코딩(vibe coding)의 창시자인 Andrej Karpathy가 공유한 "LLM wiki" (AI second brain)라는 컨셉이었습니다.

그의 주장은 「지식 베이스(wiki)의 유지보수를 LLM에 맡기고, 인간은 소스(source, 소재)를 던져 넣는 것과 질문을 던지는 것에 전념한다」는 것으로, 소재를 집어넣는 sources/, 그것을 증류한 본체인 wiki, CLI Agent 제어를 위한 schema, 그리고 시계열의 추가 로그(append-only log)——라는 구조를 제안하고 있습니다.

2.2 Google의 Open Knowledge Format (OKF)

나아가 그 발상을 포맷으로서 표준화하러 온 것이 Google Cloud입니다. 2026년 6월, **Open Knowledge Format (OKF)**라는 사양이 공개되었습니다 (착안점으로 바로 Karpathy의 LLM wiki가 언급되었습니다).

OKF의 본질은 심플하며, 3가지 "Just"로 설명됩니다.

원칙	의미
Just markdown
어떤 에디터에서도 읽을 수 있고, GitHub에서 렌더링되며, 어떤 검색 도구로도 인덱싱할 수 있음
Just files
tarball로 배포할 수 있고, 임의의 git repo에 호스팅할 수 있으며, 임의의 파일 시스템에 마운트할 수 있음
Just YAML frontmatter
쿼리 가능한 필드는 소수뿐임: type (필수) / title / description / resource / tags / timestamp

설계 사상은 "The format is the contract; the tooling at each end is independently swappable." (포맷이 계약이며, 양 끝의 도구는 독립적으로 교체 가능하다)입니다. 특정 클라우드나 DB, 모델 프로바이더, 에이전트 프레임워크에 얽매이지 않는 — 즉, format(포맷)이지 platform(플랫폼)이 아니다라고 명시하고 있습니다.

어떻게 wiki를 만들고, 어떻게 PKB(Personal Knowledge Base)로서 운용하는 것이 베스트 프랙티스(Best Practice)인지 각 분야에서 탐색하고 있는 인상이며, OKF는 그러한 흐름 속에서 프로토콜화를 목표로 하는 움직임이라고 파악됩니다.

2.3 상용: 「답하는 AI」와 그 너머

상용 및 컨슈머 세계에서는 이미 「자신의 자료를 바탕으로 출처와 함께 즉시 답하는」 경험이 실현되었습니다. 친숙한 사례로는 Google의 NotebookLM이 있으며, 기업용으로는 Capacity의 **Answer Engine®**이 그 대표적인 예입니다.

Capacity의 캐치프레이즈가 매우 뛰어난데, "Answers, not documents" (문서가 아니라, 답을)입니다. 기존의 검색이 「파란 링크의 목록」을 반환하는 것에 반해, 출처의 위치와 함께 "답" 그 자체를 반환합니다. 게다가 열람 권한 내의 데이터만을 근거로 삼는 (할루시네이션 (Hallucination) 억제) 설계입니다. NotebookLM 역시 발상은 동일하여, 업로드한 자료군을 근거로 인용과 함께 답해줍니다.

다만, 이들은 모두 지식 베이스를 "읽고 답할" 뿐인 도구라는 점에 주의해야 합니다. 자료군 그 자체는 정적인 상태로 방치되며, 「누가 그 지식 베이스를 키우고, 정리하고, 계속해서 써 내려갈 것인가」는 손대지 않은 상태로 남습니다. 즉, 던져 넣은 자료는 던져 넣은 채로 남으며, 구조화나 증류(Distillation)는 인간의 숙제로 남게 됩니다.

「AI가 출처와 함께 즉답하게 하는 것」(기존의 RAG와 같은 방식)뿐만 아니라, AI 스스로가 소재를 증류하고, wiki 본체를 다시 쓰며, 구조 자체를 계속해서 유지·보수하는 — 즉, 2.1의 LLM wiki와 2.2의 OKF가 그리는 「살아있는」 지식 베이스를 고민해보고자 합니다.

2.4 「사용자의 기억」을 Agent가 다루게 하는 연구

그리고 학계/OSS에서도 「에이전트에게 외부의 구조화된 사용자 기억을 갖게 하는」 연구가 급격히 두터워졌습니다.

연구	연도	한 줄 요약
MemGPT[1]	2023	LLM을 OS처럼 간주하여, 컨텍스트 외부에 장기 기억을 영속화함
CoALA[2]	2023	언어 에이전트의 기억을 모듈로서 정리한 이론적 프레임워크 (외부의 구조화된 기억을 일반화)
A-MEM[3]	2025	Zettelkasten (메모법)에서 착안한 에이전트 기억. 인간의 메모 습관을 기억 설계로 이식
Mem0[4]	2025	영속 기억 레이어의 산업적 구현 (프로덕트와 쌍을 이룸)

흥미로운 점은, A-MEM이 Zettelkasten이라는 "인간의 지적 생산 메소드"를 명시적으로 밑바탕에 두고 있다는 점입니다. 에이전트의 기억 설계가 PKM — Personal Knowledge Management, 즉 자신의 지식을 「포착 → 정리 → 연결 → 재사용」하는 개인 지식 관리의 활동 (Zettelkasten이나 후술할 Second Brain이 그 대표적 사례) — 의 전통으로 회귀하고 있습니다.

3. PKM이 줄곧 말해왔던 것

「외부에 지식을 저장하고, 그것과 대화하며 생각한다」는 발상은 AI 이전부터 PKM 세계에서 줄곧 이야기되어 온 것이기도 합니다.

인물 / 개념	주장	AI 시대의 재해석
Niklas Luhmann (Zettelkasten) [5]	메모 더미는 단순한 보관소가 아니라 "대화 상대 (communication partner)"이다	그 대화 상대가 이제 LLM이 되었다
Tiago Forte (Building a Second Brain) [6]	뇌는 "아이디어를 갖기 위한" 것이지, "저장하기 위한" 것이 아니다	저장은 Second Brain에, 사고는 인간에게, 실행은 AI에게
Andy Matuschak (evergreen notes) [7]	지적 생산은 일회용이 아니라 "축적 (accrete)"되어야 한다	축적된 문맥이 그대로 AI의 작업 문맥이 된다

Luhmann가 말한 "메모는 communication partner"라는 말은 지금 읽어보면 다소 예언적입니다. 그의 시대에 "대화 상대"는 어디까지나 비유였지만, 2026년의 우리는 그 상대에게 정말로 말을 걸 수 있습니다. 지난번에 스위칭 코스트 (switching cost) 이야기를 했지만, 지식을 외부에 꺼내어 인지 부하를 낮춘다는 PKM의 기본 동작은 "AI에게 전달할 문맥을 외부화하는" 동작과 거의 같다고 말할 수 있을지도 모릅니다.

4. Claudian Orchestra

긴 서론이었지만, 여기서부터가 본론입니다. 위에서 언급한 흐름 속에서 제가 실제로 구축하여 매일 사용하고 있는 것이 바로 본 기사의 제목이기도 한 Claudian Orchestra입니다. 참고로 운영 인스턴스(실제 Vault 폴더)의 이름은 MY_MEMORY이며, 이후 스크린샷에 등장합니다.

전제로서 오자키(Ozaki)가 어떤 PKB를 구축하고 어떤 경험을 하고 싶은지에 대한 요구사항을 나열하면 다음과 같습니다.

• Markdown 파일을 메인 관리 파일로 한다.
• Markdown 파일 이외의 것도 넣어두고 싶다.
• Claude Code Orchestra가 구조화해주길 바라며, 함께 편집하고 싶다.
• 인간이 보는 곳과 AI만 보는 곳을 명확히 구분한다.
• 일상 업무나 연구에서 사용하는 외부 소스로부터의 정보 추출도 자동화하고 싶다. (Web 버전 ChatGPT와의 대화 포함)
• 작업 메모리가 알아서 정리되고, 알아서 구조적으로 저장되길 바란다.
• Terminal을 사용하고 싶고, 가끔 간단한 코드도 실행하고 싶다.
• 동일한 폴더 내에서 업무와 연구를 모두 관리하고 싶다.
• Google Calendar나 Google Tasks 등 익숙한 도구는 바꾸고 싶지 않다.
• 여러 PC에서 동일한 PKB를 사용하고 싶다.

등등, 다소 욕심이 많지만... (웃음)

4.1 전체상

Claudian Orchestra의 전체 구성. 왼쪽 = Obsidian Workspace (Vault: MY_MEMORY), 중앙 = Claudian Orchestra (Claude Code Orchestra + Hermes 2계통), 오른쪽 = External Sources

위의 사항들을 (적어도 현재는) 충족하는 Claudian Orchestra의 설계는 크게 3개 층으로 구성됩니다.

층	내용	역할
Obsidian Workspace	Markdown 노트의 Vault (Daily / Inbox / 프로젝트 / Maps 등)	지식과 작업의 "기재 (substrate)". 인간이 읽고 쓰는 장소
Claudian Orchestra	Claude Code Orchestra와 Hermes 2계통 (Sonnet·Codex는 Claude Code Orchestra 내의 subagent)	Vault를 읽고 쓰며 정리하고, 외부와 연결함
External Sources	Slack / Calendar / Tasks / Notion / Web / 회의록 / GitHub	1차 정보의 발생원. 여기서 정보를 가져옴

결국 숙제에 대한 해답인 인터페이스는 Obsidian이며, 그 본질은 구조화/공유된 Markdown 군이었습니다. 저는 Obsidian을 열어 노트를 읽고 쓰며, AI 에이전트들도 동일한 노트를 읽고 씁니다.

4.2 왜 Obsidian인가

이것은 §2.2의 OKF에서 다룬 「Just markdown」을 그대로 계승한 형태입니다. 요구사항에 따라 저의 메모리는 Markdown으로 관리합니다. 관리 대상이 Markdown이 되었을 때 어떤 IDE를 사용할지 검토하게 되는데, 저는 Obsidian을 선택했습니다.

정석적인 VS Code나 가볍고 빠른 Zed, Notion 등도 메인 UI로 검토했지만, VS Code와 같은 터미널 (Terminal) 조작이나 확장 기능, 매끄러운 git 연동 기능을 갖추면서도, Notion처럼 프론트매터 (frontmatter)를 포함한 기분 좋은 Markdown 편집 경험을 제공할 수 있는 것은 Obsidian이었습니다.

또한 이 Obsidian의 볼트 (Vault, 편집 대상 폴더)로 Google Drive를 사용하고 있습니다.

여러 PC에서 동일한 PKB를 사용하기 위해, Obsidian 공식에서 Obsidian sync라는 기능을 제공하고 있습니다. 다만 이는 월간 유료 결제 방식이라는 점을 고려하여 제외하고, 동일한 작업을 수행할 수 있는 Google Drive를 로컬에 마운트하여 그곳을 볼트 (Vault)로 사용하는 운영 방식을 취하고 있습니다. (참고로 Obsidian 공식 문서 (docs)를 읽어보면, 이러한 서드파티 드라이브를 볼트로 사용하는 것도 고려되어 있는 듯합니다.)

또한 Obsidian은 VS Code처럼 확장 기능을 설치함으로써 많은 것을 할 수 있게 됩니다. 커뮤니티 플러그인 (Community plugin)이라고 하여, 비공식적으로 많은 플러그인이 제작되어 있으며, 터미널 (Terminal)을 사용할 수 있게 해주는 플러그인이나 Markdown 이외의 파일을 사용할 수 있게 해주는 플러그인 등이 게시되어 있습니다. 업데이트도 활발하여 안심하고 사용할 수 있다고 생각합니다.

결과적으로 저의 Obsidian 화면은 Markdown 편집에 특화된 거의 VS Code에 가까운 모습이 되었습니다.

4.3 Claudian Orchestra: 4개 에이전트의 역할 분담

저는 Claude Code를 오케스트레이터 (Orchestrator)로 사용하고, 다른 CLI 에이전트 (CLI Agent)들을 조합하여 사용하는 프레임워크인 「Claude Code Orchestra」를 과거에 제안한 바 있습니다. Claude Code Orchestra는 어디까지나 코딩용으로 스킬 (skills) 등을 만들어 둔 것이지만, 개인적으로 이 경험이 매우 마음에 들어서, MY_MEMORY에서도 Claude Code Orchestra를 기반으로 한 CLI 에이전트 (CLI Agent)를 사용하고 싶었습니다.

아무런 고민 없이 그대로 Claude Code Orchestra를 도입할 수도 있지만 (앞서 언급했듯이 터미널 (Terminal)이 있으므로), 사실 Obsidian의 터미널 (Terminal)은 버그가 많아서 말이죠 (레이아웃 깨짐 등)...\n그래서 Obsidian의 플러그인인 Claudian을 사용하기로 했습니다.

VS Code에도 Claude Code를 CLI가 아닌 콘솔 (Console) 같은 곳에서 사용하기 위한 확장 기능이 있는데, 그것의 Obsidian 버전이라고 할 수 있습니다. (이전 항목의 스크린샷 화면 오른쪽 상단에 보이는 부분입니다.)

Claudian은 상당히 우수한 플러그인으로, Claude Code 외에도 Codex나 OpenCode를 백엔드 (Backend)로 사용할 수 있으며, 그 전환도 용이합니다. 또한 여러 가지 세부 설정이 가능하여, CLAUDE.md와는 별개로 커스텀 프롬프트 (Custom prompt)를 설정할 수 있거나, Markdown의 프론트매터 (frontmatter)를 표식으로 삼아 .claude 안에 있더라도 특정 파일을 읽지 않도록 설정하는 등의 작업이 가능합니다.

자, 이제 이 Claudian을 사용하여 Claude Code Orchestra, 즉 Claudian Orchestra를 설계합니다.

당연히 메인 오케스트레이터 (Orchestrator)는 Claude Code (Opus 4.8 1M)입니다. 서브 에이전트 (subagent)로서 Sonnet (1M), 그리고 Codex (gpt-5.5)를 세팅했습니다. 장문이나 이미지, PDF, Office 파일 등의 읽기에는 Sonnet을, 리뷰가 필요할 때나 gpt-image를 사용하여 이미지를 생성할 때는 Codex를 사용하는 식으로 구분했습니다.

또한 Claude Code Orchestra와의 큰 차이점은, Claude Code와는 독립된 또 다른 계통의 에이전트로서 Hermes Agent를 통합했다는 점입니다 (Claude로부터 hermes-query로 "호출"할 수는 있지만, 하위의 서브 에이전트 (subagent)는 아닙니다).

Hermes Agent는 OpenClaw와 매우 유사한 소위 Claw Agent(상주형 Agent)입니다. 코어 모델은 gpt-5.4-mini입니다. 이번에는 외부와의 모든 연결을 담당하게 됩니다. Slack, GitHub, Calendar 등 오자키(Ozaki)가 작업에 사용하는 거의 모든 외부 소스에서 정보를 가져옵니다. 외부와의 연결이 전제로 설계된 부분도 있어, Hermes는 그 부분의 설정이 간편했습니다(정확히 말하면 말하자마자 바로 해주었습니다). 또한 이를 즉시 cron 작업으로 전환할 수 있다는 점도 Claw Agent의 장점입니다.

Hermes 자체에 대한 자세한 해설은 별도의 기사에 정리되어 있습니다.

최상위 레벨에서는 Claude Code Orchestra와 Hermes의 두 계통이 있지만, 역할을 나누면 다음 4가지가 됩니다.

에이전트	역할	비유
Claude Code	오케스트레이터 (Orchestrator). 대화·우선순위 지정·Vault 내부 정리·큐레이션 (curate)	지휘자
Sonnet	Claude Code 하위의 서브 에이전트 (subagent). 장문·이미지·PDF·Office 파일 읽기 담당	독자·자료 담당
Hermes	모든 외부 연결을 전담하며, Slack/Calendar/Tasks/Web/GitHub 등에서 로우 데이터 (raw data)를 가져옴 (capture 전담)	대외 협력·물류
Codex	설계·계획·복잡한 구현·디버깅 위임 대상 (Claude Code로부터 상담 받음)	전문 기술자

설계의 핵심은 "누가 어떤 인증(연결)을 갖는가"를 일원화한 것입니다. 외부 API의 토큰은 모두 Hermes가 보유하며, Claude Code는 외부를 직접 호출하지 않습니다. 코드의 무거운 작업은 Codex에게 던집니다. Claude Code 자신은 "대화"와 "Vault의 정리"에 집중합니다. 지난번 스펙트럼(Spectrum)에서 사용한 표현을 빌리자면, 연결·수집은 자동화에 가깝고, 지식의 증류·배분은 인간의 승인을 거치는 식의 농담(濃淡)을 역할로 표현한 것입니다.

5. 외부 소스 설계

앞서 언급한 바와 같이, 외부 소스로서 어떤 곳을 가져올지는 Hermes와 함께 디자인해 두어야 합니다. 이번에 외부 소스로 설정한 것은 다음과 같습니다.

• Slack

• 이는 Hermes Agent가 UI로서 전제로 설정되어 있기 때문에 연결이 쉽습니다. 자신의 User Token을 전달해 두면, 그날 자신이 관련된 대화를 모두 가져올 수 있습니다.

• 또한 Slack 연동 시에는, 필요 최소한의 스코프 (scope)로 제한한 토큰을 준비하여 로컬 환경 변수나 시크릿 관리 도구로 보관하고 있습니다. 실제 운용 시에는 토큰의 권한, 보관 장소, 로테이션 방침을 사전에 확인하십시오.

• Other Files

• 이는 업무나 연구와 관련되지만 본인으로부터 유래하지 않은 자료입니다. 현재는 오자키가 Vault 안에 그때마다 직접 넣고 있습니다.

• Google Calendar / Tasks

• 앞서 언급한 기사와 같이, 스마트폰이나 워치·이어폰을 통해 Gemini를 경유하여 조작하며, 적절히 세부적인 태스크나 일정을 입력하고 있습니다.

• 이를 GWS CLI를 사용하여 가져오는 스킬 (skills)을 Hermes에게 부여했습니다. 하나의 계정의 GCP 프로젝트에 여러 계정을 초대하여, 업무와 연구 각각의 일정과 태스크를 혼합하여 관리하고 있습니다.

• Notion

• Notion MCP로 연결하고 있습니다.

• Web

• 주로 ChatGPT나 Claude의 웹 버전에서 수행한 브레인스토밍(wall-hitting)이나 간단한 조사를 클릭 한 번으로 가져오는 Chrome 확장 프로그램을 만들고 있습니다.

• 베이스는 Obsidian-AI-exporter이며, 그대로 사용하면 모델이 도구 호출 (Tool Call)을 한 시점에서 가져오기가 중단되는 버그가 있어, 이를 첨부 파일이나 Deep Research 결과도 가져올 수 있도록 개인적으로 수정한 것을 사용하고 있습니다. 완성된 dist 폴더를 Chrome에 넣으면 다음과 같습니다.

• 

• 여기서 버튼을 누르면, 가져온 내용이 Obsidian의 지정된 폴더에 저장됩니다.

• Genspark

• 회의록에는 Genspark의 AI 회기록을 사용하고 있습니다. 화자 분리도 해주고 전사(transcription) 정확도도 높으며, gsk CLI를 통해 터미널(Terminal)에서도 사용할 수 있어 Obsidian과의 연결도 쉽습니다.

• GitHub

• GitHub MCP로 연결하고 있습니다.

• 코드 자체는 이 Vault로 가져오지 않고, 리포지토리(repository)만 매핑해 두어 그날의 작업 분량을 이해하는 데 사용합니다.

6. 정보의 흐름: capture → Daily 허브 → Main DB

에이전트가 여러 명이라도, 모두가 제멋대로 기록하면 시스템은 붕괴합니다. Claudian Orchestra는 정보의 흐름을 3단계로 나누어, 작성자를 시점별로 한 명으로 제한하고 있습니다. LLM wiki에서도 외부에서 가져온 정보인 "raw"와 정리하는 장소인 "wiki"를 완전히 분리했다는 점이 핵심이었습니다.

6.1 단일 허브로서의 Daily 노트

[외부 소스]
│ ① capture (Hermes가 자동 가져오기)
▼
...

매일 작성하는 한 장의 Daily 노트가 아침의 briefing → 낮 시간의 작업 로그 → 밤의 회고에 이르기까지 관통하는 허브 역할을 합니다. 가공되지 않은 로그를 곧바로 정리용 폴더에 넣지 않고, 반드시 Inbox를 거쳐 Daily로 가져온 뒤, 사람이 Daily 상에서 확인 및 정리하여 내구성이 있는(durable) 지식만을 각 wiki 폴더로 **승격(promotion)**시킵니다 (이 승격은 Claude가 증류(distill) 안을 제시하고 사람이 승인하는 반자동 플로우, 즉 후술할 eod-distill 방식으로 진행되며, 완전 자동은 아닙니다).

Daily 노트의 아침 briefing 예시. 오늘과 내일의 예정, Google Tasks, Genspark 회의록 리마인더가 자동으로 나열됩니다. Google Calendar나 Tasks에서 가져온 정보입니다.

낮 동안에는 자신이 담당하는 프로젝트(PJT)별로 어떤 작업을 했는지 기록해 나갑니다. 진척이 없는 날은 기록이 남지 않습니다.

업무 외의 연구나 기타 자기 계발, 소규모 태스크(task)도 기록됩니다. 이날은 학회 위원 업무나 테크 블로그 집필을 진행한 것으로 보입니다. 그 외에 이 Claudian Orchestra의 운용 방침 변경에 관한 작업도 수행한 듯합니다.

밤의 회고에서는 그날 완료되지 않은 태스크나 다음으로 미뤄진 예정 태스크가 기록됩니다. 또한 그날 Daily에 모인 내용 중 중요한 것을 Main DB (Wiki)로 배분하고, 이동할 곳의 링크를 남깁니다. 배분할 때는 사람이 승인하도록 되어 있습니다.

6.2 정본(System of Record)의 소재와 PKB에서의 중요한 규율

PKB(Personal Knowledge Base)에서의 중요한 규율 중 하나로 "정본(system of record)이 어디인가"를 추적하는 것을 꼽을 수 있습니다. 앞서 언급했듯이, 사용자는 다양한 외부 소스를 통해 작업을 수행합니다. 어떤 것이 어디에서 왔는지, 어떤 것이 먼저 만들어진 것인지를 정리해 둘 필요가 있습니다.

여기서 말하는 "정본"은 정보가 처음 생성되어 지속적으로 업데이트되는 원천—GitHub의 해당 파일, Slack의 스레드, Google Calendar의 이벤트 등—을 가리킵니다. 뒤집어 말하면, Inbox/에 가져온 가공되지 않은 데이터(md)조차 그 대부분은 외부에 있는 정본의 "복사본"에 불과합니다 (예외적으로 ChatGPT/Claude와의 대화 로그처럼 외부에 원본이 남지 않는 경우는 Vault 측의 생로그가 정본이 됩니다).

Vault 내 노트의 대부분은 "외부 정본을 증류한 복사본"입니다. 그렇기 때문에 "이 노트의 원천(정본)은 어디인가"를 놓치지 않는 것이 중요하며, 여기서 §2.2의 OKF resource 필드가 제 역할을 합니다. resource: "https://github.com/.../pipeline.py"와 같이 정본에 대한 포인터를 프런트매터(frontmatter)에 보유하면, "정본의 소재"를 **횡단 쿼리(cross-query)**할 수 있게 됩니다 (포인터는 외부 URL 외에도 Vault 상대 경로 또는 SoR 식별자로 표현할 수 있습니다).

또한 생성 및 업데이트의 타임레인지(시계열)는 git이 추적할 수 있으므로, 프런트매터의 필수 항목으로는 설정하지 않았습니다.