고급 Obsidian 설정: 개인 지능형 OS 구축하기

AI로 돈 버는 것은 '메모의 양'과 상관없다

먼저, 차분히 이야기해 봅시다.

연수입 1억 엔과 Obsidian 설정 사이에 인과관계가 있다는 연구 결과는 없습니다. "부자만 아는 비밀 플러그인" 같은 것도 없습니다.

제가 말하는 "1억 엔 플레이어"는 방대한 지식을 저장하는 사람이 아닙니다.

그들은 획득한 정보를 다음과 같은 것으로 변환할 수 있는 사람들을 말합니다:

의사결정
협상
채용
투자 판단
제품 설계
콘텐츠
영업 자료
조직 시스템
재사용 가능한 지적 자산

...이것을 극도로 빠른 속도로 해내는 사람들입니다.

일반 Obsidian 사용자는 "무엇을 저장할까"를 고민합니다.

강력한 사용자는 먼저 "미래에 어떤 상황에서, 어떤 질문을 가지고 이 정보를 검색하게 될까?"를 생각합니다.

더 강력한 사용자는 검색된 지식이 결국 어떤 결정이나 결과물로 전환되었는지를 추적합니다.

즉, 여러분이 진짜 설계해야 하는 것은 "두 번째 뇌(Second Brain)"가 아닙니다.

바로 의사결정과 지적 생산을 복리로 증폭시키는 개인 인텔리전스 OS(Personal Intelligence OS)입니다.

Obsidian은 노트를 로컬 Markdown 파일로 저장합니다. Vault는 단순한 폴더이며, 외부 편집기나 스크립트로 변경한 내용이 Obsidian에 반영됩니다. 설정과 플러그인 정보는 .obsidian 폴더에 분리되어 저장됩니다. 즉, Obsidian은 단순한 앱이 아니라 Git, CLI, Claude, Codex로 다룰 수 있는 "지식 저장소"입니다.

이 글에서는 Obsidian의 요소를 다음과 같이 취급합니다:

Obsidian 요소	지식 시스템에서의 의미
Markdown	소스 코드
Properties	타입 시스템
Templates	생성자(Constructor)
Links	의존성(Dependency)
MOC	사람이 편집한 인덱스
Bases	데이터베이스 뷰
Canvas	임시 사고 공간
Skills	재실행 가능한 업무 절차
CLI	외부 에이전트용 API
Git	히스토리, 차이점, 복구
Weekly Review	테스트 및 리팩토링

이 관점에 도달하면 Obsidian 사용 방식이 완전히 바뀝니다.

제1장: 해외 사례 연구—승리 전략은 "정리"가 아닌 "검색"이었다

1. 7명의 연구자 Vault에서 배운 것

브라질 연구소의 전산학 연구자 7명의 Obsidian 사용법을 조사한 2025년 발표 사례 연구가 있습니다.

이 연구의 가장 중요한 교훈은 참가자들이 어떻게 노트를 작성했는지가 아니었습니다.

미래에 어떻게 검색할 것인지에 대한 의도가 노트 작성 및 정리 방식에 강한 영향을 미친다는 사실이 밝혀졌습니다. 참가자들은 검색창, 태그 목록, 텍스트 내 태그, 내부 링크를 각각 다른 목적으로 사용했습니다. 일부 사용자는 작성한 노트를 Inbox에 넣고 일주일에 한 번 처리했습니다.

연구자들이 도출한 설계 제안은 다음 세 가지로 요약할 수 있습니다:

처음부터 완벽한 분류를 요구하지 말고 최소한의 초기 구조를 준비하라.
사용 중에 구조를 변경할 수 있도록 하라.
작성/정리 방법과 미래 검색 방법을 처음부터 연결하라.

즉, "올바른 폴더를 만드는 것"이 문제가 아닙니다.

미래의 자신이 어떻게 검색할지 결정하고, 그 검색 경로에 맞춰 기록하는 것이 중요합니다.

이 점만 봐도 대부분의 일반적인 Obsidian 강좌는 방향이 잘못되었음을 알 수 있습니다.

많은 강좌에서 먼저 폴더, 태그, 플러그인, 외형을 결정하라고 가르칩니다.

하지만 실제로 먼저 결정해야 할 질문은 이것입니다:

세 달 후, 이 정보가 필요할 때 나는 어떤 고민을 하고 있을까?

