원문은 보존하고, 기록은 쌓고, 생각은 연결한다

옵시디언에 메모를 쌓다 보면 비슷해 보이는 세 가지를 한곳에 넣고 싶어진다. 읽은 글의 내용, 당시 있었던 일, 그리고 그 둘을 연결한 내 생각이다. 나도 예전에는 이것을 한 노트에 담고 태그를 많이 붙이면 나중에 찾을 수 있다고 생각했다.

그런데 시간이 지나면 무엇이 원문이고, 무엇이 그때의 판단이며, 지금도 고쳐야 하는 내 생각인지 구분하기 어려워진다. 그래서 지금은 기록의 역할을 나눈다.

• sources/는 남의 말을 보존한다.
• log/는 그때의 상태를 쌓는다.
• notes/는 내 생각을 계속 고친다.
• wikilink는 파일을 옮기지 않고 관계를 문장 안에 남긴다.

핵심은 많이 분류하는 것이 아니다. 한 사실을 두 곳에 저장하지 않는 것이다.

원문은 sources/에 보존한다

sources/는 내가 쓴 글이 아닌 것을 보관하는 곳이다. 외부 글, 영상, 문서에서 알게 된 내용을 나중에 참고할 수 있도록 남긴다. 이때 중요한 것은 요약을 잘하는 것보다 무엇이 원문에서 온 말인지 보존하는 것이다.

그래서 sources/에 있는 노트의 본문은 고치지 않는다. 참고한 URL이나 출처 한 줄을 남기고, 원문에서 읽은 내용을 보관한다. 지금의 내가 그 내용을 다르게 해석하게 되었다고 해서 과거의 원문 노트를 다시 써 버리면, 출처와 해석의 경계가 흐려진다.

sources라는 이름은 폴더와 Properties에 모두 등장한다. 하지만 역할은 조금 다르다. sources/는 남의 원문을 보존하는 자리이고, sources property는 현재 노트를 뒷받침하는 URL이나 출처 노트를 가리키는 근거 목록이다. 이름이 같다고 하나의 정보를 두 번 적는 것은 아니다.

외부 글을 읽다가 내 생각이 생겼다면 원문 노트에 덧붙이지 않는다. 내가 이해한 내용이나 다른 맥락에 적용한 판단은 별도의 notes/ 노트로 만든다. 그러면 나중에 원문으로 돌아갔을 때 “저자가 말한 것”과 “내가 거기서 가져온 것”을 다시 구분할 수 있다.

log/에는 당시의 상태를 쌓는다

log/는 그때의 사건과 판단을 남기는 곳이다. 회의에서 어떤 이야기가 오갔는지, 프로젝트가 그 시점에 어디까지 왔는지, 투자나 생활에서 어떤 판단을 했는지를 log/ 아래에 기록한다.

로그는 현재의 내가 과거를 다시 평가해 고쳐 쓰는 문서가 아니다. 그때 무엇을 알고 있었고 어떤 선택을 했는지 보존하는 기록이다. 지금 생각이 바뀌었다면 예전 로그를 현재의 결론에 맞게 바꾸기보다, 새 notes/ 노트에서 해석을 이어가는 편이 낫다. 잘못 판단했던 기록도 그때의 상태로 남아 있을 때 회고의 재료가 된다.

그렇다고 임시 메모를 전부 log/에 넣는 것은 아니다. 아직 판단하지 않은 기록은 먼저 inbox/에 둔다. 검토가 끝나면 sources/, log/, notes/ 중 맞는 자리에 새 정본을 만들고 원래 캡처와 연결한다. 캡처의 독립 가치가 없다면 참조를 확인한 뒤 삭제한다. 사건의 맥락 자체를 보존할 이유가 있을 때만 로그가 된다.

프로젝트가 끝났을 때도 같은 기준을 적용한다. 당시의 회의록과 진행 기록은 log/에 남기고, 다른 맥락에서도 다시 쓸 원칙이나 설명만 별도의 notes/로 새로 추출해 기록과 연결한다. 프로젝트 MOC는 종료됐다는 이유만으로 자동 아카이브하지 않는다. 더는 고치지 않지만 관심 영역의 탐색·회고에 유용할 때만 state: archived로 동결한다. 기록과 재사용할 지식을 한 파일에서 계속 섞지 않는 것이 중요하다.

notes/에서 내 생각을 다시 쓴다

notes/는 내가 쓰고 앞으로도 고칠 글을 둔다. 외부 자료를 읽고 내 말로 정리한 설명, 여러 경험에서 공통으로 발견한 원칙, 반례가 생길 때마다 다듬을 개념이 여기에 해당한다.

