Hako의 기획 with AI

Obsidian 최소 볼트 구조

15 min read

B4. Obsidian 최소 볼트 구조

이 부록은 입력과 연결과 재사용이 막히지 않는 최소 볼트 구조를 보여준다.

볼트를 처음 만들면 가장 먼저 생기는 충동이 있다.

완벽한 폴더 구조를 만들고 싶어진다. 카테고리를 나누고, 하위 폴더를 만들고, 명명 규칙을 정하고, 모든 경우를 커버하는 구조를 설계하려 한다. 일주일 뒤에는 폴더 구조가 완성됐는데 노트는 10개가 안 된다.

구조를 설계하는 것이 목적이 되면 이렇게 된다.

볼트 구조의 목적은 하나다. 정보가 들어오고, 처리되고, 꺼내 쓰이는 흐름이 막히지 않게 하는 것이다. 그 목적에 맞는 최소한의 구조만 있으면 된다.

[도식: fig-minimum-vault-flow] — inbox에서 projects, areas, resources, archive로 흘러가는 최소 볼트 흐름

PARA 기반 5폴더 + inbox

이 책에서 쓰는 볼트 구조는 Tiago Forte의 PARA를 기반으로 기획자 업무에 맞게 조정한 것이다.

PARA는 디지털 정보를 Projects / Areas / Resources / Archives 4가지로 분류하는 방법론이다. 이 책에서는 여기에 inbox를 추가해 5폴더로 시작한다.

볼트 루트/
├── 00.inbox/          ← 분류 전 모든 것이 들어오는 완충 구간
├── 10.projects/       ← 현재 진행 중인 프로젝트 (마감 있음)
├── 20.areas/          ← 지속적으로 관리하는 영역 (마감 없음)
├── 30.resources/      ← 재사용 가능한 지식 자산 (영구 지식)
└── 90.archive/        ← 완료되거나 비활성화된 것들

PARA의 핵심 구분은 활성도다.

  • Projects: 지금 진행 중이고 마감이 있다
  • Areas: 지속적으로 유지해야 하는 책임 영역 (서비스 담당 영역, 팀 운영 기준 등)
  • Resources: 특정 프로젝트와 관계없이 언제든 꺼내 쓸 수 있는 지식
  • Archive: 완료됐거나 더 이상 활성이 아닌 것

5폴더가 처음에 필요한 전부다. 하위 폴더는 실제로 필요해졌을 때 만든다. 처음부터 채울 필요 없다.

각 폴더의 역할

00.inbox — 모든 것이 처음 들어오는 곳

분류를 결정하지 않아도 일단 넣는 곳이다. 인터뷰 후 빠른 메모, 회의에서 떠오른 아이디어, 나중에 정리할 자료. 분류를 결정하는 데 시간이 걸리면 기록 자체를 안 하게 된다. 일단 inbox에 넣고 나중에 처리한다.

처리 주기는 주 1회면 충분하다. inbox가 30개 이상 쌓이면 처리 주기를 앞당긴다.

10.projects — 진행 중인 프로젝트

현재 진행 중인 프로젝트별로 하위 폴더를 만든다. 프로젝트가 완료되면 90.archive로 이동한다. 이 폴더는 “지금 내가 집중하는 것”을 담는다.

10.projects/
├── 검색기능개선/
│   ├── _MOC-검색기능개선.md    ← 프로젝트 인덱스
│   ├── prd-검색기능개선-v1.md
│   ├── dec-2026-03-14-정렬방식.md
│   └── ev-2026-03-10-사용자조사.md
└── 온보딩개선/

프로젝트가 완료되면 폴더째 90.archive로 이동한다. 단, Evidence Note, Decision Log처럼 재사용 가능한 지식으로 전환할 수 있는 것은 30.resources로 먼저 옮긴다.

20.areas — 지속 관리 영역

프로젝트는 끝나면 archive로 간다. 하지만 내가 지속적으로 담당하는 영역은 프로젝트가 끝나도 계속 관리해야 한다. 이것이 Areas다.