2. Nicole van der Hoeven—메모를 경력 학습 도구로 만들기

Developer Advocate이자 Performance Engineer로 일하는 Nicole van der Hoeven은 업무에 대한 지속적인 메모 작성이 학습 속도뿐만 아니라 기술 업계에서의 경력에도 긍정적인 영향을 미쳤다고 말합니다.

핵심은 그녀가 "아름다운 지식 데이터베이스를 만들었다"는 것이 아닙니다.

그녀는 업무 중 학습을 기록하고, 이를 공유, 설명, 발표에 재사용합니다.

그녀는 학습 메모를 개인 기록을 넘어 다음과 같은 곳으로 흘려보냅니다:

프레젠테이션
기사
영상
문서
교육 자료
다음 업무

이러한 "인풋에서 아웃풋으로의 전환"이 지식의 경제적 가치를 창출합니다.

3. Bruno Paz—로컬, Markdown, 최소한의 플러그인

소프트웨어 엔지니어 Bruno Paz는 코드 스니펫, 회의록, 프로젝트 사양, 연구 자료, 생활 지식까지 모든 것을 Obsidian에 통합합니다.

하지만 모든 것을 Obsidian에 넣는 것보다 더 중요한 것은 그의 설계 철학입니다.

그는 Markdown의 이식성과 Git을 통한 히스토리 관리를 강조하며, 플러그인 수를 최소한으로 유지하는 정책을 취합니다. 플러그인은 Obsidian을 편리하게 만들지만, 콘텐츠 자체가 특정 플러그인에 너무 의존해서는 안 됩니다.

또한 type과 같은 Frontmatter를 템플릿으로 표준화하고, 관련 노트에 대한 Wikilink를 topics에 넣으며, Bases나 Dataview로 목록화합니다.

여기서 얻는 결론은 명확합니다:

고기능인 것보다 문제가 생겼을 때 Markdown만으로 복구할 수 있는 것이 더 중요하다.

4. Ian O'Byrne—"소비 → 큐레이션 → 창작"으로 정보 흐르게 하기

교육 및 연구 분야에서 Obsidian을 사용하는 Ian O'Byrne은 Vault를 대략 다음과 같은 흐름으로 구성합니다:

Consume: 기사, 책, 논문, 팟캐스트 등 인풋
Curate: 핵심 요점 증류, 관계 연결, MOC 생성
Create: 블로그, 뉴스레터, 교육 자료 등 아웃풋
Meta: Vault 자체의 운영 정보

중요한 것은 폴더 이름이 아닙니다.

정보가 인풋에서 의미 형성을 거쳐 아웃풋으로 이동하는 구조입니다. 그는 플랫폼보다 과정이 더 중요하며, Vault는 필요에 따라 진화한다고 설명합니다.

이러한 해외 사례를 종합하면, 훌륭한 Vault에는 다섯 가지 공통점이 있습니다:

검색 우선—미래의 검색에서 역으로 설계하라
아웃풋 중심—단순 저장이 아닌 결과물로 흐르게 하라
로컬 우선—Markdown을 진실 공급원(Source of Truth)으로 사용하라
최소한의 스키마—입력 필드를 과도하게 복잡하게 만들지 마라
진화적—사용하면서 구조를 변경하라

제2장: "1억 엔 Vault"를 정의하는 여섯 가지 지표

노트 수, 링크 수, Graph의 아름다움은 본질적인 성과 지표가 아닙니다.

저는 Vault의 성능을 다음 여섯 가지 지표로 측정합니다:

1. 캡처 지연 시간(Capture Latency)

아이디어가 떠오른 후 저장하기까지의 시간.

목표는 30초 이내입니다. 입력 시점에 태그, 관련 노트, 저장 위치를 고민하게 만드는 구조는 약한 구조입니다.

2. 검색 시간(Retrieval Time)

필요한 정보에 도달하는 데 걸리는 시간.

일반 정보는 30초 이내, 중요한 의사결정 기록은 60초 이내를 목표로 합니다.

3. 맥락 재구성 비용(Context Reconstruction Cost)

오래된 노트를 볼 때 그 이야기가 무엇에 관한 것인지 복원하는 데 걸리는 시간.

회의 제목만 있는 노트는 약합니다. "배경", "결정", "이유", "전제", "다음 행동"이 보존된 노트가 강력합니다.

4. 결정 추적 가능성(Decision Traceability)

