오늘은 그 첫 시간으로, 서문과 제1장 “The Memory of a Goldfish(금붕어의 기억력)”를 다룹니다.

원문에서는 우리가 매일 겪는 고통을 이렇게 꼬집으며 시작합니다.

“You are paying twenty bucks a month for an AI with the memory of a goldfish.”
(우리는 금붕어 수준의 기억력을 가진 AI에 매달 20달러를 내고 있습니다.)

저스틴) 기억력을 갖도록 하는 방법을 마련하는 것은 너무 당연한 것인데, 그렇지 않고 이렇게 말하면 큰 오해가 생깁니다.

---

STAGE 1 — Why It Matters: 왜 이 문제가 심각할까요?

여러분이 매달 월급을 줘서 최고 스펙의 비서를 한 명 고용했다고 상상해 보세요.

일처리는 기가 막히게 잘합니다. 그런데 치명적인 문제가 있습니다. 매일 아침 출근하면 기억이 깨끗하게 리셋됩니다. 어제 우리가 어떤 데이터베이스를 쓰기로 합의했는지, 지난주에 클라이언트와 어떤 범위까지 일하기로 조율했는지 전혀 모릅니다.

그래서 매일 아침 출근하자마자 첫 40분 동안 “우리 회사는 이런 곳이고, 어제 우리가 여길 고쳤고…” 하면서 똑같은 배경 설명을 반복해야 합니다.

이게 바로 지금 우리가 클로드(Claude)나 챗GPT를 쓸 때 겪는 일입니다. 세션이 새로 열릴 때마다 대화는 0에서 다시 시작합니다.

책의 저자가 계산한 수치를 볼까요?

• 하루에 두 번, 맥락 설명에 45분씩 낭비한다고 치면 일주일에 약 7.5시간입니다.
• 1년이면 약 390시간에 달합니다.
• 시급 4~6만 원으로 계산하면, 1년에 최소 1,500만 원에서 2,300만 원 상당의 시간 비용을 허공에 날리고 있는 셈입니다.

저스틴) 일이 연속적이어야 한다면, 연속된 일처리로 진행해야 하는 것은 너무 당연한 것 아닌가요?

---

STAGE 2 — Unpacking the Core Concept: 세컨드 브레인의 실체

유튜브나 인터넷을 보면 ‘세컨드 브레인’이라는 거창한 말이 넘쳐납니다. 하지만 본질을 쪼개보면 놀라울 정도로 단순합니다.

세컨드 브레인 = 5개의 마크다운 폴더(서류함) + 똑똑한 전담 비서(Claude Code)

비유를 하나 들어볼게요. 집에 서류함이 하나 있습니다. 그 서류함 안에는 여러분의 업무 규칙, 현재 진행 중인 프로젝트, 사람들과 나눈 미팅 메모가 들어 있습니다. 그리고 여러분 옆에는 ‘클로드 코드(Claude Code)’라는 비서가 서 있습니다.

터미널에서 claude를 실행하는 순간, 이 비서는 여러분이 아무 말도 하지 않았는데 먼저 서류함을 열어봅니다.

• “아, 지금 사장님이 exports-api 버그 수정 프로젝트를 하고 계시구나.”
• “지난주 화요일에 캐싱 방식 대신 조인 레이어를 고치기로 결정하셨네.”

이걸 비서가 1초 만에 스스로 읽고 자리에 앉습니다. 여러분이 “어제 하던 작업 이어서 하자”라고 한마디만 던져도, 비서는 이미 모든 맥락을 알고 정답을 내놓습니다.

더 이상 복사-붙여넣기를 할 필요가 없습니다. 노션(Notion) 창을 열었다 닫았다 할 필요도 없습니다.

구분	기존 방식 (노트 복사-붙여넣기)	AI 세컨드 브레인 (Claude + Obsidian)
시작 단계	지난 작업 배경을 장문으로 타이핑	터미널 실행 즉시 프로젝트 맥락 자동 로드
기억 저장소	흩어진 노션, 슬랙 DM, 기억에 의존	로컬 마크다운 파일(Obsidian 5대 폴더)
작업 종료	대화창 닫으면 맥락 소멸	세션 종료 시 결정 사항이 일지(daily/)에 자동 기록
시간 소모	아침마다 30~45분 소모	0분 (커피 마시며 바로 본론 시작)

---

저스틴) 노션, 슬랙과 같은 여러 도구를 사용하지 말고, 하나의 도구만 사용할 수 있도록 해야 합니다. My AI Smarteasy라는 강력한 무기를 사용하면 됩니다. 레이저 총이 있는데 M1, M16, K1, K2, … 를 사용할 필요 없습니다.

STAGE 3 — Evidence and Application: 실제 토요일 아침의 두 가지 풍경

책에서는 같은 프로젝트를 진행하는 두 사람의 토요일 아침을 대조해서 보여줍니다.

A의 토요일 아침: 오전 9시, 터미널을 엽니다. API 오류를 고치려고 합니다. 프롬프트를 치다가 멈춥니다. “그 파일 경로가 뭐였더라?” 에디터로 가서 경로를 복사해 옵니다. “이 함수가 뭘 리턴해야 하더라?” 배경 설명을 칩니다. 클로드가 엉뚱한 대답을 합니다. 왜냐하면 2주 전에 비슷한 버그를 딴 데서 고쳤다는 사실을 모르기 때문입니다. 맥락을 다시 설명합니다. 시계를 보니 9시 45분이고, 커피는 식었고, 코드는 한 줄도 못 짰습니다.

B의 토요일 아침: 오전 9시, 옵시디언 볼트 폴더 안에서 claude를 켭니다. 세션이 시작되자마자 자동화 장치(SessionStart Hook)가 작동합니다. 현재 활성 프로젝트 파일(projects/exports-api.md)과 볼트 규칙(CLAUDE.md)을 클로드의 머릿속에 즉시 집어넣습니다. 질문 한 줄을 던집니다. 클로드는 2주 전의 결정 사항과 코드 경로를 이미 알고 핵심만 답변합니다. 9시 25분에 해결책을 확인하고, 10시 30분에 테스트를 끝낸 뒤 다음 작업으로 넘어갑니다.

이 차이를 만드는 건 거창한 기술이 아닙니다.

1. 5개의 정돈된 폴더 구조
2. AI가 무시하지 않는 지침서 (CLAUDE.md)
3. 상황마다 자동으로 작동하는 5개의 연결고리 (Hooks)
4. 반복 작업을 한 단어로 줄여주는 명령어 (Skills)

이것뿐입니다. 이론서처럼 수백 페이지를 공부할 필요가 없습니다. 딱 이번 주말 동안 하나씩 조립하면 끝납니다.

---

STAGE 4 — Summary and Extension: 요약과 앞으로의 여정

오늘 나눈 이야기의 핵심을 정리해 볼까요?

1. 문제의 본질: AI의 성능 부족이 아니라, 매 세션마다 맥락이 끊기는 ‘금붕어 기억력’이 진짜 병목입니다.
2. 해결책의 본질: 복잡한 도구가 아니라, 내 컴퓨터 안의 텍스트 파일(Obsidian)을 Claude Code가 스스로 읽고 쓰게 만드는 루프를 닫는 것입니다.
3. 우리의 목표: 매일 아침 내 비즈니스와 프로젝트를 AI에게 재설명하는 일을 완전히 끝내는 것입니다.

---

[이해도 자가 진단 질문]

강의를 마무리하기 전에, 스스로 다음 두 질문에 답해 보세요.

1. 여러분이 최근 AI를 쓰면서 “아, 이거 지난번에 다 말했던 건데…” 하고 답답했던 순간은 구체적으로 어떤 작업이었나요?
2. 왜 노션에서 매번 글을 긁어다 붙이는 방식이 장기적으로 실패할 수밖에 없을까요?

---

 

[제2강] 왜 당신의 노트는 잡동사니 서랍이 되는가? (Why Your Vault Becomes a Junk Drawer)

지난 1강에서 우리는 매일 아침 기억을 잃어버리는 ‘금붕어 비서’에게 지치지 않으려면 내 컴퓨터 안에 명확한 작업 서류함(Obsidian Vault)을 둬야 한다는 것을 배웠습니다.

그런데 여기서 아주 흔하고 치명적인 실수가 벌어집니다. 의욕에 넘쳐 노트를 몇백 개, 몇천 개 모아두었는데, 어느 순간 AI가 엉뚱한 답변을 내놓기 시작합니다. 내가 직접 찾으려고 검색창을 쳐도 관련 없는 대화 기록만 30개씩 쏟아져 나와 결국 포기하고 맙니다.

책 2장에서는 레딧(Reddit)의 한 유저(@tensorfish)가 남겨 큰 공감을 얻었던 한 문장을 소개합니다.

“Otherwise Obsidian just becomes a very organised junk drawer.”
(그렇지 않으면 옵시디언은 그저 매우 잘 정돈된 잡동사니 서랍이 될 뿐입니다.)

오늘 강의에서는 여러분의 볼트(Vault, 보관소)가 왜 ‘잡동사니 서랍’이 되어버리는지, 그리고 AI가 단 1초 만에 정확한 문서를 찾게 만드는 ‘5대 폴더 스키마’의 비밀을 파헤쳐 보겠습니다.

---

STAGE 1 — Why It Matters: 태그(Tag)는 왜 AI를 똑똑하게 만들지 못할까요?

노트 앱을 쓸 때 우리가 가장 먼저 하는 행동이 무엇인가요? 바로 #태그를 다는 겁니다. #아이디어, #회의록, #프로젝트A, #중요.

처음에는 그럴듯해 보입니다. 옵시디언의 ‘그래프 뷰(Graph View)’를 켜면 은하수처럼 반짝이며 노드들이 연결되니 뭔가 대단한 지식 네트워크를 구축한 것 같은 착각이 듭니다.

하지만 비유를 하나 들어볼게요. 여러분이 택배 기사(AI)에게 배송을 부탁한다고 생각해 보세요.

• 방식 A (태그): 택배 상자에 #서울 #강남 #아파트 #급함 #선물이라는 알록달록한 스티커(태그)가 5개 붙어 있습니다. 하지만 정확한 동·호수 주소는 없습니다.
• 방식 B (폴더 경로): 상자에 서울특별시/강남구/역삼동/101동/502호라는 명확한 경로(Path)가 적혀 있습니다.

어느 쪽이 배송하기 쉬울까요? 당연히 B입니다.

AI 모델(Claude)이 폴더를 열어볼 때 가장 먼저 읽는 최우선 맥락 신호는 파일의 경로(Path)입니다. 루트 폴더에 뒹굴면서 #api #export #project 태그가 덕지덕지 붙은 파일은 AI에게 모호합니다. 태그들 사이에 어떤 상하 관계나 문맥이 있는지 AI가 추측(Guess)해야 하기 때문입니다.

반면, projects/exports-api/decisions.md라는 경로에 놓인 파일은 읽는 순간 100% 명확합니다. “아, 이건 exports-api 프로젝트의 의사결정 문서구나!”

AI에게 추측을 시키는 순간 환각(오답)이 시작되고, 여러분은 AI를 불신하게 됩니다. 따라서 필요한 것은 ‘태그 규칙’이 아니라, 엄격한 ‘폴더 규칙’입니다.

---

STAGE 2 — Unpacking the Core Concept: 포스트잇 한 장에 들어가는 5대 폴더

책의 핵심 철학은 아주 단호합니다. “스키마가 먼저이고, 프롬프트는 그다음이다(Schema First, Prompts Second).”

폴더가 20개, 30개가 되면 사람의 뇌도 어디에 넣어야 할지 헷갈려서 시스템이 무너집니다. 무조건 단 5개의 최상위 폴더로만 끝내야 합니다. 포스트잇 한 장에 다 적을 수 있어야 지킬 수 있습니다.

폴더명	영문 이름 및 정렬	어떤 것이 들어가는가? (역할)	머무는 기간 (수명)
임시 보관함	_inbox/	빠르게 캡처한 날것의 아이디어, 슬랙 캡처, 분류 안 된 메모	최대 7일 (비워내야 함)
활성 프로젝트	projects/	지금 실제로 진행 중인 작업 (프로젝트당 하위 폴더 1개)	진행 중일 때만 유지
일일 저널	daily/	하루 단위의 기록 (YYYY-MM-DD.md), 회의 메모, 낙서장	영구 보관 (날짜순 누적)
사람/관계	people/	정기적으로 만나는 동료, 클라이언트, 팀원별 기록	관계가 이어지는 동안
보관소 (묘지)	_archive/	끝났거나 멈춘 프로젝트, 7일 지난 미분류 메모, 과거 기록	영구 보관 (검색용)

(참고: 폴더명 앞에 붙은 밑줄(_)은 옵시디언 파일 탐색기에서 알파벳 순서상 가장 위로 띄워 시선이 먼저 닿게 만들기 위한 영리한 장치입니다.)

규칙은 단순합니다:

1. 모든 메모는 반드시 이 5개 중 딱 1곳에만 들어간다.
2. _inbox/는 쌓아두는 곳이 아니라 매주 비워내는 배수구다.
3. projects/에 들어간 프로젝트 중 최근 2주 동안 한 번도 손대지 않은 것은 즉시 _archive/로 보낸다. (화면에 한눈에 들어오는 프로젝트만 ‘활성’ 상태입니다.)

이 규칙이 서류함의 질서를 유지해 줍니다. 

---

STAGE 3 — Evidence and Application: 자꾸만 만들고 싶어지는 ‘유혹의 폴더 3가지’

시스템을 쓰다 보면 한 달쯤 지나 반드시 악마의 속삭임이 찾아옵니다. “아, 이 5개로는 부족한데? 폴더 하나만 더 만들까?” 책에서는 사람들이 가장 많이 빠지는 3가지 유혹의 덫을 정확히 지적합니다.

1. 유혹 1: references/ (자료/참고자료 폴더)

   • 마음의 소리: “읽을거리나 PDF, 웹 문서 스크랩을 모아둘 폴더가 필요해!”
   • 진실: 여기에 들어간 문서는 1년에 한 번 열어볼까 말까 한 쓰레기통이 됩니다.
   • 해결책: 지금 진행 중인 프로젝트에 필요한 자료라면 그 프로젝트 폴더 내부(projects/프로젝트명/refs/)에 넣으세요. 프로젝트와 상관없는 일반 자료라면 그냥 _archive/refs/로 보내세요.