기획자에게 Areas의 전형적인 예:

  • 담당 서비스 도메인 (검색, 결제, 추천 등)
  • 이해관계자 목록과 관계 이력
  • 팀 운영 기준, 협업 방식
  • 내가 지속적으로 발전시키는 방법론

이 폴더의 내용은 특정 프로젝트가 끝나도 살아있다. “이 사람과 어떻게 협업해왔는가”는 프로젝트를 넘어 누적된다.

30.resources — 재사용 가능한 지식 자산

언제든 꺼내 쓸 수 있는 영구 지식이 여기 들어간다. 방법론 노트, 도메인 개념, 기술 용어, 업계 표준. 특정 팀이나 프로젝트에 종속되지 않는다.

재사용 지식을 어떤 축으로 분류할지는 이 책의 맥락 / 도메인 / 기술이해 / 관계 구조와 Knowledge Tree 설명을 바탕으로 정한다. Knowledge Note는 그 기준에 따라 여기 쌓인다.

30.resources/
└── {내 지식 축}/   ← 책의 분류 기준에 맞게 직접 정한다

90.archive — 완료되거나 비활성화된 것들

완료된 프로젝트 폴더, 더 이상 활성이 아닌 Areas 항목. 삭제하지 않고 archive에 넣는다. Decision Log처럼 번복된 결정의 원본은 여기서도 삭제하지 않는다. 과거 판단 이력이 자산이다.

파일명 규칙

파일명이 일관되지 않으면 검색할 때 찾기 어렵다. 최소한의 규칙을 정한다.

객체 유형파일명 형식예시
Decision Logdec-YYYY-MM-DD-키워드.mddec-2026-03-14-정렬방식변경.md
Evidence Noteev-YYYY-MM-DD-키워드.mdev-2026-03-10-검색사용자조사.md
Problem Briefpb-YYYY-MM-DD-키워드.mdpb-2026-03-01-검색불만원인.md
PRDprd-키워드-v버전.mdprd-검색기능개선-v1.md
MOC_MOC-키워드.md_MOC-검색기능개선.md
일반 노트키워드-설명.md리뷰-RICE프레임워크.md

규칙의 핵심은 두 가지다. 날짜가 앞에 있으면 시간 순 정렬이 자동으로 된다. 객체 유형 접두사(dec-, ev-, pb- 등)가 있으면 검색할 때 타입 필터가 가능하다.

메타데이터 최소 항목

Properties에 처음에 필요한 최소 필드다.

---
object_type: decision-log   # 객체 유형
status: draft               # draft / confirmed / archived
created: 2026-03-14        # 생성 날짜
project: 검색기능개선        # 연관 프로젝트
---

4개로 시작한다. 이 4개가 있으면 Dataview로 “confirmed 상태인 결정 전체”, “검색기능개선 프로젝트의 모든 객체” 같은 동적 목록을 만들 수 있다.

나중에 필요에 따라 추가한다. tags, impact, reliability, step_link 같은 것들은 시스템이 자리를 잡은 뒤에 붙인다.

inbox에서 자산화까지 흐름

노트 하나가 볼트 안에서 어떻게 흘러가는가.

(새 정보 입력)
      ↓
 00.inbox/  ← 분류 결정 전. 일단 여기 (Daily Note에서 수집된 것도 포함)
      ↓ (주 1회 처리)
      ├─ 특정 프로젝트의 결정/근거 → 10.projects/{프로젝트}/로 이동
      │   Evidence Note, Decision Log, PRD 형태로 변환
      │
      ├─ 지속 관리할 이해관계자·서비스 영역 → 20.areas/로 이동
      │
      ├─ 재사용 가능한 용어·개념·방법 → 30.resources/{KT축}/으로 이동
      │   Knowledge Note 형태로 정제
      │
      └─ 임시 메모였음 → 삭제 또는 inbox 유지

처음에 모든 것을 제자리에 넣으려 하면 기록 자체가 느려진다. inbox가 중간 완충 역할을 한다. 기록 속도와 정리 품질을 분리하는 것이다.