중요한 판단에 대해 나중에 다음을 추적할 수 있는 비율:

왜 결정되었는가
무엇이 기각되었는가
어떤 전제가 있었는가
어떤 조건에서 번복될 수 있는가

5. 아웃풋 전환율(Output Conversion Rate)

저장된 Source Note 또는 Evergreen Note 중 기사, 제안서, 제품, 결정, 회의, 영업 활동에 재사용된 비율.

6. 에이전트 실행 가능성(Agent Executability)

Claude나 Codex가 Vault의 규칙을 오해하지 않고 검색, 제안, 검증할 수 있는 시간 비율.

이를 종합하면, 지식 시스템의 ROI는 다음과 같이 생각할 수 있습니다:

지식 ROI = (재사용된 지식 + 개선된 결정 + 방지된 실패) / 기록, 정리, 유지보수에 소요된 시간

노트 수가 늘어나도 재사용되지 않으면 분모만 커집니다.

제3장: 일본인 사용자에게 쉬운 Vault 구조

처음부터 구축한다면, 저는 이 최상위 구조를 사용하겠습니다:

MyVault/

├── 00_Inbox/

│ ├── AI/

│ └── Clippings/

├── 10_Daily/

│ └── 2026/

├── 20_Projects/

├── 30_Areas/

├── 40_Notes/

│ └── MOCs/

├── 50_Sources/

├── 60_Entities/

│ ├── People/

│ ├── Companies/

│ └── Products/

├── 70_Outputs/

│ ├── Drafts/

│ └── Published/

├── 80_Assets/

├── 90_System/

│ ├── Templates/

│ ├── Bases/

│ ├── Schemas/

│ ├── AgentSkills/

│ └── AI/

├── 99_Archive/

├── scripts/

├── .claude/

├── .agents/

├── .codex/

├── CLAUDE.md

└── AGENTS.md

00_Inbox

분류되지 않은 인풋. 여기서 정리하지 마십시오. 태그는 일반적으로 불필요합니다. "그냥 저장"하는 장소입니다.

10_Daily

시간순 업무 기록. 독립 노트를 만들 가치가 없는 메모, 대화, 깨달음, 진행 상황을 남깁니다.

20_Projects

완료 조건이 있는 활동. "매출 증대"는 Area나 Goal이지만, "2026년 9월까지 기업 요금제 가격 개정"은 Project입니다. Project에는 항상 next_action이 있어야 합니다.

30_Areas

지속적인 책임 영역. 관리, 영업, 채용, 재무, 건강, 가족, 학습 등. Project가 완료된 후에도 Area는 유지됩니다.

40_Notes

장기 재사용을 위한 지식. 단순 발췌가 아닌 자신의 언어로 설명할 수 있는 내용을 여기에 둡니다. "하나의 노트, 하나의 개념"을 엄격히 따를 필요는 없습니다. 일본어에서는 주어와 전제가 생략되기 쉬우므로, 너무 잘게 쪼개면 맥락이 끊어집니다. 기준은 다음과 같습니다:

1 노트 = 미래에 하나의 단위로 재사용하고 싶은 콘텐츠

50_Sources

외부 정보 기록. 책, 논문, 기사, 영상, 회의 자료, 연구 데이터 등. "상대방이 말한 것"과 "내가 해석한 것"을 분리합니다.

60_Entities

사람, 회사, 제품, 고객, 경쟁사, 기술 등의 엔티티. 동일한 사람이나 회사가 여러 프로젝트에 등장하더라도 Entity Note는 하나만 유지합니다.

70_Outputs

기사, 기획 문서, 제안서, 영상 대본, 프레젠테이션, 영업 자료, 제품 사양 등. Outputs를 독립적인 최상위 폴더에 배치하는 것이 중요합니다. 저장만을 목표로 하는 Vault는 지식의 무덤이 됩니다.

90_System

템플릿, Schemas, Bases, AI 규칙, Skills 등 Vault 자체를 운영하는 메커니즘. 이를 구축함으로써 자신의 운영 방식을 설명할 수 있게 됩니다.

하나의 Vault로 할까?

원칙적으로 그렇습니다. Obsidian의 내부 링크는 하나의 Vault 내에서 해결됩니다. Vault를 분할하면 지식 간의 관계가 끊어집니다. 앞서 언급한 연구에서 Vault를 세 개로 나눈 참가자는 검색에 혼란을 겪었다고 보고했습니다.

