이 시스템 쓰는 법

하나의 원리

노트는 몇 년 쌓이면 못 쓰게 된다. 양이 많아서가 아니라, 전부 stream으로만 쌓았기 때문이다. stream은 시간으로 색인된다. “3월에 내가 뭐 했지?”에는 답하지만 그 외에는 아무것도 답하지 못한다. 그런데 6개월 뒤에 실제로 떠오르는 질문은 “내가 이것에 대해 뭘 알고 있지?”이고, stream을 아무리 검색해도 이 질문에는 답이 나오지 않는다. 애초에 stream 안에는 답이 없기 때문이다. 답의 재료만 있다.

그래서 이 시스템은 규칙이 정반대인 두 개의 기록을 따로 둔다.

이 둘은 넘나드는 것이 의무일 때만 연결된 상태로 유지된다. 모든 log 항목은 최소 하나의 개념 노트를 링크해야 하고, 매주 몇 개의 관찰이 log에서 note로 승격(promote)된다. 사건의 기록과 이해의 기록은 서로 다른 집에 살아야 한다 참고.

무엇을 어디에

content/를 Obsidian에서 열면 평범한 vault처럼 동작한다. [[위키링크]], 태그, 첨부, 그리고 _templates/의 템플릿까지 그대로 쓸 수 있다. 웹사이트는 이 파일들을 보여주는 하나의 뷰일 뿐이다. 사이트가 내일 사라져도 잃는 것은 없다.

태그, 그리고 폴더가 없는 이유

도서관식 분류 체계는 없다. 일부러 없다.

분류는 항목마다 자리를 하나만 허용한다. 그런데 실험 하나는 대개 여러 곳에 동시에 속한다 — optimization 문제이면서, 특정 프로젝트의 사건이고, 어떤 논문의 반박이기도 하다. 물리적인 책은 한 칸에만 꽂히니까 분류가 필요했던 것이지, 파일에는 그 제약이 없다. 자리를 정하는 대신 링크와 태그를 쓴다.

다만 평평한 태그는 서른 개만 넘어도 무너진다. 그래서 태그는 두 단계다.

tags: [ml/optimization, method/pkm]

ml이 group, optimization이 subgroup이다. 슬래시가 없는 태그(meta)는 자식 없는 group으로 취급되므로, 쓰던 태그를 굳이 옮길 필요는 없다.

세 단계는 만들지 않았다. 세 단계부터는 태그가 서류함이 되기 시작한다 — 이게 무엇에 관한 것인가 대신 어디에 속하는가를 고민하게 되고, 그 고민 비용이 검색해서 얻는 것보다 커진다. 더 세밀한 관계는 링크가 맡는다.

홈의 The map이 이 구조를 그린다. group마다 세로선이 하나 있고 그 아래 subgroup들이 매달린다. 아무거나 누르면 그 태그가 붙은 항목들이 쭉 나오고, 정렬 방식(최신순 / 오래된순 / 링크 많은 순 / 가나다)을 바꿀 수 있다. 정렬 상태도 URL에 남는다.

리듬

매일 — 2분

캡처한다. 어디서든 /를 누르면 검색이 열리고, 에디터의 quick capture 칸에 한 줄 던져두면 된다. 캡처된 줄은 오늘 날짜 파일로 들어가 Inbox에 연결된다. 잡는 순간에 “이게 어디 속하지”를 정하게 만드는 것이야말로 사람들이 아무것도 안 잡게 되는 이유다.

매주 금요일 — 20분

/review를 연다. 순서대로 세 번, 네 번째는 시작하지 않는다.

1. 열린 것을 닫는다. 끝난 실험 중 result가 아직 pending인 것에 지금 답을 적는다. 기억이 남아 있을 때. 한 달 뒤면 이건 추측이 되고, 기록 안의 추측은 빈칸보다 나쁘다.
2. 한두 개를 승격한다. 이번 주 항목들을 훑으면서, 그 실행 하나를 넘어서도 참인 관찰을 찾는다. 그것이 개념 노트가 된다. 제목은 주장문으로 쓰고, 나온 항목으로 다시 링크한다. 하나면 충분하다.
3. 다음을 정한다. 쌓인 next 중 두 개만 남기고 나머지는 해당 항목에서 지운다. 할 수 있는 일을 전부 적어둔 목록은 계획이 아니다.

20분짜리 리뷰는 매주 일어난다. 한 시간짜리 리뷰는 두 번 하고 끝난다.

매달 — 40분

/garden을 연다. 빌드마다 새로 계산되는 목록이 뜬다. 아무 데도 닿지 않는 링크 · 조용해진 작업 · 답이 없는 질문 · 아무것도 배워가지 않은 log 항목 · 아무것도 가리키지 않는 노트 · 6개월간 손대지 않은 핵심 노트 · 관련돼 보이는데 링크되지 않은 쌍. 위에서부터 처리하고 타이머가 울리면 멈춘다. 그다음 진행 중인 프로젝트의 열린 질문을 갱신한다.

분기마다

