노트는 언제까지 고쳐야 할까

노트를 정리하면서 주로 고민한 것은 어디에 둘 것인가였다. 그런데 폴더를 어느 정도 정리하고 나니 다른 질문이 남았다.

“이 노트는 언제까지 고쳐야 하지?”

모든 노트를 계속 다듬으면 그때의 기록이 사라진다. 반대로 한 번 쓴 노트를 전부 그대로 두면 새로 알게 된 사실과 생각이 여기저기 흩어진다. 생성일과 수정일은 남아 있지만 날짜만으로는 다음 행동을 정하기 어려웠다.

그래서 노트를 시간축 위에 놓아 보기로 했다. 중요한 것은 언제 만들었는지가 아니라 관심이 언제 다시 돌아오고, 언제 닫히는가였다.

• Bullet Journal: 시간축을 기준으로 노트가 배치된다. 다른 노트를 보려면 시간축을 거슬러 올라가야 하고 인덱스 페이지에 의존해야 한다.
• PARA Method: 만료된 프로젝트와 무관심해진 영역들을 archive 폴더로 이동 시킨다. 즉 시간의 변화에 따라 공간이 뒤틀린다.
• ACE Framework: 시간과 공간이 분리되어 있다. 내 설계와도 비슷하다고 느꼈다. 다만 나는 Atlas와 Calendar가 atlas+notes+sources와 logs로 분리되어 있다.

세 방법의 공통점은 삶의 영역에서 행동의 변화까지 이끌어낸다. 그런 부분에서 긍정적인 효과가 있으나 현재 내가 다루고자 하는 내용과는 핀트가 조금 다르다.

생성일 하나로는 노트의 시간을 설명할 수 없다

파일에는 생성일이 있다. 옵시디언에서도 날짜를 속성으로 남길 수 있고, 파일 시스템에는 마지막 수정 시각이 기록된다. 처음에는 이 정도면 노트의 시간을 충분히 설명한다고 생각했다.

그런데 같은 날 만든 노트라도 살아가는 방식은 다르다.

회의록은 회의가 끝나면 그날의 기록으로 남는다. 인박스에 적어둔 메모는 며칠 동안 검토하다가 다른 노트가 되거나 사라진다. 내가 계속 사용하는 원칙이나 개념 노트는 몇 년 뒤에도 새로운 근거가 생기면 다시 고친다.

셋은 생성일이 같아도 다시 관심을 기울이는 방식이 다르다. 결국 노트의 시간은 날짜 하나보다 독립적인 관심과 갱신이 이어지는 구간에 가깝다.

시간 형태를 정한 뒤 실제 파일을 어느 공간에 둘지는 공간축 글에서 이어서 다룬다.

점, 선분, 반직선

점·선분·반직선은 시간을 정확히 재는 수학 모델이 아니다. 노트를 어느 폴더에 둘지 강제하는 분류표도 아니다. 한 노트에 관심이 돌아오는 모양을 비교하기 위한 운영 비유다.

점({t₀})은 한 번의 관심 구간 안에서 작성과 마감이 함께 일어나고, 이후 독립적인 갱신 회차가 없는 노트다. 회의록, 당시의 판단을 남긴 로그, 나중에 참조하기 위해 보관한 외부 원문이 여기에 가깝다.

점이라고 해서 작성 시간이 0이라는 뜻은 아니다. 네 시간짜리 회의 중 회의록을 계속 고쳤더라도, 회의와 직후 정리라는 한 번의 관심 구간이 닫힌 뒤 다시 갱신하지 않는다면 점이다. 반대로 짧은 문서라도 며칠 뒤 다시 열어 고치고 마감한다면 선분에 가깝다.

선분([t₀, t₁])은 서로 다른 시점에 다시 관심을 기울여 갱신하지만 종료 조건이 있는 노트다. 판단을 기다리는 조사 초안과 종료 시점이 있는 프로젝트 MOC가 여기에 가깝다.

선분에서 중요한 것은 오른쪽 끝이다. 인박스 캡처는 기한 안에 검토하고 새 정본을 만들거나 삭제한다. 프로젝트 MOC는 프로젝트가 끝났다는 이유만으로 자동으로 state: archived가 되지 않는다. 더는 고치지 않지만 관심 영역의 탐색·회고 경로로 계속 유용할 때만 동결 상태로 남긴다. 탐색 가치도 없다면 참조를 정리한 뒤 삭제한다.

반직선([t₀, ∞))은 시작은 있지만 미리 정한 끝이 없는 노트다. 내가 계속 사용하는 원칙, 개념, 관심사 MOC가 여기에 가깝다. 내 볼트에서는 주로 notes/가 이 역할을 맡는다.