이 노트들은 한 번 완성하고 닫는 문서가 아니다. 새로운 근거를 만나면 같은 노트로 돌아가 문장을 고치고, 예외를 붙이고, 더 이상 맞지 않는 내용을 걷어낸다. 계속 참조할 생각을 매번 새 파일로 만들면 비슷한 정본이 여러 개 생기기 때문이다.

예를 들어 어떤 글에서 “장애 원인은 이것이다”라는 설명을 읽었다고 해보자. 원문은 sources/에 보존하고, 그때 실제로 겪은 장애나 회의의 판단은 log/에 남긴다. 여러 사례에 적용할 수 있는 원칙으로 정리하고 싶다면 notes/에서 내 말로 다시 쓴다. 세 기록은 같은 주제를 다루지만, 앞으로 어떻게 다룰지가 다르다.

wikilink는 관계를 문장으로 남긴다

태그는 “어느 주제로 다시 찾을까?”에 답한다. 반면 wikilink는 “무엇과 어떤 의미로 이어지는가?”에 답한다. 그래서 모든 링크를 목록처럼 모아 두기보다, 링크가 필요한 문장 안에 맥락과 함께 건다.

세션을 서버에 두지 않으면 [[statelessness-in-system-design|세션 상태를 외부 저장소로 분리해야 한다]].

이렇게 쓰면 링크 대상의 제목을 억지로 문장에 끼워 넣지 않아도 된다. 링크를 따라간 사람도 두 노트가 단순히 같은 단어를 공유해서 연결된 것이 아니라, 어떤 판단으로 이어졌는지 알 수 있다.

고유명사와 개념은 wikilink가 잘하는 대상이다. Kubernetes가 등장했다는 이유로 kubernetes 태그를 하나 더 만드는 대신 [[Kubernetes]]로 연결하면, 그 문장에서 Kubernetes가 원인인지 사례인지 적용 대상인지 설명할 수 있다. 다른 이름을 쓰는 대상은 aliases로 연결할 수도 있다.

다만 “같은 주제면 무조건 wikilink”라는 규칙도 만들지 않는다. 여러 맥락을 가로지르는 주제를 반복해서 검색하려면 태그가 더 적합하다. 반대로 연결할 의미가 없는 원문 노트에는 링크가 없어도 정상이다. 링크의 수보다 다음에 읽을 때 관계를 이해할 수 있는지가 중요하다.

처음 만들 자리를 질문으로 정한다

새 기록을 만났을 때는 노트의 종류를 맞히려 하지 않고, 처음 만들 자리를 정하기 위해 다음 질문을 순서대로 묻는다.

그다음에 다른 노트와 의미 있는 관계가 있으면 본문 안에 wikilink를 만든다. 같은 주제를 자주 함께 읽게 되면 atlas/에 MOC를 만들고, 각 링크를 왜 읽는지 적는다. 폴더는 파일의 취급 방식을 정하고, 링크와 MOC는 파일을 옮기지 않고 다른 읽는 길을 만든다.

가령 Kubernetes 장애를 조사한다고 해보자. 공식 문서의 설명은 sources/, 장애 당시의 회의와 판단은 log/00월00일-장애리포트.md, 여러 장애에 공통으로 적용할 원칙은 notes/에 둔다. notes/의 문장 안에서 [[Kubernetes]]와 관련 개념을 연결하고, 반복해서 읽을 필요가 생겼을 때만 MOC를 만든다. 하나의 노트에 모든 역할을 넣지 않아도 정보 사이의 연결은 오히려 더 선명해진다.

분리한다고 연결이 끊기지는 않는다

예전에는 폴더를 나누면 서로 다른 장소로 흩어지는 것 같았다. 지금은 반대로 생각한다. 원문과 기록과 해석을 한 파일에 섞어 두면 무엇을 고쳐도 되는지부터 다시 판단해야 한다. 역할을 분리하면 각 노트의 수명과 책임이 분명해진다.

sources/는 다른 사람의 말을 지키고, log/는 그때의 나를 남기고, notes/는 지금의 내가 계속 고친다. wikilink는 그 사이의 의미 있는 관계를 문장으로 잇는다. 노트의 공간 축이 파일의 자리를 정하고, 노트의 시간 축이 관심이 언제 돌아오고 닫히는지를 살핀다면, 이 글은 실제 기록을 어디에 보존하고 어떻게 이어갈지에 대한 이야기다.

결국 노트 시스템은 모든 것을 한 번에 설명하는 분류표가 아니었다. 원문은 현재의 생각에 맞게 고치지 않고, 기록은 나중의 결론으로 덮어쓰지 않고, 내 생각만 다음 근거에 맞춰 고치는 것. 지금의 나는 이 구분이 시간을 꽤 많이 돌려준다고 생각한다.