2. 유혹 2: templates/ (서식 템플릿 폴더)

   • 마음의 소리: “회의록 양식, 일일 노트 양식을 보관할 폴더가 있어야지.”
   • 진실: 템플릿은 문서 콘텐츠가 아니라 ‘도구(설정)’입니다.
   • 해결책: 나중에 배울 Claude 명령어 파일(skills) 내부에 프롬프트로 심어두거나, 굳이 필요하다면 _archive/templates/에 조용히 넣어두세요. 최상위 폴더를 어지럽히지 마세요.

3. 유혹 3: someday/ 또는 ideas/ (언젠가 할 일 / 아이디어 폴더)

   • 마음의 소리: “언젠가 써먹을 기막힌 아이디어를 따로 모아야 해!”
   • 진실: 반쯤 익은 아이디어들의 무덤이 될 뿐이며, 다시는 들여다보지 않습니다.
   • 해결책: 일단 _inbox/에 던져두세요. 매주 금요일 정리할 때 진짜 실행할 마음이 들면 projects/로 승격시키고, 아니면 _archive/로 보내서 잊어버리세요. (어차피 검색하면 다 나옵니다.)

폴더가 6개가 되는 순간, 여러분의 뇌는 새로운 메모를 적을 때마다 “이걸 인박스에 넣어야 하나, 자료 폴더에 넣어야 하나?” 고민하기 시작하고, 그 고민의 마찰력 때문에 결국 시스템을 버리게 됩니다. 무조건 5개로 틀어막으세요.

---

STAGE 4 — Summary and Extension: 실전 분류 연습 (Action Step)

오늘 배운 내용을 몸으로 익혀보는 가장 좋은 방법은, 여러분이 지금 컴퓨터나 스마트폰 메모장에 아무렇게나 적어둔 메모 15개를 꺼내 종이에 분류해 보는 것입니다.

예를 들어볼까요?

• “동료 지수 님이 슬랙으로 공유해 준 3분기 기획안 링크” 👉 _inbox/ (아직 읽고 처리하지 않았으므로)
• “2026-04-19 민수 팀장과의 가격 정책 논의 미팅” 👉 daily/ (날짜 기반 일일 노트에 기록하고, 팀장 프로필 people/minsu/에서 연결)
• “새로운 블로그 글 작성 아이디어” 👉 _inbox/ (주간 정리 때 진짜 쓸 거면 projects/blog/로 이동, 아니면 _archive/)

---

[이해도 자가 진단 질문]

다음 상황에서 메모가 들어갈 올바른 폴더는 어디일까요?

1. 3주 전에 야심 차게 시작했지만, 급한 회사 일 때문에 최근 2주 동안 전혀 손대지 못하고 멈춰 있는 ‘유튜브 채널 개설’ 프로젝트 폴더는 어디로 옮겨야 할까요?
2. 웹서핑을 하다가 너무 좋은 개발 팁 글을 발견해서 복사했습니다. 당장 어떤 프로젝트에 쓸지는 모르겠습니다. 어디에 넣어야 할까요?

---

 

[제3강] 카파시의 비법 (Karpathy’s Trick)

지난 2강에서 우리는 모호한 태그 대신 파일 경로가 명확한 ‘5대 폴더 스키마’를 세워야 한다는 규칙을 배웠습니다. 뼈대를 어떻게 잡아야 하는지 감을 잡으셨을 겁니다.

그런데 최근 한 달 사이에 유튜브와 테크 커뮤니티에서 이 방식의 조회수가 무려 90만 회에 육박하며 폭발적인 열풍을 일으켰습니다. 그 진원지는 바로 전(前) 테슬라 AI 총괄이자 OpenAI의 창립 멤버인 안드레이 카파시(Andrej Karpathy)가 올린 단 한 장짜리 깃허브 문서(llm-wiki.md)였습니다.

카파시는 그 글의 말미에 이런 문장을 남겼습니다.

“share it with your LLM agent and work together to instantiate a version”
(LLM 에이전트와 공유하고 함께 협력하여 필요에 맞는 버전을 구현해 보세요.)

이 짧은 문장은 전 세계 개발자들에게 “아, AI의 기억력 문제는 이렇게 푸는 거구나!”라는 거대한 영감을 주었습니다. 하지만 동시에 치명적인 숙제도 던졌습니다. 원리는 알겠는데, 당장 내 컴퓨터에 어떻게 설치하고 실행해야 하는지 구체적인 사용 설명서가 빠져 있었던 것이죠.

오늘 강의에서는 카파시가 공개한 비법의 진짜 알맹이가 무엇인지, 그리고 우리가 이번 주말에 완성할 시스템과 어떻게 맞물리는지 명쾌하게 짚어드리겠습니다.

---

STAGE 1 — Why It Matters: 왜 지금 모든 크리에이터가 여기에 열광할까요?

왜 갑자기 지난달에 이 열풍이 불었을까요? 세 가지 신호가 정확히 한 지점에서 만났기 때문입니다.

1. 카파시라는 이름의 무게감: 세계 최고 수준의 AI 연구자가 자신이 직접 쓰는 비밀 작업 방식을 공개했습니다.
2. 클로드 코드의 기능 출시: 마침 Claude Code에 특정 시점마다 자동으로 스크립트를 실행해 주는 ‘생명주기 훅(Lifecycle Hooks)’ 기능이 새로 추가되었습니다.
3. 사용자들의 누적된 분노: 1강에서 다뤘던 ‘금붕어 기억력’ 때문에 지친 수많은 사용자가 마침내 탈출구를 찾고 있었습니다.

카파시가 칠판에 멋진 설계도를 쓱쓱 그려 보여주자마자, 전 세계 사람들이 환호성을 지른 겁니다. 

---

STAGE 2 — Unpacking the Core Concept: 3개 층(Layers)과 3대 작업(Operations)

카파시가 제시한 핵심은 군더더기를 싹 빼면 딱 두 덩어리입니다. 바로 3개의 층(Layers)과 3개의 작업(Operations)입니다.

거대한 전문 연구 도서관을 하나 상상해 보세요.

1. 원본층 (Raw): 도서관 지하의 수장고입니다. 원본 PDF, 회의 녹취록, 고객의 이메일 원문이 보관됩니다. 이 자료는 절대로 수정하지 않는 ‘불변(Immutable)’의 진실입니다.
2. 지식층 (Wiki): 사서(AI)가 상주하는 열람실입니다. 사서는 수장고의 원본을 읽고, 핵심만 요약하고, 지난 결정 사항을 정리하여 깨끗한 마크다운 문서로 만들어 둡니다. AI가 주로 일하고 업데이트하는 구역입니다.
3. 규칙층 (Schema): 사서의 책상 위에 붙어 있는 ‘업무 매뉴얼’입니다. “새 책이 오면 어떻게 요약할 것인가?”, “어떤 폴더에 꽂아둘 것인가?”를 정의한 CLAUDE.md 파일이 바로 여기에 해당합니다.

그리고 이 도서관에서 사서가 수행하는 일은 딱 3가지입니다.

작업명 (Operation)	일상적 의미	AI 비서가 실제로 하는 일
수집 (Ingest)	새 자료 입고	새로운 아티클이나 회의록을 읽고, 요약본을 만들어 기존 지식과 연결(Link)함
질의 (Query)	도서 검색 및 열람	“내가 지난 분기에 가격 책정에 대해 뭐라고 결정했지?”라고 물으면 위키를 뒤져 근거와 함께 답변함
정돈 (Lint)	서가 청소 및 점검	주기적으로 위키를 돌며 깨진 링크를 고치고, 길어진 문서를 쪼개고, 낡은 문서를 정리함

여기에 카파시는 전체 지식의 목차 역할을 하는 index.md와, 언제 무엇이 들어왔는지 기록하는 출납 일지 log.md를 두자고 제안했습니다.

어떤가요? 복잡한 AI 기술이 아니라, 아주 오래되고 검증된 도서관 관리 시스템과 똑같지 않나요?

---

STAGE 3 — Evidence and Application: 유튜브의 3개 진영과 이 책의 해답

유튜브에 올라온 수많은 영상들을 살펴보면, 카파시의 아이디어를 구현하는 방식이 세 갈래로 나뉩니다. 이 지도를 미리 알고 있어야 쓸데없는 방황을 하지 않습니다.

1. 마크다운 순수주의파 (Camp 1):
   오직 텍스트 파일과 터미널만 씁니다. 가장 가볍고 튼튼하지만, 초보자가 보기엔 화면이 너무 삭막하고 완성도가 떨어져 보입니다.
2. 옵시디언 플러그인 중독파 (Camp 2):
   Dataview, Templater, Copilot 등 화려한 플러그인을 수십 개 설치합니다. 화면은 화려하지만, 옵시디언이 판올림될 때마다 플러그인이 충돌을 일으키며 전체 시스템이 멈춥니다.
3. 풀스택 도구 조립파 (Camp 3):
   벡터 데이터베이스, 로컬 모델(Ollama), 음성 변환 파이프라인까지 설치합니다. 세팅하는 데만 꼬박 이틀이 걸리고, 정작 지식 정리는 시작도 못 한 채 지쳐버립니다.

우리가 취할 전략은 명확합니다.
기본 뼈대는 캠프 1(단순하고 단단한 마크다운)로 시작합니다. 여기에 꼭 필요한 자동화 양념만 살짝 얹는 겁니다.

그리고 카파시가 남겨둔 빈칸을 우리는 이렇게 채웁니다:

• 카파시는 “도메인에 맞게 알아서 만드세요”라고 했지만, 우리는 [제2장의 5대 폴더 스키마]로 확정합니다.
• 카파시는 추상적인 규칙만 말했지만, 우리는 [제5장의 100줄짜리 CLAUDE.md]로 구체화합니다.
• 카파시는 수동으로 시켰지만, 우리는 [제6장의 5가지 자동 실행 훅(Hooks)]으로 세션이 열리고 닫힐 때 알아서 돌아가게 만듭니다.

한 가지 솔직한 주의점: 파일 형식의 한계
“카파시 방식은 PDF나 음성 파일, 이미지도 알아서 척척 읽어주나요?”라는 질문에 대한 정직한 대답은 “아닙니다”입니다.
AI는 순수한 텍스트(마크다운)를 읽을 때 가장 빠르고 똑똑합니다. 따라서 긴 PDF는 텍스트 추출 도구로 변환해서 넣고, 음성 메모(회의 녹음)는 위스퍼(Whisper) 같은 도구로 텍스트로 풀어낸 뒤 _inbox/에 던져 넣어야 합니다. 원본은 수장고(Raw)에 두고, 텍스트 요약본만 열람실(Wiki)에 올리는 원칙을 기억하세요.

---

STAGE 4 — Summary and Extension: 요약과 우리가 가질 멘탈 모델

앞으로 여러분이 이 책을 읽고 실습하면서 머릿속에 품어야 할 단 하나의 그림은 이것입니다.

내 노트북 폴더(Obsidian)가 유일한 진실의 원천이다.
클로드는 그 폴더 안에서 태어나고, 일하고, 기록을 남기고 사라진다.
규칙(CLAUDE.md)이 길을 안내하고, 자동문(Hooks)이 적절한 타이밍에 문서를 꺼내주며, 특수 요원(Subagents)들이 주기적으로 서가를 청소한다.

이 구조만 갖춰지면 클로드는 더 이상 기억을 잃어버리는 금붕어가 아닙니다. 여러분의 모든 역사와 맥락을 꿰뚫고 있는 충직한 수석 사서가 됩니다.

---

[이해도 자가 진단 질문]

1. 카파시의 3계층 모델에서, 클라이언트와 주고받은 원본 계약서 PDF나 회의 녹음 파일은 ‘Raw, Wiki, Schema’ 중 어느 층에 속하며, 왜 AI가 이를 직접 수정하면 안 될까요?
2. 카파시가 말한 3대 작업 중, 주기적으로 지식 창고를 점검하며 깨진 연결고리를 잇고 오래된 문서를 정리하는 작업의 명칭은 무엇인가요?

---

 

[제4강] 한 번에 끝내는 5대 폴더 볼트 세팅 (Your 5-Folder Vault, In One Sitting)

안녕하세요! 여러분의 실전 튜터, 강사 저스틴(Justin)입니다.

지난 1~3강을 통해 우리는 왜 이 시스템이 필요한지, 그리고 어떤 설계도로 지어야 하는지 머릿속에 완벽하게 집을 지었습니다. 이제 이론은 끝났습니다. 오늘 강의에서는 직접 팔을 걷어붙이고 내 컴퓨터에 5대 폴더를 파고, 클로드 코드를 연결할 겁니다.

옵시디언을 처음 켜서 빈 화면을 마주하면 막막해집니다. 레딧의 r/ObsidianMD 게시판에도 이런 답답함을 토로하는 글이 올라왔습니다.

“Why is it so complicated to connect Claude to Obsidian on windows?!”
(윈도우에서 클로드와 옵시디언을 연결하는 건 왜 이렇게 복잡한가요?!)

수많은 사람들이 둘 사이에 무슨 거창하고 비밀스러운 ‘연동 플러그인’이나 특수 케이블이 필요하다고 생각합니다. 하지만 오늘 여러분이 깨닫게 될 가장 통쾌한 진실은 이것입니다. “연결 단계 따위는 애초에 없다. 그저 같은 폴더를 바라볼 뿐이다.”

지금부터 딱 60분 만에 끝내는 실전 구축 단계로 들어가 보겠습니다.

---

STAGE 1 — Why It Matters & 설치 함정 피하기

비유를 하나 들어볼까요? 여러분의 서재 한가운데에 커다란 나무 책상이 하나 놓여 있습니다.

• 책상 한쪽 의자에는 여러분이 앉아서 옵시디언(Obsidian)이라는 예쁜 모니터를 통해 문서를 읽고 씁니다.
• 책상 맞은편 의자에는 클로드 코드(Claude Code)라는 손 빠른 비서가 앉아서 터미널 창을 띄워두고 같은 문서를 읽고 고칩니다.

두 사람이 대화하기 위해 복잡한 전선이 필요한가요? 아닙니다. 책상 위에 놓인 종이(마크다운 파일)를 같이 보면 끝납니다. 옵시디언 볼트는 데이터베이스도 아니고 서버도 아닙니다. 그저 내 컴퓨터 안의 평범한 폴더(Directory)일 뿐입니다.

설치는 딱 두 가지만 하면 됩니다.

1. 옵시디언 설치:
   공식 홈페이지(obsidian.md)에서 본인 OS에 맞는 버전을 받아 설치합니다. 새 볼트를 만들 때 경로는 기억하기 쉽게 홈 디렉토리(예: ~/vault 또는 C:\Users\사용자명\vault)로 잡으세요.