반직선이라고 매일 고친다는 뜻은 아니다. 몇 달 동안 손대지 않을 수도 있다. 다만 새로운 통찰이나 반례, 변경된 사실을 만났을 때 같은 노트를 다시 열어 고칠 수 있다. 관심이 돌아올 가능성을 미리 닫지 않은 것이다.

시간축은 폴더 분류표가 아니다

같은 주제의 노트도 서로 다른 시간 형태를 가질 수 있다.

예를 들어 한 프로젝트의 보안 회의록은 점이다. 프로젝트가 진행되는 동안 사용하는 보안 체크리스트는 선분일 수 있다. 여러 프로젝트에서 계속 다듬어 쓸 보안 원칙은 반직선에 가깝다.

그래서 회의록, 보안, 개념 같은 노트 종류를 하나 더 저장한다고 문제가 해결되지는 않았다. 종류는 무엇에 관한 노트인지 설명하지만, 언제 관심을 닫고 다시 열지는 알려주지 않는다.

나는 별도의 lifecycle 속성을 모든 노트에 붙이지 않기로 했다. 폴더 구조가 시간 형태를 암시할 수는 있지만, 점·선분·반직선을 폴더나 속성에 강제로 저장하지 않는다. created는 만든 날이고 file.mtime은 마지막 수정 시각일 뿐이라 과거의 관심 회차 전체를 보여 주지도 못한다. 이 구분은 정밀한 편집 로그가 아니라 앞으로 그 노트를 어떻게 다시 다룰지 생각하기 위한 모델이다.

오른쪽 끝을 정하지 않으면 생기는 일

시간 형태를 나눈 뒤 가장 크게 달라진 곳은 인박스와 로그였다.

예전에는 인박스의 메모도 언젠가 쓸 수 있다는 이유로 오래 남겨두곤 했다. 하지만 선분에는 끝이 있어야 한다. 검토해서 내 생각으로 발전시킬 수 있으면 notes/에 새 노트를 만들고, 외부 자료라면 sources/에 새 캡처를 만든다. 원래 인박스 캡처는 독립 가치가 있으면 연결해 남기고, 아니라면 지운다.

로그는 반대다. 지금의 생각에 맞게 계속 다듬고 싶어도 멈춰야 할 때가 있다. 지난 결정의 근거를 현재 기준으로 고쳐 버리면 왜 그런 선택을 했는지 돌아볼 수 없다. 잘못 판단했던 기록도 그때의 상태로 남아 있어야 의미가 있다. 원문은 sources/에, 사건의 맥락은 log/에 남기고, 그 기록에서 재사용할 해석만 별도의 notes/에서 계속 고친다.

반직선인 노트에는 다른 책임이 생긴다. 살아 있는 노트라고 해놓고 새 근거를 만날 때마다 새 파일만 만들면 정본이 여러 개가 된다. 계속 참조할 원칙이라면 기존 노트로 돌아가 문장을 고치고, 반례를 붙이고, 더 이상 맞지 않는 내용을 걷어내야 한다.

결국 점은 보존하고, 선분은 끝을 처리하고, 반직선은 다시 쓴다.

노트의 시간은 멈춤을 설계하는 일이다

노트의 시간 축이라고 하면 보통 생성일, 수정일, 일간 노트를 먼저 떠올린다. 나도 그랬다. 그런데 실제로 정리를 어렵게 만든 것은 날짜가 부족해서가 아니라 멈춤의 기준이 없어서였다.

이 노트는 그때의 기록으로 남아야 하는가. 정해진 시점에 처리되어야 하는가. 새 근거가 생길 때마다 계속 고쳐야 하는가.

이 세 질문에 답하면 모든 노트에 복잡한 상태를 붙이지 않아도 다음 행동이 보인다. 과거를 보존할 노트와 앞으로 자랄 노트를 같은 방식으로 다루지 않게 된다.

아마 이 구분도 실제 사용 속에서 조금씩 바뀔 것이다. 다만 지금의 나는 노트를 언제 만들었는지보다, 관심이 언제 돌아오고 언제 닫히는지를 먼저 생각한다. 동결한 MOC를 언제 남기고 지울지는 위키링크와 MOC 글에서, 원문·기록·계속 고칠 생각을 나누는 실제 규칙은 sources, log, wikilink 글에서 이어서 정리했다. 시간축은 날짜를 정리하는 방법보다 노트의 끝을 생각하는 방법에 가깝다.