단, 다음 정보는 물리적으로 분리하십시오:

계약상 외부 AI 입력이 금지된 정보
의료 정보, 개인 식별 번호, 자격 증명
매우 민감한 인사 정보
규제 대상 데이터
조직 정책상 외부 모델에 전달할 수 없는 정보

"개인 Vault"와 "규제 Vault"로 분리한다고 생각하면 됩니다.

제4장: 폴더, Properties, 링크, 태그의 역할을 혼동하지 마라

Obsidian 시스템이 붕괴하는 가장 큰 이유는 폴더, 태그, Properties, 링크를 모두 사용하여 동일한 분류를 표현하기 때문입니다. 각각의 역할을 다음과 같이 고정하십시오:

폴더는 "라이프사이클"을 위한 것

Inbox, Project, Source, Output, Archive 등. 노트가 현재 프로세스의 어느 단계에 있는지를 나타냅니다.

Properties는 "기계가 처리할 타입과 상태"를 위한 것

type, status, created, project, revisit 등. Obsidian Properties는 YAML로 저장되며 text, list, number, checkbox, date, datetime, tags 등의 타입을 가질 수 있습니다.

링크는 "의미적 관계"를 위한 것

[[Pricing Strategy]], [[ABC Corp]], [[Reversibility of Decisions]] 등. 토픽을 태그 대신 노트로 만들면 해당 토픽 자체에 설명, 반증, 참고 자료, MOC를 담을 수 있습니다.

태그는 "임시적인 교차 상태"를 위한 것

#review, #waiting, #question, #contradiction, #publish 등으로 제한하십시오.

