나의 노트 정리법(YKM)

노트 정리법을 꽤 오래 찾아다녔다. Zettelkasten, PARA, Bullet Journal, ACE까지 하나씩 써봤다. 각각 분명히 좋은 방법이었다. 그런데 그대로 가져오면 내 생활과 어긋나는 부분이 생겼다.

나는 노트를 쓰는 시간보다 시스템을 고치는 시간이 더 길어지는 순간을 여러 번 겪었다. 폴더를 다시 나누고, 태그를 합치고, 속성을 추가했다가 지웠다. 구조는 점점 정교해졌는데 새 노트를 어디에 둘지는 여전히 어려웠다.

결국 다른 사람의 방법을 하나 더 찾는 대신, 내가 실제로 반복하는 판단을 규칙으로 만들기로 했다. 이름은 You-Know Management, 줄여서 YKM이라고 붙였다. Yoonho를 you know로 읽은 말장난이기도 하다.

YKM은 내가 아는 것을 많이 쌓는 방법이 아니다. 무엇을 어떻게 알게 되었고, 그때의 기록과 지금의 해석을 어떻게 서로 덮어쓰지 않을지를 관리하는 방법이다.

모든 것을 한곳에 넣지 않는 이유

노트에서 보존하고 싶은 것은 정보의 양보다 변화의 경계다.

• 그때 실제로 무슨 일이 있었는가?
• 그때 외부에서 무엇을 만났는가?
• 지금 나는 그것을 어떻게 이해하고 있는가?
• 다른 생각과 어떤 의미로 이어지는가?

이 네 질문을 한 파일에 모두 넣으면 곧 경계가 흐려진다. 외부 자료를 요약한 문장과 내 해석이 섞이고, 과거의 판단을 지금의 결론에 맞게 고쳐 쓰게 된다. 나중에는 무엇이 원문이었고 무엇이 내 생각이었는지 다시 분리해야 한다.

그래서 YKM은 기억의 역할을 나눈다.

분리한다고 연결이 끊어지는 것은 아니다. 오히려 각 파일이 무엇을 책임지는지 분명해지면 링크를 따라갈 때 변화가 더 잘 보인다.

시간축은 언제 다시 고칠지를 본다

노트의 시간은 생성일과 수정일만으로 설명되지 않는다. 내가 중요하게 보는 것은 이 노트에 관심이 언제 다시 돌아오고, 그 갱신이 언제 끝나는가다.

이를 점·선분·반직선으로 생각한다.

네 시간 동안 쓴 회의록도 회의가 끝난 뒤 다시 고치지 않는다면 점이다. 반대로 짧은 글이라도 여러 날 동안 다시 열어 고치다가 마감한다면 선분이다. 중요한 것은 작성 시간이 아니라 관심이 독립적으로 돌아오는 횟수와 끝의 유무다.

Bullet Journal은 시간 순서로 현재를 운영하고, PARA는 시간이 지나며 프로젝트를 Archive로 옮긴다. ACE는 Atlas와 Calendar를 나눠 지식과 시간을 바라본다. YKM도 시간이 노트의 다음 행동을 바꾼다고 생각하지만, 작성 순서나 보관 위치보다 언제 같은 정본을 다시 고치고 언제 닫을지에 초점을 맞춘다.

시간축을 더 자세히 정리한 내용은 노트는 언제 끝날까에 따로 적었다.

공간축은 이 파일을 어떻게 취급할지 정한다

하나의 파일은 한 곳에만 둘 수 있다. 하지만 하나의 노트는 여러 주제와 관련될 수 있다. security이면서 privacy이고 architecture인 노트도 있다.

주제로 폴더를 나누면 셋 중 하나를 골라야 한다. 복사본을 만들면 어느 파일이 정본인지 다시 관리해야 한다. 그래서 YKM에서 폴더는 주제를 설명하지 않는다. 이 파일을 앞으로 어떻게 취급할지만 정한다.