2. 클로드 코드 설치:
   터미널을 열고 공식 명령어를 입력합니다.
   • macOS / Linux: curl -fsSL https://claude.ai/install.sh | bash
   • Windows (PowerShell): irm https://claude.ai/install.ps1 | iex

⚠️ 여기서 절대 빠지면 안 되는 3대 함정!

• 함정 1 (sudo의 저주): 혹시 npm으로 설치할 때 권한 에러가 난다고 sudo npm install -g ...를 치지 마세요! 파일 권한이 꼬여서 나중에 고치려면 반나절을 날립니다. 컬(curl) 설치 스크립트를 쓰는 것이 가장 안전합니다.
• 함정 2 (윈도우 유저의 실수): 윈도우 환경에서는 반드시 Git for Windows를 먼저 설치해야 합니다. 클로드가 백그라운드에서 Git 도구를 쓰기 때문입니다.
• 함정 3 (Node 버전): Node.js를 쓴다면 반드시 18 버전 이상이어야 합니다. 16 버전 이하에서는 설치 도중 외계어 같은 에러를 뿜으며 멈춥니다.

설치 후 터미널에 claude --version을 쳤을 때 버전 숫자가 보이면 준비 완료입니다. 이해가 되시나요?

---

STAGE 2 — Unpacking the Core Concept: 5대 뼈대와 폴더별 ‘헌법(README)’

이제 터미널에서 볼트 폴더로 이동합니다.

단 한 줄로 2장에서 배운 5대 폴더가 생겼습니다. 옵시디언 화면을 보면 마법처럼 5개 폴더가 짠 하고 나타날 겁니다.

하지만 폴더만 만들어서는 안 됩니다. 사람도 시간이 지나면 규칙을 까먹고, AI 비서는 폴더 이름만 봐서는 세부 규칙을 알 수 없습니다. 그래서 각 폴더마다 3~5줄짜리 짧은 README.md를 헌법처럼 심어둬야 합니다.

이 헌법 문서는 미래의 나, 그리고 세션을 시작할 클로드가 읽을 지침서입니다.

각 폴더에 위 요약된 내용의 README.md 파일을 메모장이나 옵시디언으로 만들어 넣어주세요. 이제 여러분의 서류함은 완벽한 규칙을 갖췄습니다.

---

STAGE 3 — Evidence and Application: 첫 스모크 테스트와 첫 프로젝트 생성

소방관들이 건물을 짓고 나면 불을 내지 않고 연기만 피워 화재경보기가 울리는지 확인하는 시험을 ‘스모크 테스트(Smoke Test)’라고 부릅니다. 우리도 비서와 서류함이 제대로 소통하는지 연기 한 모금을 피워봐야 합니다.

[검증 1: 스모크 테스트] 터미널에서 볼트 경로로 들어간 뒤 클로드를 실행합니다.

화면에 Claude 프롬프트가 뜨면, 다음 문장을 그대로 입력해 보세요.

“_inbox/test-vault-check.md 위치에 오늘 날짜와 ‘vault read/write loop verified’라는 한 줄이 적힌 마크다운 파일을 생성해 줘.”

엔터를 치고, 옵시디언 화면을 쳐다보세요. 새로고침 버튼을 누를 필요도 없습니다. 옵시디언의 _inbox/ 폴더 아래에 방금 요청한 파일이 실시간으로 툭 튀어나올 겁니다. 그 파일을 옵시디언에서 열어보세요. 클로드가 쓴 글자가 적혀 있나요? 축하합니다! 루프가 닫혔습니다. 여러분과 AI가 하나의 뇌를 공유하기 시작한 순간입니다.

[검증 2: 첫 번째 진짜 프로젝트 폴더 만들기] 테스트 파일 하나로 끝내면 오늘 밤에 다시 예전 습관으로 돌아갑니다. 지금 머릿속에 있는 진짜 내 일 하나를 서류함에 등록해 봅시다. 예를 들어 pricing-page-redesign(가격 페이지 개편)이라는 프로젝트가 있다면, 클로드 터미널에 이렇게 시키세요.

“projects/pricing-page-redesign/ 폴더를 만들고 그 안에 README.md, decisions.md, notes.md 파일 3개를 만들어 줘.”

순식간에 폴더와 파일이 생깁니다. 이제 옵시디언으로 가서 여러분이 직접 손으로 채워 넣으세요:

• decisions.md를 열고: 내가 이미 마음속으로 결정한 사항 3가지를 불릿 기호(-)로 적습니다. (예: “결제 모듈은 토스페이먼츠 우선 연동”, “모바일 웹부터 대응”)
• notes.md를 열고: 지금 고민 중인 생각 두 단락을 편하게 적습니다.

다시 터미널의 클로드에게 가서 이렇게 물어보세요.

“projects/pricing-page-redesign/ 안의 문서들을 읽고, 이 프로젝트가 무엇이고 지금까지 무엇이 결정되었으며 아직 남은 고민이 뭔지 요약해서 summary.md 파일로 뽑아줘.”

클로드가 여러분이 방금 쓴 글을 읽고, 결정 사항과 미해결 질문을 기가 막히게 분리해서 요약본을 만들어 냅니다. 이것이 바로 앞으로 우리가 매일 출근해서 맛보게 될 마법입니다.

---

STAGE 4 — Summary and Extension: 동기화(Sync)와 기존 노트 이사

마지막으로 초보자들이 가장 많이 묻는 두 가지 질문을 깔끔하게 정리해 드리겠습니다.

1. “스마트폰이랑 다른 노트북에서도 같이 쓰고 싶은데 동기화는 어떻게 하나요?”

   • 거창한 도구가 필요 없습니다. 볼트 자체가 ‘일반 폴더’이기 때문에, 볼트 폴더 위치를 iCloud Drive나 Dropbox 안에 두면 끝납니다.
   • 보안이 극도로 중요한 개발자라면 오픈소스 도구인 Syncthing을 쓰면 서버를 거치지 않고 내 기기간 직접 동기화가 됩니다. 공식 유료 서비스인 Obsidian Sync를 써도 좋습니다. 볼트는 어디에 있든 상관하지 않습니다.

2. “기존에 노션이나 애플 메모에 써둔 수백 개의 글은 어떻게 가져오나요?”

   • 옵시디언의 공식 플러그인인 Importer를 설치하세요. 노션 zip 파일이나 애플 메모를 클릭 한 번으로 마크다운으로 변환해 줍니다.
   • 단, 가져온 파일들을 절대 projects 폴더에 쏟아붓지 마세요! 일단 전부 _inbox/나 _archive/에 몰아넣어 두고, 매주 금요일 주간 정리 때 천천히 분류해야 볼트가 망가지지 않습니다.

---

[실습 체크포인트 & 과제]

오늘 강의가 끝난 직후 여러분의 화면에 다음 3가지가 갖춰져 있어야 합니다.

1. ~/vault 안에 5대 폴더(_inbox, projects, daily, people, _archive)와 각각의 README.md가 존재하는가?
2. 스모크 테스트 파일(test-vault-check.md)이 옵시디언 창에 자동으로 나타났는가?
3. 지금 내가 진행 중인 진짜 프로젝트 하나가 projects/ 안에 등록되었는가?

---

 

[제5강] 무시당하지 않는 CLAUDE.md 작성법 (The CLAUDE.md That Doesn’t Get Ignored)

지난 4강에서 우리는 드디어 내 컴퓨터에 5대 폴더를 파고, 클로드 코드가 실시간으로 마크다운을 읽고 쓰는 역사적인 첫 루프를 닫았습니다.

그런데 볼트를 구축한 분들이 며칠 지나지 않아 레딧이나 커뮤니티에 가장 많이 올리는 하소연이 있습니다.
“분명히 규칙을 적어뒀는데, 클로드가 대화가 조금만 길어지면 제멋대로 폴더를 만들어요!”

레딧의 유명한 토론 스레드에서 유저 @fredjutsu는 이 고통의 본질을 단 한 문장으로 찔렀습니다.

“claude.md is not a hard instruction it’s a soft suggestion”
(CLAUDE.md는 강제 규정이 아니라 클로드가 수시로 무시하는 부드러운 제안일 뿐입니다.)

이게 무슨 말일까요? 개발사인 앤스로픽(Anthropic)의 공식 문서를 열어보면 아주 솔직하게 적혀 있습니다.
“클로드는 이 파일을 강제적인 설정(Configuration)이 아니라 단순한 배경 맥락(Context)으로 취급합니다.”

즉, 법조문처럼 엄격한 강제 시스템이 아니라는 뜻입니다. 그렇다면 우리는 포기해야 할까요? 아닙니다. 클로드가 세션 1번째 대화는 물론, 20번째 대화에서도 도저히 무시할 수 없게 만드는 ’80~150줄의 브리핑 기술’이 있습니다. 오늘 그 비법을 전수해 드리겠습니다.

---

STAGE 1 — Why It Matters: 당신의 지침서가 쓰레기통으로 들어가는 3가지 이유

비유를 하나 들어볼게요. 여러분이 새로 출근한 신입 수석 비서(AI)에게 업무를 지시하려고 합니다. 다음 세 가지 중 비서가 가장 일을 잘할 수 있는 방식은 무엇일까요?

1. 500페이지짜리 두꺼운 사규집을 던져준다.
   비서는 읽다가 지칩니다. 대화 몇 마디만 오가면 앞부분 내용은 머릿속에서 하얗게 지워집니다.
2. “회사 분위기에 맞게 알아서 잘해”라고 말한다.
   비서는 탭을 써야 할지 스페이스를 써야 할지, 문서를 어디에 저장해야 할지 몰라 눈치만 보다가 제멋대로 행동합니다.
3. “절대 지각하지 마! 절대 딴짓하지 마! 절대 파일 지우지 마!”라며 금지 사항만 30개 외친다.
   비서는 공포에 질려 아무 결정도 못 내리고 사소한 것까지 하나하나 허락을 구하느라 업무가 마비됩니다.

이 세 가지가 바로 여러분의 CLAUDE.md가 실패하는 3대 원인입니다.

• 원인 1: 지나치게 긴 분량 (Length)
  앤스로픽은 200줄 이하를 강력히 권장합니다. 문서가 길어질수록 AI의 ‘주의력 예산(Attention Budget)’을 갉아먹습니다. 책의 권장 분량은 80~150줄입니다. 80줄 미만이면 설명 부족이고, 150줄이 넘어가면 배경 소음으로 전락합니다.
• 원인 2: 구체성 없는 모호함 (Vagueness)
  “프로젝트 컨벤션을 잘 따를 것”이라고 적으면 AI는 아무것도 모릅니다. “프로젝트 규칙은 projects/내프로젝트/decisions.md를 먼저 읽고 따를 것”처럼 정확한 파일 경로(Path)를 찔러줘야 합니다.
• 원인 3: 우선순위 없는 금지어 도배 (Over-prescription)
  ‘NEVER’, ‘DO NOT’을 남발하면 AI는 규칙 간에 충돌이 날 때 무엇이 더 중요한지 판단하지 못합니다. 절대적인 원칙 2~3개와 기본 권장 사항 몇 개로 압축해야 합니다.

이해가 되시나요? CLAUDE.md는 비서를 묶어두는 족쇄가 아니라, 가장 저항이 적은 올바른 길로 유도하는 ‘인수인계 요약본’이어야 합니다.

---

STAGE 2 — Unpacking the Core Concept: 7대 황금 섹션 구조

그렇다면 100줄 안팎의 완벽한 CLAUDE.md는 어떻게 생겨야 할까요? 책에서는 반드시 위에서 아래로 다음의 7개 섹션 순서를 지켜야 한다고 못 박습니다.

1. 정체성 (Identity): 내가 누구인지 2~3문장으로 정의합니다. (예: “나는 파이썬과 SQL을 다루는 프리랜서 백엔드 개발자다.”)
2. 폴더 스키마 (Folder Schema): 2장에서 배운 5대 폴더(_inbox, projects, daily, people, _archive)의 역할을 한 줄씩 요약합니다.
3. 활성 프로젝트 (Active Projects): 지금 실제로 진행 중인 프로젝트 2~3개의 이름과 이번 주 목표를 적습니다. (가장 자주 업데이트되는 섹션입니다.)
4. 의사결정 포인터 (Decision Log Pointer): “과거 결정 사항을 물어보면 각 프로젝트의 decisions.md를 먼저 뒤져라”라는 안내 표지판입니다.
5. 사람과 관계 (People & Entities): 동료나 클라이언트와의 회의 준비를 할 때 people/ 폴더를 보라는 지침입니다.
6. 세션 종료 규칙 (Session-Closer Rules): 대화가 끝날 때 오늘 한 일을 daily/에 적고, 남은 질문을 _inbox/에 던져두라는 뒷정리 규칙입니다.
7. 안티 패턴 (Anti-Patterns): “새 최상위 폴더 만들지 말 것”, “허락 없이 아카이브 파일 삭제하지 말 것” 등 딱 3~4개의 핵심 금지 사항입니다.

이 구조의 핵심은 지식을 직접 담는 것이 아니라, 지식이 있는 곳의 ‘주소(포인터)’만 담는 것입니다. 그래서 파일이 늘 날씬하게 유지될 수 있습니다.

---

STAGE 3 — Evidence and Application: 실전 예시와 ‘배치 순서’의 비밀

실제 프리랜서 개발자가 쓰는 109줄짜리 CLAUDE.md의 핵심 형태를 살펴봅시다.

💡 여기서 가장 중요한 ‘배치 순서(Load-Order)’의 규칙!
왜 Anti-Patterns(금지 사항)를 제일 마지막에 두고, Identity(정체성)를 맨 위에 두었을까요?

AI는 글을 위에서 아래로 읽으며 사고의 프레임(맥락)을 잡습니다. 만약 금지 조항을 맨 위에 두면, 클로드는 세션 내내 “혼나지 않으려면 어떻게 방어적으로 대답해야 하지?”라는 공포 모드에 빠져 지나치게 소극적으로 변합니다.

반대로 정체성을 맨 위에 두고 금지 조항을 맨 아래에 두면, 클로드는 “아, 나는 이 개발자를 돕는 든든한 파트너구나!”라는 긍정적인 역할 모델을 먼저 장착한 뒤, 몇 가지 주의사항만 자연스럽게 지키며 적극적으로 돕게 됩니다.

---

STAGE 4 — Summary and Extension: 내 볼트 적용 및 스모크 테스트