"Marketing"이나 "AI" 같은 개념은 가능하면 링크를 사용하십시오. 태그를 개념 사전처럼 사용하면 태그가 난무하게 됩니다(예: #AI, #ArtificialIntelligence, #GenerativeAI). 대신 개념 노트에서 Aliases를 사용하십시오.

제5장: 최소한의 Property 스키마

처음부터 20개 항목을 채우려고 하지 마십시오. 스키마를 세 단계로 나누십시오:

캡처 단계

필수 요소만:
``yaml
type: inbox
created: 2026-07-24
status: inbox
``

승격 단계(Promoted Stage)

장기 보관 가치가 있을 때 추가:
``yaml
type: note
created: 2026-07-24
status: active
topics:
- "[[Pricing Strategy]]"
- "[[B2B SaaS]]"
source_notes:
- "[[SRC Competitor Pricing Research 2026-07]]"
confidence: medium
sensitivity: internal
``

운영 단계

Project나 Decision에 필요한 항목 추가:
``yaml
type: project
created: 2026-07-24
status: active
owner: me
area: "[[Management]]"
due: 2026-09-30
next_action: Compare annual plans of 5 competitors
``

제6장: 일본어 파일명 규칙

일본어 본문이나 제목을 억지로 영어로 바꿀 필요는 없습니다. 단, 기계 처리를 위해 사용하는 Property 이름과 폴더 이름은 ASCII로 유지하십시오. 저는 다음과 같은 명명 규칙을 사용합니다:

Project: PJT Redesign of Corporate Pricing
Decision: DEC 2026-07-24 Make Annual Plan the Standard Proposal
Evergreen Note: Price is Determined by Implementation Failure Risk Rather Than Feature Count

Evergreen Note의 제목은 "카테고리명"이 아닌 "주장(Assertion)"으로 만드십시오. 주장 형태의 제목은 검색 결과만으로도 내용을 떠올릴 수 있게 해줍니다.

제7장: 실제로 포함할 템플릿

Daily Note

"마찰 로그(Friction Log)"를 포함하십시오. "검색했지만 찾지 못한 것"을 기록하면 실제 검색 실패를 기반으로 Vault를 개선할 수 있습니다. 미적 취향이 아닌 실패한 검색에서 구조를 진화시키십시오.

Project Note

Project Note는 태스크의 창고가 아닙니다. 누구나 30초 안에 현재 상태를 파악할 수 있는 프로젝트 사령부(Project Command Center) 입니다.

Decision Note

고수익 업무에서는 정보의 질보다 의사결정의 질이 더 중요합니다. 따라서 Decision Note는 가장 가치 있는 노트 유형입니다. 가장 중요한 필드는 번복 트리거(Reversal Trigger) 입니다. 훌륭한 의사결정자는 결정 당시에 어떤 조건에서 마음을 바꿀지 기록할 수 있는 사람입니다.

제8장: MOC는 "링크 목록"이 아닌 "편집된 사고 모델"

좋은 MOC(Map of Content)에는 편집자의 판단이 담겨 있습니다. 단순한 관련 노트 목록이 아니라, 현재 해당 분야 전체를 어떻게 이해하고 있는지를 압축한 편집된 인지 모델입니다.

제9장: Bases로 "관리 대시보드" 만들기

Obsidian Bases는 노트 Properties를 데이터베이스처럼 표시, 필터링, 정렬할 수 있는 핵심 기능입니다. 이를 사용하여 "활성 프로젝트 Bases"나 "결정 검토 Bases"를 만들어 방치된 판단을 복구하십시오.

제10장: 계층별 플러그인

Tier 0 (핵심만): Properties, Templates, Daily Notes, Bases, Search, Canvas 등.
Tier 1 (마찰이 생길 때): QuickAdd, Templater, Tasks.
Tier 2 (Bases로 충분하지 않을 때만): Dataview.

활성 커뮤니티 플러그인은 12개 이하로 유지하십시오. 각 플러그인의 목적, 대안, 삭제 조건을 기록하십시오.

제11장: 2026년의 결정적 변화—공식 Obsidian CLI

2026년 7월 현재, Obsidian에는 공식 CLI가 있습니다. 터미널에서 데스크톱 버전을 조작할 수 있습니다: 검색, 읽기, 생성, Properties 업데이트, 태스크 확인 등. 이를 통해 Claude와 Codex는 단순히 Markdown을 직접 편집하는 대신 Obsidian 자체의 해석 로직을 사용하여 작업할 수 있습니다.

제12장: AI 네이티브 Vault를 위한 올바른 구조

AI가 모든 노트를 자유롭게 편집하도록 하는 것은 "AI 활용"이 아닙니다. 이는 검증되지 않은 인턴에게 회사의 모든 문서를 넘기는 것과 같습니다. 올바른 역할 분담은 다음과 같습니다:

사람: 목표, 가치 판단, 최종 승인, MOC 편집.
Obsidian: 진실 공급원, 관계, 히스토리, 뷰.
Claude: 의미 증류, 비교, 반론, 초안 작성.
Codex: 구조 변경, 스크립트, 검증, diff 리뷰.
Git: 복구, 감사, 실험 격리.
Validator: 스키마 위반 및 링크 이상 감지.

제13장: CLAUDE.md와 AGENTS.md 배치

Claude Code는 CLAUDE.md를 지속적인 명령어로 읽습니다. Codex는 AGENTS.md를 검색합니다. 이 파일들에 "Vault 운영 계약서"를 배치하여 언어(일본어 문장, ASCII Properties), 안전 규칙(기본 드라이런), 스키마 규칙을 정의하십시오.

제14장: Obsidian 태스크를 Claude를 통해 Skills로 전환하기

세 번 이상 반복하는 작업이나 표준화된 품질이 필요한 작업에 대해 "Agent Skills"을 정의하십시오. 예를 들어, obsidian-distill 스킬은 원시 회의록을 Decisions, Tasks, Evergreen Notes로 변환할 수 있습니다. 좋은 Skill은 명시적인 입력, 절차, 금지 사항, 완료 조건을 갖춘 재실행 가능한 작업 표준입니다.

제17장: Claude, Codex, Obsidian CLI의 협업 패턴

패턴 1: 회의록 증류 (Claude가 결정/태스크 추출).
패턴 2: 주간 관리 리뷰 (Claude가 주간 진행 상황과 지연된 프로젝트 요약).
패턴 3: 스키마 드리프트 감사 (Codex가 Property 불일치 감지).
패턴 4: 결정 전제 감사 (Claude가 과거 결정의 기반이 된 가정이 여전히 유효한지 확인).

이것은 "AI로 노트를 요약하는" 수준을 넘어선 사용법입니다. AI를 과거 자신의 판단을 감사하는 지적 컨트롤러로 사용하는 것입니다.

제18장: Vault 검증기 포함하기

AI가 Vault를 편집하고 있다면 "그럭저럭 괜찮아 보인다"고 만족하지 마십시오. 스크립트(예: vault_check.py)를 통해 허용된 타입, 상태, 필수 Properties를 확인하는 최소한의 정적 테스트를 구현하십시오.