새 노트를 처음 만들 때는 종류를 맞히지 않고 세 질문을 묻는다.

1. 아직 판단이 끝나지 않았는가? 그렇다면 inbox/에 둔다.
2. 외부에서 들어온 자료인가? 그렇다면 sources/에 보존한다.
3. 내가 만든 내용이라면 나중에 계속 고칠 것인가? 그렇다면 notes/, 아니라면 log/에 둔다.

log/에는 별도의 맥락·프로젝트 하위 폴더를 만들지 않는다. 새 기록은 log/ 바로 아래에 두고, 맥락은 파일명과 본문, wikilink와 MOC로 표현한다.

그리고 노트의 이주는 없다. 성질이 달라졌다면 기존 파일이 변신한 것이 아니라 다른 역할의 노트가 새로 생긴 것이다.

• 외부 원문은 sources/에 남기고, 그에 대한 내 해석은 notes/에 새로 쓴다.
• 당시 프로젝트 기록은 log/에 남기고, 반복해서 쓸 원칙은 notes/에 새로 추출한다.
• 검토 전 AI 초안은 inbox/에 두고, 사람이 채택한 내용은 맞는 자리에 새 정본으로 만든다.

두 노트는 wikilink로 연결한다. 이전 캡처가 독립적으로 남을 가치가 없다면 참조를 확인한 뒤 삭제한다. 파일 이동에 의미를 맡기지 않고 각 노트의 역할을 처음부터 끝까지 유지하는 방식이다.

공간축을 만든 과정을 더 자세히 보고 싶다면 노트는 어디에 있어야 할까에서 이어서 볼 수 있다.

폴더가 내려놓은 질문을 나눠 맡긴다

폴더를 단순하게 만드는 것만으로는 충분하지 않았다. 폴더가 내려놓은 질문을 Properties, tags, wikilink, MOC에 정확히 나눠줘야 했다.

Properties는 최소한만 둔다

기본 Properties는 created, tags, sources, aliases 네 개다. created와 tags는 항상 두고, sources와 aliases는 값이 있을 때만 쓴다. 더는 고치지 않지만 탐색·회고 경로로 남길 MOC에만 state: archived를 허용한다.

type, status, confidence, updated 같은 값은 만들지 않는다. 폴더나 파일명, 본문에서 이미 알 수 있거나 실제로 필터하지 않는 값이라면 한 번 더 저장할 이유가 없다. 확신이 낮은 내용은 confidence: low로 감추기보다 본문의 열린 질문에 적는다.

tags는 횡단 주제만 남긴다

태그는 한 노트에 최대 세 개만 쓴다. 소문자 영문 kebab-case를 사용하고 계층 태그는 만들지 않는다. 새 태그를 붙이기 전에는 세 가지를 확인한다.

1. 이 태그로 다시 찾을 노트가 세 개 이상인가?
2. 종류·상태·위치·프로젝트명이 아니라 실제 주제인가?
3. 이 노트가 그 태그에 관한가? 단지 관련만 있는 것은 아닌가?

사람·조직·제품·기술·사건 같은 고유명사는 태그가 아니라 wikilink로 연결한다. 태그는 같은 주제로 결과를 모으는 데는 좋지만, 왜 연결했는지는 말해 주지 못하기 때문이다.

wikilink는 관계를 문장으로 말한다

링크는 많다고 좋은 것이 아니다. 본문 문장 안에서 두 대상의 관계를 설명할 수 있을 때만 만든다.

세션을 서버에 두지 않으면 [[statelessness-in-system-design|수평 확장]]이 쉬워진다.

이 문장은 두 노트가 같은 주제라는 사실보다 무상태성이 수평 확장과 어떤 관계인지 보여 준다. 링크 대상의 제목에 맞춰 문장을 비틀지 않고, 현재 문맥에서 그 대상이 맡는 역할을 드러낸다.

MOC는 색인이 아니라 지도다