오늘 배운 내용을 바탕으로 여러분의 볼트 루트(~/vault/CLAUDE.md)에 위 7대 섹션을 채워 넣으세요.
작성이 끝나면 터미널에서 글자 수를 확인해 보세요.

80줄에서 150줄 사이라면 완벽합니다!

이제 클로드가 이 지침을 제대로 읽었는지 테스트해 볼 시간입니다. 볼트 폴더에서 터미널을 열고 아무런 설명 없이 이렇게 툭 질문을 던져보세요.

“내가 회의록을 작성하면 어느 폴더에 넣어야 하지?”

클로드가 부가 설명 없이 즉시 “daily/ 폴더에 넣으셔야 합니다”라고 답하거나 스키마를 인용한다면 합격입니다! 만약 “어떤 종류의 회의록인가요?”라며 되묻는다면, 2번 폴더 스키마 섹션이 모호하다는 증거이니 다시 다듬어야 합니다.

---

[이해도 자가 진단 질문]

1. CLAUDE.md 파일에 지난 1년간의 프로젝트 회의록과 방대한 코드 스타일 가이드를 직접 전부 복사해서 붙여넣으면 안 되는 이유는 무엇일까요?
2. 7개 섹션 중 가장 수정 빈도가 잦아야 하며, 만약 여기에 등록된 항목이 5개가 넘어간다면 즉시 정리해야 하는 섹션은 무엇인가요?

---

 

[제6강] CLAUDE.md를 고정시키는 5가지 생명주기 훅 (Five Hooks That Make CLAUDE.md Stick)

지난 5강에서 우리는 100줄 안팎의 완벽한 브리핑 문서인 CLAUDE.md를 작성했습니다. 하지만 여전히 풀리지 않은 숙제가 하나 남아 있습니다. 대화가 1시간, 2시간 길어지거나 수십 번의 대화가 오가면, AI는 세션 처음에 읽었던 그 브리핑 문서를 서서히 잊고 제멋대로 행동하기 시작합니다.

레딧의 r/ClaudeAI 게시판에서 유저 @OkLettuce338은 문서 기반 컨텍스트의 한계를 이렇게 정곡을 찔렀습니다.

“It gets too big to consume at once and you need a progressive disclosure mechanism”
(한 번에 다 담기엔 너무 커지므로, 점진적인 정보 공개 메커니즘이 필요합니다.)

그렇습니다. 전체 볼트를 통째로 AI 머릿속에 쑤셔 넣으면 AI는 정보의 무게에 짓눌려 더 멍청해집니다. 필요한 것은 “딱 필요한 순간에, 딱 필요한 만큼의 정보만 자동으로 밀어 넣어주는 장치”입니다.

그 장치가 바로 오늘 배울 ‘생명주기 훅(Lifecycle Hooks)’입니다.
지침서(CLAUDE.md)가 단순한 ‘사규’라면, 훅(Hooks)은 사규를 위반할 수 없게 만드는 ‘자동 출입 게이트 센서’입니다. 오늘 이 5개의 센서를 완벽하게 달아보겠습니다.

---

STAGE 1 — Why It Matters: 정책은 부드럽고, 훅은 단호하다

비유를 하나 들어볼게요. 회사 로비에 “외부인은 출입 대장을 작성해 주세요”라는 표지판(지침서)을 세워뒀습니다. 바쁜 아침에는 사람들이 표지판을 흘끗 보고 그냥 지나쳐 버립니다. 이게 바로 대화가 길어졌을 때 CLAUDE.md가 겪는 ‘컨텍스트 희석’ 문제입니다.

하지만 로비에 자동 스피드 게이트(센서 훅)를 설치하면 어떻게 될까요?

• 문 앞에 서는 순간(SessionStart) 게이트가 사원증을 스캔합니다.
• 발을 디딜 때마다(UserPromptSubmit) 소지품을 검사합니다.
• 퇴근할 때(Stop)는 자동으로 퇴근 카드를 찍고 문이 닫힙니다.

사람이 깜빡하든 말든 시스템이 알아서 작동합니다. 클로드 코드의 훅(Hooks)도 똑같습니다. 우리가 일일이 “이거 기록해 줘”, “내 프로젝트 규칙 기억하지?”라고 잔소리할 필요가 없습니다. 특정 사건(이벤트)이 터질 때마다 내 컴퓨터의 작은 스크립트가 실행되어 클로드의 멱살을 잡고 올바른 맥락을 주입해 줍니다. 이해가 되시나요?

---

STAGE 2 — Unpacking the Core Concept: AI의 하루를 지배하는 5대 훅

클로드 코드에는 세션이 켜지고 꺼질 때까지 정확한 5개의 타이밍(생명주기)이 존재합니다. 이 타이밍에 각각 전담 요원을 하나씩 배치하는 겁니다.

이 5가지 훅의 역할을 표로 정리해 보겠습니다.

훅 이름	작동 시점	비서에게 시키는 일 (핵심 역할)
1. SessionStart	터미널에서 claude를 켠 순간	[로더] CLAUDE.md와 현재 진행 중인 프로젝트 문서를 읽어 첫 질문 전에 머릿속에 집어넣음
2. UserPromptSubmit	내가 엔터를 치는 매 순간	[검증기] “5대 폴더 원칙 잊지 마!”라는 5줄짜리 알림을 프롬프트 앞에 몰래 붙여줌
3. PostToolUse	클로드가 문서를 쓰거나 고친 직후	[로거] 오늘 날짜 저널(daily/오늘.md)에 “14:20 파일 수정함”이라고 실시간 로그를 남김
4. PreCompact	대화가 너무 길어져서 요약 압축되기 직전	[스냅샷] 이전 대화가 지워지기 전에 중요한 ‘의사결정’들만 뽑아서 일지에 먼저 저장시킴
5. Stop	클로드가 대답을 마치고 멈춘 순간	[클로저] 오늘 작업한 내용이 있다면 일일 저널을 최종 정리하고 인박스를 정리함

이 5개의 톱니바퀴가 맞물려 돌아가면, 클로드는 절대로 기억을 잃어버릴 수 없습니다. 세션이 시작할 때 스스로 기억을 로딩하고, 일할 때마다 장부에 적으며, 끝날 때 스스로 일기를 쓰기 때문입니다.

---

STAGE 3 — Evidence and Application: 실제로 어떻게 설정하고 연결하는가?

“이 대단한 훅들을 설치하려면 엄청난 코딩을 해야 하나요?”
전혀 아닙니다. 5개의 훅 핸들러 스크립트는 합쳐봐야 100줄 안팎의 간단한 셸 스크립트와 파이썬 코드일 뿐입니다.

가장 중요한 첫 번째 훅, SessionStart가 실제로 어떻게 돌아가는지 원리를 볼까요?

우리가 터미널에서 볼트로 들어가 claude를 치면, 클로드 코드는 백그라운드에서 .claude/hooks/session-start.sh라는 스크립트를 조용히 실행합니다. 이 스크립트는 다음과 같은 JSON 텍스트를 클로드에게 건넵니다.

이 짧은 JSON이 여러분이 첫 타이핑을 치기도 전에 클로드의 머릿속에 들어갑니다. 그래서 자리에 앉자마자 “오늘 뭐부터 고치면 되지?”라고만 물어도, 클로드는 이미 그 프로젝트의 모든 역사를 알고 정확한 파일 경로를 짚어내는 겁니다.

[저자의 실제 경험담: 훅이 돈값을 한 순간]
저자가 이 시스템을 몇 달 동안 쓰면서 가장 소름 돋았던 순간이 있었습니다. 어느 날 아침, 새로운 기능 기획을 클로드와 논의하고 있었는데, 클로드가 3주 전에 적어둔 옛날 메모 하나를 불쑥 꺼내 들었습니다. “잠깐만요, 3주 전에 그 방식으로 접근했다가 실패해서 폐기하기로 결정하셨잖아요.”

저자는 까맣게 잊고 있었지만, SessionStart 훅과 로그 시스템이 그 기록을 찾아낸 겁니다. 그 덕분에 저자는 이틀 동안 헛고생할 뻔한 삽질을 피할 수 있었습니다. 단순한 생산성 장난감이 아니라, 진짜 업무 파트너가 되는 순간이었습니다.

---

STAGE 4 — Summary and Extension: 실패하지 않는 3대 설치 체크포인트

이 5대 훅을 설치할 때 초보자들이 99% 겪는 오류와 해결책을 알려드리겠습니다. 책의 부록(Appendix A2)에 있는 코드를 볼트의 .claude/hooks/ 폴더에 넣고 설정할 때 이것만 기억하세요.