허브 노트 — 많은 것이 가리키는 노트 — 를 다시 쓴다. 글 한 편을 발행한다. 한 분기 동안 글이 하나도 안 나왔다면 보통 노트가 논증으로 바뀌기를 멈췄다는 뜻이다.

항목 쓰기

log 항목

세 개의 필드가 가치의 대부분을 짊어진다.

id — 영구적이며, 재사용도 재번호 매기기도 하지 않는다: EXP-YYYY-MM-DD-a. 파일 이름이 바뀌거나 옮겨져도 살아남기 때문에, 어디서든 안전하게 인용할 수 있다.

concepts — 개념 노트 최소 하나. 없으면 빌드가 실패한다. 이것이 stream에서 garden으로 가는 다리다. 개념이 없는 항목은 아무것도 되짚어 올 수 없는 막다른 길이다.

result — supported · refuted · inconclusive · pending. 이 필드 하나가 스키마 전체의 값을 한다. 실패한 실험은 보통 가장 먼저 사라진다. 정리하기 지루하고, 넣을 자리도 없어서, “그거 이미 해봤는데”라는 지식이 누군가 기억하는 동안만 존재하게 된다. enum 하나면 그게 질의(query)가 된다.

실험은 question과 hypothesis를 돌리기 전에 적는다. 나중에 적은 가설은 가설이 아니라 서술이다.

지난 항목의 결론은 절대 고치지 않는다. 대신 supersedes:로 이전 id를 가리키는 새 항목을 쓴다. 둘 다 남고, 사이트가 그 계보를 그려준다. 3월에 내가 무엇을 믿었는가도 증거다.

개념 노트

제목은 라벨이 아니라 주장으로 쓴다.

• Warmup은 adaptive optimizer의 초기 분산을 억제한다 ✓
• Warmup ✗

주장은 문장 한가운데에 링크로 꽂아도 그 자체로 뜻이 통하지만, 라벨은 그러지 못한다. 이 시스템 전체에서 가장 효과가 큰 습관이다. 제목만 훑어도 그것이 지식으로 읽히게 된다.

maturity(seed → budding → evergreen)와 certainty(speculative → likely → established)는 정직하게 적는다. 독자에게 그대로 보인다. 확신 없는 것을 확신 없다고 표시한 채 공개할 수 있다는 것이, 애초에 공개를 가능하게 만든다.

논문

claim은 그 논문의 핵심 주장을 내 말로 옮긴 것이다. 초록이 아니다. critique는 내가 보기에 틀렸거나 입증되지 않은 지점이다. 논문이 아직 머릿속에 있을 때 둘 다 적는다. 나중에 믿을 수 있는 요약 하나가 믿을 수 없는 하이라이트 열 개보다 낫다.

다시 찾기

기억나는 정도에 따라 들어가는 문이 네 개다.

모든 필터는 URL이다. /log?result=refuted&project=x는 “여기서 내가 이미 아니라고 확인한 것들”이다. 자주 쓰게 되는 조합은 해당 프로젝트 노트에 붙여둔다. 프로젝트 안에 박혀 있는 질의 하나가, 다시는 못 찾을 북마크보다 낫다.

링크와 제안의 차이

항목 하단에 세 가지가 나오고, 셋 다 일부러 다르게 그려진다.

• Linked from — 내가 쓴 링크. 실선. 이것이 그래프다.
• Mentioned, not linked — 남의 글에 그 말은 나오는데 링크는 안 된 곳. 진짜 구조는 보통 여기 숨어 있다.
• Reads similar — 본문에서 계산된 것. 흐린 점선으로 그려지고, 절대 링크로 기록되지 않는다.

기계는 제안까지만 한다. 두 가지가 연결된다고 판단하는 행위 자체가 이해이기 때문이다. 그걸 자동화하면 그래프는 자라지만 이해는 자라지 않는다.

공개와 비공개

모든 항목은 visibility를 선언한다. 기본값은 private이고, 실수로 공개되는 일은 없다.

공개 사이트는 별도의 빌드이며 비공개 항목을 아예 포함하지 않는다. 본문도, 제목도, URL도 없다. 비공개 항목으로 향하는 링크는 조용히 일반 텍스트로 되돌려진다. 배포 때마다 검사가 돌고, 하나라도 새어 나가면 배포가 실패한다.

다만 검사가 대신해줄 수 없는 것이 하나 있다. 공개 노트 본문에 비공개 id를 평문으로 적으면 그건 누수다. 검사가 잡아주기는 하지만, 고치는 건 내 몫이다.

고치는 두 가지 방법

Obsidian — content/를 vault로 연다. Git 플러그인은 push 전에 pull하도록 설정한다.

/admin — 같은 파일을 브라우저에서, 로그인 뒤에서 고친다. 타이핑하는 동안 frontmatter를 빌드와 같은 규칙으로 검사해준다. 스키마를 깼다는 걸 한 시간 뒤 실패한 배포에서가 아니라 지금 알게 된다. 저장하면 커밋되고, 1분쯤 뒤 사이트가 다시 빌드된다.

둘 다 같은 마크다운을 고친다. 데이터베이스도, 제3의 사본도 없다. 그래서 둘이 어긋날 수가 없다.