태그와 검색은 무엇이 있는지 보여 주지만 무엇부터 읽을지는 알려 주지 않는다. 한 주제를 찾으며 여러 노트를 헤매기 시작했거나, 하나의 태그가 30개를 넘었거나, 프로젝트의 기록과 재사용할 지식을 한 흐름으로 회고하고 싶을 때 atlas/에 MOC를 만든다.

MOC는 읽기 시작점과 현재 위치, 관점이 갈리는 지점을 보여 주는 지도다. 링크마다 그 경로에서 왜 읽는지 한 줄을 쓴다. 같은 노트가 여러 MOC에 나타나도 괜찮다. 파일은 하나지만 읽는 목적은 여러 개일 수 있기 때문이다.

Properties·tags·wikilink의 차이는 속성과 태그, 노트 정보를 표현하는 두 층에서, 링크와 MOC의 관계는 위키링크와 MOC, 관계와 읽기 경로 잇기에서 더 자세히 다뤘다.

실제로는 이렇게 운영한다

YKM의 흐름을 한 번에 쓰면 아래와 같다.

캡처 → inbox/
        ↓ 사람이 판단한다. 파일은 옮기지 않는다.
외부 자료 → sources/에 새 캡처
당시의 사건·활동 → log/에 새 기록
계속 발전시킬 해석 → notes/에 새 글
        ↖ 원래 캡처·source·log와 필요한 관계를 연결
프로젝트에서 재사용 가치가 생기면 → notes/에 원칙 1~3개를 새로 추출
탐색 비용이 커지면 → atlas/에 MOC 작성

주 1회 15분 정도 inbox/를 비운다. 한 달이 넘은 캡처는 정말 지킬 가치가 있는지 다시 보고, 끝난 프로젝트에서는 다시 쓸 원칙 한두 개만 추출한다. 분기마다 한 번만 저빈도 태그와 동의어, MOC가 필요한 큰 태그를 살핀다.

자동으로 모든 것을 롤오버하지 않는다. 다시 읽고 남길 것을 고르는 약간의 마찰이 필터가 되기 때문이다. 시스템의 목적은 모든 것을 보존하는 것이 아니라, 다음에 다시 쓸 수 있는 것과 당시의 기록으로 남길 것을 구분하는 데 있다.

원문·당시 기록·현재 해석을 나누는 구체적인 예시는 원문은 보존하고, 기록은 쌓고, 생각은 연결한다에 적었다.

결국 정리법보다 책임의 경계였다

예전에는 미래의 모든 노트를 설명할 수 있는 폴더 구조를 만들고 싶었다. 지금은 그런 구조가 가능하다고 생각하지 않는다. 주제는 계속 늘고, 관심은 바뀌고, 같은 자료를 다시 읽은 나는 이전과 다른 결론을 내릴 수 있다.

대신 각 수단의 책임을 작게 만든다. 폴더는 취급 방식, Properties는 최소 구조, tags는 횡단 주제, wikilink는 의미 관계, MOC는 읽는 순서를 맡는다. sources/는 남의 말을 지키고, log/는 그때의 나를 남기고, notes/는 지금의 내가 계속 고친다.

YKM이 다른 사람에게도 정답일 것이라고 생각하지는 않는다. 다만 적어도 나는 새 노트를 만들 때 예전만큼 오래 망설이지 않는다. 시스템을 고치는 시간보다 노트를 쓰고 다시 읽는 시간이 조금 더 많아졌다. 지금은 그 정도면 충분하다.

AI가 이 볼트를 다룰 때 쓰는 RULES.md

아래 블록은 AI 에이전트에게 그대로 제공할 수 있도록 YKM의 운영 규칙만 명령형으로 정리한 것이다. 도구에 맞춰 볼트 경로와 검사 명령만 조정하면 된다.

# RULES.md — You-Know Management (YKM)

이 볼트는 원문, 당시 기록, 현재 해석을 서로 덮어쓰지 않고 연결하기 위한 지식 시스템이다.
파일을 수정하거나 만들기 전에 아래 규칙을 따른다.

