노트는 어디에 있어야 할까

노트를 쓰다 보면 결국 이 질문을 만나게 된다.

“이 노트는 어디에 두어야 하지?”

나도 이 질문 때문에 폴더를 꽤 자주 바꿨다. 개발 폴더를 만들었다가 프로젝트 폴더로 옮기고, 생산성에 관한 노트인지 PKM에 관한 노트인지 고민했다. 새 구조를 만들 때마다 이번에는 오래 쓸 수 있을 것 같았다. 그런데 노트가 늘어나면 경계가 다시 흐려졌다.

지금 생각하면 폴더가 부족했던 것이 아니다. 폴더에 너무 많은 질문을 맡기고 있었다.

공간을 주제로 나눈 것이 문제였다

파일은 동시에 여러 폴더에 있을 수 없다. 하나의 노트에는 하나의 경로만 있다.

그런데 주제는 그렇지 않다. 옵시디언 보안 설정을 정리한 노트가 있다고 해보자. 이 노트는 obsidian에 관한 글이면서 security와 privacy에도 걸쳐 있을 수 있다. 주제로 폴더를 나누면 셋 중 하나를 골라야 한다.

복사해서 여러 곳에 둘 수도 있다. 그러면 곧 다른 문제가 생긴다. 어느 파일이 정본인지, 어디를 고쳐야 하는지 판단해야 한다. 파일을 하나만 남기면 선택하지 않은 주제로 들어오는 길이 끊긴다.

폴더에 넣기 어려운 노트가 계속 생긴다면 분류가 덜 세밀해서가 아닐 수 있다. 애초에 여러 답을 가질 수 있는 질문을, 하나의 답만 허용하는 도구에 맡긴 것일 수 있다.

폴더는 하나의 질문만 답한다

그래서 공간 축을 다시 정했다. 주제가 아니라 이 노트를 어떻게 취급할 것인가를 폴더가 답하도록 했다.

내 볼트에서는 노트가 어디에서 왔고 앞으로 어떻게 다룰지에 따라 자리를 나눈다.

이 기준도 완벽한 분류법은 아니다. 다만 security인가?, privacy인가? 보다 답하기 쉽고, 시간이 지나도 비교적 덜 흔들린다. 주제는 계속 늘고 하나의 노트가 여러 주제와 관련되지만, 노트가 어디에서 왔고 앞으로 어떻게 취급할지는 더 적은 선택지로 남기 때문이다.

폴더는 노트가 실제로 놓이는 한 위치다. 태그·위키링크·MOC는 그 파일을 복제하지 않고도 다른 관점에서 다시 보게 한다.

주제는 위치가 아니다

여기서 중요한 것은 폴더를 줄이는 것만이 아니다. 폴더가 내려놓은 질문을 다른 수단에 정확히 나눠줘야 한다.

태그는 “어느 주제로 다시 찾을까?”에 답한다. 한 노트에 여러 태그를 붙일 수 있으니 다중 소속을 표현하기 좋다. 다만 태그가 많아지면 다시 분류 체계가 되기 때문에, 실제로 함께 볼 가치가 있는 횡단 주제만 남긴다.

위키링크는 “무엇과 어떤 의미로 이어질까?”에 답한다. Node.js나 Kubernetes처럼 이름이 있는 대상은 태그보다 링크가 자연스럽다. 중요한 것은 링크의 수가 아니라 왜 연결했는지를 문장 안에 남기는 일이다.

속성과 태그를 실제로 어떻게 나눠 쓰는지는 속성과 태그 글에서, 의미 관계와 읽기 경로를 만드는 방법은 위키링크와 MOC 글에서 이어서 정리했다. 원문·당시 기록·내 생각을 실제로 나누는 기준은 sources, log, wikilink 글에서 더 자세히 다뤘다.

MOC(Map of Content)는 “어떤 순서로 읽을까?”에 답한다. 검색 결과를 한 번 더 나열하는 색인이 아니라, 읽기 시작점과 관점이 갈리는 곳을 보여 주는 지도다. 링크마다 그 경로에서 왜 읽는지 적는다. 같은 노트가 여러 MOC에 연결되어도 파일은 여전히 하나다.

노트의 이주는 없다

공간축을 정리하면서 가장 오래 남은 문제는 inbox/였다. 검토가 끝난 캡처를 sources/, notes/, log/ 중 어디로 옮길지 정하면 되는 것처럼 보였다. 그런데 파일 이동에 의미를 맡기면 한 파일이 성질까지 바꾸는 셈이 된다.

지금은 더 단순하게 생각한다. 노트의 이주는 없다. 성질이 달라져 다른 폴더가 필요하다면, 달라진 성질에 맞는 노트를 그 자리에 새로 만든다.

• 검토 전 캡처는 inbox/에 남기고, 채택한 생각은 notes/에 새로 쓴다.
• 외부 원문은 sources/에 남기고, 그 원문에 대한 내 해석은 notes/에 새로 쓴다.
• 프로젝트의 당시 기록은 log/에 남기고, 반복해서 쓸 원칙은 notes/에 새로 추출한다.

새 노트와 이전 노트는 위키링크로 이어 둔다. 이전 캡처가 변화 과정이나 출처를 보여 줄 가치가 있다면 남기고, 독립적인 가치가 없다면 참조를 확인한 뒤 삭제한다. 주제가 바뀌었다는 이유만으로 파일을 옮기거나 복제하지 않는다. 주제의 추가·삭제는 태그와 링크의 일이지 파일 이동의 이유가 아니다.

이 원칙에서 가장 조심할 곳은 inbox/다. 인박스는 아직 정하지 못한 것을 받기 때문에 쉽게 창고가 된다. 30일 안에 검토하고, 맞는 자리에 새 정본을 만들거나 버린다. 인박스 파일 자체를 오래 보관하는 것으로 결정을 미루지 않는다.

폴더가 단순해지니 쓰는 일이 남았다

예전에는 애매한 노트를 만날 때마다 새 폴더가 필요하다고 생각했다. 지금은 질문을 바꾼다.

이 노트를 어떻게 다룰 것인가. 어느 주제로 찾고 싶은가. 무엇과 연결되는가. 어떤 순서로 다시 읽을 것인가.

각 질문을 폴더, 태그, 위키링크, MOC가 하나씩 맡으면 구조를 크게 고칠 일이 줄어든다. 새 주제가 생겨도 폴더를 추가할 필요가 없고, 하나의 노트가 여러 관심사에 걸쳐 있어도 복사본을 만들지 않는다. 파일의 자리는 하나지만, 의미 있는 관계는 문장 안에서 여러 방향으로 이어질 수 있다.

결국 내가 원한 것은 모든 노트를 완벽하게 설명하는 폴더 구조가 아니었다. 노트를 쓸 때 망설이지 않고, 나중에 고칠 곳이 하나뿐인 구조였다.

공간 축은 노트의 의미 전체를 설명하지 않는다. 그저 이 파일을 어떻게 취급할지 정한다. 오히려 그 정도만 맡길 때 폴더는 오래 쓸 수 있는 도구가 되는 것 같다.