1. 실행 권한(chmod +x)을 주었는가?
   스크립트 파일만 만든다고 실행되지 않습니다. 터미널에서 다음 명령어를 반드시 쳐야 합니다.
   chmod +x .claude/hooks/*.sh .claude/hooks/*.py
   (이걸 빼먹어서 훅이 작동하지 않는 경우가 가장 흔합니다.)
2. jq 도구가 컴퓨터에 깔려 있는가?
   스크립트들이 JSON 데이터를 예쁘게 포장하기 위해 jq라는 작은 도구를 씁니다. 터미널에 which jq를 쳐보세요. 없다면 brew install jq(Mac)나 apt install jq(Linux)로 1초 만에 깔아주세요.
3. 훅은 폴더가 아니라 settings.json이 지휘한다!
   스크립트를 .claude/hooks/에 넣어뒀다고 저절로 작동하지 않습니다. 반드시 .claude/settings.json 파일 안에 “어떤 이벤트에 어떤 스크립트를 부를 것인지” 등록해 줘야 비로소 클로드가 인식합니다.

---

[이해도 자가 진단 질문]

1. 대화가 너무 길어져서 클로드가 예전 대화를 요약하고 압축(Compaction)하려고 할 때, 중요한 아키텍처 결정 사항이 통째로 증발하는 것을 막아주는 훅의 이름은 무엇인가요?
2. 클로드가 볼트 안의 코드를 수정하거나 노트를 편집할 때마다 오늘 날짜 일지(daily/YYYY-MM-DD.md)에 자동으로 타임스탬프와 파일명을 적어주는 훅은 무엇인가요?

---

 

[제7강] 밥값 하는 명령어 스킬들: /capture, /daily, /plan, /process-inbox (Skills That Pay Rent)

지난 6강에서 우리는 세션이 시작하고 끝날 때마다 알아서 맥락을 로딩하고 일기를 쓰는 5개의 자동 센서(Hooks)를 설치했습니다.

그런데 뼈대와 자동 센서를 다 갖춰놓은 분들이 바로 이 지점에서 가장 깊은 멘붕에 빠집니다.
레딧의 r/ClaudeAI 게시판에서 유저 @One_Interaction_149는 이 허탈함을 아주 솔직하게 털어놓았습니다.

“I did a bit of this, but also realized, I dont know what I want it to do.”
(저도 이걸 따라 만들어 봤는데, 정작 AI한테 뭘 시켜야 할지 모르겠다는 걸 깨달았습니다.)

서류함도 생겼고 똑똑한 비서도 채용했는데, 막상 비서 책상 앞에 서면 “어… 오늘 뭐 시키지?” 하고 멍해지는 겁니다.

결국 예전처럼 다시 일반 채팅창에 긴 프롬프트를 주절주절 타이핑하다가 지쳐버립니다.
오늘 배울 ‘스킬(Skills)’은 바로 이 어색한 침묵을 깨부수는 무기입니다. 비서의 책상 위에 “버튼 하나만 누르면 알아서 서류를 정리해 오는 5개의 원터치 단축키”를 올려두는 작업입니다.

오늘 강의가 끝나면, 여러분은 긴 프롬프트를 칠 필요 없이 슬래시(/) 한 번으로 하루 업무의 80%를 끝내게 됩니다.

---

STAGE 1 — Why It Matters: 훅(Hooks)은 배경이고, 스킬(Skills)은 전경이다

개념을 선명하게 분리해 볼게요.

• 훅 (Hooks):
  여러분이 신경 쓰지 않아도 뒤에서 알아서 돌아가는 ‘배경 자동화(Background)’입니다. 출퇴근할 때 센서가 사원증을 찍어주는 것과 같습니다.
• 스킬 (Skills):
  여러분이 목적을 가지고 명시적으로 호출하는 ‘의도적 작업(Foreground)’입니다. 비서에게 “김 비서, /daily 실행해”라고 단축 다이얼을 누르는 것과 같습니다.

매일 아침 출근해서 “오늘 날짜로 된 마크다운 파일을 하나 만들고, 맨 위에는 오늘 목표 한 줄, 중간에는 작업 완료 목록, 아래에는 미해결 과제 섹션을 나눠줘”라고 5줄씩 타이핑하고 계신가요?

그 타이핑 자체가 매일 아침 여러분의 에너지를 갉아먹는 마찰력입니다. 그 업무 방식(Heuristic)을 단 50줄 미만의 마크다운 파일 하나로 고정해 두면, 앞으로 여러분은 /daily 딱 6글자만 치면 끝납니다. 이해가 되시나요?

---

STAGE 2 — Unpacking the Core Concept: 스킬이란 도대체 무엇인가?

클로드 코드에서 ‘스킬’이란 복잡한 프로그램이 아닙니다.
볼트 안의 .claude/commands/스킬이름.md 위치에 넣어둔 아주 짧은 마크다운 지침서일 뿐입니다.

예를 들어 .claude/commands/capture.md라는 파일을 하나 만들면, 클로드 터미널에서 즉시 /capture라는 나만의 슬래시 명령어가 생겨납니다.

파일의 구조는 놀라울 정도로 단순합니다.

이게 전부입니다. 프로그래밍 코드가 아니라 명확한 한국어나 영어 프롬프트입니다. 하지만 이 짧은 파일 하나가 여러분의 시간 수십 시간을 아껴줍니다.

책에서 제시하는, 매일 ‘밥값(Rent)’을 톡톡히 해내는 5대 필수 스킬을 한눈에 정리해 볼까요?

슬래시 명령어	실행 시점	비서가 하는 일	출력물 위치
/capture <내용>	번뜩이는 생각, 슬랙 링크 생겼을 때	생각할 틈 없이 정해진 규격으로 인박스에 파일 생성	_inbox/
/daily	매일 아침 출근 직후	오늘의 저널 양식(Intent, Done, Open) 자동 생성	daily/오늘.md
/plan	월요일 아침, 우선순위 흔들릴 때	projects/의 모든 문서를 읽고 날카로운 우선순위 권고	터미널 화면 (일회성)
/process-inbox	매주 금요일 오후	_inbox/의 모든 메모를 읽고 어디로 보낼지 추천 표 작성	터미널 화면 (확인용)
/weekly-review	금요일 퇴근 전	지난 7일간의 일지를 털어 의사결정·완료·남은 일 요약	_archive/weekly-reviews/

---

STAGE 3 — Evidence and Application: 5대 핵심 스킬의 실전 규칙

이 5개 스킬 중 가장 놀랍고 유용한 3가지의 실전 운영 디테일을 살펴보겠습니다.

1. /capture: 마찰력 제로의 수집기
일을 하다가 “아, 3분기 기획안 슬랙 링크 나중에 봐야지”라는 생각이 들면, 옵시디언을 켜고 제목을 고민할 필요가 없습니다.
터미널에서 바로 칩니다:
/capture 3분기 기획안 슬랙 링크 확인 - 금요일까지 피드백
클로드는 3초 만에 _inbox/2026-04-26-q3-roadmap-slack.md라는 완벽한 이름의 파일을 생성하고 입을 닫습니다. 파일명 짓는 스트레스가 사라집니다.

2. /plan: 단호한 우선순위 제안 (의견 있는 AI 만들기)
월요일 아침에 /plan을 치면 클로드는 projects/ 안의 활성 프로젝트 README와 결정 로그를 싹 훑습니다.
여기서 프롬프트의 핵심 비결은 “Be opinionated(확고한 의견을 가져라)”라는 지침입니다.
두루뭉술하게 “다 중요해 보입니다”라고 아첨하는 비서는 쓸모가 없습니다. 마감일과 병목 현상을 분석해서 “A 프로젝트와 B 프로젝트의 마감이 겹치므로, 오늘은 무조건 A의 결제 모듈부터 끝내셔야 합니다”라고 단호하게 지적하게 만들어야 합니다.

3. /process-inbox: 자동 이동 금지의 안전장치
/process-inbox는 인박스에 쌓인 메모를 읽고 다음과 같은 표를 화면에 띄웁니다:

현재 파일	추천 이동 위치	사유
_inbox/결제오류.md	projects/acme-api/	어제 수정한 API 버그와 직접 관련된 메모임
_inbox/영수증처리.md	_archive/	1회성 잡무 메모이므로 보관 처리
_inbox/정체불명아이디어.md	[확인 필요(Needs Review)]	맥락이 부족하여 어디로 넣을지 모호함

💡 여기서 가장 중요한 안전 원칙!
이 스킬은 파일을 절대로 지 혼자 마음대로 옮기지 않습니다.
인간이 표를 보고 “좋아, 그렇게 옮겨”라고 승인했을 때만 움직입니다. AI가 자의적으로 파일을 옮기다가 중요한 메모가 증발하는 참사를 막는 가장 훌륭한 안전장치입니다.

---

STAGE 4 — Summary and Extension: 스킬이 할 수 없는 일 (한계 알기)

스킬을 만들다 보면 너무 신나서 모든 것을 스킬로 만들고 싶어집니다. 하지만 스킬의 명확한 한계를 알고 있어야 합니다.

1. 스킬은 ‘단발성(One-shot)’ 작업 전용입니다.
   오늘 1단계를 하고, 내일 2단계를 하고, 3일 뒤에 결과를 합치는 식의 복잡한 다단계 작업은 스킬에 맞지 않습니다.
2. 스킬은 예약 실행(Cron Schedule)이 안 됩니다.
   “매주 금요일 5시마다 알아서 돌아라”라고 시킬 수 없습니다. 스킬은 오직 여러분이 터미널에서 엔터를 쳐서 부를 때만 동작합니다.
3. 스킬은 부모 대화창의 메모리를 같이 씁니다.
   스킬이 너무 많은 문서를 한 번에 읽으면, 여러분이 작업하던 터미널의 대화 컨텍스트가 가득 차서 금방 둔해집니다.

“그럼 수천 개의 노트를 읽고 분석하거나, 복잡한 리서치를 백그라운드에서 돌리고 싶을 때는 어떻게 하나요?”
바로 그 질문에 대한 답이 다음 장에 나옵니다. 스킬의 한계를 뛰어넘어, 나만의 독립된 메모리를 가지고 백그라운드에서 임무를 완수하고 돌아오는 특수 요원, ‘서브에이전트(Subagents)’를 부르면 됩니다.

---

[이해도 자가 진단 질문]

1. 내가 터미널에서 수동으로 슬래시(/)를 입력하지 않아도, 세션이 시작되거나 파일이 저장될 때 백그라운드에서 자동으로 감지되어 실행되는 장치는 ‘스킬’일까요, ‘훅’일까요?
2. /process-inbox 스킬을 만들 때, AI가 인박스의 파일들을 추천 경로로 즉시 자동 이동(auto-mv)시키지 않고 표를 먼저 출력해 사용자에게 보여주도록 설계하는 이유는 무엇일까요?

---

 

[제8강] 밥값 하는 3가지 서브에이전트 (Three Subagents That Pay Rent)

지난 7강에서 우리는 슬래시 명령어 하나로 하루 업무 루틴을 처리하는 5가지 단축키(Skills)를 배웠습니다.

그런데 볼트에 노트가 500개, 1,000개 쌓이기 시작하면 새로운 벽에 부딪힙니다.
“지난 2주 치 일기 30개를 전부 읽고 내 성과를 뽑아줘”, “볼트 전체를 훑어서 서로 연결 안 된 노트를 다 찾아줘” 같은 요청을 스킬로 돌리면 어떻게 될까요?

수십 개의 파일 내용이 메인 채팅창에 한꺼번에 쏟아져 들어오면서 대화창의 메모리(컨텍스트)가 꽉 차버립니다. 방금 전까지 하던 작업 맥락은 흔적도 없이 밀려나고, AI는 둔해집니다.

옵시디언 회의론 스레드에서 유저 @YouWillConcur는 도대체 실무자들이 시스템을 어떻게 굴리는지 이렇게 물었습니다.

“Could you describe more in depth what you do? what heuristics do you use?”
(실제로 무엇을 하는지, 어떤 휴리스틱을 사용하는지 더 깊이 설명해 주실 수 있나요?)

책에서는 이 질문에 명쾌하게 답합니다.
“휴리스틱(노하우)을 적어서 독립된 방으로 파견 보내는 것, 그것이 바로 서브에이전트(Subagents)다.”

오늘은 메인 세션을 티끌 하나 어지럽히지 않고 백그라운드에서 수백 개의 노트를 조사하고 돌아오는 특수 정예 요원 3총사를 조직해 보겠습니다.

---

STAGE 1 — Why It Matters: 사장실을 어지럽히지 않는 비결

비유를 하나 들어볼게요. 여러분이 한 회사의 사장님(메인 세션)입니다. 중요한 비즈니스 결정을 내리고 있습니다.

• 방식 A (스킬의 한계):
  비서에게 “지난 한 달 치 영수증과 회의록 500장 싹 긁어모아서 분석해 와”라고 시켰습니다. 비서가 사장님 책상 위에 서류 500장을 쿵! 하고 쏟아붓습니다. 책상이 서류 더미에 파묻혀 사장님은 정작 하려던 메인 업무를 보지 못합니다.
• 방식 B (서브에이전트):
  사장님이 전문 조사관에게 “별관 회의실(독립된 컨텍스트)로 가서 저 500장 분석하고 와”라고 파견을 보냅니다. 조사관은 혼자 회의실에 틀어박혀 서류를 샅샅이 뒤진 뒤, 사장실로는 단 1장짜리 핵심 요약 보고서만 들고 노크합니다. 사장님의 책상은 여전히 깨끗합니다.

이 차이가 이해가 되시나요?
스킬은 내 대화창에서 순서대로 실행되는 단축키이고, 서브에이전트(Subagent)는 자기만의 독립된 뇌(Context Window)를 가지고 나가서 일하고 오는 외주 전문가입니다.

---

STAGE 2 — Unpacking the Core Concept: 깃허브에서 검증된 정예 요원 3총사

서브에이전트 역시 거창한 코드가 아닙니다. 볼트 안의 .claude/agents/이름.md 경로에 마크다운 파일로 작성합니다.

상단에는 YAML 설정(이름, 설명, 허용할 도구, 모델)을 적고, 본문에는 사명(지침)을 적어줍니다. 깃허브 2,000스타를 받은 오픈소스 저장소(breferrari/obsidian-mind)에서 뽑아낸, 가장 실용적인 3대 에이전트를 소개합니다.

1. brag-spotter (자랑거리 발굴 요원)

• 임무: 지난 14일간의 일일 노트(daily/)를 샅샅이 뒤져 내가 이뤄낸 진짜 성과를 발굴합니다.
• 필터링 규칙: 영수증 처리, 단순 미팅 참석 같은 일상 잡무는 철저히 무시합니다. “배포 완료”, “주요 의사결정”, “고객의 칭찬”처럼 인사고과나 연봉 협상 때 매니저에게 자랑할 수 있는 알맹이만 골라냅니다.
• 결과물: people/me/wins.md 파일에 차곡차곡 누적합니다.

2. slack-archaeologist (슬랙 고고학자)

• 임무: 여러 사람의 대화가 뒤섞인 슬랙 스레드를 통째로 복사해서 던져주면, 인물별로 프로필을 분리해 줍니다.
• 행동 강령: “지수”가 한 말, “민수”가 한 말을 발라내어 각자의 폴더(people/jisu/profile.md, people/minsu/profile.md)에 오늘 날짜로 덧붙입니다.
• 안전 규칙: 기존에 적혀 있던 동료의 프로필을 절대 덮어쓰거나 지우지 않고 오직 아래에 추가(Append-only)만 합니다.

3. cross-linker (지식 연결관)

• 임무: 볼트 안의 문서들을 읽으며 서로 연결되어야 하는데 빠져 있는 위키링크([[문서명]])를 찾아냅니다.
• 작동 원리: A라는 문서에서 “결제 API”라는 단어를 언급했는데, 마침 볼트에 결제 API.md라는 문서가 있다면 “여기에 링크를 거는 게 어떨까요?”라고 제안합니다.
• 안전 규칙: 원본 파일을 지 마음대로 수정하지 않습니다. 추천 목록을 _archive/cross-link-suggestions.md라는 표로 뽑아두고 인간의 승인을 기다립니다.

---

STAGE 3 — Evidence and Application: 금요일 오후의 15분 병렬 오케스트라

이 서브에이전트들의 진가는 ‘동시에 병렬로 실행할 때’ 폭발합니다.
책에서 묘사하는 실제 금요일 오후의 15분 업무 풍경을 볼까요?

• 오후 3시 50분: 터미널에서 볼트로 들어가 클로드를 켭니다.
• 오후 3시 51분: 명령어 한 줄을 던집니다.
  “지난 7일간의 노트를 대상으로 brag-spotter와 cross-linker를 백그라운드에서 병렬로 돌려줘. 그리고 메인 세션에서는 /weekly-review를 시작하자.”
• 오후 3시 51분~3시 54분:
  • 조사관 1(brag-spotter)은 다른 방에서 일기장을 뒤지며 이번 주 성과 3개를 찾아냅니다.
  • 조사관 2(cross-linker)는 다른 방에서 빠진 링크 5개를 찾아 표로 만듭니다.
  • 메인 세션의 클로드는 사장님과 함께 이번 주 주간 회고 문서를 작성합니다.
• 오후 3시 54분: 세 작업이 동시에 끝납니다!
• 오후 3시 55분~4시 05분: 사장님(나)은 10분 동안 에이전트들이 가져온 3개의 보고서만 쓱 읽어보고, 추천된 링크를 승인하고 주간 회고를 확정합니다.
• 오후 4시 05분: 터미널을 닫습니다. Stop 훅이 작동하며 오늘 일지에 최종 결정을 백업하고 깔끔하게 업무가 끝납니다.

손으로 직접 했다면 1시간 넘게 걸렸을 고통스러운 정리 작업이, 세 요원을 동시에 부림으로써 단 15분 만에 끝난 것입니다.

---

STAGE 4 — Summary and Extension: 나만의 서브에이전트 제작 공식

앞으로 여러분의 업무에 맞춰 새로운 에이전트를 만들고 싶다면, 딱 하나의 황금률만 기억하세요.
“한 달에 두 번 이상 반복되고, 손으로 하면 10분 이상 걸리며, 독립된 백지가 필요한 작업인가?”

이 세 가지가 맞는다면, 파일 이름을 ‘동사-명사(Verb-Noun)’ 형태로 짓고 .claude/agents/에 마크다운을 만드세요.

• meeting-prepper.md: 캘린더 일정을 던져주면 관련 사람과 프로젝트 문서를 훑어 1장짜리 사전 브리핑 작성
• inbox-zero.md: 매주 인박스를 훑어 90일 넘게 방치된 메모를 아카이브로 추천
• research-synthesizer.md: 볼트 안의 특정 주제 노트 10개를 모아 종합 보고서 작성

단, 주의하세요!
“볼트 관리 도와주기” 같은 두루뭉술한 에이전트는 100% 실패합니다.
서브에이전트는 단 하나의 명확한 입력과 단 하나의 구체적인 결과 파일(Contract)을 가질 때만 제 밥값을 합니다.

---

[이해도 자가 진단 질문]

1. 지난 2주간의 방대한 일일 노트 수십 개를 분석해야 할 때, 일반 대화창(스킬) 대신 ‘서브에이전트’를 호출해야 메인 세션이 느려지지 않는 기술적 이유는 무엇일까요?
2. cross-linker 에이전트가 빠진 문서 링크를 발견했을 때, 원본 문서를 즉시 자동으로 수정해 버리지 않고 추천 목록 표를 먼저 작성하도록 설계한 이유는 무엇일까요?

---

 

[제9강] 당신의 역할, 당신의 볼트 (Your Role, Your Vault)

지난 8강까지 우리는 볼트의 뼈대를 세우고, 5가지 자동 센서(Hooks)를 달고, 5가지 단축키(Skills)와 3명의 특수 요원(Subagents)까지 완벽하게 고용했습니다. 인프라는 100% 완성되었습니다.

그런데 똑같은 서류함과 똑같은 AI 비서를 쥐여주어도, 어떤 사람은 여전히 허덕이고 어떤 사람은 연봉을 올리고 사업을 폭발적으로 성장시킵니다. 차이가 어디서 올까요?

레딧의 r/ClaudeAI 게시판에서 무려 75개의 추천을 받으며 실무자들의 열광을 이끌어낸 현직 프로덕트 매니저(PM) 유저 @ch-12는 자신의 경험을 이렇게 증언했습니다.

“I use this setup at work as a software product manager… It crafted my obsidian vault”
(저는 소프트웨어 PM으로서 직장에서 이 설정을 사용하고 있습니다. 이것이 제 옵시디언 볼트를 구축해 주었습니다.)

그렇습니다. 중요한 것은 도구의 종류가 아니라 “내가 매일 어떤 의식(Ritual)으로 이 시스템을 굴리는가”입니다.
똑같은 5대 폴더 서류함이지만, 프리랜서에게는 ‘돈을 떼이지 않게 지켜주는 방패’가 되고, PM에게는 ’40분 걸리던 1:1 미팅 준비를 5분으로 줄여주는 치트키’가 됩니다.

오늘 강의에서는 여러분의 실제 직업에 맞춰 시스템을 200% 폭발시키는 4대 맞춤형 플레이북을 전수해 드립니다.

---

STAGE 1 — Why It Matters: 도구는 하나지만 레시피는 달라야 한다

비유를 하나 들어볼게요. 최고급 주방이 하나 있습니다. 칼, 도마, 가스레인지, 냉장고(5대 폴더와 클로드)가 완벽하게 갖춰져 있습니다.

• 여기에 제과사가 들어오면 정밀한 저울과 오븐 온도 타이머를 세팅해야 합니다.
• 스테이크 전문 셰프가 들어오면 고기 숙성고와 강한 화력이 필요합니다.
• 바텐더가 들어오면 셰이커와 얼음이 중심이 되어야 합니다.

주방의 기본 설비(5대 폴더, CLAUDE.md, 훅)는 똑같습니다. 바뀌어야 하는 것은 ‘주간 회고(Weekly Review)에서 무엇을 뽑아낼 것인가’와 ‘people/과 projects/ 폴더를 어떤 데이터로 채울 것인가’입니다.

자신에게 맞지 않는 남의 업무 방식을 그대로 복사해 오면, 일주일 만에 시스템을 버리게 됩니다. 철저히 내 업무의 고통을 해결하는 방향으로 정렬해야 합니다. 이해가 되시나요?

---

STAGE 2 — Unpacking the Core Concept: 4대 직무별 맞춤형 볼트 레이아웃

책에서 정의하는 4가지 대표 역할의 실전 구성과 전용 주간 회고 스킬을 살펴보겠습니다.

구분	특화 폴더 구조	핵심 해결 과제	전용 명령어 및 결과물
1. PM	projects/sprint-12/ people/팀원명/meetings/	지난주에 팀원이 요청한 사항을 까먹고 1:1 미팅에 들어가는 참사 방지	/weekly-review-pm 👉 스프린트 변동사항 + 팀원별 미해결 질문 1장 요약
2. 창업가	projects/decisions/ (날짜-의사결정.md)	3달 전에 가격 정책을 왜 바꿨는지 잊어버리고 주말마다 투자자 레터로 밤새는 고통 해결	/weekly-review-founder 👉 결정 배경 요약 + 투자자 이메일에 바로 붙여넣는 성과 불릿
3. 프리랜서	projects/고객사명/ (scope.md, changes.md)	구두로 추가 요청해놓고 청구서 보낼 때 발뺌하는 고객사의 ‘범위 잠식’ 차단	/weekly-review-freelancer 👉 합의된 원래 범위 vs 추가 작업 내역 대조 청구서 초안
4. 지식 노동자	daily/의 미팅 섹션 people/동료명/profile.md	“화요일 회의 때 김 과장이 부탁한 자료”를 금요일까지 까먹고 있다가 생기는 사고 방지	/weekly-review-kw 👉 내가 해줘야 할 일(My Asks)과 남이 해주기로 한 일(Their Asks) 추출

---

STAGE 3 — Evidence and Application: 현업 고수들의 실제 파이프라인

책에서는 레딧에서 가장 구체적인 프로덕션 파이프라인을 운영 중인 유저들의 실제 사례를 공개합니다.

1. 유저 @kaizer1c의 5단계 실전 파이프라인 (4개월 실운영)

이 유저는 단순 메모를 넘어 삶 전체를 볼트에 연결했습니다.

• 1단계 (이메일 분류): 아침마다 지메일을 스캔하여 할 일은 _inbox/ 노트로, 미팅 요청은 캘린더로 자동 분류.
• 2단계 (주간 프로젝트 정리): 2주 동안 아무 수정이 없는 프로젝트를 찾아 아카이브 후보로 추천.
• 3단계 (시맨틱 검색): 노트가 2,000개를 넘어가자 로컬 벡터 임베딩을 장착하여 키워드가 달라도 개념으로 검색 (10장에서 자세히 다룸).
• 4단계 (여행 계획): 비행기나 숙소를 예약하면 projects/travel-도쿄/에 일정표와 파트너 공유용 캘린더 생성.
• 5단계 (음성 작업 기록): 작업이 끝날 때마다 스마트폰에 한 줄 음성 메모를 녹음하면, Whisper가 텍스트로 풀어 _inbox/에 넣고, Toggl에 작업 시간을 자동 등록.

2. 유저 @docNNST의 다중 볼트(Multi-Vault) 원칙

“볼트를 개인용, 회사용으로 쪼개야 하나요, 하나로 합쳐야 하나요?”라는 질문에 대한 가장 현명한 해답입니다.

• 이 유저는 여러 개의 직업(복수 고객사 컨설팅)을 동시에 뛰고 있습니다.
• 그는 ‘보안과 비밀유지계약(NDA)’의 경계에 따라서만 볼트를 분리합니다.
  • A 회사 볼트 (A사 기밀 코드와 문서)
  • B 회사 볼트 (B사 업무)
  • 개인 볼트 (개인 학습 및 일상)
• 그리고 웹 브라우저의 claude.ai를 최고 아키텍트로 두고 볼트 간의 큰 그림을 조율합니다.

💡 저스틴의 핵심 가이드:
여러분이 법적 비밀유지 서약을 한 기업 프로젝트를 다루거나 극도로 민감한 개인 일기를 쓰는 것이 아니라면, 볼트는 무조건 ‘하나’로 시작하는 것이 정답입니다. 볼트를 3~4개로 쪼개는 순간, 메모를 적을 때마다 볼트를 전환해야 하는 피로감 때문에 시스템 전체가 멈추게 됩니다.

---

STAGE 4 — Summary and Extension: 오늘 당장 실행할 나의 역할 선택

오늘 강의가 끝나면 여러분은 책의 부록(Appendix A5)에 있는 4가지 주간 회고 템플릿 중 딱 하나를 골라 .claude/commands/에 심어야 합니다.

만약 여러분이 프리랜서라면:

1. projects/고객사A/scope.md를 만드세요. (최초 계약 내용과 금액)
2. 고객이 카톡이나 슬랙으로 “이것도 살짝 추가해 주세요”라고 할 때마다 projects/고객사A/changes.md에 날짜와 함께 한 줄을 적어두세요.
3. 목요일 오후에 터미널에서 /weekly-review-freelancer를 실행하세요.
4. 클로드가 이렇게 출력해 줄 겁니다:
   “고객사 A: 원래 계약에는 결제 모듈만 있었으나, 4월 22일 대화에서 관리자 대시보드 추가 요청이 있었습니다. 청구서 발행 전 추가 공수 협의가 필요합니다.”

이 한 번의 알림이 여러분의 수십, 수백만 원짜리 공짜 야근을 막아줍니다. 시스템이 내 밥값을 벌어다 주는 순간입니다.

---

[이해도 자가 진단 질문]

1. 프리랜서가 클라이언트의 ‘작업 범위 잠식(Scope Drift, 슬그머니 일 더 시키기)’을 방어하기 위해 projects/고객사명/ 폴더 안에 반드시 유지해야 하는 두 가지 핵심 마크다운 문서의 이름은 무엇인가요?
2. 기업의 엄격한 비밀유지계약(NDA)이 걸린 업무 자료와 개인 블로그 아이디어 노트를 관리할 때, 단일 볼트 대신 ‘다중 볼트(Multi-Vault)’로 쪼개야 하는 유일하고 결정적인 기준은 무엇일까요?

---

 

[제10강] 2,000개 노트에서의 기억법 (Memory at 2,000 Notes)

시스템을 착실히 굴려 6개월, 9개월이 지나면 볼트 안에 노트가 1,000개, 2,000개씩 쌓이기 시작합니다.
바로 이 시점에 모든 세컨드 브레인 사용자들에게 거대한 위기가 찾아옵니다.

분명히 예전에는 “지난번 가격 정책 결정 찾아줘”라고 하면 클로드가 1초 만에 척척 찾아냈는데, 노트가 2,000개를 넘어가자 엉뚱한 대화 기록이나 스크랩 글 30개를 마구 긁어오기 시작합니다. 결국 내가 일일이 클릭해서 확인해야 합니다.

레딧의 r/ClaudeAI 게시판에서 유저 @kyletraz는 매 세션마다 겪는 피로감을 이렇게 표현했습니다.

“Every new session, I’d spend the first few exchanges reconstructing what I was building”
(새 세션마다 무엇을 만들고 있었는지 재구성하느라 처음 몇 번의 대화를 허비하곤 했습니다.)

노트가 100개일 때는 비서가 파일 이름만 훑어도 다 기억할 수 있었습니다.
하지만 2,000개가 넘어가면 ‘단순 단어 검색(Grep)’ 방식 자체가 물리적 한계에 부딪힙니다.

오늘 강의에서는 내 컴퓨터 밖으로 개인정보를 단 1바이트도 유출하지 않으면서, 단어가 아닌 ‘의미와 개념(Concept)’으로 문서를 척척 찾아내는 3단계 두뇌 업그레이드 비법을 전수해 드립니다.

---

STAGE 1 — Why It Matters: 키워드 검색은 왜 수천 개 문서 앞에서 무너질까요?

비유를 하나 들어볼게요. 두껍고 거대한 백과사전 50권이 서가에 꽂혀 있습니다.

• 키워드 검색 (Grep):
  사전 맨 뒤의 ‘찾아보기(색인)’에서 정확히 “토마토”라는 글자를 찾는 겁니다. 책에 “토마토”라고 정확히 적혀 있으면 1초 만에 찾아냅니다. 하지만 내가 찾고 싶은 내용이 “붉고 즙이 많은 채소”라고 적혀 있다면? “토마토”라는 글자가 없으므로 검색 결과는 0건이 뜹니다. 반대로 “가격”이라는 흔한 단어를 검색하면 관련 없는 문서가 100개 쏟아져 나와 사람을 질리게 만듭니다.
• 시맨틱 검색 (Semantic Search / 의미 기반 검색):
  도서관의 사서가 책의 모든 내용을 읽고 머릿속에 ‘의미의 지도’를 그리고 있는 상태입니다. 내가 “지난 분기에 돈 받는 방식 바꾼 거 어디 있지?”라고 물으면, 문서에 ‘돈’이나 ‘지난 분기’라는 단어가 없어도 “구독형 요금제 개편안” 문서를 정확하게 집어내 내밉니다.

노트가 200개 이하일 때는 키워드 검색으로도 충분했습니다.
하지만 2,000개가 넘어가면 AI에게 ‘단어의 뜻을 이해하는 눈’을 달아주어야만 시스템이 살아남습니다. 이해가 되시나요?

---

STAGE 2 — Unpacking the Core Concept: 지식 검색의 3대 계층 (3 Tiers)

책에서는 볼트의 성장에 따라 검색 인프라를 3단계(Tier)로 나누어 진화시켜야 한다고 말합니다.

계층	볼트 규모	작동 방식 및 도구	장점과 한계
Tier 1 (Grep)	200개 미만	파일 경로, 파일명, 단순 단어 일치 검색	추가 설치 불필요, 정확한 고유명사 검색에 최고. 단, 개념 검색 불가
Tier 2 (로컬 임베딩)	200~2,000개+	Ollama + obsidian-copilot 플러그인	내 노트북 안에서 완전 무료·오프라인 구동. 단어가 달라도 문맥으로 찾아냄
Tier 3 (커스텀 MCP)	5,000개 이상	stdio 기반의 로컬 MCP 서버 (qmd 등)	클로드 코드가 대화 도중 직접 도구로 검색 호출 가능. 설정 난이도 높음

대부분의 지식 노동자와 개발자는 Tier 2(로컬 임베딩) 단계만 갖춰두면 앞으로 몇 년 동안 아무 걱정 없이 수천 개의 노트를 완벽하게 지배할 수 있습니다.

---

STAGE 3 — Evidence and Application: 20분 만에 끝내는 로컬 임베딩 구축

“내 비밀 노트들을 외부 AI 회사 서버로 보내서 색인해야 하나요?”
절대 아닙니다! 우리는 내 노트북 안에서만 돌아가는 오픈소스 로컬 모델(Ollama)을 쓸 겁니다. 인터넷 연결을 끊어도 동작합니다.

딱 5단계로 끝납니다.

1단계: 올라마(Ollama) 설치

공식 사이트(ollama.com)에서 프로그램을 내려받아 설치합니다. (내 컴퓨터에서 AI 모델을 돌려주는 초경량 엔진입니다.)

2단계: 임베딩 전용 모델 다운로드

터미널을 열고 다음 명령어를 칩니다.

마크다운 문서를 읽고 의미를 숫자로 변환하는 데 가장 최적화된 작고 빠른 모델입니다. (조금 더 정밀한 검색을 원한다면 ollama pull mxbai-embed-large를 쓰셔도 좋습니다.)

⚠️ 주의! 인터넷 블로그에서 ollama pull --quantize ... 같은 옵션을 쓰라는 글을 보더라도 절대 따라 하지 마세요! 올라마 명령어에는 그런 플래그가 없습니다.

3단계: 가장 중요한 함정! CORS 환경변수 설정

초보자의 90%가 여기서 막혀서 포기합니다. 옵시디언 앱이 로컬 올라마 엔진과 통신하려면, 올라마에게 “옵시디언의 접근을 허락해라”라는 통행증을 쥐여준 상태에서 엔진을 켜야 합니다.

터미널에서 반드시 엔진을 켜기 전에 이 환경변수를 먼저 입력하세요:

(만약 올라마가 이미 켜져 있다면 완전히 종료한 뒤 위 명령어를 순서대로 쳐서 다시 켜야 합니다.)

4단계: 옵시디언 플러그인 설치

옵시디언 설정 → 커뮤니티 플러그인 → 탐색으로 가서 “Copilot for Obsidian”(logancyang 제작, 깃허브 6,800스타)을 검색해 설치하고 활성화합니다.

5단계: 로컬 모델 연결 및 인덱싱

옵시디언의 Copilot 설정 창으로 갑니다.

• 제공자(Provider): Ollama 선택
• 모델 이름: 방금 다운로드한 nomic-embed-text 입력
• 저장(Save)을 누릅니다.

이제 플러그인이 내 볼트 안의 모든 노트를 읽으며 ‘의미의 색인 지도’를 만들기 시작합니다. 1,000개 노트 기준으로 약 10분, 2,000개 노트 기준으로 약 20분이면 끝납니다.

---

STAGE 4 — Summary and Extension: 가짜 도구 주의보와 검색의 지혜

구축이 끝나면 옵시디언의 Copilot 패널을 열고 테스트해 보세요. 문서에 한 번도 등장하지 않은 문장, 예를 들어 “지난 분기 가격 책정 어떻게 하기로 했지?”라고 물어보세요.
본문에 ‘가격 책정’이라는 단어가 없어도, 요금제 개편 회의록이 1순위로 튀어나온다면 성공입니다!

마지막으로 인터넷 커뮤니티를 떠도는 잘못된 정보와 한계를 짚어드리겠습니다.

1. 가짜 제품에 낚이지 마세요!
   레딧에 가끔 “옵시디언용 omegamax mem 써보신 분 있나요?” 같은 글이 올라옵니다. 세상에 omegamax mem이라는 제품은 존재하지 않습니다. 누군가 이름을 잘못 기억한 헛소문입니다. 대화 기억은 mem0, 종합 기억 시스템은 MemPalace(깃허브 4.9만 스타)가 진짜 오픈소스 프로젝트입니다.
2. 노트북LM(NotebookLM)은 연동 도구가 아닙니다!
   구글 노트북LM에 옵시디언 폴더 구조를 통째로 연동하는 마법 같은 방법은 없습니다. 노트북LM은 그냥 내가 손으로 복사해서 업로드한 파일을 읽는 별개의 독립 웹 서비스일 뿐입니다.
3. 임베딩이 만능은 아닙니다 (Grep과의 아름다운 동거)
   • “구독 모델 도입 배경이 뭐였지?” 👉 임베딩(Copilot)이 정답입니다. (개념 검색)
   • “지난달 Acme 계약서의 정확한 금액이 얼마였지?” 👉 단어 검색(Grep)이 정답입니다. (정확한 수치·고유명사)

똑똑한 사용자는 둘 중 하나만 쓰지 않습니다.
개념을 찾을 때는 임베딩 렌즈를 끼고, 정확한 숫자나 고유명사를 찾을 때는 Grep 돋보기를 들이댑니다. 이 두 가지가 결합할 때 2,000개의 문서는 더 이상 잡동사니가 아니라 완벽한 내 두뇌가 됩니다.

---

[이해도 자가 진단 질문]

1. “2026년 4월 15일에 발생한 서버 오류 코드 500의 정확한 에러 로그”를 찾으려고 합니다. 이때는 ‘의미 기반 임베딩 검색’과 ‘키워드 검색(Grep)’ 중 어느 쪽이 훨씬 더 빠르고 정확할까요?
2. 옵시디언의 Copilot 플러그인이 내 컴퓨터의 올라마(Ollama) 모델과 정상적으로 통신하기 위해, 올라마 서버를 켜기 전에 터미널에 반드시 등록해야 하는 환경변수 설정 코드는 무엇인가요?

---

 

[제11강] 시스템이 삐걱거릴 때: 20분 진단법 (When It Breaks, And the 20-Minute Diagnostic)

우리는 지난 10강까지 완벽한 도서관을 짓고, 자동문(Hooks)을 달고, 특수 조사관(Subagents)을 배치하고, 의미를 꿰뚫어 보는 투시경(임베딩)까지 장착했습니다.

그런데 수만 명의 구독자를 가진 외국의 한 유명 테크 유튜버, 조나단 맥레모어(Jonathan McLemore)는 영상에서 아주 뼈아픈 진실을 폭로했습니다.

“this is one of the things that kills the Obsidian approach for owners.”
(지식 정원을 계속 가꿔야 한다는 부담감이야말로 사용자들이 옵시디언을 포기하게 만드는 주범입니다.)

그렇습니다. 만드는 것은 토요일 하루면 끝나지만, 유지하는 것은 끝없는 일상이기 때문입니다.
시스템을 만들고 한 달쯤 지나면 노트 이름이 바뀌면서 링크가 깨지고, 인박스에는 한 달 전 메모가 굴러다니며, 어느 순간 옵시디언 창을 열지 않는 자신을 발견하게 됩니다.

장담컨대, 이건 여러분이 게을러서가 아닙니다. 모든 시스템이 겪는 자연스러운 ‘부품 마모 현상’일 뿐입니다.
자동차가 5,000km를 달리면 엔진오일을 갈아주듯, 볼트도 정기적으로 기름칠만 해주면 평생 쌩쌩하게 돌아갑니다.

오늘 강의에서는 시스템을 파괴하는 4대 고장 증상을 진단하고, 딱 20분 만에 볼트를 새것처럼 복원하는 ‘월간 20분 진단법’을 전수해 드립니다.

---

STAGE 1 — Why It Matters: 왜 사람들은 4주 만에 시스템을 버릴까요?

트위터(X)의 한 인플루언서는 이렇게 꼬집었습니다.
“대부분의 사람들은 볼트를 방치해 버리거나, 아니면 매달 20달러를 내면서 형편없이 요약해 주는 AI 툴에 돈을 낭비한다.”

사람들이 기껏 구축한 세컨드 브레인을 4주 만에 버리는 데는 정확히 3가지 방아쇠(Triggers)가 있습니다.

1. 초반의 과도한 욕심 (Over-engineering early):
   토요일에 볼트를 만들고, 일요일에 에이전트 5개를 붙이고, 월요일에 벡터 DB까지 띄웁니다. 복잡성이 너무 높아져서 작은 에러 하나만 나도 고치지 못하고 질려버립니다.
2. 매일의 작은 의식 부재 (No daily ritual):
   인박스에 메모를 던져넣기만 하고 털어내지 않습니다. 일기를 쓰지 않으니 볼트와 내 현실 업무가 완전히 분리되어 ‘남의 일기장’처럼 느껴집니다.
3. 2주 차의 보상 부재 (No payoff in week two):
   “내가 이걸 왜 하고 있지?”라는 의문이 들 때, AI가 내 옛날 결정을 기가 막히게 기억해서 시간을 아껴주는 ‘짜릿한 보상의 순간’을 맛보지 못했기 때문입니다.

이 세 가지 덫에 걸리지 않으려면, 시스템을 복잡하게 만드는 대신 정기적인 ‘청소 규칙’을 세워야 합니다. 이해가 되시나요?

---

STAGE 2 — Unpacking the Core Concept: 몇 달 쓰면 나타나는 4대 마모 현상

시간이 흐르면 볼트에는 반드시 다음 4가지 문제가 발생합니다. 원인을 알면 두렵지 않습니다.

1. 깨진 링크의 누적 (Dead-Link Accumulation)

노트를 쓰다 보면 제목을 바꿀 때가 있습니다. 그러면 그 노트를 가리키던 옛날 [[위키링크]]들이 한순간에 갈 곳을 잃고 끊어집니다.
3개월만 지나면 볼트 안에 이런 시체 링크가 30~50개씩 쌓입니다. 그래프 뷰는 점선투성이가 되고, 링크를 클릭할 때마다 빈 페이지만 떠서 신뢰를 잃게 됩니다.

2. 스키마 부패 (Schema Decay)

2장에서 정한 “최상위 폴더는 딱 5개!”라는 원칙이 슬그머니 무너집니다.
projects/ 안에는 2달 전에 끝났거나 중단된 유령 프로젝트가 7개씩 방치되어 있고, _inbox/는 배수구가 아니라 쓰레기통이 되어 갑니다. 비서(클로드)가 문서를 찾으려고 해도 어디가 활성 작업인지 헷갈리게 됩니다.

3. 프라이버시와 보안에 대한 막연한 공포 (Privacy Concerns)

“내 민감한 회사 문서나 일기가 앤스로픽 서버로 유출되는 것 아니야?”라는 불안감이 엄습합니다.
명확한 사실 관계를 정리해 드릴게요.

• 보관 중인 파일 (At Rest): 100% 여러분의 컴퓨터 하드디스크에만 존재하는 마크다운 텍스트입니다. 인터넷으로 어디에도 전송되지 않습니다.
• 세션 중 읽는 파일 (In Flight): 클로드 터미널을 켜서 문서를 읽히거나 질문할 때는, 그 질문에 포함된 텍스트가 앤스로픽 API로 전송되어 모델의 연산을 거칩니다.

👉 해결책: 법적인 비밀유지(NDA)가 걸린 극비 코드나 극도로 내밀한 개인 일기는 별도의 private-vault로 분리해서 클로드 코드를 아예 열지 마세요. 일반 업무 볼트만 클로드와 함께 쓰면 보안 걱정은 깔끔하게 해결됩니다.

4. 완전 방치 (Abandonment)

결국 관리가 안 되니 옵시디언 아이콘을 누르는 것 자체가 스트레스가 되어 폴더째로 삭제해 버리는 최악의 결말입니다.

---

STAGE 3 — Evidence and Application: 단 20분 만에 끝내는 ‘5대 자가진단표’

이 모든 파멸을 막는 방법은 아주 간단합니다.
매월 첫 번째 주말, 딱 20분 동안 타이머를 맞춰두고 다음 5가지 질문을 던지는 겁니다.

이 표를 인쇄해서 모니터 옆에 붙여두세요. 책의 부록(B1)에 수록된 골든 스탠다드 진단표입니다.

번호	점검 항목 (질문)	위험 기준치 (Threshold)	기준치를 넘겼을 때의 즉각 처방
1	깨진 링크 검사 (부록 B3의 link-check.sh 스크립트 실행)	깨진 링크가 5개 초과	8장의 cross-linker 에이전트를 돌려 추천 링크를 즉시 반영한다.
2	인박스 고임 검사 (_inbox/ 폴더 안의 파일 목록 확인)	생성된 지 7일 넘은 파일이 3개 초과	지금 당장 /process-inbox를 실행해 제자리로 보내거나 아카이브한다.
3	방치된 프로젝트 검사 (projects/ 하위 폴더들 확인)	30일 동안 수정이 없는 프로젝트가 2개 초과	망설이지 말고 해당 폴더 통째로 _archive/projects/로 옮긴다.
4	누락된 연결 검사 (cross-linker 서브에이전트 실행)	링크 추천이 10개 초과	볼트 구조가 느슨해졌다는 뜻. 30분 동안 추천 링크들을 검토하고 승인한다.
5	지침서 신선도 검사 (CLAUDE.md의 최종 수정일 확인)	마지막 수정일이 90일 초과	내 우선순위가 바뀌었을 확률 100%. Active Projects 섹션을 지금 당장 최신화한다.

이 5가지 질문에 답하는 데 10분, 처방을 실행하는 데 10분, 총 20분이면 충분합니다.
진단이 끝나면 그 결과를 _archive/diagnostics/2026-05-01.md라는 파일로 저장해 두세요. 내 두뇌 시스템이 얼마나 건강하게 유지되고 있는지 한눈에 알 수 있습니다.

---

STAGE 4 — Summary and Extension: 연간 6시간의 유지보수 철학

기억하세요. 볼트 시스템을 평생 유지하는 데 필요한 총비용은 다음과 같습니다.

**월간 20분 진단 (20분 × 12개월 = 4시간)

• 분기별 1시간 대청소 (1시간 × 4회 = 4시간 미만)
  = 1년에 고작 6시간!**

1년에 딱 6시간만 투자하면, 매일 아침 45분씩 버려지던 연간 390시간의 낭비를 영원히 막을 수 있습니다. 390시간을 아끼기 위해 6시간을 투자하는 것, 이보다 남는 장사가 어디 있을까요?

여러분의 시스템이 삐걱거리기 시작한다면 당황하지 마세요. 고장 난 것이 아니라, 그저 20분짜리 정기 점검 신호가 켜진 것뿐입니다.

---

[이해도 자가 진단 질문]

1. projects/ 폴더 안에 있는 프로젝트 중 최근 30일 동안 단 한 번도 파일을 열거나 고치지 않은 프로젝트는 어떻게 조치해야 최상위 작업 공간을 깨끗하게 유지할 수 있을까요?
2. 5대 자가진단 항목 중, CLAUDE.md 파일의 수정일이 90일을 넘어갔을 때 가장 먼저 점검하고 최신 정보로 고쳐주어야 하는 핵심 섹션은 무엇일까요?

---

 

[제12강] 앞으로 30일 동안 배포하기 (Ship the Next 30 Days)

여기까지 오신 것을 진심으로 축하드립니다! 우리는 지난 11개의 강의를 통해 5대 폴더 서류함(projects, daily 등)을 세우고, 100줄짜리 지침서(CLAUDE.md)를 쓰고, 5개의 자동 센서(Hooks)와 5가지 단축키(Skills), 3명의 특수 요원(Subagents)을 고용했으며, 2,000개 노트를 견디는 로컬 AI 검색(임베딩)과 20분 자가진단법까지 모두 마쳤습니다.

이 책의 모든 부품을 손에 쥐었을 때, 모든 독자가 던지는 공통적인 질문이 있습니다.
레딧의 r/ObsidianMD와 r/ClaudeAI에 수없이 올라오는 바로 그 질문입니다.

“Best way to use Claude in Obsidian: Claudian vs terminal vs else?”
(옵시디언에서 클로드를 쓰는 최선의 방법은 무엇인가요: Claudian인가요, 터미널인가요?)

많은 사람들이 모든 부품을 한꺼번에 조립하려다 과부하에 걸리거나, 어떤 도구를 최종 인터페이스로 삼아야 할지 망설이다가 멈춰 섭니다.

오늘 본문의 마지막 강의에서는 앞으로 30일 동안 매주 딱 하나의 산출물(Deliverable)만 배포하는 구체적인 행동 캘린더와, 흔들리지 않는 도구 선택의 최종 기준을 확정해 드리겠습니다.

---

STAGE 1 — Why It Matters: 4단계 로켓 추진의 지혜

비유를 하나 들어볼게요. 달에 가는 로켓을 쏠 때, 1단·2단·3단 추진체를 한꺼번에 점화하고 발사하지 않습니다.

• 1단 로켓이 땅을 박차고 올라가고,
• 대기권을 뚫으면 2단 로켓이 켜지며,
• 궤도에 안착한 뒤에야 3단 탐사선이 작동합니다.

세컨드 브레인도 똑같습니다.
책을 다 읽었다고 이번 일요일 밤에 폴더, 훅, 스킬, 서브에이전트, 벡터 DB까지 한꺼번에 세팅해 버리면 어떻게 될까요?
월요일 아침에 작은 스크립트 충돌 하나만 나도 어디가 고장 났는지 찾지 못하고 시스템 전체를 포기하게 됩니다.

11강에서 배운 ‘방치(Abandonment)’의 첫 번째 원인이 바로 ‘초반의 과도한 욕심(Over-engineering early)’이었습니다.
각 단계를 최소 1주일 동안 내 몸으로 굴려보면서 불편함을 느껴야, 다음 단계의 도구가 ‘사치’가 아니라 ‘진짜 내 무기’로 안착합니다. 이해가 되시나요?

---

STAGE 2 — Unpacking the Core Concept: 4주 완성 배포 캘린더

책에서 제시하는 4주 30일 배포 캘린더는 다음과 같이 정밀하게 설계되어 있습니다.

주차	주요 실행 과제	이번 주의 단 하나의 핵심 행동	주간 최종 산출물 (Deliverable)
1주 차 (기본기)	2장 & 4장: 5대 폴더 생성 5장: CLAUDE.md 작성	매일 아침 볼트 안에서 클로드를 켜고 오늘 일지(daily/) 적기	최소 7개의 일일 노트가 쌓인 작동하는 볼트
2주 차 (자동화)	6장: 5대 생명주기 훅 설정 (session-start.sh 등)	SessionStart 훅 정상 작동 확인하기 (아침 맥락 설명 제로화)	파일 수정 시 daily/에 실시간 로그가 남는 자동화 볼트
3주 차 (전력화)	7장: 5대 슬래시 스킬 8장: 3대 서브에이전트 9장: 내 역할 맞춤 주간 회고	금요일 오후 4시에 cross-linker를 돌려 빠진 링크 3개 연결	첫 주간 회고 문서 발행 + wins.md 성과 누적 시작
4주 차 (특화)	10장: 로컬 임베딩 구축 또는 나만의 확장 경로 배포	내가 가장 고통스러웠던 지점의 확장 기능 하나 완성하기	[선택 경로 1개 배포 완료]

---

STAGE 3 — Evidence and Application: 도구의 갈림길과 3대 확장 경로

1. 인터페이스 선택: 터미널 vs 클로디안(Claudian) vs 서드파티 앱

책 서두의 질문에 대한 답은 명쾌합니다.

• 터미널 (claude 직접 실행):
  이미 하루 종일 VS Code나 터미널 창을 띄워두고 일하는 개발자나 테크 지식 노동자에게 최적입니다. 가장 가볍고, 가장 빠르며, 군더더기가 없습니다.
• 클로디안 (Claudian 플러그인):
  터미널 글자만 보면 울렁거리고, 옵시디언 에디터 안에서 마우스로 문서를 편집하며 AI와 대화하고 싶은 기획자, PM, 작가, 프리랜서에게 최적입니다. (깃허브 9,200스타의 YishenTu/claudian을 쓰세요. 볼트 안의 .claude 설정을 그대로 공유하므로 터미널과 언제든 바꿔 탈 수 있습니다.)
• 절대 피해야 할 길 (서드파티 유료 구독 앱):
  “AI 세컨드 브레인을 만들어준다”며 매달 구독료를 요구하는 화려한 웹 서비스들입니다. 여러분의 소중한 데이터를 그들의 서버에 가두는 짓이며, 우리가 이 고생을 해서 로컬 볼트를 만든 이유를 송두리째 부정하는 길입니다.

2. 4주 차에 선택할 ‘3대 확장 경로’

4주 차가 되면 욕심부리지 말고 다음 세 갈래 길 중 딱 하나만 선택하세요.

대부분의 독자에게 가장 가성비가 높은 길은 ‘경로 3(스킬 추가)’입니다.
내 업무에 딱 맞는 전용 단축키(예: /triage-email, /prep-meeting) 5개를 저녁 한 번 투자해서 만드는 것이, 수십 시간 걸리는 인프라 개발보다 훨씬 더 큰 생산성 복리를 가져다줍니다.

---

STAGE 4 — Summary and Extension: 첫 7일의 FAQ와 최종 선언

여러분이 다음 주 월요일부터 겪게 될 가장 흔한 질문 3가지에 대한 명쾌한 해답입니다.

1. “기존에 쓰던 수백 개의 노트를 전부 새 폴더로 옮겨야 하나요?”
   절대 안 됩니다! ’90일 원칙’을 지키세요. 최근 90일 동안 한 번도 열어보지 않은 문서는 통째로 _archive/에 넣고 잊어버리세요. 최근 30일 동안 만진 진짜 중요한 문서만 골라 5대 폴더로 배치해야 시스템이 망가지지 않습니다.
2. “CLAUDE.md의 Active Projects를 매일 고치고 있는데 정상인가요?”
   첫 달에는 정상입니다. 하지만 그 이후에는 일주일에 한 번(금요일 또는 월요일)만 수정해야 합니다. 매일 고치고 있다면 활성 프로젝트가 너무 많다는 뜻입니다. 지식 노동자는 최대 5개, 개발자는 3개 이하로 압축하세요.
3. “스크립트가 터미널에서는 잘 되는데 클로드가 부르면 에러가 납니다!”
   거의 100% 다음 두 가지 이유입니다.
   ① 실행 권한 누락 (chmod +x .claude/hooks/*.sh)
   ② jq 도구 미설치 (brew install jq)

---

[에필로그] 당신의 AI는 이제 모든 것을 기억합니다

12개의 강의 전, 우리는 매일 아침 기억을 잃어버리는 ‘금붕어 비서’와 함께 시작했습니다.
매일 아침 똑같은 5개 단락의 배경을 다시 타이핑하고, 노션에서 복사-붙여넣기를 반복하느라 커피가 식어가던 토요일 아침을 기억하실 겁니다.

우리가 지난 시간 동안 만든 것은 거창한 마법이 아닙니다.
누구나 컴퓨터에 가지고 있는 평범한 5개의 마크다운 폴더(서류함)입니다.

하지만 그 위에 규칙(CLAUDE.md)을 얹고, 자동문(Hooks)을 달고, 단축키(Skills)와 정예 부하(Subagents)를 엮어주는 순간, 평범한 서류함은 세상을 바꿀 AI 세컨드 브레인으로 변신했습니다.

이제 여러분이 터미널을 열면 풍경이 완전히 달라집니다.
클로드는 볼트를 읽고, 여러분이 지금 무슨 프로젝트를 하는지 이미 알고 있으며, 지난주에 내린 결정을 스스로 확인하고 자리에 앉습니다.

여러분이 지불하던 매달 20달러는 이제서야 제 밥값을 하기 시작했습니다.
강의는 끝났습니다. 이제 터미널을 켜고, 여러분만의 멋진 지식 세계를 구축하러 가십시오!

---

[이해도 자가 진단 질문]

1. 4주간의 30일 로드맵에서, 1주 차에 무리해서 훅(Hooks)이나 에이전트(Subagents)를 달지 않고 오직 5대 폴더와 CLAUDE.md로만 일주일 동안 작업해 보기를 강력히 권장하는 이유는 무엇일까요?
2. 4주 차 3대 확장 경로(플러그인, MCP 서버, 추가 스킬 제작) 중, 가장 적은 시간(저녁 한 번)을 들여 일상 업무의 마찰력을 가장 확실하게 줄일 수 있는 최우선 권장 경로는 무엇인가요?

---

 

[부록 종합 특강] 복사해서 바로 쓰는 아티팩트 팩 (The Copy-Paste Artifacts Pack)

우리는 지난 12번의 강의를 거치며 한 번도 본 적 없는 가장 단단하고 똑똑한 ‘AI 세컨드 브레인’의 설계도를 완성했습니다.
하지만 아무리 뛰어난 설계도를 가졌어도, 볼트와 스크립트를 손으로 직접 하나하나 타이핑하다 보면 따옴표 하나를 잘못 닫거나 쉼표 하나를 빼먹어서 에러를 마주하기 십상입니다.

책의 마지막 부록 B4는 이 모든 시스템의 실체를 아주 담담하고 명쾌하게 선언합니다.

“That is the entire surface area of the system. Two dozen files.”
(이것이 시스템의 전체 실체입니다. 딱 24개의 파일뿐입니다.)

그렇습니다. 세상에 수많은 AI 생산성 이론이 넘쳐나지만, 우리가 실제로 컴퓨터에 심어두어야 할 파일은 단 24개의 작은 텍스트 파일이 전부입니다.

오늘 부록 강의는 여러분이 이 24개의 부품을 오타 없이, 고민 없이, 단 몇 분 만에 내 볼트에 안전하게 이식할 수 있도록 돕는 ‘완성형 부품 상자 언박싱’ 시간입니다.

---

STAGE 1 — Why It Matters: 완성형 부품 팩이 필요한 이유

비유를 하나 들어볼게요. 여러분이 이케아에서 아주 튼튼한 5단 서랍장을 샀습니다. 조립 설명서(1~12강)를 완벽하게 이해했다고 해서 볼트와 너트, 경첩을 집에서 쇠를 깎아 직접 만들 필요가 있을까요?

전혀 아닙니다. 상자 안에 동봉된 투명 비닐 팩을 뜯어서, 정해진 구멍에 규격 부품을 꽂고 나사를 조이기만 하면 30분 만에 가구가 완성됩니다.

책의 부록(Appendix A, B, C)이 바로 그 ‘정밀 규격 부품 팩’입니다.

• CLAUDE.md는 몇 줄로 어떻게 나눠 써야 하는지,
• 5개의 훅을 담은 settings.json의 괄호는 어떻게 닫아야 하는지,
• 깨진 링크를 찾아내는 셸 스크립트는 어떻게 짜야 하는지,

고민할 필요가 없습니다. 이미 수개월간 현업에서 구르고 검증된 코드를 그대로 가져다 쓰면 됩니다. 이해가 되시나요?

---

STAGE 2 — Unpacking the Core Concept: 한눈에 보는 볼트 지형도 (24개 파일)

여러분의 터미널 옆 모니터에 띄워두거나 출력해서 붙여둘 ‘단 한 장의 퀵 레퍼런스 카드’입니다.
내 볼트(~/vault)가 완성되었을 때의 최종 모습입니다.

어떤가요? 복잡해 보였던 전체 시스템이 이렇게 한눈에 정리되니 머릿속이 시원해지지 않나요? 이 24개 파일이 서로 맞물려 돌아가며 여러분의 기억을 지켜줍니다.

---

STAGE 3 — Evidence and Application: 부록의 3대 보물 활용법

부록에는 여러분의 시간을 수십 시간 아껴주는 3가지 결정적인 도구가 들어 있습니다.

1. 일체형 settings.json (부록 A2)

6장에서 배웠던 5개의 훅을 하나의 JSON 파일로 합쳐둔 완성본입니다.
볼트의 .claude/settings.json에 그대로 복사해 넣으면 됩니다.

(기억나시죠? 스크립트 파일을 만들고 나면 반드시 터미널에서 chmod +x .claude/hooks/*.sh .claude/hooks/*.py를 쳐서 실행 권한을 주어야 합니다!)

2. 원클릭 링크 검사기: scripts/link-check.sh (부록 B3)

매월 20분 자가진단을 할 때, 볼트 안의 깨진 [[위키링크]]와 상대 경로를 1초 만에 색출해 주는 셸 스크립트입니다.
외부 라이브러리 설치 없이, 순수 bash와 grep, sed 명령어로만 작동합니다.
터미널에서 bash scripts/link-check.sh를 실행하면 다음과 같이 깔끔하게 출력됩니다:

• === Dead wikilinks === (지워진 문서를 가리키는 위키링크 목록)
• === Dead path links === (존재하지 않는 마크다운 경로 링크 목록) 여기서 5개 이상 발견되면? 8장의 cross-linker 에이전트를 돌려 즉시 치유하면 됩니다.

3. 공식 컴패니언 깃허브 저장소 (부록 A6)

“파일 하나하나 복사해서 만들기조차 귀찮다!” 하시는 분들을 위해 저자가 공식 깃허브 저장소를 열어두었습니다.

• 저장소 주소: github.com/regardo911/claude-obsidian-second-brain
• 특징:
  • 챕터별로 파일이 완벽하게 정리되어 있습니다.
  • API 키나 유료 계정 없이 순수 bash, jq, python 환경에서 즉시 동작합니다.
  • 내 볼트를 검사해 주는 자동 진단 스크립트(./chapters/11-diagnostic/vault-diagnostic.sh ~/내볼트경로)가 포함되어 있습니다.

---

STAGE 4 — Summary and Extension: 전체 13강 완강을 선언하며

우리는 서문과 제1장의 ‘금붕어 비서’ 이야기로 시작해서, 마침내 시스템의 마지막 나사 하나까지 모두 조였습니다.

비서와 서류함, 자동 센서 문, 원터치 매크로 다이얼, 독립 조사관, 로컬 의미 투시경, 그리고 비상 수리 키트까지.
이제 여러분의 손에는 전 세계 상위 1%의 AI 파워 유저들이 사용하는 가장 정교하고 실용적인 ‘로컬 AI 세컨드 브레인’이 쥐어져 있습니다.

클라우드 기업이 내 데이터를 엿볼까 봐 두려워할 필요도 없고, 매달 비싼 서드파티 구독료를 낼 필요도 없으며, 월요일 아침마다 AI에게 내 비즈니스를 처음부터 다시 설명할 필요도 없습니다.

모든 지식은 여러분의 컴퓨터 안에 안전하게 머물며, 클로드는 여러분의 든든한 평생 두뇌 파트너로서 함께 나아갈 것입니다.

---

[최종 완강 체크리스트]

오늘 특강을 마치고 책상에서 일어나기 전, 터미널에서 다음 핵심 명령어 3가지를 가볍게 테스트해 보세요.

점검 작업	터미널 입력 명령어	정상 동작 확인 기준
1. 볼트 기동	cd ~/vault && claude	SessionStart가 돌며 활성 프로젝트를 자동 인지하는가?
2. 빠른 수집	/capture 완강 완료 - 내일부터 실전 가동	_inbox/에 오늘 날짜 파일이 3초 만에 생성되는가?
3. 무결성 점검	bash scripts/link-check.sh	깨진 링크 리스트가 오류 없이 터미널에 출력되는가?