이 판단 흐름의 핵심은 단순하다. 입력이 들어왔을 때 프로젝트 맥락인지, 지속 관리 영역인지, 재사용 지식인지 먼저 구분하는 것이다. 지금은 “어디에 넣을지 결정하는 것이 곧 기획 맥락을 해석하는 일”이라는 점만 잡으면 충분하다.

과설계 방지 기준

볼트를 더 복잡하게 만들고 싶어질 때 다음 기준으로 결정한다.

폴더를 추가할 때: 실제로 노트가 10개 이상 쌓일 것 같을 때만 만든다. “이런 노트가 생길 수도 있으니까”로 미리 만들지 않는다.

Properties 필드를 추가할 때: 이 필드가 없어서 찾기 어려운 상황이 실제로 발생했을 때 추가한다. “나중에 필요할 것 같아서”는 아직 추가하지 않는다.

플러그인을 추가할 때: 지금 작업 흐름에서 구체적인 불편함이 생겼을 때 설치한다. “유용할 것 같아서”가 이유면 나중으로 미룬다.

설계를 늘리는 것은 언제든 할 수 있다. 처음에 단순하게 시작해서 실제로 필요해지면 추가하는 것이 유지 가능한 구조를 만드는 방법이다.

기존 자료 처리

볼트를 새로 만들면 “기존에 쌓아둔 자료들을 다 옮겨야 하나?”는 고민이 생긴다.

한 번에 다 옮기려 하지 않는다.

지금 진행 중인 프로젝트 관련 자료만 먼저 옮긴다. 그것도 전부가 아니라 최근 2~3개월치만. 오래된 자료는 필요해지면 그때 가져온다. 처음부터 완전한 볼트를 만들려 하면 이전 작업만 하다가 현재 작업이 멈춘다.

볼트는 오늘부터의 기획 업무를 위한 도구다. 과거 자료 보관소가 아니다.

기획자의 판단과 연결되는 지점

볼트 구조를 결정하는 것은 파일 정리 방법을 고르는 게 아니다. 이 정보가 지금 내 기획에서 어떤 위치에 있는가를 판단하는 훈련이다.

inbox에 넣는 것과 projects에 넣는 것, resources로 분류하는 것은 모두 다른 판단이다. “이건 지금 진행 중인 결정에 연결된다”(projects), “이건 다음 프로젝트에서도 쓸 수 있다”(resources), “아직 어디 속하는지 모르겠다”(inbox). 파일 하나를 놓을 때 이 판단을 반복하면서 기획자는 자신의 지식 지형을 감각한다.

이 구조가 자리를 잡으면, 나중에 어떤 기획 결정 앞에서도 “이게 어디 있더라”가 아니라 “이걸 어디에 연결할까”를 먼저 생각하게 된다. 저장이 목적이었던 것이 연결이 목적으로 바뀌는 순간이다.

PARA 원본과의 차이

PARA 원본은 Projects / Areas / Resources / Archives 4개 폴더다. 이 책에서는 두 가지 조정을 했다.

inbox 추가: PARA 원본에는 빠른 수집을 위한 inbox가 없다. 기획자의 실제 업무에서는 분류를 결정하지 않고 일단 수집하는 단계가 반드시 필요하다. Daily Note와 inbox가 함께 작동한다.

resources 명칭: PARA의 Resources는 “언젠가 유용할 수 있는 참고 자료”에 가깝다. 이 책에서는 “현재 실제로 쓰고 있는 재사용 가능한 지식”으로 좁게 정의한다. 막연히 저장하는 것이 아니라 KT 축 기반으로 분류된 지식이 여기 들어온다.

이 두 가지를 제외하면 PARA 구조를 그대로 따른다. PARA로 이미 구성된 볼트가 있다면 그 위에 inbox만 추가해도 이 책의 실습을 따라갈 수 있다.

이 구조는 처음부터 완벽하게 만들 필요가 없다. 폴더 5개와 첫 노트 몇 개만 있어도 책의 나머지 흐름을 따라갈 수 있다.

그래프 뷰