## 1. 각 수단의 책임

- 폴더는 노트의 취급 방식을 표현한다.
- Properties는 기계가 읽을 최소 구조만 담는다.
- tags는 여러 맥락을 가로지르는 주제만 표현한다.
- wikilink는 대상과 생각 사이의 의미 관계를 문장 안에 표현한다.
- Atlas MOC는 읽기 시작점, 현재 위치, 관점이 갈리는 지점을 안내한다.
- 같은 정보를 둘 이상의 수단에 중복해서 기록하지 않는다.

## 2. 새 노트의 위치

새 노트를 만들기 전에 다음 질문을 순서대로 묻는다.

1. 아직 사람이 판단하지 않은 캡처인가? 그러면 `inbox/`에 만든다.
2. 외부에서 들어온 원문인가? 그러면 `sources/`에 만들고 본문을 임의로 고치지 않는다.
3. 사람이 작성한 내용이라면 앞으로 계속 고칠 글인가?
   - 예: `notes/`에 만든다.
   - 아니오: `log/`에 당시 기록으로 만든다.

- `atlas/`에는 MOC와 진입점만 만든다.
- `_attachments/`에는 이미지와 첨부 파일만 둔다.
- `_system/`에는 규칙, 템플릿, 검사 도구만 둔다.
- 새로운 최상위 폴더를 만들지 않는다.
- 새 `log/` 기록은 `log/` 바로 아래에 만든다. 맥락·프로젝트 하위 폴더를 만들지 않는다.
- 일반적인 `archive/` 폴더를 만들지 않는다.

## 3. 노트의 이주는 없다

- 노트의 성질이 달라지면 기존 파일을 옮기거나 덮어쓰지 않는다.
- 달라진 역할에 맞는 새 노트를 알맞은 위치에 만들고 이전 노트와 연결한다.
- 외부 원문은 `sources/`에 남기고 해석은 `notes/`에 새로 쓴다.
- 당시 사건은 `log/`에 남기고 재사용할 원칙은 `notes/`에 새로 추출한다.
- 이전 캡처를 삭제하기 전에 참조와 독립적인 보존 가치를 확인한다.
- 파일을 삭제하기 전에 해당 파일을 참조하는 wikilink를 먼저 고친다.

## 4. 시간에 따른 수정

- `sources/`와 `log/`는 한 관심 구간이 닫히면 현재 관점에 맞춰 다시 쓰지 않는다.
- 같은 사건이 다시 일어나거나 외부 자료가 바뀌면 새 노트를 만든다.
- `notes/`는 새 근거, 반례, 경험이 생길 때 같은 정본을 계속 갱신한다.
- 종료 조건이 있는 프로젝트 MOC는 종료 뒤 탐색·회고 가치가 있을 때만 `state: archived`로 동결한다.
- 탐색 가치가 없는 노트는 참조를 정리한 뒤 삭제한다.

## 5. Front matter

모든 지식 노트는 YAML front matter를 사용한다.

```yaml
---
created: YYYY-MM-DD
tags: []
sources:
  - "https://example.com/"
aliases:
  - 다른 이름
---
```

- `created`와 `tags`는 필수다.
- `tags`는 항상 배열이며 0~3개다.
- `sources`와 `aliases`는 값이 있을 때만 쓴다. 빈 배열을 남기지 않는다.
- `state: archived`는 더는 고치지 않지만 탐색·회고 경로로 남길 `atlas/` MOC에만 쓴다.
- `type`, `kind`, `status`, `reviewed`, `confidence`, `updated`, `title`, `author` 등 새 프로퍼티를 만들지 않는다.
- 확인하지 못한 사실과 낮은 확신은 프로퍼티가 아니라 본문의 `열린 질문` 절에 쓴다.
- 다음 행동은 상태 프로퍼티가 아니라 본문에 쓴다.

