⑤ 지식·업무 시스템 · 선택
수집·생각·프로젝트·레퍼런스를 어떻게 나누나
주제로 나누면 계속 겹친다. 겹치지 않는 축은 수명과 상태 변화다 — 이 노트가 끝나는 일인지, 내 판단인지 외부 사실인지가 자리를 정한다.
무엇을 기준으로 삼나에서 폴더·태그·링크·속성의 자리를 갈랐다면, 그다음 질문은 무엇을 분류하는가다. 여기서 대개 주제를 기준으로 잡는다 — “AI”, “업무”, “개발” 같은 것. 그런데 그렇게 나누면 한 노트가 여러 곳에 걸리고, 걸릴 곳을 고민하는 동안 노트를 안 쓴다.
읽기 전에 한 번 골라보기
회의에서 들은 말, 그걸 읽고 든 생각, 그래서 하기로 한 일. 셋을 한 노트에 적었다면 무엇이 문제일까?
수명이 다른 것을 한 덩어리로 묶은 것이다
하기로 한 일은 며칠 뒤 끝나고, 들은 말은 그때 상황이 지나면 가치가 줄고, 든 생각은 몇 년 뒤에도 유효할 수 있다. 한 노트에 묶으면 가장 짧은 것의 수명에 끌려간다 — 일이 끝나면 그 노트를 다시 안 열고, 그 안의 생각도 같이 묻힌다. 나누는 기준이 주제가 아니라 수명인 이유다.
겹치지 않는 축
주제는 겹친다. 수명과 상태는 겹치지 않는다. 그래서 다음 네 유형으로 나뉜다.
| 유형 | 무엇인가 | 상태가 변하나 | 수명 | 필요한 속성 |
|---|---|---|---|---|
| 수집 | 아직 판단하지 않고 주워온 것 | 아니다 — 처리하면 사라진다 | 며칠 | 없음(들어온 날짜 정도) |
| 프로젝트 | 끝이 있는 일 | 변한다 — 대기·진행·완료 | 몇 주~몇 달 | 상태, 마감일 |
| 레퍼런스 | 외부에서 온 사실 | 아니다 — 다만 낡는다 | 사실이 유효한 동안 | 출처, 확인일 |
| 생각 | 내가 내린 판단 | 아니다 — 갱신된다 | 가장 길다 | 관련 링크(속성보다 링크가 값을 한다) |
이 표에서 실용적인 부분은 오른쪽 두 칸이다. 수명이 다르면 관리 방법이 달라야 하고, 필요한 속성도 달라진다. 넷을 한 폴더에 섞으면 결국 전부 수집처럼 취급된다 — 들어온 순서대로 쌓이고 아무것도 안 나간다.
이 노트는 어느 유형인가
유형을 고르는 세 질문
이 내용에 대해 아직 판단하지 않았나? (일단 주워온 상태)
끝이 있는 일인가? (완료라는 상태가 존재하나)
내용이 내 판단인가, 외부에서 온 사실인가?
수집 — 비우는 것이 목표다
속성을 붙이지 않는다. 폴더 하나로 충분하고, 목표는 쌓는 게 아니라 비우는 것이다. 며칠 안에 다른 유형으로 옮기거나 지운다. 비워지지 않으면 그 자체가 신호다 — 애초에 필요 없던 것이거나, 옮길 유형이 없어서다.
프로젝트 — 상태를 속성으로
상태와 마감일을 속성으로 두면 Bases 로 "진행 중", "이번 주 마감" 같은 목록이 자동으로 만들어진다. 태그로는 이게 안 된다 — 날짜 비교나 정렬이 필요하기 때문이다. 끝나면 상태만 바꾸고, 지우지 않는다.
노트가 쌓이기만 하는 이유 →레퍼런스 — 출처와 확인일을
외부 사실은 낡는다. 출처 주소와 확인한 날짜를 속성으로 남기면 언제 다시 확인해야 하는지 알 수 있다. 이 사이트가 글마다 sources·verified·review_by 를 붙이는 것과 같은 이유다.
생각 — 링크가 속성보다 중요하다
내 판단은 조건으로 걸러 쓸 일이 드물다. 대신 다른 판단과 어떻게 이어지는지가 값을 한다. 그래서 여기는 속성을 최소로 두고 링크를 늘린다. 아직 없는 노트로 미리 링크를 걸어두는 것도 이 유형에서 가장 잘 맞는다.
유형이 정해지면 속성도 정해진다
유형별로 필요한 속성이 다르니, 템플릿을 유형 단위로 두면 입력이 고르게 된다. 아래는 형태의 예시다 — 이 스키마를 그대로 쓰라는 뜻은 아니고, 유형마다 다른 속성이 붙는다는 것을 보여주려는 것이다.
--- 프로젝트 노트
type: project
status: doing # todo / doing / done
due: 2026-08-15
---
--- 레퍼런스 노트
type: reference
source: https://obsidian.md/help/bases
verified: 2026-07-26
---
--- 생각 노트
type: thought
updated: 2026-07-26
# 속성은 이 정도로 줄이고, 본문에서 링크로 잇는다
---템플릿을 쓸 때 문서에 적힌 함정이 하나 있다. Live Preview 에서 Properties 패널이 따옴표 없는 템플릿 변수를 덮어쓸 수 있다. 날짜 변수를 넣었는데 값이 사라지면 이것부터 확인한다 — 따옴표를 쓰거나 Source mode 에서 편집하라고 안내한다.
폴더로 나눌지 속성으로 나눌지
같은 유형 구분을 폴더로도 할 수 있고 type 속성으로도 할 수 있다. 문서에서 확인한 성질로만 비교하면 이렇다.
- 폴더는 노트당 하나뿐이다. 유형은 노트당 하나이므로 폴더와 궁합이 맞다. 파일 탐색기에서 바로 보이는 것도 장점이다.
- 속성은 여러 조건을 조합할 수 있다.
type: project이면서status: doing인 것만 모으는 식이다. Bases 뷰를 쓸 계획이라면 속성이 필요하다.
둘을 같이 쓰는 것도 가능하다 — 폴더로 나누고 type 속성도 넣는 것. 다만 두 곳에 같은 정보가 생기니 한쪽이 틀어지면 목록이 어긋난다. 어느 쪽을 진실로 삼을지는 정해두는 게 낫다. 이건 확인된 사실이 아니라 판단이고, 실제로 어긋나봐야 어느 쪽이 편한지 알 것이다.
아직 해보지 않은 것
- 네 유형이 실제로 맞는 개수인지 — 운영해보면 줄거나 늘 수 있다
- 수집을 며칠 안에 비우는 게 현실적인지
- 프로젝트가 끝난 뒤 그 안의 판단을 생각 노트로 옮기는 작업이 유지되는지
- 폴더와
type속성을 같이 쓸 때 실제로 얼마나 어긋나는지
특히 세 번째가 이 구조의 약한 고리로 보인다. 일이 끝나면 대개 정리하지 않고 넘어가는데, 그러면 프로젝트 노트와 함께 판단도 묻힌다. 이건 규칙으로 되는 일이 아닐 수도 있다.
이 문서를 덮어도 되는 시점
지금 열려 있는 노트 하나를 위 세 질문에 통과시켜 유형을 정하고, 그 유형에 필요한 속성만 남기면 된다. 네 유형을 전부 만들 필요는 없다 — 프로젝트와 수집 두 개로 시작해도 된다.
- 초안 작성(근거: 조사·정리). 분류 기준을 주제에서 수명·상태로, 네 유형과 유형별 속성, 폴더 대 type 속성 비교. 실사용 검증 없음 (성숙도: 탐색 중)
- 운영해본 뒤 — 유형 개수 조정, 수집 비우기의 현실성, 끝난 프로젝트에서 판단을 건져내는 방법