## 6. Tags

- 태그는 이 노트가 실제로 다루는 횡단 주제에만 붙인다.
- 한 노트에 최대 3개만 사용한다.
- 소문자 영문 kebab-case를 사용한다.
- 계층 태그와 본문의 `#해시태그`를 사용하지 않는다.
- 새 태그는 같은 이유로 다시 찾을 노트가 3개 이상일 때만 만든다.
- 폴더 위치, 노트 종류, 상태, 난이도, 프로젝트명을 태그로 만들지 않는다.
- 사람, 조직, 제품, 기술, 사건 같은 고유명사는 태그 대신 wikilink로 연결한다.
- 하나의 태그가 30개를 넘으면 세분화보다 Atlas MOC가 필요한지 먼저 검토한다.

## 7. Wikilinks

- 의미 있는 관계가 있을 때만 링크한다. 최소 링크 수는 없다.
- 링크는 가능하면 본문 문장 안에 두고 관계를 자연어로 설명한다.
- 링크 대상의 제목에 맞추려고 현재 문장을 비틀지 않는다. 필요하면 `[[대상|현재 문맥의 표현]]`을 쓴다.
- 모든 명사를 링크하지 않는다. 반복해서 생각하거나 근거·대조·전제로 사용하는 대상만 연결한다.
- `sources/` 원문은 링크가 없어도 정상이다. 그 원문을 사용한 `notes/`가 관계를 만든다.
- AI가 관련 링크를 제안할 때는 최대 3개까지만 제안하고 억지 연결을 만들지 않는다.

## 8. Atlas MOC

- `atlas/index.md`를 단일 진입점으로 사용한다.
- 한 주제를 찾으며 여러 노트를 헤매거나 태그가 30개를 넘을 때 MOC 생성을 검토한다.
- MOC는 자동 생성 목록이 아니라 사람이 읽을 경로를 설계한 지도다.
- 모든 링크 옆에 그 경로에서 왜 읽는지 한 줄을 쓴다.
- 같은 노트는 읽는 목적이 다르면 여러 MOC에 연결할 수 있다. 원본 파일은 복제하지 않는다.
- MOC끼리 상위·동료 지도로 연결할 수 있다.
- 읽기 시작점, 관점이 갈리는 지점, 아직 없는 반례·사례를 드러낸다.

## 9. AI 협업

- AI는 원문을 임의로 바꾸지 않는다.
- AI가 만든 요약·초안은 기본적으로 `inbox/`에 두고 사람이 검토하게 한다.
- 사용자가 특정 정본의 생성·수정을 명시적으로 요청한 경우에만 해당 파일을 직접 편집한다.
- 사실, 인용, 해석을 구분한다.
- 확인할 수 없는 내용은 확정하지 않고 `열린 질문`으로 남긴다.
- 사실의 확정, 핵심 주장 선택, 프로젝트 의사결정은 사용자에게 남긴다.
- 기존 파일과 사용자 작성 내용을 먼저 확인하고, 관련 없는 내용을 삭제하거나 덮어쓰지 않는다.

## 10. 저장 전 확인

- 새 노트가 처음부터 맞는 폴더에 만들어졌는가?
- 새 `log/` 기록이 `log/` 바로 아래에 있는가?
- 파일명이 볼트 전역에서 유일한가?
- `created`와 배열 형태의 `tags`가 있는가?
- 태그가 3개 이하이며 실제 주제인가?
- 고유명사·종류·상태·위치를 태그로 만들지 않았는가?
- 근거가 있는 노트에 `sources`가 있는가?
- 사실·인용·해석과 열린 질문이 구분되어 있는가?
- 기존 노트를 옮기거나 현재 관점으로 과거 기록을 덮어쓰지 않았는가?
- 삭제 전 참조를 먼저 정리했는가?

가능하다면 저장 후 볼트 검사기를 실행하고, 기존 위반과 이번 변경으로 생긴 위반을 구분해 보고한다.